Xử lý các ước tính khủng khiếp

Một dự án gần đây tôi làm việc đã được chứng minh là bị kiến ​​trúc sư đánh giá thấp. Ước tính đã được ra ít nhất 500%.

Thật không may, tôi đã được đưa vào dự án sau khi ước tính đã được ký kết với khách hàng. Là nhà phát triển cấp cao, tôi nhanh chóng nhận ra rằng thông số kỹ thuật và chức năng. chứa một số khoảng trống lớn và sự không chắc chắn.

Kết quả là tôi cảm thấy buộc phải gọi một cuộc họp khẩn cấp với các giám đốc kinh doanh và kỹ thuật để cho họ biết thực tế. Là người đầu tiên và quan trọng nhất là một nhà phát triển, tôi thấy đây là một tình huống rất căng thẳng và khó khăn. "Doanh nghiệp" cáo buộc IT không đủ năng lực và là người đưa tin tôi nhận được một vài "viên đạn".

Khách hàng đe dọa sẽ hủy tài khoản, tuy nhiên đến nay dự án vẫn còn dang dở và tôi không còn liên quan trực tiếp đến nó nữa.

Kiến trúc sư là một chàng trai tốt về mặt xã hội, nhưng dựa trên tập phim này đơn giản là không đủ năng lực hoặc có áp lực doanh số / doanh nghiệp lớn ảnh hưởng đến ước tính của anh ta.

Vì vậy, là lập trình viên, kinh nghiệm của bạn về loại tình huống này là gì và bạn sẽ tư vấn xử lý nó như thế nào?

Trả lời dài, nhưng này, tôi đã có một bản tóm tắt ở cuối, vì vậy hãy bỏ qua để tóm tắt nếu bạn không thể bận tâm đọc toàn bộ!

Là một nhà phát triển, tôi phải đối phó với tình huống theo đúng nghĩa đen của mọi dự án khác, nhưng phải đến khi tôi chuyển sang quản lý dự án, tôi mới học được cách đối phó với nó một cách hiệu quả. Đối với tôi giao dịch hiệu quả là về hai điều: quản lý kỳ vọng và hiểu cách ước tính hoạt động.

Bắt đầu với một tiền đề rằng việc đưa ra ước tính là không hợp lý, cam kết ước tính hoặc đưa ra bất kỳ dấu hiệu nào khác về độ chính xác của ước tính mà không thể thực hiện một số biện pháp thẩm định trước. Những người khác dựa vào khả năng chuyên môn của bạn để dự đoán một lượng công việc cần thiết, đưa ra một dấu hiệu sai sẽ làm tổn thương họ và doanh nghiệp của họ.

Nhưng bạn phải đưa ra một cái gì đó, trong cuộc sống thực, bạn đã kéo vào một cuộc họp ngẫu hứng hoặc một dự án muộn và cấp trên của bạn có thể sẽ nói rõ rằng họ mong đợi bạn đưa ra một số liệu ngay lập tức hoặc nhận xét về ước tính họ cung cấp. Đây là nơi quản lý kỳ vọng đi vào chơi.

Giải thích rằng bạn sẽ sai khi đưa ra bất kỳ con số hoặc bất kỳ dấu hiệu nào mà không hiểu vấn đề và tự mình tìm ra các con số. Nói rằng số liệu của họ có thể khá chính xác, bạn chỉ không biết trước khi tự mình thực hiện bài tập ước tính. Và mặc dù bạn có thể có một bức tranh tốt về những gì cần thiết ở đó và khi nào, hãy nói rằng bạn vẫn cần một chút thời gian để giải quyết các con số. Chỉ có một ước tính họ có thể mong đợi bạn đưa ra: khi nào bạn có thể cung cấp ước tính. Bằng mọi cách hãy cung cấp con số đó.

Là một nhà phát triển không bao giờ chịu trách nhiệm (hoặc đưa ra dấu hiệu có thể được hiểu là sự chấp nhận) ước tính của người khác mà không thể xem xét chúng trước. Là người quản lý dự án, đó là một vấn đề hoàn toàn khác, bởi vì sau đó bạn thực sự có một số quyền kiểm soát quá trình ước tính: cách ước tính được bắt nguồn và xem xét và bạn phải dựa vào người khác để hoàn thành công việc thực tế và bạn cần phải thực hiện chắc chắn họ đã cam kết.

Thậm chí không bao giờ bình luận về các ước tính mà không thể thực hiện thẩm định. Đây là đạo đức. Luật sư hoặc bác sĩ sẽ nói rõ rằng họ không thể đưa ra bất kỳ lời khuyên nào trừ khi khách hàng (hoặc bệnh nhân) chơi theo quy tắc của họ và trước tiên phải làm thủ tục đánh giá. Bạn cũng có quyền thỏa mãn câu hỏi của mình trước khi đưa ra ý kiến ​​chuyên môn.

