제품 원칙, 어디에 쓰나요?
제품 원칙의 힘(2)
이전글이 있습니다. 제품 원칙, 어떻게 만드나요?
이전 글을 짧게 요약하자면, 처음으로 조인한 팀에서 "문제 없는 제품"을 만들기 위한 원칙을 정의하고 합의했다. 해당 내용은 아래와 같고, 우리는 이 원칙을 피곤한 늦은 새벽이라도 지키기로 약속했다.
우리가 정의하고 합의한 문제 없는 제품이란?
- 의도한 기획과 디자인처럼 모두 적용되어있다.
- 기획/디자인에서 정의되지 않았던 내용 중에 기능적으로 이슈가 있는 것은 해결한다.
- 정의된것처럼 반영이 되어있으나 심각한 사용성이 있는 경우는 보완한다.
예정되어있던 QA 당일, 오전 10시 게더타운에 모여 다같이 QA를 시작했다. 테스트하고 결과를 다 같이 싱크하고 반영할지, 반영하지 말지를 결정하고 다음 QA할 시간을 정하고, 다시 모여 테스트하는 것을 반복했다. 3-4번 쯤 QA를 하고 어느새 시간은 저녁 7시에 되었지만, 아직 반영되지 못한 티켓들과 거기에 새롭게 발견된 티켓들 덕분에 티켓 리스트는 길이는 줄어들지 않고 있었다.
티켓 쌓이는 속도 > 티켓 해결하는 속도밤 10시, 다음 새벽 1시, 그 다음 새벽 3시. 3번의 QA를 더하고 나서야 대부분의 티켓을 반영이 되었다. 아침부터 시작해서 7차례 정도의 QA를 진행했으니, 다들 피로도가 꽤나 올라온 상황이었다. 남은 티켓들을 기능과 상관없는 디자인 이슈였다.
그렇다. 마치 예언처럼 제품 원칙 논의 뒤로 맞이한 첫번째 QA, 새벽 3시 실제로 그런일이 일어난 것이다.
이전 QA 시간때 "반드시 반영해야만 한다"라는 분위기에서 "이걸 꼭 지금 반영해야할까?"하는 느낌으로 미묘하게 공기가 바뀌는게 느껴졌다.
"흠..." 피곤한 목소리의 한 개발자가 이걸 꼭 반영해야하냐고 조심스럽게 질문을 던졌다.
새벽 3시, 내가 낼 수 있는 가장 밝은 목소리로 빠르게 대답 했다.
“넵! 우리가 정한 제품 원칙에 따라 반영하기로 했잖아요.”
“…!"
우리가 합의한 원칙과 그 실행의 무게감을 모두가 절실하게 체험한 순간이었다.
"그럼 빨리 한번더 고치고 QA하고 마무리 하시죠!”
질문을 했던 개발자는 답에서 '어쩔 수 없네'라는 뉘앙스가 아니라 원칙을 지켜야 겠다는 약간의 비장함도 느껴졌다.
역시, 그것이 약속이니까-한시간 쯤 뒤, 마지막 QA. 모든 티켓 리스트를 해결하고 아침에 더 가까운 새벽시간에 모든 이슈를 클로징 하고 sign-off를 했다. 몸은 피곤했지만 결국 해냈다라는 기분 좋은 성취감과 함께 속 편하게 잠들 수 있었다.
새벽 4시와 5시 사이 어디쯤, QA sign-off를 축하하는 세레모니릴리즈를 뒤에 이어진 회고에서는 아래의 의견들이 주를 이루었다.
티켓 반영 여부를 원칙에 맞춰서 추가 논의 없이 빠르게 의사 결정 할 수 있었다.
불안하지 않은 제품을 릴리즈 할 수 있었다는 것에 대한 만족감이 들었다.
진정 한팀으로 일한것 같은 생각이 든다.
새벽까지 일해서 피곤하지만 목표를 이루었다는 성취감이 더 크다.
원칙이 없었다면, 각 티켓별로 해야하는지 말아야하는지 지리한 논의가 필요했을 것이다. 비단 새벽 3시의 QA시간 뿐만 아니라 이전의 QA 시간에 티켓 반영 유무를 결정할때 합의한 원칙 기준으로 빠르게 의사 결정 할 수 있었다.
누군가는 새벽에 기능적으로 이슈 없는 버그를 대응 하느라 리소스를 비효율적으로 사용한 것은 아니냐고 반문할 수 있다. 맞는 이야기다. 기준이 없었으므로 기준을 처음 만들었으니 지켜야 한다. 지켜야 무엇이 문제인지 알 수 있다. 그리고 성과결과와 회고를 통해서 해당 기준을 계속 가다듬어 나가야 한다. 원칙을 만들었다고 원칙 자체가 불변한 것은 아니다.
또 누군가는 기준을 만드는 것 자체가 시간 낭비가 아닌가 할 수도 있다. 기준을 만들어내는 시간 보다 필요할때마다 논의해야하는 커뮤니케이션 코스트가 훨씬 효율적이면, 기준을 억지로 만들어낼 필요는 없다. 각 조직의 상태와 상황에 따라 선택을 하면 된다.
우리팀의 경우 제품 원칙에 논의한 내용은 약 2시간 정도였지만, 이후 제품을 만들어가는 동안 2시간과는 비교도 할 수 없을 정도의 커뮤니케이션 코스트를 절약했고, 불필요한 갈등을 피했고, 원칙을 지켜냈다는 만족감과 그것으로 중심으로 원팀을 만드는데 큰 도움이 되었다.
완전히 다른 배경의 사람들이 모여서 무주공산에서 제품을 만든다면 다같이 한발짝 나아가기 위해서라도 최소한의 원칙은 필요하다.
최소한 누가 어느쪽 발부터 나갈지 정해야 한발짝이라도 움직일 수 있다.만약, 동료들과 일을 하다가 매번 비슷한 이슈들에 대해서 논의를 하는데 들어가는 시간이 아깝다는 생각이 들거나, 분명 이야기를 했는데 나중에 다른 소리를 한다고 느낀다면 디테일한 질문들을 통해서 간단한 원칙들을 정해보는 것을 추천한다.
제품 원칙에 대해서 고민하고, 작은 원칙을 통해 얻은 경험을 정리하다보니 제품 원칙 자체에 대해서도 한번 정리가 필요할 것 같다는 생각이 들었다. 다음 "그래서 제품원칙은 무엇인가?"에 대한 글도 관심 부탁드려요!
