Làm thế nào tôi có thể khiến sếp (hoặc đồng nghiệp) cẩn thận hơn khi ước tính mức độ phức tạp của một nhiệm vụ / dự án?

Tôi là một nhà phát triển phần mềm và tôi làm việc trong một công ty phát triển web nhỏ. Nó dường như là một chủ đề định kỳ mà một người quản lý cấp trung sẽ hỏi tôi điều gì sẽ mất bao lâu và khi tôi đưa cho họ ước tính của mình, họ nghĩ rằng nó quá cao. Nếu đó là một người quản lý kỹ thuật hoặc nhà phát triển khác, họ thường sẽ có một ước tính của riêng họ và bắt đầu cố gắng thực hiện nó theo cách riêng của họ vì họ nghĩ rằng họ có thể làm điều đó nhanh hơn.

Tuy nhiên, có một xu hướng, nơi các nhà phát triển khác đã kết thúc bằng cách sử dụng thời gian nhiều hơn đáng kể so với họ đã trích dẫn. Họ sẽ nhận được một nửa ngân sách của mình, sau đó nhận ra rằng có một số nhu cầu kinh doanh mà kế hoạch thực hiện của họ không thể giải quyết đúng đắn. Nhiều lần hơn không, kế hoạch của tôi sẽ giải quyết nhu cầu này, nhưng nó đã bị loại bỏ vì tính năng " Bạn sẽ không cần nó ".

Tệ hơn nữa, khi họ va vào bức tường này, họ thường sẽ đến gặp tôi để giúp họ thoát khỏi góc mà họ đã tự vẽ, nhưng chỉ có rất nhiều giờ trong ngày của tôi.

Trường hợp tốt nhất : Những gián đoạn này cắt giảm thời gian mà tôi đã phân bổ cho công việc phát triển của riêng mình, dẫn đến các dự án khác bị trì hoãn hoặc tôi phải làm thêm giờ vì tôi là "người duy nhất có thể làm X".

Trường hợp xấu nhất : Cuối cùng tôi phải đảm nhận nhiệm vụ / dự án là của riêng tôi và đến thời điểm đó, ngân sách không còn thời gian để tôi thực hiện theo cách của mình. Tôi phải cố gắng hoàn thành những gì họ bắt đầu theo cách họ bắt đầu, vì vậy "công ty không mất thêm tiền". Điều này luôn quay trở lại để cắn tôi bởi vì sau đó nó trở thành mã hack "của tôi" và khi nó phá vỡ mọi người hỏi tôi tại sao nó được tạo ra theo cách đó (sau tất cả, họ không biết ai thực sự tạo ra nó.)

Vì vậy, câu hỏi của tôi là : Làm thế nào tôi có thể giúp những đồng nghiệp này hiểu khi mọi thứ không đơn giản như họ đang hình dung và họ cần đánh giá lại sự hiểu biết của họ về nhu cầu của khách hàng?

Không giống như câu hỏi tương tự về quản lý thuyết phục để xử lý nợ kỹ thuật [hiện tại] , câu hỏi của tôi tìm kiếm các chiến lược giúp nhóm nhận ra [chủ động] trước khi chúng sắp phát sinh nợ kỹ thuật, trong nỗ lực ngăn chặn nó bắt đầu. Hai điều này song hành với nhau, nhưng chúng khác biệt rõ rệt trong suy nghĩ của tôi. Các câu trả lời của câu hỏi khác đề nghị thêm thời gian tái cấu trúc vào các ước tính cho các tính năng trong tương lai. Điều này không bao giờ có thể hoạt động nếu các nhà phát triển khác (và do đó là các nhà quản lý) luôn nghĩ rằng tính năng trong tương lai sẽ mất ít thời gian hơn so với thực tế và tôi không thể thuyết phục họ rằng ước tính của tôi là thực tế hơn.

Tôi thích câu hỏi này bởi vì mỗi ngày tôi đều phải đối mặt với việc đưa ra một ước tính mới hoặc chịu đựng một ước tính trước đó.

Câu trả lời phụ thuộc vào mức độ lớn của một dự án / nhiệm vụ mà bạn đang nói đến. Có sách và phương pháp để xử lý các ước tính. Dự án dự án cho nhóm phát triển 50 người với ngân sách 1 triệu có cách tiếp cận khác với làm việc trên các dự án nhỏ '80 giờ '- đây là một số điểm' đời thực 'cho sau này:

• Ước tính "Từ dưới lên" - Bạn có thể chia nhỏ các nhiệm vụ càng nhỏ, ước tính của bạn càng tốt. Bạn có thể ước tính các phần nhỏ hơn một cách độc lập có lợi ích bổ sung trong việc xác định các hàm bị thiếu. Giả sử bạn đang trao các bản nháp của một trang web và được yêu cầu ước tính. Đừng đi theo số lượng trang, đi theo số lượng tính năng. Ví dụ: giỏ hàng có thể là '1 trang', nhưng có thể được tạo thành từ 10 tính năng khác nhau.

