PO가 없으면 안 되는 이유...

개발TF 투입!

지난 일주일간 플랜바이는 초간단 MVP를 개발하는 데 집중했습니다.

저는 개발 업무에 투입되지는 않았고, 대략의 기획 이후 피그마로 프로토타이핑을 마친 뒤 AI 개발자 한 명(CTO)과 CTO님과 이전부터 알고 지내시던 풀스택 개발자 한 명으로 구성된 개발TF에게 업무를 맡겼습니다.

프로토타입 - 많아보이지만 실제로는 한 페이지입니다.

언제나 자신 있고, 그만큼 빠른 성과를 가져오는 개발TF이기에 간단한 기획만으로 충분히 알아서 프로덕트까지 만들 수 있겠거니 팀원 모두가 생각하고 있었습니다.

그러지 말았어야 함을 깨달은 것은 그로부터 이틀이 지났을 때였습니다…

알아서 개발할 수 있겠지?

이틀 뒤, 개발을 맡겨두고 다른 업무에 집중하고 있는 동안 풀스택 개발자님께서 찾아오셔서 개발 상황에 차질이 빚어졌다는 이야기를 꺼내셨습니다.

프론트엔드 개발을 위해선 피그마에 올라와 있는 프로토타입을 참고해야 하는데, CTO님이 개발해놓은 AI 모델과 제가 만든 프로토타입이 서로 합의가 되어 있지 않은 상황이었습니다.

하나의 예를 들자면, 프로토타입은 AI 모델의 출력물로서 사진 한장을 받아오도록 제작되어 있는데, 개발된 모델은 사진 세장을 출력하도록 되어 있었습니다.

화면에 이미지를 띄울 때 한 장과 두 장 이상은 큰 UI의 차이를 불러오기에, 여태까지 제 프로토타입을 바탕으로 개발하시던 개발자분 입장에서는 상당히 당혹스러우셨을 것입니다.

저도 처음에는 무척 당황했으나, 이내 마음을 가다듬고 객관적으로 상황을 분석하여 어디부터 문제가 생겼는지 반추하기 시작했습니다.

간단한 컨셉, 그러나 간단하지 않은 세부 기획

결론부터 말하자면, 기획 단계에서 많은 부분에 대한 합의가 부족한 것이 문제였습니다.

어느덧 세번째 올리는 초간단 기획

아무리 된다 치고 라지만, 세부적인 부분에서 계획되지 않은 것이 많이 보이기 시작했습니다.

몇 개만 정리하자면,

1. AI 모델 인풋과 아웃풋의 구체적인 수치

2. 최종결과물의 연출

3. 로그인, 회원가입 등 auth 시스템

4. 데이터 수집 방법

등 이외에도 많은 부분에서 합의되지 않은 내용이 나타났습니다.

이후 액션

“개발된 MVP를 활용하여 유료 고객을 유치할 수 있을 것”이라는 금주 스프린트의 검증 대상 가설은 거짓으로 드러났습니다.

사유를 정리하여 한줄 회고록에 기록해놓았고, 오랜만에 겪은 개발 단계에서 좌절인 만큼 금요일에는 전사 싱크업을 위한 1on1을 진행했습니다.

각자 이번 스프린트에서 어떤 실수나 실책이 있었는지 솔직하게 이야기하였고, 추후에는 개발 투입 이전에 훨씬 더 깊은 레벨의 기획 합의가 필요함에 모두가 동의하였습니다.

또한 앞으로는 MVP를 포함한 프로덕트 개발에 있어 언제나 PO를 지명하여 책임이 분산되는 일이 없도록 하기로 하였습니다.

다소 경황이 없는 한 주의 마무리였지만, 그만큼 팀원 모두가 많은 것을 배우고 개선할 수 있었다고 생각합니다!

좋은 경험과 안 좋은 경험 모두에서 인사이트를 얻어내는 능력이 있는 우리 팀이기에, 앞으로 더 잘 해나갈 수 있다고 믿습니다😊