Làm thế nào để trả lời khi bạn được yêu cầu ước tính?

Chúng tôi, với tư cách là lập trình viên, liên tục được hỏi 'Sẽ mất bao lâu'?

Và bạn biết đấy, tình hình hầu như luôn như thế này:

• Các yêu cầu không rõ ràng. Không ai đã thực hiện một phân tích chuyên sâu về tất cả các tác động.
• Tính năng mới có thể sẽ phá vỡ một số giả định bạn đã thực hiện trong mã của mình và bạn bắt đầu nghĩ ngay đến tất cả những điều bạn có thể phải cấu trúc lại.
• Bạn có những thứ khác để làm từ các bài tập trước đây và bạn sẽ phải đưa ra một ước tính có tính đến công việc khác đó.
• Định nghĩa 'xong' có lẽ không rõ ràng: Khi nào nó sẽ được thực hiện? 'Xong' như vừa hoàn thành mã hóa nó, hay 'xong' như trong "người dùng đang sử dụng nó"?
• Cho dù bạn có ý thức như thế nào về tất cả những điều này, đôi khi "niềm tự hào của lập trình viên" khiến bạn cho / chấp nhận thời gian ngắn hơn so với ban đầu bạn cho rằng nó có thể mất. Đặc biệt khi bạn cảm thấy áp lực của thời hạn và kỳ vọng quản lý.

Nhiều trong số đó là những vấn đề về tổ chức hoặc văn hóa không đơn giản và dễ giải quyết, nhưng cuối cùng thực tế là bạn đang được yêu cầu ước tính và họ mong bạn đưa ra câu trả lời hợp lý. Đó là một phần công việc của bạn. Bạn không thể đơn giản nói: Tôi không biết.

Kết quả là, tôi luôn luôn đưa ra những ước tính mà sau này tôi nhận ra mình không thể thực hiện được. Nó đã xảy ra vô số lần và tôi luôn hứa rằng điều đó sẽ không xảy ra lần nữa. Nhưng nó làm.

Quá trình cá nhân của bạn để quyết định và đưa ra một ước tính là gì? Những kỹ thuật bạn đã tìm thấy hữu ích?

Từ lập trình viên thực dụng: Từ Journeyman đến Master :

Nói gì khi được hỏi về Ước tính

Bạn nói "Tôi sẽ lấy lại cho bạn."

Bạn hầu như luôn nhận được kết quả tốt hơn nếu bạn làm chậm quá trình và dành thời gian trải qua các bước chúng tôi mô tả trong phần này. Ước tính được đưa ra tại máy pha cà phê sẽ (như cà phê) trở lại ám ảnh bạn.

Trong phần này, các tác giả đề xuất quy trình sau:

• Xác định độ chính xác mà bạn cần. Dựa trên thời lượng, bạn có thể trích dẫn ước tính với độ chính xác khác nhau. Nói "5 đến 6 tháng" khác với nói "150 ngày". Nếu bạn trượt một chút vào tháng thứ 7, bạn vẫn khá chính xác. Nhưng nếu bạn trượt vào ngày thứ 180 hoặc 210, thì không nhiều lắm.
• Hãy chắc chắn rằng bạn hiểu những gì đang được hỏi. Xác định phạm vi của vấn đề.
• Mô hình hệ thống. Một mô hình có thể là một mô hình tinh thần, sơ đồ hoặc các bản ghi dữ liệu hiện có. Phân tách mô hình này và xây dựng các ước tính từ các thành phần. Gán giá trị và phạm vi lỗi (+/-) cho từng giá trị.
• Tính toán ước tính dựa trên mô hình của bạn.
• Theo dõi ước tính của bạn. Ghi lại thông tin về vấn đề bạn đang ước tính, ước tính của bạn và các giá trị thực tế.
• Những thứ khác trong ước tính của bạn là phát triển và ghi lại các yêu cầu hoặc thay đổi đối với thông số kỹ thuật yêu cầu, tạo hoặc cập nhật tài liệu thiết kế và thông số kỹ thuật, thử nghiệm (đơn vị, tích hợp và chấp nhận), tạo hoặc cập nhật hướng dẫn sử dụng hoặc READMEs với các thay đổi. Nếu 2 người trở lên làm việc cùng nhau, sẽ có chi phí liên lạc (cuộc gọi điện thoại, email, cuộc họp) và hợp nhất mã nguồn. Nếu đó là một nhiệm vụ dài, hãy tính đến những việc như công việc khác, thời gian nghỉ (ngày lễ, kỳ nghỉ, thời gian nghỉ ốm), các cuộc họp và các nhiệm vụ trên cao khác khi chọn ngày giao hàng.

