Làm gì khi ước tính thời gian sai?


26

Giả sử bạn ước tính thời gian cho một trường hợp là 3 ngày. Vào ngày thứ hai, bạn nhận thấy rằng vụ việc đang gia tăng và các kịch bản mới đang xuất hiện mà không được tính khi ước tính thời gian thực hiện. Phát hiện mới dẫn đến thêm 2 ngày (tổng cộng 5 ngày). Đây là một vấn đề điển hình mà bạn sẽ phải đối mặt sớm hay muộn với tư cách là nhà phát triển.

  • Chiến lược nào có thể được sử dụng khi bạn định thông báo cho lãnh đạo dự án về thời gian giao hàng mới?
  • Bạn thường nhận được câu hỏi tại sao? Làm thế nào để bạn thúc đẩy thời gian giao hàng mới?

Thực tế là nhiều dự án không dành nhiều thời gian cho phân tích & thiết kế trong SDLC.

EDIT: Trong các dự án rất phức tạp, bất kể bạn dành bao nhiêu thời gian hợp lý cho Phân tích & Thiết kế, luôn có những bất ngờ vì các quy tắc kinh doanh quá phức tạp. Tuy nhiên trong những trường hợp như vậy tôi tin rằng người lãnh đạo dự án phải nhận thức được sự phức tạp và có thái độ đúng đắn khi những bất ngờ bất ngờ xuất hiện. Câu hỏi là làm thế nào để giải quyết các nhà lãnh đạo dự án, những người không hiểu sự phức tạp.


1
Tôi nghĩ rằng câu hỏi tốt hơn là, bạn sẽ làm gì khi ước tính là chính xác ? Hầu hết thời gian, nó sẽ không được.
Tim Post

@Tim Post Bạn nói đúng về "Hầu hết thời gian, nó sẽ không" Tôi muốn được bảo lưu.
Amir Rezaei

1
+1 - Cảm ơn EDIT có chứa những lời khôn ngoan. Thực tế bạn đã nhấn mạnh ("" Trong các dự án rất phức tạp cho dù bạn dành bao nhiêu thời gian hợp lý cho Phân tích & Thiết kế, vẫn luôn có những bất ngờ vì quy tắc kinh doanh quá phức tạp.) "" Rất đúng.
Karthik Sreenivasan

Câu trả lời:


17

Truyền tin xấu

Bạn hoàn toàn cần phải nêu vấn đề kịp thời, tuy nhiên nếu bạn có thể làm như vậy trong một khoảng thời gian hợp lý (đó là một vài giờ, không nhiều hơn), bạn nên làm một chút đánh giá tác động trước khi bạn làm.

Như với tất cả các tin tức xấu, tốt nhất là cung cấp thông tin chi tiết (thay vì chỉ thốt ra "nó sẽ bị trễ"), vì vậy hãy cung cấp càng nhiều / nhiều:

1) Sửa đổi ước tính / thời gian cho các nhiệm vụ đã trượt.

2) Ước tính / thời gian sửa đổi cho các nhiệm vụ trong tương lai mà bây giờ bạn nghĩ, khi biết rằng một số thứ đã chạy quá mức, có thể mất nhiều thời gian hơn.

3) Những lý do rất ngắn gọn tại sao sự trượt xảy ra (không quay, chỉ là sự thật, nhưng không có vẻ như bạn đang kiếm cớ). Trong trường hợp này, bạn nêu "Chúng tôi ước tính dựa trên quy tắc X và Y nhưng giờ đây chúng đã bao gồm Z không bao giờ được đề cập". Anh ta có thể sử dụng điều này trong việc giải thích sự chậm trễ cho khách hàng và giáo dục họ về tầm quan trọng của việc kỹ lưỡng ngay từ đầu.

4) Nếu có thể thay thế để đưa mọi thứ trở lại đúng hướng (thường giảm phạm vi nhưng có thể có các tùy chọn khác - các phần khác của dự án có thể đi trước thời hạn và có thể di chuyển các nhiệm vụ xung quanh).

Hãy nhớ rằng với sự trượt dốc, tác động tâm lý / tín nhiệm là có tính chất cấu thành. Bạn có thể có thể thoát khỏi với một nhưng thứ hai sẽ khó khăn hơn rất nhiều và thứ ba vẫn còn khó khăn hơn.

Đó là lý do tại sao điểm 2 rất quan trọng - xem xét lại không chỉ những gì đã bị trượt mà cả những nhiệm vụ trong tương lai mà bạn nghĩ bây giờ có thể mất nhiều thời gian hơn dự đoán ban đầu. Trượt xảy ra trong CNTT, không học hỏi từ những sai lầm của bạn là một tội lỗi lớn hơn.

