Medium - Why Your Task Estimation is Likely Wrong?
in Trend
Trend 파악을 위한 Medium 기고문 포스팅 - 당신의 업무 예측이 틀리는 이유; 업무 예상 시간을 잘 잡는법에 대해 알아봅시다.
The problem of task estimation
The accuracy increase with task progress, but the growth is not proportional to the effort.
개발자에게 가장 대답하기 어려운 질문은 바로 이겁니다: 작업을 끝내는데 얼마나 걸리시죠? Story point, hour, day.. 모두 옛날 얘기일 뿐이죠. 누군가는 여러분의 작업이 언제 완료가 되는지 궁금해 합니다. 프로젝트 매니저 관점에서는 꼭 필요한 포인트 입니다. 일정이 있고 마감일이 있기 때문에 그들은 알아야 할 필요가 있는 것이죠. 어떻게 정확한 작업 시간을 예측할 수 있을까요? 발생할 수 있는 결함을 어떻게 계산해야 할까요? 여러분이 처음으로 하는 일이라서 학습에 시간이 필요하다면 어떻게 처리해야 할까요?
작업 예측은 매우 복합적인 것으로 많은 시간이 들고 클라이언트들과 의사소통 하는데도 쓰입니다. 왜 이렇게 작업 예측하기가 어려울까요?
소프트웨어 개발은 폭포수 같이 직선적인 흐름이 아닙니다. 카탈로그에서 항목 몇개를 골라서 수량을 담고 파는 것이 아니죠. 소프트웨어 개발은 오히려 예술과도 같습니다. 예술가에게 새로운 곡이나 초상화가 언제 완성될 지 묻는 것과 비슷한 것이죠. 스케줄링은 끊임없이 수정되어야 하며 작업 예측은 항상 오차가 생길 여지가 있습니다.
그렇기 때문에 이 포스트에서는 작업 예측의 기본에 대해서 설명해 드리고 제 경험에서 유용했던 기술을 공유해드리겠습니다. 작업 예측에 관한 문제를 완전히 해결할 수 있겠지만 실수를 줄이실 수는 있을겁니다.
Task estimation techniques #1: Experience
시간을 예측하는 일은 아주 흔한 일입니다. 차가 고장났다고 쳐봅시다. 처음에 여러분이 정비사에게 물을 질문이 뭐죠? “제차가 언제쯤 고쳐질까요?”, 이 질문은 “언제 작업이 끝나는지” 묻는 것과 비슷하죠. 그래요 아마 “수리비가 얼마나 나올까요?”같은 질문도 많이 나오겠지만 항상 시간이 중요합니다(웃음). 소프트웨어 개발에서는 모든 것이 다른 직업군과 비슷하지만 매번 새로운 것을 한다는 것이 다릅니다. 만약 이런게 아니라 같은 일을 반복하는 거라면 그냥 코드를 복붙하면서 재사용만 하면 될겁니다. 이 경우에는 여러분의 작업이 언제 완료되는지 정확하게 알 수 있습니다. 흠, 그러고보니 우리는 오직 작업이 끝난 경우에만 작업에 소요된 시간을 알 수 있습니다.
작업이 끝난 다음에야 우리는 완벽한 정보를 얻게 되지만 이미 끝나버린 작업이라서 필요가 없는 정보들이죠. 아니면 여러분은 작업 시간을 대충 찍을 수도 있을 겁니다. 이렇게 하면 빠르게 작업을 예측할 수 있지만 아마 제일 안좋은 방법일 겁니다. 작업 예측에 대해 한번 큰 개념으로 생각해봅시다. 작업 시간에 많은 시간을 들일 수록 좋은 예측이 될 것입니다. 그러나 작업 예측에만 시간을 쓰기에는 아깝죠. 그럼 얼마나 시간을 들여야 적당할까요? 다음의 다이어그램은 작업 예측과 노력의 상관관계를 나타냅니다. 처음에 작업을 예측할 때는 많은 불확실성이 있습니다. 그러나 작업이 진행되고 더욱 구현이 되면서 여러분이 정보가 많아질 수록 작업 예측에 정확도가 올라갑니다. 요구사항 명세서가 있다면 이런 불확실성을 많이 줄일 수 있습니다. UI가 어떻게 동작하는지 보여주는 프로토타입이 있는 것도 많은 것을 명확하게 해주죠. 각 단계는 불확실성을 줄여주지만 이런 것들이 다 비용입니다.
우리의 작업 예측 모순을 생각해보면 작업이 끝났을 때 작업 시간을 확실히 알 수 있지만 제안을 한 고객이 마음을 바꿀 수도 있기 때문에 이러면 작업은 작업대로 하고 돈과 시간을 날리게 되는 것이죠.
The accuracy increase with task progress, but the growth is not proportional to the effort.
이 경우에 Pareto의 80/20 법칙이 좋은 해답이 됩니다. 80%의 정확도를 얻는데 들이는 시간이 1이라면 100%의 정확도를 얻는데는 다섯배가 들어가게 됩니다. 더욱 현실적인 답변은 작은 리스크를 피하기 위해서 너무 많은 시간을 업무 예측에 쓰지 말라는 것입니다.
Task estimation techniques #1: Experience
첫번째로 가장 활용하기 쉬운 도구는 경험입니다. 같은 작업을 한적이 있나요? 거기에 얼마나 시간이 소모되었나요? 해당 이슈와 작업을 떠올려보면 이번에 얼마나 작업 시간이 들어갈지 예상할 수 있을겁니다. 이건 여러분이 개발자가 아니라도 마찬가지죠. 만약 여러분이 PM이라서 개발자에게 작업에 대한 예상시간을 물어보고 그 시간이 하루였다고 칩시다. 그런데 실제 개발에 소요되는 시간은 3일이었다면 여러분은 비슷한 작업에 걸리는 시간이 사흘이라는 것을 알 수 있겠죠. 물론 이것이 완벽하게 딱 맞아 떨어지는 것은 아닙니다. 왜냐면 효율에 영향을 미치는 요소들은 너무나도 많기 때문이죠 ( 작업을 맡은 사람이 특정 업무를 처음할 수도 있겠죠? ) 그러나 같은 상황이라면 이런 사례는 도움이 될 수 있을겁니다.
Task estimation techniques #2: Ask the expert
만약 여러분이 어떤 것을 해야하는지 이해하지 못하는 상황이라면 당연히 얼마나 시간이 걸리는 지도 알 수 없을 것입니다. 가장 좋은 방법은 알고 있는 사람에게 묻는 것이겠죠. 이것이 선배들에게 조언을 구하는 것입니다. 이 방법은 아주 빠르게 피드백을 받을 수 있기 때문에 좋습니다.
Task estimation techniques #3: Estimation games
다른 재밌는 방법은 여러사람들을 모아놓고 그들은 얼마나 시간이 소요될지 물어보는 것입니다. 그 중에 카드 게임형태도 있는데 각 멤버들이 예측시간을 작성해서 토너먼트 식으로 선택을 하는 것입니다. 가장 적합하다 싶은 모델이 선택되는 것이죠. 저는 이 방법이 꽤나 모호하다고 생각하는데 왜냐하면 매번 상황은 달라지는데 항상 똑같은 개념을 적용하기 때문입니다. 명확한 기준을 세워서 비교를 통해 빠르게 결과를 얻을 수 있도록 하시는 것이 좋습니다.
The tricks for the good planning and task estimation
스케줄링에서 많은 실수를 통해 저는 좀더 나은 프로세스를 만드는 규칙들을 알게 되었습니다. 이런 기술들은 작업 예측에 있어서 같은 실수를 저지르는 것을 방지해 줄 것입니다.
Take a buffer, but not too much
어느정도의 버퍼를 갖는 것은 결점을 보완하는데 유용할 수 있습니다. 그렇지만 만약 여러분이 정비소에 갔는데 바퀴를 교체하는데 3달이 걸린다고 하면 어떻게 하시겠어요? 아마 여러분은 다른 정비소에 가겠죠. 따라서 버퍼는 필요하지만 딱 필요한큼만 갖도록 해야합니다. 베스트 케이스와 워스트 케이스를 고려해보고 중간점을 잡도록 하세요. 쫌 대략적이긴 하지만 얼추 맞긴 합니다.
Don’t be superb, always ask an expert ( or your collegue. )
피드백을 받는 것은 우리에게 주어진 가장 큰 기회 중 하나입니다. 진짜루요. 그냥 동료분에게 물어보세요. 동료분들은 여러분들이 못보고 지나쳤던 위험요소를 짚어주거나 아니면 작업이 더욱 빨리 끝나도록 조언을 해줄 수 있을 것입니다.
Share the risks
그냥 어떤 것은 단순히 예측을 하기 어려운 것이 있습니다. 문제를 파악하는데 시간이 걸리거나 POC를 만드는데 시간이 걸리는 것이죠. 예측에 시간을 많이 투자하는 것은 좀 껄끄럽지만 그래도 고객에게 납기일을 지키지 못할거 같다고 말하는게 더 최악이 될겁니다.
Do not take it too long
여러분이 작업에 걸리는 시간을 파악하기 위해 시간이 좀 걸리는 때가 있을겁니다. 아니면 너무 바빠서 대답을 못할 수도 있죠. 그렇지만 항상 너무 오랜 시간을 투자하지 않도록 하세요. 사람들은 여러분의 정보가 필요하고 여러분은 그들에게 피드백을 줘야합니다. 만약 시간이 너무 오래걸린다면 양해를 구해서 연기를 요청하거나 다른 액션을 취해야 합니다.
Pick the right tool
관리 업무는 그냥 주사위 굴려서 나오는 숫자나 말해주고 하는 것이 아닙니다. 항상 자주 의사소통하고 업무 절차를 줄여나가야 합니다. 여러분도 아시는 것처럼 메일이나 채팅은 좋은 도구가 아니죠. Asana는 작업을 관리하고 작업 플로우를 관리하는데 훌륭한 플랫폼입니다. 만약 개발자인 경우에는 애저 데브옵스, 깃랩, 깃허브와 같은 것들로 업무와 개발 프로세스를 통합할 수 있을 것입니다.
Summary
- 업무 예측에 관한 글,
- 시간을 예측해보고 항상 결과를 비교해야 함. 그래야 추측이 아니라 예측이 된다.
- 경험자, 동료들에게 업무에 소요되는 예상시간을 한번 피드백 받아볼 것
