첫 시도에서 개발자가 바로 짓는 소프트웨어 요청서 작성법

출처: Dev.to
게시됨: true
”헤이, 내 리드를 추적하는 앱을 만들어 줄 수 있어?” 처음에는 합리적으로 보이지만, 실제 구현해 보려니 이 문장이 약 50가지 결정을 전달하고 전혀 답변하지 않았다는 걸 알게 된다.
리드는 무엇인가? 어디서 오는가 — 웹 폼, 전화 통화, 문자? 각각에 대해 저장하고 싶은 필드는 무엇인가? 한 건이 들어오면 어떻게 되는가 — 이메일이 전송되나요, 데이터베이스에 기록되나요, 그냥 있는 것만인가? 사용자는 누구인가 — 오직 너 혼자인가, 아니면 팀 전체인가? 이는 모바일 앱, 웹 앱, 혹은 백그라운드 스크립트인가? “추적”은 당신에게 어떤 의미를 갖는가?
그 문장에는 포함되어 있지 않았다. 제작할 사람은 모든 공백을 자신 대신 채우고, 가장 쉬운 방법으로 채우며, 당신에게 옳은 것으로 채우지 않는다. 완성된 제품을 보고 ‘그게 내가 원한 게 아니다’라고 말하고, 그들은 ‘네가 요청한 거야’라고 답한다. 양쪽 모두 맞다. 이것이 전체 문제다.
사람들은 요청을 짧게 적은 것이 시간을 절약한다고 생각한다. 그 생각은 이렇습니다: 핵심을 전달하면, 그들은 세부 사항을 스스로 정리하고, 함께 진행하며 해결해 나갑니다.
실제로는 이런 일이 일어납니다. 세부 사항이 사라지지 않아요. 단지 나중에야 답변받게 되죠 — 개발자 입장에서, 구축 중간에, 예산의 절반 이상이 이미 쓰인 뒤 말이죠.
앞서 답변하지 않은 모든 질문은 추측이 됩니다. 그 추측이 틀리면 재구축이 필요합니다. 재구축은 어떤 소프트웨어 프로젝트에서도 가장 비싼 일인데, 코딩하고, 잘못된 점을 발견하고 다시 코딩해야 하기 때문입니다.
질문은无论如何 이루어집니다. 선택지는 작업 시작 전에 답변을 받을지(변경이 무료인 경우) 혹은 그 이후에 받을지(변경 비용이 발생하는 경우)입니다.
제가 보는 가장 큰 실수는 솔루션을 요청하는 것이 아니라 결과를 설명해야 하는 것입니다.
”대시보드에 캘린더 뷰를 넣어줘”는 솔루션이다. 이미 앱이 대시보드와 캘린더가 필요하다고 가정했으며, 그 중 어느 쪽도 맞지 않을 수 있다. 이제 개발자는 실제 문제를 해결하기보다 네 추측에 고정되어 있다.
진짜로 원하는 것은 “일을 겹치게 예약하게 되는 건, 한눈에 가득 찬 날이 어떤 날인지 알 수 없어서다.” 이 말은 유용하다. 개발자는 캘린더가 정답인지, 아니면 간단한 가용성 확인만으로 충분한지 알려줄 수 있다. 당신은 그들에게 그렇게 하라고 고용했다. 맡겨라.
좋은 규칙은 소프트웨어가 완성되었을 때 어떤 것이 참이어야 하는지 설명하는 것이 아니라 화면이 어떻게 보여야 하는지에 대해 설명하는 것이 아니다.
”리드가 들어오면 앱이 1분 이내에 나를 텍스트로 보내니 무엇을 확인할 필요 없이 끝난다.” 이 한 문장은 버튼과 레이아웃에 대한 세 장의 단락보다 개발자에게 더 많은 정보를 전달한다.
사용자는 누구인가. 오직 너 혼자인가? 팀인가? 고객이냐? 모바일 폰이나 데스크톱 브라우저에서 사용하는가? 소프트웨어에 익숙한 사람인가, 아니면 아주 간단하게 사용해야 하는 사람인가?
그들이 달성하고자 하는 것. 실제 목표를 평이한 말로 표현한다. 기능 자체보다는 그 기능이 수행해야 할 일이다.
단계별로 일어나는 일. 개발자에게 스토리처럼 흐름을 보여준다. “고객이 웹 폼을 제출한다. 그다음 데이터가 시트에 기록된다. 그리고 텍스트가 나와 나에게 전송되고, 가장 가까운 운전자 쪽으로도 전달된다.”
입력과 출력. 어떤 데이터가 들어가고, 어떤 것이 나오는가? 이름, 전화번호, 주소가 들어가면 — 정렬된 목록이 되고, SMS 알림이 나온다. 데이터를 구체적으로 명시하라.
엣지 케이스. 두 건이 동시에 들어오면 어떻게 되는가? 필수 항목이 비어 있다면? 같은 리드가 두 번 제출되면? 이들을 해결할 필요는 없지만, 지금 이름을 지정하면 나중에 버그로 나타나는 것을 방지할 수 있다.
“완료”가 어떤 모습인지이다. 사람들은 이를 건너뛰고 전체 요청에서 가장 중요한 문장이다. 어떻게 확인할 수 있을까?
”완료는 내가 휴대폰에서 테스트 리드를 제출하고 1분 이내에 내 폰에 텍스트가 뜨면 된다.” 이것이 수용 테스트이다 — 이제 소프트웨어가 완성되었는지 논의할 여지가 없다.
”이것은 제외다.” 중요성은 무엇인지와 같다. “결제 처리가 필요 없다. 사용자 계정이나 로그인도 필요 없다. 단순히 리드를 캡처하고 알림을 전송한다.”
나쁜: ‘리드 관리를 위한 앱을 만들어줘.‘
좋은: ‘나는 한 명만 운영하는 조경 사업한다. 리드는 두 가지 방식으로 들어온다 — 웹사이트 폼과 적어 놓은 전화 통화이다. 지금은 종이 조각에 적혀 있어 뒤따라오지 못해 버린다. 단순한 웹 앱을 원해, 오직 내 휴대폰에서만 사용하고, 내가 아직 호출하지 않은 사람에게 리드를 정렬된 한 목록에 넣는다. 3일 후에 follow-up 알림을 받도록 한다. Done는 30초 이내에 리드를 추가할 수 있고, 하나도 잃지 않는다는 의미다. 청구서 작성이나 고객 로그인은 필요 없으며 — 단순히 캡처하고 follow-up만 하면 된다.‘
같은 프로젝트다. 후자의 경우 개발자가 처음부터 올바른 방향으로 가는지 확인하기 어렵고, 세 번의 “아니”와 그에 상응하는 비용을 초래한다.
두 번째 유형의 요청을 받는 사람은 정확하게 인용하고 한 번에 구현하여 12번 반복 없이 배포할 수 있다. 첫 번째 유형의 요청을 받는 경우, 먼저 그들이 답변하지 않은 모든 질문을 던진다. 왜냐하면 한 시간 안에 명확한 사양을 작성하는 것이, 잘못된 앱을 3주간 코딩하는 것보다 낫기 때문이다.
이것이 바로 내가 928 Builds에서 고정 견적을 제공하는 이유다. 고정 견적은 양쪽이 실제로 무엇을 구축할지 정확히 알 때만 작동한다. 이는 당신에게 예측 불확실성을, 나를 위해-blindly 구축하는 위험을 방지한다. 명확한 요청은 전체 프로젝트의 가장 저렴한 보험이다.
코딩 방법을 알 필요는 없다. 단순히 실행될 때 어떤 것이 참이어야 하는지 명확히 말하면 된다.
한 시간을 투자해 적어내라. 그것은 구축 시간의 주를 되돌려준다.
조엘 벤넷 · 928 빌드스 설립자 · 툰소노, 아리조나 · 928builds.com