Xử lý các ước tính như một lập trình viên cơ sở

Tôi đã làm việc được vài tháng nay trong một công ty ước tính (đối với dân số nói chung, không phải là đàn em cụ thể) và sau đó chúng tôi được giao nhiệm vụ, giải quyết nó, trải qua hai bài kiểm tra và cuối cùng ước tính sẽ là phần nào gặp nhau

Tôi vượt quá căng thẳng vì một số ước tính đơn giản là không thể đáp ứng cho tôi. Tôi vẫn không biết toàn bộ hệ thống (vì nó khá đáng kể) vì vậy đôi khi tôi dành một nửa thời gian để tìm hiểu những gì tôi cần làm và ở đâu và đến khi tôi hoàn thành thì đôi khi ước tính đã kết thúc và vẫn còn thử nghiệm. thực hiện (và sửa lỗi nếu chúng là bất kỳ).

Lần thứ hai tôi phải xử lý một chức năng tương tự, tất cả đều hoạt động nhanh hơn nhiều, nhưng cho đến nay tôi cảm thấy mình chỉ kém về lập trình.

Có điều gì bạn đã làm khi bạn mới bắt đầu giúp bạn vượt qua giai đoạn này không? Tôi đã rất căng thẳng khi tôi thấy có ít thời gian để viết mã đến mức đôi khi tôi thậm chí không thể tập trung chính xác vào những gì tôi đang làm khiến nó thậm chí còn tồi tệ hơn.

• Nhiều nhà phát triển có ít kinh nghiệm quản lý ước tính các nhiệm vụ bằng cách sử dụng vận tốc hoặc vận tốc của riêng họ của một nhà phát triển "tốt nhất" trong một nhóm.

• Vận tốc thay đổi theo kinh nghiệm. Nhà phát triển cao cấp có thể mất 3 giờ để giải quyết vấn đề gì đó, khi đó bạn sẽ mất 2 ngày làm việc để giải quyết vấn đề tương tự.

• Căng thẳng có thể hiếm khi tránh được khi bạn nhận một công việc mới. Sau vài tháng, nó sẽ trở nên tốt hơn, giả sử bạn đặt đủ công việc và hỏi nhiều câu hỏi liên quan.

• Người cao niên của bạn có thể không nhận thức được bạn cảm thấy thế nào về các ước tính, do đó, điều quan trọng là bạn hỏi họ những gì họ mong đợi ở bạn.

Từ kinh nghiệm của tôi:

• Tôi nghĩ rằng nhà phát triển cấp cao hoặc người quản lý sẽ có thể ước tính câu chuyện của người dùng (yêu cầu kinh doanh) về kích cỡ áo phông (XL, L, M, S, XS).

• Công việc của các nhà phát triển là chia câu chuyện của người dùng thành các nhiệm vụ nhỏ hơn và ước tính chúng. Nhiệm vụ lớn có thể khiến nhà phát triển cấp cao mất một ngày để giải quyết, khi đó có thể khiến bạn mất cả tuần.

• Điều rất quan trọng là ghi lại thời gian bạn thực sự mất bao lâu để hoàn thành nhiệm vụ.

• Quản lý dự án tốt hoặc nhà phát triển cao cấp sẽ liên tục thu thập số liệu thống kê này. Khi năng suất của bạn được cải thiện, họ sẽ nhận thức được điều đó và họ sẽ gửi thêm công việc theo cách của bạn.

Điều này không chỉ làm cho cuộc sống của bạn bớt căng thẳng mà còn cho phép bộ phận quản lý tài nguyên của họ một cách hiệu quả.

Đưa ra điều này với trưởng nhóm của bạn, người quản lý dự án và / hoặc bất cứ ai ước tính của bạn; không phải chúng tôi. Mọi người hiểu rằng mọi thứ không mất cùng một nỗ lực cho mọi người và họ có thể làm việc để điều chỉnh các ước tính khi nhiệm vụ được giao hoặc ít nhất là làm giảm bớt mọi nỗi sợ hãi của bạn về thời gian xem xét.

