Guide cho Senior Engineer trong việc hướng dẫn người mới

Đây là bài dịch, bài gốc mời các bạn xem ở đây: http://silverwraith.com/blog/2017/10/the-senior-engineers-guide-to-helping-others-make-decisions

Một trong những việc mà tôi thấy các Senior Engineer hay mắc phải, đó là giúp đỡ Junior Engineer tiến bộ. Lý do cho việc này, thông thường là do chúng ta không cho họ đủ không gian để khám phá, học hỏi và hiểu cách để tự tiếp cận và giải quyết vấn đề.

Trong bài viết này, chúng ta sẽ cùng trải qua ba tình huống hoàn toàn khác nhau để mô phỏng sự cần thiết và thường xuyên của việc đưa ra quyết định, đồng thời tìm hiểu cách để làm cho các quyết định ngày càng tốt hơn. Và với vai trò là một Senior Engineer, chúng ta sẽ biết cách để giúp mọi người đưa ra quyết định, chứ không phải là quyết định hộ mọi người.

Chúng ta đưa ra quyết định như thế nào

Quá trình dựa trên khuynh hướng (bias)

Mỗi chúng ta có riêng một tập các khuynh hướng của bản thân dùng để ra quyết định. Các khuynh hướng này được hình thành thông qua kinh nghiệm thực tế trong nhiều năm trời, trong đó đa số chúng là những kinh nghiệm đau thương nhớ đời. Các khuynh hướng này có một sức mạnh đáng kinh ngạc, vì nó sẽ dẫn đường cho bản thân đến những luồng suy nghĩ mà chúng ta cảm giác rằng "Chắc như đinh đóng cột" - đồng thời, quan trọng hơn, khiến chúng ta tránh xa khỏi những luồng suy nghĩ khác, kể cả nó có hiệu quả hơn.

Khi đối diện với các hành động được đề xuất bởi người khác, chúng ta sẽ bắt đầu với hậu quả tồi tệ nhất mà hành động đó có thể gây ra, và sau đó sẽ kiến tạo nên một quá trình có thể dẫn đến hậu quả đó, với điểm khởi đầu là hành động được đề xuất. Từ điểm này, chúng ta sẽ hoàn toàn lờ đi mặt tích cực của lời đề xuất, sử dụng bạo lực ngôn từ, và kết thúc bằng một cục thảm hại. Càng bất ngờ hơn nữa là sự đa dạng về số lượng và chủng loại các hành vi dựa trên khuynh hướng. Các bạn có thể tham khảo một số như Khuynh hướng hỗ trợ chọn lựa, Khuynh hướng niềm tin, Khuynh hướng xác nhận, Khuynh hướng tiêu cực,... Danh sách rất dài.

Tưởng tượng một đoạn đối thoại như dưới đây

Junior Engineer : Thay vì back up database một tuần một lần như hiện nay, nếu chúng ta thực hiện backup hàng ngày và tạo ra nhiều bản sao của bản backup đó thì sao nhỉ? Senior Engineer: Hàng ngày á? Làm thế tồi vãi c' luôn, nếu như việc backup mất thời gian và ảnh hưởng đến băng thông thì sao? J: Ờ thì, em cũng không rõ nữa. Đáng lẽ nó không nên như vậy chứ? S: Nhưng nó có thể. Và một đống dung lượng sẽ cần cho việc lưu trữ các bản backup hàng ngày? Chúng ta làm méo có chỗ. J: Ừ nhỉ, bác nói đúng đấy. S: Lần gần đây nhất bọn anh thử vấn đề này, bọn anh khiến site bị down trong mấy giờ liền, và gặp một đống rắc rối luôn. J: Éc. Em xin lỗi vì chưa nhận thức được ý kiến của mình lởm thế nào. S: Chú sẽ sớm biết thôi.

Một ý kiến có lý, thậm chí có thể đánh giá là khá cẩn thận, đã được trình bày, nhưng đã bị khuynh hướng của senior engineer đập cho sml. Thanh niên senior engineer đã nhớ lại về một ý tưởng tương tự mà anh ta gặp phải trong quá khứ đã khiến anh ta khốn đốn như thế nào, và ngay lập tức anh ta bác bỏ ý kiến của junior engineer luôn. Thêm nữa, senior engineer cũng không thể biết được tại sao junior engineer lại đưa ra đề nghị backup hàng ngày. Đồng thời, senior engineer đã sử dụng ngôn từ thô bạo trong tranh luận để biện hộ cho vị trí của bản thân, chứng tỏ rằng junior engineer không hiểu gì về bối cảnh và không đem lại ích lợi gì cả.

Tệ hơn nữa, junior engineer sẽ chỉ cảm nhận được mình bị mắng do mình thiếu kinh nghiệm, mất hẳn cơ hội để học hỏi từ tình huống vừa rồi

