Tôi là người New Zealand sống ở Seoul. Bài này kể lại môi trường phát triển phần mềm ở Hàn nhìn từ bên trong, từ cả hai phía của bàn tuyển dụng, và những gì tôi muốn nói với ai đang tính chuyện sang đây làm việc.

Tôi đến đây bằng cách nào

#

Con đường của tôi bắt đầu từ bậc thạc sĩ. Sau khi học cử nhân ở Đại học Waikato và làm vận hành mạng một năm ở một công ty viễn thông tại New Zealand, tôi học thạc sĩ khoa học máy tính ở Đại học Kyung Hee từ tháng 3/2017 đến tháng 2/2019. Mỗi học kỳ, phòng lab của chúng tôi đều đi dự KSC và KCC, hai hội nghị tin học trong nước. Ở KSC 2018 tại PyeongChang, nhà tài trợ có nhiều công ty công nghệ lớn nhất Hàn Quốc, lại có cả gian hàng tuyển dụng cho ai đang tìm việc. Nếu bạn là sinh viên cao học nước ngoài ở Hàn thì điều này đáng để biết.

Từ đó đến nay:

Phần kỹ thuật là nửa quen thuộc. Startup hỗ trợ khách hàng là nơi tôi học được rằng một phần lớn việc phát hành phần mềm thực ra là vận hành, còn backend của nền tảng cho nhà sáng tạo chạy trên nhiều bộ công nghệ hơn mức tôi sẽ chọn bây giờ. Khác biệt riêng của Hàn Quốc nằm ở rìa. Naver là công cụ tìm kiếm bạn buộc phải để ý: khi ra mắt website mới cho Kiwi Alumni, tôi làm SEO cho cả Google lẫn Naver. Các nền tảng Hàn Quốc thu thập dữ liệu (crawl) bằng những cái tên bạn khó đoán ra (crawler của Naver tên là Yeti, còn bản xem trước link trong KakaoTalk là do một thứ tên kakaotalk-scrap lấy về). Và ngân hàng trực tuyến ở Hàn đến giờ vẫn đòi cài phần mềm bảo mật riêng của họ lên máy tính của bạn.

Nhưng chẳng cái nào trong số đó là phần khó.

Nunchi là gì, và vì sao nó không phải là “optics”

#

눈치 là cảm giác về việc người khác đang nghĩ gì, muốn gì, mong đợi gì, nắm bắt từ tình huống chứ không phải từ lời họ nói ra. 눈 nghĩa là “mắt”, và Euny Hong, tác giả cuốn The Power of Nunchi (2019), cuốn sách giới thiệu nunchi bằng tiếng Anh được biết đến nhiều nhất, dịch cả từ này là “eye-measure”, tức là “đo bằng mắt”. Nó xuất hiện trong mấy cách nói hằng ngày. Người “눈치가 빠르다” (nunchi nhanh) là người đọc tình huống rất nhanh, kiểu người mình gọi là tinh ý. Người “눈치가 없다” (không có nunchi) thì không đọc được gì cả, và đó chẳng phải lời khen. Còn “눈치를 보다” (nhìn nunchi) là liên tục để ý phản ứng của người khác, thường là cấp trên, rồi điều chỉnh để mình luôn ở phía an toàn, rất giống chuyện “nhìn sắc mặt” mà dân văn phòng Việt Nam hay nói.

Từ tiếng Anh mà người ta hay chọn ở đây là “optics”, và tôi nghĩ nó sai. Optics là chuyện một việc trông như thế nào từ bên ngoài, bất kể thực chất ra sao, kiểu “công bố thưởng ngay trong tuần cắt giảm nhân sự thì optics rất tệ”. Nó là chuyện hình thức, và người quản lý nó là người đang bị nhìn. Nunchi phần lớn lại chỉ theo hướng ngược lại: vấn đề không phải là bạn trông thế nào trong mắt người khác, mà là bạn nhìn người khác rõ đến đâu. Hai thứ chỉ gặp nhau ở “눈치를 보다”, khi bạn quan sát mọi người để quản lý hình ảnh của mình trong mắt họ, và đó chính là phiên bản xuất hiện trong các bài báo nước ngoài viết về văn phòng Hàn Quốc.

Ví dụ trong những bài báo đó lần nào cũng na ná nhau: không về trước trưởng nhóm, cái nunchi người ta phải để ý khi thật sự xin nghỉ phép năm (연차), biết lúc nào thì được phép rời một buổi 회식 (bữa ăn tối cùng đội), và quyết định nếu phản bác cấp trên thì nói ngay trong cuộc họp hay lặng lẽ nói sau. Dù bạn nghĩ gì về từng ví dụ, chúng đều có chung một hình dạng: mỗi cái là một quy tắc ai cũng theo mà không ai nói ra.

Và nó là một vấn đề tách biệt với ngôn ngữ. Tiếng Hàn nằm trong lời nói. Nunchi nằm trong mọi thứ xung quanh lời nói.

Nunchi lộ ra ở đâu trong một đội phát triển

#

Các đội phát triển vận hành đúng theo hình dạng đó. Vài tháng sau khi lần đầu làm quản lý, tôi viết một bài về quy ước của đội mở đầu thế này: phần lớn xích mích tôi phải xử lý không phải chuyện kỹ thuật, mà là mỗi người ngầm mặc định một kiểu về việc review code (đánh giá mã) nên được phản hồi nhanh đến đâu, “xong” thực ra nghĩa là gì, và nhắc ai đó lần thứ hai có bị coi là bất lịch sự không. Hồi đó tôi chưa dùng từ này, nhưng danh sách ấy dòng nào cũng là thứ mà nunchi phải đọc ra. Mỗi dòng là một quy tắc cả đội ngầm đồng ý mà không nói ra, và người mới chỉ có thể học bằng cách quan sát.

Cũng trong bài đó, tôi phàn nàn chuyện người mới học quy ước “như truyền miệng dân gian” thay vì được nói rõ khi nhận việc (onboarding), và chuyện các đội đa quốc gia cứ tưởng chuẩn của mình là chuẩn của tất cả mọi người. “Folklore”, truyện truyền miệng, là từ tiếng Anh hay nhất tôi tìm được để mô tả thứ mà nunchi dựa vào. Khi bạn là người nước ngoài duy nhất trong đội, chuẩn bị lệch chính là của bạn, và những “truyện truyền miệng” kia chẳng được ghi lại ở đâu để bạn đọc.

Chỗ tốn kém nhất là buổi họp đứng (standup) hằng ngày. Năm 2023 tôi có viết về một dự án tôi phụ trách bị chậm tiến độ trong khi tôi cứ chờ có ai hỏi đến. Ba tuần sau mới có người hỏi, và lúc đó mọi thứ đã thành thảm họa. Nunchi tốt không cứu được chuyện này. Đọc được không khí thì bạn biết điều gì không ai muốn nghe, nhưng nó không bảo bạn phải nói ra bất chấp. Thói quen tôi rút ra thì ngược hẳn với việc chờ đợi: nói trước, bằng văn bản, trước khi có ai hỏi. “Việc này đang lâu hơn tôi nghĩ. Giờ tôi ước tính khoảng 8 đến 10 ngày chứ không phải 5. Mình cắt bớt phạm vi hay lùi hạn chót?”

Khi bạn là người bị “đọc”

#

Tháng 2/2024, tôi bắt đầu quản lý một đội kỹ sư ở một công ty phần mềm tại Seoul, và nunchi đảo chiều. Khi còn là lập trình viên, tôi là người đọc không khí. Khi làm quản lý, tôi chính là không khí. Những gì tôi nói trong cuộc họp, những gì tôi không nói, tôi trả lời tin nhắn nhanh hay chậm, mấy giờ tôi về, tất cả đều trở thành thứ người khác có thể đọc.

