Làm thế nào để tôi tính đến các nhiệm vụ đã thay đổi hoặc bị lãng quên trong một ước tính?

Để xử lý các ước tính cấp độ nhiệm vụ và báo cáo thời gian, tôi đã sử dụng (đại khái) kỹ thuật mà Steve McConnell mô tả trong Chương 10 của Dự toán phần mềm. Cụ thể, khi đến lúc tôi phải tạo ước tính cấp độ nhiệm vụ (ngay trước khi mã hóa bắt đầu dự án), tôi xác định các nhiệm vụ ở mức khá chi tiết để bất cứ khi nào có thể, tôi không có nhiệm vụ nào với một điểm duy nhất, 50 % - độ tin cậy ước tính lớn hơn bốn giờ. Bằng cách đó, quy trình ước tính nhiệm vụ giúp xây dựng phần mềm đồng thời giúp tôi không quên các nhiệm vụ trong quá trình ước tính. Tôi cũng đưa ra một phạm vi giờ có thể cho mỗi nhiệm vụ và bằng cách sử dụng các tính toán thống kê mà McConnell mô tả cùng với dữ liệu chính xác lịch sử của tôi, tôi có thể tạo ước tính ở các mức độ tin cậy khác khi muốn. Tôi cảm thấy như phương pháp này đã làm việc khá tốt cho tôi. Chúng tôi được yêu cầu đưa các nhiệm vụ và ước tính của chúng vào TFS để theo dõi, vì vậy tôi sử dụng các ước tính theo tỷ lệ tin cậy mà tôi được yêu cầu sử dụng.

Tuy nhiên, tôi không chắc chắn phải làm gì khi tôi quên một nhiệm vụ hoặc cuối cùng tôi cần phải thực hiện công việc không nằm gọn trong một trong những nhiệm vụ tôi ước tính. Tất nhiên, cố gắng tránh tình huống này là tốt nhất, nhưng làm thế nào để tôi tính đến các nhiệm vụ bị lãng quên / thay đổi? Tôi muốn có dữ liệu lịch sử tốt nhất có thể để giúp tôi ước tính trong tương lai, nhưng hiện tại, về cơ bản tôi chỉ đang tính toán liệu tôi có đưa ra ước tính độ tin cậy 50% hay không và liệu tôi có đưa ra ước tính trong phạm vi không.

Tôi sẽ vui lòng làm rõ những gì tôi đang hỏi nếu cần - cho tôi biết những gì không rõ ràng.

Cuốn sách Waltzing With Bears: Quản lý rủi ro đối với các dự án phần mềm (của DeMarco và Lister, các tác giả của Peopleware) có một cách tiếp cận tuyệt vời cho vấn đề này. Đây là cách diễn giải của tôi:

Hãy ước tính "mọi thứ diễn ra hoàn hảo". Tất nhiên, mọi thứ hiếm khi diễn ra hoàn hảo, do đó có khả năng xảy ra thấp, nói 0,1 phần trăm. Nói cách khác, chỉ có một dự án trong một nghìn sẽ hoàn thành kế hoạch. Đây là những gì hầu hết mọi người sử dụng như "ước tính" của họ rõ ràng là điên rồ.

Thay vào đó chúng ta nên nghĩ về các ước tính như phân phối xác suất. Ước tính "thế giới hoàn hảo" này là điểm trái nhất trong phân phối xác suất ước tính.

Tiếp theo, hãy ước tính "nếu mọi thứ diễn ra như thế đã xảy ra đối với các dự án tương tự như thế này". Ước tính này giúp bạn có "chế độ xem bên ngoài" ( http://wiki.lesswrong.com/wiki/Outside_view ), thoát khỏi sai lầm kế hoạch ( http://wiki.lesswrong.com/wiki/Planning_fallacy ).

Tiếp theo, hãy ước tính "Tôi chắc chắn 90% sẽ được thực hiện bằng X". Hãy rất, rất chắc chắn rằng bạn có nghĩa là chắc chắn 90%. Nói cách khác, bạn dự kiến ​​sẽ mất nhiều thời gian hơn dự toán này chỉ một lần cho mỗi mười dự án bạn làm.

Bây giờ chúng tôi có thể sử dụng ước tính đầu tiên của bạn làm ước tính xác suất 0,1% và ước tính thứ hai của bạn là ước tính xác suất 50% (theo mùa) và thứ ba là ước tính 90% của bạn, sẽ cho bạn một đường cong đẹp.

Giả sử các ước tính 0%, 50% và 90% của bạn là ngày 1 tháng 5, ngày 1 tháng 6 và ngày 1 tháng 8, thì đường cong ước tính của bạn sẽ trông giống như thế này:

     100 |                                  ......
         |                        ..........
% chance |                ........
of being |          ......
  done   |      ....
         |   ...
         |...
       0 +-----------------------------------------
          \           \           \           \
           May 1st     June 1st    July 1st    August 1st

Lưu ý cách tăng trưởng của xác suất chậm lại theo thời gian. Nếu ai đó hỏi bạn ước tính 99,9% trong kịch bản này, đó có thể là ngày 1 tháng 1 năm sau.

Trong một từ - dự phòng.

Dự phòng là số tiền bạn thêm cho "những thứ khác" - những thứ bạn không thể tính đến ở nơi khác trong ước tính của mình. SMc có bao gồm nó trong Dự toán phần mềm không? Tôi không thể nhớ và bản sao của tôi đang ở nơi làm việc (Tôi đang trong kỳ nghỉ trả lời điều này - tôi buồn như thế nào) ...

Dù sao, nói chung, có ba loại dự phòng mà tôi khuyên bạn nên xem xét:

1) Dự phòng rủi ro cụ thể - đó là nơi bạn xác định một rủi ro cụ thể và thêm một khoảng thời gian nhất định để chi trả cho khả năng vượt quá tiềm năng liên quan đến nó. Điều đầu tiên cần làm rõ ở đây là rủi ro là gì - đó là điều có thể xảy ra, điều này sẽ tác động tiêu cực đến dự án, nằm ngoài tầm kiểm soát của bạn .