Chúng ta nên quyết định như thế nào

Chúng ta vẫn hay thường hay nói Học hỏi từ hành động, với hàm ý là chúng ta sẽ học hỏi được nhiều nhất khi bắt tay vào làm gì đó. Thông thường thì, thất bại từ những lần thử sẽ là một cách tuyệt vời để học hỏi những điều mới nếu có thể vượt qua được những khuynh hướng do kinh nghiệm tiêu cực ép chúng ta tuân theo.

Cuộc hành trình của bản thân

Công cuộc học hỏi để trở nên một good engineer của tôi bắt đầu vào giữa những năm 90's khi tôi có chiếc PC đầu tiên. Nó chạy Windows 3.0, có 4Mb Ram và 512Mb ổ cứng. Sau khi trải qua cảm giác có đồ mới, tôi đã nhận ra cái PC mình đang có thực ra rất là cùi, đã thế lại còn đắt, và tôi muốn làm thêm nhiều thứ nữa nhưng không biết bắt đầu như thế nào.

Tôi bắt đầu đọc các tạp chí về máy tính, hầu hết chúng gồm 3 loạt:

• Tối ưu hiệu năng hệ thống
• Các mục về trợ giúp và lời khuyên
• Thông tin về công nghệ mới

Các mục về trợ giúp và lời khuyên là một cách tuyệt vời để hiểu rõ các vấn đề người khác đang gặp phải. Tôi thường đọc và thử xem mình có thể gặp các vấn đề giống thế không, và tái hiện lại giải pháp.

Bài học đầu tiên: Giữ cho đĩa cài đặt luôn trong tầm tay.

Bằng cách này, tôi đã xay dựng một nền tảng trong việc phục hồi, test an toàn, làm quen với các tình huống tồi tệ nhất, và nhiều hơn nữa... Rất nhiều engineer sản phẩm hoặc người vận hành hệ thống sẽ có những kinh nghiệm tương tự, nhưng chúng ta lại thường có xu hướng xấu hổ và tránh xa chúng trong công việc chuyên nghiệp của bản thân, trong khi chúng ta nên cổ vũ junior engineering làm việc theo cách này nhiều hơn.

Cách tiếp cận nửa chừng (Half-way)

Câu chuyện đối thoại ở trên rất thường xuyên xảy ra, không chỉ trong ngành công nghiệp của chúng ta, mà còn trong rất nhiều tình huống ở công việc hoặc quan hệ cá nhân.

Sau đây là một cách tiếp cận khác mà tôi gọi là "Cách tiếp cận nửa chừng"

Hãy xem câu chuyện sẽ tiếp diễn như thế nào:

Junior Engineer : Thay vì back up database một tuần một lần như hiện nay, nếu chúng ta thực hiện backup hàng ngày và tạo ra nhiều bản sao của bản backup đó thì sao nhỉ? Senior Engineer: Hàng ngày ấy hả? Ngày xưa bọn anh cũng thử thế rồi nhưng gặp một vài trục trặc J: Có vấn đề gì thế bác? S: Việc backup mất quá nhiều thời gian, và khi đến thời điểm băng thông tăng cao, website bị down trong vòng vài giờ. J: Eo vãi. Vậy có cách gì chúng ta có thể làm với cái này không nhỉ? S: Anh cũng đã nghĩ đến vấn đề này vài lần kể từ lúc đó. Nếu chú có thể bắt đàu backup sớm hơn và tạo ra một cronjob để dừng việc backup nếu nó mất quá nhiều thời gian, thì có thể giải quyết được một vài vấn đề đấy. J: Ok, việc đó em có thể quẩy được. S: Và cho cái job đó email cho chúng để biết được chuyện gì đã xảy ra. Nhưng trước khi làm bất cứ việc gì, chú nên tạo ticket để xem chúng ta có thể có thêm chỗ lưu trữ. Nếu không thể có thêm dung lượng, thì việc này chỉ dừng ở mức thảo luận được thôi. J: À nhỉ, ngon, em sẽ hỏi luôn việc này. Cảm ơn bác!

Đây là một bước cải tiến so với đoạn đối thoại trước đó. Có ít thái độ thù hằn hơn, và xúc tiến được nhiều việc hơn để hoàn thành công việc. Tuy nhiên chúng ta vẫn có 2 vấn đề lớn ở đây:

• Cả 2 engineer đều có vẻ đang làm việc cùng nhau cho một giải pháp, nhưng senior engineer đang lên kế hoạch dựa trên kinh nghiệm trước đó của anh ta, và junior engineer chỉ cần tuần theo từng bước đã được vẽ sẵn. Junior Enginner là một người chủ động, thể hiện qua việc ghi chú lại và thực hiện implement giải pháp được giao, nhưng vẫn có rất ít cơ hội cho junior engineer được học hỏi và phát triển.
• Senior engineer vẫn không hỏi tại sao junior engineer lại muốn làm việc này, và vấn đề mà junior engineer đang muốn giải quyết là gì. Ở đây chúng ta đang giả định rằng cả 2 đang làm việc để giải quyết vấn đề với cùng một lý do, nhưng chúng ta ko biết được có thực ra là như vậy hay không.

