How important is transparency in IT project management

Minh bạch (transparency) là gì?

1. "Tính minh bạch"
2. Rõ ràng
3. Không có "undertable"
4. Không có điều kiện ẩn 

Ví dụ về sự không minh bạch

Ví dụ 1

Giám đốc và PM đặt 2 deadlines khác cho dự án. Một deadline công bố với team, một deadline còn lại, sau khi đã buffer được thông báo với khách hàng. Team members không biết tới deadline ẩn thứ hai này.

Ví dụ 2

Khách hàng, product owner nói "được" hay "không được với output của nhóm phát triển. Tuy nhiên, định nghĩa thế nào là được hay không được không được khách hàng/product owner phát biểu rõ ràng, không được viết/nói rõ trong các tài liệu dự án, chuẩn dự án, quy định dự án. 

Ví dụ 3 

Việc không có ground rule tốt, được sự đồng ý/đồng thuận của cả nhóm phát triển với khách hàng, product owner cũng thể hiện sự không minh bạch. Khi "rule" không rõ ràng, ai muốn làm gì cũng được, cho dù lợi cho cá nhân anh ta nhưng không lợi cho tổng thể. Lúc này, bản thân các cá nhân không hoàn toàn có lỗi.

Ví dụ 4

Chuẩn về chất lượng, giao diện giữa nhóm phát triển và khách hàng khác nhau, luôn cần điều chỉnh, thoả thuận khi demo, giao nộp sản phẩm. 

Làm thế nào là/cho minh bạch?

1. Đừng giấu thông tin gì

2. Hạn chế trao đổi riêng

3. Luôn đi đến sự đồng thuận, thống nhất giữa số lớn thành viên liên quan 

4. Nói cho đơn giản, dễ hiểu

5. Viết ra, tài liệu hoá

6. Khi conflict, cãi nhau: Xem lại hoặc update rules chung  

Cụ thể hơn, mẹo và thực hành thế nào?

1. Chia sẻ thông tin

Chia sẻ thẳng thắn, cởi mở những thông tin liên quan đến dự án. 

Mọi người trong dự án đều có nguồn thông tin ngang nhau, giống nhau để đảm bảo không hiểu khác nhau (có thể hiểu sai giống nhau)

2. Chủ nghĩa genba

"genba" nghĩa là "nơi làm việc". Chủ nghĩa genba được hiểu đơn giản là việc lấy nơi/người làm việc làm trung tâm tối ưu, tạo điều kiện tốt nhất cho người làm viêc tốt nhất. Việc minh bạch hoá là điều kiện tiên quyết để người thật việc thật ở genba cả thấy yên tâm, thoải mái làm việc hiệu quả. 

3. Không có under table

Không giấu diếm gì. Những điều nhạy cảm và tế nhị như lương/thưởng, chế độ, conflict giữa các cá nhân nghiêm trọng, đánh giá nhân sự, tính xấu, hối lộ... có thể không được bàn công khai.

Những thông tin "cứng" về dự án như issue, tiến độ, yêu cầu công việc, thiết kế, điều kiện hoàn thành, điều khoản hoàn thành trong hợp đồng cần được chia sẻ rõ. 

4. Không "đi đêm"

Việc có thoả thuận ngầm giữa một vài hay nhiều đối tượng liên quan không được chấp nhận.

Ví dụ,

a. Tester và developer thoả thuận ngầm không đưa ra lỗi của nhau

b. Các developers hardcode và không share việc đó cho members khác

5. Công khai báo cáo/chia sẻ

Báo cáo về dự án: Share bằng wiki, Google Drive để tất cả những người liên quan có thể nhìn thấy, và nhìn thấy thông tin giống nhau.

Việc nhìn thấy thông tin giống nhau quan trọng hơn việc (mọi người) đều thấy thông tin sai. 

Tránh những chia sẻ/report bao gồm nội dung đánh giá con người, nhận xét xấu tới ai đó.

Công việc tồi: OK, nên report

Con người tồi: Không nên viết trong report

Việc tốt, người tốt: Nên khen công khai 

6. Mọi người liên quan đều chia sẻ, báo cáo

Xem phần 5. 

Những người liên quan có thể không phát ngôn, nhưng họ cần được truy cập vào thông tin báo cáo. 

7. Hou-ren-sou

Những nội dung nói trong bài viết này là một phần của nguyên tắc cơ bản với người Nhật: hou-ren-sou (báo cáo, liên lạc, thảo luận)

Việc thực hiện hou-ren-sou tốt đảm bảo tính minh bạch được tăng cường. 

8. Cộng tác với team, trên tinh thần hợp tác 

Tâm lý nói dối vì sợ, giấu thông tin, chia sẻ một phần sự thật là phổ biến.

Để tránh điều này, hợp tác trên tinh thần giúp đỡ.

Sếp, người liên quan, người có quyền ảnh hưởng thay vì ra lệnh, hỏi vặn, trì triết... nên hợp tác, hỏi thông tin thật và tìm cách hợp tác cùng giải quyết.

Bằng cách này, nhóm phát triển (người thật, việc thật) cảm thấy yên tâm, nói thật hơn.

9. Nói thẳng, nói thật 

Sự thật mất lòng. Nhưng vẫn cần tránh động tới cá nhân.

Giải quyết vấn đề trước. Nếu không được thì giải quyết con người.

Tập trung vào issue chứ không tập trung vào con người gây ra issue đó.

10. Công khai rủi ro, issues 

Tài liệu hoá risk, issue register, để nó ở nơi mọi người nhìn thấy (báo cáo, wiki...)

​Tham khảo: https://www.scrumalliance.org/community/articles/2013/june/transparency-in-agile-product-development​

--

Best Regards,
Nguyen Hung Vu [aka: NVH] (in Vietnamese: Nguyễn Vũ Hưng, グェン　ヒュン　ウー, 阮武興)
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype: vuhung16plus, twitter: vuhung, MSN: vuhung16.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to Linux Users' Groups, Free and Open Sources forums, mailing lists, the above is my personal opinion and is *not* the opinion of my employer(s), associations and/or groups I join.