Thẩm định kỹ thuật không phải một cuộc thi về chất lượng mã nguồn, và các đội chuẩn bị cho nó thường dồn thời gian vào đúng thứ không cần thiết. Không ai đi mua một công ty để chấm điểm các tầng trừu tượng của bạn. Bên mua đang cố tính ra chi phí sở hữu hệ thống này, và mức độ tệ hại có thể xảy ra sau khi tiền đã đổi chủ.

Cách đặt lại vấn đề này quan trọng, vì nó thay đổi thứ bạn nên sửa trước. Mã nguồn xấu nhưng chạy được, cả đội đều hiểu và có thể sửa an toàn chỉ là một phát hiện nhỏ. Mã nguồn thanh lịch mà chỉ một người hiểu mới là phát hiện nghiêm trọng, và chính trường hợp thứ hai làm dịch chuyển mức giá.

Câu hỏi nằm sau mọi câu hỏi: nếu kỹ sư sáng lập nghỉ việc ngay tuần sau khi hoàn tất giao dịch, hệ thống này có tiếp tục chạy và tiếp tục thay đổi được không? Gần như mọi phát hiện làm giảm giá chào mua đều là một câu trả lời cụ thể cho điều đó. Kiến thức dồn vào một người, quy trình triển khai không có tài liệu, giấy phép chưa ai kiểm tra, thông tin đăng nhập chỉ nằm trong trí nhớ của một cá nhân.

Thẩm định kỹ thuật thực chất đánh giá điều gì

Bốn nhóm rủi ro, xếp gần đúng theo mức ảnh hưởng tới định giá.

Rủi ro phụ thuộc nhân sự chủ chốt. Hệ thống dựa vào từng cá nhân hay dựa vào quy trình đã ghi chép. Đây luôn là phát hiện gây thiệt hại nhất, vì khắc phục về sau khó nhất và vì nó đe dọa trực tiếp thứ đang được mua.

Chi phí duy trì tiếp. Những gì cần để hệ thống tiếp tục chạy và tiếp tục phát triển: chi phí hạ tầng, nghĩa vụ giấy phép, quy mô đội ngũ cần thiết, và bao nhiêu phần lộ trình sản phẩm sẽ bị bảo trì ăn mất thay vì dành cho việc mới.

Trách nhiệm pháp lý. Giấy phép xung đột với mục đích thương mại, dữ liệu cá nhân được xử lý theo cách không trụ nổi trước một khiếu nại, lỗ hổng bảo mật, và mọi nghĩa vụ pháp lý mà công ty thực tế chưa đáp ứng.

Khả năng thay đổi. Tính năng mới có ra được đều đặn theo nhịp dự đoán được không, hay mỗi thay đổi đều mang rủi ro làm hỏng một thứ chẳng liên quan.

Chất lượng mã nguồn chỉ có ý nghĩa qua điểm thứ tư, nên người rà soát dành ít thời gian đọc mã hơn nhiều so với kỳ vọng của nhà sáng lập, và dành nhiều thời gian hơn để hỏi quy trình triển khai diễn ra thế nào.

Những phát hiện làm giảm giá

Chỉ một người biết triển khai. Quy trình phát hành nằm trong đầu một người, hoặc trên máy của họ, luôn bị coi là rủi ro vận hành nghiêm trọng, dù hôm nay nó chạy tốt đến đâu.

Không có kiểm thử trên các luồng quan trọng. Không phải tỷ lệ bao phủ, thứ người rà soát phần lớn bỏ qua, mà là hệ thống có sửa được với chút tự tin nào không. Mã nguồn thiếu kiểm thử quanh luồng doanh thu sẽ bị tính vào giá một lộ trình chậm hơn. Hướng dẫn về chiến lược kiểm thử phần mềm của chúng tôi chỉ ra thứ gì thực sự xứng đáng.