Ước tính phần mềm là nhiệm vụ đơn lẻ khó khăn nhất trong công nghệ phần mềm - thứ hai gần gũi là yêu cầu khơi gợi.

Có rất nhiều chiến thuật để tạo ra chúng, tất cả dựa trên việc nhận được yêu cầu tốt trước tiên. Nhưng khi bạn dựa lưng vào tường và họ từ chối cung cấp cho bạn thông tin chi tiết hơn, Fake It:

1. Hãy nhìn vào những yêu cầu bạn có.
2. Đặt giả định để điền vào các khoảng trống dựa trên dự đoán tốt nhất của bạn về những gì họ muốn
3. Viết ra tất cả các giả định của bạn
4. Làm cho họ ngồi xuống, đọc và đồng ý với các giả định của bạn (hoặc, nếu bạn may mắn, hãy khiến họ nhượng bộ và đưa ra cho bạn những yêu cầu thực sự).
5. Bây giờ bạn có yêu cầu chi tiết mà bạn có thể ước tính từ.

Nó giống như mẹ tôi từng đe dọa khi tôi còn là một đứa trẻ "Nhanh lên và chọn ra một số quần áo, hoặc tôi sẽ chọn chúng ra cho bạn!"

Tôi đã phát triển cho một anh chàng rất kiên quyết muốn ước tính chính xác. Những gì chúng tôi giải quyết, hoạt động rất tốt, là đây:

• Tôi đã lập hóa đơn cho tất cả thời gian tôi đã ước tính. Nó chiếm khoảng 20-25% những gì tôi đã lập hóa đơn.
• Tôi đã làm kiểm tra cực kỳ chi tiết của các nhiệm vụ. Không chụp từ hông. Tôi đã đi vào mã, tìm ra những dòng cần thay đổi, những phần khác của chương trình sẽ ảnh hưởng đến mức độ nào, tôi phải làm bao nhiêu thử nghiệm để đảm bảo mọi thứ vẫn hoạt động. Tôi ước tính mỗi phần theo đơn vị .1 giờ (6 phút).
• Tôi đã gửi cho anh ta ước tính của tôi cho từng nhiệm vụ cùng với sự cố chi tiết đó.

20-25% thanh toán có vẻ rất nhiều.

Nhưng anh ấy yêu cầu tôi thực hiện thay đổi XYZ, nghĩ rằng sẽ mất khoảng 2 giờ. Trong 1 giờ ước tính chi tiết, tôi xác định sẽ mất 8,5 giờ. Vì vậy, anh ấy quyết định liệu nó có đáng giá 8,5 giờ trả tiền hay không. Nếu không, sau đó anh ta đã tiết kiệm được 7,5 giờ so với chi phí mà anh ta phải trả nếu tôi thực hiện nó mà không có ước tính.

Và nếu anh ta muốn đầu tư 8,5 giờ, công việc chi tiết tôi đã làm cho ước tính là công việc tôi phải làm bằng mọi cách.

