it-swarm-vi.com

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 dẫn đầu dự án của tôi nói rằng PM đ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 đã 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 tăng lên 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 đó, rằng PM muốn số của anh ta 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 hợp đồng đã ký, PM 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? Có phải thông thường người quản lý sẽ khóa các ước tính thời gian của nhà phát triển phần mềm có hợp đồng đã ký không? Hoặc trong trường hợp này, cố gắng.

Xin lưu ý, tôi là nhân viên chính thức, không phải là 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ư bản gốc và ngày giao hàng là gì PM đã được sửa.

116
spong

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?

. Đ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ị với bạn.

Có phải thông thường người quản lý sẽ khóa các ước tính thời gian của nhà phát triển phần mềm có 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 cái 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 ."

109
Tangurena

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.

160
whatsisname

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 :)

59
Slawek

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 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.

31
Pemdas

Đâ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 liên tục được đưa ra, đ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!

27
Steven A. Lowe

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ỳ 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ới Đẹ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. Hãy xem Steve McConnell's Ước tính phần mềm và Stephen Withall Các mẫu yêu cầu phần mềm để 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.

19
Michael Brown

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?

14
ThomasW

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 lưu ý rằng PM 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 mang đến cho họ sự đau buồn. Họ (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 ' Điều đó 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 & chơi với bạn phải không?). Nếu PM 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 mà họ rất xứng đáng. Điều đó PM 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 điều xấu xấu n ... cách duy nhất tôi có thể thấy rằng 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 đượ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 được mối đe dọa này). 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. Thật tốt khi những người khác đi theo bạn từ những gì bạn nói, vì vậy lời khuyên dưới đây sẽ có lẽ đã bật ra 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ả, vì điều đó 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 giờ 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 cuộc họp đã gặp 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ọ bị câm và bạn đã thắng. Chính điều đó sẽ kéo họ trở lại 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 điều đúng, và cũng làm điều đúng bởi bạn. 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.

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 sẽ là một loại thiết lập lại xảy ra trong dự án và có thể đó PM sẽ lặng lẽ được gán lại cho một khu vực khác. được đưa ra trong cuộc họp của Thủ tướng, sau đó đáp ứng các 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 họ với bạn, và cho toàn bộ đội ngũ phát triển, khi họ bắt đầu chơi những kiểu tâm trí đó Trò chơi.

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, 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. Nếu bạn không thể đối phó với điều đó, bạn đang chơi sai.

10
nomaderWhat

Có, điều này sẽ giương 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ý 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.

8
Larry Coleman

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ư PM 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ề phần mềm Agile và Lean nói về, 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ó dẫn đế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 mắt. 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 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 bạn PM hoặc khách hàng hoặc nhóm QA) và nhà phát triển. Nhà phát triển đồng ý chỉ làm việc trên những thứ được ưu tiên quan trọng nhất đối với 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 được tích hợp đầy đủ thường xuyên (ví dụ: hàng tuần hoặc hàng tháng). Chủ sở hữu sản phẩm, ngược lại, đồ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 Nhắc. cũng đồng ý đặt mức độ ưu tiên cho lần lặp tiếp theo và một lần được đặt thành 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à PM có thể không hiểu. Nhiều người PM truyền thống thực sự không biết. 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ố; 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.

4
Wolfram Arnold

Â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.

4
martinws

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.

2
PSU

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ố mà giá trị 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.

P.S. 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.

1
Mike Dunlavey

"Đ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ờ đỏ.

0
Bill the Lizard

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ỳ 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ể chỉ định thời hạn, 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.

0
Oddthinking

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

0
Arjang

Đâ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 đề xuất 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 một 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.

0
Anne Schuessler

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 độ Kỹ thuật nhóm, đặc biệt là sau một dự án/phát hành đặc biệt muộn. Trong nhiều trường hợp, trên thực tế, quản lý của bạn và toàn bộ tổ chức của bạn có thể đã đã đăng ký cho 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 điều hướng cho đến 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 mà một quy trình kỹ thuật chung xuất hiện. Có lẽ bạn đã 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à cung cấp một thứ 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. A 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à một cờ đỏ.

0
TREE