Vai trò của proof of concept trong thiết kế giải pháp

Giá trị chính của PoC nằm ở việc chuyển một giả định kỹ thuật thành kết quả có thể kiểm tra. Thay vì chỉ đánh giá trên bản vẽ, tài liệu hoặc nhận định của nhóm thiết kế, đội ngũ có thể xây dựng một mô hình thử nghiệm tối thiểu, đo các chỉ tiêu liên quan và dùng kết quả đó để tiếp tục, điều chỉnh hoặc loại bỏ phương án

Proof of concept giải pháp kiểm chứng điều gì trong quá trình thiết kế

PoC có giá trị nhất khi phương án còn tồn tại uncertainty ở một điểm kỹ thuật quan trọng. Đó có thể là khả năng tích hợp giữa các thành phần, khả năng đáp ứng hiệu năng, tính tương thích, khả năng xử lý một điều kiện vận hành đặc biệt hoặc khả năng thực hiện một cơ chế chưa được chứng minh

Một PoC có thể tập trung kiểm chứng:

·         Một cơ chế kỹ thuật có thực sự hoạt động như giả định hay không

·         Hai hệ thống hoặc thành phần có thể tích hợp với nhau hay không

·         Kiến trúc dự kiến có đáp ứng yêu cầu hiệu năng hay không

·         Công nghệ được chọn có xử lý được điều kiện hoặc tải dự kiến hay không

·         Một yêu cầu kỹ thuật có thể đạt được bằng phương án đang thiết kế hay không

·         Một rủi ro kỹ thuật có thể được kiểm soát bằng biện pháp đề xuất hay không

Điểm quan trọng là PoC không nên kiểm chứng mọi thứ cùng lúc. Nếu một phương án có 10 thành phần nhưng chỉ có 2 giả định mang tính quyết định, PoC nên tập trung vào 2 giả định đó. Như vậy kết quả thử nghiệm có giá trị trực tiếp hơn đối với quyết định thiết kế

PoC giúp giảm rủi ro thiết kế bằng cách nào

Rủi ro lớn của thiết kế phương án là một giả định chưa được kiểm chứng có thể chỉ bộc lộ khi hệ thống đã được triển khai. Khi đó chi phí sửa đổi thường cao hơn nhiều so với lúc phương án còn ở giai đoạn thiết kế

PoC đưa hoạt động kiểm chứng lên sớm hơn trong chuỗi quyết định:

Giả định kỹ thuật → Thiết kế thử nghiệm tối thiểu → Đo lường → Đánh giá → Điều chỉnh phương án

Cách tiếp cận này giúp phát hiện sớm những vấn đề như:

·         Cơ chế hoạt động khác với dự kiến

·         Hiệu năng không đạt yêu cầu

·         Hai thành phần không tương thích

·         Điều kiện vận hành thực tế làm thay đổi kết quả

·         Một yêu cầu phụ tạo ra ràng buộc mới cho kiến trúc

·         Phương án chỉ khả thi về mặt lý thuyết nhưng khó triển khai thực tế

Giá trị của PoC vì vậy không chỉ nằm ở trường hợp chứng minh phương án hoạt động. Một kết quả cho thấy phương án không đạt cũng có giá trị nếu nó được phát hiện trước khi tổ chức đầu tư lớn vào thiết kế và triển khai

Thiết kế PoC cần dựa trên tiêu chí đo lường nào

Một PoC có giá trị ra quyết định phải được thiết kế với tiêu chí thành công có thể kiểm chứng. Không nên chỉ kết luận rằng giải pháp “hoạt động tốt”, “ổn định” hoặc “đạt yêu cầu” nếu không xác định cách đo

Tùy phương án, các chỉ tiêu có thể gồm:

·         Độ trễ

·         Throughput

·         Tỷ lệ lỗi

·         Độ chính xác

·         Mức sử dụng CPU hoặc bộ nhớ

·         Khả năng chịu tải

·         Thời gian phản hồi

·         Khả năng tương thích

·         Tỷ lệ hoàn thành một quy trình

·         Mức tiêu thụ tài nguyên

·         Khả năng phục hồi sau lỗi

Mỗi chỉ tiêu cần gắn với điều kiện thử nghiệm và ngưỡng đánh giá phù hợp. Không có một ngưỡng PoC thành công chung cho mọi giải pháp; ngưỡng phải xuất phát từ yêu cầu kỹ thuật mà phương án cần đáp ứng

Ví dụ, nếu PoC nhằm kiểm chứng một kiến trúc xử lý dữ liệu, câu hỏi không nên chỉ là “kiến trúc có chạy được không?”. Câu hỏi có giá trị hơn là liệu kiến trúc đó có đạt mức throughput, độ trễ và mức sử dụng tài nguyên cần thiết trong điều kiện thử nghiệm đã xác định hay không

PoC ảnh hưởng thế nào đến việc lựa chọn và điều chỉnh phương án

Kết quả PoC nên được xem như một đầu vào của quyết định thiết kế, không phải một bước thử nghiệm tách rời khỏi quá trình thiết kế

Có thể hình dung ba kết quả chính:

Đạt yêu cầu: giả định kỹ thuật quan trọng được xác nhận trong phạm vi thử nghiệm, phương án có thể tiếp tục sang bước thiết kế chi tiết hoặc kiểm chứng tiếp theo

Đạt một phần: cơ chế cốt lõi hoạt động nhưng xuất hiện giới hạn về hiệu năng, tích hợp, tài nguyên hoặc điều kiện vận hành. Khi đó phương án cần được điều chỉnh và có thể phải thực hiện PoC bổ sung

