Quản lý dự án muốn khóa thời gian ước tính bằng hợp đồng đã ký

Ở lần làm việc trước, người quản lý dự án (PM) không hài lòng với thời gian giao mã của dự án tôi đang thực hiện. Tôi được người đứng đầu dự án của tôi nói rằng Thủ tướng đang xem xét để tôi ký hợp đồng để khóa các ước tính thời gian của tôi, tôi đã đưa ra cho các nhiệm vụ và ngày giao hàng.

Tình huống trong dự án là chúng tôi đã làm việc với các công nghệ mới, cơ sở mã hóa, tiêu chuẩn mã hóa và các yêu cầu rất dễ thay đổi. Tôi đã học được những điều mới và áp dụng chúng tốt nhất có thể theo yêu cầu luôn thay đổi. Các yêu cầu trong các lần lặp lại tăng gấp 2-3 lần, với ước tính của tôi sẽ tăng lên khoảng 5-8 lần. Điều duy nhất không thay đổi là ước tính và ngày giao hàng.

Vâng, cuối cùng tôi đã bỏ lỡ hầu hết thời hạn. Và tôi đã làm việc trên một số công nghệ rất mới mà không ai khác trong toàn bộ nhóm phát triển có thể thực sự giúp đỡ vì họ sẽ không quen thuộc với nó. Ít nhất là không dễ dàng.

Dường như với tôi sau đó, Thủ tướng muốn số của mình tăng lên - và do đó muốn tôi ký hợp đồng để "đảm bảo" rằng tôi sẽ luôn cung cấp mã làm việc đúng hạn. Tôi cho rằng với một hợp đồng đã ký, Thủ tướng có thể sử dụng nó chống lại tôi nếu tôi không thể giao hàng đúng hạn.

Tôi tin rằng những gì xảy ra tiếp theo là các nhà quản lý dự án và / hoặc lãnh đạo dự án khác đã bảo vệ tôi và không để điều này xảy ra.

Câu hỏi của tôi là, điều này có nên giương cờ đỏ về người quản lý không? Đây có phải là thông lệ đối với người quản lý để khóa các ước tính thời gian của nhà phát triển phần mềm với hợp đồng đã ký không? Hoặc trong trường hợp này, cố gắng.

Xin lưu ý, tôi là một nhân viên toàn thời gian, không phải là một nhà tư vấn độc lập.

Cập nhật : Tôi muốn thêm rằng tôi đã đưa ra các ước tính mới hàng tuần, nhưng có vẻ như các ước tính ban đầu và ngày giao hàng là những gì Thủ tướng đã cố định.

Câu hỏi của tôi là, điều này có nên giương cờ đỏ về người quản lý không?

Có . Điều đó có nghĩa là đã đến lúc bạn cần cập nhật sơ yếu lý lịch / CV và bắt đầu tìm kiếm một công việc mới. Hoặc nó có nghĩa là người quản lý của bạn sắp bắt đầu chơi một số trò chơi rất khó chịu với bạn.

Đây có phải là thông lệ đối với người quản lý để khóa các ước tính thời gian của nhà phát triển phần mềm với hợp đồng đã ký không?

Tôi chưa bao giờ nghe nói về việc này được áp dụng cho một nhân viên.

Thời gian và nỗ lực ước tính luôn luôn khó khăn. Đặc biệt là vì nghề nghiệp của chúng tôi đầy lạc quan quá mức. Có một số hệ thống ước tính có thể giúp ước tính trong tương lai, nhưng chúng cần thu thập số liệu thống kê lịch sử từ chính bạn. Một là PSP . Một điểm khác là Điểm chức năng . Nhiều nhà phát triển không thích, và bạn sẽ tìm thấy những ý kiến ​​rất mạnh mẽ chống lại cả hai.

Khó khăn chính trong việc ước tính thời gian và nỗ lực là thiếu thông tin phản hồi trong các phỏng đoán ước tính của chúng tôi. Một trong những chìa khóa là viết ra những gì bạn nghĩ là ước tính và những thông số bạn đã sử dụng để ước tính nó. Sau đó, dựa trên những gì bạn thực sự hoàn thành, hãy so sánh điều đó với những gì bạn nghĩ bạn sẽ làm. Và sử dụng điều đó để sửa đổi các tham số ước tính của bạn. Trong kỹ thuật, chúng tôi gọi đây là " phản hồi ."

Vâng, điều đó hoàn toàn nên tiếng chuông báo động.

