Tiếp Quản Dự Án Phần Mềm - Đánh Giá Và Bàn Giao

Việc tiếp quản dự án phần mềm trở nên cấp bách khi một nhà phát triển rời đi, mối quan hệ với nhà cung cấp bị phá vỡ hoặc việc giao hàng bị đình trệ trong khi hoạt động kinh doanh vẫn phụ thuộc vào ứng dụng. Tìm một đội khác chỉ là một phần của quyết định. Bạn cũng cần thiết lập những gì bạn kiểm soát, phiên bản nào thực sự chạy trong môi trường vận hành và liệu người mới có thể thay đổi phần mềm mà không làm gián đoạn khách hàng hay không.

Việc tiếp quản dự án phần mềm nên bắt đầu bằng việc đánh giá quyền truy cập dựa trên bằng chứng, khả năng tái tạo xây dựng, phục hồi dữ liệu và hành vi kinh doanh quan trọng. Tách đánh giá khỏi cam kết thực hiện, sau đó thống nhất những gì nhóm mới phải chứng minh trước khi nhận trách nhiệm. Một trang web đang hoạt động và một kho lưu trữ được sao chép là những điểm khởi đầu hữu ích, nhưng cả hai đều không chứng minh rằng dự án có thể được vận hành an toàn.

Hướng dẫn này dành cho doanh nghiệp ủy quyền tiếp quản chứ không phải dành cho nhà đầu tư đánh giá việc mua lại. Mục đích là giữ lại phần mềm hữu ích, phát hiện rủi ro giao hàng và đưa ra quyết định chi tiêu tiếp theo với bằng chứng tốt hơn. Nó áp dụng cho ứng dụng kinh doanh nội bộ, cổng thông tin khách hàng hoặc sản phẩm được duy trì bởi nhóm bên ngoài.

Khi nào việc tiếp quản dự án phần mềm là phù hợp

Một ứng dụng có thể cần chủ sở hữu mới mà không cần kiến trúc mới. Có lẽ các bản phát hành phụ thuộc vào nhà phát triển không có mặt, các thay đổi quan trọng mất quá nhiều thời gian hoặc trách nhiệm hỗ trợ không rõ ràng. Trong những trường hợp đó, mục tiêu đầu tiên là tính liên tục. Việc thiết lập một quy trình vận hành và phát triển đáng tin cậy có thể mở ra những cải tiến mà trước đây tưởng chừng như không thể thực hiện được.

Mô tả vấn đề kinh doanh trước khi yêu cầu giải pháp kỹ thuật. Một hệ thống đặt hàng bị mất nội dung gửi trong quá trình triển khai cần được đánh giá khác với một nguyên mẫu hoàn toàn không thể xây dựng được. Nêu rõ những gì phải tiếp tục phát huy tác dụng, thay đổi cần thiết tiếp theo và hậu quả của việc bỏ lỡ nó. Điều đó mang lại cho nhà cung cấp mới cơ sở để ưu tiên điều tra.

Tránh biến sự thất vọng thành một bản tóm tắt viết lại ngay lập tức. Hệ thống hiện tại có thể bao gồm nhiều quy tắc kinh doanh kéo dài nhiều năm mà không ai ghi lại. Việc thay thế nó có thể tái tạo các màn hình hiển thị trong khi mất đi hành vi vô hình. Đánh giá tiếp quản cần xác định điều gì có giá trị, điều gì không an toàn và những thay đổi nào có thể được thực hiện một cách độc lập trước khi đề xuất thay thế.

Xác định phạm vi trách nhiệm

Vẽ ranh giới ứng dụng trong ngôn ngữ kinh doanh. Bao gồm các giao diện mà người dùng phụ thuộc vào, cơ sở dữ liệu lưu giữ hồ sơ của họ, các tích hợp di chuyển thông tin và những người phản hồi khi có sự cố. Ranh giới kho lưu trữ thường nhỏ hơn trách nhiệm vận hành mà khách hàng mong đợi nhà cung cấp chấp nhận.

