※ 일본의 한 블로그 글을 번역한 포스트입니다. 오역 및 의역, 직역이 있을 수 있으며, 틀린 내용은 지적해주시면 감사하겠습니다.
견적이란?
견적은 금액, 양, 기간, 행동을 미리 개산하는 것을 의미한다. 이러한 견적은 무언가를 행하기 전에 사전에 그 결과를 예상하는 것을 말한다.
견적을 사용하는 경우는 소프트웨어 개발에 한정된 이야기는 아니지만, 제조업에 있어 어떠한 소프트웨어 개발에 있어서는 "견적"이라는 업무가 다양한 경우에 등장하고 있다.
견적이 힘든 사람이 많다.
소프트웨어 개발에서는 "이 기능을 개발할 때는 어느정도 걸려서 완성됩니까?"을 견적내는 경우가 많다. 이러한 시간적 견적을 힘들어 하는 사람이 의외로 많다.
"견적냈던 대로 끝나지 않으면 어쩌지?" 라던가 "이 작업 자체가 구체적으로 상상이 안되서 어느정도 시간이 걸리는지 모르겠다."등 매번 부담을 느끼기에, 견적을 내는 작업이 굉장히 싫었다.
그럼 이러한 부담감을 어떻게 줄일 수 있을까? 그것은 "견적은 어떤 것인가?"를 깊게 이해함으로써 해결 할 수 있다.
견적을 낼 때 중요한 마음가짐
먼저, 견적을 할 때 가져야 할 마음가짐은 "견적은 정확하지 않다"라는 생각을 항상 갖고 있는 것이다.
견적은 앞서 말했듯 어떠한 것을 하기전에 상정하고 대략적으로 계산하는 것이다. 따라서 초기 개발부터 그 견적대로 진행되는 경우가 오히려 신기한 것이다.
견적의 단계
여기서 부터는 조금 더 실전적인 내용에 대해서 설명하도록 하겠다. 견적은 기본적으로 아래의 공정과 관련이 있다.
- 무엇을 위한 견적인지를 확인하기
- 견적내기
- 견적의 근거를 설명하기
- 필요에 따라 수정하기
견적에는 반드시 목적이 있다. "개발 금액을 대략적으로 계산하고 싶다", "개발 기간(릴리즈일)을 알고 싶다", "생산성을 계산하고 싶다"등 의뢰하고 있는 사람이 어떠한 목적으로 이 견적을 원하고 있는지 반드시 확인해야한다.
목적 확인에서 특히 알고 싶은 것은 "견적의 정확도"이다. 견적의 근거를 설명하는 부분에 대해서 나중에 자세히 설명하겠지만, 목적을 모르면 정확도나 낮은 견적이 되어버리는 경우가 많으므로, 커다란 차이가 발생한 경우에 제대로 커뮤니케이션이 되지 않는 문제가 발생한다.
이러한 문제를 피하기 위해서는 반드시 견적의 목적에 대해서 반드시 인식해두자.
견적의 근거를 설명하기
이 부분에서는 실제로 견적을 내는 과정에 대해서 설명하도록 하겠다. 하지만 그전에 견적을 낼 때 "견적의 근거(어떠한 근거로 그렇게 견적을 냈는가?)"에 대해서 이해할 필요가 있다.
우선 무엇을 바탕으로 견적을 내면 좋을지에 대해서 생각해보자. 여기서는 "자신이 하는 작업 시간의 견적"에 초점을 맞춰 얘기하도록 하겠다.
견적의 근거는 가볍게 분류하면 아래의 다섯가지로 나눌 수 있다.
- 자신이 과거에 했던 것과 동일한 작업
- 자신이 과거에 했던 것과 비슷한 작업
- 다른 사람이 과거에 했던 동일한 작업
- 다른 사람이 과거에 했던 비슷한 작업
- 추측
첫 번째는 자신이 이전에 했던 것과 완전히 동일한 작업인 경우이다. "A라는 작업을 할 때 이전에 2시간 걸렸으니 이번에도 2시간으로 견적내자"라는 케이스이다.
두 번째는 완전히 동일하지 않지만, 거의 비슷한 구성의 작업을 하는 경우이다.
세 번째는 자신이 아닌 다른 사람이 동일한 작업을 했던 경험이 있는 경우이다. 이 경우에는 ''X씨가 이전에 2시간만에 끝냈다고 말했으니까 대체로 이와 비슷하게 견적낸다"와 같은 형식이다.
네 번째는 두 번째와 거의 비슷하므로 스킵한다.
세 번째와 네 번째 경우는 자신의 작업 스피드랑 다른 그 누군가의 작업 스피드의 차이를 이해해둘 필요가 있다. X씨의 작업 스피드가 나보다 빠르다면 조금 더 시간을 확보한다는 식이다.
다섯 번째는 적당히 추측하는 것이다. 완전히 예측되지 않지만 숫자를 적어야만 하는 경우 최후의 수단이 된다.
이러한 견적의 근거는 첫 번째가 가장 정확도가 높고, 다섯 번째가 가장 낮다.
견적의 정확도는 경험 양에 비례한다.
근거를 기반으로 견적을 낼 때, 정확도를 의식하는 것도 중요하다. 앞서 말햇듯 가장 높은 정확도의 견적 근거는 "자신이 관거에 똑같은 작업을 했을 경우"이지만 그렇다고 해도 정확도가 떨어지는 경우가 있다. 그것은 바로 경험의 양 차이이다. 기본적으로 견적의 정확도는 경험치에 비례한다.
예를 들면, 도보로 회사에 통근하고 있는 사람의 통근 시간을 견적 낸다라고 할 때, 같은 회사에 1년째 다니고 있는 A씨랑 그날이 두 번째 출근길인 B씨면 역시 A씨가 정확한 견적을 낼 수 있다. 그것은 1년이라는 경험의 양을 통해 오차가 발생할 수 있는 점을 미리 고려하기 때문이다.
이러한 견적과는 경험의 축적에 따라 정확도가 달라진다. 따라서 만일 같은 작업을 경험했다고 해도, 딱 한 번 경험한 경우 정확도가 떨어질 수 밖에 없다.
견적에 버퍼를 두기
소프트웨어 개발에 있어서 일반적이지만, 개발을 할 때 예상치 못한 트러블이나 지연은 일반적으로 발생한다. 개발하는 것은 결국 인간이기 때문에 컨디션이나 가정 사정으로 인한 스케줄 지연 등 언제 일어날지는 모르는 요소가 많이 포함되어 있기 때문이다. 이러한 경우는 견적한 시간에 버퍼(어떤 트러블이 발생했을 경우의 잉여 시간)을 미리 추가해두자.
버퍼에 대해서 어느정도 넣어두는 것이 좋은가에 대한 이야기가 많지만 개인적으로는 20%~50%비율이 적덩하다고 생각된다.
견적의 근거를 설명하기
마지막으로 가장 중요한 포인트로 그 견적을 의뢰인에게 설명하는 작업이 있다. 여기서 포인트는 무엇을 근거로 이번 견적을 작성했나? 몇 퍼센트의 버퍼를 추가했는가?(이유를 설명할 수 있다면 더욱 좋다) 등 견적 내용을 정확하게 설명하는 것이다.
설명할 때는 앞에서 말했던 목적이 달성되는지를 구체적으로 얘기할 필요가 있다. 하지만 틀렸다고해도 비난받을 일은 거의 없을 것이다.
중요한 것은 필요한 내용을 정확하게 상대방에게 전달하고 견적에 대해 합의를 하는 것이다. 견적은 어디까지나 예상이기 때문에 합의만 이루어지면 결과는 그다지 중요하지 않다.
참고자료
https://zenn.dev/nuits_jp/articles/2022-07-31-estimate-assumptions
'IT > 기초 지식' 카테고리의 다른 글
| 코드 리뷰의 코멘트에 태그를 사용하여 심리적 안전성 올리기 (0) | 2023.06.28 |
|---|---|
| 검색 속도가 빨라지는 데이터베이스 설계 (0) | 2023.06.25 |
| UX 디자인의 5단계 모델 (0) | 2023.06.15 |
| DB 설계 공유는 dbdocs를 이용하자 (0) | 2023.06.14 |
| 읽기 쉬운 코드를 쓰기 위한 가이드라인 (0) | 2023.06.11 |