Nhiều điều tôi từng viết khi còn làm trưởng dự án lại càng đúng hơn khi đã là quản lý. Nếu mọi người không thấy an toàn để nói với bạn chỗ nào đang hỏng, bạn sẽ là người biết sau cùng. Giữ thông tin quá lâu thì mọi người cảm nhận được, và tin đồn sẽ lấp đầy khoảng im lặng bạn để lại. Câu “tôi không biết” nghe như thất bại khi năm người trong phòng họp đang chờ câu trả lời của bạn, và chính vì thế mà nó đáng để nói ra. Còn câu mà tôi cứ quay lại mãi: người khác không đọc được ý định của bạn, họ chỉ đọc được lời bạn nói. Trong một đội vận hành bằng nunchi, họ vẫn sẽ cố đọc: từ nét mặt bạn, từ những gì bạn bỏ qua, từ giờ bạn ra về. Đó là lý do chính đáng để bạn chừa cho họ ít chỗ phải đoán hơn.

Những thứ tôi dựa vào đều chẳng có gì hào nhoáng. Họp 1:1 với từng người, nói về chính người đó chứ không phải về sprint, cùng một câu hỏi giản dị làm được phần lớn việc: “Có điều gì bạn cần tôi hoặc cả đội hỗ trợ để làm việc thuận hơn không?”

Một danh sách quy ước ngắn của đội, từ ba đến năm điều, ghi ở chỗ ai cũng thấy, kể cả chuyện sẽ ra sao nếu chính người quản lý vi phạm. Chủ động đi hỏi những người sẽ chẳng bao giờ lên tiếng trong một phòng tám người, thay vì chờ họ tự nói. Và một câu thẳng thắn “không được, lý do là thế này” thay cho câu “để xem đã” rồi chẳng bao giờ được nhắc lại, vì một câu trả lời mơ hồ chỉ thêm một thứ nữa khiến người ta phải nhìn sắc mặt. Khoảng một tháng sau khi tôi vào, buổi dã ngoại của đội sản phẩm bắt đầu ở một quán cà phê với một buổi workshop về giá trị của từng người và quy ước của đội. Một công ty khó có câu trả lời nào cho nunchi trực diện hơn thế: dành nguyên một buổi sáng để nói to những điều thường chẳng ai nói ra.

Được tuyển với tư cách người nước ngoài

#

Tôi không có bí kíp tìm việc nào cho Hàn Quốc. Thứ tôi có là góc nhìn của người quản lý tuyển dụng, và lời khuyên rút ra từ đó là: hãy dùng nunchi với chính công ty trước khi bạn ký hợp đồng.

Hồi còn làm quản lý và tuyển người, những lập trình viên tôi muốn tuyển nhất chẳng bao giờ có mặt trên các trang tuyển dụng, và như tôi từng viết, các nhà sáng lập thích tuyển người mình đã từng làm cùng hơn nhiều. Vậy nên cửa vào tốt nhất là bất cứ thứ gì giúp người ta thấy bạn làm việc trước khi tuyển bạn. Một kỳ thực tập ở công ty nhỏ hay lặng lẽ biến thành lời mời làm chính thức. Một cuộc thi hackathon cho người ta xem bạn làm việc suốt cả cuối tuần: năm 2023, tôi cùng ba người nữa trong một đội bốn người đã thắng Seoul Tech Impact Hackathon do Lunit Global tổ chức, với một ứng dụng giúp tìm các xe bán đồ ăn đường phố, vốn ở Hàn chẳng có địa chỉ.

Rồi còn buổi cà phê trò chuyện (coffee chat). Tôi từng viết rằng cách một người cư xử trong một cuộc nói chuyện thoải mái cho bạn biết làm việc cùng họ sẽ ra sao nhiều hơn hẳn một buổi phỏng vấn đã tập dượt, và điều đó đúng cho cả hai phía. Với ứng viên, đó là cơ hội duy nhất để đọc một đội trước khi bước vào. Nếu ngồi ở ghế ứng viên, tôi sẽ hỏi: thách thức lớn nhất đội đang gặp lúc này là gì, vì sao anh chị vào đây và điều gì giữ anh chị ở lại, và có điều gì về việc làm ở đây có thể khiến tôi bất ngờ. Câu cuối là một cách lịch sự để xin người ta nói trước cho mình phần nunchi. Câu trả lời né tránh về chuyện nghỉ việc hay định hướng công ty tự nó đã nói lên khá nhiều.

Nếu bạn đang tuyển lập trình viên nước ngoài

#

Nếu bạn điều hành một đội ở Hàn và đang tuyển một lập trình viên đến từ nơi khác, điều hữu ích nhất bạn có thể làm chính là câu trong bài viết về quy ước của đội: biến những điều ngầm hiểu thành điều nói rõ. Đừng để họ học quy tắc của bạn như truyện truyền miệng. Hãy nói với họ ngay tuần đầu: review thường được phản hồi trong bao lâu, “xong” nghĩa là gì, nhắc lần hai có bị coi là bất lịch sự không, mọi người thực tế mấy giờ thì về, và xin nghỉ phép thì ngoài cái đơn ra còn phải để ý gì nữa không. Hai câu cuối là những câu hỏi nunchi kinh điển, những điều mà người trong đội chẳng ai nghĩ đến chuyện phải nói ra.

Sau đó là những thói quen nhàm chán giúp người ta bớt phải đoán. Nói trước khi bị hỏi; một email ba gạch đầu dòng gửi các bên liên quan vào thứ Sáu (đã phát hành gì, tiếp theo làm gì, có điều gì đáng lo) chỉ mất mười phút. Hỏi thẳng những người trầm tính thay vì chờ họ lên tiếng trong cuộc họp. Đưa ra câu trả lời thật, kể cả “không”, kèm theo lý do. Và phỏng vấn mọi ứng viên bằng cùng một bộ câu hỏi, theo cùng một thang đánh giá. Điều này tôi mất một thời gian mới học được, nhưng đó là cách công bằng duy nhất để so sánh mọi người; nếu không, bạn sẽ thiên vị người mình nói chuyện gần đây nhất. Nó cũng có nghĩa là ứng viên không biết các quy tắc ngầm của đội bạn sẽ được hỏi đúng những câu mà ứng viên đã biết được hỏi.

Cộng đồng người New Zealand ở đây

#

Năm 2018, khi vẫn còn là sinh viên, tôi chụp ảnh cho một buổi ăn sáng về lãnh đạo của Kiwi Chamber, và sau đó viết rằng tôi thật sự thích làm tình nguyện cho những sự kiện thúc đẩy quan hệ giữa hai nước. Từ tháng 1/2020, tôi làm chủ tịch Kiwi Alumni, một cộng đồng dành cho người New Zealand ở Hàn Quốc và cho những ai từng học ở New Zealand nay đang sống và làm việc ở đây. Đây là vai trò tình nguyện, và phần lớn là việc với con người: tổ chức sự kiện, xây dựng quan hệ với Đại sứ quán New Zealand và các cơ sở giáo dục, cộng thêm những việc chẳng ai thấy như làm logo mới hay một website mà thành viên thật sự tìm được thứ mình cần. Năm 2023, chúng tôi cùng Đại sứ quán tổ chức Kiwi Alumni Night, và sự kiện còn lên cả KTV.

Câu tôi viết sau đêm đó là thứ gần nhất với luận điểm chính của bài này. Những người từng sống ở cả Hàn Quốc lẫn New Zealand hiểu cách nối những khác biệt, vì họ đã trải qua cả hai nền văn hóa. Nếu bạn sang đây làm việc, dù bạn đến từ đâu, hãy tìm những người như thế. Họ là người sẽ nói với bạn bằng lời lẽ rõ ràng rằng căn phòng lúc đó đã muốn nói gì.

Làm tự do từ Seoul

#

