기능 명세서의 중요성

저번 아티클에서 우리팀이 와이어프레임을 만드는 데 어려움을 겪고 있다고 말한 바 있다. 그 원인을 분석해보니, 크게는 'MVP에 대한 잘못된 이해', 작게는 '기능명세서의 누락'으로 좁힐 수 있었다.

1. MVP에 대한 잘못된 이해

분명 MVP(Minimum Viable Product)에 대해 이해하고 있다고 생각했으나, 실질적으로 우리가 개발하는 과정은 전혀 mvp를 만드는 과정이 아니었다.

우리의 목표는 '공무원 분들이 보셨을 때 wow할 수 있는 product를 만드는 것'이었다. 미팅을 여러 번 잡을 수 없다보니, 첫 미팅에 신뢰를 확보해야겠다는 생각을 했다. 그 전에 공무원 분들과 미팅을 했을 때 반응이 시큰둥하신 분들도 계셨는데, 제대로 된 프로토타입이 없는 상태에서 뵈러 갔기 때문이라는 결론을 내렸었다. 그래서 더더욱 서비스의 퀄리티를 벌써부터 고려하지 않을 수 없었다. 이게 첫 번째로 빠진 함정인 것 같다.

너무 많은 기능을 초반부터 넣으려고 하다보니, (물론 그것도 줄이고 줄인 핵심적인 기능 위주였지만) 머릿속이 복잡해졌고 와이어프레임을 만들 때 수정사항이 계속해서 생겨났다.

이 유명한 사진을 왜 계속 잊게 되는걸까...

1. 기능명세서의 누락

우린 맨땅에 헤딩하듯 제대로 된 레퍼런스 조사도 없이 유저플로우+와이어프레임부터 만들기 시작했다. 그러다보니 의견이 발산형으로 계속 나왔고, 수렴되는 데에 시간이 매우 오래 걸렸다. 와이어프레임을 만들다가 누락된 기능이 계속 발견되었다. 이런 문제점에 대해 y-startup week4 세션 때 멘토님께 공유해드렸더니, 기능명세서를 누락한 것에 대해 지적해주셨다. 정말 한 발 앞선 창업가 분들이 핵심적이고 결정적인 부분을 짚어주실 수 있다는 것을 다시금 느낄 수 있었던 부분이었다.

그래서 기능명세서를 만들었다. 보통 notion이나 구글 스프레드 시트를 사용한다고 한다.

기능명세서에 더해, 요즘 뼈저리게 느끼고 있는 것 중 하나는

내가 겪은 모든 시행착오는 이미 대부분의 사람들이 겪었을 시행착오라는 것이다.

그렇기 때문에 빠르게 lean하게 무언가 시작하고 달성하려면,

과거 사례들을 많이, 다양하게 찾아보는 것이 무조건 선행되어야 한다는 점...

물론 그걸 또 적용하고 실행하는 것은 나의 몫이지만

와이어프레임 만들 때도 레퍼런스 찾아볼 생각은 안하고

제로베이스에서부터 하나하나 만들려고 했는데, 다소 무지하지 않았나 싶다.

여전히 부족하고 더디지만.. 한 주 한 주 더 나아가고 있다고 느낀다.

어서 종강하고 제품 개발과 유저 인터뷰에만 신경쓸 수 있으면 좋겠다.