개발 프로젝트가 산으로 가는 순간

실패하는 프로젝트의 공통점

여러 프로젝트를 진행하다 보면, 어려운 기술이 들어간 프로젝트보다 소통 구조가 무너진 프로젝트가 훨씬 위험하다는 것을 알게 됩니다. 아래 네 가지는 거의 항상 같이 나타납니다.

1. 결정권자가 여러 명이다

시안을 보내면 담당자가 확인하고, 팀장이 다르게 말하고, 대표님이 또 다른 방향을 제시합니다. 그 사이 작업은 두 번 세 번 뒤집힙니다.

해결책은 간단합니다. 최종 결정을 내리는 한 사람을 정하는 것입니다. 내부 의견은 그 사람이 모아서 한 번에 전달하면 됩니다. 이 하나만으로 일정이 눈에 띄게 안정됩니다.

2. 말로만 오간다

전화로 “여기 이렇게 해주세요” 하고 끝나면, 나중에 서로 다르게 기억합니다. 악의가 아니라 사람의 기억이 원래 그렇습니다.

통화가 끝나면 “오늘 말씀 주신 내용은 A·B·C입니다”라고 글로 정리해 확인받는 습관이 필요합니다. 5분이면 되고, 나중에 며칠을 아낍니다.

3. 간단한 수정의 기준이 없다

발주처 입장에서 “버튼 색만 바꿔주세요”는 간단한 일입니다. 개발 입장에서도 대개 간단합니다. 문제는 그런 요청이 스무 번 쌓였을 때입니다.

그래서 계약 단계에서 숫자로 정해두는 것이 서로에게 좋습니다. “시안 확정 후 수정 3회”, “오픈 후 1개월 내 콘텐츠 수정 무상”처럼 세는 단위가 있어야 합니다.

4. 변경의 대가가 보이지 않는다

중간에 기능을 추가하는 것 자체는 문제가 아닙니다. 문제는 그 추가가 일정과 비용에 얼마나 영향을 주는지 그 자리에서 공유되지 않는 것입니다.

“가능합니다”로만 답하면 나중에 일정이 밀렸을 때 이유를 설명할 수 없습니다. “가능합니다. 다만 일정 5일, 비용 OO만원이 추가됩니다”로 답해야 발주처도 판단할 수 있습니다.

가장 흔한 지연 요인

의외로 개발이 아닙니다. 자료 전달입니다. 로고 원본, 제품 사진, 회사 소개 문구, 임직원 사진. 이것들이 늦어져서 몇 주씩 멈추는 경우가 정말 많습니다.

그래서 착수할 때 필요한 자료 목록과 마감일을 먼저 확정하는 편이 좋습니다. 준비가 어렵다면 촬영이나 원고 작성을 포함해 진행하는 것도 방법입니다.

정리

좋은 결과물은 좋은 개발자에게서만 나오지 않습니다. 결정 구조가 명확하고, 기록이 남고, 변경의 대가가 투명한 프로젝트가 좋은 결과로 이어집니다. 이건 발주처와 개발사가 함께 만드는 조건입니다.