Tôi chuyển sang làm tự do vào tháng 10/2025, sau khi nghỉ việc quản lý. Thực tế đó là các hợp đồng DevOps và MLOps, phần lớn là hạ tầng tại chỗ: một cụm PostgreSQL độ sẵn sàng cao, rồi hạ tầng phục vụ LLM trên chính phần cứng đó. Làm rồi mới thấy phần kiểm soát chất lượng còn nhiều hơn phần “đi ống nước”: theo dõi trace và các cuộc hội thoại nhiều lượt để tìm xem đầu ra của mô hình bắt đầu lệch từ đâu. Từ tháng 2/2026, tôi còn làm thêm một ứng dụng chợ và cộng đồng của riêng mình.

Làm tự do không giúp bạn thoát khỏi nunchi; nó chỉ đổi thứ bạn phải đọc. Đến bất kỳ đâu, thứ đầu tiên tôi xem là hệ thống giám sát (monitoring), vì nó cho biết về một đội nhiều hơn file README. Đó là nunchi dành cho hệ thống: đọc những gì một đội thật sự làm, chứ không phải những gì họ nói là mình làm.

Điều tôi muốn nói với ai đang cân nhắc

#

1. Hãy vào bằng một cánh cửa nơi người ta thấy bạn làm việc trước khi tuyển bạn. Của tôi là bậc thạc sĩ. Một cuộc thi hackathon, một kỳ thực tập ở công ty nhỏ, hay cộng đồng người cùng nước với bạn ở đây cũng có tác dụng y như vậy, và chính trong cộng đồng bạn sẽ gặp những người từng sống ở cả hai bên.
2. Đừng gạt bỏ các công ty nhỏ; phần lớn sự nghiệp của tôi là ở đó. Ở một công ty mười người thì chẳng có ai để bạn đẩy việc nhàm chán sang, và thứ bạn làm ra thật sự được đưa vào sử dụng.
3. Đọc đội trước khi vào. Tận dụng buổi coffee chat, hỏi xem làm ở đây có gì khiến bạn bất ngờ, và đừng xem nhẹ những câu trả lời né tránh về chuyện nghỉ việc.
4. Đừng chờ bị hỏi. Một ước tính đang trễ, một thay đổi rủi ro, một quyết định người khác đang chờ: hãy nói trước, bằng văn bản.
5. Hỏi thành tiếng những quy tắc chưa được viết ra: review được phản hồi nhanh đến đâu, “xong” nghĩa là gì, nhắc lần hai có bất lịch sự không. Nếu chưa ai viết lại, hãy xung phong viết.
6. Học cả hệ sinh thái xung quanh bộ công nghệ của bạn. Ở đây, Naver và Kakao quan trọng theo những cách mà thói quen dùng Google của bạn không bao quát được.

Phần kỹ thuật là nửa bạn có thể chuẩn bị trước khi đến. Nunchi là nửa bạn học trong lúc làm, và cách nhanh nhất tôi biết để học nó là nhờ mọi người nói to phần thường không được nói ra, và tự mình nói phần của mình trước.

Một buổi cà phê trò chuyện (coffee chat) kéo dài khoảng 30–45 phút, không chính thức, ngồi ở quán cà phê hoặc gọi video. Không có bảng trắng, không có hội đồng, không có câu hỏi mẹo. Tôi kể về sản phẩm chúng tôi đang làm và vì sao lại làm nó, còn họ kể về công việc hiện tại và điều họ muốn làm tiếp theo. Cuối buổi, cả hai đều biết có nên nói chuyện sâu hơn hay không. Với tôi, tuyển dụng giống bài toán ghép cặp hơn là bài toán sàng lọc, và đây là cách nhanh nhất tôi biết để hai bên trao đổi đúng những thông tin cần cho việc ghép cặp đó.

Vì sao tôi chịu khó làm việc này

#

Tôi không còn coi những buổi này là tuyển dụng nữa. Đó chỉ là những cuộc trò chuyện, và thỉnh thoảng lại có một cuộc dẫn tới việc tuyển được người, có khi mười tám tháng sau, khi hoàn cảnh của người đó thay đổi. Những nguồn ứng viên đều đặn mang lại người giỏi đều được xây từ những mối quan hệ như vậy, chứ không phải từ tin đăng tuyển.

Những buổi cà phê này cũng giải quyết luôn vấn đề của bản mô tả công việc (JD). Bản mô tả công việc thì kiểu gì cũng phải viết chung chung. Còn khi ngồi cà phê, ứng viên có thể hỏi những câu thật sự quan trọng với họ: sáu tháng đầu thế nào thì được coi là thành công, tôi sẽ làm việc với ai, bài toán kỹ thuật khó nhằn nhất của đội lúc này là gì. Được nghe câu trả lời thành thật cho những câu hỏi đó, người ta thường tự biết mình có hợp hay không.

Hơn nữa, một buổi cà phê cho người ta tận mắt thấy văn hóa công ty bạn, thay vì chỉ nghe kể. Bạn có chuẩn bị trước không, có thật sự tò mò không, có tôn trọng thời gian của người khác không: những điều đó nói lên nhiều hơn bất kỳ trang tuyển dụng nào. Chiều ngược lại cũng thế. Cách một người cư xử trong một cuộc nói chuyện thoải mái cho bạn biết làm việc cùng họ sẽ ra sao, rõ hơn hẳn một buổi phỏng vấn mà họ đã tập dượt kỹ.

Hình thức này phát huy tác dụng nhất trong mấy trường hợp: khi tiếp cận một người hoàn toàn không tìm việc, khi muốn làm quen trước với một người được giới thiệu trước khi bắt đầu quy trình chính thức, và khi nói chuyện với ai đó đang cân nhắc rẽ hướng sự nghiệp, chẳng hạn từ người làm chuyên môn (IC) lên quản lý, từ startup sang tập đoàn, hoặc ngược lại. Khi thị trường nhân lực khan hiếm, chừng đó trường hợp đã bao gồm gần hết những người bạn muốn tuyển.

Tôi tổ chức một buổi như thế nào

#

Tin nhắn đầu tiên quyết định tất cả. Tin nhắn chung chung sẽ bị xóa ngay. Hãy tìm hiểu kỹ về người đó trước, và nói thẳng mục đích của mình:

“Chào Sarah, mình có xem bài nói của bạn về hệ thống phân tán ở QCon và mấy bài blog của bạn về event sourcing. Bên mình ở [Company] cũng đang vật lộn với những bài toán tương tự trong lúc mở rộng hạ tầng thanh toán. Bạn có muốn đi cà phê 30 phút không? Không phải phỏng vấn đâu, chỉ là mình tò mò muốn nghe góc nhìn của bạn và kể bạn nghe bên mình đang làm gì.”

Tin nhắn này hiệu quả vì nó cụ thể, nói rõ mục đích ngay từ đầu, và mang lại cho người nhận một thứ gì đó (một cuộc trò chuyện về những bài toán thú vị) chứ không chỉ xin thời gian của họ. Sau đó hãy làm cho mọi thứ thật dễ dàng: đưa ra vài khung giờ để họ chọn, chọn một chỗ tiện cho họ hoặc một công cụ gọi video không cần cài đặt, và gửi lời mời qua lịch hẳn hoi để không ai phải đoán giờ đoán chỗ.

Bản thân buổi nói chuyện chỉ cần một khung sườn lỏng lẻo. Mở đầu bằng vài phút hỏi han thật lòng và lý do bạn liên hệ. Tiếp theo là câu chuyện của họ: công việc hiện tại, điều họ thích, điều khiến họ bực mình, điều họ mong muốn ở chỗ làm tiếp theo. Ở đoạn này, việc của bạn chủ yếu là lắng nghe. Sau đó đến lượt bạn: sứ mệnh của công ty, những thách thức thật mà đội đang gặp, kể cả những phần khó khăn, vì ứng viên đánh giá cao sự minh bạch và nhận ra ngay khi bạn đang chào hàng. Đoạn đáng giá nhất là phần trò chuyện cởi mở gần cuối: cần những điều kiện gì thì họ mới cân nhắc chuyển việc? Kết thúc bằng các bước tiếp theo rõ ràng, kể cả khi bước tiếp theo chỉ là “mình giữ liên lạc nhé”.

