소프트웨어 프로젝트 인수 - 진단, 비용과 인계

개발자가 떠나거나, 공급업체 관계가 무너지거나, 비즈니스가 여전히 애플리케이션에 의존하는 동안 제공이 중단되면 소프트웨어 프로젝트 인수가 긴급해집니다. 다른 팀을 찾는 것은 결정의 일부일 뿐입니다. 또한 제어 대상, 실제 프로덕션에서 실행되는 버전, 고객을 방해하지 않고 새로운 사람이 소프트웨어를 변경할 수 있는지 여부도 설정해야 합니다.

소프트웨어 프로젝트 인수는 액세스, 빌드 재현성, 데이터 복구 및 중요한 비즈니스 행동에 대한 증거 기반 평가로 시작되어야 합니다. 구현 약속과 평가를 분리한 다음, 책임을 수락하기 전에 차기 팀이 입증해야 할 사항에 동의합니다. 작동 중인 웹사이트와 복사된 저장소는 유용한 출발점이지만 둘 다 프로젝트가 안전하게 운영될 수 있다는 것을 증명하지 못합니다.

이 가이드는 인수를 평가하는 투자자가 아닌 인수를 의뢰하는 기업을 위한 것입니다. 목표는 유용한 소프트웨어를 유지하고, 제공 위험을 파악하고, 더 나은 증거를 바탕으로 다음 지출 결정을 내리는 것입니다. 이는 내부 비즈니스 애플리케이션, 고객 포털 또는 외부 팀이 유지 관리하는 제품에 적용됩니다.

소프트웨어 프로젝트 인수가 필요한 상황

애플리케이션에는 새 아키텍처가 없어도 새 소유자가 필요할 수 있습니다. 아마도 릴리스는 사용할 수 없는 개발자에 의존하거나, 중요한 변경 사항이 너무 오래 걸리거나, 지원 책임이 불분명해졌을 수 있습니다. 이러한 경우 첫 번째 목표는 연속성입니다. 안정적인 개발 및 운영 프로세스를 구축하면 이전에는 불가능해 보였던 개선이 가능해집니다.

기술적인 솔루션을 요청하기 전에 비즈니스 문제를 설명하십시오. 배포 중에 제출물이 손실되는 주문 시스템은 전혀 구축할 수 없는 프로토타입과 다른 평가가 필요합니다. 계속해서 작동해야 하는 사항, 다음으로 필요한 변경 사항 및 이를 놓친 경우의 결과를 설명합니다. 이는 들어오는 공급업체에게 조사 우선순위를 정할 수 있는 기반을 제공합니다.

좌절감을 즉시 다시 작성하는 브리핑으로 바꾸지 마십시오. 기존 시스템에는 누구도 문서화하지 않은 수년간의 비즈니스 규칙이 포함될 수 있습니다. 이를 교체하면 눈에 보이지 않는 동작을 잃어버리면서 눈에 보이는 화면을 재현할 수 있습니다. 인수 평가에서는 교체를 제안하기 전에 가치 있는 것, 안전하지 않은 것, 독립적으로 변경할 수 있는 변경 사항을 식별해야 합니다.

책임 범위를 정의하기

비즈니스 언어로 애플리케이션 경계를 그립니다. 사용자가 의존하는 인터페이스, 기록을 보관하는 데이터베이스, 정보를 이동하는 통합, 문제가 발생했을 때 대응하는 사람을 포함하세요. 저장소 경계는 고객이 공급자가 수락할 것으로 기대하는 운영 책임보다 작은 경우가 많습니다.

예를 들어 공급업체는 고객 포털을 유지 관리하고 내부 직원은 신원을 관리하고 별도의 회사에서 청구서를 관리할 수 있습니다. 들어오는 팀은 누가 각 시스템의 변경을 승인할 수 있는지 알아야 합니다. 그렇지 않으면 명백히 작은 업데이트가 액세스, 자격 증명 또는 누구도 프로젝트에 속하지 않는다고 생각한 통합에 대한 논쟁이 될 수 있습니다.