Ví dụ: một nhà cung cấp có thể duy trì cổng thông tin khách hàng trong khi nhân viên nội bộ quản lý danh tính và một công ty riêng thực hiện việc thanh toán. Nhóm mới đến cần biết ai có thể cho phép thay đổi trong mỗi hệ thống. Nếu không, một bản cập nhật nhỏ dường như có thể trở thành tranh chấp về quyền truy cập, thông tin đăng nhập hoặc sự tích hợp mà không ai nghĩ rằng nó thuộc về dự án.

Ghi lại những gì bị loại trừ một cách cẩn thận như những gì được bao gồm. Tiếp quản việc bảo trì ứng dụng không tự động bao gồm việc thiết kế lại quy trình kinh doanh, làm sạch dữ liệu lịch sử hoặc vận hành mọi dịch vụ được kết nối. Những nhiệm vụ đó có thể trở nên cần thiết nhưng chúng sẽ xuất hiện dưới dạng các quyết định riêng biệt với các chủ sở hữu được nêu tên thay vì các giả định bất ngờ trong kế hoạch phân phối.

Kiểm tra quyền truy cập và quyền sở hữu trước khi sửa hệ thống đang vận hành

Yêu cầu kiểm kê quyền truy cập được kiểm soát bao gồm kho nguồn, dịch vụ lưu trữ, miền, hệ thống triển khai, cơ sở dữ liệu và các dịch vụ được kết nối. Xác định chủ sở hữu tài khoản, chủ sở hữu thanh toán và những người có thể khôi phục quyền truy cập. Sử dụng các tài khoản do công ty kiểm soát khi thích hợp và cung cấp cho nhà cung cấp đầu vào quyền truy cập cá nhân phù hợp để đánh giá.

Quyền truy cập kỹ thuật tách biệt với sự cho phép theo hợp đồng để sử dụng hoặc sửa đổi tài liệu. Yêu cầu chủ doanh nghiệp giải quyết những vấn đề không chắc chắn về quyền mã, các thành phần của bên thứ ba và thỏa thuận với nhà cung cấp thông qua các cố vấn thích hợp. Báo cáo kỹ thuật có thể xác định bằng chứng còn thiếu, nhưng nó không nên giả vờ rằng việc sở hữu một kho giải quyết mọi vấn đề về quyền sở hữu.

Đừng bắt đầu bằng cách sao chép mọi thông tin xác thực vào email hoặc tài liệu được chia sẻ với tất cả người tham gia. Đồng ý một phương thức chuyển giao an toàn và quyền truy cập tối thiểu cần thiết cho mỗi tác vụ. Duy trì sổ đăng ký thông tin xác thực phải được thay thế, các tích hợp phụ thuộc vào chúng và người có thể phê duyệt thay đổi mà không làm gián đoạn quá trình sản xuất.

Chuyển kho mã nguồn chưa hoàn tất bàn giao

Tài liệu chuyển kho lưu trữ của GitHub nêu rõ rằng các webhook, dịch vụ, bí mật và khóa triển khai liên quan vẫn còn trong kho lưu trữ được chuyển. Nó cũng mô tả hành vi của cộng tác viên trong quá trình chuyển giao. Những chi tiết đó quan trọng vì việc thay đổi chủ sở hữu được hiển thị không được coi là tự động xóa mọi đường dẫn truy cập hoặc tích hợp cũ.

Xem lại tư cách thành viên thực tế và tự động hóa sau khi chuyển. Xác định thông tin xác thực nào vẫn thuộc về nhà cung cấp gửi đi, dịch vụ nào mong đợi vị trí kho lưu trữ cũ và quyền nào mà tổ chức đích áp dụng. Lập kế hoạch thay thế thông tin xác thực bằng các kiểm tra phụ thuộc, nhờ đó, việc cải thiện khả năng kiểm soát quyền truy cập sẽ không vô hiệu hóa quy trình phát hành hoặc lệnh gọi lại thiết yếu.

