Onboarding lập trình viên thường được đo bằng độ dài của buổi tiếp nhận thủ tục, và đó là đầu sai của vấn đề. Con số đáng quan tâm là một con số khác: bao lâu thì một kỹ sư mới có thể thay đổi một thứ gì đó mà vẫn chắc chắn mình không làm hỏng thứ khác. Ở phần lớn các nhóm, con số đó được tính bằng tháng chứ không phải bằng ngày.

Sự chậm trễ hiếm khi nằm ở con người. Nó nằm ở chỗ có bao nhiêu phần của hệ thống chỉ tồn tại trong đầu người khác, và bao nhiêu phần của hai tuần đầu tiên bị dùng để moi nó ra, mỗi lần một câu hỏi làm gián đoạn ai đó.

Chỉ số duy nhất đáng theo dõi: bao lâu thì thay đổi đầu tiên của họ lên tới môi trường production. Không phải commit đầu tiên, thứ có thể chỉ là sửa một lỗi gõ chữ, mà là một thay đổi có ý nghĩa và đã chạy thật. Nếu con số đó vượt quá một tuần, rào cản gần như không bao giờ là năng lực. Đó là một quy trình cài đặt mà gần đây chưa ai chạy lại từ đầu, hoặc một mã nguồn mà các điểm vào của nó không thể tìm ra nếu không có người dẫn.

Onboarding lập trình viên đang cạnh tranh với điều gì

Ba khoản chi phí, và chỉ một trong số đó là thời gian của người mới.

Thời gian của họ, khoản nhìn thấy được và là khoản ai cũng tìm cách tối ưu. Thời gian của cả nhóm, vì mỗi câu hỏi lại cắt ngang một người đang làm việc khác, và khoản này lớn hơn khoản đầu tiên. Và chi phí của những câu hỏi không bao giờ được hỏi, khi một kỹ sư mới chọn đoán thay vì làm phiền đến lần thứ năm trong một buổi sáng, rồi phỏng đoán đó sai theo một cách chỉ lộ ra sau hai tháng.

Khoản thứ ba mới là thứ mà onboarding tốt thực sự loại bỏ. Tài liệu đáng viết không phải vì đọc nhanh hơn hỏi, mà vì nó cho phép một người tự tìm ra câu trả lời lúc mười một giờ đêm, không phải cân nhắc cái giá xã hội của việc hỏi thêm một lần nữa.

Sửa môi trường làm việc trước đã

Yếu tố quyết định nhiều nhất tới tuần đầu tiên là dự án có chạy được trên một máy sạch mà không cần ai trợ giúp hay không.

Các nhóm luôn đánh giá thấp điều này, vì ai cũng đã có sẵn một môi trường chạy được và đã hai năm nay không ai dựng lại từ đầu. Trong lúc đó, tài liệu cài đặt vẫn trỏ tới một phiên bản đã đi xa hơn, bỏ sót biến môi trường mà ai đó thêm vào mùa xuân năm ngoái, và mặc định rằng người mới có quyền truy cập một dịch vụ mà thực tế họ chưa từng được cấp.

Cách sửa không có gì hào nhoáng. Hãy để người vào làm tiếp theo làm theo tài liệu đúng từng chữ, không thay đổi gì cả, và ghi lại mọi điểm nó thất bại. Danh sách đó chính là quy trình cài đặt thật của bạn. Tốt hơn nữa, hãy rút nó về một lệnh duy nhất tạo ra một hệ thống đang chạy kèm dữ liệu thử dùng được, vì mỗi bước thủ công đều là một bước sẽ trôi lệch theo thời gian.

Quyền truy cập cũng là một phần của môi trường. Người có mã nguồn nhưng không có quyền trên repository, không có thông tin đăng nhập môi trường staging hay công cụ theo dõi công việc thì chưa được thiết lập xong. Hãy chuẩn bị tài khoản trước ngày đi làm, thay vì phát hiện ra các lỗ hổng vào buổi sáng đầu tiên.

Giao ngay một việc thật

Bản năng muốn che chắn người mới khỏi công việc thật trong hai tuần là thiện ý nhưng phản tác dụng. Đọc mã nguồn mà không có mục đích thì dạy được rất ít, vì không có gì để neo những thứ đã đọc vào.

Một thay đổi nhỏ, thật và triển khai được ngay ngày thứ hai hoặc thứ ba sẽ dạy toàn bộ đường đi tới sản phẩm: mã nguồn nằm ở đâu, test chạy thế nào, review diễn ra ra sao, triển khai được thực hiện thế nào và phải báo cho ai. Chính con đường đó là thứ một kỹ sư mới cần nhất, và cũng là thứ ít có khả năng được viết ra ở đâu đó nhất.

Hãy chọn một việc mà có người dùng thật đang chờ, đừng chọn bài tập bịa ra. Người ta nhận ra sự khác biệt, và sự khác biệt đó quyết định họ có coi trọng phản hồi hay không.

Rồi hãy ngồi làm cùng nhau. Một giờ bên cạnh người hiểu hệ thống truyền đạt được nhiều hơn cả một ngày đọc tài liệu, và người ngồi kèm thường tự phát hiện ra điều gì đó về chính mã nguồn của mình.