Trong vòng 24 giờ, hãy nhắn lại một lời ngắn gọn có nhắc tới một chi tiết cụ thể trong buổi nói chuyện, và làm đúng những gì bạn đã hứa, dù là giới thiệu một người, gửi một liên kết hay bất cứ thứ gì. Chính phần việc nhàm chán sau buổi gặp này mới thể hiện rõ nhất văn hóa của bạn.

Nếu bạn làm việc này thường xuyên, hãy giữ một bảng tính đơn giản ghi lại những người đã nói chuyện và thỉnh thoảng hỏi thăm họ, kể cả khi không có vị trí nào đang tuyển. Và đây cũng không nhất thiết là việc riêng của quản lý. Nhiều buổi cà phê hay nhất lại là khi các kỹ sư của bạn đi cà phê với những người giỏi trong mạng lưới quen biết của chính họ. Những lời giới thiệu chất lượng thường đến từ đó.

Những câu hỏi đáng dành thời gian

#

Những câu tôi hay hỏi:

• “Gần đây bài toán thú vị nhất mà bạn từng làm là gì?”
• “Ở công việc tiếp theo, bạn muốn điều gì khác đi?”
• “Bạn hay học theo cách nào? Bạn muốn phát triển chuyên môn ra sao?”
• “Bạn có câu hỏi nào để đánh giá xem chỗ này có hợp với mình không?”

Những câu tôi sẽ hỏi nếu ngồi ở phía bên kia bàn:

• “Thách thức lớn nhất mà đội đang đối mặt lúc này là gì?”
• “Anh/chị đánh giá thế nào là thành công ở vị trí này?”
• “Con đường thăng tiến ở đây như thế nào?”
• “Vì sao anh/chị vào công ty này? Điều gì khiến anh/chị ở lại?”
• “Có điều gì khi làm ở đây mà có thể khiến tôi bất ngờ không?”

Nếu bạn là người được mời

#

Phần lớn những người tra “coffee chat là gì” lại đang ngồi ở phía bên kia bàn so với tôi: có ai đó vừa mời họ đi cà phê, và họ muốn biết mình sắp bước vào chuyện gì. Dưới đây là những điều tôi muốn nói với bạn, từ phía người hay gửi lời mời.

Đây không phải buổi phỏng vấn. Không ai chấm điểm bạn, cũng chẳng có bài kiểm tra nào, nên bạn không cần chuẩn bị sẵn câu trả lời. Dù vậy, đây vẫn là lần gặp đầu tiên và ấn tượng ban đầu vẫn quan trọng, nên hãy coi nó như gặp một người đồng nghiệp tương lai, chứ không phải gặp bạn của một người bạn. Điểm khác với phỏng vấn là ở đây bạn được phép tò mò, và người ta mong bạn hỏi cũng nhiều như bạn trả lời.

Về trang phục, hãy mặc như khi bạn đi làm ở công ty đó vào một ngày bình thường. Nếu không biết họ mặc thế nào thì cứ chọn phong cách lịch sự mà thoải mái (smart casual), không bao giờ sai. Nếu gặp qua video, hãy bật camera và tìm một phòng yên tĩnh; mấy chuyện đó quan trọng hơn chiếc áo bạn mặc.

Chuẩn bị mất khoảng nửa tiếng. Tìm hiểu xem công ty đó làm sản phẩm gì, và đọc qua những gì người mời bạn đã viết hoặc đã làm ra. Chuẩn bị sẵn một phần giới thiệu dài chừng hai phút về công việc hiện tại và điều bạn muốn làm tiếp theo, vì kiểu gì bạn cũng sẽ được hỏi câu đó. Mang theo hai, ba câu hỏi của riêng mình; danh sách ở phần trên là một điểm khởi đầu không tệ.

Còn nên nói chuyện gì: công việc của bạn, điều bạn thích ở công việc đó, và những gì bạn tò mò về công việc của họ. Chuyện lương thì để sau, trừ khi họ chủ động nhắc tới. Bạn hoàn toàn có thể hỏi thẳng xem họ có đang nghĩ tới vị trí nào cho bạn không, và nếu có thì quy trình tuyển dụng sẽ diễn ra thế nào.

Thường thì ai mời người đó trả tiền. Bạn cứ ngỏ ý trả, nhưng đừng giành nhau. Trong vòng một ngày, hãy gửi một lời cảm ơn ngắn có nhắc tới điều gì đó hai bên thực sự đã nói, vậy là bạn đã làm tốt hơn phần lớn mọi người rồi.

Còn nếu chính bạn muốn có một buổi coffee chat, cứ chủ động hỏi. Viết tin nhắn ngắn thôi, nói rõ vì sao bạn muốn gặp đúng người đó, và làm sao cho họ dễ nhận lời: “Chào bạn, mình vẫn theo dõi phần việc của đội bạn với tính năng tìm kiếm mới, và mình đang tính chuyển sang mảng platform engineering. Trong vài tuần tới, bạn có thể dành cho mình 30 phút đi cà phê hoặc gọi điện không? Mình sẽ sắp xếp theo lịch của bạn.” Với một lời đề nghị cụ thể như vậy, phần lớn mọi người đều đồng ý.

Những cách làm hỏng buổi cà phê

#

Cách nhanh nhất là biến nó thành một buổi phỏng vấn trá hình. Hễ bạn bắt đầu hỏi kiểm tra kỹ năng kỹ thuật hay lồng vào mấy câu hỏi hành vi là bạn đã phá vỡ thỏa thuận ngầm giữa hai bên, nên hãy để dành những thứ đó cho quy trình chính thức. Đứng thứ hai là chào hàng quá đà: những người ở lại lâu dài là những người đã biết rõ các khó khăn ngay từ lúc nhận lời. Đến mà không chuẩn bị, hoặc im bặt sau buổi gặp, thì gây hại âm thầm hơn; buổi cà phê nào cũng góp phần định hình những gì người đó kể về bạn với mạng lưới của họ.

Từ phía tôi, dấu hiệu đáng lo là một ứng viên không tò mò về bất cứ điều gì, một cuộc nói chuyện chỉ thuần túy trao đổi lợi ích, hoặc một người nhắc đến chỗ làm cũ nào cũng bằng cùng một giọng cay đắng. Ứng viên cũng nên có danh sách dấu hiệu của riêng mình: người đại diện công ty không giải thích được vì sao công việc này có ý nghĩa, những câu trả lời né tránh về tỷ lệ nghỉ việc hay định hướng của công ty, và bất kỳ ai chỉ lo chào mời bạn hơn là tìm hiểu bạn.

Không phải buổi cà phê nào cũng dẫn tới kết quả, và điều đó hoàn toàn bình thường, vì phần lớn là không. Mục đích là lần tới khi cần tuyển gấp cho một vị trí quan trọng, bạn không phải bắt đầu từ một tin tuyển dụng trống trơn, mà từ cả một loạt những cuộc trò chuyện thật. Hãy liên hệ bằng một lời mời đi cà phê, chứ không phải bằng một bản mô tả công việc.

Đọc thêm

#

Bài viết liên quan trên blog này:

• Dùng phương pháp STAR để phỏng vấn lập trình viên - khi buổi cà phê chuyển thành quy trình phỏng vấn chính thức
• Ba điều tôi ưu tiên khi mới làm quản lý kỹ thuật - điều gì giúp một đội làm việc tốt với nhau, cũng chính là thứ bạn đang tìm khi ghép cặp
• Vì sao bạn nên thực tập ở startup - bối cảnh hữu ích khi nói chuyện với người đang cân nhắc chuyển sang startup

Tài liệu bên ngoài:

