Làm thế nào để cấu trúc một nhóm phát triển

Tôi là quản lý của một nhóm gồm 11 nhà phát triển phần mềm chăm sóc các trang web / ứng dụng web của công ty tôi, chạy tới 4 dự án đồng thời cộng với hỗ trợ hàng ngày bất cứ lúc nào. Trong 11 nhà phát triển, có sự kết hợp của các kỹ năng kỹ thuật, chức danh công việc và kinh nghiệm, mặc dù cấu trúc nhóm không thay đổi với tất cả 11 nhà phát triển báo cáo trực tiếp với tôi.

Toàn bộ nhóm có một người quản lý duy nhất đang bắt đầu chứng minh không có quy mô rất tốt. Tôi bắt đầu được truyền bá quá mỏng nên muốn giảm số lượng báo cáo trực tiếp của mình. Tất cả các cách tôi có thể nghĩ để làm điều này có nhược điểm đáng kể:

• Có nhà phát triển cơ sở báo cáo cho những người cao cấp. Điều này làm giảm thời gian phát triển của các kỹ thuật viên tốt nhất.
• Chia nhóm theo sản phẩm phần mềm, ví dụ: nhà phát triển 1-6 làm việc trên mạng nội bộ và 7-11 làm việc trên các trang bên ngoài, với mỗi phần có nhóm trưởng mới (có thể là mô tả công việc mới với trách nhiệm quản lý / cố vấn / huấn luyện nhiều hơn so với các nhà phát triển cao cấp hiện tại ). Điều này bổ sung các silo nhân tạo và có thể gây khó khăn cho việc một "nhà phát triển mạng nội bộ" hoạt động trên một trang web bên ngoài nếu tôi muốn.
• Giữ cấu trúc phẳng và thêm hỗ trợ quản lý theo hình thức Quản lý dự án / Quản trị viên nhóm chỉ để giảm áp lực. Điều này không giải quyết được vấn đề vì nhóm không thể tiếp tục phát triển như thế này mãi mãi.

Có một cách tiêu chuẩn để giải quyết vấn đề này mà tôi đang thiếu?

Nếu không, làm thế nào những người khác của bạn đã giải quyết vấn đề này?

Một số suy nghĩ nhanh:

• Các nhóm phụ là một ý tưởng hay: 11 báo cáo trực tiếp mà không có cấu trúc nào quá lớn đối với một nhóm khả thi (bạn sẽ không có đủ thời gian để huấn luyện trực tiếp và các cuộc họp nhóm với nhiều người sẽ có xu hướng không hiệu quả).
• Xem xét tách các hoạt động ra khỏi sự phát triển - đó là một kỹ năng hơi khác biệt và bị gián đoạn bởi các vấn đề hoạt động cả ngày có thể gây tổn hại nghiêm trọng đến năng suất phát triển của các dự án.
• Theo kết quả của hai điểm đầu tiên, tôi nghĩ bạn có lẽ nên có 3 điểm phụ - Mạng nội bộ, Trang web bên ngoài và Hoạt động. Các nhân viên hoạt động sẽ giải quyết tất cả các vấn đề hàng ngày / sửa chữa bảo trì, vv trong khi hai nhóm phát triển tập trung vào việc cung cấp các dự án / giá trị mới cho doanh nghiệp.
• Chu kỳ người giữa các đội một cách thường xuyên. Điều này có thể là thỉnh thoảng (ví dụ: có người thực hiện đánh giá mã trong một phụ đề khác), cho một dự án hoặc trên cơ sở vĩnh viễn. Nhưng hãy chắc chắn rằng vai trò của nhóm sẽ thay đổi bất cứ khi nào có nhu cầu kinh doanh - không ai "sở hữu" một vai trò cụ thể mãi mãi.
• Đừng thêm nhiều người quản lý / quản trị viên - đây là một cách chắc chắn để giảm hiệu quả / năng suất chung của các nhóm của bạn. Có người có kinh nghiệm nhất trong mỗi nhóm phụ đóng vai trò dẫn dắt đội / huấn luyện viên. Hãy chắc chắn rằng họ thấy vai trò của họ ở đây là huấn luyện và làm cho cả đội thành công, và đảm bảo rằng họ được trang bị để hành xử theo cách này chứ không phải là một "người quản lý nhiệm vụ".
• Vai trò của bạn nên được tập trung vào quản lý các bên liên quan bên ngoài, ưu tiên các nguồn lực / nhiệm vụ trong nhóm và đóng vai trò là "huấn luyện viên trưởng". Bạn sẽ cần xử lý vấn đề thỉnh thoảng leo thang từ các nhóm phụ, nhưng nói chung, bạn nên khuyến khích họ tự giải quyết vấn đề mà không cần đến với bạn.
• Nếu bạn có kỹ thuật cao, bạn cũng có thể chọn đóng vai trò đảm bảo kiến ​​trúc sư / thiết kế. Nếu không, hãy tìm ai đó có thể, trong đội hoặc ở nơi khác .....

Ngoài ra, nó luôn luôn đáng để đi và (đọc lại) Tuyên ngôn Agile , và đặc biệt là mười hai nguyên tắc .

Cấu trúc đó sẽ chủ yếu depend on project specifications