Lưu giữ hồ sơ bàn giao kết nối kho lưu trữ với hệ thống vận hành. Cần xác định các nhánh có liên quan, nguồn triển khai, cấu hình bản dựng và các phần phụ thuộc bên ngoài. Một kho lưu trữ chứa đầy mã hợp lý sẽ không đủ nếu ứng dụng sản xuất được xây dựng từ một nhánh khác hoặc bao gồm thay đổi máy chủ thủ công chưa bao giờ được đưa vào kiểm soát phiên bản.

Chứng minh nhóm mới có thể dựng lại ứng dụng

Hãy yêu cầu người không xây dựng hệ thống ban đầu tạo môi trường làm việc từ các hướng dẫn được cung cấp và kiểm tra rõ ràng. Ghi lại thời gian chạy cần thiết, các phần phụ thuộc, cấu hình và điều kiện tiên quyết về dữ liệu. Các bước bị thiếu sẽ trở thành những phát hiện được ghi lại thay vì cách giải quyết vô hình trên máy tính xách tay của nhà phát triển khác.

Phần trình diễn sẽ kết nối bản sửa đổi nguồn đã biết với một sản phẩm ứng dụng đã biết. Nếu có sẵn quy trình triển khai hiện có, hãy kiểm tra và chạy quy trình đó trong môi trường phi sản xuất phù hợp. Nếu bản sao hoạt động duy nhất tồn tại trên máy chủ, hãy thiết lập những gì có thể được phục hồi và so sánh trước khi ghi đè lên nó. Bảo quản đến trước khi dọn dẹp.

Một bản dựng có thể tái tạo không chứng minh được mọi tính năng đều đúng nhưng nó thay đổi cuộc trò chuyện tiếp quản. Giờ đây, nhóm có thể điều tra hành vi, thêm các bài kiểm tra và diễn tập các thay đổi mà không cần dựa vào trí nhớ của từng cá nhân. Nếu tái tạo không thành công, đánh giá nên giải thích bằng chứng cản trở và đề xuất nhiệm vụ khôi phục có giới hạn, thay vì che giấu sự không chắc chắn bên trong mức giá thực hiện cố định.

Xác định hành vi nghiệp vụ trước khi đánh giá chất lượng mã

Bắt đầu với những hành trình tạo ra, di chuyển hoặc bảo vệ giá trị doanh nghiệp. Đối với cổng thông tin khách hàng có thể có nghĩa là đăng ký, quyền, gửi đơn đặt hàng và cập nhật trạng thái. Đối với ứng dụng nội bộ, điều này có thể có nghĩa là nhập hồ sơ, sửa các trường hợp ngoại lệ và tạo báo cáo dùng để đưa ra quyết định tài chính.

Yêu cầu nhân viên vận hành đưa ra ví dụ về kết quả đúng và sai. Hãy quan sát các đường dẫn ngoại lệ, không chỉ đường dẫn hạnh phúc được sử dụng trong phần trình bày bán hàng. Một ứng dụng có thể chấp nhận một cách chính xác một đơn hàng tiêu chuẩn trong khi xử lý sai các đơn hàng bị hủy, nhập trùng lặp hoặc khách hàng có quyền tài khoản bất thường. Những chi tiết đó trở thành nền tảng của các bài kiểm tra chấp nhận.

Phong cách mã có thể được cải thiện dần dần. Hành vi không có giấy tờ làm thay đổi số dư của khách hàng hoặc làm mất hồ sơ đáng được quan tâm sớm hơn. Việc đánh giá phải kết nối các phát hiện kỹ thuật với kết quả kinh doanh, hành động được đề xuất và bằng chứng cần thiết để giải quyết vấn đề. Một danh mục dài các tập tin lộn xộn sẽ ít hữu ích hơn một lời giải thích ngắn gọn về những gì cản trở hoạt động an toàn.

Xác định phạm vi kiểm tra yêu cầu bảo mật

OWASP ASVS cung cấp cơ sở để thử nghiệm các yêu cầu và biện pháp kiểm soát bảo mật ứng dụng web để phát triển an toàn. Nhóm mới đến có thể sử dụng lựa chọn yêu cầu phù hợp để đánh giá bảo mật của mình một cách rõ ràng. Đề xuất nên nêu rõ những gì sẽ được kiểm tra và những bằng chứng nào doanh nghiệp sẽ nhận được.