• First Round Review: Hiring Engineers - các hướng dẫn tuyển dụng cho startup từ những người điều hành giàu kinh nghiệm
• Lara Hogan: “Questions for Our First 1:1” - viết cho các buổi gặp riêng 1:1, nhưng dùng khi đi cà phê cũng rất hợp
• Patrick McKenzie bàn về đàm phán lương - đáng đọc để hiểu góc nhìn của ứng viên
• Who: The A Method for Hiring - khung phương pháp tuyển dụng bài bản của Geoff Smart và Randy Street
• Harvard Business Review: Hiring and Recruitment - các bài viết dựa trên nghiên cứu về thu hút nhân tài

Từ khi nhận quản lý một đội kỹ sư hồi đầu năm, đánh giá hiệu suất với tôi đã chuyển từ chuyện người khác làm với mình thành chuyện mình phải đứng ra tổ chức. Tôi viết bài này một phần để sắp xếp lại suy nghĩ của chính mình, nên bạn hãy xem đây là ghi chép của một người đang mò đường, chứ đừng coi là chân lý.

Rốt cuộc đánh giá hiệu suất để làm gì?

#

Ở cấp nào thì mục đích cũng quy về hai điều: giúp mọi người tiếp tục học hỏi, và đảm bảo những ai đang làm vượt tầm vai trò của mình thực sự được ghi nhận và đền đáp xứng đáng.

Rất nhiều công ty nhỏ nói rằng họ không có thời gian hay nguồn lực để đánh giá hiệu suất, rồi lặng lẽ lấy thâm niên làm căn cứ duy nhất để xét xem ai đã sẵn sàng lên vị trí kỹ sư cấp cao (senior). Đó là một sai lầm, và không chỉ vì thâm niên là một thước đo lười biếng. Bỏ qua đánh giá tức là bỏ luôn kênh trao đổi hai chiều giữa công ty và nhân viên, và mối quan hệ làm việc sẽ vì thế mà đi xuống.

Chuyện này đúng theo cả hai chiều. Một kỹ sư có thể đang làm việc theo cách mà họ thật lòng tin là tốt nhất cho công ty, trong khi thói quen, phương pháp hay cách giao tiếp của họ lại đang dần lệch sang hướng chẳng giúp ích gì. Không có góp ý thì chẳng ai phát hiện ra. Ngược lại, công ty nào không bao giờ lắng nghe nhân viên qua một kênh bài bản thì cứ thế vô tư không biết mọi người thực sự nghĩ gì về công ty.

Mỗi bên nên kỳ vọng gì khi bước vào

#

Về phía nhân viên, danh sách không có gì phức tạp. Họ muốn biết công việc của mình gắn với mục tiêu của đội ra sao, mình đang làm tốt ở đâu, và cần cải thiện ở đâu, nói cụ thể chứ không phải kiểu “cần giao tiếp tốt hơn”. Họ muốn đóng góp của mình được ghi nhận, muốn có một cuộc trao đổi thực chất về lộ trình sự nghiệp và đào tạo, và một quy trình công bằng dựa trên công việc chứ không phải chuyện chính trị văn phòng.

Về phía tôi, tôi mong mọi người mang tới một bản tự đánh giá, tức là góc nhìn của chính họ về những gì đã làm tốt và chưa tốt. Tôi mong họ cởi mở đón nhận góp ý, thay vì mở màn như luật sư bào chữa. Tôi mong có một cuộc thảo luận thật lòng về mục tiêu sắp tới, và những chia sẻ thẳng thắn về việc họ thấy mình hợp với đội đến đâu. Kỳ đánh giá cũng là lúc tôi tự lên kế hoạch cho mình: cơ cấu đội, những ai có thể được thăng chức, ai cần được phát triển theo hướng nào.

Không có một khuôn mẫu chung cho mọi kỹ sư

#

Một đội kỹ sư gồm những người khác nhau về văn hóa, kinh nghiệm và chuyên môn, nên không thể dùng cùng một kịch bản đánh giá cho tất cả. Đối xử như nhau và đối xử công bằng không phải là một. Cách tiếp cận phải linh hoạt theo nhu cầu, giai đoạn sự nghiệp và mức đóng góp của từng người. Tối thiểu, bạn phải đảm bảo vai trò và trách nhiệm của mỗi kỹ sư được định nghĩa rõ ràng và thực sự tương xứng với mức lương của họ.

Chỗ nhạy cảm nhất là chức danh và lương. Khi ai đó còn băn khoăn về chức danh của mình, hoặc thấy mình đã sẵn sàng lên cấp, thì những lời động viên chung chung chẳng khác gì thuốc độc. Cái có tác dụng là những thứ cụ thể: cùng thống nhất một số thử thách hoặc mục tiêu dự án cụ thể làm mốc cho cấp tiếp theo, để chuyện thăng tiến có tiêu chí khách quan chứ không dựa vào cảm tính. Lương cũng vậy. Nếu ai đó thấy mình đang bị trả thấp, hoặc muốn nhận thêm trách nhiệm, hãy đưa vào kế hoạch của họ những mục tiêu đo được, nói rõ cần đạt được gì trước kỳ đánh giá tới thì mới có cơ sở để điều chỉnh. Rồi đến kỳ đánh giá đó, cả hai bên phải giữ đúng lời.

Góp ý về những điểm cần cải thiện cũng phải cụ thể như vậy. Một khóa đào tạo, một buổi workshop hay một dự án cụ thể nhắm vào đúng một điểm yếu cụ thể thì có ích. Còn một câu “tiếp tục nâng cao kỹ năng nhé” thì không.

Đặt mốc ngay từ buổi gặp đầu tiên

#

Buổi đánh giá đầu tiên với một thành viên mới trong đội chủ yếu là để đặt mốc ban đầu. Hai bên cùng xem lại vai trò đó thực sự gồm những việc gì, và nó đóng góp vào mục tiêu của đội, của công ty như thế nào. Thống nhất những kết quả đo được sẽ dùng để đánh giá hiệu suất. Đặt mục tiêu cho ngắn hạn và cho xa hơn. Đây cũng là lúc thích hợp để nói về văn hóa và cách hành xử mà đội kỳ vọng, góp ý sẽ được đưa ra như thế nào và vào lúc nào, người đó có thể dựa vào những nguồn lực và sự kèm cặp nào, và lộ trình sự nghiệp từ vị trí hiện tại của họ trông ra sao. Chẳng có gì trong số này hấp dẫn cả, nhưng nhờ có buổi này mà mọi kỳ đánh giá về sau đều dễ hơn.

Chương trình tôi dùng cho các kỳ sau

#

1. Nói chuyện phiếm. Nghe thì có vẻ vặt vãnh, nhưng nó giúp không khí bớt căng, và nhờ vậy mà phần còn lại của buổi nói chuyện thành thật hơn.
2. Điểm qua chương trình buổi gặp để không ai bị bất ngờ vì một chủ đề nào đó.
3. Những tiến bộ kể từ kỳ đánh giá trước: nói rõ ra họ đã tiến bộ ở đâu, vì hiếm ai tự nhận ra sự tiến bộ của mình.
4. Hiệu suất hiện tại, bắt đầu từ điểm mạnh.
5. Những điểm cần cải thiện, mỗi điểm kèm theo một mục tiêu cụ thể và thực tế.
6. Kế hoạch sự nghiệp, và công việc hiện tại có thực sự đưa họ tới đó không.
7. Chỉ tiêu, mục tiêu và những việc cụ thể cần làm trước kỳ đánh giá tới.

KPI chỉ có tác dụng khi được may đo cho từng người

#

Với kỹ sư trong một đội sản phẩm, KPI phải phù hợp với cả mục tiêu của đội lẫn từng cá nhân. Front-end, back-end và full-stack là những vai trò khác nhau, còn kỹ sư mới vào nghề (junior) và kỹ sư cấp cao thì càng khác nhau hơn nữa. Số lượng commit có thể nói lên điều gì đó về một lập trình viên mới vào nghề, nhưng lại chẳng nói được gì về một kỹ sư cấp cao mà thành quả chính là các quyết định kiến trúc. Vì thế, KPI phải được đặt ra qua trao đổi, chứ không phải chép từ một mẫu có sẵn.