Ngăn chặn việc truyền tải tin xấu

Có hai kịch bản ở đây: đầu tiên, bạn không tự mình thực hiện các ước tính trong trường hợp đó bạn không thể làm gì khác ngoài việc thúc đẩy tham gia vào các ước tính vào lần tới.

Thứ hai, bạn đã tự mình thực hiện các ước tính trong trường hợp bạn cần xem xét làm thế nào để ước tính tốt hơn. Đối với tôi cụm từ chính trong câu hỏi là "luôn có những điều bất ngờ vì quy tắc kinh doanh quá phức tạp" .

Với sự tôn trọng, nếu nó luôn xảy ra, nó không phải là một bất ngờ . Nếu bạn chỉ nhận được một nửa các quy tắc kinh doanh thì bạn cần phải thừa nhận rằng trong ước tính của mình và cho phép tính năng leo.

Bạn có thể làm điều này bằng cách tăng các ước tính cho các quy tắc bạn có (nó hoạt động nhưng bạn không giáo dục bất cứ ai về những gì đang thực sự xảy ra), nhưng tốt hơn là nêu các ước tính của bạn "Về mặt lịch sử, các quy tắc chúng tôi nhận được là một phiên bản đơn giản về những gì họ thực sự muốn. Các quy tắc họ đã nêu sẽ mất 3 ngày để thực hiện, tuy nhiên chúng tôi nên cho phép thêm 3 ngày nữa cho các quy tắc chưa được đề cập nhưng có khả năng được phát hiện trong quá trình phát triển và thử nghiệm. "

Nếu Thủ tướng đặt câu hỏi này thì bạn cần phải nhắc nhở anh ấy về tất cả các lần điều đó là sự thật (với các ví dụ - thật khó để tranh luận về các ví dụ) và cũng nhẹ nhàng đề nghị rằng anh ấy quan tâm đến việc giao hàng đúng giờ cũng như của bạn. Tốt hơn để được bảo thủ?

Nhưng điểm mấu chốt: nếu bạn luôn đánh giá thấp vì một yếu tố cụ thể (trong trường hợp này là tính năng creep) thì hãy tính điều đó vào ước tính của bạn.


2
+1 "Như với tất cả các tin tức xấu, tốt nhất là cung cấp thông tin chi tiết" Tuy nhiên mọi người đều không hiểu chi tiết / độ phức tạp của vấn đề.
Amir Rezaei

@Amir - Tôi đã thêm một chút nữa, mặc dù là người hiểu sự phức tạp, sự thật đơn giản là trách nhiệm của bạn là phải giải thích nó. Họ sẽ không học cách nào khác.
Jon Hopkins

Điểm tốt! "với các ví dụ - thật khó để tranh luận về các ví dụ" & "nhẹ nhàng đề nghị rằng việc anh ấy quan tâm đến việc giao hàng đúng hạn". Về "nếu nó luôn xảy ra, nó không phải là một bất ngờ", vấn đề là thời gian thêm cho sự bất ngờ không phải là hằng số. Vì vậy, bạn thậm chí có thể không lấy trung bình trên chúng, vì chúng có xu hướng có sự thay đổi lớn.
Amir Rezaei

+1 "Hãy nhớ với sự trượt dốc, tác động tâm lý / tín nhiệm được tích lũy."
Karthik Sreenivasan

16

Ước tính dựa trên thời gian là dự đoán về tương lai và điều đó sẽ luôn thất bại trong thời gian dài. Đó là một trận chiến vô nghĩa mà bạn không thể chiến thắng.

Ngừng ước tính trong ngày và bắt đầu sử dụng ước tính tương đối thay thế. Đây là một ví dụ đơn giản:

  1. Gán một số cho mỗi nhiệm vụ. Nhiệm vụ khó khăn nhất có thể là 10 và nhiệm vụ dễ nhất 1.
  2. Bắt đầu lập trình để hoàn thành nhiệm vụ của bạn.
  3. Sau một tuần, dừng công việc của bạn và tổng hợp tất cả các số nhiệm vụ đã hoàn thành. Hãy nói rằng bạn kết thúc với 14. Đó là vận tốc hàng tuần của bạn.

