Danh sách các hành vi quản lý này có thực sự thu hút các nhà phát triển phần mềm không? [đóng cửa]

Tôi đã xem qua danh sách các hành vi quản lý này ( http://suven.posterous.com/dos-and-donts-lead-software-development-te ).

Tôi nghĩ rằng nó có một số đá quý, nhưng tôi không phải là 100% trong số chúng. Tôi đã đánh dấu những cái đó bằng chữ nghiêng và tên của tôi.

Bạn, với tư cách là một nhà phát triển phần mềm, nghĩ rằng những thứ này có hấp dẫn không? Ba mục nào sẽ là mục "phải có" của bạn từ ban quản lý?

Đừng

• Đừng quy mô đội theo chiều dọc bằng cách thêm nhiều người

• Đừng tạo một nhóm có hơn 10 người

• Đừng gọi tài nguyên của mọi người, nó không hay và thực sự gây khó chịu

• Đừng cho rằng mọi người trong nhóm có thể hoán đổi cho nhau

• Đừng so sánh các đội với nhau khi làm nổi bật điểm yếu

• Đừng ném các đội vào nhau

• Đừng tạo thời hạn giả

• Đừng ép buộc tiêu chuẩn hóa các công cụ và quy trình giữa các nhóm (Tôi nghĩ rằng điều này có thể được tranh luận trong một số tình huống - Todd)

• Đừng thuê người quản lý sản phẩm không có đầu mối về phát triển phần mềm

• Đừng độc quyền sử dụng KPI để điều khiển các nhóm của bạn (Không chỉ không hiệu quả, mà các nhà phát triển sẽ tìm cách điều khiển các số liệu KPI - "Bạn muốn có các dòng mã? Tôi đã có các dòng mã của mình!" - Todd)

• Đừng buộc các nhóm của bạn làm việc quá giờ, thậm chí yêu cầu bị ràng buộc để tạo ra căng thẳng

• Đừng cho rằng nhân đôi số người bằng một nửa thời gian

Làm

• Thực hiện quy mô theo chiều ngang bằng cách tạo thêm các nhóm khoảng 5-8 người

• Có tầm nhìn cho sản phẩm và đội ngũ

• Hãy đánh giá cao rằng mỗi đội là khác nhau, vì vậy hãy phân bổ các dự án một cách thích hợp

• Hãy thúc đẩy các nhóm của bạn (Wow - đó là một người trơn trượt, khó xác định. Tôi đồng ý với tình cảm, nhưng nó giống như nói "Hãy hiệu quả" mà không có hướng dẫn. -Todd)

• Không cho phép mọi người di chuyển giữa các đội

• Có phiên để thảo luận về tầm nhìn, chiến lược, công nghệ và quy trình sản phẩm

• Có liên quan đến nhóm khi xác định tên nhóm / sản phẩm

• Đừng cho phép các đội của bạn đưa ra quyết định của riêng họ, đặc biệt nếu họ là những người có chuyên môn

• Có liên quan đến nhóm của bạn về bất kỳ quyết định nào ảnh hưởng đến cách thức hoặc những gì họ làm việc trên

• Không khuyến khích một phương pháp phát triển phù hợp với nhóm và dự án

• Hãy chú ý đến kế hoạch phát triển cá nhân của mỗi cá nhân

Tôi đoán là danh sách này thực sự hấp dẫn các nhà phát triển phần mềm bởi vì nó xác nhận hình ảnh bản thân của họ là những diva sáng tạo được nuông chiều hơn là những người giải quyết vấn đề khó khăn (một Winston Wolf) và mong muốn được đối xử chuyên nghiệp.

Tôi cũng nghi ngờ nếu chúng tôi cải tiến các kỹ thuật phát triển phần mềm đến mức thương mại của chúng tôi có thể được chứng nhận như của các kiến ​​trúc sư, luật sư, chuyên gia y tế và tương tự, chúng tôi sẽ có thể chỉ đạo cách quản lý các nhà phát triển phần mềm tốt hơn.