Theo tôi, đây là lý do mà các ước tính nên được thực hiện bởi những người được giao nhiệm vụ (với đầu vào / cộng tác từ khách hàng tiềm năng / đồng nghiệp). Bạn có được ước tính chính xác hơn cho công việc thực sự sẽ mất bao lâu để mọi người làm.

Tôi không thể tưởng tượng một vị trí tồi tệ hơn để đặt một nhà phát triển cơ sở hơn là đặt kỳ vọng rằng họ không thể giữ được, trừ khi tất nhiên họ đang làm điều đó để thách thức bạn. Bạn đã có bất kỳ hậu quả thực sự để không đáp ứng các ước tính?

Tôi muốn nói trước, điều quan trọng là bạn phải tự mình ước tính. Khi bạn được giao một nhiệm vụ, hãy lập tức ước tính nó theo những gì bạn nghĩ nó sẽ thực hiện, và sau đó bắt đầu tìm đồng bằng giữa hai. Tôi gần như có thể đặt cược rằng chất lượng đang bị hy sinh trong ước tính ngắn ban đầu. Nếu chỉ đơn giản là họ đang mong đợi bạn thiết kế và phát triển các mặt hàng nhanh hơn bạn có thể, bạn có thể cần trò chuyện với ai đó để giải quyết vấn đề.

Thứ hai, hiểu rằng chất lượng là một tính năng mà những người nắm giữ cổ phần, ông chủ của bạn, có quyền quyết định trả tiền. Nó có thể là một cái gì đó mà bạn sẽ phải hy sinh một chút để đáp ứng các yêu cầu trong thời gian bạn có.

Dù bằng cách nào, hãy loại bỏ sự căng thẳng, sẽ không có cảm giác thú vị khi tiếp tục viết mã xấu. Hi vọng điêu nay co ich.

Điều này là phổ biến.

Nói chung, tốt hơn là đưa ra các ước tính lớn hơn, nhỏ hơn (Hầu hết thời gian bạn sẽ vượt qua ước tính này). Tôi khuyên bạn nên cắt nhiệm vụ thành các nhiệm vụ nhỏ nhất có thể và ước tính chúng với mỗi nhiệm vụ không quá 4 giờ.

Nếu một nhiệm vụ có thể mất hơn 4 giờ, hãy chia nó thành một nhóm nhiệm vụ khác. Đồng thời thêm bộ đệm phần trăm cho các tác vụ bạn không thể thấy trước (sở thích cá nhân của tôi là 1 tác vụ không mong muốn cho mỗi 2 tác vụ ước tính với mỗi tác vụ không mong muốn mất 2 - 4h tùy thuộc vào hệ thống bạn đang làm việc).

Sau đó, thêm thời gian bạn nghĩ sẽ cần để thử nghiệm, giao tiếp, phân tích, v.v.

Đầu tiên: Nếu bạn trở nên nhanh hơn với mỗi lần thử vào một vấn đề, có lẽ bạn không phải là một lập trình viên tồi. Vì vậy, hãy để suy nghĩ đó ra khỏi đường đi.

Tôi sẽ đề nghị đây là thất bại của người quản lý của bạn, nhưng nó sẽ luôn luôn là công việc của bạn để quản lý kỳ vọng.

Thay vì đánh bại bản thân vì không thể đáp ứng thời hạn không thực tế, hãy đo xem bạn thực sự có thể làm bao nhiêu ngày trong một tuần. Sau đó giải thích với trưởng nhóm của bạn rằng bạn chưa quen với việc phát triển phần mềm và kinh doanh và bạn chỉ có thể được mong đợi có được n ngày làm việc của nhà phát triển cấp cao trong một tuần tiêu chuẩn. Họ ít nhất nên hiểu điều này, ngay cả khi họ không thích nó.