Tôi thấy rằng với phương pháp này, tôi có thể thực hiện hầu hết các nhiệm vụ đúng hạn hoặc thậm chí sớm, mà không phải đánh giá quá cao. Bởi vì thời gian đã bị phá vỡ rất tinh vi, tôi có thể nói sớm nếu tôi bị trượt. Nếu tôi gặp những trở ngại để sau 3 giờ tôi có thể biết rằng nhiệm vụ 8,5 giờ của tôi sẽ diễn ra 12, tôi có thể nói chuyện với anh ấy trước khi có thêm thời gian để anh ấy có thể đánh giá lại và đánh giá tính năng nếu anh ấy lo ngại về chi phí .

Có phải anh ấy đã mờ đi? Không, tôi xem nó như để anh ta áp dụng tiền của mình vào nơi anh ta thấy có lợi nhất. Và tôi rất vui khi có được kinh nghiệm trong việc ước tính, điều mà tôi luôn thấy khủng khiếp.

Chúng tôi thường được yêu cầu "ước tính sân bóng" trong các cuộc họp, nơi chúng tôi đưa ra những ý tưởng rất rộng rãi và vauge về những gì họ muốn làm. Tôi luôn nói, "nếu bạn muốn có câu trả lời hôm nay thì đó là một năm và một triệu đô la. Nếu bạn muốn cho tôi biết thêm chi tiết và một chút thời gian để xem xét chúng thì tôi có thể tinh chỉnh những con số đó cho bạn."

Họ hầu như luôn luôn có được điểm.

Nó phụ thuộc vào những gì ước tính là cho.

Đối với một ước tính ban đầu, cấp cao cho một trường hợp kinh doanh thì điều quan trọng là:

1. Tốc độ. Dù bạn sử dụng phương pháp nào thì cũng cần phải nhanh chóng. Toàn bộ vấn đề là các bên liên quan không chắc chắn liệu nó có đáng để thực hiện dự án hay không - đó là lý do tại sao họ cần các con số cho trường hợp kinh doanh. Nếu trường hợp kinh doanh vững chắc, họ sẽ không cần ước tính của bạn. Phần lớn các dự án này sẽ không đi trước, vì vậy điều quan trọng là quá nhiều nỗ lực không được dành cho việc ước tính.
2. Đưa ra một phạm vi. Làm cho nó rộng. Bạn đã không có thời gian để phân tích các yêu cầu, hội thảo với các bên liên quan, xác nhận các giả định. Phạm vi rộng cho người nhận ước tính "Các dự án phần mềm rất phức tạp và rủi ro - nếu bạn muốn có ước tính chính xác, bạn cần cung cấp cho tôi nhiều chi tiết hơn và nhiều thời gian hơn". Vấn đề với việc đưa ra một con số hoặc một phạm vi hẹp là nó đưa bạn vào một góc bằng cách đặt kỳ vọng trước khi thực hiện bất kỳ phân tích thực tế nào.

Tôi tìm thấy kỹ thuật tốt nhất để chọn một dự án tương đương mà "cảm thấy" giống nhau. "Cảm nhận" là hoàn toàn chủ quan - nhưng với loại ước tính này, kinh nghiệm của tôi cho tôi biết bạn sẽ không tìm thấy các phép đo khách quan. Sau đó cung cấp một phạm vi rộng. Tôi đã đọc một số cuốn sách nói rằng phạm vi từ -50% đến + 100% là tốt nhưng nó phụ thuộc vào nhiều yếu tố.

Đối với một ước tính chi tiết, cấp thấp:

1. Bạn cần một đường cơ sở. Nếu đường cơ sở không ổn định, ước tính là vô nghĩa.
2. Từ dưới lên là tốt nhất. Nhận phân tích công việc chi tiết, ước tính từng thành phần sau đó cuộn nó thành một số lớn hơn. Tôi thấy lập kế hoạch poker là một kỹ thuật tuyệt vời ở đây.
3. Dự phòng tài liệu. Làm rõ nơi dự phòng (nếu có) được thêm vào. Được thêm vào từng mục hàng? Hoặc để toàn bộ ước tính? Hoặc để rủi ro cụ thể? Hay là không có?
4. Nêu các giả định của bạn. Xác thực càng nhiều càng tốt cho khung thời gian.
5. Nêu rõ những gì được bao gồm và loại trừ trong dự toán. Ví dụ, bao gồm đánh giá? Là sự chậm trễ kỹ thuật bao gồm?