Những mảng tôi thường xem xét:

• Chất lượng mã: tỉ lệ lỗi, mức độ tuân thủ các chuẩn chung, công việc của họ có hay phải sửa lỗi lại không
• Tiến độ dự án: các mốc và hạn chót đã hoàn thành đúng hẹn
• Đổi mới và giải quyết vấn đề: những cải thiện về hiệu quả, những bài toán khó thực sự được giải quyết
• Cộng tác: rà soát mã cho đồng nghiệp, đóng góp vào mục tiêu và các cuộc thảo luận của đội
• Phát triển bản thân: các mục tiêu học tập đã đạt, chứng chỉ, công nghệ mới đã nắm được
• Tác động tới khách hàng: góp ý từ người dùng, mức độ người dùng sử dụng những tính năng mà họ đã phát hành

Về phần đo lường được, kiểm thử đơn vị (unit test) là một yếu tố mà tôi ngày càng thấy ưng. Bài viết này trên InfoQ bàn về việc đưa kiểm thử đơn vị vào đánh giá hiệu suất, cả cách làm cụ thể lẫn ảnh hưởng của nó tới văn hóa của đội, và cho rằng nên kết hợp cả thước đo định tính lẫn định lượng về độ “khỏe” của mã nguồn. Đáng đọc nếu bạn đang tìm những KPI không biến kỹ sư thành những con số đếm dòng mã.

Chọn KPI nào thì chọn, hãy cùng nhau thống nhất trong buổi đánh giá hoặc buổi 1:1, và xem lại mỗi khi vai trò, dự án hay công nghệ thay đổi. Một KPI mà không ai đồng ý thì chẳng khác gì cây roi.

Mẫu tôi dùng để ghi

#

Mỗi người tôi giữ một tài liệu riêng, và mỗi kỳ đánh giá thì thêm một mục mới vào đó, để toàn bộ lịch sử nằm ở cùng một chỗ. Đây là khung sườn:

## Đánh giá hiệu suất: [Tên], [kỳ đánh giá]

**Vai trò và cấp bậc:** [chức danh, và cấp bậc đó nghĩa là gì trong đội này]
**Mục tiêu từ kỳ trước:** [chép lại từ mục của kỳ trước]

### Tự đánh giá (kỹ sư điền trước buổi gặp)
- Những gì đã làm tốt, kèm một hai ví dụ
- Những gì chưa tốt, và lần sau sẽ làm khác đi thế nào
- Một năm nữa muốn được làm gì

### Tiến độ với các mục tiêu của kỳ trước
- [Mục tiêu]: đạt / đạt một phần / chưa đạt, kèm bằng chứng

### Điểm mạnh (kèm ví dụ cụ thể)
- [Đã làm gì, khi nào, và điều đó thay đổi được gì]

### Điểm cần cải thiện (mỗi điểm kèm một mục tiêu)
- [Hành vi hoặc kỹ năng] → [thế nào thì được coi là "tốt hơn"] trước [ngày]

### Lộ trình sự nghiệp và cấp bậc
- Đang ở đâu so với cấp tiếp theo, và còn thiếu gì

### Mục tiêu đến kỳ đánh giá sau
1. [Mục tiêu đo được]
2. [Mục tiêu đo được]

### Những việc đã thống nhất
- [Ai] sẽ [làm gì] trước [khi nào]

Bản tự đánh giá phải được gửi tới trước buổi gặp một hai ngày, không bao giờ để đến lúc ngồi họp mới làm. Đọc trước bản này khiến cuộc nói chuyện khác hẳn: cứ hai lần thì có một lần chính kỹ sư đã tự nêu ra đúng điều tôi định nói, và hai bên có thể dành cả buổi để bàn xem nên làm gì với nó.

Câu hỏi cho phần tự đánh giá

#

Đây là những câu hỏi gợi ý mà tôi gửi trước cho mọi người. Tôi cố tình để chúng ở dạng câu hỏi mở, để câu trả lời cho tôi biết người đó nhìn nhận công việc của chính mình ra sao, chứ không chỉ liệt kê họ đã làm những gì:

• Kể từ kỳ đánh giá trước, bạn tự hào nhất về điều gì, và vì sao lại là điều đó?
• Bạn đã bị vướng ở đâu, và điều gì có thể giúp bạn gỡ được sớm hơn?
• Có góp ý nào từ đồng đội hay người rà soát mã cho bạn mà bạn vẫn còn nhớ mãi?
• Trong các mục tiêu của kỳ trước, bạn nghĩ mình đã đạt những mục tiêu nào, và muốn bỏ hay thay đổi mục tiêu nào?
• Tiếp theo bạn muốn học gì, và công việc hiện tại có cho bạn cơ hội học điều đó không?
• Với vai trò là quản lý của bạn, tôi nên làm gì khác đi?

Câu cuối cùng là câu khiến người ta im lặng ngượng ngùng lâu nhất, nhưng cũng mang lại những câu trả lời có ích nhất.

Góp ý cụ thể nghe như thế nào

#

Phần lớn những góp ý tồi trong buổi đánh giá không tệ vì gay gắt, mà vì mơ hồ. Dưới đây là sự khác biệt, kèm những ví dụ theo kiểu mà tôi cố gắng viết:

Mỗi góp ý cụ thể đều nêu ra một sự việc, nói rõ sự việc đó đã dẫn tới điều gì, và chỉ ra một việc người đó có thể làm tiếp theo. Viết như vậy tốn thời gian hơn, và đó chính là lý do tôi tự bắt mình ghi lại ví dụ dần dần trong suốt cả quý, thay vì đến tối hôm trước buổi đánh giá mới cố nhớ lại.

Viết ra giấy

#

Sau buổi gặp, hãy viết một bản tóm tắt: những điểm chính đã bàn, các vấn đề được nêu ra, những việc cần làm, và những mục tiêu mà cả hai đã thống nhất. Nghe thì có vẻ quan liêu, nhưng chính bản ghi này giúp tránh được màn “ơ, đâu có thống nhất như vậy” sáu tháng sau. Vấn đề nào đã ghi lại thì sẽ được theo dõi thay vì bốc hơi, danh sách việc cần làm trở thành phần mở đầu cho chương trình kỳ đánh giá sau, và người ta cũng nghiêm túc với mục tiêu hơn khi nó đã nằm trên giấy.

Toàn bộ hệ thống thật ra chỉ có vậy: kỳ vọng rõ ràng ngay từ ngày đầu, KPI may đo cho từng người, mọi thứ đều được ghi lại, và theo sát tới cùng từng việc cần làm. Một buổi đánh giá mà không phải là cuộc trao đổi hai chiều với kết quả đo được thì chỉ là làm cho có, và kỹ sư thì ngửi thấy mùi “làm cho có” ngay từ lúc nhận lời mời họp.

Tôi cũng sắp bước sang vai trò này, nên thời gian gần đây tôi đi hỏi chuyện những người đã từng chuyển, và tìm được gì thì đọc nấy. Bài học rõ nhất cho tới giờ là: từ kỹ sư lên quản lý kỹ thuật (Engineering Manager) không phải là leo thêm một bậc. Thực ra bạn đang bước ngang sang một công việc khác hẳn. Thành quả của bạn không còn là những dòng mã mình viết ra, mà là những gì cả đội làm ra. Ai cũng nói vậy, và theo tôi thấy thì ai cũng vẫn xem nhẹ chuyện này.

Những gì thực sự thay đổi

Bạn không còn trực tiếp giải các bài toán kỹ thuật nữa, mà chuyển sang giải các bài toán về con người. Lịch làm việc kín mít những buổi 1:1, họp lên kế hoạch, họp để các đội thống nhất với nhau. Chuyện tuyển dụng và đánh giá hiệu suất giờ đổ lên đầu bạn. Phần lớn công việc là lo cho đội có đủ những gì họ cần để yên tâm làm việc: đủ bối cảnh, thứ tự ưu tiên rõ ràng, và càng ít chuyện vớ vẩn càng tốt.

