Cách giải thích công nghệ rõ ràng cho người ra quyết định không làm kỹ thuật [Bài dịch]

1. Nhấn mạnh rằng vai trò của kỹ sư trong việc mang lại sự rõ ràng về kỹ thuật trong tổ chức là quan trọng nhất.

   • Sự rõ ràng về kỹ thuật là trạng thái mà các lãnh đạo không làm phát triển có thể hiểu đầy đủ những thay đổi trong hệ thống phần mềm để đưa ra quyết định hợp lý.

2. Lý do sự rõ ràng về kỹ thuật hiếm có và không dễ đạt được trong tổ chức.

   • Phần mềm cực kỳ phức tạp, đến cả kỹ sư cũng khó có thể hiểu hoàn toàn hệ thống của chính mình.
   • Các lãnh đạo không làm kỹ thuật bị hạn chế về thời gian và kiến thức nền.

3. Ví dụ về các câu hỏi kỹ thuật mang tính thực tiễn.

   • Những câu hỏi tiêu biểu mà lãnh đạo không làm kỹ thuật nhất định phải biết khi triển khai tính năng mới:
     1. Có thể cung cấp an toàn tính năng trả phí cho người dùng miễn phí không?
     2. Có thể triển khai dần dần không?
     3. Khi xảy ra sự cố, có thể rollback an toàn không?
     4. Có thể cấp quyền truy cập sớm không?
     5. Khi phát sinh vấn đề về năng lực xử lý, có thể ưu tiên người dùng trả phí không?

4. Ý nghĩa của cố vấn kỹ thuật chính thức/phi chính thức và tầm quan trọng của họ.

   • Staff Engineer hoặc Senior Engineer đóng vai trò như một “người đại diện” của lãnh đạo không làm kỹ thuật, trừu tượng hóa độ phức tạp của hệ thống và giải thích theo cách dễ hiểu.
   • Những kỹ sư cung cấp tốt sự rõ ràng về kỹ thuật sẽ giành được niềm tin trong tổ chức và được bố trí vào các dự án trọng yếu.

5. Sự bất định mà kỹ sư trải qua và cách cân bằng nó.

   • Kỹ sư luôn giữ một mức độ bất an và cảnh giác nhất định về chuyên môn của mình, và phần lớn chỉ có khoảng 95% chắc chắn.
   • Với lãnh đạo không làm kỹ thuật, không nên bộc lộ toàn bộ nỗi lo này hay mọi chi tiết kỹ thuật; thay vào đó cần truyền đạt rõ ràng những điểm cốt lõi.

6. Việc bộc lộ bất định không phải lúc nào cũng đúng.

   • Nếu kỹ sư cung cấp quá nhiều thông tin quá chi tiết về mặt kỹ thuật và làm loãng sự rõ ràng (một cách hiểu đã được đơn giản hóa), người ra quyết định sẽ khó đưa ra quyết định đúng đắn.
   • Hãy chỉ sắp xếp và truyền đạt rõ ràng các khuyến nghị cốt lõi cùng những yếu tố rủi ro.

7. Ba nguyên tắc để truyền đạt sự rõ ràng về kỹ thuật.

   • (1) Trực giác để phân biệt điều gì nên đề cập và điều gì nên lược bỏ.
   • (2) Hiểu biết kỹ thuật sâu về hệ thống (thông qua trực tiếp viết code và thực hiện dự án).
   • (3) Tự tin trình bày cho cấp quản lý một bức tranh đã được đơn giản hóa.

[ng0301]

Thực tế là... dù có biết điều đó thì vẫn còn rất nhiều thứ vượt xa hơn thế..

[geekgig]

Không biết bình luận này có phù hợp với tinh thần của bài viết hay không...

Tuy là khác biệt về góc nhìn,
rốt cuộc tôi vẫn nghĩ ý chí của người ra quyết định là quan trọng nhất.

Họ không muốn biết,
chỉ muốn nghe rằng chắc chắn làm được,
và muốn nghe rằng cứ để đó rồi sẽ tự lo được,

Nên việc giải thích có lẽ cũng đồng nghĩa với việc nói ra những điều khiến người có quyền quyết định cảm thấy không thoải mái.

ps.
Có vẻ đây là câu chuyện được đặt trên tiền đề rằng “người ra quyết định là đúng”?
Nếu người ra quyết định = trọng tài không thích, thì tôi nghĩ dù dùng cách nào đi nữa cuối cùng cũng vô ích.