Một số lời khuyên từ mặt tối từ một người học cách khó khăn.

Các yêu cầu không rõ ràng. Không ai đã thực hiện một phân tích chuyên sâu về tất cả các tác động.

Đừng ước tính vào thời điểm này. Người ta không ước tính có bao nhiêu binh sĩ cần thiết để giành chiến thắng trong một trận chiến mà không có manh mối về số lượng kẻ thù. Dự toán được thực hiện sau khi trinh sát. Điều này là trừ khi bạn đã chiến đấu với kẻ thù này.

Tính năng mới có thể sẽ phá vỡ một số giả định bạn đã thực hiện trong mã của mình và bạn bắt đầu nghĩ ngay đến tất cả những điều bạn có thể phải cấu trúc lại.

Đây là trách nhiệm của bạn để tham gia trừ khi bạn mong đợi người khác có chuyên môn về lĩnh vực này.

Bạn có những thứ khác để làm từ các bài tập trước đây và bạn sẽ phải đưa ra một ước tính có tính đến công việc khác đó.

Tương tự như trên, ngay cả đối với công việc không dự đoán được tạo bởi một người bạn đồng đội bên cạnh bạn với quy trình kiểm tra gần như không tồn tại khiến mã của bạn bị trục trặc mà bạn không thể dự đoán trước một cách hoàn hảo. Đó là một dự báo thời tiết.

Định nghĩa 'xong' có lẽ không rõ ràng: Khi nào nó sẽ được thực hiện? 'Xong' như vừa hoàn thành mã hóa nó, hay 'xong' như trong "người dùng đang sử dụng nó"?

Hiểu yêu cầu kết thúc của người dùng ở đây, suy nghĩ như một người dùng. Đừng làm những gì đồng nghiệp của bạn làm nếu họ ước tính một cái gì đó sẽ được "thực hiện" chỉ vì một số chức năng cơ bản với quy trình làm việc của barebones mà không người dùng nào có thể chịu đựng được là những gì họ cho là "hoàn thành" . Hãy nghĩ về nó từ quan điểm người dùng, bởi vì đó là tất cả các khách hàng bạn đang ước tính sẽ hiểu. Ước tính theo yêu cầu hoàn chỉnh của người dùng, không phải theo yêu cầu kỹ thuật của barebone. Và nhận ra rằng khách hàng của bạn yêu cầu ước tính sẽ hoàn toàn không chính xác ở đây về cách họ diễn đạt mọi thứ và hiểu các khía cạnh kỹ thuật của những gì bạn nói.

Cho dù bạn có ý thức như thế nào về tất cả những điều này, đôi khi "niềm tự hào của lập trình viên" khiến bạn cho / chấp nhận thời gian ngắn hơn so với ban đầu bạn cho rằng nó có thể mất. Đặc biệt khi bạn cảm thấy áp lực của thời hạn và kỳ vọng quản lý.

Đừng làm điều này! Bạn có vẻ như là một nhân viên chăm chỉ tự động viên và có thể là một người dễ dàng nhượng bộ.

Vấn đề ở đây là: giả sử bạn và Joe ước tính thời gian cho cùng một nhiệm vụ (nhưng giữa hai nhân viên riêng biệt, không biết cả hai ước tính cùng một lúc). Bạn ước tính dũng cảm, "một tuần" . Bạn nghĩ không sao, bạn sẽ làm việc hơn 100 giờ một tuần, không được trả lương ngoài giờ. Bây giờ bạn trễ ba ngày.

Trong khi đó, Joe ước tính 5 tháng. Bạn nghĩ rằng điều này là vô lý, bạn nghĩ rằng bạn có thể thực hiện điều này trong một tuần. Joe làm việc bao nhiêu? 10 giờ một tuần? ... ngoại trừ anh ấy hoàn thành đúng hạn trong đúng 5 tháng.

