실무를 해본 경험이 없어서 일정 산출이라는 말이 굉장히 낯설게 느껴진다. 프로젝트를 할 때, 기한을 정해두긴 하지만 그건 그냥 데드라인이고 일정을 산출하지는 못한다. 경험이 부족하기에 일정을 어떻게 산출해야 할지 모르기 때문이다.
취업을 먼저하고 개발 일정을 산출 할 수 있지만, 그것보다 어떠한 상황에서 일정을 산출하고 어떻게 관리하며 산출과정에서의 커뮤니케이션이 궁금하여 이 세션에 참여하게 되었다.
일정 산출 역량은 프로젝트의 성공 여부를 좌우하는 핵심 요소로, 개발자들이 현실적인 목표를 설정하고, 팀원들과 효율적으로 협업하며, 프로젝트 진행 중 발생할 수 있는 리스크를 사전에 대비할 수 있게 한다. 특히, 시간암배를 통해 추가적인 업무도 가능하고 가장 중요한 야근을 피할 수 있다!
서비스 성숙도가 낮은 회사같은 경우에는 혼자 여러가지 기능을 구현하거나 내 가 모르는 스택으로 구현해야 할 수 있다. 이러한 상황인데, 물어볼 사람도 없는 상황에서는 책을 참고하라고 말씀하셨다. '과연 이걸 실전에 적용이 될까?' 싶었는데, 책이 항상 옳았다고 책을 참고하면 좋은 답을 찾을 수 있을 것이라고 말씀하셨다.
'과일을 담을것을 만들어주세요'라는 말을 들었을 때 누군가는 상자를 떠올리고 누군가를 과일바구니, 접시 등 여러가지 것들을 떠올릴 수 있다. 이렇게 개발을 진행하게 되면 엉뚱한 것을 개발하고 그에 따른 리소스 소모가 심하기에 적극적으로 커뮤니케이션 하여 요구사항을 좁혀갈 필요가 있다고 말씀하셨다.
설계, 구현, 배포준비와 같이 프로세스 별로 일정을 산정하여 잘게 분할해서 일정을 산정할 필요가 있다고 말씀하셨다.
누가 보지 않더래도 일정과 작업했던 내용들, 버그사항들을 문서화할 필요가 있다고 말씀하셨다. 이를 통해, 일정을 투명하게 공개하여 후에 했던 일들을 객관적으로 판단할 수 있다.
일정 산출 시 버퍼를 두어 예기치 않은 상황에 대비할 것을 권장하셨다.
특수 상황 고려: 휴가, 공휴일, 회의, 스터디, 행사 등 특수한 상황을 고려하여 일정을 산정해야 한다고 강조하셨다. 프로젝트 중요도와 개인 일정의 중요도를 조율하는 것도 중요하다고 하셨다.
프로젝트 진행 중 일정이 변경될 경우, 최악의 시나리오까지 생각해보고 문서화하는 것이 중요하다고 하셨다. 이를 통해 문제 발생 시 빠르게 대처할 수 있고, 리스크를 최소화 하기위해 사전에 노력할 수 있다.
내 편은 동료밖에 없다. 동료들과 업무, 일정등을 공유하며 여러가지 아이디어를 얻을 수 있고 도움을 받을 수 있다. 물론, 동료가 도움이 필요하면 도움을 줄 수 있어야 한다.
프로젝트 기간 동안 발생한 문제들을 기록하고 회고하며 문서화하는 것을 강조하셨다. 프로젝트 기간동안 어떻게 진행되었는지, 일정이 차질이 없었는지, 어떠한 문제가 있었는지를 모두 회고하고 문서화할 것을 꼭 강조했다.
개발자는 코드와 씨름하는 사람이 아니라, 어떠한 프로덕트를 기획서를 보고 구현해내는 사람이다. 하지만, 기획서는 사람이 작성하고 그걸 이해하는 것도 사람이기에 오해가 생길 수 있고 그것을 명확하게 짚을 필요가 있다. 그 후에 개발 일정을 내 역량과 리스크가 생길 상황들을 생각하며 산출하고 그것들을 문서화하는것이 중요하다.
커뮤니케이션과 문서화에 대해 다시 한 번 크게 상기시키는 세션이었다.