Cách tiếp cận tốt hơn

Phá bỏ những khuynh hướng của bản thân là một việc vô cùng khó. Việc khó hơn nữa là nhận thức được rằng có rất nhiều cái tôi cũng như cảm xúc cá nhân có thể ảnh hưởng đến cách chúng ta đưa ra quyết định. Bất cứ khi nào có engineer khác đến với chúng ta vì một vấn đề, ý tưởng hay cách tiếp cận nào đó, chúng ta đều có một niềm ham muốn mãnh liệt để điều khiển họ đến giải pháp mà chúng ta muốn được implement, dựa trên những ý tưởng và kinh nghiệm của chúng ta.

Trở thành một senior engineer có nghĩa là nhận ra rằng không phải tất cả mọi thứ có thể được hoàn thành theo cách mà chúng ta muốn.

Một hệ quả cho việc này là :

Người khác có thể tạo ra các công cụ, hệ thống hoặc quyết định không tốt bằng thứ mà bạn tạo ra, nhưng chúng vẫn nên được tạo ra.

Bất kể là junior hay senior, engineer nên được chung cấp hướng dẫn và đề nghị để giúp họ tạo ra ra những ý tưởng mạnh mẽ, và cải thiện khả năng suy luận, hơn là được đưa gcho giải pháp để implement hoặc bị bác bỏ sml.

Hãy cùng xem lại đoạn đối thoại giữa 2 engineer của chúng ta, nhưng lần này là với cách tiếp cận khác:

Junior engineer: Thay vì back up database một tuần một lần như hiện nay, nếu chúng ta thực hiện backup hàng ngày và tạo ra nhiều bản sao của bản backup đó thì sao nhỉ? Senior engineer: Ý tưởng thú vị đấy, thế chú định giải quyết vấn đề gì thế? J: Em đang lo ngại rằng chúng ta có thể mất dữ liệu của cả một tuần nếu server bị crash. S: Lý do hợp lý đấy. Vậy thì chú sẽ gặp vấn đề như này: Nếu như backup chạy lúc băng thông server cao thì sao? Chúng ta làm nó vào cuối tuần vì lúc đó không có mấy người dùng. J: À, em hiểu. Vậy thì chúng ta có thể thử chạy nó sớm hơn, và có thể thêm ít code để theo dõi và thông báo cho chúng ta nếu có vấn đề. Bác nghĩ sao? S: Khởi đầu như thế ổn đấy. Hãy thử làm nó đi xem thế nào.

Một thời gian sau

J: Em đang nghĩ là, nếu chúng ta có thể chỉ backup những thay đổi diễn ra hàng ngày thay vì tất cả toàn bộ DB thì tốt nhỉ? Backup toàn bộ có vẻ tốn chỗ phết? S: Làm được thế thì ngon, anh có một vài ý tưởng để thực hiện việc này, nhưng chú nên thử nghiên cứu và làm thử vài ý tưởng của bản thân trước thì sao nhỉ. Nếu chỗ nào bí thì hãy hỏi anh. J: Ok cảm ơn bác.

Một thời gian sau nữa

J: Ok bác ei, em có một giải pháp khả thi cho việc này. Và em thấy nó ngon phết. em đã học được ngôn ngữ có tên là Perl và nó có thể giải quyết vấn đề chúng ta muốn hết sức dễ dàng S: Perl à, hmm. Nếu thế thì chú sẽ gặp phải vấn đề với việc maintain sau này đấy, bởi vì có môi chú và anh là biết Pert. Nhưng nếu chú thích giải pháp này và nó hoạt động thì cứ làm thôi. Nhớ đảm bảo rằng chú viết tài liệu mô tả đầy đủ và rõ ràng tại sao nó chạy, và cách để fix nó nếu lỗi nhé. Và đừng quên comment vào trong code! S: À, với cả chú có ticket để theo dõi toàn bộ công việc của task này không? Nó sẽ là một cách rất tốt để tài liệu hoá những gì chú đã làm và giải thích tại sao, đồng thời chúng ta có thể theo dõi lại nó sau này nếu cần. J: Không hẳn bác ạ, nhưng em sẽ làm ticket trước khi làm thêm bất cứ thứ gì. Cảm ơn bác!

Một điều quan trọng cần phải ghi nhớ là sau khi thực thi giải pháp, engineers có thể nhận ra rằng giải pháp là không khả thi, không hiệu quả, hoặc không phù hợp với yêu cầu nghiệp vụ, hoặc sẽ là một giải pháp hoạt động tốt nhưng không phải được của senior engineer, mà là một giải pháp được đề ra và triển khai bởi junior engineer.

