Việc cung cấp cho các tân binh một tiểu dự án riêng biệt từ các nhà phát triển có kinh nghiệm sẽ giúp những người mới chơi nhanh hơn?

Chúng tôi có 7 nhà phát triển trong một nhóm và cần tăng gấp đôi tốc độ phát triển trong một khoảng thời gian ngắn (khoảng một tháng). Tôi biết có một quy tắc thông thường rằng "nếu bạn thuê thêm nhà phát triển, bạn chỉ mất năng suất trong vài tháng đầu". Dự án là một dịch vụ web thương mại điện tử và có khoảng 270K dòng mã.

Ý tưởng của tôi bây giờ là chia dự án thành hai tiểu dự án độc lập ít nhiều và để nhóm mới làm việc trên hai dự án nhỏ hơn, trong khi nhóm hiện tại làm việc trong dự án chính. Cụ thể, nhóm mới sẽ làm việc với chức năng thanh toán, cuối cùng sẽ trở thành một dịch vụ web độc lập để giảm khớp nối. Bằng cách này, nhóm mới làm việc trên một dự án chỉ với 100K dòng mã.

Câu hỏi của tôi là: cách tiếp cận này sẽ giúp các nhà phát triển newbie dễ dàng thích nghi với dự án mới? Những cách khác để mở rộng nhóm phát triển nhanh chóng mà không phải chờ hai tháng cho đến khi những người mới bắt đầu sản xuất nhiều phần mềm hơn thì lỗi?

=======

CẬP NHẬT

Doanh nghiệp này thất bại hoàn toàn, nhưng không phải vì những lý do mà các bạn đề cập. Trước hết, tôi đã hiểu sai về quy mô và khả năng của đội bóng mới. Tôi nên tự đánh giá chúng. Thứ hai, tuyển dụng hóa ra là một công việc khó khăn tại trang web đó. Tại trang web của việc thuê văn phòng chính dễ dàng hơn nhiều, nhưng trong thành phố của đội thứ hai rõ ràng là thiếu nhà phát triển với trình độ chuyên môn cần thiết. Kết quả là, thay vì dự kiến ​​1,5 tháng, công việc được kéo dài đến khoảng 4,5 tháng và bị ban lãnh đạo cấp cao hủy bỏ giữa chừng.

Một sai lầm khác mà tôi đã mắc phải (và đã được Alex D cảnh báo về điều đó) là tôi đã cố gắng bán tái cấu trúc cho ban lãnh đạo cao nhất. Bạn không bao giờ bán tái cấu trúc, chỉ có tính năng.

Các startup hóa ra vẫn thành công. Việc tái cấu trúc chưa bao giờ xảy ra đã biến thành nợ kỹ thuật: hệ thống trở nên nguyên khối hơn và ít bảo trì hơn, năng suất của nhà phát triển giảm dần. Bây giờ tôi không ở trong đội, nhưng tôi hy vọng họ sẽ hoàn thành nó trong tương lai gần nhất. Nếu không, tôi sẽ không cho một xu cho sự sống còn của dự án.

Đã nghĩ, tôi đồng ý như mọi người khác ở đây, rằng:

"... thêm nhiều nhà phát triển vào một dự án bị trì hoãn, làm cho dự án, để trì hoãn nhiều hơn ..."

Tôi có cảm giác, bạn sẽ làm điều đó, ở bất cứ đâu, vì vậy ...

Ý tưởng của bạn có thể giúp, nếu, dự án hiện tại của bạn, đủ tổ chức, bởi các mô-đun, hệ thống con hoặc các dự án con.

Những gì bạn có thể muốn thử, đó là cung cấp cho họ các phần nhỏ / mô-đun / biểu mẫu / lớp của dự án của bạn, để làm việc với, thay vì tất cả dự án.

Nếu bạn sử dụng cơ sở dữ liệu, bạn có thể muốn tạo một bản sao của DB đang hoạt động với dữ liệu và truy cập chúng từ mô-đun hoặc hệ thống con của mã sẽ hoạt động.

Có các nhà phát triển mới biết ngôn ngữ lập trình hoặc môi trường lập trình, là không đủ, các ứng dụng phần mềm có thể trở nên rất phức tạp.

Bạn có một số tài liệu về ứng dụng như: UML, ER, Codd-Yourdon, bất cứ điều gì không?

Chúc may mắn.