Nói với họ rằng bạn sẽ tiếp tục cải thiện và chỉ cho họ cách bạn có thể đo lường sự cải thiện đó. Và đồng ý với họ rằng bạn không mong đợi mức lương của cấp cao cho đến khi bạn có thể thực hiện 5 ngày làm việc của nhà phát triển cấp cao trong một tuần. Nhưng tương tự như vậy, bạn không mong đợi các trách nhiệm tương tự như một cấp cao khi bạn không được trả gần như nhiều.

Để hiểu rõ hơn, đây là lý do tại sao tôi là người ủng hộ mạnh mẽ việc sử dụng điểm câu chuyện thay vì hàng giờ để ước tính. I E. Mỗi công việc được một số điểm và nhóm ước tính có bao nhiêu điểm họ có thể đạt được trong một khoảng thời gian nhất định. Khoảng thời gian sau, ước tính giống như thực tế từ giai đoạn trước, được điều chỉnh cho các yếu tố đã biết như tháng nghỉ lễ nặng hoặc nhà phát triển rời đi.

Là người quản lý, khi một nhà phát triển mới xuất hiện (cấp cơ sở hoặc cấp cao), tôi nói rõ với doanh nghiệp rằng chúng tôi sẽ không tăng ước tính trong trường hợp đầu tiên. Nhà phát triển đó dự kiến ​​sẽ chiếm nhiều thời gian từ các nhà phát triển khác khi họ tiết kiệm. Nhà phát triển mới có thể sẽ làm tốt hơn thế, nhưng hứa hẹn và cung cấp quá mức là câu thần chú.

Nhà phát triển sẽ cải thiện theo thời gian, cấp cao nhanh hơn đàn em và "vận tốc" của nhóm - tháng ước tính theo tháng - sẽ cải thiện cùng với nó.

Giữ bình tĩnh và tiếp tục. Nếu vấn đề bạn không đáp ứng các ước tính đã được đưa ra, chỉ cần nói với họ những điều tương tự những gì bạn đã viết trong bài đăng của bạn, hoặc nếu bạn cảm thấy không an toàn, hãy tự mình nói về vấn đề này với người cố vấn / nhóm của bạn.

Ước tính chỉ có vậy, ước tính. Chúng có thể và sẽ tắt, hơn nữa khi bạn học các sợi dây. Và với tư cách là một thiếu niên, có khả năng bạn đang học các sợi dây với tư cách là thành viên nhóm trong dự án cụ thể đó, với tư cách là một lập trình viên sử dụng bất kỳ công nghệ nào bạn đang sử dụng và làm nhân viên tại công ty của bạn. Và nếu bạn đang làm việc với những người nhạy cảm, họ sẽ hy vọng rằng bạn sẽ không hài lòng với các ước tính.

Bạn có thể đang xem xét các nhiệm vụ bạn nhận được "từ dưới lên". Nhiệm vụ của bạn quan trọng với bạn hơn bức tranh lớn của dự án bạn đang thực hiện - đó là điều dễ hiểu. Bạn thấy các ước tính là những hạn chế đặt ra cho bạn và rõ ràng là đang lo lắng khi bạn không gặp chúng.

Nhưng khi bạn nhìn vào bức tranh lớn, bạn sẽ thấy các ước tính đó, thậm chí nhiều hơn 'mục tiêu' cho các nhà phát triển, là 'tín hiệu' cho các nhà quản lý dự án / dự án. Chia công việc thành các nhiệm vụ và ước tính chúng là một cách để giảm sự phức tạp của việc quản lý và ước tính toàn bộ dự án. Theo dõi công việc thực tế được thực hiện so với ước tính là một phương tiện để theo dõi cách thức thực hiện dự án, nhưng đó chỉ là một trong những số liệu có thể được áp dụng. Khi các ước tính không được đáp ứng một cách thường xuyên, đó là một tín hiệu cho người quản lý rằng có điều gì đó không ổn với dự án. Nhưng trong bất kỳ dự án hợp lý nào, sẽ không có thực tế là có một nhà phát triển cơ sở trong nhóm không đáp ứng các ước tính.

