- 스탠디시 그룹 2020 카오스 리포트에 따르면, IT 프로젝트 실패 원인 중 가장 빈번하게 언급된 것은 기술 문제가 아닌 요구사항 불명확이었습니다. 예산과 일정을 모두 지킨 프로젝트는 전체의 31%에 불과했습니다.
- 병목이 코드 단계에 있는지, 목표 결정 단계에 있는지에 따라 해결 방법이 완전히 달라집니다. 코드 병목에는 인력 추가가 효과적이지만, 목표 병목에는 인력 추가가 혼선만 늘립니다.
- 배포 빈도는 높은데 방향이 자주 바뀐다면 병목은 코드가 아닌 목표 결정에 있습니다. 이 경우 개발 프로세스 개선이 아닌 기획 프로세스 개선이 필요합니다.
개발팀에 사람을 더 넣어도 속도가 안 나는 이유
스탠디시 그룹이 2020년 발표한 카오스 리포트는 수천 건의 IT 프로젝트를 분석했다. 예산과 일정 안에 성공한 프로젝트는 31%였고 실패 또는 취소된 프로젝트가 19%였으며 나머지 50%는 예산과 일정을 초과했다. 실패와 지연을 겪은 프로젝트에서 가장 빈번하게 언급된 원인은 요구사항 불명확이었다. 기술 문제나 개발자 역량 문제가 아니었다.
프레더릭 브룩스(Frederick P. Brooks)는 1975년 '맨먼스의 신화'에서 브룩스의 법칙(Brooks's Law)을 정리했다. 지연된 소프트웨어 프로젝트에 인력을 추가하면 더 늦어진다는 것이다. 추가 인력은 기존 팀원의 시간을 교육과 조율에 쓰게 만들기 때문이다. 이 법칙은 목표가 명확할 때도 성립하는데, 목표가 불명확할 때는 더 강하게 작동한다.
병목이 코드 이전, 즉 무엇을 만들어야 하는지의 결정 단계에 있으면, 개발 자원을 늘려도 전체 출력이 늘지 않는다. 엘리야후 골드랫이 제약이론(Theory of Constraints)에서 정리한 것처럼, 병목이 아닌 곳의 효율을 높이는 것은 전체 처리량을 늘리지 못한다. 병목만 빠르게 만드는 것이 전체를 빠르게 하는 유일한 방법이다.
목표 병목과 코드 병목을 구분하는 방법
니콜 포스그렌(Nicole Forsgren)과 동료들이 2018년 'Accelerate'에서 발표한 연구는 소프트웨어 전달 성과를 측정하는 지표를 네 가지로 정리했다. 배포 빈도, 변경 리드타임, 서비스 복구 시간, 변경 실패율이다. 이 네 지표를 함께 보면 병목이 코드 단계에 있는지 기획 단계에 있는지를 구분할 수 있다.
배포 빈도가 낮고 리드타임이 길면 코드 병목이다. 개발 프로세스, 자동화, 테스트 구조를 개선해야 한다. 반면 배포 빈도는 적절한데 배포 이후 방향이 자주 바뀌고 기능을 되돌리는 경우가 많다면, 코드 병목이 아닌 목표 결정 병목이다. 이 경우 개발 프로세스 개선은 효과가 없다.
Ahn Partners 판단: 중소중견기업에서 '개발이 느리다'는 불만이 나올 때 실제 원인을 진단해 보면, 코드 단계 문제인 경우보다 기획과 개발 사이 요구사항 전달 단계 문제인 경우가 더 많습니다. 기획이 진행 중에 변경되거나, 두 단계의 경계가 모호한 경우입니다. 이것은 개발팀의 역량 문제가 아닌 조직 프로세스 문제입니다.
목표 병목을 해결하는 첫 번째 조치
목표 병목의 첫 번째 징후는 기획 문서가 개발 도중에 수정되는 빈도다. 이것을 측정하지 않는 조직은 문제의 규모를 모른다. 가장 단순한 측정 방법은 스프린트 시작 이후 요구사항이 변경된 건수를 주단위로 기록하는 것이다. 이 수치가 일정 수준을 넘으면 개발 프로세스가 아닌 기획 프로세스를 고쳐야 한다는 신호다.
두 번째 조치는 개발 착수 전에 '완료 기준'을 명문화하는 것이다. 이 기능이 완성됐다고 볼 조건을 기획자와 개발자가 함께 합의하는 것이다. 이 합의가 없으면 개발 중에 기준이 바뀌고, 개발팀은 계속 수정을 반복한다. 수정 반복은 속도를 줄이는 가장 큰 요인 중 하나다.
한 문장으로 정리하면, 개발팀이 느린 것이 아니라 무엇을 만들어야 할지 결정되지 않아서 느린 것이다. 병목이 코드 이전에 있을 때, 개발 속도를 높이려는 시도는 문제를 더 빠르게 악화시킨다.
점검 목록
- 최근 완료한 개발 프로젝트에서 착수 이후 요구사항이 변경된 건수가 얼마나 되는가
- 배포 빈도와 배포 이후 방향 변경 빈도를 함께 추적하고 있는가
- 기능 개발을 시작할 때 완료 기준이 기획자와 개발자 사이에 문서로 합의돼 있는가
출처
- Standish Group (2020). Chaos Report 2020. Standish Group International.
- Brooks, F.P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. [Brooks's Law 원전]
- Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
- Goldratt, E.M. & Cox, J. (1984). The Goal: A Process of Ongoing Improvement. North River Press. [제약이론 원전]
기술 조직에서 전사 운영으로 역할을 확장하는 방법은 기술 책임자에서 운영 총괄이 됐을 때 가장 먼저 틀리는 것에서 이어집니다.
우선순위는 있지만 실행이 따르지 않는 조직의 문제를 찾는 방법은 안건이 많아도 조직이 움직이지 않는 것은 우선순위가 없어서가 아닙니다에서 이어집니다.