Đoán xem ai được coi là kẻ ngốc? Đúng vậy, bạn. Joe có vẻ như là một công nhân tuyệt vời, bạn dường như không đáng tin cậy. Nó không quan trọng đến mức bạn có thể đạt được kết quả thậm chí còn tốt hơn trong ~ 7% thời gian Joe đã làm. Vấn đề là bạn được nghỉ 3 ngày so với ước tính một tuần.

Không bao giờ sai ở phía ước tính chặt chẽ hơn. Err về phía ước tính lỏng lẻo. Có một danh tiếng để xây dựng tại công ty của bạn và nó sẽ không dựa trên độ dài của các ước tính của bạn gần bằng độ chính xác của các ước tính của bạn. Thật dễ dàng để chính xác với một ước tính quá dài, bạn chỉ cần có thêm thời gian để giải quyết vấn đề và giải quyết nó tốt hơn. Một ước tính quá ngắn không có phòng thở, bạn sẽ gặp nó một cách tuyệt vọng hoặc bạn bị lừa.

"Hai tuần!"

Nghiêm túc. Ước tính đầu tiên của tôi luôn luôn là hai tuần. Bởi vì tôi có một khối tâm thần kỳ quái nào đó khiến tôi nghĩ mọi thứ nghe có vẻ như sẽ hai tuần.

Tôi cố gắng làm việc xung quanh nó, cố gắng thực sự nghĩ về việc tôi nghĩ sẽ mất bao lâu, cố gắng xác định tất cả các điểm rắc rối tiềm ẩn và các bit trông quá đen để tôi ước tính chính xác. Và cố gắng nhận ra rằng nếu câu trả lời của tôi là "Hai tuần!", Tôi có khả năng đã không làm như vậy.

Khá nhiều người quản lý giỏi mà tôi đã học cách nhận ra "Hai tuần!" như một câu trả lời đòi hỏi một cú tát nhẹ bằng lời nói trong phản ứng.

Có một mục blog phác thảo cách ghi lại mức độ chính xác của các ước tính trước đó của bạn, và lần sau bạn nói với ai đó "sẽ là hai tuần", bạn có thể xem lịch sử trước đó của mình và xem nó kéo dài bao lâu thực sự đã mất lần cuối bạn nói "nó sẽ là hai tuần".

Tôi đã không thử bản thân mình, nhưng tôi muốn, để xem ước tính của tôi chính xác đến mức nào.

Nó phụ thuộc vào tổ chức và cách ước tính được sử dụng.

Nếu ước tính chỉ là để cung cấp một ý tưởng chung về khi nào nó sẽ sẵn sàng, tôi thường có thể ước tính nhanh dựa trên kinh nghiệm của mình. Thường thì tôi sẽ bao gồm bất kỳ sự không chắc chắn hoặc các biến thể có thể có với ước tính cùng với cách các thay đổi có thể ảnh hưởng đến các khu vực khác của hệ thống và mức độ thử nghiệm hồi quy cần thiết.

Nếu ước tính được sử dụng cho bất kỳ điều gì theo hợp đồng hoặc trong một kịch bản đòi hỏi thời gian chính xác hơn, tôi sẽ hoàn thành công việc. Đây là công việc nhiều hơn và đòi hỏi suy nghĩ sâu hơn về thiết kế và thay đổi hệ thống, nhưng chính xác hơn nhiều, đặc biệt là đối với các phần lớn hơn của công việc.

Trong cả hai trường hợp, giao tiếp liên tục là chìa khóa. Nếu bạn gặp phải điều gì đó bất ngờ, hãy làm cho nó được biết đến vào thời điểm đó thay vì chờ đến thời hạn. Nếu các yêu cầu không rõ ràng, hãy đảm bảo bạn ghi lại sự hiểu biết của bạn về chúng và chức năng mà bạn dự định cung cấp. Điều này cũng hữu ích với bất kỳ giả định nào bạn đưa ra. Và theo như các ưu tiên cạnh tranh, khi một phần của công việc va chạm với nhau, hãy rõ ràng về cách điều đó sẽ tác động đến lịch trình.