Hãy để tôi giới thiệu bạn với hai người bạn của tôi, WAG và SWAG

Tức là, 'Đoán hoang dã' và 'Đoán hoang dã khoa học'

Dù bạn có tin hay không thì tôi cũng không làm được. Chúng thực sự khá phổ biến trong kinh doanh. Hãy xem bài viết này để xem những gì tôi muốn nói.

Lý tưởng nhất, tốt nhất là đưa ra một ước tính chắc chắn nhưng nếu bạn không thể, tốt hơn là nói rằng ước tính đó là thô do dữ liệu không đầy đủ hơn là nói dối.

Điều quan trọng là, kinh doanh không phải là lập trình máy tính. Quản lý kỳ vọng quan trọng hơn độ chính xác. Điều quan trọng là phải đánh giá thời gian bạn nghĩ sẽ mất thêm 10% như một sự dự phòng để bù đắp cho bất kỳ vấn đề không lường trước được.

Nếu bạn đánh giá quá cao, họ sẽ rất vui khi bạn kết thúc với thời gian rảnh rỗi. Nếu bạn đánh giá thấp, họ sẽ không thất vọng nếu bạn đáp ứng thời hạn hoặc cực kỳ thất vọng nếu có sự cố xảy ra.

Kinh doanh là một lĩnh vực màu xám mà một số người có được cảm giác trực quan theo thời gian. Thực tế là họ đang yêu cầu một nhà phát triển cơ sở đưa ra các loại quyết định này một cách độc lập nói lên một điều. Hoặc là họ không có ai sẵn sàng, những người có khả năng đưa ra những quyết định như vậy hoặc người quản lý không muốn chịu trách nhiệm về những thất bại.

Tôi sẽ đặt tiền của mình vào sau nếu bạn đang làm việc cho một tổ chức lớn. Khi một mô hình kinh doanh phân cấp phát triển đủ lớn, đỉnh cao sẽ bị loại bỏ khỏi đáy đến mức những người cấp cao hơn chỉ có thể đo lường tiến độ bằng những gì họ nhận được trên giấy. Đó là một môi trường tồi tệ vì các chương trình khuyến mãi thường được đưa ra để không phạm sai lầm. Nhưng những người nhận được các chương trình khuyến mãi tránh thất bại bằng cách đẩy trách nhiệm của họ lên người khác (tức là không đủ năng lực mù quáng) và lấy tín dụng cho những thành công của những người thấp hơn trong chuỗi.

Thật không may, các lập trình viên là những mục tiêu dễ dàng ném 'dưới xe buýt' vì dù vấn đề có lớn đến đâu, chúng tôi sẽ cố gắng tìm giải pháp. Điều quan trọng là, đừng dành nhiều thời gian để xác định cách ước tính vấn đề hơn là bạn thực hiện giải pháp.

Đó là một nơi khó khăn. Âm thanh như bạn bị mắc kẹt trong giai đoạn "chỉ phải cung cấp" của đường ống đó.

Trong những năm qua, tôi đã nhận thấy những điều sau đây về ước tính: Chất lượng của một ước tính có thể được xác định bằng cách trả lời (với một tên thích hợp) ba câu hỏi sau đây.

• Ai làm thiết kế?
• Ai lập dự toán?
• Ai đang thực hiện?

Chất lượng của ước tính tỷ lệ nghịch với số lượng cá thể riêng biệt được đặt tên. Ví dụ: ước tính tốt nhất là khi cùng một người đã thực hiện cả ba nhiệm vụ trên, ước tính yếu là khi một người thực hiện thiết kế / ước tính và người khác sẽ thực hiện và ước tính tồi nhất là một trong đó cả ba câu hỏi được trả lời một cái tên độc đáo