Phần thứ hai là về cách ước tính hoạt động. Tôi đề nghị nghiên cứu các cách tiếp cận khác nhau để thực hiện ước tính và cách thức hoạt động của quá trình ước tính, bao gồm các ngành khác ngoài phát triển phần mềm (sản xuất, thị trường tài chính, xây dựng). Điều này sẽ cho bạn ý tưởng những gì mà sếp hoặc khách hàng của bạn có thể mong đợi một cách hợp lý và, thật kỳ lạ, sẽ giúp đưa ra những dự đoán chính xác hơn về khối lượng công việc. Nó sẽ cải thiện khả năng của bạn để bảo vệ các ước tính của bạn và bạn sẽ cần bảo vệ các số liệu mỗi khi chúng khác với các số liệu được cung cấp bởi một kiến ​​trúc sư hoặc một nhân viên bán hàng.

Thông thường, cách nó hoạt động, là ước tính của bạn trước tiên được quét cho các mục tìm kiếm kỳ lạ hoặc tương đối lớn. Do đó, hãy chuẩn bị để bảo vệ bất cứ điều gì với cái tên phi tiêu chuẩn. Đồng thời phân chia các nhiệm vụ lớn hơn để tất cả các nhiệm vụ có cùng độ lớn, nghĩa là nếu hầu hết các nhiệm vụ mất 2 ngày và một nhiệm vụ duy nhất là 10 ngày, hãy chuẩn bị để được khoan.

Hãy rõ ràng về những gì được bao gồm trong mỗi nhiệm vụ, tốt nhất là phân chia thử nghiệm dev và đơn vị thay vì chỉ có dev và có ai đó cho rằng nó cũng bao gồm tài liệu. Rõ ràng theo cách này, bạn sẽ cần phải tạo ra một ước tính hạt khá tốt.

Tiếp theo khoan đến. Vì rất khó để xem xét phân tích công việc lâu dài, khách hàng hoặc sếp của bạn có thể sẽ áp dụng một chiến lược khác: tập trung vào một bit ngẫu nhiên mà họ có thể biết và tìm hiểu sâu cho đến khi họ quản lý để làm mất toàn bộ ước tính hoặc sẽ hài lòng với bạn câu trả lời. Độ tin cậy của toàn bộ ước tính có thể phụ thuộc vào một mẫu ngẫu nhiên! Do đó, một lần nữa, bạn cần có thời gian để chuẩn bị một cách cẩn thận, chỉ bao gồm các bit có liên quan, loại trừ bất kỳ tính năng bổ sung nào hoặc chuyển chúng sang một phần tử đẹp mắt để che giấu phần và nghĩ về cách bạn sẽ bảo vệ các số liệu.

Rõ ràng bạn có thể nhất quán trong cách tiếp cận của mình, tức là ước tính dựa trên các tính năng, số lượng màn hình, v.v. hoặc có sự kết hợp các cách tiếp cận, nhưng trong mọi trường hợp, hãy chuẩn bị để bảo vệ lý do tại sao bạn chọn một cách ước tính nhất định. Hãy chuẩn bị để giải thích lý do tại sao số liệu của bạn khác với những người khác cố gắng dự đoán số lượng công việc cần thiết.

Tìm hiểu các dấu hiệu rõ ràng của ước tính yếu:

• Được thực hiện với các nhiệm vụ chung chung, được sao chép từ mẫu (ước tính tốt là cụ thể cho nhiệm vụ trong tay).

• Ước tính hạt thô (nghĩa là các nhiệm vụ dài hơn vài ngày).

• Ước tính được thực hiện ở giai đoạn đầu của một dự án hoặc bởi một người có thể không có kiến ​​thức thực tế về các yêu cầu hoặc công việc liên quan.

• Ước tính được biên soạn bởi những người khác hơn là người làm thực tế

• Ước tính mơ hồ (không rõ những gì được bao gồm và, không kém phần quan trọng, được loại trừ).

• Sự khác biệt đáng kể trong thứ tự của cường độ nhiệm vụ.

Thực hành đánh giá người khác ước tính và khoan các số liệu mà không có kiến ​​thức thực tế về chi tiết thực hiện. Điều này sẽ giúp sao lưu yêu cầu của bạn thêm một chút thời gian khi được yêu cầu xác nhận ước tính của người khác khi bạn không có bằng chứng cứng.

Để tóm tắt:

• Đừng cam kết với một ước tính khủng khiếp hoặc bất kỳ ước tính nào cho vấn đề đó, trước khi bạn có cơ hội để thực hiện thẩm định.

• Hãy nói rõ ngay từ đầu, đừng để ai cho rằng đó là bất kỳ cách nào khác và diễn giải sự im lặng của bạn như một dấu hiệu của sự đồng ý.

