Computer >> 컴퓨터 >  >> 프로그래밍 >> Ruby

소프트웨어 개발 견적은 목표가 아니라 커뮤니케이션 도구입니다

"이 작업은 얼마나 걸릴까요?"

"이 변경 사항을 적용하기가 얼마나 어려운가요?"

이런 질문에 화가 나고 답답함을 느낀다면, 아마 소프트웨어 개발자일 가능성이 높습니다. 견적(estimate)은 참으로 고통스러운 작업입니다. 특히 견적을 요청하는 사람(여기서는 편의상 '밥'이라고 부르겠습니다)이 자신이 요청하는 작업에 대해 막연한 윤곽만 가지고 있을 때 더욱 그렇습니다. 이러한 고통의 상당 부분은 밥이 실제로 원하는 것과 내가 생각하는 '밥이 원하는 것' 사이의 차이에서 비롯됩니다.

견적은 목표가 아니다

개발자 입장에서 견적이란 "평균적으로 이 작업을 완료하는 데 얼마나 걸릴까?"라는 질문입니다. 그런데 그 질문에 답할 충분한 정보가 없다는 점, 그리고 내가 말한 숫자 그대로 평가받게 될 것이라는 점 때문에 답답합니다. 게다가 견적을 지키는 능력이 전반적인 성과 평가의 척도가 될 것이라고 생각하면 스트레스와 짜증이 밀려오기 마련입니다.

견적은 커뮤니케이션 도구다

출시되는 모든 제품에는 그것에 의존하는 다른 요소들이 있습니다. 회사 규모에 따라 마케팅, 홍보, 비즈니스 분석, 향후 제품 기획 등 다양한 분야가 관련될 수 있습니다. 즉, 밥이 정말로 알고 싶은 것은 "이 작업이 완료되었다고 가정하고, 거기에 의존하는 계획을 세우기 시작할 수 있는 시점이 언제인가?"라는 질문에 대한 답입니다.

그런데 개발자는 "~까지 완료될 예정입니다"라고 답하는 반면, 밥이 듣고 싶어 하는 것은 "~까지 반드시 완료됩니다"라는 확실한 약속입니다.

David Bryant Copeland의 훌륭한 책 『The Senior Software Engineer』는 첫 장에서 바로 이 문제를 다룹니다.

시니어 소프트웨어 엔지니어는 가장 중요한 작업을 신뢰성 있게 수행할 것이라고 신뢰받고, 그렇게 해야 할 책임이 있습니다. 이를 달성하는 방법은 자신이 하는 모든 일을 '결과의 전달'에 집중하는 것입니다.

이 점을 명심한다면, 밥의 입장에 맞춰 견적을 제공하는 것이 가장 좋은 방법입니다. 구체적으로는 다음과 같습니다.

  • 견적은 50%가 아니라 90%의 확신 수준으로 작성한다

    밥은 작업이 완료된 시점부터 그것에 의존하는 계획을 세울 수 있기를 원합니다. 이를 위해 버퍼를 추가해야 한다면(아마 필요할 것입니다) 그렇게 해도 좋습니다. 한두 시간 뒤에 다시 답변해야 하는 상황이라면 그것도 전혀 문제되지 않습니다.

  • 견적은 테스트 인계 시점이나 배포 대기열 통과 시점이 아니라 '출시까지의 시간'을 기준으로 작성한다

    이것 역시 결과 전달에 초점을 맞추기 위함입니다. 밥이 프로젝트 출시를 기다리고 있는데 작업이 QA 단계에 머물러 있다면 그것은 밥에게 아무런 도움이 되지 않습니다. 따라서 보통 견적에 다시 한번 버퍼를 추가해야 하며, 역시 그래도 괜찮습니다.

  • 최고의 견적은 종종 "지금은 답변드리기 어렵습니다. 확인 후 다시 연락드리겠습니다"다

    견적을 더 작은 단위로 나누면 각 부분을 이해하기 쉬워지고, 90% 확신 수준의 출시 시점 견적을 도출하는 것이 훨씬 수월해집니다. 정확한 견적을 산출하는 구체적인 방법론을 다룬 책은 많지만, 이 글의 범위를 벗어나므로 생략하겠습니다.

"속도가 너무 느리다"는 지적을 받으면 어떻게 해야 할까?

제가 일했던 모든 직장에서 경영진은 우리가 더 빨리 움직일 수 있기를 바란다고 말했습니다. 제품이 아무리 빠르게 전달되더라도, 품질이 완전히 희생되더라도, 견적이 터무니없이 무리한 수준이더라도, 하루 20시간을 일하더라도 경영진은 여전히 더 빨라지기를 바랍니다. 개발자의 역할은 그것이 어디까지나 하나의 '바람'일 뿐임을 인식하고, 빠르면서도 유지보수 가능한 속도를 유지하고, 예측 가능하게 행동하며, 결과를 전달하고, 높은 품질 기준을 지키는 일입니다.

견적보다 훨씬 빨리 끝내서 견적이 지나치게 부풀려졌다고 보이면 어떡하지?

꾸준히 과대평가를 했다는 이유로 불이익을 받는 사람을 본 적이 없습니다. 오히려 나중에 예상보다 훨씬 오래 걸리는 프로젝트가 생겼을 때 그 버퍼가 빛을 발합니다. 같은 폭이라도 과소평가보다 과대평가가 훨씬 안전합니다(손실 회피 성향과 비슷하다고 생각합니다). 대부분의 경우 백로그가 있으므로 다음 작업을 더 일찍 시작할 수 있고, 그야말로 일석이조입니다.

만약 50% 확신 수준으로 목표를 잡으면, 예상치 못한 문제 하나로 제품 일정 전체가 무너질 수 있습니다. 실제로 그럴 확률이 약 절반입니다! 반면 90% 확신 수준을 목표로 하면 설령 상황이 나빠지더라도 나머지 일정은 계획대로 진행될 수 있습니다. 제품은 제때 출시되고, 모두가 만족하며, 당신은 승진과 연봉 인상, 그리고 최고의 보상인 '새로운 견적을 작성할 기회'까지 얻게 됩니다!