Ưu tiên các biện pháp kiểm soát liên quan đến ứng dụng thực tế: xác thực, ủy quyền, xử lý dữ liệu nhạy cảm và giao diện hiển thị. Quét phụ thuộc có thể đóng góp bằng chứng nhưng không chứng minh được rằng người dùng không thể đọc hồ sơ của khách hàng khác. Tương tự, việc không tìm thấy vấn đề rõ ràng nào trong quá trình xem xét hạn chế không phải là sự đảm bảo rằng ứng dụng được an toàn.

Tách biệt việc phát hiện tiếp quản khỏi cam kết kiểm tra bảo mật chuyên dụng khi rủi ro đảm bảo điều đó. Xác định quyền truy cập môi trường, quyền kiểm tra và các ràng buộc hoạt động trước khi thử nghiệm. Kết quả hữu ích là một tập hợp các phát hiện và bằng chứng khắc phục được ưu tiên, với những hạn chế được nêu rõ ràng để doanh nghiệp hiểu được những gì vẫn chưa được kiểm tra.

Kiểm chứng khôi phục dữ liệu bằng diễn tập

Bảng điều khiển hiển thị các bản sao lưu thành công là điều đáng khích lệ, nhưng việc tiếp quản cần có bằng chứng cho thấy doanh nghiệp có thể khôi phục dữ liệu có thể sử dụng được. Xác định nội dung nào được sao lưu, thành phần ứng dụng nào phụ thuộc và ai có thể truy cập tài liệu khôi phục. Bao gồm các tệp đính kèm, cấu hình và trạng thái khác nếu ứng dụng cần chúng để diễn giải các bản ghi cơ sở dữ liệu.

Diễn tập quá trình phục hồi trong môi trường biệt lập và kiểm tra kết quả kinh doanh có ý nghĩa. Cổng thông tin được khôi phục có thể hiển thị đơn đặt hàng và các tài liệu liên quan không? Nhân viên được ủy quyền có thể hoàn thành quy trình làm việc cần thiết không? Ghi lại các bước, thời lượng quan sát và mọi điều kiện tiên quyết còn thiếu. Đừng thay thế lời hứa phục hồi chưa được kiểm chứng bằng một buổi diễn tập có tính toán.

Đồng ý về khoảng thời gian mất dữ liệu và gián đoạn dịch vụ có thể chấp nhận được với chủ doanh nghiệp. Đây là những yêu cầu để đánh giá chứ không phải những con số mà nhà cung cấp mới nên đoán. Nếu thiết lập hiện tại không thể đáp ứng được chúng, hãy chỉ ra khoảng trống và các phương án để cải thiện nó. Giữ các thay đổi khôi phục tách biệt khỏi hoạt động của tính năng không liên quan để có thể kiểm tra hiệu quả của chúng một cách có chủ ý.

Kiểm tra tích hợp và tác vụ định kỳ chạy nền

Các ứng dụng kinh doanh thường phụ thuộc vào các công việc và lệnh gọi lại không có trong giao diện người dùng chính. Xuất theo lịch, thông báo thanh toán, gửi email và đồng bộ hóa qua đêm có thể tiếp tục chạy ngay cả khi không ai nhớ lý do chúng được tạo. Yêu cầu nhóm sắp ra đi và người dùng vận hành xác định các quy trình đó và nơi chúng được cấu hình.

Theo dõi một bản ghi đại diện trên mỗi ranh giới quan trọng. Thiết lập điều gì sẽ xảy ra khi đích không có sẵn, khi cùng một tin nhắn lại đến và khi người dùng sửa bản ghi sau khi truyền. Tiện ích tích hợp hoạt động một lần trong bản trình diễn vẫn có thể tạo ra các bản sao hoặc khiến các bản ghi bị kẹt vĩnh viễn sau khi bị gián đoạn.