Nhiễm giấy phép. Mã copyleft trong sản phẩm độc quyền là một trong số ít phát hiện chặn đứng được giao dịch chứ không chỉ định giá lại, và công cụ quét thường tìm ra sau vài phút.

Dữ liệu cá nhân không có cơ sở bảo vệ được. Dữ liệu thu thập không có cơ sở pháp lý rõ ràng, lưu vô thời hạn, hoặc để ở nơi công ty không liệt kê nổi. Cơ chế trong bài tuân thủ GDPR về mặt kỹ thuật chính là thứ bên rà soát kiểm tra.

Phụ thuộc không tài liệu vào cá nhân hoặc nhà cung cấp. Một tích hợp trọng yếu với nhà cung cấp không hợp đồng, hoặc hạ tầng trong tài khoản cá nhân, đều bị đọc là rủi ro chưa quản lý.

Thiếu nền tảng bảo mật. Không phải kết quả kiểm thử xâm nhập, mà là khóa bí mật có nằm trong hệ thống quản lý phiên bản không, quyền truy cập có bị thu hồi khi người ta nghỉ không, và hiện có gì chưa vá mà vẫn mở ra Internet không.

Điều người rà soát không quan tâm

Điều này đáng nói ra, vì thời gian chuẩn bị có hạn và thường bị tiêu sai chỗ.

Họ không quan tâm bạn chọn framework nào, miễn là tuyển được người làm. Họ không quan tâm tới trào lưu kiến trúc: một hệ thống nguyên khối vẫn ra được sản phẩm thì không phải phát hiện. Họ không quan tâm phong cách viết mã, cách đặt tên, hay việc thiếu một mẫu thiết kế mà ai đó trên mạng khuyên dùng.

Họ cũng không kỳ vọng nợ kỹ thuật bằng không. Công ty nào cũng có, và sự tồn tại của nó là bình thường. Điều quan trọng là đội ngũ có biết nó nằm ở đâu và mô tả được cái giá của nó hay không. Một đội đưa ra danh sách rõ ràng các vấn đề của chính mình được đọc là có năng lực. Một đội khẳng định không có vấn đề nào bị đọc là thiếu nhận thức, và người rà soát khi đó phải tự tìm, việc này lâu hơn và cho ra bản báo cáo tệ hơn.

Chuẩn bị mà không viết lại thứ gì

Phần lớn những việc có ích chỉ tốn vài ngày chứ không phải vài tháng, và không việc nào đụng tới kiến trúc.

Viết ra cách triển khai. Từ một máy trống cho tới hệ thống đang chạy. Riêng tài liệu này đã xử lý nhóm phát hiện gây thiệt hại nhất, và có thể viết xong trong một buổi chiều.

Liệt kê các phụ thuộc và giấy phép của chúng. Công cụ tự động dựng danh sách này rất nhanh, và biết câu trả lời trước người rà soát còn giá trị hơn nhiều so với một kết quả sạch.

Đưa khóa bí mật ra khỏi hệ thống quản lý phiên bản và kiểm kê ai đang có quyền với cái gì. Sau đó thu hồi quyền của tất cả những người đã nghỉ.

Ghi lại những thứ bạn biết là sai. Một sổ đăng ký ngắn gọn và trung thực về các vấn đề đã biết, kèm chi phí khắc phục ước lượng. Chủ động đưa ra tài liệu này là một trong số ít việc cải thiện được giọng điệu của bản rà soát.

Bảo đảm hạ tầng thuộc sở hữu công ty, không phải tài khoản cá nhân, và tên miền, chứng chỉ, kho mã nguồn đều nằm dưới quyền kiểm soát của doanh nghiệp.

Các phát hiện sẽ đi về đâu

Chúng hiếm khi giết chết một thương vụ. Chúng trở thành điều kiện.

