Làm thế nào để trả lời khi nào nó sẽ được thực hiện?

Tất cả chúng ta đều có nó, các vấn đề chứng minh là khó khắc phục và tìm ra cách khắc phục thông qua mã tối nghĩa và chức năng bất ngờ kỳ quái. Dần dần, làm việc một cách hợp lý theo cách của bạn thông qua việc cố gắng tìm ra các mô hình, lỗi, sai lầm. Quá trình này mất thời gian và các vấn đề thường không dễ hiểu bởi khách hàng.

Làm thế nào để một người trả lời khi được hỏi câu hỏi "Khi nào nó sẽ được thực hiện?", Đặc biệt là khi khách hàng có thể không hiểu được sự phức tạp vốn có của phát triển phần mềm?

Bạn trả lời câu hỏi một cách trung thực.

Bạn nói với họ đó là một vấn đề khó khăn, giải pháp không rõ ràng và bạn không chắc sẽ mất bao lâu để giải quyết. Hứa sẽ cập nhật chúng về tiến trình của bạn mỗi [khung thời gian], để chúng biết bạn đang làm việc với nó, và tất nhiên, thực sự gửi cho chúng các bản cập nhật.

Các nhà phát triển tiếp cận một vấn đề phức tạp bằng cách phân tách nó thành những vấn đề nhỏ hơn và giải quyết chúng một cách riêng biệt.

Trong một thế giới lý tưởng , giải quyết một vấn đề sẽ là một vấn đề phức tạp Một và bạn sẽ có thể, trong một thời gian nhất định, để phân hủy nó thành một danh sách ngắn các vấn đề nhỏ Một ₁ đến A _n , cho mỗi đánh giá thời điểm đó là đơn giản, được đưa ra rằng thời gian cần thiết để giải quyết vấn đề phức tạp ban đầu sẽ là:

với D là quá trình tự phân hủy.

Trong thế giới thực , vấn đề duy nhất là t ( D ) thực sự sẽ lớn hơn thời gian bạn dành để giải quyết các vấn đề nhỏ. Nói cách khác, để đạt được mức độ phân rã của vấn đề này, thực tế bạn cần phải tự giải quyết vấn đề.

Bạn vẫn có thể:

• Phân tách nhiệm vụ nhất định (giải quyết vấn đề) thành các phần nhỏ hơn, mỗi phần vẫn là một vấn đề phức tạp,

• Đánh giá thời gian dự kiến ​​cho mỗi đoạn và rủi ro tương ứng.

  Ví dụ, nhiệm vụ 1 yêu cầu khoảng. 5 giờ, nhưng nguy cơ bị chặn làm việc đó là rất cao, vì vậy hãy dành 12 giờ như mong đợi của bạn cho khách hàng.

• Đánh giá sự phụ thuộc và cách chúng ảnh hưởng đến thời gian.

  Ví dụ: nhiệm vụ 19 yêu cầu 2 giờ và rủi ro thấp đến mức bạn có thể nói chắc chắn là 2 giờ. Không phải 1. Không phải 3. Nhưng nhiệm vụ 19 dựa vào nhiệm vụ 24: nhiệm vụ 24 có thể ảnh hưởng đến nhiệm vụ 19 theo cách mà bạn sẽ yêu cầu viết lại hoàn toàn mã của nhiệm vụ 19 bằng cách sử dụng một cách tiếp cận khác.

• Cung cấp tất cả những chi tiết cho khách hàng của bạn. Đừng đưa ra số tiền.

Điểm cuối cùng là quan trọng. Nếu bạn đưa ra số tiền, giả sử 192 giờ, khách hàng tin rằng đó là một số liệu rất chính xác và thời gian bạn sẽ sử dụng là từ 189 đến 195 giờ.

Nếu, thay vào đó, bạn cung cấp các chi tiết,

• Khách hàng quan tâm sẽ hiểu rằng đó không phải là 192 giờ. Đó là 192 giờ nếu mọi thứ không ổn với rủi ro được xác định trong quá trình đánh giá. Đó cũng là 238 giờ nếu mọi thứ còn tồi tệ hơn. Đó cũng là 85 giờ nếu mọi thứ đều ổn.

• Đối với khách hàng không quan tâm, anh ta sẽ không đọc câu trả lời của bạn trong mọi trường hợp. Tất cả những gì anh ấy muốn là một con số, để có thể đổ lỗi cho bạn sau này. Bằng cách đưa ra một câu trả lời rất chi tiết anh ta sẽ không bao giờ đọc, bạn biết rằng anh ta không thể hỏi bạn về thời gian sẽ mất một lần nữa: bạn đã trả lời điều đó. Anh ta cũng không thể đổ lỗi cho bạn sau này, vì anh ta đã không đọc câu trả lời để tính tổng.

Bất cứ điều gì bạn ước tính đừng quên bao gồm luật của Hofstadter : Nó luôn mất nhiều thời gian hơn bạn mong đợi, ngay cả khi bạn tính đến luật của Hofstadter.

