Cách sử dụng proof of concept công nghệ

Giá trị của PoC không nằm ở việc tạo ra một phiên bản thu nhỏ của hệ thống hoàn chỉnh. Giá trị chính là giảm bất định trước khi tổ chức cam kết nguồn lực lớn hơn. Một PoC tốt phải tạo ra dữ liệu đủ rõ để dẫn đến quyết định: tiếp tục, điều chỉnh giả thuyết, thử thêm một vấn đề còn chưa chắc chắn hoặc dừng công nghệ đang được xem xét.

Proof of Concept được sử dụng như một phép kiểm chứng trong đánh giá công nghệ

Khi đánh giá một công nghệ mới, nhiều thông tin ban đầu mới chỉ thể hiện khả năng được tuyên bố. Tài liệu kỹ thuật có thể cho biết sản phẩm hỗ trợ một giao thức, đạt một mức hiệu năng nhất định hoặc tích hợp với một nền tảng cụ thể, nhưng chưa chứng minh rằng các đặc tính đó vẫn phù hợp với dữ liệu, kiến trúc và điều kiện vận hành của tổ chức.

PoC chuyển các nhận định này thành những giả thuyết có thể kiểm tra. Chẳng hạn, thay vì đặt câu hỏi chung chung như “công nghệ này có nhanh không?”, nhóm đánh giá có thể kiểm tra:

·         Có xử lý được khối lượng giao dịch dự kiến hay không

·         Độ trễ có nằm trong ngưỡng chấp nhận hay không

·         Có tương thích với hệ thống hiện hữu hay không

·         Có duy trì được chức năng cần thiết khi tải tăng hay không

·         Quy trình tích hợp, cấu hình và vận hành có tạo ra trở ngại nghiêm trọng hay không

·         Các cơ chế bảo mật bắt buộc có hoạt động trong kiến trúc dự kiến hay không

Như vậy, PoC đóng vai trò như một công cụ tạo bằng chứng cho quyết định công nghệ. Nó không chứng minh rằng toàn bộ dự án chắc chắn thành công; nó kiểm chứng những điều kiện kỹ thuật quan trọng nhất mà quyết định triển khai đang phụ thuộc vào.

Điểm này đặc biệt quan trọng khi hai hoặc nhiều công nghệ đều đáp ứng yêu cầu trên giấy. Một thử nghiệm được thiết kế với cùng dữ liệu, cùng khối lượng công việc và cùng tiêu chí đo lường có thể làm lộ ra khác biệt về hiệu năng, khả năng tích hợp hoặc độ phức tạp vận hành mà tài liệu sản phẩm không thể hiện đầy đủ.

Bắt đầu PoC bằng giả thuyết và tiêu chí thành công có thể đo lường

Một PoC khó tạo giá trị nếu mục tiêu chỉ là “thử xem công nghệ có tốt không”. Trước khi thử nghiệm, nhóm đánh giá cần chuyển vấn đề cần xác minh thành một hoặc một số giả thuyết rõ ràng.

Ví dụ, giả thuyết có thể là: công nghệ A có thể xử lý tải nghiệp vụ dự kiến với độ trễ nằm dưới ngưỡng mà ứng dụng cho phép, đồng thời vẫn kết nối được với cơ chế xác thực và nguồn dữ liệu hiện có.

Từ giả thuyết đó, tiêu chí thành công phải được xác định trước khi có kết quả thử nghiệm. Nếu tiêu chí chỉ được đặt ra sau khi nhìn thấy kết quả, nhóm đánh giá rất dễ lựa chọn những số liệu thuận lợi và bỏ qua điểm yếu.

Tiêu chí chức năng

Nhóm đánh giá cần xác định những chức năng bắt buộc phải hoạt động trong PoC. Chỉ nên đưa vào các chức năng có ảnh hưởng trực tiếp đến quyết định công nghệ, thay vì cố tái tạo toàn bộ sản phẩm tương lai.

Ví dụ:

·         Đọc và ghi đúng loại dữ liệu cần thiết

·         Thực hiện được luồng xử lý cốt lõi

·         Hỗ trợ giao thức hoặc API bắt buộc

·         Thực hiện được cơ chế xác thực cần dùng

·         Xử lý đúng một số tình huống lỗi quan trọng

Tiêu chí phi chức năng

Đây thường là khu vực tạo Information Gain lớn nhất trong PoC vì nhiều rủi ro công nghệ chỉ xuất hiện khi hệ thống thực sự chạy.

Các tiêu chí có thể bao gồm:

·         Độ trễ

·         Throughput

·         Mức sử dụng CPU và bộ nhớ

·         Thời gian phục hồi sau lỗi

·         Khả năng xử lý tải đồng thời

·         Độ ổn định trong thời gian thử nghiệm

·         Khả năng mở rộng khi khối lượng công việc tăng

