맞춤형 소프트웨어 의뢰서에는 무엇을 써야 할까요?

“예약 시스템을 개선해야 해요”라는 말은 자연스러운 출발점입니다. 다음에 물어볼 것은 누군가 예약을 시도할 때 실제로 어떤 일이 일어나는가입니다.

개발자와 처음 이야기하기 전에, 요청을 받는 순간부터 결과가 나올 때까지 업무 하나를 설명해 보세요. 까다로운 상황도 포함하세요. 소프트웨어를 어떻게 만들지 몰라도 일상적인 말로 설명할 수 있습니다.

실제로 하는 업무 하나부터 시작하기

가상의 교육 회사를 떠올려 보세요. 고객이 이메일로 한 강좌에 두 자리가 있는지 문의합니다. 담당자가 남은 자리를 확인하고 고객에게 답한 뒤 예약을 기록합니다. 강좌가 꽉 찼다면 무엇을 대신 제안할지 누군가 결정해야 합니다.

이 정도면 쓸모 있는 의뢰서를 시작할 수 있습니다. “대시보드가 있는 포털을 만들어 주세요”만으로는 누가 쓰는지, 무엇을 끝내려는지, 언제 예약이 성립하는지를 개발자가 추측해야 합니다.

영국 정부의서비스를 만들기 전에 문제를 이해하는 방법에 관한 안내는 사용자와 그들이 거치는 전체 과정, 제약을 살펴보라고 권합니다. 안내에 나온 정부의 개발 절차는 그 환경에 한정됩니다. 이 교육 회사에서는 고객이 강좌에 등록하려면 무엇이 필요한지부터 물으면 됩니다.

지금 하는 일과 바꾸고 싶은 일을 구분하기

그 일을 하는 사람에게 최근 사례 하나를 처음부터 설명해 달라고 하세요. 관찰한 사실을 먼저 적고, 그다음 무엇을 다르게 하고 싶은지 씁니다. 가상의 회사라면 다음처럼 정리할 수 있습니다.

첫 부분은 현재 업무를 설명하고, 두 번째는 변경안을 제안하면서 아직 결정하지 않은 점을 남겨 둡니다. 직원마다 일하는 방식이 다를 때 이 구분이 중요합니다. 답을 기다리는 동안 자리를 임시로 잡아 두는 사람도 있고, 계속 비워 두는 사람도 있습니다. 개발자에게 규칙으로 만들라고 하기 전에 두 방식을 모두 기록하세요.

시작과 끝, 까다로운 상황 알려 주기

강좌 문의라면 다음 내용을 메모로 정리할 수 있습니다.

• 시작: 특정 날짜의 강좌에 두 자리가 있는지 묻는 이메일이 온다.
• 사람: 강좌 담당자가 요청을 처리한다. 예약 규칙에 관한 판단은 교육 책임자가 한다.
• 정보: 강좌 날짜, 남은 자리, 요청한 자리 수, 고객의 답변. 현재는 이메일 받은편지함, 스프레드시트, 달력에 나뉘어 있다.
• 완료된 결과: 담당자가 합의된 예약을 기록하고, 남은 자리 수에 반영되며, 고객이 합의된 확인 안내를 받는다.
• 까다로운 상황: 고객은 두 자리를 원하지만 하나만 남았다. 다른 날짜를 제안하는 동안 문의를 미완료 상태로 유지할 방법이 필요하다.

이는 가상의 사례에 대한 메모 초안이지, 모든 교육 회사에 적용할 확정 규칙은 아닙니다. 여러분의 회사에서는 “합의된 예약”이 무엇을 뜻하는지 물어보세요. 자리를 제안했을 때, 고객이 수락했을 때, 아니면 결제했을 때 그 자리가 찬 것으로 볼까요? 질문을 적어 두면 함께 결정할 수 있습니다.

가상의 기록으로 짧은 사례도 만들어 보세요. 5월 12일의 강좌 A에는 한 자리만 남았고, 문의 B는 두 자리를 요청했습니다. 누가 결정하고 어떤 결과를 기대하는지 적으면 개발자가 구체적인 상황을 놓고 질문할 수 있습니다.

필수 조건, 아이디어, 미결정 사항 표시하기

필수 조건: 담당자가 아직 답하지 않은 문의를 볼 수 있어야 합니다. 그렇지 않으면 공유 받은편지함을 뒤져 끝나지 않은 업무를 찾아야 한다는 이유도 적습니다.

논의할 아이디어: 고객이 다른 강좌 날짜를 직접 고를 수도 있습니다. 어떤 업무가 필요하고 누구에게 도움이 되는지 살펴보기 전까지는 가능성으로 남겨 두세요.

열린 질문: 언제 자리를 예약해 두고 누가 그 예약을 풀 수 있나요? 개발자가 업무 규칙을 조용히 정하게 두지 말고, 교육 책임자가 결정할 사람임을 적으세요.

실제 제약도 포함하세요. 기존 달력을 계속 써야 할 수도 있고, 일부 직원만 고객 정보를 봐야 할 수도 있습니다. 특정 날짜 전까지 한 강좌를 지원해야 할 수도 있습니다. 어떤 제약이 확정됐고 왜 필요한지 설명하세요. 날짜나 예산이 아직 희망 사항이라면 그렇게 표시합니다.

쓸모 있는 결과인지 확인하는 방법

“사용하기 쉽게”라는 말에는 사례가 필요합니다. 이 회사라면 담당자가 문의부터 답변까지 진행 상황을 따라가고, 아직 답하지 않은 문의를 모두 찾을 수 있어야 합니다. 일반적인 예약과 한 자리만 남은 사례로 완성된 작업이 무엇을 보여 줘야 하는지 논의하세요.

지금 측정하고 싶은 문제도 기록할 수 있습니다. 예를 들어 직원들이 답하지 않은 문의를 찾으려고 여러 도구를 확인하는 빈도입니다. 무엇을 관찰했고 무엇을 더 확인해야 하는지 구분하세요. 비교 기준을 확인한 뒤 목표를 합의합니다.

개발자에게 보내기 전에 실제로 업무를 하는 사람들에게 의뢰서를 보여 주세요. 빠진 단계를 짚거나, 쉬워 보이는 지름길이 왜 문제인지 설명할 수 있습니다. 해결되지 않은 질문은 답할 사람을 지정해 문서에 남깁니다.

저희는맞춤형 업무 소프트웨어를 만듭니다. 프로젝트를 이야기하고 싶다면 지금 하는 일, 바꾸고 싶은 점, 구체적인 사례, 아직 남은 질문을 가져오세요. 그 업무를 바탕으로 범위와 상업 조건을 논의할 수 있습니다. 의뢰서는 대화의 시작이며, 기술 조사와 설계는 이후에도 필요합니다.

소프트웨어 의뢰서에 관한 질문