• Ước tính "Ba điểm" có nghĩa là thực hiện ba ước tính dưới dạng phạm vi. Sau đó, bạn có thể trả lời với "40-80 giờ, tùy thuộc vào mức độ phức tạp của các tính năng xxx." Đây là một cách tốt để giới thiệu rủi ro trong ước tính của bạn. Bạn cũng nên lấy ước tính từ những người khác trong nhóm của mình để nếu ai đó nói 50 giờ và ai đó nói 100 giờ, bạn có thể thảo luận về sự khác biệt.

• Đáp ứng Ngân sách / aka Đặt kỳ vọng - Nếu bạn biết ngân sách dành cho 100 giờ và bạn nghĩ đó là dự án 200 giờ, bạn có thể giúp đặt kỳ vọng trước khi bạn cam kết. "Mọi thứ bạn yêu cầu là một dự án 200 giờ; nếu chúng tôi giới hạn tính năng-x, chúng tôi có thể thực hiện trong 100 giờ".

• Thời gian phát triển so với thời gian thử nghiệm so với thời gian dự án so với thời gian lịch - Tất cả đều khác nhau và nếu bạn là một nhóm, thật dễ dàng để kết hợp tất cả lại với nhau. Nếu bạn cần dành 8 giờ để tìm ra các yêu cầu, sau đó 72 giờ thời gian phát triển, bạn sẽ mất nhiều thời gian hơn 2 tuần để hoàn thành dự án. Đặc biệt nếu bạn cần cân bằng các nhiệm vụ khác, tương tác với một nhóm, chờ đợi khách hàng hoặc dành hàng giờ để viết qua email. Trong trường hợp này, hãy nói với sếp của bạn "100 giờ, đó là x giờ của thời gian phát triển, giờ làm việc với khách hàng và z giờ hỗ trợ ban đầu." Điều này sẽ giúp hiển thị rằng bạn bao gồm cả thời gian ngoài mã của bạn.

QUAN TRỌNG - Tôi không nghĩ ước tính là vấn đề chính của bạn, tôi nghĩ giao tiếp bên ngoài và bên trong là. Nếu tính năng X rất quan trọng, thì khách hàng nên đã truyền đạt nó ngay từ đầu. Khi yêu cầu được đưa ra cho tính năng X, người quản lý dự án của bạn sẽ nói rằng "nó nằm ngoài phạm vi nhưng chúng tôi có thể phân bổ lại giờ hiện tại hoặc mở rộng ngân sách".

Trong nội bộ, bạn cần thực hiện giao tiếp để những người cấp cao của bạn nhận thức được rằng bạn vượt quá ngân sách / lịch trình tốt trước khi "quá muộn". Khi một nhiệm vụ được giao cho bạn, bạn nên biết thời gian (như tính theo giờ) và thời gian (như trên lịch) mà bạn phải thực hiện nhiệm vụ đó. Nếu tác vụ không phù hợp với những ràng buộc đó, thì bạn cần phải làm cho họ biết - "Tính năng A & B sẽ yêu cầu tôi thực hiện C. Điều này sẽ không để lại thời gian cho X hoặc Y".

Không có gì ngạc nhiên - Bạn cũng cần đảm bảo rằng bạn sẽ liên lạc lại với dự án. Hãy chắc chắn để báo cáo những thứ tốt, nhưng nếu một cái gì đó mất nhiều thời gian hơn dự kiến, hãy chắc chắn rằng bạn nói như vậy ngay lập tức. Năm mươi phần trăm của dự án có trách nhiệm nói:

"Tính năng X khiến tôi mất nhiều thời gian hơn dự kiến, tôi có thể không nhận được tính năng Y".

Vào ngày đáo hạn, không có trách nhiệm nói:

"Tôi không làm tính năng Y vì tôi hết thời gian"

MOMEMNT CÁ NHÂN - Tất cả có thể thực sự khó khăn khi các nhà quản lý vẫn muốn giữ lập trình viên và khi mọi người muốn làm hài lòng khách hàng.

Làm tốt và làm cho nó được biết đến.

Nếu bạn phải khắc phục vấn đề của người khác vì họ không lắng nghe những gì bạn nói trước đó hoặc vì họ quá thiếu kinh nghiệm để hiểu những gì bạn đã nói với họ, hãy chắc chắn rằng những người đó và sếp của bạn biết lý do là gì khi mong đợi khung thời gian đã bị bỏ lỡ, và loại thất bại kế hoạch đã được thực hiện. Và hãy kiên nhẫn, nếu đồng nghiệp của bạn không hoàn toàn chống lại việc học hỏi từ những sai lầm, tình huống có thể sẽ trở nên tốt hơn theo thời gian.