제외된 내용은 포함된 내용만큼 주의 깊게 기록하세요. 애플리케이션 유지 관리 작업에는 비즈니스 프로세스 재설계, 기록 데이터 정리 또는 연결된 모든 서비스 운영이 자동으로 포함되지 않습니다. 이러한 작업은 필요할 수 있지만 납품 계획에서 예상치 못한 가정이 아닌 지정된 소유자와 별도의 결정으로 나타나야 합니다.

운영 환경 변경 전에 접근 권한과 소유 관계 확인하기

소스 리포지토리, 호스팅, 도메인, 배포 시스템, 데이터베이스 및 연결된 서비스를 포괄하는 통제된 액세스 인벤토리를 요청하세요. 계정 소유자, 청구 소유자 및 액세스 권한을 복구할 수 있는 사람을 식별합니다. 적절한 경우 회사가 관리하는 계정을 사용하고 신규 공급업체에게 평가에 적합한 개별 액세스 권한을 제공하십시오.

기술적 접근은 자료를 사용하거나 수정하기 위한 계약상 허가와는 별개입니다. 사업주에게 적절한 조언자를 통해 코드 권리, 제3자 구성 요소 및 공급업체 계약에 대한 불확실성을 해결하도록 요청하세요. 기술 보고서는 누락된 증거를 식별할 수 있지만 저장소를 소유하면 모든 소유권 문제가 해결되는 척해서는 안 됩니다.

모든 자격 증명을 모든 참가자와 공유하는 이메일이나 문서에 복사하는 것으로 시작하지 마십시오. 보안 전송 방법과 각 작업에 필요한 최소 액세스 권한에 동의하세요. 교체해야 하는 자격 증명, 이에 의존하는 통합 및 생산 중단 없이 변경을 승인할 수 있는 사람의 등록을 유지 관리합니다.

저장소 이전만으로 인계가 끝나지는 않는다

GitHub의 저장소 전송 문서에는 연결된 웹훅, 서비스, 비밀 및 배포 키가 전송된 저장소에 남아 있다고 명시되어 있습니다. 또한 전송 중 공동작업자의 행동에 대해서도 설명합니다. 표시된 소유자를 변경한다고 해서 모든 이전 통합 또는 액세스 경로가 자동으로 제거되는 것으로 간주되어서는 안 되기 때문에 이러한 세부 정보가 중요합니다.

이전 후 실제 멤버십 및 자동화를 검토하세요. 어떤 자격 증명이 여전히 나가는 공급자에게 속해 있는지, 어떤 서비스가 이전 저장소 위치를 예상하는지, 대상 조직이 적용하는 권한을 결정합니다. 종속성 확인을 통해 자격 증명 교체를 계획하므로 액세스 제어를 개선해도 릴리스 파이프라인이나 필수 콜백이 비활성화되지 않습니다.

저장소를 운영 체제에 연결하는 인계 기록을 유지합니다. 관련 분기, 배포 소스, 빌드 구성 및 외부 종속성을 식별해야 합니다. 프로덕션 애플리케이션이 다른 브랜치에서 구축되었거나 버전 제어를 입력하지 않은 수동 서버 변경이 포함된 경우 그럴듯한 코드로 가득 찬 저장소는 충분하지 않습니다.

새 팀이 애플리케이션을 재현할 수 있는지 입증하기

원래 시스템을 구축하지 않은 사람에게 제공된 지침과 깔끔한 점검을 통해 작업 환경을 만들도록 요청하십시오. 필요한 런타임, 종속성, 구성 및 데이터 전제조건을 기록합니다. 누락된 단계는 다른 개발자의 노트북에서 보이지 않는 해결 방법이 아니라 문서화된 결과가 되어야 합니다.

데모는 알려진 소스 개정을 알려진 애플리케이션 아티팩트에 연결해야 합니다. 기존 배포 파이프라인을 사용할 수 있는 경우 이를 검사하고 적합한 비프로덕션 환경에서 실행합니다. 유일한 작업 복사본이 서버에 있는 경우 덮어쓰기 전에 복구하고 비교할 수 있는 복사본을 설정합니다. 정리보다 보존이 먼저다.