Tuần tới, lặp lại quá trình một lần nữa. Tôi cá là vận tốc của bạn sẽ thay đổi, nhưng không nhiều. Sau một vài tuần với điều này, vận tốc của bạn sẽ khá ổn định và đó là những gì chúng tôi đang hướng tới. Bây giờ bạn có thể bắt đầu thực hiện kế hoạch với sự tự tin. Chọn các nhiệm vụ tổng hợp với vận tốc của bạn và PM của bạn có thể khá chắc chắn nó sẽ được hoàn thành như đã hứa. Đó là cách bạn nên giải quyết các nhà lãnh đạo dự án của bạn.


Bạn có thể đưa ra một ví dụ về cách bạn theo dõi kích thước của các nhiệm vụ? Bạn có tạo một bảng với các loại tác vụ (như "tạo biểu mẫu mới", "thêm phương thức vào webservice X") hay đó là một cảm giác tốt hơn?
co rúm

Chỉ cần so sánh với các nhiệm vụ bạn đã ước tính và hoàn thành trước đó.
Martin Wickman

+1 - "Ước tính dựa trên thời gian là dự đoán về tương lai và điều đó sẽ luôn thất bại trong thời gian dài. Đó là một trận chiến vô nghĩa mà bạn không thể chiến thắng." Đây là lần đầu tiên tôi học về ước tính tương đối và nó chắc chắn là một thực phẩm để suy nghĩ. Cảm ơn.
Karthik Sreenivasan

Thật là một ý tưởng tuyệt vời! Tôi chắc chắn sẽ khám phá điều này hơn nữa.
đáp ứng

3

Ngay khi bạn thấy ước tính bị sai, bạn cần phải gióng lên hồi chuông cảnh báo. Thông báo cho những người mong đợi việc giao hàng về sự chậm trễ.

Yêu cầu sự giúp đỡ từ các đồng đội nếu có thể. Hãy chắc chắn rằng bạn vẫn cung cấp phần mềm chất lượng cao nhất có thể.

Cắt ngắn rất có thể sẽ gây hại nhiều hơn vào cuối cùng, và mọi người liên quan nên biết điều này. Hoặc ít nhất nên có thể giải thích nó cho họ.


3

Điều này xảy ra thường xuyên đến nỗi không có người quản lý dự án có kinh nghiệm sẽ kiếm được nhiều tiền. Chỉ cần trung thực về nó và đừng đưa ra những ước tính mới quá lạc quan; Khi bạn thấy nó sẽ mất nhiều thời gian hơn, hãy nói nó. Đừng nói "Tôi cần thêm một chút thời gian" hàng ngày.

Bạn sẽ phải giải thích cho người quản lý: ước tính sai ngay từ đầu hoặc là trường hợp bất lợi (dành một ngày để săn một lỗi) lý do cho sự chậm trễ? Trong trường hợp đầu tiên, có gì đó không đúng với quy trình ước tính, có thể nó quá lạc quan hoặc ngây thơ. Trong trường hợp thứ hai, đó là trường hợp cho bộ đệm được hy vọng có trong kế hoạch dự án.


2

Luôn luôn giữ cho các bên liên quan biết về tiến trình của bạn, bao gồm (đặc biệt là!) Thực tế là các ước tính của bạn quá lạc quan. Họ sẽ không vui, nhưng họ sẽ biết dự án thực sự đứng ở đâu và có thể lên kế hoạch phù hợp.

Lý tưởng nhất là danh sách các tính năng của bạn sẽ được MoSCoWed - Phải, Nên, Có thể, Không.

Khi bạn đang hướng tới vượt mức, hãy cắt lon, sau đó là Cần. Cắt các tính năng để bạn có thể giao hàng đúng hạn: dự án của bạn thường không tồn tại một cách cô lập và bạn sẽ đi vào ngày phát hành quá khứ có nghĩa là các dự án hạ nguồn giờ cũng sẽ vượt quá lịch trình của họ.

Lý tưởng nhất là bạn chỉ có ~ 60% Musts. Nếu bạn phải cắt giảm những người bạn đang gặp rắc rối rất sâu (gặp sự cố quá nghiêm trọng), trong trường hợp đó bạn sẽ phải cắt góc.

Hãy chắc chắn rằng bạn dành cho mình đủ thời gian sau khi phát hành để dọn dẹp mớ hỗn độn bằng cách cắt góc!


4
+1 @Frank Điểm hay về "Cắt các tính năng để bạn có thể giao hàng đúng hẹn". Vấn đề ở đây là tôi không phải là người lãnh đạo dự án.
Amir Rezaei

@Amir Trong trường hợp khách hàng của bạn là (loại) người lãnh đạo dự án của bạn. Bạn nói "Tôi đứng sau. Tôi có thể cắt tính năng này hoặc tính năng đó. Tôi phải làm gì?"
Frank Shearar