Nếu tôi ở vị trí này, để giải trí cá nhân, tôi sẽ yêu cầu người quản lý ký hợp đồng đóng băng tất cả các yêu cầu. Tôi tưởng tượng người quản lý có khả năng tại ngoại. Sau đó tôi sẽ rời đi.

Thật đơn giản. Chỉ cần nói với người quản lý của bạn rằng bạn sẽ đăng nhập để khóa ước tính thời gian của mình khi anh ta sẽ đăng nhập để khóa thông số kỹ thuật. Bởi vì bạn không thể, chắc chắn cung cấp bất kỳ ước tính cho một cái gì đó chưa biết. Thông số dự án đầy đủ trước khi bạn bắt đầu, không có thay đổi - và bạn có thể hoàn thành kịp thời gian :)

Một thay đổi cho spec => hợp đồng là vô hiệu. Có lẽ mọi thứ sẽ biến mất chỉ sau 10 phút vào ngày đầu tiên của bạn :)

Vâng, đây là một lá cờ đỏ. Điều nó nói với bạn là người quản lý không hiểu cách quản lý rủi ro trong các dự án phần mềm. Những gì anh ấy nên làm là tìm ra chính xác điều gì gây ra sự chậm trễ ở nơi đầu tiên và sau đó bắt đầu thực hiện một quy trình để quản lý hiệu quả các rủi ro lịch trình sẽ không thể tránh khỏi trong một dự án phần mềm.

KHÔNG BAO GIỜ trong mọi trường hợp tôi sẽ ký hợp đồng với người quản lý của mình để đảm bảo lịch trình. Những người khác đã đề cập đến việc anh ta ký một khóa về thông số kỹ thuật. Điều này theo tôi là không đủ. Điều này không giải thích cho những khó khăn không lường trước được với các công cụ hoặc công nghệ, thiết kế không hoàn chỉnh hoặc kém, hiệu suất của các thành viên khác trong nhóm, v.v.

Đây không phải là một lá cờ đỏ, đây là sự ngu ngốc cấp vũ khí.

Nếu ước tính và thời hạn được liên tục thổi, điều hợp lý cần làm là xác định nguyên nhân và cải thiện các quy trình.

Nếu bạn đổ lỗi và đá con ngựa vì bạn không biết mình đang đi đâu, đừng ngạc nhiên nếu con ngựa cắn bạn và bỏ chạy!

Trong khi người quản lý đã không phù hợp với nhu cầu của mình. Anh ấy không hoàn toàn để đổ lỗi. Nếu bạn đang làm việc trong lãnh thổ hoàn toàn xa lạ, không có gì sai khi nói "Tôi không biết." Phải mất một thời gian tôi mới nhận ra rằng "Tôi không biết" là một câu trả lời hoàn toàn có thể chấp nhận được, vì vậy tôi biết bao nhiêu để nói ra những lời đó. Nhưng nếu bạn thực sự không biết thì đó là câu trả lời. Và nếu họ chùn bước, hãy yêu cầu họ đưa ra ước tính về việc bạn sẽ mất bao nhiêu đồng xu để tạo ra một chồng cao như Tháp Sears (biến nó thành Willis). Và họ có sẵn sàng ký hợp đồng trả cho bạn mỗi xu họ đã nghỉ không?

Bất kỳ Người quản lý dự án nào xứng đáng với mức lương của anh ta đều nên biết rằng một số thứ không phù hợp và đẹp trong bảng tính. Đôi khi mọi thứ được thực hiện khi chúng được thực hiện. Tôi nghĩ bạn đang làm tốt bằng cách đưa ra tiến bộ về số tiền bạn đã làm. Chỉ cần ngừng đưa ra các bản cập nhật số.

Một bài tập khác là chia nhiệm vụ lớn thành các đơn vị nhỏ hơn có thể ước tính hơn. Bài tập này sẽ giúp bạn hiểu rõ hơn những gì bạn cần làm là tốt. Kiểm tra Dự toán phần mềm của Steve McConnell và Các mẫu yêu cầu phần mềm của Stephen Withall để biết các mẹo về phá vỡ các nhiệm vụ và khám phá các yêu cầu ẩn tương ứng.

Đừng bắn từ hông vào một ước tính. Hãy dành thời gian để phá vỡ nó. Ước tính một số lượng lớn các nhiệm vụ nhỏ sẽ cho bạn ước tính tổng thể tốt hơn (do luật trung bình, một số ước tính của bạn sẽ được thực hiện nhưng một số sẽ kết thúc và chúng sẽ có xu hướng cân nhắc lẫn nhau) của nhiệm vụ lớn.

Hỏi "người quản lý dự án" của bạn: Chúng tôi đang bán phần mềm hay thời hạn?