Phát hiện thường kết thúc ở một trong ba hướng: điều chỉnh giá phản ánh chi phí khắc phục, một điều khoản bảo đảm hoặc bồi thường trong hợp đồng, hoặc một điều kiện phải hoàn thành trước khi hoàn tất giao dịch. Chỉ có nhiễm giấy phép và rủi ro bảo vệ dữ liệu nghiêm trọng chưa xử lý mới thường xuyên chặn đứng hẳn giao dịch.

Nghĩa là mục tiêu thực tế không phải một hệ thống hoàn hảo. Đó là hệ thống mà các vấn đề của nó đã được biết, được giới hạn và mô tả được, vì vấn đề đã lượng hóa thì được đưa vào giá, còn vấn đề chưa lượng hóa thì bị mặc định là tệ hơn thực tế.

Mecanik thực hiện các đợt rà soát kỹ thuật kiểu này như một phần công việc phát triển phần mềm , thường là đứng về phía bên mua. Quy luật khá ổn định: hệ thống qua được rà soát không phải hệ thống tinh vi, mà là hệ thống có người chịu ghi chép lại mọi thứ.

Bài viết liên quan: Software escrow: ai thực sự cần đến nó , Phát triển phần mềm fintech tại Anh: FCA, rails và chi phí , Hợp đồng trọn gói hay tính theo thời gian và vật tư? và Phát triển phần mềm theo yêu cầu tại Anh: cẩm nang đầy đủ cho bên mua .

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

Thẩm định kỹ thuật là gì? Là việc đánh giá chi phí sở hữu một hệ thống phần mềm và mức độ tệ hại có thể xảy ra sau một thương vụ mua lại hoặc một khoản đầu tư. Nó xem xét rủi ro phụ thuộc nhân sự chủ chốt, chi phí duy trì tiếp, trách nhiệm pháp lý và khả năng tiếp tục thay đổi hệ thống, chứ không chấm điểm chất lượng mã nguồn vì bản thân nó.

Phát hiện nào làm giảm giá nhiều nhất? Kiến thức dồn vào từng cá nhân, đặc biệt là quy trình triển khai chỉ một người thực hiện được. Sau đó là: không có kiểm thử đáng kể trên các luồng tạo doanh thu, nhiễm giấy phép do mã copyleft nằm trong sản phẩm độc quyền, dữ liệu cá nhân không có cơ sở pháp lý bảo vệ được, và khóa bí mật bị commit vào hệ thống quản lý phiên bản.

Người rà soát có quan tâm nợ kỹ thuật của tôi không? Họ mặc định là có nợ. Công ty nào cũng có và sự tồn tại của nó không phải một phát hiện. Điều quan trọng là đội ngũ có biết nó nằm ở đâu và mô tả được chi phí khắc phục hay không. Một sổ đăng ký rõ ràng các vấn đề đã biết được đọc là năng lực; khẳng định không có vấn đề nào bị đọc là thiếu nhận thức và làm bản rà soát xấu đi.

Tôi chuẩn bị cho thẩm định kỹ thuật thế nào? Viết ra cách đưa hệ thống chạy từ một máy trống, liệt kê các phụ thuộc và giấy phép, gỡ khóa bí mật khỏi hệ thống quản lý phiên bản, rà lại xem ai còn quyền truy cập, xác nhận hạ tầng và tên miền thuộc về công ty chứ không phải cá nhân, và lập một sổ đăng ký trung thực các vấn đề đã biết kèm chi phí khắc phục ước lượng.

Một phát hiện kỹ thuật có thể chặn đứng hẳn thương vụ không? Hiếm khi. Phần lớn phát hiện trở thành điều chỉnh giá, điều khoản bảo đảm trong hợp đồng, hoặc điều kiện phải thỏa mãn trước khi hoàn tất giao dịch. Các ngoại lệ thực sự chặn được giao dịch là nhiễm giấy phép copyleft bên trong một sản phẩm độc quyền và rủi ro bảo vệ dữ liệu nghiêm trọng chưa được xử lý.