• Biết các phương pháp ước tính khác nhau hoạt động như thế nào, ứng dụng thực tế và giá trị của chúng, bao gồm cả những phương pháp phát triển phần mềm bên ngoài này.

• Hãy chuẩn bị để bảo vệ ước tính của bạn.

• Tìm hiểu cách đánh giá ước tính của người khác để bạn không phải cam kết với những con số không chính xác.

Không thể dự đoán tương lai. Yêu cầu dự đoán ("ước tính") chỉ đơn giản là yêu cầu sự cố. Mọi người đều làm điều đó, và mọi người đều hiểu sai.

Đánh giá của bạn về "hết 500%" có lẽ cũng sai như ước tính của kiến ​​trúc sư. Rốt cuộc, "... cho đến nay dự án vẫn còn dang dở ..." Không có sự thật nào có sẵn ở đây.

Không ai biết câu trả lời "đúng". Và cho đến khi nó được thực hiện, sẽ không ai biết.

Và ngay cả sau khi hoàn thành, ước tính "ban đầu" (có hoặc không có kiểm soát thay đổi) có thể không tương quan với bất kỳ điều gì đã thực sự đạt được.

Ước tính là một cái bẫy - đó là một trò chơi gian lận. bạn không thể thắng, bạn không thể hòa vốn và thậm chí bạn không thể thoát khỏi trò chơi.

Biên tập

Xử lý các ước tính xấu; Một ước tính "di sản" xuất hiện sai .

Nó đây rồi Bạn không đồng ý với ước tính của người khác. Hoặc họ đã bỏ qua một cái gì đó bạn nghĩ là cần thiết; họ có phạm vi công việc khác với bạn hoặc họ có tỷ lệ năng suất khác nhau. Ngoài ra, nếu ước tính không chỉ là nỗ lực, họ có cơ sở chi phí khác nhau. Tất cả đều có thể tranh cãi. Vì vậy, tranh chấp các chi tiết dẫn đến ước tính. Đừng tranh chấp về tổng số - không có thông tin thực sự trong một bản tóm tắt. Tranh chấp chi tiết cá nhân làm cơ sở cho ước tính. Tìm hiểu những gì họ đã suy nghĩ.

Có khả năng là các giả định của bạn cũng sai như các giả định của họ. Có khả năng như nhau.

Khi được hỏi để ước tính .

1. Bạn sẽ sai.

   1. Họ nói dối về phạm vi công việc.

   2. Bạn không biết năng suất của đội.

   3. Bất cứ điều gì công nghệ mới có liên quan đã được trình bày sai.

2. Bạn không thể ném vào đệm để che những thứ này một cách ngẫu nhiên. Bạn thực sự không biết và không có cơ sở để "ước tính". Chỉ là đoán thôi. Hãy vượt qua nó.

Quy tắc 1: Vì bạn chỉ đoán, hãy đoán theo từng bước nhỏ.

Câu hỏi cơ bản trong bất kỳ tình huống "ước tính" nào là không dự đoán tương lai. Bạn không thể làm điều đó với bất kỳ độ chính xác nào trong khoảng thời gian dài hơn một hoặc hai tuần. Giới hạn dự đoán của bạn trong một khoảng thời gian mà bạn có một số kiến ​​thức chi tiết trực tiếp và ngay lập tức. Ví dụ, phiên bản tiếp theo.

Câu hỏi cơ bản là - thông thường - ra quyết định từ phía người mua hoặc khách hàng của bạn. Câu hỏi không phải là "chi phí sẽ là bao nhiêu?" - đó là không đầy đủ. Câu hỏi là "đầu tư sẽ có giá trị?" Câu hỏi thực sự nằm nhiều hơn giữa "tỷ lệ chi phí / lợi ích" và "khi nào chúng ta nên ngừng chi tiêu vì đầu tư nhiều hơn sẽ không tạo ra nhiều lợi nhuận hơn?" Đó là những câu hỏi thực sự.

Quy tắc 2: Hỗ trợ người ra quyết định với thông tin thực tế.

Hầu hết mọi người được phục vụ tốt nhất theo cách tiếp cận Agile. Bản phát hành đầu tiên - một tháng kể từ bây giờ - sẽ mất 5 người × 4 tuần và nó sẽ mang lại tính năng X giúp khắc phục khoản lỗ $ 1 / ngày và tính năng Y khắc phục các cơ hội bị mất $ 200K / tuần. Bạn có kiến ​​thức chi tiết về những gì bạn đang làm, vì vậy dự đoán này có ý nghĩa. Việc phát hành sau đó là một chút mơ hồ.