Tôi là người quản lý dự án và lập trình viên :-) Tôi có thể nói rất nhiều về việc hầu hết các PM đến từ bên ngoài ngành và không thể xử lý bất cứ điều gì không phù hợp với mô hình dây chuyền sản xuất ... nhưng tôi sẽ không, không phải ở đây. Thay vào đó, đây là một cuộc bút chiến dài về những việc cần làm (Mr Mod, nếu quá lâu hãy làm những gì bạn sẽ làm với nó). Tôi đồng ý với các ý kiến ​​đã được đưa ra ở đây, một số bạn nên làm trước những người khác, nhưng đây là điều tôi nghĩ tốt nhất là bước đầu tiên của bạn . Ồ, và câu trả lời rõ ràng cho câu hỏi của bạn là có, nhưng đó được xây dựng bằng ngôn ngữ đầy màu sắc và chi tiết dưới đây.

Trước khi tôi bắt đầu, mặc dù lưu ý rằng Thủ tướng rất có thể mang đến cho bạn sự đau buồn, bởi vì một người nào khác trong chuỗi thức ăn đang khiến họ đau buồn. Chúng (chúng ta) là những sinh vật đơn giản ... Có nhiều cách để tránh tình huống bạn mô tả - Mike Brown che đậy điều đó khá tốt. Cũng không có gì sai khi hội thảo một cái gì đó cho 3/4/5 .. hàng giờ liền trước khi khởi động nó (thực sự tất cả các loại báo động cần phải tắt nếu điều này không xảy ra). Và nếu bạn đang đi vào lãnh thổ chưa biết, hãy lùi lại và yêu cầu một tuần để nghiên cứu khu vực & công nghệ để có thể đưa ra ước tính hợp lý (bạn sẽ muốn làm điều này đúng vì bạn muốn công nghệ mới học và chơi với don bạn là ai?). Nếu PM của bạn và quản lý tại nơi bạn đang ở không hiểu điều này ... thì hãy cập nhật sơ yếu lý lịch của bạn và tìm lối thoát gần nhất, để lại cho họ số phận họ rất xứng đáng. Rằng Thủ tướng thậm chí sẽ nghĩ rằng việc một nhân viên toàn thời gian ký hợp đồng như thế là một dấu hiệu xấu xấu ... cách duy nhất tôi có thể thấy là họcó thể không hoàn toàn bất tài là họ thực sự chỉ chơi trò chơi trí tuệ với người dẫn đầu dự án của bạn và bạn (từ những gì tôi đọc họ đã không đưa điều này trực tiếp cho bạn, và cuối cùng không theo dõi mối đe dọa). Rốt cuộc là một thiên đường cho tâm lý công ty tiêu chuẩn của bạn sau khi tất cả. Thật tốt khi những người khác đã nói xấu bạn từ những gì bạn nói, vì vậy lời khuyên dưới đây có thể đã trở nên tích cực cho bạn cuối cùng. Tôi tưởng tượng họ sẽ có một cuộc cách mạng trong tay nếu nó trở nên nhiều hơn nói chuyện.

Vì vậy, với tình huống / lỗ hổng thực tế mà bạn đã mô tả , bởi vì nó sẽ xảy ra một lần nữa với ai đó, ở đâu đó (như khoảng 5 phút trước và một lần nữa trong 5 ngày khác, calendarRepeat ()). Có lẽ không có sự ngu ngốc của hợp đồng, nhưng cốt truyện cơ bản luôn giống nhau. Tổ chức một cuộc họp (!), Họ thích các cuộc họp ;-) mọi người có thể vỗ lưng vào cuối như thể một cái gì đó đã thực sự được thực hiện. QUAN TRỌNG:Hãy chắc chắn rằng bạn bao gồm trưởng nhóm dự án kỹ thuật / trưởng nhóm / kiến ​​trúc sư / quản lý thiết kế của bạn trong lời mời họp đã giải quyết vấn đề với họ và đưa họ lên tàu. Hệ thống phân cấp càng cao bạn có thể dành cho ai đó ở bên 'bạn' thì càng tốt. Bởi vì PM của bạn sẽ thấy điều đó và thử và kết hợp trình quản lý thiết kế của bạn với một mức tương đương. Nếu không, họ thật ngu ngốc và bạn đã chiến thắng. Điều đó nói chung sẽ kéo họ trở lại thành hàng, bởi vì bây giờ chúng có thể được nhìn thấy bởi một người có thể sa thải họ ngay tại chỗ. Nếu họ đang chơi trò chơi với bạn, bạn được phép trả lại sự ủng hộ.