Cung cấp cho mọi tích hợp quan trọng một chủ sở hữu vận hành và cách phát hiện lỗi. Bao gồm thời hạn truy cập, thông tin xác thực dịch vụ và khôi phục thủ công trong quá trình chuyển giao. Công việc này có thể giải thích tại sao việc tiếp quản lại tốn kém hơn việc đọc mã: nhóm sắp tới đang kế thừa một mạng lưới các phụ thuộc có hành vi ảnh hưởng đến hoạt động kinh doanh bên ngoài chính ứng dụng.

Thống nhất nghiệm thu bàn giao dựa trên bằng chứng

Việc chấp nhận phải yêu cầu những minh chứng có thể quan sát được thay vì những tuyên bố chung chung như “nhóm hiểu mã”. Yêu cầu nhà cung cấp trình bày bản dựng rõ ràng, quá trình triển khai có kiểm soát, quy trình làm việc quan trọng và buổi diễn tập phục hồi. Ghi lại mọi hạn chế và ai sở hữu công việc chưa được giải quyết khi quá trình đánh giá kết thúc.

Ma trận sau đây là điểm khởi đầu cho cuộc thảo luận. Trong văn xuôi, thông điệp cốt lõi của nó là việc kiểm soát, phân phối, hành vi kinh doanh và phục hồi, mỗi thứ đều cần có bằng chứng riêng. Vượt qua một cái không có nghĩa là vượt qua những cái khác. Điều chỉnh các bài kiểm tra theo trách nhiệm của ứng dụng trước khi đưa chúng vào báo cáo công việc.

Tách chi phí đánh giá khỏi công việc triển khai tiếp quản

Yêu cầu báo giá GBP trong phạm vi đánh giá với các sản phẩm được phân phối có tên, các giả định về quyền truy cập và điểm dừng. Đầu ra phải hỗ trợ quyết định ngay cả khi doanh nghiệp chọn nhà cung cấp triển khai khác. Một báo cáo chỉ khuyến nghị mua một dự án tiếp theo chưa được xác định sẽ khiến người mua có rất ít giá trị độc lập.

Sau đó, chi phí phân phối phụ thuộc vào những gì đánh giá tìm thấy: cơ sở hạ tầng xây dựng còn thiếu, khả năng truy cập bị phân mảnh, kiểm tra yếu, tích hợp dễ vỡ hoặc công việc khôi phục đáng kể. Yêu cầu các gói công việc này một cách riêng biệt. Một nhiệm vụ khẩn cấp liên tục có thể xứng đáng được tài trợ trước khi cải tiến kiến ​​trúc rộng hơn và vấn đề quyền sở hữu chưa được giải quyết có thể cản trở hoàn toàn sự phát triển.

So sánh chi phí hỗ trợ định kỳ cũng như nỗ lực ban đầu. Làm rõ phạm vi sự cố, trách nhiệm bảo trì, hóa đơn của bên thứ ba và các thỏa thuận bàn giao trong tương lai. Không có mức giá phổ quát nào có thể đáng tin cậy đối với một nguyên mẫu bị bỏ rơi và một hệ thống sản xuất quan trọng trong kinh doanh. Một ước tính đáng tin cậy giải thích sự không chắc chắn và bằng chứng cần thiết để giảm thiểu nó.

So sánh báo giá theo quyết định mà chúng hỗ trợ

Hai đề xuất đánh giá có thể có cùng mức giá và mang lại giá trị rất khác nhau. Người ta chỉ có thể kiểm tra mã, trong khi người khác bao gồm việc tái tạo bản dựng và diễn tập phục hồi. So sánh các sản phẩm bàn giao, ranh giới ứng dụng và các giả định về quyền truy cập trước khi coi tổng số của chúng là tương đương. Hỏi những hoạt động nào cần có sự tham gia của nhà cung cấp sắp tới hoặc nhân viên của bạn.

Một cách tiếp cận lập ngân sách minh họa là yêu cầu các dòng riêng biệt để khám phá, thực hiện công việc liên tục và cải tiến theo kế hoạch. Đây là một cách để cấu trúc một báo giá, không phải là một yêu cầu về giá thị trường. Giữ khả năng dự phòng rõ ràng và kết nối nó với những điều không chắc chắn được đặt tên, chẳng hạn như sự tích hợp không có giấy tờ, thay vì chấp nhận một khoảng đệm không giải thích được gắn liền với toàn bộ dự án.