Việc phát hành một năm kể từ bây giờ là trong tương lai mà mọi dự đoán chỉ trong một con số ngẫu nhiên. Đừng đổ mồ hôi chi tiết của bất cứ điều gì hơn 6 tháng trong tương lai, chỉ cần sử dụng các quy tắc đơn giản.

Khi họ hỏi TCO là gì, bạn phải trung thực. "Tổng chi phí xảy ra khi bạn ngừng trả tiền cho sự phát triển. Cho đến khi bạn ngừng trả tiền, bạn sẽ luôn phải chịu chi phí."

Câu hỏi thực sự là "bạn đang cố gắng khắc phục vấn đề gì?" hoặc "cơ hội mới nào bạn đang theo đuổi?" và "giá trị đó là gì?"

Quy tắc 3: Làm cho phần mềm ít tốn kém hơn so với vấn đề cần giải quyết.

Nếu bạn không biết rõ vấn đề, ước tính sẽ được đưa ra để phù hợp với nhận thức. Hãy cố gắng tránh điều này.

Về xác suất . Ngoại trừ bệnh suy nhược hoặc tai nạn, không có phần phát triển phần mềm nào bị chi phối bởi xác suất thực tế. "Rủi ro" đơn giản là quản lý tồi. Nói chung ở dạng "chúng tôi không tính đến sự phức tạp của nhu cầu kinh doanh A hoặc công nghệ B". Thông thường hơn về hình thức "khi chúng tôi tìm hiểu thêm về vấn đề hoặc công nghệ, chúng tôi đã thay đổi lịch trình" bị trừng phạt là "phạm vi leo".

Không có xác suất học tập và thay đổi phạm vi. Đó là một điều chắc chắn.

Về kế hoạch . Có "lập kế hoạch" và có "ước tính". Lập kế hoạch những gì cần xây dựng là một điều, được thể hiện tốt nhất dưới dạng danh sách kiểm tra hoặc biểu đồ phụ thuộc. "Ước tính" nỗ lực cần có được dựa trên các yếu tố không thể biết được.

"Lập kế hoạch" là quản lý tốt thông thường.

"Ước tính" đòi hỏi kiến ​​thức không thể biết. Để "ước tính nỗ lực" một cách chính xác, bạn phải có mức độ hiểu biết về mã nguồn đối với sản phẩm và bạn phải biết người nào sẽ nhập mã nguồn đó và những lỗi mà cá nhân đó sẽ mắc phải. Vì bạn không thể biết điều đó, mọi ước tính đều phải sai. Và thường sai điểm sai lầm và do đó vô dụng.

Nếu ước tính đã hết 500% và dự án vẫn tiếp tục, thì ước tính có giá trị gì?

Không ai. Tất cả những gì nó làm là khiến mọi người không vui. Nhưng dự án vẫn tiếp tục.

Vì không ai có thể nhìn thấy tương lai, nên việc ước tính đúng không có nghĩa gì cả. Làm cho nó hữu ích, giúp mọi người đưa ra quyết định.

Giữ chân trời ngắn. Cung cấp giá trị càng nhanh càng tốt. Tạo một kế hoạch cho phép khách hàng hủy dự án bất cứ lúc nào mà vẫn có giá trị.

Đừng để kế hoạch trở thành "sự thật thiêng liêng" duy nhất trong dự án. Các chức năng có thể cung cấp là thiêng liêng. Mọi thứ khác sẽ thay đổi khi việc giao hàng thay đổi.

Đừng để kế hoạch vượt quá giá trị mà nó tạo ra.

Nếu không có đủ thời gian thì không có đủ thời gian. Không có giải pháp kỳ diệu để hoàn thành dự án nào. Theo ý kiến ​​của tôi, bạn đã làm những gì bạn có thể nêu ra. Hóa ra họ phải tìm ra nó một cách khó khăn. Đó là cách nó thường đi. Hy vọng kiến ​​trúc sư và ban quản lý đã học được từ những sai lầm của họ và đừng làm điều đó một lần nữa. Nếu đây là công việc như thường lệ khi ban quản lý quá thờ ơ để lắng nghe lập luận của bạn và có hành động phù hợp thì có lẽ nên tìm kiếm các dự án khác hoặc công ty khác.

"Các nhà phát triển là thợ thủ công, và điều tồi tệ nhất bạn có thể làm với thợ thủ công là để anh ta đưa ra một sản phẩm tào lao." Câu nói nổi tiếng từ đâu đó nhưng tôi không thể nhớ lại từ đâu.

Sự trung thực cần luôn được tôn vinh. Tôi đã nhận được "tầm nhìn của kiến ​​trúc sư" và khi nhà phát triển đến với tôi với tin tức khủng khiếp rằng toàn bộ giải pháp sẽ không hoạt động, chúng tôi đã đến các đơn vị kinh doanh và có cuộc trò chuyện khủng khiếp. Sau đó, nhà phát triển đã đưa ra một ước tính mới, bao gồm 80% chức năng, nhưng anh ta đã giao đúng thời hạn và ngân sách.