Trong cuộc họp, hãy xem qua các chi tiết kỹ thuật về những gì bạn đang giải quyết và tại sao phải mất thời gian. Họ sẽ muốn biết điều này (và làm thế nào họ có thể giúp bạn hoàn thành nó), nhưng thực tế đáng buồn là điều này thường không xảy ra ... có lẽ bạn sẽ nhận được 10 phút trước khi mắt họ quay lại. Bây giờ những gì tôi muốn làm ở đây có lẽ không hợp pháp ... vâng, tôi đã kiểm tra, nó thực sự rất bất hợp pháp và bạn không muốn ngồi tù lâu như vậy. Vấn đề là bạn đã nỗ lực hết sức để chủ động và nếu bạn có một số người có trình độ cao hơn, thì nỗi đau của bạn bây giờ là của họ ... như nó phải vậy. Bạn sẽ phải sử dụng phán đoán của mình về cách mọi thứ có thể diễn ra, bởi vì 'leo thang' là điều sẽ xảy ra. Nếu lãnh đạo tại nơi bạn ở là một nửa đàng hoàng, họ sẽ làm đúng, và làm điều đúng bởi bạn là tốt. Nếu không, thì bạn đã có sơ yếu lý lịch của bạn trên thị trường trước đó ... bạn sẽ rời đi ngay cơ hội đầu tiên (và có vẻ như cuối cùng bạn đã làm). Ban lãnh đạo sẽ rơi vào hai nhóm - hoặc họ là những người am hiểu về kỹ thuật và họ sẽ thấy ngay quan điểm của bạn; hoặc họ không và họ sẽ làm gì với nó ngoài việc cười và chịu đựng nó? Nếu họ có thể làm những gì bạn làm, thì họ đã làm như vậy. và họ sẽ làm gì với nó ngoài việc cười và chịu đựng nó? Nếu họ có thể làm những gì bạn làm, thì họ đã làm như vậy. và họ sẽ làm gì với nó ngoài việc cười và chịu đựng nó? Nếu họ có thể làm những gì bạn làm, thì họ đã làm như vậy.

Giữ vấn đề thay đổi yêu cầu như là con át chủ bài của bạn để sử dụng vào cuối ... nó sẽ phục vụ như là một lối thoát cho tất cả mọi người. Bản thân dự án và khách hàng / các bên liên quan chết tiệt sẽ có tên của họ vô ích. Cách không đau đớn nhất về phía trước sẽ là một loại thiết lập lại xảy ra trong dự án, và có lẽ PM sẽ lặng lẽ được chỉ định lại cho một khu vực khác. Phép lạ thỉnh thoảng xảy ra. Nếu vấn đề hợp đồng được đưa ra trong cuộc họp của Thủ tướng, thì hãy đáp lại yêu cầu đóng băng yêu cầu đối tác - theo như tôi lo ngại, họ đã đốt cầu của bạn với bạn và cho toàn bộ nhóm phát triển, khi họ bắt đầu chơi những trò chơi trí tuệ

Trước khi tôi đăng xuất: Thay đổi phạm vi / yêu cầu - một trong những lý do tốt nhất để áp dụng phương pháp Agile, vì vậy khách hàng / các bên liên quan có trách nhiệm đúng đắn để thay đổi suy nghĩ của họ về những gì họ muốn ...

Ồ, một điều khác: trong tuyên bố "Tôi không biết", luôn là tiêu chuẩn cá nhân của tôi về cách đánh giá giá trị của một kỹ thuật viên đồng nghiệp hoặc thành viên trong một trong các nhóm dự án của tôi. Tôi thấy những người duy nhất có thể nói rằng thẳng vào mặt bạn là tốt nhất, chủ yếu là bởi vì ai đó biết họ ở sâu thẳm sẽ không bao giờ nói điều đó - mở ra cho họ thấy được ai đó có khả năng thực sự rõ ràng một nhịp tim. Mặt khác, một người nào đó sẽ lên tiếng và nói điều đó, cũng sẽ có một kế hoạch cơ bản (ngay cả khi nó chưa được nghĩ đến) về cách giải quyết những điều chưa biết để trong 24 giờ sẽ có câu trả lời hữu ích hơn, và trong thời gian một tuần thậm chí còn tốt hơn. Khi Apollo 13 đang bay quanh mặt tối của Mặt trăng, có cả đống "tôi không biết" đang xảy ra.

Có, điều này sẽ giơ cờ đỏ, đặc biệt nếu bạn là nhân viên chính thức. Các điều kiện của hợp đồng là gì? Bạn thực sự sẽ bị sa thải nếu bạn bỏ lỡ thời hạn? Hay bạn sẽ bỏ lỡ một phần thưởng? Họ sẽ làm gì?