Không có một ngưỡng hiệu năng chung áp dụng cho mọi PoC. Ngưỡng phải xuất phát từ yêu cầu của hệ thống đang được đánh giá. Nếu ứng dụng yêu cầu phản hồi dưới 300 ms ở tải dự kiến, tiêu chí PoC cần sử dụng chính ngưỡng đó thay vì kết luận định tính rằng hệ thống “phản hồi nhanh”.

Tiêu chí tích hợp và vận hành

Một công nghệ có thể đạt benchmark trong môi trường độc lập nhưng trở nên khó triển khai khi đặt vào kiến trúc thực tế. Vì vậy, PoC cần kiểm tra những dependency có khả năng làm thay đổi quyết định.

Có thể xem xét:

·         Mức độ phức tạp khi kết nối với hệ thống hiện hữu

·         Yêu cầu thay đổi kiến trúc

·         Khả năng quan sát log, metric và lỗi

·         Cách triển khai cấu hình

·         Dependency đối với nền tảng hoặc dịch vụ khác

·         Những thao tác thủ công cần thiết để vận hành

Mục tiêu không phải đo mọi thứ có thể đo. Mỗi metric phải gắn với một giả thuyết hoặc một rủi ro cần xác minh.

Thực hiện PoC trong điều kiện đủ gần với bài toán thực tế

PoC cần được giới hạn để giữ chi phí thử nghiệm thấp, nhưng giới hạn quá mức có thể khiến kết quả mất giá trị. Nếu một công nghệ sẽ phải xử lý hàng triệu bản ghi nhưng PoC chỉ sử dụng vài trăm bản ghi đơn giản, thử nghiệm có thể xác nhận chức năng mà không kiểm tra được vấn đề thực sự quan trọng.

Môi trường PoC vì vậy cần đại diện cho những yếu tố có khả năng ảnh hưởng đến kết luận, chẳng hạn dữ liệu, tải, kiểu truy cập, dependency hoặc giới hạn hạ tầng.

Quy trình thực hiện có thể đi theo bốn bước:

1.    Xác định bất định cần giảm: Chọn những vấn đề chưa thể giải quyết đáng tin cậy chỉ bằng tài liệu hoặc phân tích lý thuyết

2.    Thiết kế phép thử: Xác định dữ liệu đầu vào, workload, điều kiện môi trường, metric và ngưỡng pass/fail

3.    Thực thi và ghi nhận kết quả: Lưu cả kết quả đạt và không đạt, bao gồm lỗi, cách cấu hình và điều kiện thử nghiệm

4.    Đối chiếu với tiêu chí đã đặt trước: Đánh giá kết quả theo yêu cầu ban đầu thay vì theo cảm nhận của nhóm thực hiện

Trong trường hợp so sánh nhiều công nghệ, điều kiện thử càng cần được chuẩn hóa. Nếu công nghệ A được chạy trên cấu hình mạnh hơn công nghệ B, hoặc mỗi giải pháp sử dụng tập dữ liệu khác nhau, kết quả không còn là bằng chứng so sánh đáng tin cậy.

Tương tự, một benchmark duy nhất cũng không nên được dùng để đại diện cho toàn bộ tính khả thi. Hiệu năng cao không bù được cho việc thiếu một cơ chế tích hợp bắt buộc; khả năng tích hợp tốt cũng không đủ nếu hệ thống không đáp ứng tải tối thiểu. PoC cần kiểm tra đúng tập hợp các điều kiện mà quyết định triển khai phụ thuộc vào.

Dùng kết quả PoC để đưa ra quyết định triển khai thay vì chỉ xác nhận công nghệ hoạt động

Kết quả PoC nên được chuyển thành một decision record rõ ràng. Câu hỏi cuối cùng không phải “demo đã chạy được chưa?” mà là “các giả thuyết quan trọng đã được chứng minh đến mức nào?”.

Một cách đánh giá thực tế là phân loại từng tiêu chí thành:

·         Đạt: Kết quả đáp ứng ngưỡng đã xác định

·         Đạt có điều kiện: Có thể đáp ứng nhưng cần thay đổi cấu hình, kiến trúc hoặc quy trình

·         Chưa xác định: Dữ liệu thử nghiệm chưa đủ để đưa ra kết luận

·         Không đạt: Kết quả không đáp ứng yêu cầu bắt buộc

Cách phân loại này giúp tránh một sai lầm phổ biến: coi PoC là thành công chỉ vì nhóm kỹ thuật đã làm cho một chức năng chạy được. Nếu để đạt kết quả đó phải sử dụng workaround khó duy trì, thay đổi một dependency quan trọng hoặc chấp nhận mức tài nguyên vượt giới hạn, điều kiện này phải trở thành một phần của kết luận.

Sau PoC, tổ chức thường có bốn hướng quyết định hợp lý:

·         Tiếp tục sang pilot hoặc giai đoạn triển khai khi các bất định quan trọng đã được giảm đủ

·         Tiếp tục có điều kiện và xử lý những hạn chế đã xác định