Nên viết gì lại và không nên viết gì

Tài liệu sẽ mục đi, vậy nên chỉ viết những gì còn đúng lâu dài và bù lại được công bảo trì.

Đáng viết: cách cài đặt và chạy hệ thống, cách triển khai nó, hình dạng của kiến trúc và lý do nó như vậy, những quyết định mà nếu không ghi lại thì sẽ bị mang ra tranh cãi lần nữa, và ai chịu trách nhiệm phần nào. Hướng dẫn của chúng tôi về tài liệu kỹ thuật bàn kỹ hơn về bài toán bảo trì.

Không đáng viết: mọi thứ mà mã nguồn đã nói rõ, các bài hướng dẫn từng bước qua những màn hình thay đổi hằng tháng, và các tài liệu tham chiếu API đầy đủ viết tay. Đó là những trang cũ đi nhanh nhất và gây hiểu nhầm nhiều nhất.

Ở phần lớn các nhóm, tài liệu có giá trị cao nhất là một bản tổng quan kiến trúc ngắn, nói rõ các mảnh lớn là gì và vì sao chúng được tách ra. Nó tốn một buổi chiều, hiếm khi thay đổi, và trả lời đúng câu hỏi mà mọi kỹ sư mới phải mất nguyên tuần đầu để tự dựng lại.

Onboarding là bài kiểm tra dành cho cả nhóm

Mọi thứ khiến người mới vất vả đều là thứ cả nhóm đã âm thầm gánh từ trước.

Nếu cài đặt mất ba ngày thì chi phí đó luôn ở đó, được trả rải rác bởi mọi người từng dựng lại một máy. Nếu không ai giải thích nổi vì sao một thành phần tồn tại thì sự mơ hồ ấy đã âm thầm làm hỏng các quyết định. Nếu triển khai cần đúng một người thì phụ thuộc đó vốn đã là rủi ro, và cũng chính là rủi ro lộ ra khi thẩm định kỹ thuật và trong mọi kế hoạch khôi phục nghiêm túc.

Vậy nên hãy coi vài tuần đầu là một cuộc audit miễn phí. Hãy nhờ người mới ghi lại mọi thứ khiến họ bối rối, và đọc danh sách đó như một backlog, không phải như nhận xét về năng lực. Đó là mô tả trung thực nhất về hệ thống của bạn, vì sau hai tháng chính họ cũng thôi để ý.

Mecanik thường xuyên tham gia vào mã nguồn có sẵn trong công việc phát triển phần mềm của chúng tôi, tức là chạy bài kiểm tra này trên hệ thống của người khác để kiếm sống. Những nhóm hội nhập người mới nhanh không phải là nhóm có tài liệu tốt nhất. Đó là nhóm mà gần đây có người đã dựng lại môi trường của mình và sửa những gì hỏng.

Câu hỏi thường gặp

Onboarding lập trình viên nên kéo dài bao lâu? Hãy đo thời gian tới thay đổi có ý nghĩa đầu tiên chạy trên production, thay vì đo độ dài buổi tiếp nhận. Nếu con số đó vượt quá một tuần, rào cản hiếm khi là năng lực. Thường thì đó là quy trình cài đặt mà gần đây chưa ai chạy lại từ đầu, hoặc một mã nguồn mà không có người dẫn thì không tìm ra điểm vào.

Lập trình viên mới nên làm gì trong những ngày đầu? Một thay đổi nhỏ, thật và triển khai được, có người dùng thật đang chờ. Đọc mã nguồn mà không có mục đích thì dạy được rất ít vì thiếu điểm neo, trong khi một thay đổi thật sẽ dạy mã nguồn nằm ở đâu, test chạy thế nào, review ra sao, triển khai thế nào và phải báo cho ai.

Vì sao thiết lập môi trường lại mất nhiều thời gian đến vậy? Vì ai cũng đã có sẵn một môi trường chạy được và nhiều năm nay không ai dựng lại từ đầu, nên tài liệu trôi lệch dần. Cách sửa là để người vào làm tiếp theo làm theo đúng từng chữ, không đổi gì, và ghi lại mọi chỗ thất bại. Danh sách đó là quy trình thật, còn rút nó về một lệnh duy nhất sẽ ngăn nó trôi lệch lần nữa.

Tài liệu nào đáng được duy trì cho việc onboarding? Cách cài đặt và chạy hệ thống, cách triển khai, hình dạng kiến trúc và lý do nó như vậy, những quyết định mà nếu không ghi thì sẽ bị tranh cãi lại, và ai chịu trách nhiệm phần nào. Bỏ qua những gì mã nguồn đã nói, các bài hướng dẫn qua màn hình thay đổi hằng tháng và tài liệu tham chiếu API viết tay.

Onboarding chậm nói lên điều gì về một nhóm? Rằng những chi phí nhóm âm thầm gánh là có thật. Ba ngày cài đặt vốn vẫn được trả rải rác bởi tất cả những ai dựng lại một máy. Một thành phần không ai biện minh nổi thì đã lặng lẽ làm hỏng các quyết định. Một lần triển khai chỉ một người làm được thì đã là rủi ro từ trước khi có người mới tới.