Cờ này tăng lên là người quản lý không biết làm thế nào để quản lý một dự án xử lý các công nghệ mới / lạ và các yêu cầu thay đổi ảnh hưởng trực tiếp đến nỗ lực ước tính. Mặc dù thời hạn khó khăn đôi khi xảy ra, một người quản lý biết tình huống không nên cố gắng để nhân viên ký hợp đồng để thực thi chúng. Đêm muộn và thời gian khủng hoảng sẽ là xấu nhưng đó có lẽ là ngang bằng với khóa học. Và đôi khi thời hạn sẽ trượt. Nó xảy ra, và giống như một người khác được đăng, cách duy nhất để tuân thủ lịch trình là đóng băng các yêu cầu SỚM TRÊN để vẫn còn đủ chỗ để giữ dòng thời gian.

Từ những gì bạn đã nói, tiếng chuông báo thức là một vài tháng quá muộn. Thông thường rủi ro khi dựa trên một dự án nhạy cảm với thời gian trên các công nghệ mà nhân viên chưa quen thuộc. Thật ngu ngốc khi làm như vậy nếu bạn không nắm bắt được yêu cầu thu thập và quản lý phạm vi.

Điều đó nói rằng, tôi đồng ý với các câu trả lời khác. Ngoài ra, bạn có thể muốn cập nhật sơ yếu lý lịch của mình nếu bạn chưa làm như vậy.

Cũng giống như tất cả những người được hỏi khác, tôi không thể đồng ý nhiều hơn rằng điều này sẽ giương cờ đỏ.

Có vẻ như Thủ tướng không muốn tham gia vào quá trình phát triển.

Trong thực tế cá nhân của tôi, từ lâu tôi đã tránh xa việc xử lý các thông số kỹ thuật chi tiết, đăng xuất, ước tính dự án đầy đủ hoặc giá thầu cố định (từ góc độ tư vấn).

Lý do cho điều này là sự hiện thực hóa, điều mà nhiều chuyên gia về Agile và Lean Software nói đến, phần mềm đó không phải là một thực thể có thể sản xuất cố định, nhưng nó chủ yếu là một quá trình khám phá.

Nhiều người vẫn gặp rắc rối với khái niệm này và có vẻ như PM của bạn cũng vậy. Nó đi đến một sự hiểu biết đơn giản về sự đánh đổi.

Thông số kỹ thuật cứng nhắc và ước tính cố định hoạt động cho các hệ thống có chi phí thay đổi cao. Giống như xây dựng một tòa nhà cao tầng. Nếu bạn quên chỉ ra các trục thang máy ở phía trước, thì sẽ rất khó để cải tạo lại tòa nhà một khi nó được dựng lên. Chi phí thay đổi cao đòi hỏi rất nhiều kế hoạch trước, tìm hiểu những ẩn số của các thành phần và công nghệ, và thử nghiệm trước. Chỉ khi bạn đã hoàn thành tất cả bài tập về nhà này, bạn có thể ước tính ngân sách và chi phí.

Trong phần mềm, mọi người đã rất quen với ý tưởng rằng chi phí thay đổi thấp, và vì vậy họ muốn tận dụng khả năng thay đổi mọi thứ một khi họ thấy một bản phát hành, kết hợp sự hiểu biết mới về ứng dụng, doanh nghiệp, khách hàng một cơ sở đang diễn ra. Tất cả điều này là tốt và một cơ hội lớn khi tận dụng chính xác. Hầu hết những người làm phần mềm mà tôi đã gặp và làm việc cùng thực sự không thích dành nhiều thời gian để lập kế hoạch hoặc điều tra; hầu hết chúng ta (bao gồm PM) muốn xem lực kéo đang diễn ra. Đây là nơi phát triển lặp đi lặp lại với các bản phát hành nhỏ, tăng dần của chức năng. Có những thực tiễn khác có thể được sử dụng, chẳng hạn như phát triển dựa trên thử nghiệm để đảm bảo rằng chi phí thay đổi vẫn ở mức thấp và có nợ kỹ thuật.

