이 세션의 내용은 '공동계좌'를 출시하기까지의 과정이다.
https://s3-us-west-2.amazonaws.com/secure.notion-static.com/553bca71-0f2c-4b68-9634-84b06439384f/untitled
https://s3-us-west-2.amazonaws.com/secure.notion-static.com/41bb6a85-a733-4daa-a85a-6b048f205d22/untitled
시작은 회비 걷기 너무 힘들다는 문제 정의다. 총무는 독촉도 해야 되고 누가 돈을 안보냈는 지 확인도 해야 되고 모임 구성원은 회비가 잘 모이고 있는지 알 길이 없고 등등...
첫 주는 사일로의 각 직군이 해결안에 대해 아무말 대잔치를 하며 아이데이션을 한다. 그러다 보면 대충의 스펙이 나온다.
https://s3-us-west-2.amazonaws.com/secure.notion-static.com/d644eed4-d4dd-4d43-860c-2a21bde60f1c/untitled
https://s3-us-west-2.amazonaws.com/secure.notion-static.com/fce56a1c-47e3-4233-b90a-f37070eb5021/untitled
그러나 이 스펙을 모두 대응할 수는 없다. Minimum Feature, 기능은 가치가 아니라 비용이다, 있어서 좋은 기능을 만드는 것이 아니라 없으면 안되는 것 하나만 만든다는 이론 아래서 처음 정해진 스펙의 80%를 불살라버리고 20%만 남겼다. 개발스펙의 기준이 "있으면 좋은 기능"이 되어 버리면 관리되지 못할 기능은 결국 쓰레기통에 버려질 것이고 필요 없는 기능만 덕지덕지 붙기 때문이다. 이렇게 스펙을 쳐내고, 공동계좌라는 제품을 만들기로 했다.
디자인은 TDS 덕에 이틀밖에 걸리지 않았고, 오히려 기존 정책에 대한 고민이 있었다. 송금 10회 제한이라는 정책이 있는데 공동계좌가 생겨버리면 그 계좌를 이용해 무한 송금을 할 수 있기 때문에 매출에 영향을 주지 않을까? 이 고민을 PO와 상의했고 일어나지 않은 일에 대한 걱정은 말고 일단 해보자는 결론을 얻었다.
이틀만에 한 디자인
이틀만에 한 디자인2