개발은 얼마나 걸릴까요?
지인은 한달이면 된다는데, 우리 개발팀은 왜 6개월이 걸릴까요?
어쩌다 보니 기획자는 개발부서에 무언가를 만들어 달라고 '요청'하는 관계로 협업을 하게된다.
사실, 기획은 어떤 문제를 먼저 풀지, 어떤 방식으로 풀지를 '정의'하는 역할이고, 개발팀은 이것을 '실현'하는 역할이지 누가 누구에게 요청하는 관계는 아니다. 오히려 개발팀이 기획팀에게 우선순위에 근거에 대한 요청이라던가, 더욱 정교한 정의를 요청할 수도 있다.
여튼, 그럼에도 불구하고 전반적인 일정과 출시를 관리(일정을 예측하여 타 부서와 협업을 조율함)하는 역할도 포함하다보니, 어떤 기능 구현에 대해 '얼마가 걸리는가'를 협의하는 회의가 종종있다
그렇다. 불편한 회의다.
용산에서 가격을 흥정하는 듯한 밀당이 오고가기도 한다.
개인차가 있지만, 대부분 개발자들은 보수적으로 일정은 산출한다. 그 일정을 지켜야 하는 책임감과 개발이라는 기본적인 불확실성이 큰 과업을 예측하려다 보면, 보수적으로 산정하는 것이 어느정도 합리적인 선택이다. (그럼에도 불구하고, 그 보수적 예측을 언제나 넘어선다)
간단한 수정사항이라고 생각했는데, 터무니없는 일정을 이야기 해서 상처를 받아 지인 개발자 친구들에게 물어보면 신기하게도 1/3의 기간을 이야기 한다. 우리 개발팀이 무능한 것인가? 자괴감에 빠지기도 한다.
왜 이렇게 개발 일정은 다르게 산정되는 것일까?
모든 사람의 속마음은 어차피 모른다는 가정하에 평균 정도라고 하고 (아주 못된 사람은 없다고 하고) 생각보다 개발역량이 그렇게 차이나지는 않는다. 일정이 2~3배 차이나는 것은 이상하다.
상황마다 다르겠지만, 두 가지가 대부분 원인이었는데,
1. 요구사항이 추상적이라 범위를 다르게 인식한다.
2. 완성도 수준과 완료에 인식의 차이이다.
예를들어,
앱스토어에 커뮤니티 기능을 올리면 애플님께서 사용자 생성 컨텐츠는 차단기능을 넣어야 한다며 리젝을 주실 텐데, 이를 해결하기 위해 기획자는 차단 버튼과 팝업 문구를 정해서 디자인을 해서 전달한다. 그런데 개발팀에게 물어봤더니 2주가 걸린다고 한다. 어떤 개발자는 이틀이면 된다고 한다.
이 간단한(?) 기능을 위해서는
* 당연히 백오피스에 이런 차단 관리를 수동으로 할 수 있는 기능을 추가해야한다
* 향후 CS를 대비해서 로그를 남겨야 한다
* 해당 컨텐츠가 홈화면에 노출된 경우에 홈화면 노출 컨텐츠에 대한 정책을 새로 새우거나, '차단된 컨텐츠'라는 표시를 해야한다
* 차단을 다시 원복할 수 있는 경로를 만들어 두어야 한다
* 비회원인 경우 처리를 해야한다.
이렇게 관련된 다양한 상황들을 자세히 정리하면 조금은 비슷한 일정을 산정하게 될지도 모르겠다. 이때 기획에서는 모든 것을 만들지 않고, '고객센터로 문의주세요' 팝업을 적절히 섞어가며 이정도 예외상황에 대한 개발 리소스를 최소화 하는 고민을 하면 개발 범위가 작아질 것이다
즉, 일정을 산정하는 것이 아니라 '개발 범위'를 일정으로 환산하는 것이다. 이 개발 범위의 조절을 통해 일정을 조율할 수 있고 이 범위를 정하는 것은 '기획자'이다.
일정이 많이 다르다면, 개발범위가 잘 정의되지 않거나 전달되지 않은 것일 수 있다. 그러니 다른 개발자 지인들에게 백날 물어봐야 소용이 없다. 어차피 대신해 줄 것도 아니고, 우리 개발팀이 개발을 해야하기 때문에 그들의 기준에 의해 산정되고, 그 산정된 기준이 일관성이 있다는 전제하에 '기획'을 통해 컨트롤 할 수 있다.
그런데 어려운 것은 두번째이다.
생각보다 1번은 경험이 쌓이면 짠밥이 생겨서, 하나의 기능을 위해 필요한 최소한의 기능들을 어느정도 예측할 수 있게 되는데, 그렇게 정의된 요구사항에도 불구하고 사람마다 다른 일정이 나오는 것은 '완성도'에 대한 차이일 수 있다.
누군가는 이후 100년 뒤에도 유지보수가 수월할 공통부분을 모듈화해나가면서, 큰 틀을 유지하려고 하고, 또 더 큰 차이는 '완료'의 정의가 '구현'의 끝이 아니라 '검수'의 끝이라고 완전히 테스트까지 끝난 상태라고 생각할 수도 있다. 물론 개발 테스트 범위라고 하더라도, 사람마다 코딩하고 한번 돌려보고 끝이라는 사람도 있고, 구현끝나고 두 세번은 버그를 수정한 버전이 끝이라고 생각하는 사람도 있다.
DOD : Definition of Done
이것은 정말 중요한 정의의다. 단순히 일정 산정뿐아니라, 전체적인 커뮤니케이션의 가장 큰 복병이다. 끝난 줄 알았는데, 끝난게 아니다. 그래서 오히려 일정이 오래 걸려도 '완전한 끝'을 합의하면 그것이 향훙에 훨~씬 효과적이다. 대부분의 지연요소는 일이 끝나지 않고 계속 끌리는 것들인데, 이것이 'Done'으로 티켓들이 그냥 '구현만' 된 것들이 많기 때문이다.
그래서, 너무 오버엔지니어링을 하는 듯 하면, 향후 리팩토링을 할 기회를 따로 마련하도록 하고
그럼에도 'Done'은 정말 명확히 'Done'으로 모든 멤버가 인지될 수 있도록 수없이 싱크를 맞춰야 한다.
그러면 어느정도 비슷한 수준의 일정 예측을 할 수 있을 것이다.
너무 오래 걸린다는 사람과 짧게 걸린다는 사람이 있다면 구체적으로 예측을 위해 이해한 범위와 완성도 수준을 물어보면 그 산정들이 어느정도 이해가 될 것이다.
우리는 점쟁이가 아니다.
어떤 숨어있는 일정을 (정답을) 맞추는 것이 아니라, 예측성을 높히기 위해 불확실 성을 계속 줄여나가는 일들이다.
아, 그냥 일정 따위 없는 세상에 살고싶다.
건강에 좋지 않다.