Sợ hãi trước những điều này không phải là lời biện minh cho việc cản trở công việc.

Junior engineer đã học được một số kỹ năng khó:

• Học thêm ngôn ngữ lập trình mới
• Tạo một giải pháp backup

Cùng với một số kĩ năng mềm khác:

• Tăng cường khả năng đưa ra quyết định
• Phối hợp với engineer khác
• Trình bày và trau chuốt ý tưởng
• Trình bày giải pháp
• Theo dõi công việc

Và tất cả những điều này đều học được trước khi giải pháp được triển khai lên production!

Giúp đỡ junior engineer đưa ra đề xuất tốt

Trình bày ý tưởng là một kỹ năng có thể học, chúng ta phát triển nó qua việc tương tác với người khác, tranh luận, xem các buổi nói chuyện và tham gia các buổi gặp mặt. Là một senior engineer, một trong những việc quan trọng là giúp những engineer xung quanh mình phát triển kỹ năng này. Trong cuộc hội thoại thứ 3, senior engineer đã hỏi junior engineer vấn đề mà 2 người đang giải quyết là gì - cách tiếp cận có tên là phương pháp Socratic Một số câu hỏi tốt khác có thể sử dụng là :

• 3 giải pháp hàng đầu mà bạn đã tìm hiểu trước khi chọn cái này là gì?
• Tại sao bạn bỏ qua các phương pháp khác?
• Trong các phương án còn lại, có lợi điểm nào mà chúng ta có thể cân nhắc sau này không?
• Vấn đề gì có thể xảy ra với giải pháp này?
• Khả năng maintain của giải pháp này nếu bạn không có mặt ở đây là gì?
• Dữ liệu nào cần phải backup cho giả định của bạn?

Mục tiêu là để engineer của bạn nghĩ về những câu hỏi này trước khi đề xuất với bạn. Và bắt họ phải trả lời những câu hỏi này cùng với ý tưởng ban đầu. Về mặt dài hạn, việc này sẽ giúp họ phát triển các giải pháp dựa nhiều vào dữ liệu, đánh giá nhiều giải pháp và khiến cho ý tưởng dễ tiếp cận hơn.

Hầu hết tất cẩ các công việc đều là một cơ hội để học hỏi, nhưng bạn không nên cổ vũ junior engineer chọn những công việc có độ rủi ro thấp hay có ảnh hưởng nhỏ với mục đích chỉ để học tập. Hãy tìm những khoảng thời gian dành riêng cho việc học, và cho phép họ làm việc với những task khó, thậm chí cả task có độ rủi ro cao với hướng dẫn từ senior engineer.

Sức ảnh hưởng của ngôn từ

Để tổng kết lại post này, tôi sẽ dành một khoảng để nói về việc từ ngữ mà chúng ta đang sử dụng có thể có ảnh hưởng lớn như thế nào đến giọng điệu và kết quả của một cuộc nói chuyện.

Trong đoạn hội thoại thứ 3, senior engineer không hề dùng từ Không hay là Nhưng. Thay vào đó, anh ta cổ vũ rằng ý tưởng có vẻ hợp lý, đồng thời động viên junior khám phá nó. So với đoạn hội thoại đầu tiền, giọng điệu của 2 cuộc nói chuyện rất khác nhau. Cuộc nói chuyện đầu tiên mang tính đe doạ và phòng thủ, trong khi cuộc nói chuyện cuối cùng lại cởi mở, động viên và chào đón.

Kể cả có thể suy nghĩ rằng giải pháp được thiết kế và triển khai không giống như cách mà senior engineer đã làm, thì nó vẫn hoạt động và mang đến cho junior engineer cảm giác làm chủ. Nó giúp cho junior tăng khả năng học hỏi về cách triển khai ý tưởng, là thứ mà sẽ không thể có được nếu như ý tưởng bị bác bỏ ngay từ đầu, hoặc được bảo tận tay cách thực hiện.

Thay vì các từ như không, nhưng hoặc là có, nhưng mà.. (mang tính tiêu cực), hãy học cách nó Ừ hoặc Ừ, và.... Hãy cổ vũ các engineer khác tìm hiểu kỹ hơn và đưa ra những giải pháp cho các vấn đề, đồng thời giúp học trong việc implement các giải pháp đó. Họ có thể trở thành những người không giống như bạn nghĩ. Hó có thể không giả quyết được tất cả các vấn đề bạn có thể nghĩ đến, hoặc không nhìn ra được ảnh hưởng trong tương lại. Nhưng đây sẽ là điểm khởi đầu, và là một cơ hội quan trọng để phát triển, trưởng thành và thành công.

Cảm ơn.