Câu hỏi của tôi là cách tiếp cận này sẽ giúp các nhà phát triển newbie dễ dàng thích nghi với dự án mới?

"Newbie" có thể có nghĩa là mới đối với bạn hoặc có thể có nghĩa là mới khi làm việc với tư cách là nhà phát triển phần mềm. Nếu bạn định thuê một nhóm các nhà phát triển để thực hiện một dự án quan trọng theo lịch trình, hãy đảm bảo rằng ít nhất hầu hết các nhân viên mới là các nhà phát triển có kinh nghiệm và tốt nhất là những người đã viết các dự án tương tự như những gì bạn đang cố gắng để xây dựng.

Những cách khác để mở rộng đội ngũ phát triển nhanh chóng mà không phải chờ hai tháng cho đến khi họ bắt đầu sản xuất thêm phần mềm sau đó là lỗi?

• Mua hoặc cấp phép cho một sản phẩm hiện có thay vì cố gắng xây dựng của riêng bạn. Bạn có thực sự cần phải phát minh lại bánh xe thanh toán?

• Như tôi đã nói ở trên, hãy thuê những người có kinh nghiệm xây dựng loại hệ thống mà bạn muốn.

• Ngay cả trước khi bạn thuê nhóm mới này, bạn nên suy nghĩ về những gì họ sẽ cần biết về nội dung hiện có của bạn. Hãy chắc chắn rằng bạn dành đủ thời gian cho các buổi đào tạo để giúp họ tăng tốc.

• Bạn đã tạo ra một tập hợp các yêu cầu bằng văn bản? Nếu không, hãy làm điều đó ngay bây giờ. Nếu bạn dự kiến ​​sẽ thiết kế dự án thay vì để nhóm mới làm điều đó, bạn cũng nên chuẩn bị một tài liệu thiết kế rõ ràng, nhưng hãy sẵn sàng để thay đổi để đáp ứng với đầu vào từ các thành viên nhóm mới.

• Bạn có một quy trình phát triển được xác định rõ? Cơ sở dữ liệu lỗi? Kiểm soát phiên bản? Quy trình xét duyệt mã? Hướng dẫn mẫu? Có được những thứ đó tại chỗ.

• Đừng mong chờ phép màu. Bạn muốn thuê một nhóm bảy người và khiến họ làm việc hiệu quả trong vài tuần, nhưng muốn điều đó không có nghĩa là bạn có thể có điều đó. Tùy thuộc vào vị trí của bạn, có thể mất nhiều thời gian hơn một tháng chỉ để tìm bảy người phù hợp. Cố gắng vội vàng mọi thứ bây giờ sẽ chỉ gây ra đau đớn và chi phí sau này.

IMHO đưa tất cả các nhà phát triển mới vào dự án mới, tách biệt với nhóm hiện tại của bạn chắc chắn sẽ gây ra vấn đề. Có, điều này (có thể) cho phép nhóm cũ của bạn tiếp tục làm việc nhiều hơn hoặc ít hơn với tốc độ hiện tại. Tuy nhiên, những kẻ mới sẽ không có manh mối về kiến ​​trúc tổng thể và bức tranh lớn, vì vậy họ sẽ mất rất nhiều thời gian để tăng tốc ... và thậm chí sau đó họ có thể đang đi sai hướng.

Tôi đề nghị chia đội hiện tại của bạn thành hai và thuê thành viên mới vào cả hai đội. Bằng cách này, có những người trong cả hai đội có thể cố vấn cho những người mới đến và đảm bảo rằng một tầm nhìn kiến ​​trúc chung, mạch lạc được theo kịp.

Mặt khác, tôi đồng ý với Caleb về việc ghi lại các yêu cầu rõ ràng, xác định quy trình và công cụ phát triển và dành thời gian đào tạo ... và cũng mong rằng một nhóm 7 người sẽ được thuê và tăng tốc trong vòng một tháng là không thực tế.

Dmitry, tăng gấp đôi tốc độ phát triển của bạn trong một thời gian ngắn là một mục tiêu cực kỳ tham vọng. Một số gợi ý tốt đã được đăng ở đây; nhưng, bất kể bạn cố gắng gì, hãy lưu ý rằng điều đó có thể không xảy ra . nếu tốc độ phát triển của bạn không tăng gấp đôi, thì hậu quả sẽ ra sao, từ góc độ kinh doanh? Bạn đang cố gắng để đáp ứng một thời hạn?

