6주 동안 잘못된 제품을 만들었습니다
6주 동안 잘못된 것을 만들었습니다. 클라이언트는 한 번도 불평하지 않았습니다. 그것이 문제였습니다.
이것은 도구나 생산성 향상 팁에 관한 이야기가 아닙니다. 냉혹한 진실에 관한 이야기입니다.
한 의료 관련 클라이언트가 환자 예약 시스템을 요청했습니다. 우리는 질문을 던졌고, 고개를 끄덕였으며, 개발을 시작했습니다.
6주 차에 데모를 보여주었습니다. 클라이언트는 침묵했습니다.
그들은 말했습니다: "훌륭하네요. 하지만 간호사는 예약을 잡지 않습니다. 보험 코디네이터가 하죠. 그들의 워크플로우는 다릅니다."
아무도 거짓말을 하지 않았습니다. 의사소통에 오류가 있었던 것도 아닙니다. 우리는 그저 소프트웨어를 매일 사용할 사람이 누구인지 묻는 것을 놓쳤을 뿐입니다.
가장 비용이 많이 드는 코드는 잘못된 문제를 해결하는 코드입니다. 최악의 코드는 충돌(crash)이 발생하는 코드가 아닙니다. 완벽하게 작동하지만 아무것도 해결하지 못하는 코드입니다.
우리의 가장 큰 실수들은 다음과 같습니다:
- 사용자 페르소나 생략. 사용자가 아닌 의사 결정권자를 위해 만들었습니다.
- 승인을 정답으로 착각함. 클라이언트가 "예"라고 말한다고 해서 제품이 올바른 것은 아닙니다.
- 승인을 방어 수단으로 사용함. 존경하는 사람에게 보여주기 부끄러운 작업물이라면, 클라이언트의 승인을 방패로 삼지 마십시오.
- 배포를 결승선으로 취급함. 성공은 출시 이후에 일어납니다.
해결 방법:
의견이 다를 때는 명확하게 표현하십시오. 클라이언트에게 이렇게 말하세요: "요청하신 대로 이 기능을 만들겠습니다. 하지만 저희는 X가 Y를 초래할 것이라고 믿습니다. 이 내용을 서면으로 남겨두겠습니다."
이 한 문장이 나중에 책임 전가를 막아줍니다.
배포를 끝이라고 생각하지 마십시오. 에러 트래킹, 업타임 알림, 그리고 에러율과 지연 시간(latency)을 확인할 수 있는 통합 대시보드가 필요합니다. 또한 미래의 자신을 위한 문서화도 필요합니다.
여러분의 팀은 어떤 실수를 반복하고 있나요?