·         Thực hiện thêm một thử nghiệm hẹp đối với vấn đề còn chưa có bằng chứng

·         Dừng giải pháp khi một yêu cầu bắt buộc không thể đáp ứng

Một kết quả “không đạt” vì thế không đồng nghĩa PoC thất bại. Nếu thử nghiệm phát hiện sớm rằng một công nghệ không phù hợp trước khi tổ chức đầu tư lớn vào tích hợp, migration hoặc vận hành, PoC đã hoàn thành đúng chức năng quản trị rủi ro của nó.

PoC không thay thế pilot, MVP hoặc đánh giá production

Giới hạn quan trọng nhất của Proof of Concept là phạm vi thử nghiệm. PoC chủ yếu trả lời “ý tưởng hoặc công nghệ này có khả thi đối với những giả thuyết đang kiểm tra hay không?”. Nó không tự động chứng minh rằng giải pháp đã sẵn sàng cho môi trường production.

PoC thường có phạm vi hẹp hơn pilot. Pilot đưa giải pháp vào một nhóm người dùng, quy trình hoặc môi trường gần thực tế hơn để đánh giá cách hệ thống vận hành trong điều kiện sử dụng thực. Trong khi đó, MVP tập trung vào việc tạo một phiên bản sản phẩm có giá trị sử dụng tối thiểu để kiểm chứng nhu cầu và phản hồi của người dùng. Ba khái niệm có thể liên tiếp xuất hiện trong một sáng kiến công nghệ nhưng chúng giải quyết những loại bất định khác nhau.

Một PoC cũng có thể bỏ sót các vấn đề chỉ xuất hiện ở quy mô lớn hoặc trong thời gian dài, chẳng hạn:

·         Hành vi dưới tải kéo dài

·         Tăng trưởng dữ liệu

·         Quy trình backup và recovery đầy đủ

·         Nâng cấp phiên bản

·         Khả năng vận hành bởi đội ngũ thực tế

·         Chi phí dài hạn

·         Failure mode hiếm gặp

·         Những yêu cầu bảo mật hoặc tuân thủ chưa được đưa vào phạm vi thử

Do đó, kết luận đúng sau một PoC đạt yêu cầu là có đủ bằng chứng để tiến sang bước kiểm chứng tiếp theo, chứ không phải “công nghệ đã được chứng minh hoàn toàn”.

Một PoC có giá trị khi tập trung vào rủi ro quyết định thay vì số lượng tính năng

PoC dễ trở nên tốn kém khi nhóm thực hiện cố xây dựng quá nhiều tính năng. Việc này vừa kéo dài thử nghiệm, vừa làm mờ câu hỏi ban đầu.

Một cách ưu tiên hiệu quả là xem xét từng giả thuyết theo hai yếu tố: mức độ bất định và mức độ ảnh hưởng đến quyết định. Những vấn đề vừa chưa chắc chắn vừa có khả năng khiến dự án phải dừng hoặc thay đổi kiến trúc nên được kiểm tra trước.

Ví dụ, nếu tài liệu đã xác nhận chắc chắn một API chuẩn được hỗ trợ, việc dành phần lớn PoC để kiểm tra API đó có thể tạo ít giá trị. Ngược lại, nếu chưa biết hệ thống có giữ được độ trễ mục tiêu khi sử dụng dữ liệu thật và cơ chế xác thực hiện tại hay không, phép thử này có giá trị quyết định cao hơn.

Trước khi kết thúc PoC, nhóm đánh giá nên có khả năng trả lời rõ:

·         Giả thuyết nào đã được kiểm chứng

·         Bằng chứng nào hỗ trợ kết luận

·         Tiêu chí nào không đạt

·         Kết quả phụ thuộc vào điều kiện nào

·         Rủi ro nào vẫn chưa được giải quyết

·         Bước tiếp theo có hợp lý về mặt kỹ thuật hay không

Nếu những câu hỏi này chưa có câu trả lời, việc “chạy được một demo” chưa đủ để coi PoC đã hoàn thành nhiệm vụ đánh giá công nghệ.

Proof of Concept giúp đánh giá công nghệ bằng cách biến những giả định quan trọng thành phép thử có thể quan sát và đo lường. Quy trình hiệu quả bắt đầu từ bất định cần giảm, xác định tiêu chí thành công trước khi thử, thực hiện trong điều kiện đủ đại diện và đối chiếu kết quả với yêu cầu ban đầu.

Điểm quan trọng là không sử dụng PoC như một thủ tục để hợp thức hóa lựa chọn đã có sẵn. PoC có giá trị nhất khi cả kết quả đạt lẫn không đạt đều có thể làm thay đổi quyết định. Khi được thiết kế theo nguyên tắc đó, proof of concept công nghệ trở thành cơ chế kiểm soát rủi ro trước khi tổ chức chuyển sang pilot, đầu tư tích hợp sâu hoặc triển khai ở quy mô lớn.