Đồng ý những phát hiện bổ sung sẽ ảnh hưởng đến phạm vi như thế nào. Nhà cung cấp nên giải thích phát hiện này, hậu quả của nó và các lựa chọn sẵn có trước khi mở rộng công việc. Doanh nghiệp có thể trì hoãn một cải tiến không cần thiết mà không làm mất bằng chứng đã thu thập được. Điều này làm cho việc đánh giá trở thành một công cụ mua hàng hữu ích hơn là một cam kết mở.

Chọn ổn định, thay thế hoặc chuyển đổi từng giai đoạn

Tính ổn định sẽ hấp dẫn khi ứng dụng hỗ trợ quy trình kinh doanh phù hợp và các điểm yếu trước mắt của nó có thể được tách biệt. Xây dựng lại quy trình triển khai, ghi lại cấu hình hoặc bảo vệ hành trình quan trọng bằng các thử nghiệm có thể giúp thực hiện bản phát hành tiếp theo mà không cần thay thế sản phẩm. Đánh giá tùy chọn theo kết quả mà nó mang lại, không phải theo độ tuổi của mã.

Việc thay thế trở nên hợp lý hơn khi các yêu cầu về cơ bản đã thay đổi hoặc một đánh giá có giới hạn cho thấy rằng những hạn chế quan trọng không thể giải quyết được về mặt kinh tế. Ngay cả khi đó, kế hoạch vẫn cần di chuyển dữ liệu, tích hợp liên tục và xác minh các quy tắc kinh doanh hiện có. Giao diện mới không loại bỏ nhu cầu hiểu hệ thống trước đó đã làm gì.

Quá trình di chuyển theo giai đoạn có thể giữ lại các thành phần hữu ích trong khi thay thế ranh giới có vấn đề. Ví dụ: quá trình xuất báo cáo dễ hỏng có thể di chuyển ra sau giao diện ổn định trước khi phần còn lại của ứng dụng thay đổi. Đồng ý các quy tắc cùng tồn tại và một lộ trình quay trở lại. Tránh tạo ra hai nguồn thông tin cạnh tranh nhau mà nhân viên phải đối chiếu thủ công hàng ngày.

Ví dụ giả định: cổng thông tin có nhà phát triển không còn sẵn sàng

Hãy xem xét một nhà phân phối giả định có cổng thông tin khách hàng vẫn chấp nhận đơn đặt hàng nhưng nhà phát triển ban đầu của họ không có mặt. Doanh nghiệp có quyền truy cập kho lưu trữ và lưu trữ hóa đơn, nhưng không ai có thể chứng minh bản phát hành. Đây là tình huống minh họa, không phải kết quả của khách hàng Mecanik hay bằng chứng về thời gian tiếp quản điển hình.

Đánh giá đầu tiên sẽ bảo tồn hệ thống đang chạy, xác nhận quyền truy cập của công ty và tái tạo bản dựng trong giai đoạn chạy thử. Nhân viên chứng minh một đơn hàng bình thường, một đơn hàng bị hủy và một tài khoản có quyền hạn chế. Cuộc điều tra cho thấy một chuyến xuất khẩu theo lịch trình không có giấy tờ gửi đơn đặt hàng đến nhà kho. Quá trình đó phải được đưa vào sự chấp nhận, mặc dù nó không được khách hàng nhìn thấy.

Bước tiếp theo được đề xuất là công việc liên tục: ghi lại quá trình xuất, thêm khả năng hiển thị lỗi cũng như diễn tập triển khai và khôi phục. Một thiết kế lại được yêu cầu được định giá riêng. Quyết định trở nên rõ ràng hơn vì doanh nghiệp có thể phân biệt công việc cần thiết để tiếp tục nhận đơn đặt hàng với công việc nhằm mục đích cải thiện ngoại hình. Việc viết lại có thể vẫn xảy ra sau đó, với bằng chứng tốt hơn về những gì nó phải bảo tồn.

