첫 출시 이후까지 생각하기
제품은 고객이 이해하고 개발자가 유지보수할 수 있어야 하며, 계획이 틀어졌을 때도 운영할 수 있어야 합니다. 설계 결정은 지원 방식에도 영향을 줍니다. 통합은 의존성을 만들고, 당장의 지름길이 반복적인 비용이 되기도 합니다. 직접 제품을 만들기에 이런 연결을 놓치지 않습니다.
운영 모델을 범위에 포함
유용한 개발·납품 계획은 화면과 기능 이상의 내용을 담습니다. 누가 무엇을 할 수 있는지, 어떤 시스템이 데이터를 공유하는지, 작업을 어떻게 검증하는지, 결과를 운영하는 데 무엇이 필요한지 설명해야 합니다. 첫 버전을 작게 시작하더라도 이런 질문은 처음부터 다뤄야 합니다.
작동하는 작은 단위로 학습
서로 연결되지 않은 여러 기능보다 범위가 명확하고 처음부터 끝까지 이어지는 워크플로가 더 유용할 때가 많습니다. 팀은 실제 상호작용으로 가정을 검증하고, 기반 데이터를 살펴보며, 다음 개발 단위를 이해할 수 있습니다. 목표는 단순히 수를 늘리는 것이 아니라 평가할 수 있는 진전을 만드는 것입니다.
실제로 활용할 수 있는 인계
분명한 문서, 명시적인 절충점, 이해하기 쉬운 코드는 다음 결정을 쉽게 합니다. 소프트웨어를 사용하는 사람과 이후 책임질 사람을 위해 만든다는 제품 소유자의 관점을 고객 업무에도 적용합니다.