Những thực tiễn quản lý / phát triển nào bạn thay đổi khi một nhóm 1-3 nhà phát triển tăng lên 10+?


14

Nhóm của tôi đã xây dựng một trang web cho một khách hàng vài năm trước. Hệ số trang web đã tăng rất nhanh và khách hàng của chúng tôi đã yêu cầu chúng tôi phát triển nhóm của chúng tôi để đáp ứng nhu cầu bảo trì và yêu cầu tính năng của họ.

Chúng tôi đã bắt đầu với một số lượng nhỏ các nhà phát triển và nhóm của chúng tôi đã phát triển - bây giờ chúng tôi có hai chữ số.

Những thay đổi quản lý / phát triển nào có lợi nhất khi nhóm phát triển từ nhóm "cỡ nhà để xe" nhỏ lên hơn 10 nhà phát triển?


1
Bạn có thể muốn tách ra phần quản lý của câu hỏi và hỏi nó trên pm.stackexchange.com
blueberryfields

2
Những gì thực hành quản lý đã được nhóm sử dụng trước đây?
chrisaycock

Ban đầu chúng tôi có 2 nhà phát triển cấp cao, vì vậy họ thường chỉ nói ra những điều đó. Khi nhóm và dự án bắt đầu phát triển, có các nhà phát triển cơ sở, vì vậy chúng tôi đã giới thiệu WIKI, hệ thống theo dõi lỗi, Kiểm soát nguồn, v.v ... Bây giờ có vẻ như nhóm quá lớn để được quản lý bởi một nhà phát triển cấp cao, vì vậy có lẽ chúng ta nên bắt đầu chia nó thành các đội nhỏ hơn.
Mag20

Mua thêm cà phê.
haylem

1
Thật là một "vấn đề" tuyệt vời để có. Chúc mừng đội ngũ đang phát triển!
Hướng đạo Agile

Câu trả lời:


8

Tôi muốn nói rằng có khoảng hai con đường chính:

  • Chia nhóm thành hai hoặc ba nhóm, mỗi nhóm chịu trách nhiệm cho một lĩnh vực / khía cạnh cụ thể. điều này có lợi thế là bạn vẫn có thể làm việc theo cách bạn đã quen, trong các nhóm nhỏ hơn.
  • "Nhóm phẫu thuật", trong đó bạn có thể đọc trên Tháng huyền thoại . Ngoài ra liên kết này có một bản vẽ tuyệt vời về nó.

Chúc may mắn!


4

Chúng tôi đã tăng từ khoảng 10 đến gần 200 trong 7 năm qua. Điều đầu tiên cần thay đổi là bạn sẽ cần tài liệu tốt hơn và các quy trình chuẩn hơn. Yêu cầu có thể phải được chính thức hơn là tốt.

Bạn cũng nên xem xét các chuyên gia tuyển dụng khi bạn phát triển. Nếu bạn có một phụ trợ cơ sở dữ liệu, bạn nên có ít nhất một chuyên gia cơ sở dữ liệu chuyên dụng. Bạn có lẽ nên chi tiền cho một người thử nghiệm.

Bạn sẽ có nhiều dự án đang diễn ra và nhu cầu lớn hơn để quản lý tham, vì vậy nếu bây giờ bạn không sử dụng một dự án, bạn cần một hệ thống quản lý dự án và trình theo dõi lỗi. Bạn cần tạo ra một triển khai triển khai và giới hạn quyền sản xuất chỉ cho những người sẽ thực hiện triển khai, không còn thực hiện thay đổi trực tiếp trên prod. Các nhà phát triển của bạn sẽ cần được giới hạn chỉ chọn quyền trên prod.

Khi bạn có các nhóm lớn hơn, bạn sẽ gặp nhiều vấn đề hơn với mọi người và sẽ có nhiều khả năng thuê một số người kém kỹ năng hơn (tương đối dễ dàng để có được ba nhà phát triển giỏi khi đó là tất cả những gì bạn có, khó hơn rất nhiều khi thuê 30 người một lúc). Mặc dù bạn cố gắng để có được những người giỏi nhất, bạn càng thuê nhiều thì càng có nhiều khả năng bạn sẽ nhận được một người siêng năng, vì vậy hãy chuẩn bị để cho mọi người đi.

Phối hợp giữa mọi người là chìa khóa. Hai đội thực hiện các thay đổi loại trừ lẫn nhau cho một sản phẩm là một điều xấu.

Chỉ với hai hoặc ba nhà phát triển, bạn không thể có được những người trẻ tuổi - mọi người đều phải làm việc ở cấp cao. Với nhiều nhà phát triển, bạn không thể không có người trẻ tuổi. Thuê một số thiếu niên và đào tạo họ theo cách bạn muốn họ được đào tạo. Thường thì tốt hơn để làm việc ở một nơi có con đường sự nghiệp chưa từng có cùng cấp.

Khi nhóm của bạn phát triển, nhiều nhà phát triển hiện tại của bạn sẽ trở thành nhân viên quản lý mới. Một số người sẽ ghét điều đó, đảm bảo rằng những người đó có cơ hội quảng bá cho một nhà phát triển cao cấp hơn là quản lý. Đừng để mất tất cả chuyên môn kỹ thuật của bạn để quản lý. Thưởng cho những người không tham gia quản lý vì bạn cần có kiến ​​thức chi tiết về hệ thống hiện tại của họ để giúp những người mới tăng tốc.


4

Nếu dự án đủ lớn cho hơn 10 nhà phát triển, nó sẽ dễ dàng được chia thành các khu vực nhỏ hơn. Chia đội thành các nhóm nhỏ hơn 3-5 người mỗi nhóm và trao quyền tự chủ cho khu vực của họ. API sẽ phải được phát triển giữa các đội. Tôi khuyên bạn nên để mỗi nhóm tìm ra các yêu cầu của họ và có một hoặc hai người trong mỗi nhóm tham gia gặp nhau để thảo luận về API. Dễ dàng thảo luận và đưa ra quyết định khi có ít người tham gia.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.