Lập kế hoạch cho thay đổi đầu tiên có kiểm soát

Khi có bằng chứng về quyền truy cập và vận hành thiết yếu, hãy chọn một thay đổi đủ nhỏ để quan sát và đảo ngược. Nó phải giải quyết một nhu cầu thực sự trong khi thực hiện quá trình phát hành. Một thay đổi bề ngoài không bao giờ ảnh hưởng đến một quy trình làm việc quan trọng có thể là quá ít, trong khi việc di chuyển dữ liệu lớn sẽ tạo ra sự hiển thị không cần thiết cho lần phát hành đầu tiên.

Mô tả hành vi mong đợi trước khi bắt đầu phát triển. Xác định những người dùng sẽ xác minh nó, các tín hiệu hoạt động cần theo dõi và các điều kiện kích hoạt khôi phục. Diễn tập các bước liên quan trong quá trình dàn dựng và ghi lại những khác biệt trong quá trình sản xuất. Lên lịch phát hành với chủ sở hữu, người có thể đưa ra quyết định tiếp tục hoặc phục hồi.

Sau khi triển khai, hãy xác minh kết quả kinh doanh cũng như tình trạng kỹ thuật. Máy chủ có thể phản hồi bình thường trong khi quá trình xuất âm thầm dừng lại. Ghi lại những gì đã xảy ra và cập nhật sổ ghi chép khi các chi tiết vẫn còn mới. Thay đổi được kiểm soát thành công đầu tiên là bằng chứng hữu ích cho thấy quá trình chuyển giao có hiệu quả, nhưng nó không kết thúc mọi phát hiện đánh giá nổi bật.

Hợp tác với nhà cung cấp phát triển cũ

Yêu cầu một chương trình bàn giao cụ thể thay vì yêu cầu mơ hồ “gửi mọi thứ”. Chia sẻ ranh giới ứng dụng, yêu cầu truy cập và trình diễn trước. Sử dụng các phiên để nắm bắt các quyết định, các vấn đề hoạt động và các câu hỏi chưa được giải quyết. Các bản ghi có thể hữu ích nếu được đồng ý, nhưng sổ ghi chép có thể tìm kiếm sẽ dễ duy trì hơn khi hệ thống thay đổi.

Giữ các cuộc thảo luận thực tế khi mối quan hệ với nhà cung cấp trở nên căng thẳng. Phân biệt bằng chứng không có sẵn với các khiếm khuyết đã được xác nhận. Hướng dẫn bị thiếu có thể được phục hồi trong một phiên ngắn, trong khi sự cố bị nghi ngờ có thể yêu cầu kiểm tra trước khi nó trở thành nhiệm vụ khắc phục. Chỉ định chủ sở hữu và các hành động tiếp theo thay vì để lại những tuyên bố mơ hồ trong ghi chú cuộc họp.

Đừng làm cho tính liên tục phụ thuộc vô thời hạn vào việc trả lời các câu hỏi của nhóm sắp ra đi. Đồng ý sắp xếp chuyển tiếp có giới hạn nếu có thể, sau đó xác minh rằng nhóm mới đến có thể hoàn thành các nhiệm vụ thiết yếu một cách độc lập. Nếu không có sự hợp tác, hãy phản ánh hạn chế đó trong phạm vi và ước tính đánh giá. Nó thay đổi nỗ lực phục hồi chứ không phải tiêu chuẩn bằng chứng cần thiết để được chấp nhận.

Đặt dịch vụ tiếp quản nhằm duy trì hoạt động kinh doanh

Chuẩn bị một bản tóm tắt ngắn gọn về mục đích của ứng dụng, vấn đề hiện tại, quyền truy cập đã biết, quy trình công việc quan trọng và thay đổi mong muốn tiếp theo. Cung cấp các ghi chú kiến ​​trúc có sẵn và các ví dụ ẩn danh thông qua một kênh đã được thống nhất. Xác định nhân viên có thể giải thích các trường hợp ngoại lệ và phê duyệt chấp nhận. Những thông tin đầu vào này giúp nhà cung cấp đánh giá phạm vi mà không yêu cầu bạn hiểu mọi thành phần kỹ thuật.