Các đơn vị kinh doanh đã chiến thắng bởi thực tế là nhà phát triển đã nói thật với họ, thừa nhận các công ty của anh ta đến và làm việc như một con chó để giao hàng. Chúng tôi đã có anh chàng này làm việc cho chúng tôi trong 7 năm qua bởi vì anh ấy luôn trung thực.

Toàn bộ kịch bản rất hiếm - hầu hết các đơn vị kinh doanh nghĩ rằng bạn là một thằng ngốc vì không thể giao hàng. Bạn cần tìm kiếm những khách hàng không hoạt động theo cách này, vì bạn sẽ kiếm được nhiều tiền hơn với họ trong thời gian dài hơn là bạn sẽ cố gắng làm hài lòng những người sống chỉ muốn đối xử với bạn như một kẻ ngốc.

Đối với các kiến ​​trúc sư không biết lĩnh vực của họ, hãy tránh họ như bệnh dịch. Tôi đã có một người cố vấn đã từng củng cố với tôi một cách khắc nghiệt - "Cái này. Không phải. Để thực hành!" Anh ta sẽ chịu đựng những sai lầm chỉ khi bạn thực hiện chúng sớm, sửa chữa chúng và không bao giờ mắc lại chúng. Các công ty cho phép những người không có kỹ thuật, thiếu kinh nghiệm ở các vị trí với khách hàng vì họ có thể "giao tiếp" xứng đáng để ra khỏi doanh nghiệp.

Tôi đã từng phải đối mặt với tình huống này. Một dự án đã hết tiến độ này là do doanh nghiệp thay đổi yêu cầu và có khoảng cách giao tiếp và quản lý cấp cao muốn dự án đúng thời hạn. Để làm cho nó tồi tệ hơn, một anh chàng đang làm việc trong dự án này đã bị lôi ra để lấp vào một khoảng trống khác được ưu tiên hơn.

Nhóm của tôi đã dành nhiều đêm để hoàn thành dự án. Một đêm khuya vào khoảng 3:00 sáng (Tôi đã làm việc 19 giờ liên tục) Tôi đã gửi email cho các quản lý của mình để làm gì đó về nó.

Ngày hôm sau chúng tôi có một cuộc họp (Chỉ là những người phát triển). Toàn đội đã đến vào một ngày cuối tuần và thử nghiệm dự án ngay cả trước khi nó hoàn thành. Vài người khác tham gia nhóm trong việc sửa chữa nhanh chóng. Cuối cùng, chúng tôi đã có thể cung cấp dự án với nỗ lực của cả nhóm (Không chỉ nhóm dự án). Chúng tôi theo quy trình tương tự cho các dự án khác.

Toàn bộ nhóm (ngay cả khi họ không tham gia vào dự án) đã thử nghiệm ứng dụng và giúp khắc phục lỗi nhanh chóng.

Lưu ý: Nhóm của tôi gồm khoảng 25 người, một lần nữa có các nhóm phụ làm việc trong các dự án khác nhau.

Lời khuyên duy nhất của tôi sẽ là "Nói chuyện với người quản lý. Hãy nói với họ một cách chắc chắn rằng dự án không thể được giao đúng hạn. Ngoài ra, hãy cho họ một giải pháp thay thế.

Trong khi các doanh nghiệp thường không thích sự thật rằng mọi thứ mất nhiều thời gian hơn dự kiến, họ thích được kéo dài hơn thậm chí ít hơn. Bạn càng sớm cho ai đó biết sẽ thực sự mất bao lâu, mọi người càng nhanh chóng có thể lên kế hoạch cho các tình huống. Mặc dù điều này ban đầu có thể là một thời gian khó khăn, về lâu dài nó sẽ dễ dàng hơn. Chỉ cần làm cho đúng lần thứ hai và xây dựng trong tình huống dự phòng.

Hãy để tôi nhấn mạnh một điểm quan trọng khi làm việc với quản lý của bạn: các nhà quản lý đánh giá cao các giải pháp.

Nếu bạn phải đến gặp quản lý của mình với một vấn đề (ví dụ: ước tính là không thực tế), hãy làm việc chăm chỉ trước để bao gồm các lựa chọn thay thế cho cách giải quyết tình huống. Ví dụ: bạn có thể thực hiện phân tích Pareto (quy tắc 80/20) để hiểu giá trị của hệ thống, bạn có thể tạo trường hợp ưu tiên để cắt các tính năng (ít nhất là từ bản phát hành đầu tiên) để tập trung vào những người có giá trị kinh doanh tối đa, bạn có thể tìm kiếm các lựa chọn thay thế (dự án nguồn mở, v.v.) là sự thay thế đầy đủ cho các phần tùy chỉnh của hệ thống, v.v.