Cái khó là bạn vẫn phải giữ đủ trình độ kỹ thuật để không bị lép vế khi bàn về kiến trúc và để đưa ra những quyết định hợp lý, trong khi lại phải chấp nhận rằng mình không còn là người trực tiếp viết mã. Những người quản lý tôi từng thấy cố ôm cả hai việc thường làm dở cả hai.

Kỹ sư và quản lý kỹ thuật, đặt cạnh nhau

Trong bảng này, vòng phản hồi là điều mà những người đi trước hay dặn tôi nhất. Làm kỹ sư thì gần như ngày nào bạn cũng có một chiến thắng nho nhỏ. Làm quản lý thì thành quả vẫn có thật, nhưng đến chậm, và bạn phải quen với việc có khi phải mất một thời gian khá lâu mới biết một quyết định của mình là đúng hay sai.

Những kỹ năng có vẻ quan trọng

Giao tiếp chiếm gần hết công việc. Bạn trở thành người “phiên dịch” giữa đội mình, bộ phận sản phẩm và ban lãnh đạo, và một phần lớn đến bất ngờ của công việc chỉ là đảm bảo ba bên đang nói về cùng một chuyện. Niềm tin quan trọng hơn mọi quy trình: nếu mọi người không thấy yên tâm khi báo với bạn chỗ nào đang hỏng, bạn sẽ là người biết chuyện sau cùng. Lịch làm việc thì sẽ tìm mọi cách nuốt chửng bạn, nên giữ lại thời gian để suy nghĩ, và thời gian cho đội, là một cuộc chiến không có hồi kết. Cuối cùng, bạn phải hiểu công ty thực sự đang muốn đạt được điều gì, không thì bạn chẳng thể chỉ cho ai một hướng đi có ích.

Chuẩn bị từ trước khi có chức danh

Lời khuyên tôi nghe đi nghe lại, và cũng là điều tôi đã tự kiểm chứng được: hãy bắt đầu dẫn dắt trước khi có ai trao chức danh cho bạn. Đứng ra lo một dự án, kèm cặp một đồng nghiệp, hay tổ chức một việc gì đó. Suốt năm qua tôi làm trưởng dự án, và trải nghiệm đó giúp tôi nhiều hơn bất kỳ cuốn sách nào. Dù vậy, sách vẫn có ích. Cuốn “The Manager’s Path” của Camille Fournier thì ai cũng giới thiệu, và đọc xong tôi hiểu vì sao. Đừng để kỹ năng kỹ thuật bị cùn, vì các cuộc tranh luận về kiến trúc sẽ không dừng lại đâu. Và hãy tìm một người cố vấn (mentor) đã từng đi qua con đường này, họ sẽ giúp bạn tránh những sai lầm mà chỉ khi nhìn lại mới thấy hiển nhiên.

Được cái này, mất cái kia

Bạn có nhiều tiếng nói hơn trong chuyện sản phẩm được làm ra như thế nào, nhưng lại hiếm khi tự tay làm. Tôi đoán sẽ có những ngày thấy chuyện đó thật tuyệt, và cũng có những ngày nhớ viết mã đến phát điên. Ai từng chuyển sang vai trò này cũng bảo tôi đó là chuyện bình thường. Sáu tháng nữa hỏi lại tôi nhé.

Dạo này tôi hay nghĩ về chuyện đó, vì chính tôi cũng đang dẫn dắt dự án, và tôi hiểu cảm giác muốn chém gió là có thật. Khi có người hỏi bạn một câu giữa cuộc họp và năm người khác đang chờ bạn trả lời, nói “Tôi không biết” nghe cứ như mình thất bại. Nhưng không phải vậy. Phần lớn thời gian, đó lại là câu trả lời có sức nặng nhất mà bạn có thể đưa ra, miễn là bạn nói tiếp xem sau đó sẽ làm gì: sẽ hỏi ai, hoặc khi nào sẽ quay lại với câu trả lời.

Chém gió sớm muộn cũng lộ

#

Công nghệ phần mềm thay đổi quá nhanh, không ai nhớ hết được mọi thứ, còn kỹ sư thì đứng tận cuối phòng cũng nhận ra ai đang chém gió. Lần đầu tiên cả đội bắt gặp bạn giả vờ biết một điều gì đó, họ sẽ lặng lẽ bớt tin mọi điều khác bạn nói. Ngược lại, một người quản lý dám thừa nhận chỗ mình còn hổng rồi đi tìm hiểu cho ra thì lại được điều ngược lại: mọi người tin những câu trả lời thật của họ, vì ai cũng nhận ra đâu là câu trả lời thật khi nghe thấy.

Đó là điểm khởi đầu, chứ chưa phải câu trả lời

#

Mấu chốt nằm ở những gì bạn làm sau đó. Nói “Tôi không biết” rồi thôi thì cũng chỉ là nhún vai cho qua. Những người quản lý giỏi sẽ làm tiếp một bước: đặt những câu hỏi tốt hơn, kiểu “cái này so với thứ mình đang dùng thì thế nào?”, “nếu mình nhận định sai chỗ này thì cái gì sẽ hỏng?”, rồi mang những câu hỏi đó đến đúng người. Đội nào cũng có một người gần như sống luôn trong cơ sở dữ liệu, một người thuộc lòng mọi trường hợp biên (edge case) khó chịu ở phía giao diện. Bạn không cần biết mọi thứ; bạn chỉ cần biết ai là người biết, và chịu khó đi hỏi họ.

Nói “tôi không biết” ở chỗ làm sao cho khéo, không bị coi là thiếu chuẩn bị

#

Nguyên tắc tôi cố giữ là: đừng bao giờ để “tôi không biết” là chữ cuối cùng trong câu. Dưới đây là vài cách nói mà bạn có thể dùng ngay:

• “Cái này hiện mình chưa nắm được. Để mình tìm hiểu rồi báo lại trước thứ Năm nhé.”
• “Phần này anh Minh rành hơn mình nhiều, mình hỏi anh ấy luôn đi.”
• “Mình chưa chắc lắm. Mình nghĩ nhiều khả năng là X, nhưng trước khi chốt thì mình muốn kiểm tra lại Y đã.”
• “Số liệu đó giờ mình không có sẵn, họp xong mình gửi vào nhóm chat nhé.”
• “Phần này em chưa nắm rõ, em xin phép kiểm tra lại rồi phản hồi anh chị sau ạ.” (khi nói với cấp trên hoặc khách hàng)

Nói “tôi không biết” có bất lịch sự không? Không, nếu đi kèm một bước tiếp theo. Điều thực sự khiến người khác khó chịu là một câu “không biết nữa” bỏ lửng, chẳng giúp ai tiến thêm bước nào, hoặc một câu trả lời đầy tự tin mà sau đó hóa ra là bịa. Đi phỏng vấn cũng vậy: không biết thì cứ nói là không biết, rồi trình bày bạn sẽ tìm hiểu như thế nào. Như vậy nhà tuyển dụng thấy được về bạn nhiều hơn hẳn một câu đoán mò.

Quyết định tốt hơn

#

Trong phần mềm, một quyết định đã đưa ra thường sẽ tồn tại khá lâu, nên cần thành thật xem phần nào mình chắc chắn và phần nào mình chỉ đang đoán. Thừa nhận chỗ hổng ngay từ đầu thì bạn sẽ đi tìm thêm thông tin còn thiếu trước khi quyết định, chứ không phải sau đó. Nó cũng cho những người không đồng tình với bạn cơ hội lên tiếng, đúng vào lúc bạn cần nghe họ nhất. Khi đã quyết rồi, hãy giải thích lý do. Và nếu hóa ra bạn sai, cũng hãy nói luôn. Không gì làm một đội mất đi sự thẳng thắn nhanh bằng một người quản lý không chịu nhận là mình đã quyết định sai.

