새 개발팀이 미완성 맞춤형 소프트웨어를 끝낼 수 있을까요?

새 개발팀이 작동하는 부분을 확인하고 필요한 항목에 정당한 접근 권한을 얻어 중요한 업무 하나를 마무리할 방법을 제시할 수 있다면, 기존 소프트웨어를 완성할 가능성이 있습니다. 먼저 범위를 좁혀 평가를 요청하세요. 완성된 것처럼 보이는 화면도 결과를 저장하지 못할 수 있고, 코드 사본이 있어도 실행에 필요한 지침이나 서비스가 빠져 있을 수 있습니다.

실제 업무에 사용하는 버전이 있다면 평가하는 동안 누가 운영을 이어 갈지 정하세요. 당장 운영을 유지하는 일과 나중에 교체할지는 따로 결정할 수 있습니다.

새 개발팀에 무엇을 넘길 수 있나요?

마지막으로 사용하거나 테스트한 소스 코드 버전과 빌드에 필요한 지침과 의존 항목을 확보하세요. 배포와 외부 서비스 연결에 쓰는 계정을 누가 관리하는지, 업무 기록과 백업이 어디에 있는지, 계약상 무엇을 공유하거나 변경할 수 있는지 확인하세요. 코드 저장소에 들어갈 수 있다는 사실만으로 그런 권한이 확인되지는 않습니다.

각 항목을 따로 확인하세요. 사본을 실행할 수 있어도 운영 버전을 업데이트할 권한이 없을 수 있습니다. 반대로 호스팅 계정에 접속할 수 있어도 인계받은 자료로 소프트웨어를 다시 만들 수 없을 수 있습니다. 기록을 옮겨야 한다면 별도로 시험 삼아 데이터를 내보내고 새 시스템에서 사용할 수 있는지 확인하세요.

인수할 팀에 어떤 시연을 요청해야 하나요?

회사에 중요한 업무 하나를 고르세요. 서비스 담당자가 미완성 도구에서 요청을 제출할 수 있지만, 관리자가 승인하고 나중에 그 결정을 다시 확인하는 과정은 아직 시연하지 못했다고 가정해 봅시다. 권한을 얻은 별도의 테스트 환경에서 특정 버전을 빌드하고 그 업무를 수행해 달라고 하세요. 가상의 데이터를 사용하고 실제 알림이나 결제 등 외부에 영향을 주는 작업은 끄세요. 운영 중인 시스템은 테스트에 사용하지 않습니다.

요청이 어디까지 진행되고 어디서 멈추는지 기록하세요. 관리자가 승인할 수 있지만 요청을 다시 열 때 승인 결과가 사라진다면, 조사할 문제가 구체적입니다. 필요한 구성 요소가 없어 소프트웨어를 시작하지도 못했다면, 어떤 항목이 없었는지와 업무 흐름을 아직 시연하지 못했다는 점을 기록하세요. 승인 단계에서 실제 실패를 확인한 경우와는 다음에 해야 할 일이 다릅니다.

빌드가 성공했다는 것은 그 조건에서 해당 버전을 만들 수 있었다는 뜻입니다. 시스템 전체의 보안과 유지보수 가능성, 배포 권한 또는 운영 준비가 확인된 것은 아닙니다. 운영 책임 인계에 관한 Google의 설명에서 이 별도의 판단 과정을 볼 수 있습니다. 의존 관계와 운영 준비 상태를 검토하고, 필요한 경우 교육이나 개선을 진행합니다.

계속 개발할까요, 일부를 고칠까요, 교체할까요?

같은 업무를 기준으로 각 선택지를 비교하고, 도입 후 유지하는 데 필요한 일도 살펴보세요. 영국 정부의 조달 가이드는 필요한 기능과 비용, 운영 역량을 기준으로 기존 소프트웨어를 고쳐 쓰는 것과 새로 만드는 것을 비교하는 사례입니다.

교체가 적절하다고 판단했다면 현재 업무를 어떻게 이어 갈지는 따로 정하세요. 두 시스템을 한동안 함께 운영하는 방법도 있지만, 그에 따른 비용과 기록을 관리할 책임을 고려해야 합니다.

평가 결과에 무엇을 적어야 하나요?

실제로 소프트웨어를 쓰는 사람들과 함께 읽을 수 있는 짧은 기록을 요청하세요. 무엇을 시연했는지, 무엇이 실패했거나 시험할 수 없었는지, 어떤 접근이나 허가가 부족한지, 무엇이 현재 업무를 중단시킬 수 있는지가 들어가야 합니다. 가능한 선택지마다 다음 단계와 담당자, 추가 작업을 승인하기 전에 확인할 점을 적으세요.

신청 도구의 예에서는 기록된 승인 결과가 왜 사라지는지 조사한 다음, 관리자가 요청을 다시 열어 저장된 결정을 확인할 수 있음을 테스트 환경에서 시연하는 것이 다음 단계일 수 있습니다. 이 일을 맡길 팀을 비교한다면 맞춤형 소프트웨어 개발팀을 고르기 전에 물어볼 사항도 참고하세요.

미완성 소프트웨어를 인수할 때 자주 묻는 질문