Nhiệm vụ nhà phát triển cao cấp mới

Tôi đã có một nhà phát triển cao cấp với tám năm kinh nghiệm .NET bắt đầu vào ngày mai để làm việc trên một ứng dụng mã 11.000 dòng. Trong đội có bản thân tôi và một lập trình viên khác. Cả hai chúng tôi đã có khoảng ba năm kinh nghiệm mỗi.

Đây là dự án đầu tiên của tôi với tư cách là người quản lý (Tôi cũng là nhà phát triển dự án) và đây là lần đầu tiên tôi phải giới thiệu ai đó với một cơ sở mã đã được thiết lập. Rõ ràng là tôi sẽ xem xét từng mô-đun, quy trình triển khai, v.v. và trao cho chúng vị trí của kho lưu trữ kiểm soát nguồn, tài liệu (không phải là tốt nhất), v.v.

Tôi nên cung cấp cho họ bao lâu trước khi họ sẵn sàng bắt đầu viết các tính năng mới và sửa lỗi?

Tôi sẽ chỉ định một vài lỗi ưu tiên thấp vào ngày đầu tiên, theo cách đó, không ai hét lên nếu chúng không được thực hiện ngay lập tức cho nhà phát triển mới một thời gian để làm quen với cơ sở mã.

Điều quan trọng nhất cần làm là có một bản đánh giá mã về tất cả các công việc của anh ấy trong vài tuần đầu tiên. Bạn không muốn phát hiện ra rằng anh chàng đang đi sai hướng hoặc không tuân theo các tiêu chuẩn mã hóa của công ty hàng tháng. Tốt hơn là đảm bảo anh ta biết những gì được mong đợi từ đầu, và các đánh giá mã đảm bảo điều này. Tất nhiên tôi nghĩ rằng đánh giá mã là tốt cho tất cả nhân viên (Chúng tôi xem xét 100% mã của chúng tôi trước khi triển khai), nhưng chúng rất quan trọng đối với nhân viên mới và nên được thực hiện tại nơi bạn có thể trả lời câu hỏi và giới thiệu họ đến tài liệu mà họ có thể không có thấy chưa nếu cần.

Những gì bạn không muốn là một chàng trai mới bước vào và sử dụng một phong cách khác với phần còn lại của bạn. Mọi người thường cố gắng tiếp tục sử dụng kiểu mã của công việc trước đó ngay cả khi nó mâu thuẫn với kiểu mã được sử dụng tại địa điểm mới có thể gây nhầm lẫn và khó chịu cho các nhà phát triển khác.

Một điều tôi nhận thấy ngay cả với các nhà phát triển có kinh nghiệm là một số trong số họ không tốt như trong cuộc phỏng vấn, đánh giá mã sẽ giúp bạn tìm ra điều này nhanh chóng, vì vậy bạn có thể khắc phục nó. Nó cũng sẽ khuyến khích họ thực sự hoàn thành công việc, tôi đã thấy những nhân viên mới không được kiểm tra mã kéo ra một dự án mà không cho thấy họ đang làm gì với ai đó và sau đó rời đi một tuần trước thời hạn họ biết họ sẽ không trúng vì họ ở trên đầu và chưa thực sự hoàn thành bất kỳ phần nào của dự án. Tốt hơn nên kiểm tra sớm và thường xuyên với những người mới cho đến khi bạn thực sự chắc chắn rằng họ đang làm việc.

Ngoài ra, việc anh chàng mới bị kinh hoàng ở trạng thái dự án cũ của bạn là chuyện bình thường. Nó không được thiết kế theo cách mà anh ấy nghĩ nó nên có. Mong đợi điều này, nghe anh ta nói và không tự động bỏ qua tất cả những gì anh ta nói. Cụ thể, người này dường như có nhiều kinh nghiệm hơn bạn hoặc các nhà phát triển khác, anh ta có thể thấy những điều bạn đã xem xét. Tuy nhiên, là người quản lý, bạn phải cân bằng các thay đổi được đề xuất so với khối lượng công việc hiện tại và thời hạn. Tất cả các bạn có thể muốn đầu tư một chút thời gian vào việc học cách cấu trúc lại mã hiện có và đầu tư một số giờ vào ước tính thời gian của bạn để làm điều đó đặc biệt là nếu anh chàng mới có một số mối quan tâm hợp lệ. Bạn có thể không thể hỗ trợ viết lại toàn bộ (nhiều người mới nghĩ rằng chúng ta nên bắt đầu lại và làm nó tốt hơn),