Không đạt: giả định quan trọng bị bác bỏ. Đây là tín hiệu để thay đổi kiến trúc, thay công nghệ hoặc loại bỏ phương án trước khi chi phí triển khai tăng cao

Do đó, PoC có thể tạo ra một decision gate giữa ý tưởng và đầu tư triển khai. Nó giúp nhóm thiết kế trả lời câu hỏi không chỉ “phương án này có thể làm được không?” mà còn “phương án này có đủ cơ sở để tiếp tục với các điều kiện đã đặt ra hay không?”

Khi nào proof of concept giải pháp thực sự cần thiết

PoC đặc biệt hữu ích khi tồn tại một hoặc nhiều yếu tố sau:

·         Công nghệ hoặc cơ chế chưa từng được sử dụng trong hệ thống hiện tại

·         Có điểm tích hợp giữa nhiều hệ thống chưa được kiểm chứng

·         Yêu cầu hiệu năng hoặc tải có nguy cơ trở thành điểm nghẽn

·         Phương án phụ thuộc vào một giả định kỹ thuật quan trọng

·         Chi phí triển khai đầy đủ tương đối lớn

·         Nếu thiết kế sai sẽ khó hoặc tốn kém để thay đổi về sau

·         Có nhiều phương án cạnh tranh và cần dữ liệu để lựa chọn

Ngược lại, không phải mọi phương án đều cần một PoC riêng. Nếu công nghệ, kiến trúc và các điều kiện kỹ thuật đã được kiểm chứng đầy đủ, việc tạo thêm PoC chỉ để “có bước thử nghiệm” có thể làm tăng thời gian mà không tạo thêm Information Gain đáng kể

Vì vậy, tiêu chí tốt nhất không phải là “có nên làm PoC hay không?” mà là “có giả định kỹ thuật nào đủ quan trọng để cần kiểm chứng trước khi tiếp tục đầu tư hay không?”

PoC khác gì prototype và sản phẩm thử nghiệm

PoC, prototype và MVP có thể cùng sử dụng mô hình thử nghiệm nhưng phục vụ các câu hỏi khác nhau

PoC tập trung vào tính khả thi của một giả định hoặc cơ chế quan trọng. Phạm vi thường nhỏ và ưu tiên tốc độ kiểm chứng

Prototype tập trung nhiều hơn vào cách giải pháp được hình thành hoặc vận hành, có thể dùng để kiểm tra kiến trúc, giao diện, quy trình hoặc trải nghiệm

MVP hướng tới một phiên bản tối thiểu có thể cung cấp giá trị thực tế cho người dùng hoặc thị trường, vì vậy yêu cầu về tính hoàn thiện và khả năng vận hành thường cao hơn PoC

Không nên dùng PoC như một cách gọi khác của sản phẩm thử nghiệm. Nếu mục tiêu thực tế là chứng minh sản phẩm có thể vận hành với người dùng, phạm vi công việc đã vượt khỏi câu hỏi thuần túy về tính khả thi kỹ thuật

Cách thiết kế một PoC có giá trị cho phương án kỹ thuật

Một PoC hiệu quả nên bắt đầu từ rủi ro hoặc giả định cần kiểm chứng, thay vì bắt đầu từ việc xây dựng càng nhiều chức năng càng tốt

Trình tự phù hợp là:

1.    Xác định giả định quan trọng: Điều gì trong phương án chưa chắc chắn và có thể ảnh hưởng đến quyết định thiết kế

2.    Đặt câu hỏi kiểm chứng: PoC cần trả lời chính xác câu hỏi kỹ thuật nào

3.    Xác định tiêu chí thành công: Chỉ tiêu nào cho phép kết luận đạt, không đạt hoặc đạt có điều kiện

4.    Giới hạn phạm vi thử nghiệm: Chỉ xây dựng những thành phần cần thiết để kiểm chứng giả định

5.    Thiết lập điều kiện thử nghiệm: Xác định dữ liệu, tải, môi trường, cấu hình và điều kiện vận hành cần thiết

6.    Đo lường kết quả: Ghi nhận dữ liệu thay vì chỉ đánh giá bằng quan sát định tính

7.    Đánh giá giới hạn: Xác định kết quả có còn đúng khi điều kiện, tải hoặc cấu hình thay đổi hay không

8.    Đưa kết quả vào quyết định thiết kế: Tiếp tục, điều chỉnh, kiểm chứng bổ sung hoặc loại bỏ phương án

Điểm mấu chốt là PoC phải được thiết kế để trả lời một quyết định cụ thể. Nếu không biết kết quả PoC sẽ làm thay đổi quyết định nào, phạm vi thử nghiệm rất dễ phình to thành một dự án phát triển thu nhỏ

PoC vì vậy giữ vai trò như một lớp kiểm chứng giữa ý tưởng kỹ thuật và phương án có thể đầu tư triển khai. Nó không thay thế thiết kế chi tiết, thử nghiệm sản phẩm hay pilot, mà giúp xác định sớm liệu các giả định quan trọng của phương án có đủ cơ sở để tiếp tục hay không

Một PoC tốt không nhất thiết phải chứng minh toàn bộ giải pháp. Nó cần chứng minh đúng điểm có rủi ro cao nhất, bằng tiêu chí đo lường phù hợp, trong điều kiện thử nghiệm đủ đại diện để kết quả có giá trị đối với quyết định thiết kế