Lý tưởng nhất, nên có 3 đàn em cho mỗi nhà phát triển cao cấp trong một nhóm. Do đó, có 2-3 nhà phát triển cao cấp trên một giảng viên chính.

Do đó, chỉ có lãnh đạo công nghệ sẽ báo cáo với PM về tình trạng tiến độ của dự án. Cấu trúc được mô tả vẫn giả định rằng đối với các vấn đề phi kỹ thuật (nghỉ phép, thời gian nghỉ, xung đột, v.v.) mọi người đều có thể truy cập vào PM.

Một trong những nhóm phát triển phần mềm tương đối thành công mà tôi là một phần của việc đã làm một cái gì đó như thế này, trên cơ sở từng dự án:

Người quản lý phát triển phần mềm / Nhà phát triển cao cấp / Người cố vấn, người mà mọi người khác đã báo cáo trực tiếp.

• Một người quản lý dự án, người đã giữ lịch trình, tạo điều kiện cho các yêu cầu và đàm phán chấp nhận, và đã thực hiện truyền thông. Mọi người cũng chấm dứt báo cáo với người này. Một người làm tài liệu (thỉnh thoảng cũng là Thủ tướng, nhưng chỉ khi chuyên môn cho phép).
• Một sự kết hợp của 1-3 nhà phát triển hoặc nhà phát triển cao cấp, tùy thuộc vào nhu cầu của dự án.
• Một nhà phát triển cơ sở khi có sẵn.
• Ai đó được chỉ định từ một nhóm QA.
• Một người cơ sở hạ tầng (một vai trò thường được người quản lý hoàn thành, vì anh ta cũng có năng lực SA vững chắc).

Nó hoạt động hoàn toàn tốt, và tôi yêu tổ chức đó. Mặt khác, tôi là Giám đốc phát triển phần mềm và cơ cấu tổ chức của nhóm đang phát triển.

Xem xét theo mô hình Tổ chức cán bộ chức năng . Điều này sẽ nói về tùy chọn thứ hai của bạn về việc chia nhóm theo sản phẩm phần mềm.

Để trích dẫn bài viết trong ngữ cảnh của bạn:

Sức mạnh lớn nhất của một tổ chức chức năng là nó liên kết các cấu trúc xã hội với việc cung cấp giá trị kinh doanh. Theo quan điểm của tôi, các dự án phần mềm thành công cũng như chúng cải thiện hiệu quả của hoạt động mà chúng hỗ trợ - mang lại giá trị kinh doanh. Bằng cách tổ chức các nhóm của bạn theo cùng một cách, bạn có một nhóm được định hướng xoay quanh việc thỏa mãn người dùng doanh nghiệp của họ.

Cơ cấu quản lý / nhân sự thực tế không liên quan ngoài điều đó.

Có một cách tiêu chuẩn để giải quyết vấn đề này mà tôi đang thiếu?

Không hẳn vậy. Nó sẽ phụ thuộc vào nhóm của bạn, bạn, những gì bạn cần hoàn thành và những tài nguyên nào công ty sẽ cung cấp cho bạn.

Cá nhân, loại chuyển đổi tốt nhất là bằng cách tách quản lý kỹ thuật từ quản lý hành chính. Thật hiếm khi mọi người giỏi cả hai và họ hiếm khi có xu hướng tương tác.

Một người xử lý các khía cạnh kỹ thuật. Những gì cần phải được thực hiện, ai sẽ làm điều đó, làm thế nào mọi thứ cần phải xếp hàng. Các mặt khác xử lý các khía cạnh hành chính. Đánh giá, các cuộc họp ngân sách, lập kế hoạch sản phẩm, vv Sau đó, họ làm việc cùng nhau để truyền đạt những hiểu biết từ bên này sang bên kia và để cung cấp một mặt trận thống nhất.

Làm thế nào điều này được chia tay có thể đi một vài cách khác nhau. Phổ biến nhất là để người quản lý kỹ thuật là bên hành chính và một người kiến ​​trúc sư là bên kỹ thuật. Họ là đồng nghiệp và báo cáo cho một giám đốc / VP.

Một công việc khác mà tôi đã thấy là để người quản lý kỹ thuật là người hành chính, và sau đó (các) trưởng nhóm đóng vai trò là người kỹ thuật. Điều này là khó khăn hơn và đòi hỏi đúng người để hành động như (hầu hết) các đồng nghiệp ngay cả khi báo cáo được phân cấp.

Đối với kịch bản cụ thể của bạn, tôi khuyên bạn nên có 2-3 nhóm và có các lãnh đạo kỹ thuật thực hiện các khía cạnh kỹ thuật và bạn tập trung vào quản trị. Đúng, nó cắt giảm thời gian từ các khách hàng tiềm năng thực sự viết mã, nhưng họ nên (nếu họ đang làm tốt công việc) thu lại thời gian đó bằng cách làm cho các nhà phát triển cơ sở hiệu quả hơn / hiệu quả hơn. Nó cung cấp cho họ nhiều động lực hơn và cảm giác hoàn thành với việc quảng bá thực tế quá. Và thực tế nhất, đó là việc bán cho quản lý dễ dàng hơn là mở một vị trí mới.