Ước tính để làm gì? Nhiệm vụ nhỏ hoặc giải pháp hoàn chỉnh.

Điều sau tôi hiếm khi làm nhưng sau đó chỉ cần đoán, thêm một chút, yêu cầu người quản lý thêm một chút và biến nó thành một phạm vi, với một ghi chú nhỏ bên cạnh cho biết ở trên là một phỏng đoán.

Nhiệm vụ nhỏ - Lập kế hoạch chơi bài xì phé tôi thấy hoạt động rất tốt (không hoàn hảo, một số nhiệm vụ 1pt mất nhiều thời gian hơn và một số nhiệm vụ 5pt mất vài phút, nhưng cuối cùng tất cả đều phát triển).

Trình bày một phạm vi dựa trên những gì bạn biết ngày hôm nay. Sử dụng hình nón không chắc chắn để cung cấp phạm vi xung quanh các dự đoán ban đầu của bạn.

Mỗi tuần tính toán số tiền còn lại phải làm, ước tính lại dựa trên những gì bạn biết. Khi bạn có đủ kích thước mẫu của số lượng công việc bạn nhận được mỗi tuần, hãy cung cấp khoảng tin cậy 90% cho những gì còn lại để đưa ra một phạm vi ngày (thường) thu hẹp khi dự án tiến triển và số lượng công việc còn lại (hy vọng ) co lại.

Tự tin. Tôi không thể nói cho bạn biết bao nhiêu lần tôi đã thực hiện một cuộc họp ban đầu với khách hàng bằng cách không đưa ra sự chuyên nghiệp khi đưa ra ước tính. Ngay cả khi bạn thổi số không khí mỏng - hãy đảm bảo bạn luôn giữ một số ước tính xung quanh. Điều đó nói rằng, hãy cẩn thận để không ước tính mình vào một lỗ. Những thứ khác nhau cần một lượng thời gian, công sức và tài nguyên khác nhau để kết hợp lại với nhau. Đây là một cách tốt để làm điều đó:

Họ: Nó sẽ có giá bao nhiêu?

Tôi: Nó phụ thuộc vào những gì bạn muốn tôi làm. Nói chung, tôi bắt đầu loại dự án này vào khoảng $ X.

Đôi khi việc ước tính trở thành một thách thức lớn đối với bạn và nhóm của bạn, đặc biệt khi chúng ta đang nói về ước tính dự án phần mềm.

Khi chúng tôi đã quyết định chia sẻ kinh nghiệm và kiến ​​thức của mình về quy trình ước tính phần mềm và xác định bốn loại ước tính riêng biệt :

• hình bóng
• ước tính dịch vụ
• ước tính tính năng
• ước tính thành phần

Tất nhiên, những loại đó là khác biệt. Ballpark là nơi thường được gọi là một trò chơi guesstimate. Vì vậy, đó là một con số hoặc phạm vi gần đúng mang lại ý tưởng chung về chi phí và điều đó có thể giúp khách hàng tiềm năng quyết định liệu họ có muốn đưa cuộc thảo luận đi xa hơn không.

Theo quy định, khách hàng cần một con số trên sân bóng khi bắt đầu dự án. Và lời khuyên của chúng tôi là: thảo luận về dự án và cung cấp số liệu sân bóng chỉ nên là các bước tốt để nhận được ước tính thành phần (linh hoạt, người ta có thể sử dụng ước tính loại thành phần cho toàn bộ quá trình phát triển. Không cần phải ước tính lại từ đầu khi bạn muốn thêm, xóa hoặc thay thế các tính năng, dịch vụ, v.v.).