재현 가능한 빌드가 모든 기능이 정확하다는 것을 증명하지는 않지만 인수 대화를 변경합니다. 이제 팀은 개인의 기억에 의존하지 않고도 행동을 조사하고, 테스트를 추가하고, 변경 사항을 연습할 수 있습니다. 재생산이 실패하는 경우 평가에서는 고정된 구현 가격 안에 불확실성을 숨기기보다는 차단 증거를 설명하고 제한된 복구 작업을 권장해야 합니다.

코드 품질 평가 전에 업무 동작 파악하기

비즈니스 가치를 창출, 이동 또는 보호하는 여정부터 시작하세요. 등록, 권한, 주문 제출 및 상태 업데이트를 의미할 수 있는 고객 포털의 경우. 내부 애플리케이션의 경우 이는 기록 가져오기, 예외 수정 및 재무 결정을 내리는 데 사용되는 보고서 생성을 의미할 수 있습니다.

운영 직원에게 올바른 결과와 잘못된 결과의 예를 보여달라고 요청하세요. 영업 시연에 사용되는 행복한 경로뿐만 아니라 예외 경로도 관찰하세요. 애플리케이션은 취소된 주문, 중복된 수입 또는 비정상적인 계정 권한을 가진 고객을 잘못 처리하는 동안 표준 주문을 올바르게 수락할 수 있습니다. 이러한 세부 사항은 승인 테스트의 기초가 됩니다.

코드 스타일은 점진적으로 개선될 수 있습니다. 고객 잔액을 변경하거나 기록을 분실하는 문서화되지 않은 행위는 조기에 주의를 기울여야 합니다. 평가는 기술적 발견을 비즈니스 결과, 제안된 조치 및 문제를 종결하는 데 필요한 증거와 연결해야 합니다. 어수선한 파일의 긴 카탈로그는 안전한 작동을 방해하는 요소에 대한 간단한 설명보다 덜 유용합니다.

범위를 정해 보안 요구 사항 적용하기

OWASP ASVS는 웹 애플리케이션 보안 제어 및 보안 개발 요구 사항을 테스트하기 위한 기반을 제공합니다. 새로 합류하는 팀은 적절한 요구 사항을 선택하여 보안 평가를 명시적으로 만들 수 있습니다. 제안서에는 무엇을 검토할 것인지, 기업이 받게 될 증거는 무엇인지 명시해야 합니다.

실제 애플리케이션과 관련된 제어(인증, 권한 부여, 민감한 데이터 처리 및 노출된 인터페이스)에 우선순위를 둡니다. 종속성 스캔은 증거를 제공할 수 있지만 사용자가 다른 고객의 기록을 읽을 수 없다는 것을 입증하지는 않습니다. 마찬가지로 제한된 검토에서 명백한 문제를 발견하지 못했다고 해서 애플리케이션이 안전하다는 보장은 없습니다.

인수 발견은 위험이 보장되는 전용 보안 테스트 업무와 분리됩니다. 테스트하기 전에 환경 액세스, 테스트 권한 및 운영 제약 조건을 정의하세요. 유용한 결과는 기업이 아직 검토되지 않은 사항을 이해할 수 있을 만큼 명확하게 명시된 제한 사항과 함께 우선순위가 지정된 발견 사항 및 교정 증거 세트입니다.

백업 표시 대신 실제 데이터 복구 검증하기

성공적인 백업을 보여주는 대시보드는 고무적이지만 인수하려면 기업이 사용 가능한 데이터를 복구할 수 있다는 증거가 필요합니다. 백업되는 항목, 백업이 의존하는 애플리케이션 구성 요소, 복구 자료에 액세스할 수 있는 사람을 식별합니다. 애플리케이션이 데이터베이스 레코드를 해석하는 데 필요한 경우 첨부 파일, 구성 및 기타 상태를 포함합니다.