Làm cho công việc này liên quan đến một "hợp đồng" giữa hai bên, chủ sở hữu sản phẩm (Agile nói cho PM của bạn hoặc khách hàng hoặc nhóm QA) và nhà phát triển. Các nhà phát triển đồng ý chỉ làm việc trên các công cụ được ưu tiên là quan trọng nhất cho lần lặp đã cho và không mất thời gian với điều đó, nhưng cố gắng phát hành các khối chức năng tích hợp đầy đủ thường xuyên (ví dụ hàng tuần hoặc hàng tháng). Ngược lại, chủ sở hữu sản phẩm đồng ý xem xét liên tục các bản phát hành gia tăng và cung cấp phản hồi nhanh chóng. Họ cũng đồng ý đặt các ưu tiên cho lần lặp tiếp theo và một lần được đặt để không thay đổi suy nghĩ của họ trong suốt thời gian lặp lại.

Phần sau của thỏa thuận này là điều mà Thủ tướng của bạn có thể không hiểu. Nhiều PM truyền thống thực sự không. Một số người trong số họ nghĩ rằng công việc của họ được thực hiện khi họ bỏ thông số kỹ thuật; họ không muốn nghe về các vấn đề, giải pháp thay thế, cách tốt hơn, v.v ... Nhược điểm là điều này không chỉ chống lại dòng phát triển phần mềm mà còn gây tổn hại cho tổ chức bằng cách để lại nhiều cơ hội trên bàn.

Hãy xem Tuyên ngôn Agile: http://agilemanifesto.org/ Nó có thể cộng hưởng với bạn. Một cuốn sách hay để đọc cũng là "Phát triển phần mềm tinh gọn" của Mary Poppendieck

Chúc may mắn.

Âm thanh như người quản lý đang tìm kiếm ai đó để đổ lỗi khi anh ta báo cáo với cấp trên của mình.

Tôi thấy nếu bạn có một người quản lý không hợp lý, người nghĩ rằng 'ước tính' giống như 'thời gian cố định', điều tốt nhất nên làm là nghĩ về một khoảng thời gian ước tính rất hào phóng và sau đó nhân đôi nó!

Ngoài ra, buộc người quản lý phải đảm bảo các yêu cầu được chi tiết đầy đủ và cố định. Mọi thay đổi từ đó trở đi sẽ không được giải quyết nếu không có 'đàm phán lại chính thức' với người quản lý dự án về thời gian hoàn thành mới.

Cuối cùng, người quản lý dự án có được ý tưởng và kế hoạch phù hợp.

Kinh nghiệm cá nhân của tôi với loại điều này là người quản lý dự án đang cố gắng thiết lập một dấu vết giấy để xử lý bạn trong khi chấm dứt lỗi của bạn. Điều đó sẽ làm cho nó một lá cờ rất đỏ. Số dặm của bạn, tất nhiên, có thể thay đổi phần nào.

Câu trả lời tốt xung quanh, nhưng hãy để tôi thêm 2 xu của tôi.

Nếu bạn từng nghiên cứu xác suất, có một thứ gọi là "biến ngẫu nhiên". Đó là một số có giá trị mà bạn không biết, nhưng bạn có thể mô tả việc bạn không biết bằng phân phối, giống như phân phối (đường cong hình chuông) thông thường hoặc phân phối khác.

Vấn đề là, công việc sẽ mất một khoảng thời gian, nhưng bất kỳ ước tính trước nào cũng sẽ sai, dù ít hay nhiều, về mặt tiêu cực hoặc tích cực, do đó, có rủi ro và ai đó phải chấp nhận rủi ro. Nói chung, nếu mọi người chấp nhận rủi ro, họ được trả tiền cho nó. Bảo hiểm tốn tiền.

Khi tôi là một nhà tư vấn, tôi thường có lựa chọn ký hợp đồng thời gian và vật liệu so với hợp đồng giá cố định. Với thời gian và vật liệu khách hàng chịu rủi ro. Với giá cố định, tôi chịu rủi ro. Với giá cố định, tôi xây dựng theo biên độ an toàn, bởi vì nếu tôi không đạt được mục tiêu, không ai thắng.

Yêu cầu bạn cam kết ngày giao hàng cố định, đặc biệt là không có yêu cầu cố định, nghe có vẻ như đang cố gắng chuyển rủi ro cho bạn, mặc dù điều đó không rõ bạn đang thực sự gặp rủi ro gì. Trong mọi trường hợp, một phản ứng chỉ đơn giản là đưa vào một biên độ an toàn thực sự hào phóng.

Tái bút: Bạn thấy điều này mọi lúc với các hợp đồng của chính phủ. Có một yêu cầu ban đầu cho các đề xuất, giá thầu được thực hiện, giá thầu thấp được chấp nhận và sau đó các yêu cầu thay đổi bắt đầu xuất hiện, do đó, bong bóng chi phí và nhà thầu bị đổ lỗi. Mọi thứ hoạt động tốt hơn nhiều nếu có mối quan hệ làm việc nhóm giữa khách hàng và nhà thầu, thay vì mối quan hệ bất lợi.