@Frank Vì chúng tôi làm Scrum, và vụ việc được chuyển từ tồn đọng vào giai đoạn nước rút, dường như nó được viết bằng đá để PM giảm bớt các vụ kiện. Tuy nhiên một PM kinh nghiệm có thể không có loại vấn đề này.
Amir Rezaei

Tôi không thích MoSCoW. Thông minh duy nhất với nó là từ viết tắt. Chỉ cần giữ nhiệm vụ của bạn trong một tồn đọng ưu tiên.
Martin Wickman

1
@Martin nhún vai "Phải" có nghĩa là "nếu bạn không gửi tính năng này thì bạn chẳng có gì cả". Đó là thông tin khác với một hồ sơ tồn đọng ưu tiên, đó là "tính năng nào bạn thích đầu tiên?" Bạn vẫn còn tồn đọng ưu tiên với MoSCoW.
Frank Shearar

2

Dự toán dự án là cờ bạc, đơn giản và đơn giản. Không có phần thưởng mà không có rủi ro.

Nếu người quản lý không hiểu điều này, đó là điều đầu tiên tôi sẽ giải thích.

Câu hỏi là, ai là người chịu rủi ro?

Nếu bạn đang ở trong một hợp đồng giá cố định, thì bạn đang chịu rủi ro.

Nếu thời gian và vật liệu, sau đó anh ta đang bao gồm rủi ro.

Vì vậy, khi ước tính, điều quan trọng là phải hiểu rằng bạn đang đoán và bạn cần có ý tưởng về việc ước tính không chắc chắn như thế nào và ai là người chịu rủi ro.


1

Tôi tin rằng chiến lược tốt nhất là liên tục tinh chỉnh dự toán của bạn . Tôi biết, tôi đang nói: câu hỏi của bạn bị đặt nhầm chỗ.

Đọc Giới thiệu Khám phá có chủ ý của Dan North Tôi đã đi đến kết luận rằng việc đặt nỗ lực ước tính trong giai đoạn khởi đầu bằng để đưa ra dự đoán chính xác khi sự thiếu hiểu biết của bạn về vấn đề và miền ở mức tối đa. Đối mặt với nó, bạn không thể dự đoán những gì không chắc chắn, đặc biệt là nếu nó vẫn chưa được biết .

Các phương pháp nhanh nhẹn giải quyết vấn đề này, phá vỡ vòng đời của dự án thành nhiều phần (chạy nước rút, trong Scrum) và lặp lại ước tính (định cỡ câu chuyện) mỗi tuần. Mỗi tuần, những gì bạn biết về vấn đề được cải tiến, và ước tính cũng vậy.

Đối với tôi, một ước tính không thể đúng hay sai. Nó chỉ có thể được tinh chế ngày càng tăng . Một ước tính không phải là một cam kết. Đó là lý do tại sao nó được gọi là ước tính.

Điều tốt nhất bạn có thể làm khi bạn đến trễ (và cả khi bạn "có nguy cơ giao hàng trước", bởi vì vấn đề là như nhau: bạn đã ước tính không tốt) là leo thang và nâng cao thực tế cho khách hàng càng sớm càng tốt. Nó được gọi là quản lý rủi ro. Bạn đưa ra phản hồi càng sớm thì hiệu quả phản tác dụng sẽ càng cao. Thông thường điều đó có nghĩa là, nếu bạn có bằng chứng bạn không thể cung cấp mọi thứ, bạn nên nói chuyện với khách hàng của mình, nói với cô ấy rằng bạn chỉ có thể cung cấp 70% cam kết và để cô ấy quyết định những gì có giá trị kinh doanh hơn cho cô ấy và nên triển khai trước .

Tôi đã viết về nó ở đây Ước tính sai, giúp đỡ! Tôi trễ! Cắt các tính năng và ngừng thác nước!


1

Nó được gọi là ước tính bởi vì nó là một phỏng đoán có giáo dục. Nó không phải là một mô tả không thể sai lầm về tương lai và tôi có chút kiên nhẫn đối với những người đối xử với ước tính phần mềm theo cách đó. Cuối cùng, nhiều thứ sẽ mất nhiều thời gian hơn bạn mong đợi, trong những trường hợp hiếm hoi, chúng có thể mất nhiều thời gian hơn. Điều này xảy ra ngay cả với các lập trình viên giỏi nhất trên thế giới. Làm thế nào một người quản lý có thể mong đợi nó không xảy ra với bạn? Nếu người quản lý của bạn không hiểu điều đó, cô ấy không có nhiều kinh nghiệm. Nếu cô ấy giả vờ không hiểu nó để áp dụng lịch trình, cô ấy đang không hợp lý.

