Nguyen Le PhongNguyen Le Phong

Onboarding sao cho người mới đỡ tự bơi

Onboarding tốt không phải nhồi thật nhiều tài liệu trong tuần đầu, mà là giúp người mới có bản đồ, có chỗ hỏi, có một việc thật để bắt đầu và có đủ an toàn để học.

Sáng đầu tiên ở một nhóm mới thường không rộn ràng như trong slide chào mừng. Laptop còn đang cài công cụ, chat mở sẵn một lời chào, sáu tab trình duyệt cùng xin quyền truy cập. Mọi người đều thân thiện, nhưng ai cũng có việc. Người mới bảo “không sao đâu”, rồi lặng lẽ ghi nhớ một mớ điều chưa rõ mà chính họ cũng chưa biết phải hỏi từ đâu.

Một người ngồi trước laptop có nhiều hộp thoại và thanh tiến trình tại bàn làm việc cạnh cửa sổ.
Buổi đầu dễ bị mắc ở những việc rất nhỏ; một lộ trình rõ ràng giúp người mới biết mình đang ở đâu và cần làm gì tiếp.

Onboarding tốt bắt đầu từ việc coi khoảnh khắc đó là việc thật mà cả nhóm phải cùng lo. Nó không chỉ là danh sách tài khoản cần tạo, tài liệu cần đọc và vài cuộc giới thiệu. Đây là lần đầu một người nhìn thấy mọi người xử lý sự mơ hồ, lỗi sai, câu hỏi và cảm giác thuộc về như thế nào. Nhóm có thể nói rất hay về ownership, nhưng nếu tuần đầu chỉ toàn tự đoán trong im lặng thì bài học họ nhận được sẽ hoàn toàn khác.

Mục tiêu cũng không phải ép ai đó phải “làm ra việc” ngay ngày đầu. Áp lực ấy thường sinh ra một màn trình diễn: một pull request bé đến mức chẳng giúp hiểu sản phẩm, một vòng giới thiệu kiến trúc chạy nhanh như đọc tên ga tàu, hoặc lịch họp kín đến nỗi không còn thời gian tiêu hóa. Điều người mới cần trước tiên là phương hướng. Sản phẩm giải quyết việc gì, ai đang dùng, nhóm ra quyết định ra sao, khu vực nào của codebase dễ gây sự cố, và khi bí thì nên tìm ai.

Trước khi giao việc, hãy cho người mới bối cảnh. Cài xong dependency chưa có nghĩa là hiểu vì sao hệ thống tồn tại. Một câu chuyện mạch lạc sẽ hữu ích hơn nhiều: khách hàng đang cố hoàn thành việc gì, luồng nào quan trọng nhất, sự cố nào đã dẫn tới quy tắc hiện tại, và vì sao codebase lại mang hình dạng này. Kiến trúc có lộn xộn đến đâu cũng bớt đáng ngại khi biết con đường đã dẫn tới nó. Không có câu chuyện ấy, mỗi thư mục đều giống một câu đố dùng để thử người mới.

Vài tuần đầu nên có nhịp vừa đủ. Ngày đầu lo quyền truy cập và môi trường local, đi một vòng sản phẩm và chỉ rõ buddy. Tuần đầu làm một hoặc hai thay đổi nhỏ, với review kiên nhẫn. Tuần thứ hai bước vào một mảng tính năng thật, chứ không chỉ dọn việc lặt vặt. Trong tháng đầu, người mới nên có đủ bối cảnh để tự nhận một việc có phạm vi rõ, đặt câu hỏi tốt hơn và tham gia các nếp làm việc của nhóm mà không còn thấy mình là khách.

Vai trò buddy hay bị hiểu quá đơn giản. Buddy không phải manager, cũng không phải tổng đài cứu hộ 24/7. Họ là cánh cửa đầu tiên đủ an toàn để gõ. Họ giải thích thói quen của nhóm, gỡ nghĩa những từ viết tắt khó hiểu, chỉ đúng người phụ trách và làm cho các câu hỏi nhỏ trở nên bình thường. Buddy tốt không chỉ đưa đáp án; họ trao bản đồ: kênh nào dùng cho việc gì, tài liệu nào còn đáng tin, phần nào của hệ thống chịu trách nhiệm cho việc gì, và lúc nào nên hỏi công khai để cả nhóm cùng học.