Vâng, tất nhiên điều này làm tăng cờ về kinh nghiệm và năng lực của ông chủ cũ của bạn. Vâng, như hầu hết mọi người đề xuất, đây sẽ là thời điểm tốt để cập nhật CV của bạn.

Có, như các câu trả lời khác nêu, trong hầu hết các tình huống bạn sẽ không muốn ký thỏa thuận đó. Tuy nhiên, tôi muốn đề xuất rằng có thể có một số tình huống mà bạn có thể xem xét ký nó.

Hầu hết các nhà phát triển và quản lý đều nhận thức được sự ma sát liên tục giữa chức năng, thời hạn và ngân sách. Nhiều người cũng sẽ đề cử chất lượng là chiều thứ tư ("Tôi có thể cung cấp bất kỳ nhóm yêu cầu nào bạn muốn, vào ngày mai với ngân sách thấp, miễn là bạn sẵn sàng chấp nhận rằng nó sẽ không hoạt động!")

Nhưng vẫn còn một khía cạnh khác: rủi ro. Nếu tôi chỉ cần giao thành công 50% thời gian, tôi có thể hạ thấp ước tính của mình vô cùng; chúng được đệm để xử lý một tỷ lệ giao hàng cao hơn nhiều.

Chúng tôi có thể giải quyết rủi ro theo một số cách (và ước tính đệm là một trong số đó). Người quản lý không sẵn sàng chấp nhận bất kỳ rủi ro nào và muốn đặt rủi ro lên vai bạn. Thông thường, bạn nên từ chối một động thái như vậy ... trừ khi bạn đang được bồi thường tốt.

Nếu bạn có thể đề cử thời hạn của mình, với số lượng đệm được chấp nhận lẫn nhau để giải quyết các sự chậm trễ không mong muốn và có thể thương lượng phần thưởng (rất lớn) nếu bạn đạt được và có thể xử lý tài chính hình phạt (ví dụ như bị sa thải) nếu bạn không thể, bạn có thể thấy đó là một "canh bạc" đáng giá để chấp nhận rủi ro đó và ký hợp đồng - với các điều khoản phù hợp để xử lý các thay đổi yêu cầu.

Đây là sự ngu ngốc thẳng. Tôi không biết mục tiêu cuối cùng là gì, nhưng mỗi người quản lý dự án đàng hoàng chịu trách nhiệm về các sản phẩm phần mềm nên biết rằng các ước tính chính xác là những gì chúng được gọi là: ước tính. Chúng không phải là lời hứa và chúng không thể được thực hiện như vậy mà không làm cạn kiệt tất cả năng lượng của nhà phát triển hoặc buộc họ phải phá vỡ "lời hứa" của mình.

Nếu bạn muốn cho thấy một hợp đồng như vậy thật lố bịch, đây có thể là hai gợi ý:

a) Đánh giá quá cao đến mức mà dự án mất năm hoặc mười lần miễn là bạn ước tính mà không có hợp đồng. Nếu người quản lý dự án hỏi tại sao các ước tính rất cao chỉ cần nói rằng bạn chỉ cần đảm bảo rằng bạn có thể thực hiện hợp đồng của mình.

b) Điều này đã được đề xuất: Yêu cầu một hợp đồng đảm bảo rằng không một yêu cầu nào thay đổi và đảm bảo rằng điều này bao gồm sửa lỗi chính tả. Theo kinh nghiệm của tôi, không có một dự án phần mềm nào mà các yêu cầu không thay đổi tại một số điểm trong quá trình phát triển. Người quản lý dự án có nhiều khả năng phải phá vỡ hợp đồng của họ hơn bạn.

Nếu người quản lý dự án sẽ đồng ý với bất kỳ ai trong hai gợi ý này, bạn chắc chắn rằng họ sẽ mất trí.

Nhân tiện, làm thế nào một hợp đồng cho một nhân viên toàn thời gian sẽ làm việc như thế nào? Tôi không biết về các quy định làm việc ở các quốc gia khác, nhưng là một nhân viên toàn thời gian trong một công ty, tôi không nghĩ rằng bất cứ ai cũng có thể buộc bạn ký hợp đồng ràng buộc để đáp ứng thời hạn và có một trường hợp hợp lệ. Chắc chắn, họ có thể cho bạn địa ngục nếu bạn không đáp ứng thời hạn, nhưng họ không cần hợp đồng cho việc đó. Không ai có thể sa thải bạn hoặc cho bạn ít tiền hơn. Họ có thể cắt giảm tiền thưởng đồng ý của bạn ở mức tồi tệ nhất. Vì vậy, trừ khi điều này khác ở các quốc gia khác, điều này có vẻ giống như một mối đe dọa trống rỗng hơn bất cứ điều gì bạn nên nghiêm túc.