Không có câu hỏi rằng một túi năm pound sẽ không chứa hai mươi lăm pound cát, nhưng một phần giúp quản lý của bạn hấp thụ thông điệp khó chịu của bạn là đưa ra bằng chứng rằng bạn là đồng minh đã đính hôn.

Bạn có thể quan tâm đến bài viết này của IEEE mà tôi đã viết về trước đây. Dưới đây là những điểm nổi bật.

• Một trong những động lực lớn nhất dẫn đến thất bại của dự án là ước tính quá lạc quan.
• Một lý do lớn tại sao ước tính quá thấp là quá nhiều áp lực từ đầu để cung cấp sớm.
• Khác là creep scope trong khi thực hiện mà không truy cập lại các ước tính.

Đầu tiên tôi sẽ nói chuyện với kiến ​​trúc sư trong câu hỏi, một cách không chính thức, và xem qua danh sách các vấn đề của bạn với ước tính của anh ấy, và cố gắng thuyết phục anh ấy xem vấn đề ở đâu, và sự khác biệt về thời gian họ sẽ giải quyết.

Sau đó, tôi sẽ thử và đi đến quản lý dự án / quản lý dự án của bạn và thảo luận với anh ấy / họ.

Vào cuối ngày, kiến ​​trúc sư đã đưa ra ESTIMATE, vì vậy họ có thể thay đổi, và đôi khi với số lượng lớn, miễn là họ biết về nó, vì vậy họ có thể thực hiện các kế hoạch thay thế, như đưa một sản phẩm ra các giai đoạn, làm giảm chức năng của nó hoặc các phương tiện khác.

Vào cuối ngày, một khi bạn đã thực hiện những điều trên, đó không còn là trách nhiệm của bạn nữa.

Bạn chắc chắn không nên trực tiếp đến khách hàng, hoặc ông chủ của kiến ​​trúc sư, điều này chỉ thúc đẩy cảm giác tồi tệ, và hầu như bạn sẽ luôn nhận được một số lỗi.

Điều tốt nhất bạn có thể làm là học hỏi từ các ước tính xấu của bạn (không phải cá nhân bạn, trong trường hợp này). Một điều cần học là không bao giờ để người khác ngoài người thực hiện ý tưởng ước tính sẽ mất bao lâu. Tốc độ của các lập trình viên có thể thay đổi theo một mức độ lớn, do đó, việc ước tính cho người khác là không thể.

