Ngoài việc chỉ đọc Mythical man month, bạn sẽ giải thích như thế nào với người quản lí dự án rằng mặc dù hai lập trình viên sẽ làm gấp đôi công việc của một lập trình viên, 10 lập trình viên có thể sẽ không làm gấp 10 lần công việc.Làm cách nào để giải thích chi phí liên lạc giữa các nhà phát triển trong một nhóm?
Tất cả phụ thuộc vào đối tượng của bạn là ai.
Bạn luôn có thể thử sử dụng đề xuất kinh doanh làm ví dụ. Nếu bạn đặt hai người vào một phòng và yêu cầu họ viết một đề xuất kinh doanh, họ có thể giải quyết xung đột một cách dễ dàng và làm cho mọi thứ dễ dàng trôi chảy. Nếu bạn ném mười người vào cùng một dự án đó, bạn sẽ có mười ý tưởng rất khác nhau và thay vì nhận được một cái gì đó được thực hiện nhanh gấp mười lần ... bạn sẽ nhận được thứ gì đó không có lưới và có thứ tự cường độ dài hơn để sản xuất.
Dưới đây là một sơ đồ như thế nào mà sẽ xem xét:
cảm ơn, tôi nghĩ rằng đây là một tốt nhất, tôi sẽ bỏ phiếu lên nhưng tôi chưa thể. – user121758
Giải thích cho PM rằng việc quản lý lưu lượng truy cập của điểm dừng 4 chiều là khá dễ dàng và dễ quản lý. Một người đến điểm dừng. Người tiếp theo đến điểm dừng. Người đầu tiên được đi. Nhưng khi bạn có 10 nhà phát triển trong một nhóm, nó giống như quản lý một trong những cuộc xung đột vòng ở DC hoặc giao lộ đường cao tốc chính nơi bạn có nhiều xe đến và đi từ mọi hướng. Không ai biết chuyện gì đang diễn ra nên mọi người dừng lại để xem anh chàng tiếp theo đang làm gì.
Quản lý hai nhà phát triển tương tự trong đó Một cuộc đàm phán với B và B nói chuyện với A. Thêm C thậm chí là ok vì cuộc hội thoại đủ nhỏ để mọi người có thể theo kịp.
Có từ A đến J tất cả việc theo dõi một nhiệm vụ anothers là khó khăn ngay cả đối với PM ... vì vậy để mong đợi các nhà phát triển không bị cuốn vào cuộc trò chuyện về những người đang làm những gì không chính xác bất ngờ.
Một con thỏ chạy khoảng cách trong 10 giây. chạy cùng một khoảng cách? :) – zakovyrya
Yêu cầu người quản lý dự án của bạn tưởng tượng mình trong phòng hội nghị. Cô đã được yêu cầu thiết kế một chiếc xe hơi từ đầu, xuống bulông cuối cùng, trong 10 tuần. Nếu chúng tôi đưa 9 người khác vào phòng, thiết kế có hoàn thành trong một tuần không? Chắc là không.
Vấn đề chính là mọi người tin rằng phát triển phần mềm là giống như xây dựng chiếc xe hơn là thiết kế nó, rõ ràng không phải như vậy. Tất cả các xe đều có chung khái niệm chung (động cơ đốt, vô lăng, vít có ren) và chúng tôi tái sử dụng các khái niệm chung trong phát triển phần mềm, nhưng mục tiêu cụ thể và mục tiêu cụ thể của chúng thay đổi đủ để yêu cầu thời gian sáng tạo. Nếu phần mềm xây dựng giống như xây dựng ô tô, chúng tôi sẽ làm việc dựa trên bản thiết kế kỹ thuật đã hoàn thành. Chúng tôi đang phát triển bản thiết kế.
Tôi không tin giải thích một PM làm thế nào để thực hiện công việc là một ý tưởng tốt, cũng không thích hợp, không phải từ điểm thành viên trong nhóm của view anyway (có thể sẽ làm hại nhiều hơn lợi). Điều này có lẽ là trách nhiệm của một PM cao cấp để đưa PM sang một bên và giải thích một cách khéo léo ý tưởng đằng sau combinations.
Cách khác là trình bày vấn đề cho PM và để chúng giải quyết vấn đề bằng cách thực hiện một nhận xét off-the-record một cách lịch sự mà bạn quan tâm với mô hình truyền thông hiện tại không hiệu quả được sử dụng cho dự án .
Nếu người quản lý dự án cần giải thích cho họ, hơn là vấn đề lớn hơn. Nhược điểm của nhóm đối với hiệu quả là giao tiếp, kiểm soát và phối hợp.Bạn có thể dễ dàng giải thích từ 1 đến 2 người - điều khiển mã cần thiết, sự phối hợp của các chương trình khuyến mãi, các điểm tích hợp và phương pháp tiếp cận dự án/mã hóa tổng thể - đi từ 4-5 trở lên khó hơn một chút - đó là quy mô thay đổi đội thực sự vấn đề (đi từ 150 đến 151 có ít tác động) ... lấy thông tin cụ thể, lấy lịch sử trước tại công ty của bạn liên quan đến dự án đơn lẻ cho các dự án nhóm - dựa trên phản hồi về các số liệu cụ thể nếu bạn có thể.
Dưới đây là một bài viết tốt để tham khảo:
Tôi thích bài viết. Đồ họa của các mạng được kết nối đầy đủ lại đặc biệt hiệu quả. – BIBD
Tốt thứ cho đến nay. Ngoài ra, hãy nhớ rằng nó không phải là khá cắt và khô như nhiều độc giả của tháng Man Mythical (và những người đã không đọc nó hoặc là) sẽ có bạn tin tưởng. Có lẽ anh/cô ấy đã xem xét những hiệu ứng này.
i.e., Adding people to a late project will only make it later.
Điều quan trọng cần hiểu là ảnh hưởng của việc thêm một người vào dự án và ảnh hưởng đến phần còn lại của dự án. Tuy nhiên, đó không phải là để nói rằng bạn không bao giờ nên thêm người cho họ.
Nếu chúng được yêu cầu cho một bộ kỹ năng cụ thể đang thiếu trong dự án, thì bạn phải làm như vậy.
Nếu bạn có thể giới hạn thông tin liên lạc mà họ phải có với phần còn lại của dự án, thì bạn sẽ tác động đến chi phí liên lạc.
Điều đó nói rằng, một người quản lý dự án tốt nên đã phá vỡ nhóm của mình thành các ô hợp lý để giảm thiểu yêu cầu nói chuyện chéo (và hoạt động như kênh/bộ lọc đó).
Chúng ta hãy ra khỏi phạm vi của dự án
Trên bất kỳ nhóm mục tiêu của nhà lãnh đạo là tạo ra một môi trường của sự gắn kết mà đặt mục tiêu đội đối với bất kỳ cá nhân chương trình nghị sự của
Vì vậy, để sử dụng một câu nói nổi tiếng
Một nhóm cần phải nhanh chóng nhưng không vội vàng
Câu trả lời về tài nguyên cần thiết nằm trong khả năng của trưởng nhóm triển khai hiệu quả tài năng ở các vị trí tối ưu nhất.
Bạn có thể mua nhiều bản sao của Tháng Manical để PM có thể đọc nhanh hơn. – laalto
@laalto để giành chiến thắng! –
Điều đó nhắc tôi về sự tương tự quản lý dự án yêu thích của tôi: "Nếu một người phụ nữ có thể sinh con trong 9 tháng, thì 9 phụ nữ sẽ có thể sinh con trong 1 tháng." –