Mọi người nên ghi nhớ những rủi ro khi ước tính phát triển phần mềm: đánh giá thấp, đánh giá quá cao, kịch bản thất bại hoàn toàn sử thi, v.v.

Bạn có thể đọc thêm trên blog của chúng tôi!

http://blog.lprice.co.uk/project-manloyment/software-estimation- Process /

Hy vọng thông tin này sẽ giúp ích cho bạn!

Tôi luôn luôn đưa ra các ước tính mà sau đó tôi nhận ra rằng tôi không thể thực hiện được. Nó đã xảy ra vô số lần và tôi luôn hứa rằng điều đó sẽ không xảy ra lần nữa.

Có vẻ như bạn đang được yêu cầu cam kết, không phải là ước tính. Đây là những điều khác nhau, nhưng nếu bạn có thể quản lý các cam kết một cách đáng tin cậy thì nó sẽ thực sự giúp ích cho uy tín và sự nghiệp của bạn.

Một số lời khuyên dựa trên ~ 10 năm kinh nghiệm của tôi:

• Luôn cung cấp một phạm vi (tức là giới hạn dưới và trên). Điều này sẽ truyền đạt mức độ không chắc chắn của bạn
• Nếu bạn có sự không chắc chắn rất lớn, hãy yêu cầu hoãn lại (ví dụ 1 ngày để phân tích, sau đó cung cấp phạm vi chặt chẽ hơn)
• Nếu tác vụ quá lớn, hãy chia nhỏ nó và cung cấp một phạm vi cho mỗi phần

Đầu tiên, nếu một số nhiệm vụ được giao cho tôi, tôi sẽ chia nó thành các nhiệm vụ. Tôi sẽ ước tính thời gian cho mỗi nhiệm vụ và có thể với các nhiệm vụ tôi có thể tìm thấy khu vực có vấn đề và do đó tôi có thể dự đoán được nó sẽ kéo dài bao lâu đưa đến một mức độ nhất định.

Nhưng tất cả các kế hoạch sẽ chỉ giúp ở một mức độ nhất định. Chỉ khi bạn bắt đầu viết mã, bạn mới có thể tìm thấy các vấn đề chính xác

Nếu bạn thực hiện nhiều dự án cho cùng một ông chủ hoặc khách hàng, bạn có thể cố gắng ước tính theo các mức độ phức tạp rộng thay vì hàng tuần hoặc hàng tháng, có thể ở kích cỡ áo phông. Xác định một vài dự án trong quá khứ và gán cho chúng các kích thước S, M, L, XL.

Và sau đó tự hỏi: dự án nào nghe có vẻ tương tự trong phạm vi? Và sau đó thay vì trả lời bằng "2 tháng", bạn có thể trả lời bằng "âm thanh giống như chữ L đối với tôi" (hoặc bất cứ điều gì hiệu chuẩn của bạn cho dự án hóa ra).

Điều này khá dễ hiểu, và cũng rõ ràng rằng có rất nhiều điều không chắc chắn trong những phỏng đoán đó.

Sau đó, khi các yêu cầu thay đổi, bạn có thể nói "sự thay đổi đó làm cho âm thanh giống với XL hơn".

Hơi muộn một chút nhưng khi tôi ở trong quân đội, chúng tôi được hướng dẫn sử dụng PERT để xác định ước tính. Nó đòi hỏi một số kinh nghiệm trong lĩnh vực của bạn và nhiệm vụ trong tầm tay. Thật đáng ngạc nhiên khi xác định thời gian hoàn thành ước tính khi bảo trì và sửa chữa các thiết bị điện tử (radio phức tạp và thiết bị comms vệ tinh), trong đó bất kỳ số lượng nào có thể sai hoặc tìm thấy và cần được sửa chữa trong quá trình bảo trì định kỳ. Các ước tính rất quan trọng vì các đơn vị khác có thể không hoạt động cho đến khi họ nhận lại thiết bị comms của họ. Một cái mà tôi đã sử dụng là Máy tính PERT trực tuyến miễn phí này