Nếu bạn đang cố gắng đáp ứng thời hạn, bạn có thể làm điều đó đáng tin cậy hơn bằng cách cắt các tính năng không? Tôi đã tìm thấy một cách tuyệt vời để làm cho "thời hạn bị bỏ lỡ" được khách hàng chấp nhận là thực hiện các bản phát hành gia tăng; phát hành một phiên bản có một tập hợp con các tính năng cần thiết, và sau đó khi nhiều tính năng đã sẵn sàng, hãy phát hành chúng dần dần, cho đến bản phát hành cuối cùng.

Vì vậy, bạn đang cố gắng trở thành đội không trở thành nạn nhân của Tháng huyền thoại . Bạn sẽ có một vài vấn đề, ai đó trong nhóm sẽ phải thực hiện các cuộc phỏng vấn kỹ thuật, sau đó bạn sẽ phải chờ vài tuần sau khi họ chấp nhận vị trí này trước khi họ có thể bắt đầu. Có thể là hai tháng trước khi các nhà phát triển mới ở trước bàn phím của họ.

Mỗi nhân viên mới có năng suất âm trong vài tháng đầu. Nó được làm tồi tệ hơn bởi vì các nhà phát triển hiện tại sẽ cần phải cố vấn cho họ, làm giảm thêm năng suất.

Phần khác của MMM là khi nhóm phát triển, các vấn đề liên lạc cũng vậy. Các cuộc họp trở nên lớn hơn, chuỗi email trở nên dài hơn ...

Tôi sẽ đưa chúng vào các nhóm nhỏ hơn và biết rằng trong một thời gian dài, năng suất sẽ không tỷ lệ thuận với quy mô tăng lên của nhóm. Cũng nhận ra sự hao hụt dòng tiền trong vài tháng đầu tiên có thể là đáng kể, do chi phí lên máy bay và thiết bị.

Trong bình luận của bạn cho Alex D, bạn đã đề cập "Đây không phải là thời hạn cuối cùng, khả năng rõ ràng của nó để cung cấp các tính năng mới." Vì vậy, hãy chuyển sang một phong cách phát triển, đóng vai trò cho các tính năng trong các phần nhỏ hơn và thường xuyên hơn. Yêu cầu các thành viên mới của nhóm thử nghiệm các tính năng mới, điều đó sẽ giúp họ hiểu cơ sở mã.

Bạn sẽ tốt hơn nếu không thuê ai mới và nhìn vào các quy trình của bạn để xem bạn có thể thay đổi ở đâu để mọi thứ diễn ra nhanh hơn. Các lỗi được tìm thấy càng sớm thì càng mất ít thời gian để sửa chúng, vậy bạn đang thử nghiệm như thế nào? Bạn đang làm mã đánh giá? Bạn có chú ý đến chất lượng của yêu cầu? Bạn có xây dựng tự động và quá trình deplotyment? Bạn có kiểm tra tự động? Bạn đang có các cuộc họp chờ hàng ngày (Thật tuyệt vời khi có thể phát triển nhanh hơn bao nhiêu khi ai đó sẽ hỏi bạn về sự tự hào của bạn mỗi ngày!)? Bạn đang sử dụng các quy trình nhanh? Bạn có một số lỗi thiết kế cơ bản cần được giải quyết để làm cho phần còn lại của sự phát triển diễn ra nhanh hơn (thiết kế xấu có thể làm chậm một dự án phát triển xuống một cách khó tin).

Xin vui lòng đọc Tháng huyền thoại. Bạn rõ ràng sẽ cần để có thể nói với quản lý cấp cao tại sao họ lại đưa ra các lựa chọn quan trọng để tăng tốc dự án. .

Vì vậy, bạn muốn ném chúng ra khỏi một vách đá và xem liệu chúng có thể bay? Tôi nghĩ rằng khi bạn tự mình khám phá mọi thứ, chúng có xu hướng gắn bó với bạn về lâu dài thay vì chỉ có giải pháp được đưa ra cho bạn. Tuy nhiên, điều đó giả định rằng bạn thực sự khám phá ra các giải pháp tốt hơn. Tôi không thấy lý do tại sao bạn không thể cho phép nhóm này có một nhà lãnh đạo có trình độ, người sẽ cân bằng để họ tự mắc một số sai lầm cùng với việc hướng dẫn và chỉ dẫn cho họ bằng cách học hỏi từ các ví dụ chất lượng.