Dịch vụ phát triển phần mềm của Mecanik có thể giúp đánh giá ứng dụng kế thừa và xác định lộ trình được kiểm soát để bảo trì hoặc phát triển thêm. Yêu cầu đánh giá với các kết quả phân phối rõ ràng bao gồm quyền truy cập, bản dựng, hành vi và hoạt động. Yêu cầu một đề xuất GBP có phạm vi tách biệt việc thu thập bằng chứng, công việc khẩn cấp liên tục và các cải tiến tùy chọn.

Kết quả hữu ích là một hệ thống mà doanh nghiệp có thể vận hành và thay đổi với sự hỗ trợ có trách nhiệm. Hãy coi việc tiếp quản như một chuỗi các khả năng đã được chứng minh, với những rủi ro chưa được giải quyết có thể nhìn thấy được ở mỗi quyết định. Điều đó mang lại cho nhà cung cấp tiếp theo một trách nhiệm thực tế và mang lại cho bạn cơ sở chi tiêu rõ ràng hơn so với việc xem xét mã đảm bảo hoặc lời hứa viết lại ngay lập tức.

Câu hỏi thường gặp

Nhà phát triển mới có thể tiếp quản mà không cần sự trợ giúp của nhà phát triển ban đầu không? Thường thì điều đó là có thể, nhưng việc thiếu quyền truy cập, hướng dẫn xây dựng và kiến thức vận hành sẽ làm tăng tính không chắc chắn. Bắt đầu bằng một đánh giá có giới hạn nhằm bảo tồn hệ thống hiện tại và xác định bằng chứng có thể phục hồi được. Đừng hứa hẹn ngày giao hàng trước khi nhóm mới hiểu được những phụ thuộc thiết yếu.

Việc chuyển kho lưu trữ có loại bỏ quyền truy cập của nhà cung cấp trước đó không? Đừng cho rằng nó có. Xem xét cộng tác viên, quyền của tổ chức, thông tin xác thực triển khai và các dịch vụ được kết nối sau khi chuyển. Các tài liệu GitHub liên quan đến các bí mật và khóa triển khai vẫn nằm trong kho lưu trữ được chuyển giao, do đó, việc xem xét thông tin xác thực và quyền truy cập là các nhiệm vụ chuyển giao riêng biệt.

Chúng ta có nên viết lại ứng dụng trong thời gian tiếp quản không? Chỉ khi đánh giá hỗ trợ quyết định đó. Ổn định việc phân phối hoặc thay thế một bộ phận hạn chế có thể giải quyết vấn đề cấp bách với ít gián đoạn hơn. Việc viết lại vẫn yêu cầu hiểu các quy tắc kinh doanh, di chuyển dữ liệu và duy trì sự tích hợp, do đó, việc viết lại cần có phạm vi đánh giá riêng.

Điều gì quyết định chi phí tiếp quản dự án phần mềm? Khả năng sẵn sàng truy cập, khả năng tái tạo bản dựng, quy trình công việc quan trọng, hoạt động tích hợp, phạm vi bảo mật và các yêu cầu khôi phục định hình nỗ lực. Yêu cầu báo giá đánh giá GBP trong phạm vi, sau đó tách biệt công việc khẩn cấp liên tục khỏi các cải tiến. So sánh các kết quả và giả định thay vì coi mọi đánh giá mã là cùng một dịch vụ.

Làm sao chúng ta biết việc bàn giao đã hoàn tất? Đồng ý trước các bản trình diễn chấp nhận: quyền truy cập được xem xét, bản dựng rõ ràng, triển khai có kiểm soát, kiểm tra quy trình làm việc quan trọng và diễn tập khôi phục nếu cần. Đặt tên cho chủ sở hữu hoạt động và ghi lại những phát hiện chưa được giải quyết. Hoàn thành có nghĩa là nhóm đến có thể thực hiện các trách nhiệm đã thỏa thuận với bằng chứng chứ không chỉ đơn thuần là các hồ sơ đã được đổi chủ.