Cách tiếp cận tốt nhất là rõ ràng nhất. Ngay khi bạn có một ý tưởng rõ ràng rằng một tính năng sẽ mất nhiều thời gian hơn dự kiến, hãy thảo luận với người quản lý của bạn. Thường có nhiều cách để tiến hành sẽ giải quyết cả vấn đề của bạn và người quản lý của bạn. Đó là, phần của tính năng làm chậm mọi thứ có thể tương đối không quan trọng hoặc dễ sửa đổi theo cách làm cho tiến trình nhanh hơn có thể. Dù thế nào đi nữa, đừng để bị bắt nạt vào một ước tính lạc quan thứ hai.


0

Hãy để tất cả các đội biết điều đó và cố gắng tìm một giải pháp. Tôi đề xuất 3 giải pháp, từ ưu tiên cao đến thấp:

a. Cố gắng tìm một sửa chữa nóng tạm thời, hoặc nhanh chóng

b. Công việc mà bạn có thể làm nó, làm nó tốt nhất. Sau khi thể hiện phần công việc tuyệt vời của bạn cho khách hàng, hãy yêu cầu họ giúp đỡ: chúng tôi có thể làm điều này, nhưng có một số vấn đề và nó có thể làm giảm năng suất công việc của bạn ... Có thể bạn có thể hỏi họ nếu có yêu cầu không cần thiết / tính năng có thể được bỏ, hoặc cắt giảm.

Đề xuất một phương pháp thay thế cho vấn đề của họ có thể là một ý tưởng tốt.

c. Làm thêm giờ


Tôi cập nhật câu hỏi của tôi. Đó là người lãnh đạo dự án sẽ được thông báo.
Amir Rezaei

Tôi không hiểu lắm. Bạn là người lãnh đạo dự án, hay chỉ là một lập trình viên?
Hoàng Long

0

Tùy chọn:

  • Tính năng cắt
  • Cắt giảm chất lượng (để lại sửa lỗi cho sau này)
  • Tăng năng suất
    • Tìm và loại bỏ các trình chặn
    • Nghỉ ngơi / nghỉ ngơi
    • Cắt giảm thời gian cá nhân / ngủ
    • Có thêm lực lượng lao động
    • Nhận công cụ tốt hơn
    • Đào tạo
    • Tăng động lực
      • Đồ ăn miễn phí
      • [Hứa của] tăng / khuyến mãi / kỳ nghỉ / tiền thưởng / vv.
      • Các mối đe dọa
      • Cải thiện điều kiện làm việc (phần cứng, đồ nội thất tốt hơn, v.v.)
      • Thay đổi môi trường - làm việc từ quán cà phê hoặc di chuyển cả đội đi đâu đó mát mẻ - nhà nghỉ trên núi hay nhà bên hồ?

1
Cần lưu ý rằng mỗi từ đó là câu trả lời NGẮN HẠN cho câu hỏi "phải làm gì khi ước tính thời gian sai". Đáng chú ý nhất, các mối đe dọa làm tăng động lực trong thời gian ngắn , và sau đó có tác động ngược lại.
Dan Ray

Tôi đồng ý rằng các mối đe dọa sẽ hút, mặc dù tôi chắc chắn rằng chúng có tác dụng với một số người và trong một số tình huống, đặc biệt là nếu bạn có kế hoạch cho phép họ đi bằng mọi cách.

0

Đây là một vấn đề phổ biến :)

Một trong những cách tiếp cận đơn giản hơn là thêm một bộ đệm vào bất kỳ ước tính nào bạn thực hiện, vì các vấn đề chưa được giải quyết luôn xảy ra. Kích thước của bộ đệm phụ thuộc vào kích thước của nhóm và sự không chắc chắn của công nghệ và chính vấn đề.

Các đội lớn hơn có nhiều người mắc bệnh hơn và ít người biết "mọi thứ" hơn.

Các công nghệ mới luôn rủi ro hơn những công nghệ bạn đã biết.

Và khi bạn thấy rằng bạn sẽ không kết thúc vào ngày ước tính, hãy liên lạc sớm với các bên liên quan. Có thể bạn có thể ưu tiên lại nội dung hoặc trì hoãn một số tính năng nhất định sau khi nói chuyện với khách hàng / các bên liên quan.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.