Cách tốt hơn để đào tạo nhân viên mới [đóng cửa]

Nhóm tôi hiện đang là một phần của kinh nghiệm doanh thu khá cao, với các thành viên thường chuyển sang các dự án khác nhau trong cùng một công ty. Hiện tại, "đào tạo" của chúng tôi dành cho các thành viên mới là ghép họ với một liên hệ chính (thường là người gần đây nhất để hoàn thành khóa đào tạo của họ), người sẽ cung cấp cho họ kinh nghiệm thực tiễn và sẽ hỏi các nhà phát triển cao cấp hơn nếu người thuê mới hỏi một người cố vấn không biết Nó cung cấp một cơ hội cho người thuê mới tham gia nhanh chóng, và thách thức người cố vấn để cải thiện sự hiểu biết của anh ấy / cô ấy về hệ thống.

Tuy nhiên, như bạn có thể tưởng tượng, phong cách đào tạo này rất tốn thời gian và không cung cấp sự chuyển giao kiến ​​thức rất tốt (quan niệm sai lầm lan truyền, khoảng cách mở rộng).

Tôi đã được giao nhiệm vụ tạo tài liệu và tài liệu đào tạo cho các nhân viên mới trong tương lai của chúng tôi. Thỉnh thoảng tôi đã viết kỹ thuật, nhưng nó dành cho người dùng cuối và đặc biệt cao với nhiều ảnh chụp màn hình và tiêu tốn một lượng lớn thời gian để hoàn thành.

Tạo tài liệu mới cho nhân viên mới được coi là ưu tiên thấp và hiện tại tôi chỉ có ~ 40 giờ để làm việc với nó. Tài liệu hệ thống theo cách hiện tại tôi viết tài liệu kỹ thuật sẽ hầu như không làm trầy xước bề mặt trong 40 giờ. Đặc biệt là xem xét tôi phải tài liệu không chỉ về cơ sở mã, mà còn về việc triển khai và hỗ trợ.

Làm thế nào tôi có thể nhanh chóng viết tài liệu để có được những người tuyển dụng mới cập nhật nhanh nhất có thể mà không cần đầu tư thời gian đáng kể vào việc viết tài liệu?

Thông tin bổ sung:
Chúng tôi hiện có cả wiki và một số tài liệu đào tạo, tuy nhiên cả hai đều khá thưa thớt.

Câu hỏi hay. Lập trình viên đào tạo tại chỗ rất hiếm khi được thực hiện nghiêm túc, cũng không được nói đến thường xuyên.

Một số ý tưởng tôi đã thấy làm việc tốt:

• Trong wiki của bạn, có một tài liệu quảng cáo cho thuê mới (tài liệu bạn đang viết). Trong tài liệu đó, hãy mô tả các nhiệm vụ mà người thuê mới sẽ thực hiện trong 1-2 tuần đầu tiên. Nơi tôi làm việc, có rất nhiều thứ để biết từ việc di chuyển, từ phần mềm / công cụ nội bộ, đến quy trình, đến vị trí của các loại thông tin cụ thể. chỉnh sửa> chúng tôi có các hướng dẫn như "cài đặt x, y, z theo thứ tự" với các ảnh chụp màn hình để định cấu hình, v.v. âm thanh. Điều này áp dụng cho các phiên bản khác của những ứng dụng mà chúng tôi hỗ trợ.
• Vấn đề thực hành. Tôi đang ở đâu, chúng tôi có một sản phẩm trưng bày API lớn. Vì vậy, nó luôn có lợi cho chúng tôi khi xem qua tài liệu sản phẩm của chính chúng tôi để viết các phần mở rộng (được xác định trước) giống như khách hàng / khách hàng của chúng tôi. Vì vậy, nếu bạn có một thư viện toán học như một phần của API sản phẩm của mình, có một vấn đề thực tế là "viết máy tính bằng API của chúng tôi" hoặc đại loại như thế.
• Người cố vấn là tốt. Giữ chúng. Chúng tôi cũng làm điều đó ở đây, và không chỉ là một cách tốt để gặp gỡ mọi người / kết bạn, mà chúng còn là tài nguyên học tập vô giá. Tôi khuyên bạn không nên là người gần đây nhất hoàn thành khóa đào tạo vì họ không có lịch sử kiến ​​thức công ty mà người khác có thể. Có tất cả mọi người làm điều đó trên một vòng quay.
• Chúng tôi (đại khái) thuyết trình hàng tuần / nói chuyện công nghệ. Yêu cầu nhân viên mới chọn một cái gì đó từ sản phẩm của bạn (hoặc chỉ định nó) và thuyết trình sau tuần thứ 3 của họ. Hãy chắc chắn rằng họ biết rằng có chỗ cho họ sai và nhóm có thể sửa chúng nếu họ làm hỏng bất cứ điều gì trong bài thuyết trình.
• Có nhân viên mới làm việc trên tài liệu khi họ bắt đầu. Nó buộc họ phải đọc nó.

