Cách tôi viết 'sổ tay WTF' của mình (2021)
(simplermachines.com)- Ngay sau khi gia nhập một đội mới, thay vì lập tức chỉ ra những điều kỳ lạ mình thấy, hãy gom chúng vào sổ tay WTF để có đủ ngữ cảnh xây dựng niềm tin như một người giúp ích cho đội, chứ không phải một người chỉ biết phàn nàn
- Những thứ nên ghi lại là các tín hiệu vướng mắc trong cách vận hành đội ngũ và dòng chảy kỹ thuật như: buổi retro kết thúc mà không có hành động nào, không thể test trên máy local, bảng build luôn đỏ, hay một công việc nào đó phụ thuộc vào duy nhất một người
- Theo thời gian, danh sách này sẽ được sàng lọc thành: những việc có lý do chính đáng, những việc đã có chỉnh sửa đang được tiến hành, những việc đội không ưu tiên, và những việc có thể sửa rất dễ
- Những vấn đề vẫn còn tồn tại sau vài tuần thì hãy trao đổi với thành viên trong đội, team lead và manager để xác nhận nguyên nhân cũng như lịch sử của chúng, rồi cùng giải quyết trước những vấn đề đã gây khó chịu từ lâu nhưng tương đối đơn giản
- Thay vì làm bùng nổ vấn đề ngay lập tức, nếu tích lũy ngữ cảnh và mức độ ưu tiên trước, ngay cả thành viên mới cũng có thể không đánh mất lòng tin mà vẫn xây dựng được danh tiếng là người giải quyết vấn đề
Cách dùng sổ tay WTF
- Danh tiếng bạn muốn có trong đội là “người giúp tôi giải quyết vấn đề”, “người hoàn thành những việc tôi xem là quan trọng”
- Mỗi khi gia nhập một đội mới, hãy mở một trang mới trong bullet journal và ghi
WTF - [Team Name], rồi mỗi khi gặp điều gì đó thấy kỳ lạ thì ghi lại - Nếu có thứ gì bạn muốn thay đổi, cũng ghi nó thành một đầu việc riêng
- Trong 2 tuần đầu tiên, hãy chỉ tập trung vào việc ghi lại
- Đừng lập tức nói ra mọi thứ mà bạn nghĩ là đội đang làm sai
- Đừng đổ cả danh sách những thứ cần thay đổi vào buổi retro
- Hãy quan sát, lắng nghe, và ghi lại những gì khiến bạn thật sự cảm thấy có gì đó không ổn
- Cách này giúp bạn tạo ra thay đổi trong đội mà vẫn tự quản lý được bản thân, đồng thời không khiến mình trông như một người chỉ biết than phiền
Những tín hiệu bất thường cần bắt ở đội mới
- Ở một đội mới luôn có những chuyện khiến bạn phải thốt lên “wtf”
- Một vài ví dụ điển hình:
- Cả đội dành một tiếng trong buổi retro để nói về một vấn đề nghiêm trọng nhưng lại kết thúc mà không có action item nào
- Test không chạy được ở local nhưng trông như chẳng ai quan tâm
- Một phần lớn trên bảng build lúc nào cũng ở trạng thái đỏ
- Có một việc quan trọng và nhạy cảm về thời gian mà chỉ một người có thể xử lý
- Đội dành rất nhiều thời gian cho một tính năng nào đó nhưng không ai thực sự biết vì sao nó quan trọng hoặc nó giúp ích cho khách hàng như thế nào
Những mục sẽ bị gạch khỏi danh sách
- Khi danh sách đủ dài, hãy bắt đầu gạch từng mục đi
- Thường có bốn lý do để gạch:
- Thực ra có lý do chính đáng
- Đội đã đang sửa nó rồi
- Đội không xem vấn đề đó là quan trọng
- Nó thật sự rất dễ sửa
- Vấn đề test local không chạy được, tùy ngữ cảnh, có thể cũng không phải là vấn đề lớn
- Có thể đó là issue đã được biết đến và nỗ lực khắc phục đang diễn ra
- Có thể cả đội làm mọi thứ trên máy ảo, và có thể provision máy đó dễ dàng bằng lệnh trong chat
- Nếu hệ thống tích hợp liên tục được thiết lập tốt và đội có thói quen deploy thay đổi nhỏ thường xuyên, thì việc không test được ở local có thể không cản trở chuyện deploy nhiều lần mỗi ngày
- Một số mục lại có lời giải rất đơn giản
- Nếu biết chỗ thì có thể viết tài liệu
- Nếu tìm ra đúng script thì có thể là một thay đổi rất dễ
- Nếu đã thấy cách sửa đơn giản, hãy sửa luôn
Cùng đội xử lý những vấn đề còn lại
- Nếu sau vài tuần vẫn còn những vấn đề lạ lùng và chưa được giải quyết, hãy bắt đầu trao đổi với các thành viên trong đội, team lead và manager
- Trọng tâm của câu hỏi là vì sao mọi thứ lại ở trạng thái đó, và chúng đã trở nên như vậy bằng cách nào
- Mục tiêu là xây dựng niềm tin như một người thật sự tò mò và biết đồng cảm, kiên nhẫn và tôn trọng chuyên môn của đồng đội
- Lý do khiến vấn đề còn tồn tại thường rơi vào vài nhóm:
- Đội chưa nhận ra nó
- Đội đã quen với nó
- Vấn đề này còn khá mới, còn vấn đề trước đó thì tệ hơn nhiều
- Không biết cách sửa
- Trước đây đã từng thử sửa nhưng thất bại
- Với vài nhóm đầu tiên, chỉ cần hỏi thôi cũng có thể sửa được ngay
- Người kia có thể sửa ngay hoặc cùng bạn tìm cách giải quyết
- Nếu là vấn đề kỹ thuật thì cùng viết story hoặc ticket rồi làm
- Nếu là vấn đề về quy trình hay yếu tố con người thì đem ra trao đổi với cả đội trong buổi retro
- Ở giai đoạn này, sẽ rất tốt nếu tìm được một hai vấn đề đã làm ít nhất một đồng đội khó chịu từ lâu, nhưng lại có cách giải quyết tương đối đơn giản
- Khi đưa lên bảng retro, hãy chọn vấn đề không phải chỉ mình bạn thấy khó chịu
- Trong lúc cả đội trao đổi, hãy biến đề xuất của đồng đội đó thành một action item có thể thử ngay
- Cả đội sẽ bắt đầu cảm thấy thành viên mới đang giúp họ giải quyết vấn đề của chính họ
Những vấn đề khó hơn và cuộc trò chuyện với manager
- Theo thời gian, bạn sẽ chạm tới những vấn đề dai dẳng mà đội biết là tồn tại nhưng lại ngại đụng vào
- Đây có thể là những việc bị xem là “cũng không tệ đến thế” nhưng chẳng ai muốn nói ra
- Có thể đội đang thiếu năng lực kỹ thuật cần thiết
- Có thể trọng tâm là một vấn đề con người phức tạp
- Ở giai đoạn này, hãy mang danh sách bạn đã lập đến trao đổi với manager
- Những gì bạn đã thấy trong vài tuần qua
- Một số việc đang có tiến triển, nhưng một số việc khác có vẻ sẽ mất nhiều thời gian hơn
- Liệu bạn có bỏ sót điều gì không
- Manager muốn bạn tập trung vào khu vực nào
- Có thể manager cũng lo về đúng những vấn đề đó, nhưng vì đội trông không quá khó chịu nên họ không thể thúc mạnh hơn
- Sau đó, bạn có thể cùng manager sắp xếp lại các mối lo và vấn đề, rồi trao đổi về những trường hợp trước đây từng hiệu quả hoặc không hiệu quả
- Manager sẽ bắt đầu nhìn bạn như một người có óc phán đoán tốt và có thể giúp giải quyết những vấn đề khó hơn
Vì sao không chỉ ra ngay lập tức
- Danh tiếng bạn muốn có là “Nat giúp tôi giải quyết vấn đề”, “Nat hoàn thành những việc tôi xem là quan trọng”
- Danh tiếng đó có thể giúp bạn đạt kết quả mong muốn trong kỳ đánh giá hiệu suất năm sau, và vài năm sau còn có thể dẫn đến những lời giới thiệu
- Trước đây, tôi từng nói ra vấn đề ngay khi vừa phát hiện
- Kết quả là tôi có danh tiếng “lúc nào cũng phàn nàn”, “nghĩ rằng bọn tôi chẳng bao giờ làm đúng cả”
- Mọi người bắt đầu không còn lắng nghe, còn bản thân tôi thì vừa thất vọng về mặt cá nhân vừa kém hiệu quả trong công việc
- Nếu một thành viên mới làm ầm lên vì một chuyện thực ra không phải vấn đề, hoặc là điều đội không xem là vấn đề, hoặc đang được giải quyết rồi, hoặc có một cách sửa đơn giản mà lúc đầu họ chưa nhìn ra, thì lòng tin sẽ sụp đổ rất nhanh
- Trong đội lúc nào cũng có rất nhiều vấn đề có thể cải thiện, nhưng chỉ một phần trong số đó là thực sự có thể giải quyết được
- Thứ tự bạn phát hiện ra vấn đề hiếm khi cũng chính là thứ tự giải quyết hiệu quả nhất
- Sổ tay WTF giúp bạn tạm cất đi thôi thúc “muốn sửa ngay bây giờ”, và chờ đến khi có đủ ngữ cảnh để quyết định nên xử lý điều gì trước
1 bình luận
Ý kiến trên Hacker News
Có vẻ bài này chưa nhấn mạnh đủ một điều: góc nhìn của người mới chỉ có một lần
Lý do ta thường đánh giá kém về tính dễ dùng của sản phẩm là vì ta đã biết cách dùng, và đã trở nên chai lì với lỗi sai cùng khiếm khuyết
Thành viên mới trong nhóm thì vẫn chưa ở trạng thái đó, nên chỉ cần nhìn xem họ hỏi gì, vướng ở đâu, và thực sự cần giúp chỗ nào là cả nhóm có thể thu được rất nhiều insight
Chúng tôi ngồi đó ghi chép và trò chuyện với người dùng trong lúc họ dùng sản phẩm
Dù có thu thập bao nhiêu terabyte dữ liệu telemetry đi nữa, bạn vẫn không thể hiểu cách sản phẩm được sử dụng bằng việc nói chuyện với người dùng thật
Ngành công nghệ cần vượt qua bớt nỗi sợ với những con người khác
Nó giống như việc một giáo sư lão luyện quên mất rằng những điều phải giải thích lại khó với sinh viên mới học lần đầu
Nhưng không phải ai cũng tệ như nhau; yếu tố khác biệt lớn là họ có đủ khả năng đồng cảm và sự quan tâm để đặt mình vào vị trí người mới bắt đầu hay không
Hai người đã dùng Bash shell vô số lần vẫn có thể có mức độ thấu hiểu hoàn toàn khác nhau về điều gì là kỳ quặc và không trực quan với người mới
Nhìn bằng đôi mắt mới mẻ cũng là một kỹ năng, và có thể cải thiện bằng rèn luyện, giống như học cách vẽ bằng việc quan sát ánh sáng và vật thể thật
Nếu không nói ra ngay mà ghi lại trước, bạn sẽ có thời gian để hiểu vì sao mọi thứ lại như vậy và làm quen với địa hình của tổ chức
Khi các thứ như tài khoản, quyền hạn và phê duyệt đã được sắp xếp ổn thỏa, bạn có thể hành động dựa trên danh sách đó
Khi đó, cả nhóm cũng có nhiều khả năng đón nhận bạn như một người muốn giúp đỡ thay vì “người cứ bật ra và hét WTF mãi”
Với quy mô 12–15 người thì cách này hoạt động rất tốt, nhưng tôi không chắc nó có mở rộng tốt ở quy mô lớn hơn hay không
Việc ghi lại rồi chờ đợi mang tính tức thời, ít áp lực, lại có phần thưởng nhỏ là “danh sách đã dài thêm”, nên nếu luyện tập có hệ thống thì khá dễ học lại
Tôi thích việc tiếp tục tách riêng giai đoạn nhận ra và ghi lại, với giai đoạn sau đó là lập bản đồ, xem xét, học hỏi, rồi tập hợp và dẫn dắt những người có cùng mối quan tâm
Viết nhật ký công việc thì lúc nào cũng là ý hay, nhưng có điều gì đó trong giọng điệu của bài này khiến tôi thấy cấn
Tôi không muốn làm việc với kiểu người hành xử như Borg hay làm theo một kịch bản như lấy từ 『How to Win Friends and Influence People』
Nếu ai đó có vẻ như đang cố thao túng tôi, thì ít nhất kể từ lúc tôi nhận ra điều đó, sẽ rất khó để tin họ
Tuy vậy, cũng không nên chỉ bị cuốn theo cảm giác phản cảm tức thời đó
Bản thân tôi cũng có mục tiêu về việc muốn các bên liên quan cảm nhận tôi như thế nào, và điều đó khá hữu ích như một chuẩn hành động
Dù làm việc giỏi về mặt kỹ thuật, nếu phớt lờ khía cạnh quan hệ con người thì tôi vẫn gặp vấn đề; những lời đồn đang lan ra sao, tôi bị nhìn nhận thế nào, công việc của tôi được đóng gói ra sao, tất cả đều thực sự quan trọng
Chỉ nói “cứ làm tốt việc là được” không làm biến mất thực tế rằng công việc của tôi và cảm giác tôi tạo ra cho người khác đều quan trọng
Tôi chưa đọc 『How to Win Friends and Influence People』, nhưng tôi lại thấy bản thân bài viết này được viết khá tốt
Dù là một individual contributor dày dạn kinh nghiệm, một quản lý mới, hay một sĩ quan, thì 30–90 ngày đầu tiên nhìn chung đều nên tránh thay đổi gì mà tập trung hiểu công việc đang vận hành ra sao, và quan trọng hơn, vì sao nó lại vận hành như vậy
Cách này mang lại rất nhiều lợi ích ở cấp độ tổ chức, và nói ngắn gọn thì đó thực sự là cách nên làm
Các kỹ sư từng làm việc dưới quyền quản lý tồi, và dù không phải lúc nào cũng diễn đạt chính xác vì sao tệ, họ thường vẫn cảm nhận được
Cảm giác về “quản lý tồi” đó thường đến từ việc không làm tốt lãnh đạo ở cấp độ chiến thuật; cũng như kỹ thuật, lãnh đạo cũng là một kỹ năng có thể học được
Vấn đề là không có nhiều nơi dạy nó một cách có chủ đích như trong quân đội hay các chương trình đào tạo dành cho lãnh đạo cấp cao
Nếu bạn muốn làm việc dưới quyền một quản lý giỏi thì thực ra là bạn muốn làm việc dưới quyền một lãnh đạo giỏi, và lãnh đạo là một kỹ năng mang tính chiến thuật, giống như viết mã C++ hiệu quả vậy
Đó là việc điều phối và dẫn dắt con người để đạt được mục tiêu lớn hơn tổng những gì từng cá nhân trong nhóm có thể tạo ra riêng lẻ, nên ở một góc độ nào đó, nó có thể mang cảm giác như thao túng
Dù vậy, kiểu lãnh đạo mà kỹ sư thường thích là người bảo vệ cả nhóm khỏi những việc ngớ ngẩn từ bên ngoài, kiếm được nguồn lực cần thiết, khen ngợi công khai và phê bình riêng tư, đưa ra định hướng mà không vi mô quá mức, công nhận và tưởng thưởng thành tích, đồng thời không bỏ mặc những trường hợp dưới chuẩn
Ngược lại, nếu một kiểu chính trị gia lôi cuốn, xuất thân MBA nhưng không hiểu kỹ thuật, dùng những kỹ thuật này vì mục đích xấu, thì đó sẽ là kiểu người không ai muốn làm cùng
Những người đi lên vị trí quản lý từ nghề kỹ thuật nhưng không chấp nhận rằng quản lý là một kỹ năng khác với năng lực kỹ thuật cũng thường bị ghét
Cuối cùng, nếu cả ngành muốn có thêm nhiều lãnh đạo giỏi, thì cần phải đối xử với lãnh đạo như những bài viết kiểu này: không phải là thứ mơ hồ dựa vào tố chất bẩm sinh, mà là tập hợp các chiến thuật có thể giải thích được về cách thực hiện
Việc có được tiếng tăm kiểu “Nat giải quyết vấn đề cho tôi” thì tốt cho lời giới thiệu, nhưng có thể nguy hiểm cho sự nghiệp
Tôi đã làm như vậy suốt 20 năm ở nhiều bộ phận, và lần nào người ta cũng cố giữ tôi lại như một người xử lý vấn đề, chứ không đưa tôi vào diện ứng viên thăng chức
Một đồng nghiệp làm 40 năm rồi nghỉ hưu cũng là kiểu người giải quyết được mọi vấn đề, giỏi hơn rất nhiều so với các quản lý, nhưng vẫn không được thăng chức
Anh ấy là quân bài bí mật của mọi người nhưng hầu như không được ghi nhận, việc giải quyết vấn đề bị xem là “điều hiển nhiên”, và không có phần thưởng nào cả
Những người khác cùng cấp bậc lại được áp dụng tiêu chuẩn thấp hơn nhiều, và ngay cả trong kỳ đánh giá thành tích cuối cùng, quản lý còn nói rằng “tôi không đánh giá theo đồng nghiệp mà theo kết quả so với mục tiêu”
Tôi cũng từng nghe điều tương tự từ một quản lý khác, nên đây không phải chuyện ngẫu nhiên
Quan trọng nhất là quản lý của tôi luôn đứng về phía tôi khi phải chặn những yêu cầu không đến từ chính ông ấy
Nếu một người không quen nhờ một việc không hề nhỏ mà tôi không có thời gian hoặc không hứng thú, tôi chỉ cần nói “Hiện tại tôi không có thời gian xem việc này. Nếu cần ưu tiên thì hãy trao đổi với quản lý của tôi”, và 99 trên 100 lần thì chuyện đó không bao giờ lên đến quản lý
Lợi ích lớn nhất của việc trở thành người mọi người tìm đến trong cả bộ phận hay công ty là bạn tích lũy được người quen và mạng lưới liên hệ
Khi cần thông tin từ bên ngoài nhóm hoặc phải xuyên qua thủ tục quan liêu để làm việc quan trọng, nó hoạt động như một siêu năng lực nhỏ
Khi tìm cơ hội mới, bạn cũng có sẵn một mạng lưới để liên lạc, và toàn bộ các công việc tôi có được trong 15 năm làm ở khu vực tư nhân đều đến theo cách này
Chỉ là có thể nói rằng một trong hai cách tiếp cận thì vượt qua quy trình thăng chức rất tốt, còn cách kia thì không
Điều đó không dễ, nhưng đặt ra ranh giới là một kỹ năng quan trọng
Đoạn “Ngay khi thấy vấn đề là tôi nói ra luôn, rồi Nat có tiếng là lúc nào cũng than phiền và nghĩ rằng bất kể chúng tôi làm gì cũng sai” nên được đặt gần đầu bài hơn
Mức độ tự nhận thức như thế này là một kỹ năng thực sự đáng để rèn luyện
Cựu phi hành gia Chris Hadfield cũng nói trong sách của ông rằng khi tham gia một nhiệm vụ và một đội mới, ông dùng cách tiếp cận tương tự
Trước hết ông chuyển sang chế độ quan sát để tìm hiểu xem những khoảnh khắc WTF đó có thực sự hợp lý hay không, đồng thời tránh làm các thành viên mới trong nhóm khó chịu
Đáng đọc đấy
Sau khi làm lâu ở cùng một chỗ, tôi thấy nó giúp tạo ra một nơi để lọc và chứa bớt nhiễu, ít nhất là để nó không cứ nằm nguyên trong đầu
Không chỉ là đánh giá xem vấn đề có chính đáng hay không, mà còn gần với việc học cách buông bỏ một số thứ
Nếu bạn có thể cho biết là cuốn nào thì tốt quá
Khi bước vào một bối cảnh đã tồn tại từ trước, tôi thường tiếp cận theo cách này
Tuần đầu tiên tôi xem xét mọi thứ và ghi lại câu hỏi cùng quan sát của mình
Không chỉ những khoảnh khắc “WTF”, mà cả những thứ đang vận hành tốt và những gì tôi thấy là ý tưởng thực sự hay cũng được ghi lại
Chỉ sau đó tôi mới xem lại, sắp thứ tự ưu tiên rồi bước vào thảo luận
Đây có vẻ là một nguyên tắc rất hợp với hàng rào của Chesterton
Đó là câu chuyện nói với người muốn dỡ một hàng rào rằng “Nếu anh không biết nó dùng để làm gì thì tôi không thể cho anh dỡ nó. Hãy đi suy nghĩ đi, và chỉ khi nào anh có thể nói rằng mình đã hiểu mục đích của nó thì mới được phép bỏ nó đi”
Nói rõ hơn, điều đó có nghĩa là ngay cả khi thứ gì đó trông có vẻ kỳ cục, tốt hơn hết là giả định rằng những người đến trước không ngu ngốc và đã có lý do để làm vậy
Lý do đó giờ có thể đã lỗi thời, nhưng nếu không cân nhắc thì ta sẽ lặp lại cùng một sai lầm
Không chỉ là giữ một danh sách những thứ muốn sửa, đây còn là một ý hay vì nếu để thời gian trôi qua bạn có thể hiểu được tại sao một số thứ lại thành ra như vậy
Nhiều trường hợp có thể chỉ là làm vội hoặc mắc lỗi, nhưng đôi khi thực sự tồn tại độ phức tạp ẩn mà chỉ nhìn một dòng code thì rất khó hiểu ra ngay
Loại đầu là thất bại rõ ràng, còn loại sau thì thường sẽ tự sáng tỏ nếu bạn đủ ngấm vào môi trường đó
Dù vậy, ghi lại cả hai loại vẫn rất hữu ích
Tuần này tôi cũng đang kể với hai đồng nghiệp rằng tôi để một file “How the F” trên máy tính
Nó không hoàn toàn giống điều tác giả nói, nhưng rất gần, và mỗi khi vào một nhóm mới, cứ hễ phát sinh vấn đề kiểu “ủa, cái này lại làm thế nào nhỉ?” là tôi ghi hết vào đó
Tôi không mang nó lên cho quản lý như trong bài gốc, nhưng nó cho tôi góc nhìn để nhận ra những điểm nghẽn của nhóm và công ty, rồi dành thời gian xử lý dần
Tôi sống theo kiểu mọi ý tưởng nảy ra đều ghi vào danh sách
Không có thứ tự đặc biệt nào cả, cứ thêm tiếp vào giấy hoặc file text
Ý tưởng không xuất hiện đúng lúc cần mà cứ tìm đến suốt cả ngày khi đang làm việc khác, và nếu không ghi lại thì ít nhất là tôi sẽ không nhớ nổi
Đến khi thực sự phải làm gì đó thì chỉ cần xóa dần từng mục, khỏi phải nghĩ tiếp theo sẽ làm gì, và vì ý tưởng không bao giờ cạn nên có thể tạo ra một cú bùng nổ năng suất khá lớn
Nghe giống chuyện sắp xếp danh sách việc cá nhân hơn, trong khi bài gốc là về cách thích nghi và giao tiếp trong một nhóm
Đời quá ngắn để ngồi sắp xếp ghi chú, cứ ghi hết vào rồi dựa vào sắp xếp theo thứ tự ngược và chức năng tìm kiếm thì hơn
Trớ trêu là tôi biết mình đang có cả một kho báu ý tưởng tuyệt vời, nhưng đến tuổi này rồi thì cũng không còn đủ bận tâm để triển khai chúng như hồi tuổi 20 nữa