제3화.아들아, 베이스라인 없는 개발은 지도없이 정글을 걷는 것과 같단
아들아, 정글에서 맹수보다 무서운 건 내가 지금 어디에 있는지 모르는 상태로 걷는 거야. IT 프로젝트에서도 마찬가지란다. 분석과 설계가 끝났다면 "우리는 여기까지 이렇게 만들기로 했습니다"라고 고객과 도장을 찍는 '베이스라인 설정' 과정이 반드시 필요하단다. 기준 없이 시작된 개발은 나중에 분명히 재앙이 되는 경우가 많아.
고객이 바쁘다는 핑계로 요구사항 확정 서류에 도장을 안 찍어주는 경우가 허다할 거야. 그렇다고 마냥 기다리면 결국 개발 기간만 줄어들지. 실제로는 확정을 해줬다고 해도 나중에 마음을 바꿀 수도 있는 게 현장이란다.
도장은 없어도 우리가 무엇을 기준으로 가고 있는지 명확히 해야 해.
아빠의 노하우: 아빠는 서류상의 도장보다 '공식적인 기록'을 먼저 만들었어. "오늘까지 협의된 [요구사항 정의서 v1.0]을 기준으로 개발에 착수합니다. 이후 변경 사항은 일정에 영향을 줄 수 있습니다"라고 메일을 보내는 거야. 이 기록이 나중에 너를 지켜줄 지도가 된단다.
많은 사람이 베이스라인을 정하면 수정이 절대 안 된다고 생각해서 겁을 내지. 하지만 베이스라인은 '변경의 기준점'을 만드는 거야. 기준이 있어야 나중에 추가 요구가 올 때 일정 협의를 할 근거가 생긴단다.
현실적으로 물리적인 시간이 허락되지 않을 때가 많으니, 항상 대안을 고민해야 한단다.
아빠의 노하우: 고객에게 "수정 안 됩니다"라고 겁주지 말고, "이 기준이 있어야 오픈 날짜를 지킬 수 있습니다"라고 설득하렴. 베이스라인은 고객을 공격하는 무기가 아니라, 배가 산으로 가지 않게 잡아주는 닻이란다.
요구사항 정의서에 "편리하게 구현", "시스템 최적화" 같은 모호한 말이 있다면 당장 지워야 해. 고객이 나중에 "나는 이게 안 편리한데?"라고 우기면 대처할 방법이 없거든.
개발 문서는 고객과 개발자 사이의 '번역기' 역할을 해야 하기에 가급적 구체적이어야 한단다.
아빠의 노하우: 수치와 동작으로 정의해야 해. "3초 이내 응답", "5,000건 처리"처럼 누가 봐도 명확한 기준을 세우렴. 지도가 정교할수록 너와 개발자들의 발걸음은 가벼워지는 법이야.
계속 승인이 지연된다면 어느 시점에는 아빠가 직접 선을 그어야 했어. 현실적으로 고객에게 강하게 이야기하긴 힘들지만, 돌려서라도 분명하게 기한을 제시해야 한단다.
선을 긋지 않으면 결국 프로젝트 전체가 정글의 늪에 빠지게 돼.
아빠의 노하우: 착한 PM이 되려고 하지 마라. "금주 금요일까지 이견이 없으시면 본 안으로 확정하고 다음 단계로 넘어갑니다"라고 기한을 정해주렴. 때로는 독하게 선을 그어야 프로젝트 전체가 산단다.
한 마디
"베이스라인은 수행사와 고객이 맺는 '신뢰의 경계선'이야. 이 선이 불분명할 때 발생하는 모든 고통은 결국 개발자의 밤샘으로 돌아 오는 경우가 허다하단다. 선을 긋는 것을 두려워하지 마. 이 부분은 고객과 수행사간의 계약에 대한 명확한 선일 될꺼야. 그것이 진짜 책임감이라고 생각해."
요구사항 정의서에 도장을 찍기 전, PM은 다음 5가지 질문에 자신 있게 "네"라고 답할 수 있어야 한다.
[명사화/수치화] "다양한", "성능 개선" 같은 형용사 대신 "8종(구체적으로)", "응답속도 1초 이내" 같은 명사와 숫자로 기록했는가?
[현실성] 고객이 요구한 기능이 현재 확보된 인프라와 개발 기간 내에 물리적으로 가능한 수준인가?
[변경 프로세스 공유] 베이스라인 이후에 발생하는 변경 건은 '별도의 일정과 비용 협의'가 필요하다는 사실을 고객에게 인지시켰는가?
[데이터 정합성] 화면 뒤에서 흐르는 데이터의 출처와 저장 위치가 정의되었는가? (데이터가 정의되지 않은 화면은 신기루일 뿐이다.)
[예외 처리 기준] 정상적인 흐름 외에 '에러 상황'에 대한 처리 방식도 기준에 포함되었는가?