격리된 환경에서 복구를 연습하고 의미 있는 비즈니스 성과를 확인하세요. 복원된 포털에 주문 및 관련 문서가 표시될 수 있나요? 승인된 직원이 필요한 작업흐름을 완료할 수 있습니까? 단계, 관찰된 기간 및 누락된 전제조건을 기록하십시오. 신중한 연습을 검증되지 않은 회복 약속으로 대체하지 마십시오.

허용되는 데이터 손실 기간 및 서비스 중단 기간에 대해 비즈니스 소유자와 동의하세요. 이는 평가해야 할 요구 사항이지 새로운 공급업체가 추측해야 하는 수치가 아닙니다. 현재 설정이 이를 충족할 수 없는 경우 이를 개선할 수 있는 격차와 옵션을 보여줍니다. 복구 변경 사항을 관련 없는 기능 작업과 별도로 유지하여 해당 효과를 의도적으로 확인할 수 있습니다.

연동과 보이지 않는 예약 작업 점검하기

비즈니스 애플리케이션은 기본 사용자 인터페이스에 없는 작업과 콜백에 의존하는 경우가 많습니다. 예약된 내보내기, 결제 알림, 이메일 전달 및 야간 동기화는 생성된 이유를 아무도 기억하지 못하는 경우에도 계속 실행될 수 있습니다. 퇴임하는 팀과 운영 사용자에게 해당 프로세스와 구성 위치를 확인하도록 요청하세요.

각 중요한 경계에 걸쳐 대표적인 기록을 추적합니다. 대상을 사용할 수 없을 때, 동일한 메시지가 다시 도착할 때, 전송 후 사용자가 기록을 수정할 때 어떤 일이 발생하는지 설정합니다. 데모에서 한 번 작동하는 통합은 여전히 ​​중복을 생성하거나 중단 후 레코드가 영구적으로 정지된 상태로 남을 수 있습니다.

모든 중요한 통합에 운영 소유자와 실패 감지 방법을 제공하십시오. 인계 시 액세스 만료, 서비스 자격 증명 및 수동 복구를 포함합니다. 이 작업은 코드를 읽는 것보다 인계 비용이 더 많이 드는 이유를 설명할 수 있습니다. 들어오는 팀은 동작이 애플리케이션 자체 외부의 비즈니스에 영향을 미치는 종속성 네트워크를 상속받습니다.

증거에 근거한 인계 완료 기준 합의하기

수락하려면 “팀이 코드를 이해합니다"와 같은 광범위한 진술보다는 관찰 가능한 데모가 필요합니다. 공급업체에 깔끔한 빌드, 제어된 배포, 중요한 작업 흐름 및 복구 리허설을 보여달라고 요청하세요. 평가가 끝나면 제한 사항과 해결되지 않은 작업의 소유자를 문서화합니다.

다음 매트릭스는 논의의 출발점입니다. 산문에서 핵심 메시지는 제어, 전달, 비즈니스 행동 및 복구 각각에 고유한 증거가 필요하다는 것입니다. 하나를 통과한다고 해서 다른 것도 통과하는 것은 아닙니다. 작업 명세서에 테스트를 포함하기 전에 애플리케이션의 책임에 맞게 테스트를 조정하십시오.

진단 비용과 인수 구현 비용 분리하기

명명된 결과물, 액세스 가정 및 중단 지점이 포함된 평가에 대한 범위가 지정된 GBP 견적을 요청하세요. 기업이 다른 구현 공급자를 선택하더라도 출력은 결정을 뒷받침해야 합니다. 정의되지 않은 후속 프로젝트 구매만을 권장하는 보고서는 구매자에게 독립적인 가치를 거의 남기지 않습니다.

