고객은 고객이 원하는 걸 모른다

가장 중요한 단계, 요구사항 정의

한 일주일 동안 오랜만의 휴식을 취하고, 새로운 사무실로 출근하게 되었다.  

노무법인은 정말 생소한 영역이라, 알고 있는 정보가 전무했고, 막연하게는 전문직역 중에서도 뭔가 더 올드하다는 선입견이 있었던 것 같았다.

그러나 첫 출근일날부터 굉장히 신선한 충격을 받았다.

내부 공간도 칸막이가 없는 오픈 스페이스였고, 인테리어 역시 웬만한 IT 스타트업 분위기까지 날 정도로 밝고 시원시원했다.

그렇게 산뜻한 첫인상을 가지고, 제일 먼저 한 일은 진짜 하고자 하는 게 뭔지, 해결하고자 하는 문제가 무엇인지, 요구사항을 다시 분석하고 정의하는 것이었다.

물론 첫 합류 제안을 받았을 때도 외주업체에 견적요청을 위해 전달했던 문서를 대략 확인은 했었다.

그러나, 하루정도 실무 전반에 대한 맥락을 이해하고 살펴보니 불필요하거나 중복되는 작업이 포함되어 있었고, 이 전에 정리된 문서는 요구사항이라고 하기보다 현재 하고 있는 업무를 그대로 기술하고, 그걸 매크로  식으로 자동화 내지 단순화하는 수준이었다.

전반적인 작업의 목표와 구현 기능, 일정 등의 변경이 불가피한 상황이었다.

전체 회의를 통해, 모든 요구사항이 다시 정의되고 프로젝트 매니징 문서를 별도로 만들어 실시간으로 전 구성원이 진행과 작업 내용을 공유할 수 있도록 하였다.

결과적으로는, 비교적 빠른 시간 내, 프로젝트 방향을 재조정하고 불필요한 리소스 낭비를 막게 되긴 했지만, 원래 계획대로 이대로 외주를 맡겼다면 불 보듯 뻔한 상황이 벌어졌으리란 생각이 들었다.

사실 나도 창업했던 초기에 외주를 통해 크고 작은 개발업무를 해 본 적이 있었지만, 다시 한번, 결코 외주와 같은 형태로는 서비스다운 서비스는 나올 수 없는 근본적이고 구조적인 문제가 있음을 느꼈다.

왜냐하면, 외주 개발자는 의뢰자가 시키는 부분만 최소의 리소스를 투입해서 잔금만 입금되도록 하는 게 목표인 고객의 니즈와 상충되는 이해관계를 가지고 있을 수밖에 없기 때문이다.(사람의 문제라기보다 구조적인 문제)

나아가, 요구사항 명세는 결코 고객이 혼자 만들어 낼 수 없다.   고객은 단지 ‘뭘 하고 싶어요’에 대한 최종 결과나 효과에 대한 의견을 말할 수 있을 뿐 수단과 방법에 대한 정보와 지식이 부족하기 때문이다.

따라서, 제대로 된 개발 프로젝트는 요구사항 명세를 고객과 개발자가 함께 묻고 답하며 충분한 시간과 비용을 들여 만드는 것부터 출발해야 한다.

어쨌든 방향은 제대로 잡았으니, 전반적인 세팅 작업부터 들어갈 예정이다.