Nếu bạn có một thời gian mà anh ấy không mong đợi được đóng góp đầy đủ (và chiếm toàn bộ thời gian của anh ấy bởi khách hàng), đó cũng có thể là lúc anh ấy có thể bắt đầu một số trong những điều tái cấu trúc mà bạn muốn làm ngoài thiên đường ' t đã có thời gian để làm. Đôi khi, nên sử dụng thời gian đào tạo người mới để giải quyết một số điều không có trong kế hoạch dự án. Họ có thể tìm hiểu cơ sở mã và nếu những gì họ muốn làm không hoạt động, bạn đã không ảnh hưởng đến lịch trình hiện tại vì bạn chưa đưa chúng vào lịch trình hiện tại. Và nếu nó hoạt động, bạn có thể có một chiến thắng lớn làm cho việc bảo trì trong tương lai dễ dàng hơn hoặc bảo mật tốt hơn hoặc bất kể vấn đề là gì.

Khởi động chúng ngay lập tức trên các nhiệm vụ nhỏ - những thứ không yêu cầu bức tranh lớn hơn.

Khi họ trở nên tự tin và quen thuộc hơn với codebase, hãy tốt nghiệp cho họ những nhiệm vụ lớn hơn và lớn hơn. Làm thế nào nhanh chóng xảy ra chủ yếu phụ thuộc vào họ.

Tôi luôn muốn nhận nhiệm vụ được giao cho tôi ngay lập tức, với sự hiểu rằng sẽ mất nhiều thời gian hơn để đào mã, và rất nhiều câu hỏi sẽ được hỏi trong vài ngày / tuần đầu tiên.

Tôi thấy rằng tôi không thể hoàn toàn tập trung vào một dự án cho đến khi tôi phải thực sự đi vào và sửa chữa hoặc thay đổi một cái gì đó.

Ngoài ra ... Cho dù bạn nghĩ bạn đã giải thích tốt như thế nào về một dự án hoạt động thì vẫn luôn có 'oh yeah tôi quên nói với bạn', 'chúng tôi đã gặp phải vấn đề này, vì vậy chúng tôi đã làm điều này' những khoảnh khắc không bị trêu chọc cho đến khi bạn thực sự bắt đầu công việc

Bao lâu?

Một sợi dây dài bao nhiêu?

Khi anh ấy cảm thấy thoải mái: khi anh ấy sửa lỗi đầu tiên -> anh ấy đã sẵn sàng .

Trong cộng đồng nguồn mở, tất cả những người muốn tham gia dự án đều phải đối phó với một số vấn đề nhỏ. Nếu anh ấy hoặc cô ấy có thể xử lý vấn đề rất tốt, nhiệm vụ quan trọng hơn sẽ được giao cho anh ấy hoặc cô ấy. Theo cách này, họ sẽ trở thành một nhà phát triển cốt lõi của dự án.

Nhà phát triển cao cấp này có tám năm kinh nghiệm .NET, vì vậy bạn có thể chỉ định cho anh ta một số lỗi đơn giản để khắc phục. Nếu anh ta dễ dàng đối phó với họ, bạn có thể chỉ định cho anh ta những vấn đề phức tạp để giúp anh ta làm quen với toàn bộ ứng dụng. Sau đó, anh ta có thể bắt đầu viết các tính năng mới và phân tích các vấn đề kỳ lạ. Chỉ cần làm điều đó, không có thời gian thiết lập!

8 năm kinh nghiệm. Tôi sẽ ném anh ta vào. Anh ta có thể bơi. Như những người khác đã lưu ý bắt đầu với các nhiệm vụ nhỏ dễ dàng. Nó sẽ cho phép anh ta tìm hiểu quy trình đăng ký / kiểm tra mã và bất kỳ quy trình phát triển nào khác mà bạn có.

Tôi đã thay đổi công việc nhiều lần và tôi đã là cộng tác viên của tất cả trong số họ trong tuần đầu tiên. Khó nhất là tôi mất một tuần để lấy mã để biên dịch (ít nhất 100k + dòng mã). Một bản dựng đầy đủ mất 8 giờ cho dự án đó.

Tôi đã làm việc gì đó như 80 giờ trong tuần đầu tiên (dự án nghiêm túc phía sau).

Đối với một ứng dụng nhỏ và nhà phát triển có kinh nghiệm, tôi nghĩ một ngày là đủ cho các lỗi cơ bản. Các lỗi liên quan hoặc các tính năng nhỏ gần một tuần (một khi chúng rõ ràng hơn về miền và kiến ​​trúc vấn đề).

Câu trả lơi con phụ thuộc vao nhiêu thư. Nếu bạn muốn anh ấy sửa lỗi do một lỗi trên một thứ gì đó hoặc thay đổi màu của phần tử GUI, thì khoảng 5 phút (đây là nơi chúng tôi giữ mã của chúng tôi), nếu bạn muốn thiết kế lại toàn bộ kiến ​​trúc của ứng dụng sẽ yêu cầu lâu hơn một chút.

Nó thực sự phụ thuộc vào nhiệm vụ mà bạn mong đợi anh ta thực hiện.