Chẳng có gì phức tạp ở đây cả. Hãy đặt câu hỏi, lắng nghe những người biết nhiều hơn mình (lúc nào cũng có người biết nhiều hơn bạn), và nói rõ khi mình đang đoán. Câu “Tôi không biết, nhưng để mình tìm hiểu xem” đã giúp tôi có uy tín hơn bất kỳ câu trả lời chém gió cho qua chuyện nào tôi từng đưa ra.

Chẳng ai thích bị hỏi “việc đến đâu rồi?”, nhưng đã là người dẫn dắt dự án ở công ty thì tôi vẫn phải nắm được tình hình. Cách dung hòa của tôi là biểu đồ lịch sử Git (git graph): trước khi hỏi ai điều gì, tôi mở nó ra xem trước, và phần lớn thời gian câu trả lời đã nằm sẵn ở đó. Chỉ cần liếc qua là thấy được hoạt động commit, các nhánh được tạo ra và hợp nhất (merge) vào ra sao, mà chẳng ai phải ngồi họp vì chuyện đó.

Biểu đồ thực sự nói lên điều gì

#

Nếu bạn chưa từng nhìn kỹ loại biểu đồ này: mỗi nút là một commit, mỗi đường tách ra là một nhánh, và cả biểu đồ đọc lên giống như dòng thời gian của dự án. Cách trình bày này chứa nhiều thông tin hơn bạn tưởng:

• Liếc một cái là biết đang có bao nhiêu nhánh hoạt động và commit được đẩy lên đều đặn cỡ nào.
• Một nhánh bỗng dưng im ắng, hay một nhánh mấy tuần rồi chưa hợp nhất, thường có nghĩa là ai đó đang bị kẹt. Đây là tín hiệu cảnh báo sớm rất đáng giá.
• Tần suất hợp nhất cho bạn biết cả đội đang phối hợp với nhau thế nào. Hợp nhất thường xuyên nghĩa là phần việc của mọi người thực sự đang được ghép lại với nhau; còn nhánh tồn tại quá lâu thường là dấu hiệu có người đang làm một mình một cõi.

Ít làm phiền hơn, trao đổi chất lượng hơn

#

Cái lợi dễ thấy nhất là tôi không phải làm phiền ai mới nắm được tình hình. Nhưng cái lợi lớn hơn nằm ở những lúc thật sự cần nói chuyện: cuộc trao đổi bắt đầu từ những gì biểu đồ cho thấy, chứ không phải từ phỏng đoán. “Nhánh này đứng yên từ thứ Ba rồi, có gì đang vướng không?” là câu mở đầu tốt hơn nhiều so với “có gì mới không?”

Nói rõ thói quen này cho mọi người biết cũng giúp ích. Tôi thường liếc nhanh vào hầu hết các buổi sáng, và xem kỹ mỗi tuần một lần. Cả đội đều biết nhịp đó, nên không ai bị bất ngờ.

Đừng biến nó thành công cụ theo dõi nhân viên

#

Đây là điều tôi phải tự nhắc mình hoài. Số lượng commit không đồng nghĩa với giá trị: một commit chỉn chu có khi đáng giá hơn năm mươi commit lặt vặt. Thấy được mọi commit không có nghĩa là bạn có quyền chất vấn mọi quyết định. Hãy tin đội của mình, và chỉ nhảy vào khi thấy một xu hướng thật sự có vấn đề. Còn khi đem biểu đồ ra trong một buổi trao đổi, hãy dùng nó làm điểm khởi đầu để góp ý, chứ không phải làm bằng chứng để buộc tội ai.

Xem biểu đồ trong terminal

#

Chỉ cần có Git là đủ, không phải cài thêm gì:

git log --graph --oneline --all --decorate

Ý nghĩa của từng tùy chọn:

• --graph: vẽ các đường nhánh và đường hợp nhất (merge) ở phía bên trái.
• --oneline: mỗi commit gói gọn trong một dòng, gồm mã hash rút gọn và dòng đầu tiên của thông điệp commit.
• --all: hiện tất cả các nhánh và tag, kể cả nhánh trên remote, chứ không chỉ nhánh bạn đang đứng.
• --decorate: in tên nhánh và tag cạnh commit mà chúng trỏ tới. Các bản Git gần đây đã tự làm việc này khi kết quả hiện ra terminal, nhưng thêm tùy chọn này thì khi bạn chuyển kết quả sang lệnh khác qua pipe, tên nhánh vẫn còn.

Sáng nào cũng gõ nguyên câu lệnh dài như vậy thì mệt, nên hãy tạo một alias:

git config --global alias.graph "log --graph --oneline --all --decorate"
git graph

Với một kho mã (repository) đã chạy lâu năm, biểu đồ đầy đủ sẽ dài cuộn mãi không hết. Vài cách để thu gọn lại:

git graph --since="2 weeks ago"    # chỉ hai tuần gần nhất
git graph -20                      # chỉ 20 commit gần nhất
git log --graph --oneline main..feature                # có ở feature, chưa có ở main
git log --graph --oneline --left-right main...feature  # cả hai phía, đánh dấu < và >

Hai dòng cuối dùng để so sánh hai nhánh. Ở đây tôi dùng git log thường chứ không dùng alias, vì alias có --all sẽ kéo tất cả các nhánh khác vào lại. Hai dấu chấm cho bạn thấy những gì feature có mà main chưa có. Ba dấu chấm kèm --left-right thì hiện cả hai phía, mỗi bên có gì mà bên kia không có, nên đây là cách nhanh để xem một nhánh tồn tại lâu đã đi lệch xa đến đâu.

Xem biểu đồ trong VS Code

#

VS Code có sẵn biểu đồ. Mở khung Source Control (Ctrl+Shift+G), bạn sẽ thấy Source Control Graph là một phần trong khung đó; tính năng này có từ phiên bản 1.93 (tháng 8 năm 2024). Mặc định, biểu đồ chỉ bám theo nhánh hiện tại và nhánh remote tương ứng, nhưng bạn có thể thêm các nhánh khác bằng bộ chọn nhánh trên thanh tiêu đề của biểu đồ. Nếu chỉ cần liếc qua thì như vậy là đủ.

Muốn xem tất cả các nhánh cùng lúc thì cài extension Git Graph của tác giả mhutchie (tìm “Git Graph” trong khung Extensions). Bạn có thể mở nó bằng mục Git Graph trên thanh trạng thái (status bar), biểu tượng Git Graph ở đầu khung Source Control, hoặc lệnh Git Graph: View Git Graph (git log) trong Command Palette. Bấm vào một commit để xem các tệp đã thay đổi, hoặc bấm vào một commit rồi giữ Ctrl/Cmd bấm vào commit khác để so sánh hai commit với nhau. Extension này không có bản phát hành mới nào từ năm 2021, nên biết thêm cách dùng biểu đồ có sẵn của VS Code cũng không thừa.

Nếu không thấy nút Git Graph đâu, nhiều khả năng extension chưa tìm thấy repository nào. Theo mặc định, nó chỉ kiểm tra đúng thư mục bạn mở, không tìm vào các thư mục con. Hãy mở thẳng thư mục của repository, hoặc tăng giá trị git-graph.maxDepthOfRepoSearch trong phần cài đặt.

Các công cụ khác

#

Hầu hết công cụ Git đều có biểu đồ ở đâu đó. gitk --all là trình duyệt lịch sử commit có sẵn của chính Git. GitHub, GitLab và Bitbucket đều có chế độ xem “network” hoặc “graph” ngay trong trang repository. Các ứng dụng desktop như SourceTree (miễn phí, của Atlassian), GitKraken, Tower và TortoiseGit trên Windows cũng đều vẽ được biểu đồ.

Chọn công cụ nào cũng được, mục tiêu vẫn chỉ có một: hiểu tiến độ, chứ không phải đi đếm commit.