업무용 소프트웨어의 첫 버전에는 무엇이 필요할까요?

첫 버전에서는 누군가 끝까지 마칠 수 있는 업무 하나를 고르세요. 정보가 틀렸거나 동료가 없거나 시스템에 문제가 생겼을 때도 그 일을 끝내는 데 필요한 조건을 포함하세요.

월요일 아침을 떠올려 보세요. 직원이 소프트웨어를 열고 필요한 업무를 마친 다음, 다음 사람이 믿고 사용할 수 있는 결과를 남깁니다.

업무의 시작과 끝을 정하세요

가상의 유지보수 회사가 작업 지시 시스템을 만든다고 가정해 보겠습니다. 첫 사용자는 사무실의 조정 담당자와 한 유지보수 팀입니다. 담당자가 작업을 등록하고 배정하면 팀이 수행한 내용을 기록합니다. 담당자는 결과를 확인하고 작업을 완료 처리합니다.

이 정도면 쓸모 있는 첫 버전이 될 수 있습니다. '작업 지시 화면'이라는 말만으로는 충분하지 않습니다. 팀이 배정 내용을 볼 수 있나요? 잘못된 내용을 수정할 수 있나요? 작업을 완료 처리한다는 것은 무엇을 뜻하나요?

화면 수를 정하기 전에 사용자가 누구이고 어떤 결과가 필요한지 정하세요. 하나의 완결된 업무 흐름에도 여러 화면과 역할이 필요할 수 있습니다. 화면 수만으로는 실제 업무에 쓸 수 있는지 알 수 없습니다.

영국 정부의 베타 단계 안내는 사용자의 필요를 충족하는 서비스를 만들고 시험하는 과정을 설명합니다. 전체 이용 과정과 서비스를 지원하는 사람도 다룹니다. 정부의 개발 절차에는 자체 요건이 있습니다. 이 유지보수 회사에 중요한 질문은 선택한 사용자들이 작업 하나를 끝까지 처리할 수 있는지입니다.

까다로운 상황도 범위에 넣으세요

이 가상 사례에서 담당자가 작업을 잘못된 팀에 배정했습니다. 팀은 출발하기 전에 알아챘습니다. 누군가 배정을 바로잡아야 하고, 두 팀 모두 현재 유효한 내용을 볼 수 있어야 합니다. 수정을 나중으로 미루면 지원하기로 한 업무에 빈틈이 생깁니다.

실제로 일하는 사람들과 제안된 업무 흐름을 차례로 살펴보세요. 누가 작업을 생성, 변경, 배정, 완료할 수 있고 누가 정보를 볼 수 있는지 확인하세요. 건물에 들어갈 수 없거나 부품을 주문해야 하는 등 작업을 마칠 수 없는 경우도 결정해야 합니다. 다음 상태를 합의하고 담당자를 지정하세요.

두 번째 항목은 회사의 실제 업무에 따라 달라집니다. 청구서를 발행해야 작업이 완료된 것으로 볼 수 있다면, 첫 버전에서 그 방법을 정해야 합니다. 기존 청구 절차로 넘기는 합의된 인계만으로 충분할 수도 있습니다. 이 단계를 조용히 빼면 직원들이 일을 하다 빈틈을 발견하게 됩니다.

업무를 계속하는 데 필요한 조건을 포함하세요

팀에는 실제 작업 정보가 필요합니다. 어떤 기존 기록을 가져와야 하는지, 누가 확인할지, 오류를 어떻게 처리할지 정하세요. 가져오기 기능에 눈에 띄는 화면이 없어도 필요성이 사라지는 것은 아닙니다.

누가 계정을 만들고 삭제하며, 직원의 질문에 답하고, 장애를 조사하며, 서비스를 관리할지 합의하세요. 첫 사용자에게 필요한 도움과 안내도 포함하세요. 서비스를 사용할 수 없을 때 어떻게 할지와 관련 정보를 어떻게 복구할지도 확인하세요.

Google의 운영 책임 이관에 관한 글은 준비 상태 점검, 문서, 교육을 다룹니다. 이는 Google의 환경을 설명한 것이며 소기업에 특정 팀 구성을 요구하는 것은 아닙니다. 여기서 중요한 점은 첫 버전을 운영하고 지원할 사람을 정하고 필요한 것을 갖추게 하는 일입니다.

출시를 결정하기 전에 불확실한 부분을 시험하세요

시제품으로 조정 담당자가 배정 화면을 이해하는지, 팀이 휴대전화로 방문 내용을 기록할 수 있는지 확인할 수 있습니다. 무엇을 입증하는지 분명히 밝히세요. 완성품처럼 보이는 시연도 가상 기록을 쓰고 권한, 저장, 복구를 생략했을 수 있습니다.

운영 환경에서 사용할 수 있도록 승인하기 전에 실제 버전에 필요한 검증 근거를 합의하세요. 이 사례에서는 별도의 시험 환경에서 예정된 역할로 정상 작업과 잘못 배정된 작업을 각각 시도해야 합니다. 팀이 볼 권한이 없는 작업을 볼 수 없는지, 수정 내용이 올바른 사람에게 전달되는지, 미완료 작업이 계속 보이는지 확인하세요.

가져온 기록, 동시 변경, 장애 복구, 처리해야 할 작업량 등 시스템의 위험에 맞춰 추가 점검을 선택하세요. 한 번 성공적으로 진행했다고 모든 질문이 해결되지는 않습니다. 해결되지 않은 위험에는 담당자를 지정하고, 직원이 서비스에 의존하기 전에 무엇을 해결할지 결정하세요.

승인할 첫 버전의 범위를 적으세요

이 유지보수 회사의 버전 범위는 다음처럼 쓸 수 있습니다.

• 사용자: 조정 담당자와 지정된 유지보수 팀 하나.
• 업무: 작업 등록부터 합의한 완료까지, 또는 아직 미완료인 이유를 명시적으로 기록할 때까지.
• 필수 지원: 역할별 접근 권한, 수정, 필요한 초기 기록, 직원 도움, 운영 및 복구 절차.
• 승인 근거: 합의한 정상 상황과 까다로운 상황, 확인된 위험을 다루는 점검.
• 미결정 사항: 영향을 받는 업무를 승인하기 전에 답할 담당자를 지정.
• 이후 추가: 고객 셀프서비스, 경로 계획, 자동 청구. 기존 절차로의 인계를 합의하는 조건입니다.

직원, 업무 절차 책임자, 소프트웨어를 만들고 운영할 사람들과 이 범위를 검토하세요. 모두가 이번 버전에서 무엇을 처리하고 나머지 일은 어디로 가는지 설명할 수 있어야 합니다.

저희는 맞춤형 업무 소프트웨어를 만듭니다. 첫 버전을 논의하고 싶다면 사람들이 끝내야 할 업무, 사용할 그룹, 아직 확실하지 않은 부분을 알려 주세요. 범위, 납품, 지속적인 관리는 프로젝트별로 합의합니다.

소프트웨어 첫 버전에 관한 질문