그런 다음 제공 비용은 빌드 인프라 누락, 단편화된 액세스, 취약한 테스트, 취약한 통합 또는 상당한 복구 작업 등 평가 결과에 따라 달라집니다. 이러한 작업 패키지는 별도로 요청하세요. 긴급한 연속성 작업은 광범위한 아키텍처 개선 전에 자금을 조달할 가치가 있을 수 있으며, 해결되지 않은 소유권 문제로 인해 개발이 완전히 차단될 수 있습니다.

반복적인 지원 비용과 초기 노력을 비교하십시오. 사고 범위, 유지 관리 책임, 제3자 청구서 및 향후 인계 준비를 명확히 합니다. 버려진 프로토타입과 비즈니스에 중요한 생산 시스템에서 보편적인 가격대는 신뢰할 수 없습니다. 신뢰할 수 있는 추정치는 불확실성과 이를 줄이는 데 필요한 증거를 설명합니다.

의사결정에 필요한 결과를 기준으로 견적 비교하기

두 가지 평가 제안은 동일한 가격을 가질 수 있지만 매우 다른 가치를 제공할 수 있습니다. 하나는 코드 검사만 할 수 있고 다른 하나는 빌드 재현과 복구 리허설을 포함할 수 있습니다. 총계를 동등하게 취급하기 전에 결과물, 애플리케이션 경계 및 액세스 가정을 비교하십시오. 나가는 공급업체나 직원의 참여가 필요한 활동이 무엇인지 물어보십시오.

예시적인 예산 책정 접근 방식은 검색, 연속성 작업 및 계획된 개선을 위해 별도의 라인을 요청하는 것입니다. 이는 시장 가격 주장이 아닌 견적을 구성하는 방법입니다. 전체 프로젝트에 첨부된 설명할 수 없는 버퍼를 받아들이는 대신 우발 상황을 가시적으로 유지하고 이를 문서화되지 않은 통합과 같은 명명된 불확실성에 연결합니다.

추가 결과가 범위에 어떤 영향을 미칠지 동의합니다. 공급업체는 작업을 확대하기 전에 조사 결과, 결과 및 사용 가능한 옵션을 설명해야 합니다. 기업은 이미 수집된 증거를 잃지 않고 불필요한 개선을 연기할 수 있어야 합니다. 따라서 평가는 무기한 약속이 아닌 유용한 구매 도구가 됩니다.

안정화, 교체와 단계적 이전 중 선택하기

안정화는 애플리케이션이 올바른 비즈니스 프로세스를 지원하고 즉각적인 약점을 격리할 수 있을 때 매력적입니다. 배포 파이프라인을 재구축하고 구성을 문서화하거나 테스트를 통해 중요한 여정을 보호하면 제품을 교체하지 않고도 다음 릴리스가 가능해질 수 있습니다. 코드의 수명이 아니라 가능한 결과로 옵션을 판단하십시오.

요구사항이 근본적으로 변경되었거나 제한적 평가를 통해 중요한 제약 조건을 경제적으로 해결할 수 없다는 사실이 밝혀지면 교체가 더 타당해집니다. 그럼에도 불구하고 계획에는 데이터 마이그레이션, 통합 연속성 및 기존 비즈니스 규칙의 검증이 필요합니다. 새로운 인터페이스로 인해 이전 시스템이 수행한 작업을 이해할 필요가 없어지지는 않습니다.

단계적 마이그레이션을 통해 문제가 있는 경계를 교체하면서 유용한 구성 요소를 유지할 수 있습니다. 예를 들어 취약한 보고 내보내기는 애플리케이션의 나머지 부분이 변경되기 전에 안정적인 인터페이스 뒤로 이동할 수 있습니다. 공존 규칙 및 롤백 경로에 동의합니다. 직원이 매일 수동으로 조정해야 하는 두 개의 경쟁적인 정보 소스를 생성하지 마십시오.

가상 사례: 개발자와 연락이 닿지 않는 포털

고객 포털에서 여전히 주문을 수락하지만 원래 개발자를 사용할 수 없는 가상의 유통업체를 생각해 보십시오. 해당 기업은 저장소에 액세스하고 송장을 호스팅하고 있지만 누구도 릴리스를 시연할 수 없습니다. 이는 Mecanik 고객 결과나 일반적인 인수 기간의 증거가 아닌 예시적인 상황입니다.