Tôi cảm thấy nỗi đau của bạn ... Tôi không chắc làm thế nào để xử lý tất cả sự thất vọng này :(

https://stackoverflow.com/questions/541873/developing-on-for-a-moving-target

Trước đây tôi đã phải đối phó với những người quản lý dự án, những người đã cắt giảm các ước tính để đáp ứng một con số mà bộ phận bán hàng nghĩ rằng khách hàng sẽ trả. Người quản lý cho rằng thà xin tha thứ còn hơn xin phép.

Đây là lý do tại sao các nhà phát triển đã học cách đệm các ước tính của họ, bởi vì họ biết rằng họ sẽ bị cắt bởi các nhà quản lý của họ. Vì vậy, nếu bạn tăng gấp đôi ước tính và thêm 30%, bạn có cơ hội nhận được một lịch trình hợp lý.

Khách hàng luôn muốn nó rẻ hơn, và nếu bạn đến với họ với một ước tính hợp lý, họ sẽ chùn bước và yêu cầu bạn cắt giảm chi phí hoặc họ đi bộ. Nhưng, nếu bạn đi quá cao, họ sẽ chỉ cần đi bộ mà không cần thảo luận ("Chúng tôi sẽ xem xét và lấy lại cho bạn").

Đó là một trò chơi của những kỳ vọng được quản lý.

Vấn đề không phải là các ước tính ban đầu đã được đưa ra - đó là do ban quản lý không tin bạn.

Cách tốt nhất để quản lý đưa ra quyết định là:

1. Phác thảo vấn đề với bằng chứng để sao lưu nó; và
2. Cung cấp nhiều giải pháp để họ lựa chọn (theo thứ tự từ ít thích hợp nhất đến thích hợp nhất).

Đối với (1) triển khai Scrum và theo dõi thực tế đối với các ước tính tinh ranh hoạt động tốt để sao lưu các khiếu nại của bạn.

Đối với (2) một trong các tùy chọn của tôi sẽ là "Phát triển danh sách tính năng ưu tiên với ứng dụng khách (còn gọi là Product Backlog theo thuật ngữ Scrum)". Điều này sẽ là khó khăn trong các tổ chức giá cố định hoặc quan liêu cao, nhưng nó có thể .

Mong rằng sẽ giúp!

Tôi (như tôi chắc chắn về tất cả những người viết mã) đồng cảm. Công ty cuối cùng của tôi khá khủng khiếp về điều này - những người bán hàng sẽ tham gia và bán một dự án, sau đó bạn vào, xem các ước tính, và chỉ cười.

Như Tomh đã đề cập - chỉ có rất nhiều thời gian trong một ngày. Ngay cả khi bạn không ngủ.

Ba điều, tôi nghĩ.

Hầu hết thời gian bạn chỉ cần quản lý kỳ vọng của khách hàng và minh bạch . Hãy thẳng thắn với những gì bạn có thể làm và thể hiện những gì bạn đã làm - tất cả những điều đó. Điều này đặc biệt đúng nếu bạn đưa ra các yêu cầu quá phức tạp (như Totophil đã đề cập.) Nếu họ có thể thấy khối lượng công việc bạn phải làm, họ có thể thấy ước tính tồi tệ như thế nào. Nếu họ thấy năng suất và tiến bộ thì điều đó quan trọng hơn bất cứ điều gì trong kinh nghiệm của tôi.

Tôi nghĩ bên cạnh việc quản lý kỳ vọng và minh bạch trong khối lượng công việc của bạn, điều quan trọng khác là quản lý phạm vi . Có một khu vực rộng lớn giữa việc làm hậu môn / tấn công trong việc trở thành một phạm vi nazi và che phần đuôi của chính bạn. Khi ai đó muốn tính năng hoặc chức năng bổ sung này - hãy đồng ý với nó! Và sau đó cung cấp cho họ một ước tính tương đối chính xác về thời gian sẽ thêm vào dự án (hoặc bản phát hành tiếp theo.) Mặt trái của điều này không chỉ là tự nhồi nhét mình vào một tuần 80 giờ nữa - bạn còn nhận được một số phần trong ước tính đó đuổi kịp người kia.

Chúc may mắn!

Không bao giờ nhận bất cứ điều gì mà không nhìn thấy hoặc hiểu nó. Nếu khách hàng hoặc mgmt của bạn không sẵn sàng trả cho bạn nhiều như vậy, họ sẽ không thiết lập cho bạn thành công.

Đây là (và thường là) không thể hiểu chi tiết, dữ liệu và cách chúng tương tác trong suốt ứng dụng được xây dựng. Giả định được đưa ra thay vì đặt câu hỏi, tìm câu trả lời và đóng đinh tất cả.

Một điều tôi thường nói với khách hàng của mình là, nếu bạn định treo cổ tôi, ít nhất hãy để tôi tự treo bằng dây thừng của mình, hoặc bắn tôi bằng súng và đạn của chính tôi chứ không phải ai đó.

Có một cánh cửa quay vòng của những người đang cố gắng giải quyết nó sẽ trở nên tồi tệ hơn nhiều cho họ.

Không thực tế, lập kế hoạch kém và thiếu tầm nhìn xa có thể là tín hiệu của một vấn đề toàn tổ chức trong trường hợp bạn tốt hơn nên làm quen với nó, hoặc tiếp tục.

Trước tiên, hãy xem xét khả năng mà bạn đánh giá quá cao phạm vi của dự án. Nhân viên bán hàng và kiến ​​trúc sư có xu hướng phóng đại các giải pháp của họ. Đừng lấy chúng theo mệnh giá; họ có thể mong đợi bạn đến với ít hơn sau đó họ hứa với khách hàng.

Những gì tôi sẽ làm ở đây là dành thời gian tôi có, và dành nó một cách khôn ngoan nhất có thể. Tìm ra các ưu tiên của khách hàng và cung cấp trên đó. Chín trên mười lần, khách hàng sẽ rất vui vì những ưu tiên hàng đầu của anh ta đã được đáp ứng và bỏ qua 80% công việc chưa được thực hiện.

Điều cuối cùng bạn muốn làm là đi gọi các cuộc họp khẩn cấp và buộc tội mọi người là xấu xa. Bạn nói:

"cho họ biết thực tế"

nhưng thực tế chỉ là một ý kiến! Thư giãn, làm công việc của bạn và dành vốn chính trị của bạn cho những thứ quan trọng với bạn . Thích, khuyến mãi, nhiều tiền, nhiều ngày lễ.

Sếp của bạn giao dịch một chương trình khuyến mãi cho bạn làm việc thực sự chăm chỉ về khách hàng có ý nghĩa. Bạn sẽ haywire thay mặt cho một khách hàng không.

Một điều cần nhớ là các ước tính không bao gồm creep phạm vi hoặc sự chậm trễ không thể tránh khỏi (hoặc các vấn đề dựa trên máy khách không cung cấp cho bạn khi họ nói rằng họ sẽ như một tệp thông tin ở định dạng cụ thể).

Chúng tôi đã học cách đẩy lùi cả ước tính và / hoặc ngày đáo hạn mỗi khi một trong những điều này xảy ra. Thêm một tính năng mới, có được ước tính mới và ngày đáo hạn mới. Không cung cấp thông tin cần thiết vào ngày đã đồng ý, có được một ngày đáo hạn mới. Đưa ra thông tin nhưng làm cho nó không đầy đủ hoặc không chính xác hoặc trong bất kỳ trường hợp nào khác với những gì đã hứa, gửi một ước tính mới và ngày đáo hạn, thay đổi các yêu cầu của các tính năng đã thỏa thuận, có được ước tính mới và ngày đáo hạn. Ngừng làm việc với dự án vì khách hàng muốn bạn làm việc với mức độ ưu tiên cao hơn, gửi ngày đáo hạn mới (và có thể ước tính mới vì sẽ có thời gian bắt kịp nếu dự án bị hoãn lâu).

Nếu ước tính ban đầu đến từ bên ngoài nhóm phát triển và họ không tham gia vào nó, thì khi bạn nhận được nó, hãy chuẩn bị một ước tính của riêng bạn (ở mức chi tiết của tất cả các nhiệm vụ bạn nghĩ rằng nó sẽ có - ở mức cao hơn nhiều chi tiết hơn so với ước tính bạn đã đưa ra) và ngay lập tức cung cấp cho chuỗi đó và hỏi bạn nên cắt bỏ những gì để đáp ứng ước tính bạn đã đưa ra.

Nếu câu trả lời là không có gì, hãy nhấn mạnh khách hàng được thông báo về ước tính mới, bây giờ chúng tôi đã xem xét vấn đề sâu hơn. Nếu quản lý vẫn khăng khăng khách hàng sẽ chỉ trả tiền trong X giờ, hãy hỏi họ ai sẽ trả cho phần còn lại của giờ phát triển vì công việc như được mô tả cho bạn không thể được thực hiện dưới mức ước tính của bạn. Nó có thể hóa ra công ty sẵn sàng nhận cú đánh và tự trả tiền cho giờ.

Nếu họ không sẵn sàng lấy nó ra khỏi lợi nhuận của họ và họ sẽ không nói với khách hàng rằng họ cần thêm giờ và công ty sẽ không trả lại các ước tính chi tiết của nhân viên phát triển về doanh số '"chúng tôi nghĩ khách hàng sẽ làm gì để giành chiến thắng trong dự án ", bạn đang tham gia một dự án diễu hành tử thần và đặt cược tốt nhất của bạn là thoát ra càng sớm càng tốt. Bạn có thể chỉ ra rằng khách hàng sẽ vui hơn khi biết dự án sẽ mất nhiều thời gian sớm nhất có thể khi bạn dành 50 giờ họ đồng ý trả tiền và thậm chí không hoàn thành gần 500 bạn thực sự cần. Nhắc nhở họ rằng các ước tính quá lạc quan là một trong những yếu tố dự báo lớn nhất về thất bại của dự án. Nó sẽ không hoạt động với các loại công ty này, nhưng có lẽ cuối cùng nó sẽ chìm vào nếu bạn lặp lại đủ lần.

Tôi cũng sẽ đưa vào tài khoản ước tính sàng lọc. Tôi có nghĩa là "như tôi thấy bây giờ dự án này sẽ mất X man-hours". Sau 20-30% tôi sẽ ước tính lại và cứ thế.

Rốt cuộc làm thế nào để một trình tải xuống tập tin thực hiện ước tính của nó? Nó liên tục tinh chỉnh nó.

Tôi nghĩ rằng không đủ người ước tính không nhấn mạnh đủ vào các sự kiện của "Ước tính là bạn yêu cầu tôi làm toán và đoán để dự đoán tương lai theo cách hữu ích" và "Cam kết chúng ta thực hiện hoàn toàn tách biệt với toán học mà chúng ta làm ước tính; Chúng ta có thể đồng ý thực hiện khối lượng công việc ngu ngốc, đồng ý với những điều chúng ta thấy chúng ta có thể không hoàn thành, nhưng không ai trong số chúng thực sự thay đổi toán học của giải pháp "và" Chúng ta có thể thực hiện các phương pháp phát triển không phải là khổng lồ lô tính năng A sẽ được thực hiện trước ngày B khiến khả năng thất bại ít có khả năng hơn "

Để nhiều ước tính được văng trong ngôn ngữ đàm phán. Họ cần phải được thư giãn trong ngôn ngữ toán học và nói về những điều không chắc chắn của toán học .

Người ước tính không thể làm gì để khiến cho thực tế bị bẻ cong theo ý muốn của các doanh nhân khi đàm phán với anh ta. Công việc duy nhất của anh là khiến họ ngừng cố gắng.