Tôi sẽ đi ngược lại hạt gạo ở đây.

Tình huống bạn mô tả không phải là bất thường ở cấp độ nhóm Kỹ thuật , đặc biệt là sau một dự án / phát hành đặc biệt muộn. Trong nhiều tình huống, quản lý của bạn và toàn bộ tổ chức của bạn trên thực tế có thể đã đăng ký một ngày phát hành cụ thể và các bộ phận khác của tổ chức sẽ được chuẩn bị cho ngày đó. Có thể có áp lực rất lớn đối với chuỗi quản lý của bạn để đạt được ngày đó.

Đây là nơi có một quy trình kỹ thuật chung. Bạn có thể đã nghe nói về mô hình thác nước. Có những mô hình khác, nhưng mục tiêu cuối cùng của tất cả chúng là liên tục cung cấp một cái gì đó khi nó được mong đợi và chứa những gì đã được đồng ý. Thông số chức năng, thiết kế, danh sách nhiệm vụ, v.v ... tất cả đều hướng tới việc biến điều này thành một quá trình có thể dự đoán được. Truyền thông, phân tích rủi ro và (như bạn đã nói) thường xuyên cập nhật những kỳ vọng về lịch trình làm giảm những bất ngờ và cung cấp thông tin càng sớm càng tốt để kế hoạch có thể được điều chỉnh. Và có, nên có sự điều chỉnh cho kế hoạch bất cứ khi nào các tính năng được thêm hoặc xóa.

Trong một số nhóm tôi đã làm việc cùng, tôi sẽ không ngần ngại coi ước tính của mình là các cam kết đã ký, nhưng điều đó phản ánh chất lượng của các đội và quản lý, và không có bất kỳ kỹ năng cụ thể nào khi ước tính. Một nhóm sẵn sàng ký hợp đồng giao hàng đúng hạn là một chỉ số của một nhóm làm việc tốt, không phải là cờ đỏ.

Tôi nói hãy đặt mình vào vị trí của anh ấy / cô ấy và cố gắng hiểu điều gì thúc đẩy điều đó. Từ những người quản lý / kế toán tiềm năng, họ cần một con số để chứng minh những gì đang xảy ra và mọi thứ đang diễn ra như thế nào.

Có thể là bị chế giễu trong phòng hội đồng vì thay đổi thời hạn, bỏ lỡ quá nhiều hạn chót, anh ấy đã thử cách đơn giản nhất có thể để họ bị khóa. Hãy cho tôi một số và ký vào đây! Bạn ở đầu bên kia, chỉ có thể cảm nhận rằng đó là thứ chống lại bạn. Làm thế nào để đưa ra ước tính và khi đi cùng nhận ra rằng chúng cần được điều chỉnh là những gì anh ta có ích hơn cho anh ta. Nếu bạn hiểu điều gì thúc đẩy yêu cầu và vấn đề thực sự anh ấy đang gặp phải là gì, bạn có thể giúp anh ấy và chính mình. Là lập trình viên, chúng tôi giải quyết vấn đề. Điều này không khác, hãy hiểu và giải quyết vấn đề của anh ấy và anh ấy sẽ là người bạn tốt nhất của bạn. Có quá nhiều việc phải làm mà không ai có thời gian để vạch ra một cuộc trả thù cá nhân! Anh ta cần giúp đỡ với công việc của mình, giải pháp đơn giản nhất là nhờ ai đó ký giấy! Có lẽ anh ta đã nhận được điều đó từ một quản lý cho cuốn sách giả, "Yêu cầu nhân viên của bạn ký và được giúp đỡ chịu trách nhiệm cho một số." Vui nhưng buồn

"Đi bộ trên nước và phát triển phần mềm từ một đặc điểm kỹ thuật là dễ dàng nếu cả hai đều bị đóng băng."

-Edward V. Berard

Nếu các yêu cầu của bạn đang thay đổi, thì thật không hợp lý khi hy vọng các ước tính ban đầu của bạn là chính xác. Vâng, đây phải là một lá cờ đỏ.

Có hợp đồng chỉ định một hình phạt cho việc không đáp ứng thời hạn? Nếu không, đó hoàn toàn không phải là vấn đề - bạn chỉ đang ký vào một ước tính dựa trên kiến ​​thức của bạn tại thời điểm đó.