첫 번째 평가에서는 실행 중인 시스템을 보존하고 회사 액세스를 확인하며 빌드 인 스테이징을 재현합니다. 직원이 일반 주문, 취소된 주문, 권한이 제한된 계정을 보여줍니다. 조사 결과 창고로 주문을 보내는 문서화되지 않은 예정된 수출이 밝혀졌습니다. 그 과정은 고객에게 보이지 않더라도 수락에 포함되어야 합니다.

권장되는 다음 단계는 연속성 작업입니다. 즉, 내보내기를 문서화하고 오류 가시성을 추가하며 배포 및 복구를 연습하는 것입니다. 요청된 재설계 비용은 별도로 부과됩니다. 기업이 계속해서 주문을 받는 데 필요한 작업과 외모를 개선하기 위한 작업을 구별할 수 있기 때문에 결정이 더 명확해집니다. 나중에 보존해야 할 내용에 대한 더 나은 증거를 통해 재작성이 발생할 수 있습니다.

첫 번째 변경을 통제 가능한 범위로 계획하기

필수적인 접근 및 운영 증거가 존재하면 관찰하고 되돌릴 수 있을 만큼 작은 변경 사항을 선택합니다. 릴리스 프로세스를 실행하는 동안 실제 요구 사항을 해결해야 합니다. 중요한 워크플로우에 전혀 영향을 주지 않는 외관상의 변경은 너무 작은 것으로 판명될 수 있으며, 주요 데이터 마이그레이션은 첫 번째 릴리스에 불필요한 노출을 초래합니다.

개발이 시작되기 전에 예상되는 동작을 설명합니다. 이를 확인할 사용자, 감시할 작동 신호 및 롤백을 트리거하는 조건을 식별합니다. 준비 과정에서 관련 단계를 연습하고 제작 과정과의 차이점을 기록하세요. 지속 또는 복구 결정을 내릴 수 있는 소유자와 함께 릴리스 일정을 잡으세요.

배포 후 비즈니스 성과 및 기술 상태를 확인합니다. 내보내기가 자동으로 중지되는 동안 서버는 정상적으로 응답할 수 있습니다. 발생한 상황을 기록하고 세부 정보가 최신 상태일 때 Runbook을 업데이트하세요. 첫 번째 성공적인 통제된 변경은 인계 프로세스가 작동하고 있다는 유용한 증거이지만 모든 미해결 평가 결과가 종결되는 것은 아닙니다.

기존 개발사와 건설적으로 협력하기

“모든 것을 보내달라"는 막연한 요청보다는 구체적인 인계 안건을 요청하세요. 애플리케이션 경계, 필수 액세스 권한, 데모를 사전에 공유하세요. 세션을 사용하여 의사 결정, 운영상의 문제 및 해결되지 않은 질문을 포착하세요. 합의된 경우 녹음이 도움이 될 수 있지만 시스템 변경 시 검색 가능한 서면 런북을 유지하는 것이 더 쉽습니다.

공급업체 관계가 긴장된 경우 논의를 사실에 근거하여 유지하십시오. 확인된 결함과 이용 불가능한 증거를 구별합니다. 누락된 지침은 짧은 세션에서 복구할 수 있는 반면 의심되는 문제는 수정 작업이 되기 전에 테스트가 필요할 수 있습니다. 회의록에 모호한 설명을 남기기보다는 소유자를 지정하고 후속 조치를 취하세요.

나가는 팀이 질문에 대답하는 것에 연속성을 무기한 의존하지 마십시오. 가능하다면 제한적인 전환 방식에 동의한 다음, 새로 합류하는 팀이 필수 작업을 독립적으로 완료할 수 있는지 확인하세요. 협조가 불가능한 경우에는 평가범위 및 추정에 그 한계를 반영합니다. 수용에 필요한 증거의 기준이 아니라 회복 노력이 바뀌는 것입니다.

