Vai trò của bên liên quan trong thiết kế giải pháp

Xác định đúng bên liên quan và vai trò của từng nhóm

Không phải mọi bên liên quan đều cần tham gia với cùng mức độ. Trước khi thiết kế, cần xác định nhóm nào có thông tin, quyền quyết định, ảnh hưởng vận hành hoặc chịu tác động trực tiếp từ giải pháp.

Có thể phân biệt các nhóm theo vai trò:

·         Người sử dụng: Hiểu nhu cầu thực tế, vấn đề gặp phải và cách giải pháp được sử dụng

·         Chủ sở hữu hoặc người ra quyết định: Xác định mục tiêu, ưu tiên, ngân sách và tiêu chí chấp nhận

·         Nhóm vận hành: Cung cấp yêu cầu về quy trình, nguồn lực, khả năng triển khai và bảo trì

·         Chuyên gia kỹ thuật: Đánh giá tính khả thi, giới hạn kỹ thuật, phụ thuộc và rủi ro

·         Nhóm quản lý rủi ro, pháp lý hoặc tuân thủ: Xác định các yêu cầu bắt buộc và giới hạn không được vi phạm

·         Nhóm chịu ảnh hưởng gián tiếp: Phản ánh các tác động có thể không được nhận thấy từ góc nhìn của nhóm thiết kế

Điểm quan trọng là vai trò phải gắn với quyết định hoặc thông tin mà bên liên quan có thể đóng góp. Việc mời nhiều người tham gia nhưng không xác định rõ họ cần cung cấp hoặc xác nhận điều gì có thể làm quá trình thiết kế phức tạp hơn mà không tăng giá trị.

Đưa bên liên quan vào từ giai đoạn xác định nhu cầu và yêu cầu

Đây là giai đoạn quan trọng nhất để tránh thiết kế một giải pháp đúng về kỹ thuật nhưng sai về nhu cầu thực tế.

Bên liên quan nên tham gia để làm rõ:

·         Vấn đề nào cần giải quyết

·         Ai đang gặp vấn đề và trong hoàn cảnh nào

·         Kết quả mong muốn là gì

·         Những yêu cầu nào bắt buộc

·         Những yêu cầu nào chỉ là ưu tiên

·         Ràng buộc về quy trình, nguồn lực, thời gian hoặc khả năng vận hành

·         Điều kiện nào khiến một giải pháp được xem là chấp nhận được

Cần phân biệt nhu cầu với giải pháp được đề xuất sẵn. Nếu người sử dụng nói rằng họ cần một tính năng cụ thể, nhóm thiết kế nên tìm hiểu vấn đề phía sau tính năng đó trước khi biến nó thành yêu cầu thiết kế. Cách này giúp tránh khóa quá sớm vào một phương án chưa được kiểm chứng.

Kết quả của giai đoạn này nên là một tập yêu cầu có thể kiểm tra, trong đó các bên liên quan quan trọng đã thống nhất về vấn đề cần giải quyết và tiêu chí thành công.

Tham gia khi hình thành và đánh giá các phương án giải pháp

Khi đã hiểu yêu cầu, nhóm thiết kế có thể phát triển các phương án. Vai trò của bên liên quan lúc này chuyển từ xác định vấn đề sang đánh giá mức độ phù hợp của các lựa chọn.

Bên liên quan có thể giúp trả lời:

·         Phương án nào giải quyết đúng nhu cầu?

·         Phương án nào phù hợp với quy trình hiện tại?

·         Điều kiện nào cần có để triển khai?

·         Phương án nào tạo thêm rủi ro hoặc chi phí?

·         Có yêu cầu quan trọng nào bị bỏ sót không?

·         Đánh đổi giữa các phương án có chấp nhận được không?

Không nên yêu cầu tất cả bên liên quan cùng quyết định mọi chi tiết. Nhóm kỹ thuật có thể chịu trách nhiệm về tính khả thi kỹ thuật, trong khi người sử dụng đánh giá khả năng sử dụng và chủ sở hữu giải pháp đánh giá mức độ phù hợp với mục tiêu.

Như vậy, sự tham gia không biến thành việc “thiết kế theo biểu quyết”, mà trở thành cơ chế đưa đúng góc nhìn vào đúng quyết định.

Tham gia kiểm chứng và xác nhận giải pháp trước khi triển khai

Một giải pháp không nên được xem là hoàn tất chỉ vì nhóm thiết kế đã hoàn thành bản thiết kế. Trước khi triển khai, các bên liên quan cần có cơ hội kiểm chứng giải pháp dựa trên các yêu cầu và tiêu chí đã thống nhất.