Phần cuối cùng này rất quan trọng - đó không chỉ là "mọi thứ mất nhiều thời gian hơn tôi nghĩ", đó là "mô-đun lập lịch của bên thứ 3 mà chúng tôi đã nói rằng chúng tôi phải sử dụng vì đó là tiêu chuẩn của công ty có thể không theo nhiệm vụ". Cách bạn tính toán mức độ rủi ro cần thêm là bao nhiêu phần trăm cơ hội rủi ro có thể vượt qua được biểu thị dưới dạng thập phân (vì vậy 50% = 0,5), nhân với tác động của rủi ro đó (vì vậy, trong ví dụ nói rằng bạn cần phải viết CRON theo cách thủ công công việc thay vì sử dụng công cụ lên lịch và việc này sẽ mất 10 ngày, con số này là 10 ngày).

Vì vậy, nếu có 50% khả năng rủi ro của bạn sẽ vượt qua, và sẽ mất 10 ngày nỗ lực để hoàn thành nó nếu có, bạn thêm 5 ngày. Thêm tất cả các giá trị cho tất cả các rủi ro đã xác định trên dự án và thêm nó vào tổng số.

2) Shit xảy ra tình cờ - Mô tả hay nhất tôi từng nghe về nó, ngay cả khi nó không thanh lịch. Đó là một dự án CNTT, shit xảy ra. Nó không bao giờ đi theo cách bạn nghĩ nó sẽ, mọi thứ mất nhiều thời gian hơn, bị bỏ lỡ và như vậy. Nói chung, Dự phòng SH sẽ nằm trong khoảng từ 10% (tối thiểu tuyệt đối) và 25% (mặc dù có thể cao hơn) với 15% là về mức độ điển hình, mức độ chính xác phụ thuộc vào mức độ không chắc chắn và rủi ro chung (chuyển mục tiêu, yêu cầu không chắc chắn, v.v. ).

Nếu PM của bạn không chấp nhận SH Contingency (và có thể, anh ta có thể không có kinh nghiệm về các dự án CNTT hoặc là một người lạc quan mù quáng), thì chỉ cần thêm nó vào tất cả số tiền riêng lẻ. Nếu anh ấy biết những gì anh ấy đang làm, anh ấy sẽ có một bản ghi rủi ro của riêng mình và yêu bạn vì đã nghĩ về những thứ này. Chắc chắn nếu anh ta có bất kỳ loại bằng cấp PM nào (như PRINCE2), anh ta sẽ biết về nó.

3) Thay đổi dự phòng - Đây là nơi bạn khá chắc chắn rằng khách hàng sẽ đưa ra các thay đổi nhưng không muốn nó là một điểm gây tranh cãi. Thêm X ngày hoặc X% và nó sẽ được đưa vào nhóm để thay đổi khách hàng tăng. Có hai cách để đối phó với nó: hoặc bạn nói với họ về điều đó và đó là chi tiêu của họ hoặc bạn không nói với họ về điều đó.

Cách đầu tiên là tốt nhất nhưng cần một khách hàng có học thức và công bằng - mọi thứ được phân loại là thay đổi và anh ta có thể chi tiêu nồi của mình khi anh ta thấy phù hợp (dựa trên bạn ước tính mọi thứ khi họ đưa ra).

Cách thứ hai bạn đề cập rằng đó là một sự thay đổi nhưng đừng tìm cách tính phí anh ta thêm. Bạn phải lưu ý tất cả những thứ bạn chi tiêu cho nó vì vậy nếu nó đến mức nó hết và bạn phải quay lại với khách hàng và yêu cầu thêm thời gian hoặc tiền bạc và họ nói "giữ lấy, tôi ' m pay blah blah blah "bạn có thể chỉ ra tất cả những điều họ đã thay đổi mà bạn đã không tính phí như một dấu hiệu cho thấy bạn không hoàn toàn vô lý. Nó không phải lúc nào cũng hoạt động nhưng nó hầu như luôn củng cố sức mạnh của bạn trong các cuộc thảo luận.

Không ai trong số ba điều cụ thể bao gồm những điều bạn đã quên nhưng tôi nghĩ giữa chúng sẽ lấp đầy rất nhiều khoảng trống bạn có.

Khi được yêu cầu ước tính cho một nhiệm vụ, hãy đưa ra ước tính cao cấp cho nhóm và ước tính cấp thấp cho chính mình, làm điều đó bạn sẽ luôn có thời gian sau khi hoàn thành nhiệm vụ để làm việc gì đó mà bạn có thể đã quên đề cập ở vị trí đầu tiên.

Bạn có lo ngại rằng bằng cách thêm các nhiệm vụ bổ sung, bạn sẽ làm lệch độ chính xác lịch sử của bạn? Hoặc bạn có nghĩ rằng không bao gồm các nhiệm vụ bổ sung sẽ làm lệch độ chính xác?

Tôi nghĩ rằng để tốt nhất cho dự án, các nhiệm vụ nên được đưa vào hệ thống theo dõi. Tôi chắc chắn rằng trưởng dự án sẽ có thể đưa ra một lời giải thích phù hợp cho ban quản lý về sự khác biệt ...