업무 연속성을 중심으로 프로젝트 인수 의뢰하기

애플리케이션의 목적, 현재 문제, 알려진 액세스, 중요한 작업 흐름 및 원하는 다음 변경 사항에 대한 간단한 개요를 준비합니다. 합의된 채널을 통해 사용 가능한 아키텍처 노트와 익명화된 예시를 제공하세요. 예외 사항을 설명하고 승인을 승인할 수 있는 직원을 확인하십시오. 이러한 입력은 공급업체가 모든 기술 구성 요소를 이해하도록 요구하지 않고도 평가 범위를 지정하는 데 도움이 됩니다.

Mecanik의 소프트웨어 개발 서비스는 상속된 애플리케이션을 평가하고 유지 관리 또는 추가 개발에 대한 제어된 경로를 정의하는 데 도움을 줄 수 있습니다. 액세스, 빌드, 동작 및 운영을 포괄하는 명시적인 결과물이 포함된 평가를 요청하세요. 증거 수집, 긴급 연속성 작업, 선택적 개선을 구분하는 범위가 지정된 GBP 제안을 요청하세요.

유용한 결과는 비즈니스가 책임 있는 지원을 통해 운영하고 변경할 수 있는 시스템입니다. 인수를 일련의 입증된 기능으로 처리하고, 각 결정에서 해결되지 않은 위험이 표시됩니다. 이는 다음 공급업체에게 현실적인 책임을 부여하고 안심할 수 있는 코드 검토나 즉각적인 재작성 약속보다 더 명확한 지출 기반을 제공합니다.

자주 묻는 질문

원래 개발자의 도움 없이 새로운 개발자가 인수할 수 있나요? 종종 가능하지만 액세스가 부족하고 빌드 지침 및 운영 지식이 있으면 불확실성이 커집니다. 기존 시스템을 보존하고 복구 가능한 증거를 식별하는 제한된 평가부터 시작하십시오. 들어오는 팀이 필수 종속성을 이해하기 전에 배송 날짜를 약속하지 마십시오.

저장소 이전으로 인해 이전 공급자의 액세스 권한이 제거됩니까? 그렇다고 가정하지 마십시오. 이전 후 공동작업자, 조직 권한, 배포 사용자 인증 정보, 연결된 서비스를 검토하세요. 비밀 및 배포 키와 관련된 GitHub 문서는 전송된 저장소에 남아 있으므로 자격 증명 및 액세스 검토는 별도의 핸드오버 작업입니다.

인수 중에 신청서를 다시 작성해야 합니까? 평가가 해당 결정을 뒷받침하는 경우에만 가능합니다. 배송을 안정화하거나 제한된 구성 요소를 교체하면 중단을 최소화하면서 긴급한 문제를 해결할 수 있습니다. 다시 작성하려면 비즈니스 규칙을 이해하고, 데이터를 마이그레이션하고, 통합을 유지해야 하므로 자체 평가 범위가 있어야 합니다.

소프트웨어 프로젝트 인수 비용은 어떻게 결정되나요? 액세스 준비 상태, 빌드 재현성, 중요한 워크플로, 통합, 보안 범위 및 복구 요구 사항이 노력을 결정합니다. 범위가 지정된 GBP 평가 견적을 요청한 다음 긴급 연속성 작업과 개선 작업을 분리하세요. 모든 코드 검토를 동일한 서비스로 취급하기보다는 결과물과 가정을 비교하십시오.

핸드오버가 완료되었는지 어떻게 알 수 있나요? 사전에 승인 데모에 동의하십시오. 액세스 검토, 클린 빌드, 제어된 배포, 중요한 워크플로 확인 및 필요한 경우 복구 리허설이 포함됩니다. 운영 소유자의 이름을 지정하고 해결되지 않은 결과를 문서화합니다. 완료란 단순히 파일의 주인이 바뀌었다는 사실뿐만 아니라, 들어오는 팀이 증거를 가지고 합의된 책임을 수행할 수 있음을 의미합니다.