Người quản lý dự án của chúng tôi thường hỏi nhà phát triển xem họ cần bao nhiêu giờ để thực hiện một số chức năng mà khách hàng yêu cầu. Điều này có phù hợp với các nguyên tắc quản lý không? Bạn hoặc người quản lý dự án của bạn có làm như vậy không?Quản lý dự án có nên hỏi sẽ mất bao nhiêu thời gian để thực hiện một số chức năng?
Không còn cách nào khác để biết sẽ mất bao lâu. Bạn nên biết ơn, thực sự, rằng PM của bạn thậm chí còn tư vấn cho bạn - quá nhiều nhà quản lý gặp gỡ khách hàng và hứa hẹn thời hạn không thể, sau đó mong đợi các nhà phát triển sống theo lời hứa thái quá của họ.
thực sự, công ty chúng tôi thậm chí không tham khảo ý kiến của chúng tôi (cũng không phải là allways ...). và sau đó chúng tôi phải nói với họ, xin lỗi nhưng điều đó là không thể. – user29964
Chắc chắn. Nếu không nhận được ước tính cho thời gian phát triển không ai có một đầu mối những gì đang xảy ra. Bạn cần có khả năng quản lý kỳ vọng của các bên liên quan, trong trường hợp này là khách hàng của bạn. Và ước tính tốt hơn đến từ miệng ngựa (trong trường hợp này là nhà phát triển) chứ không phải là PM hứa hẹn khung thời gian không thể!
Các nhà phát triển đôi khi trở nên buồn cười khi thực hiện ước tính về bản chất này (tôi biết mình làm), nhưng điều quan trọng là phải điều hành một doanh nghiệp. Cách dễ nhất để tiếp cận nó là hiểu rằng PM chỉ muốn thông tin. Hãy cởi mở và trung thực - đừng nói mọi thứ sẽ được thực hiện khi họ không làm, và giải thích khi nào và tại sao mọi thứ có thể chưa được biết, hoặc tại sao có thể có một yếu tố nguy cơ xung quanh ước tính của bạn.
Có. Tốt hơn là người quản lý tư vấn cho nhóm về thời gian cần thiết. Và nhóm nghiên cứu phải đưa ra dòng thời gian thực tế xem xét tất cả các yếu tố. Các onus là trên đội để biện minh cho thời gian cần thiết để đưa ra chất lượng đầu ra. Nếu người quản lý đủ tốt, anh/cô ấy sẽ đánh giá cao và đồng ý với nhóm.
Tôi nghĩ nó nghe khá hay. Dường như tốt hơn là anh ta yêu cầu một ước tính của những người sẽ làm điều đó hơn là chỉ hứa hẹn một cái gì đó cho khách hàng mà có thể trở thành không thực tế.
Bạn rõ ràng chưa bao giờ làm việc cho người quản lý không yêu cầu ước tính từ bạn. Nếu không, bạn sẽ biết tốt hơn là đặt câu hỏi liệu họ có nên làm điều đó không. :-)
Nghiêm túc, rất ít người quản lý có thể đưa ra ước tính thực tế về thời gian cần thiết để cung cấp tính năng cụ thể, chủ yếu là vì không phải là công việc của họ thực sự làm giảm tất cả các phức tạp kỹ thuật. Một người quản lý tốt sẽ nhận ra điều này và sẽ luôn luôn liên quan đến các nhà phát triển để có được ước tính tốt về công việc có thể phù hợp khi tạo lịch biểu.
Có, bạn không thể rời khỏi các PM muốn có con số chính xác về thời gian sẽ mất bao lâu.
Cách tiếp cận của tôi là đưa ra ước tính với giá trị +/-. Tôi chắc chắn rằng tôi sẽ hoàn thành 60% trong một tuần, có 30% cơ hội sẽ lâu hơn và 10% cơ hội sẽ là 2 ngày. Mất một thời gian cho một PM để làm quen với ý tưởng đó, nhưng đó là thực tế của tình hình. Như ai đó khôn ngoan đã từng nói, chỉ [chèn thần tính ở đây] mới có thể thay đổi thực tế, bất kể PM sẽ như thế nào thì khác.
Chúng tôi biết rằng Dev là một môn khoa học chính xác, sự căng thẳng của quản lý dự án truyền thống, sự sáng tạo và dự đoán phỏng đoán tốt nhất có lẽ là đau đầu lớn nhất trong phát triển nghề nghiệp. Một sự học hỏi thực sự tốt từ Agile là chúng ta đang ước lượng ra sao, hầu hết Dev sẽ đánh giá thấp 80% thời gian - đó là ước tính của tôi.
Với điều kiện là anh ấy chấp nhận câu trả lời của bạn.
Nếu một PM có một số trong tâm trí khi anh ta hỏi bạn câu hỏi anh ta không nên ngạc nhiên bởi kết quả của mình.
Người quản lý dự án phải luôn hỏi nhà phát triển xem sẽ mất bao lâu. Những gì người quản lý dự án làm với những ước tính đó sẽ khác nhau đáng kể tùy thuộc vào kinh nghiệm và kỹ năng của riêng họ.
Nếu PM có nhiều kinh nghiệm phát triển, họ sẽ có thể hỗ trợ nhiều nhà phát triển cơ sở trong việc xác định xem ước tính của nhà phát triển có hợp lệ hay không và hy vọng chỉ ra lý do tại sao họ cho rằng ước tính là sai. Ngoài ra, một PM sẽ có thể thêm vào trong các yếu tố khác mà các nhà phát triển có xu hướng quên - thời gian họp, bệnh tật, thời gian trên SO vv, mà tất cả tác động đến thời gian của họ.
Nếu PM có ít kinh nghiệm phát triển thì ước tính chính xác nhất sẽ đến từ các nhà phát triển.
Câu hỏi công bằng của nó, chỉ cần không bao giờ trả lời với một ước tính tắt cuff. Luôn luôn lấy được ước tính từ một số loại đặc điểm kỹ thuật, theo cách đó cả hai trên mặt đất cấp, đó là lời khuyên của tôi anyway.
Vâng, đó là công việc của mình, bởi vì thời gian = tiền
Nếu bạn xem xét thực tế là
Sau đó, nó có ý nghĩa hoàn hảo mà người quản lý của bạn yêu cầu bạn "Mất bao nhiêu thời gian" bởi vì nó dịch hoàn hảo thành "Chi phí này sẽ mất bao nhiêu".
Ai đó phải trả chi phí đó, đó sẽ là khách hàng hoặc công ty của bạn. PM sẽ sử dụng các ước tính của bạn để đảm bảo dự án đến đúng giờ và với ngân sách. Nếu bạn nói điều gì đó sẽ mất 10 ngày, và đó là 5 ngày nhiều hơn anh ta thích, thì đó là tùy thuộc vào anh ta hoặc là a) cắt một số chức năng khác để có được điều này trong hoặc b) gia hạn thời hạn.
Vì vậy, đó là công việc của PM, để nhận ước tính từ bạn và cân bằng giữa phân phối thời gian và chức năng được phân phối.
CÔNG VIỆC của bạn là cung cấp các ước tính tốt nhất, trung thực nhất mà bạn có thể. Giống như một người khác nói, luôn luôn cung cấp cho một sự tự tin prcentage. "2 ngày, 30% tự tin" "Có thể 1 ngày, có thể là 3 trường hợp xấu nhất", v.v.
Có thể khó chịu khi được hỏi, nhưng đó là công việc của mình.
P.S. Đôi khi câu trả lời "Tôi không biết" là hoàn toàn chấp nhận được, tuy nhiên bạn nên cụm từ nó là "Tôi không biết, tôi cần phải nhìn vào nó nhiều hơn một chút và tôi sẽ có một ý tưởng tốt hơn sau đó".
Hy vọng điều này sẽ hữu ích.
Một trong những ưu điểm chính của điều này là nó giúp bạn tìm ra sớm trong trò chơi mà bạn bị choáng ngợp bởi một nhiệm vụ: Nếu bạn không thể thời gian, bạn có thể không biết cách giải quyết nó.
Ngoài ra, nếu ước tính của bạn nhiều hơn một tuần, thì có thể giảm 100-1'000'000% (a.k.a "suy đoán thuần túy"). Nếu bạn nghĩ ra "vài tuần", tôi khuyên bạn nên bắt đầu phá vỡ nhiệm vụ và ước lượng các phần.Điều này sẽ giúp bạn nhận thấy các vùng nguy hiểm (nơi bạn thực sự không biết sẽ mất bao lâu).
Quy trình này sẽ cho phép người quản lý của bạn trợ giúp bạn/hoàn thành công việc của bạn kịp thời (thay vì chú ý điều gì đó thiếu quan trọng hai ngày trước thời hạn).
Nếu bạn quan tâm nhiều hơn đến những điều này, tôi đề xuất sách "Death March" và trang web Extreme Programming (đặc biệt là this page). Lấy XP bằng một hạt muối: Các quy tắc sẽ không bao giờ giải quyết vấn đề của bạn; họ chỉ nói cho bạn biết những gì làm việc cho người khác. Bạn sẽ luôn luôn sử dụng chúng một cách khôn ngoan.
Hỏi là tốt hơn nhiều so với giả định.
Chúng tôi đã có một người quản lý kinh doanh gần đây đề cập đến trong một cuộc họp toàn thể nhân viên rằng một loạt các tính năng mới đang trên đường và họ không nên nỗ lực quá nhiều để thực hiện. Đây là tin tức cho đội ngũ phát triển !!
Để thêm một số ý nghĩa cho điều này, bạn nên ít nhất là xây dựng _why_ thực hành này có vẻ kỳ lạ với bạn, và những gì bạn sẽ tìm thấy tự nhiên. Như câu hỏi hiện nay, câu trả lời hợp lý duy nhất là "Có, tất nhiên. Tại sao không?" –
Giải pháp thay thế là gì? – Simon
Mô hình nguồn mở, không có ràng buộc về thời gian. Nhưng điều này không mang lại lợi nhuận cao cho một công ty ... – mouviciel