Như Dan McGrath lưu ý, đó là một ý tưởng tốt để khuyến khích những người tuyển dụng mới để cải thiện wiki cho họ.

Đầu tiên, tôi sẽ đề nghị bạn không cần phải làm cho tài liệu đào tạo thuê mới của bạn kỹ lưỡng như những gì bạn viết cho khách hàng. Nó cần phải đủ kỹ thuật để một nhà phát triển mới có thể sử dụng như một hướng dẫn, nhưng không chi tiết đến mức nó phác thảo mọi điều nhỏ nhặt. Họ sẽ có thể nói chuyện với nhóm nếu họ có câu hỏi sau tất cả.

10 điều hàng đầu mà một người thuê mới cần biết để có ích cho nhóm của bạn là gì? Tập trung vào những điều này. Biến chúng thành danh sách các mục của bạn để một nhà phát triển mới có đủ việc để làm và đủ thông tin để tiếp tục phát triển. Nếu bạn có quá nhiều thứ trong danh sách, hãy tự hỏi liệu họ sẽ làm điều đó trong hai hoặc ba tuần đầu tiên của họ. Nếu họ sẽ không làm gì đó trong thời gian này, thì có lẽ nó không nên có trong hướng dẫn lên máy bay.

Đối với mỗi phần trong hướng dẫn của bạn, hãy đảm bảo có một người đi đến được tô sáng ngay trên đầu. Bằng cách này, nếu người thuê mới có bất kỳ câu hỏi nào họ biết phải tìm ai để được giúp đỡ. Ngoài ra, hãy đảm bảo rằng một thành viên trong nhóm không phải là người thích hợp cho quá nhiều phần. Bạn không muốn mất thời gian của một người với các câu hỏi thuê mới nếu họ không phải là người cố vấn.

Đừng dành cả tuần của bạn cho tài liệu này. Hãy để lại cho mình một chút thời gian để điều chỉnh nó sau khi bạn cho ít nhất một người thuê mới đi qua nó. Xem những gì hoạt động tốt, những gì không, và sửa chữa.

Gần đây tôi đã bắt đầu trên một tài liệu tương tự tại nơi làm việc của tôi, với những hạn chế về thời gian tương tự. Tôi đồng cảm rằng thật dễ dàng để viết nó ở một mức độ rất chi tiết, như tôi đã làm lúc đầu, nhưng điều đó thực sự có thể phản tác dụng.

Nếu ai đó mới bắt đầu trong một vai trò, họ có thể bị ngập trong thông tin trong vài tuần đầu tiên. Việc đào tạo ban đầu của họ là một khối óc của một nhà phát triển, người đã ở một công ty trong nhiều năm, trong tâm trí tôi sẽ làm phức tạp thêm những gì ai đó cần biết trong vài tháng đầu tiên hoặc thậm chí cả năm ở vị trí đó. Giữ mức độ cao, cố gắng sử dụng các thuật ngữ và khái niệm tiêu chuẩn, sau đó mở rộng chúng với các chi tiết cụ thể từ trong quy trình của công ty.

Đối với tôi, lần lặp đầu tiên của tài liệu này chỉ đơn giản là một phác thảo về SDLC mà chúng tôi sử dụng tại nơi làm việc của tôi, với một danh sách các vai trò liên quan trong mỗi bước, một vài ví dụ về những người thực hiện các vai trò đó và danh sách kiểm tra cụ thể được liên kết với mỗi bước của vòng đời là tốt. Cá nhân tôi thấy danh sách kiểm tra là không thể thiếu trong mục đích đào tạo, nhưng cũng chỉ là về bất cứ điều gì khác tôi làm trong công việc. Ví dụ:

• Quản lý dự án (Joe) giao cho bạn một nhiệm vụ trong Jira.
• Đặt thời gian hoàn thành ước tính cho nhiệm vụ dựa trên công thức x.
• Đặt vé là 'trong tiến trình' khi bạn bắt đầu làm việc với nó.
• Tạo chi nhánh từ git, nhấp vào liên kết để xem video 30 giây về tiến trình này.
• Viết các bài kiểm tra đơn vị dựa trên các ràng buộc trong tài liệu thiết kế, xem trang y để biết các quy ước đặt tên thử nghiệm đơn vị.
• Đặt vé để xem xét và gửi mã cho hệ thống đánh giá .. ', v.v.

Nhân viên mới của bạn hy vọng sẽ quen thuộc với phần lớn các khái niệm và bây giờ có hướng dẫn từng bước về cách các quy trình được áp dụng tại công ty. Tôi cũng làm một bản demo nhanh của quá trình từ đầu đến cuối bằng cách sử dụng các tài liệu thực từ các dự án mà tôi cảm thấy đã được thực hiện tốt.

Như đã đề cập, nó cũng là một tài liệu sống, vì vậy các phần có thể được mở rộng khi nó được xác định rằng chúng cần thêm thông tin. Toàn đội nên tham gia để giữ cho đến nay. Nó có thể là một wiki, tài liệu OneNote, bất cứ điều gì, nhưng một cái gì đó mà tất cả mọi người có thể chỉnh sửa và xem xét, sau đó bắt đầu để người khác tham gia vào việc cải thiện nó khi họ có một giờ rảnh rỗi ở đây. Bằng cách đó, một người sẽ không làm điều đó và tuyên truyền guồng quay của chính họ trên quy trình cho tất cả các nhân viên mới.

Khi họ đã xem xét quy trình, hãy để họ theo dõi một tính năng nhỏ / sửa lỗi trong một dự án quan trọng không phải là nhiệm vụ và yêu cầu họ đặt câu hỏi mà tài liệu không đề cập. Ghi lại những câu hỏi này là gì, bởi vì chúng có thể là những điều đầu tiên bạn thêm vào tài liệu vào lần tiếp theo bạn làm việc với nó.

Bạn không thể kết hợp làm một cái gì đó tốt như thế này mà không mất thời gian. Ít nhất, nếu bạn muốn tự làm điều đó. Bạn nên tự hỏi liệu có thực sự cần thiết phải ghi lại nó chính xác như bạn đang cố gắng không?

Thay thế duy nhất là để cho những người tuyển dụng mới làm công việc chính. Hãy để họ viết một số phần. Thời gian bạn dành để sửa những điều này (dưới dạng phản hồi), sẽ ít hơn trong các tình huống hiện tại của bạn. Cung cấp một số mẫu tốt và bạn không phải lo lắng về việc bố trí.

Tôi tin rằng bạn đã biết rằng họ đã giao nhiệm vụ cho bạn với nhiệm vụ bất khả thi. Là một nhà văn, có lẽ bạn đã quen thuộc với trích dẫn từ Mark Twain:

Nếu tôi có nhiều thời gian hơn, tôi sẽ viết ít hơn.

Hầu như không có tài nguyên, có lẽ điều tốt nhất bạn có thể làm là lấy một tủ hồ sơ và yêu cầu mọi người tạo một bản sao của những gì họ đã có và đặt bản sao vào tủ tệp. Bằng cách đó, ít nhất bạn có thể nói với người thuê mới "Nếu bạn muốn tìm kiếm một cái gì đó về hệ thống, nơi bắt đầu là trong tủ hồ sơ."

Viết tốt cần có thời gian, thời gian. Hơn nữa nó cần phải được điều chỉnh cho đối tượng mục tiêu. Những gì hoạt động cho người dùng cuối sẽ không phải là những gì lập trình viên cần.

Chưa kể rằng đào tạo tốt không giới hạn ở các tài liệu bằng văn bản, nó sẽ bao gồm toàn bộ tài nguyên giáo dục bao gồm trực tuyến, lớp học, đa phương tiện, v.v.

Như họ nói, "Nếu bạn nghĩ giáo dục là đắt đỏ, hãy thử chi phí của sự thiếu hiểu biết."

Hơn nữa, không cần phải nói rằng xem tài liệu là một việc phải làm sau thực tế thay vì biến nó thành một phần không thể thiếu của quá trình từ ngày đầu tiên là dấu hiệu của một vấn đề tổ chức có hệ thống.