Hai người cùng xem một sơ đồ khối vẽ trên giấy, bên cạnh laptop và sổ ghi chép.
Một tấm bản đồ đơn giản có thể tiết kiệm rất nhiều lần mò khi người mới chưa biết các phần của hệ thống nối với nhau ra sao.

Tài liệu chỉ thật sự giúp ích khi được viết cho một tuần đầu có thật, không phải cho người vốn đã thuộc hệ thống. Hướng dẫn cài đặt cần ghi rõ phiên bản, lỗi thường gặp và dấu hiệu cho biết đã chạy thành công. Ghi chú kiến trúc nên kể cả những đánh đổi lẫn quyết định cũ, thay vì chỉ vẽ vài ô. Runbook phải giúp người đọc nhận ra dịch vụ đang khỏe hay đang có vấn đề. Tài liệu tốt không thay thế trao đổi; nó giúp cuộc trao đổi đi thẳng vào chỗ đang kẹt.

Chiến thắng nhỏ đầu tiên vẫn rất quan trọng. Pull request đầu nên đủ thật để chạm vào sản phẩm, nhưng đủ gọn để không đòi hỏi hiểu cả công ty. Review cần kỹ mà không làm người viết co lại. Chính ở đây nhóm thể hiện chuẩn của mình: PR cần bao nhiêu bối cảnh, test nên bảo vệ điều gì, lời góp ý được viết với giọng ra sao, và bất đồng được xử lý thế nào. Người mới thường hiểu văn hóa qua lần review đầu nhanh hơn qua cả bộ slide onboarding.

Hai người cùng nhìn màn hình laptop hiển thị code và các khung trao đổi, một người đang chỉ bằng bút.
Một buổi review trực tiếp cho thấy chuẩn kỹ thuật và cách góp ý của nhóm rõ hơn nhiều lời giới thiệu chung chung.

Cũng nên có chỗ để trao đổi riêng. Không phải ai cũng dám nói “mình đang lạc” giữa group chat, nhất là khi họ còn muốn chứng minh rằng mình xứng đáng có mặt. Mỗi tuần chỉ cần hỏi ba câu: điều gì làm bạn bất ngờ, điều gì vẫn khó hiểu, và phần nào nên được giải thích tốt hơn cho người đến sau? Câu trả lời không chỉ giúp người mới. Nó soi lại những bất tiện mà người cũ đã quen đến mức không còn nhìn thấy.

Vì vậy onboarding cũng là một thói quen lãnh đạo. Nếu người mới nào cũng mắc ở bước dựng môi trường local, đừng ca ngợi sự kiên trì của họ; hãy sửa cách cài đặt. Nếu ai cũng hỏi cùng một câu về kiến trúc, đừng lặp lại câu trả lời mãi; hãy bổ sung phần bối cảnh còn thiếu. Mỗi người mới đem tới một cơ hội hiếm: nhìn những chỗ mù cũ bằng đôi mắt chưa bị quen hóa.

Một đợt onboarding ổn không làm người mới thấy mình bị chấm điểm nhiều hơn. Nó giúp họ biết đủ để bắt đầu đóng góp, đủ để hỏi câu có ích, và đủ yên tâm rằng không ai trông đợi họ tự giải mã mọi thứ một mình. Cảm giác ấy không đến từ một tài liệu hoàn hảo hay một cuộc gọi chào mừng vui vẻ. Nó được tạo bởi nhiều chuẩn bị nhỏ cùng nói một điều: nhóm đã dành chỗ cho bạn học.

Khi nhớ lại tuần đầu ở một nơi nào đó, thứ còn đọng lại thường rất vụn: người giải thích một từ viết tắt mà không làm mình ngượng, README chạy đúng như hướng dẫn, hay một lời review vừa đủ rõ mà không khiến ai mất mặt. Đó mới là hệ thống onboarding thật. Và đó cũng là phần mỗi nhóm có thể sửa tốt hơn, từng lần đón một người mới.

Bạn thấy bài viết thế nào?