Thông thường tôi sử dụng một công thức được sửa đổi từ CPM / PERT. Nó giống như thế này:

Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.

(Tôi không chắc chắn làm thế nào để thực hiện tất cả các định dạng toán học ưa thích; nếu ai đó muốn chỉnh sửa điều này cho điều đó, thì cứ thoải mái.)

So, if you think:
Mn = 60  hours
Mx = 180 hours
T  = 100 hours
C  = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.

Tôi nhấn mạnh rằng nó có thể thay đổi đáng kể, tùy thuộc vào cách dự án đi. Nếu bạn đánh giá lại dự án của bạn vài ngày một lần, bạn thậm chí có thể cung cấp bản cập nhật hàng tuần. Nó đi một chặng đường dài hướng tới việc làm hài lòng những khách hàng cáu kỉnh. :)

Giải thích các mốc thời gian mơ hồ cho người dùng không có kỹ thuật là khó khăn. Điều này đúng cả trong các giai đoạn sáng tạo của một dự án và khi theo dõi một lỗi khó chịu. Trong cả hai trường hợp, "phân tách công việc thành các phần nhỏ" truyền thống cũng không hoạt động.

Nhiệm vụ ban đầu tập trung vào trường hợp sau, vì vậy hãy tập trung vào đó. Nếu bạn không thể đưa ra mốc thời gian, hãy nói với người dùng những gì bạn sẽ thử và khi nào bạn sẽ quay lại với họ. Khi bạn đạt đến nửa điểm trên dòng thời gian tự áp đặt, hãy cập nhật email ngắn gọn và trung thực. Ít nhất một giờ trước hạn chót đưa ra phản hồi chính thức của bạn. Bây giờ bạn có uy tín. Nếu vấn đề không được giải quyết thì ít nhất bạn cũng đang tỏa sáng. Nó có vẻ như lãng phí thời gian, nhưng nó không phải là.

Vì bạn không thể tính đến các rào cản chưa biết và những bất ngờ không lường trước được, nên có thể rất khó để ước tính với sự tự tin. Ý tưởng:

• Hãy thử một phạm vi - "Tôi chắc chắn sẽ mất ít nhất N ngày (ví dụ 3), nhưng có thể mất tới 4N."
• Tìm kiếm sự hỗ trợ của các kỹ sư cao cấp hơn trong việc ước tính và bảo vệ các ước tính.
• Làm việc trong các lần lặp ngắn hơn (kiểu Agile / Scrum) để tạo mã tối thiểu làm tăng giá trị doanh nghiệp (đạt được sự tự tin & tin cậy), sau đó lặp lại.
• Học các kỹ năng đàm phán từ một cuốn sách như cuốn kinh điển Bắt đầu Có (http://www.amazon.com/gp/aw/d/0143118757).

Đối với sự phát triển mới, đặc biệt là phát triển Agile:

"Sự hoàn hảo đạt được, không phải khi không còn gì để thêm, mà là khi không còn gì để lấy đi." - Antoine de Saint-Exuper

Nếu bạn đang ước tính nỗ lực và thời gian để sửa một số lỗi gần như không thể tái tạo (s) trong một hệ thống cực kỳ phức tạp với rất ít nhà phát triển không có kiến ​​thức về hệ thống thân mật thì câu trả lời đúng duy nhất là "Khi nó được sửa."

Thông thường, tôi sẽ chỉ nói với họ sự thật. Tôi sẽ nói với họ rằng họ không biết ngay bây giờ và tôi có thể có cái nhìn sâu sắc hơn trong một tuần. Sau đó tôi sẽ đưa cho họ một công viên bóng với nhiều tiếng cười khúc khích trước mặt bạn để bạn có thể đặt lên tờ giấy để chỉ ra rằng đó là một phỏng đoán dựa trên cảm giác. Nếu họ bắt đầu làm khó bạn, chỉ cần bắt đầu mỗi câu với "Có thể ..." Thông thường bất cứ ai tôi làm bất cứ điều gì đều hài lòng với "Kiểm tra lại sau một tuần hoặc lâu hơn, nhưng bây giờ tất cả những gì tôi có thể nói là khoảng 2 tháng" hoặc điều tương tự.

Quy trình phần mềm cá nhân (PSP) tập trung vào việc cải thiện các ước tính. Điều này đạt được bằng cách đăng nhập kỷ luật của các nhiệm vụ. Điều này, về bản chất phần nào "tăng tốc" phần "kinh nghiệm" của việc ước tính vì bạn sẽ có dữ liệu thực tế về các nhiệm vụ điển hình. Tất nhiên, nghề này vẫn đòi hỏi các giải pháp độc đáo cho nhiều vấn đề nhưng theo kinh nghiệm của tôi, ước tính sẽ tốt hơn sau khi sử dụng PSP.