Việc kiểm chứng có thể tập trung vào:

·         Giải pháp có đáp ứng yêu cầu chính hay không

·         Quy trình sử dụng có phù hợp với thực tế hay không

·         Các điều kiện vận hành có khả thi hay không

·         Các rủi ro hoặc giới hạn đã được xử lý chưa

·         Kết quả đầu ra có thể đo lường theo tiêu chí đã đặt ra hay không

·         Có thay đổi nào trong bối cảnh khiến thiết kế ban đầu không còn phù hợp không

Đây cũng là thời điểm cần xác định rõ ai có quyền chấp thuận và tiêu chí nào được dùng để chấp thuận. Nếu không có cơ chế xác nhận rõ ràng, quá trình thiết kế có thể tiếp tục quay lại chỉnh sửa dù giải pháp về cơ bản đã hoàn thành.

Duy trì phản hồi của bên liên quan sau khi giải pháp được thử nghiệm

Sự tham gia không nhất thiết kết thúc ngay khi giải pháp được phê duyệt. Khi giải pháp được thử nghiệm hoặc đưa vào sử dụng, phản hồi thực tế có thể phát hiện những vấn đề mà giai đoạn thiết kế không thể dự đoán đầy đủ.

Phản hồi sau triển khai nên tập trung vào:

·         Điều gì hoạt động đúng như kỳ vọng

·         Điều gì không phù hợp với thực tế

·         Người sử dụng gặp trở ngại ở đâu

·         Có phát sinh điều kiện hoặc rủi ro mới không

·         Những yêu cầu ban đầu có còn phù hợp không

·         Có cần điều chỉnh giải pháp hoặc cách vận hành không

Thông tin này tạo thành vòng phản hồi để nhóm thiết kế cải thiện giải pháp thay vì coi thiết kế là một hoạt động chỉ diễn ra một lần.

Điều chỉnh mức độ tham gia theo quyền quyết định và mức độ ảnh hưởng

Không phải giai đoạn nào cũng cần cùng một nhóm bên liên quan. Một cách tiếp cận hiệu quả là phân bổ sự tham gia theo hai yếu tố: mức độ ảnh hưởng của bên liên quan và mức độ liên quan của họ tới quyết định đang được đưa ra.

Có thể áp dụng nguyên tắc:

Cách phân bổ này giúp tránh hai thái cực: tham gia quá ít khiến giải pháp thiếu thông tin thực tế, hoặc tham gia quá nhiều khiến quá trình ra quyết định chậm và trách nhiệm bị phân tán.

Cách tổ chức sự tham gia để không làm chậm quá trình thiết kế

Sự tham gia của bên liên quan chỉ tạo giá trị khi được tổ chức quanh các quyết định cụ thể. Mỗi lần tham gia nên xác định rõ bốn yếu tố:

1.    Cần thông tin gì: Bên liên quan cần cung cấp dữ liệu, nhu cầu hay phản hồi nào

2.    Cần quyết định gì: Họ đang được tham vấn hay có quyền phê duyệt

3.    Cần bằng chứng gì: Tiêu chí hoặc kết quả nào được dùng để đánh giá

4.    Kết quả được sử dụng thế nào: Ý kiến sẽ được đưa vào yêu cầu, thiết kế, kiểm thử hay quyết định cuối cùng

Nếu chỉ thu thập ý kiến mà không chỉ rõ cách sử dụng, bên liên quan có thể tham gia nhiều lần nhưng vẫn không hiểu ý kiến của họ ảnh hưởng đến thiết kế ra sao.

Ngược lại, khi mỗi điểm tham gia gắn với một quyết định cụ thể, nhóm thiết kế có thể kiểm soát phạm vi, tránh lặp lại thảo luận và vẫn duy trì được phản hồi cần thiết.

Về bản chất, bên liên quan trong thiết kế giải pháp nên tham gia từ lúc xác định vấn đề và yêu cầu, tiếp tục trong quá trình đánh giá phương án, kiểm chứng và phê duyệt, rồi phản hồi sau triển khai. Tuy nhiên, họ không cần tham gia mọi hoạt động với vai trò giống nhau. Cách hiệu quả hơn là xác định đúng người, đúng thời điểm, đúng quyết định và đúng trách nhiệm.

Khi sự tham gia được tổ chức theo cách đó, phản hồi của bên liên quan trở thành một phần của quá trình thiết kế và kiểm chứng giải pháp, thay vì chỉ là bước lấy ý kiến mang tính hình thức.