Đặt kỳ vọng thực tế cho thời hạn


15

Tôi là một nhà lãnh đạo công nghệ cho một nhóm nhỏ. Một trong những nhiệm vụ chính trên đĩa của tôi là giao tiếp với khách hàng. Một điều tôi cảm thấy đặc biệt khó khăn là xử lý thời hạn vì chúng được khách hàng ủy quyền và tôi thường không được hỏi ý kiến.

Thông thường, sự tương tác theo mô hình sau. Khách hàng đưa ra một tính năng mà họ muốn thêm, Tính năng X. Tính năng X sẽ có vẻ tốt trong bản phát hành ứng dụng vào tuần tới, cách đó khoảng 6 ngày làm việc. Tại thời điểm này, yêu cầu tính năng cần phải được phê duyệt và thường xuyên có các phụ thuộc khác cần được giải quyết. Cuối cùng, N ngày sau, yêu cầu tính năng nhỏ giọt xuống đội của tôi. Ngay cả khi dòng chết ban đầu (được đặt bởi người quản lý không phải là nhà phát triển) có thể đạt được thì nó vẫn không còn nữa. Đội của tôi bị đổ lỗi, cảm thấy nản lòng và có một bầu không khí thất bại chung , tôi cảm thấy nản lòng và bị đánh bại.

Rõ ràng quá trình tổng thể bị phá vỡ. Thật không may, tôi không thể làm gì nhiều vì tôi không ở vị trí quyền lực ở đây. Cách tiếp cận hiện tại của tôi là nhẹ nhàng nhắc nhở khách hàng về ngày bắt đầu của chúng tôi so với thời hạn, phạm vi của Tính năng, v.v ... Điều này cảm thấy rất giống như tôi đang kiếm cớ.

Các bạn đã ở trong tình huống tương tự? Điều gì đã / chưa làm việc cho bạn?


13
Rời khỏi. Bạn không thể thắng. Quản lý của bạn không bảo vệ bạn, do đó họ không quan tâm đến bạn. Rời khỏi.
Christopher Mahan

4
"Điều này cảm thấy rất giống như tôi đang kiếm cớ."? Tại sao? Sự thật là sự thật. Bạn "xin lỗi" là gì?
S.Lott

Chúng tôi không làm việc trong một hộp đen. Khi nhóm bị rối loạn chức năng, chỉ có rất nhiều nhà phát triển thấp kém có thể làm được.
P.Brian.Mackey

2
@EightyEight: Kỹ thuật "xếp hàng" không làm rõ bất cứ điều gì. Đó là bạn hoặc nhóm (hoặc có thể cả hai). Nhưng một dòng không giúp ai hiểu câu hỏi của bạn là gì . Bạn có thể xóa những thứ không đúng hoặc không liên quan.
S.Lott

Câu trả lời:


13

Bạn thực sự cần nói chuyện với sếp của bạn về điều này và đặt ra một số quy tắc cơ bản:

  • Hạn chót không phải là hạn chót trừ khi bạn cam kết với nó.
  • Ước tính không phải là ước tính trừ khi bạn đưa ra, và sau đó nó là "ước tính" không phải là thời hạn cuối cùng.

Clean Coder của Robert Martin có một chương thực sự hay về cách truyền đạt nội dung này đến sếp của bạn. Đó không phải là lỗi của bạn nếu đội ngũ bán hàng đang thực hiện các cam kết không thể.

Khi bạn nhận được một tính năng mới, bạn ước tính nó và sử dụng PERT để bạn có phân phối xác suất. "Tôi sẽ hoàn thành nó trong 4 ngày nhưng có thể mất tới 8". Giữ vững lập trường của bạn. KHÔNG BAO GIỜ đàm phán ước tính với nhân viên bán hàng, cuối cùng bạn sẽ cam kết điều không thể.

Sau một vài lần lặp lại, nhân viên bán hàng hy vọng sẽ chán ngấy việc bị coi là một kẻ ngốc và sẽ điều chỉnh hành vi thành "Tôi sẽ kiểm tra với nhóm phát triển và xem khi nào chúng tôi có thể hoàn thành công việc đó" chứ không phải là một lời hứa rằng bạn sẽ kết thúc phá vỡ.


1
+1 - nhà phát triển / người biết những gì thực sự liên quan đến việc không tham gia vào ước tính sẽ hét lên điên cuồng điên rồ: /
elwyn

2
'... một lời hứa cuối cùng bạn sẽ phá vỡ.' - Không bao giờ quên và thường xuyên nhắc nhở những người bạn không thể thực hiện lời hứa mà bạn không thực hiện, bao gồm cả những lời hứa thay cho bạn.
mattnz

"Hạn chót không phải là hạn chót trừ khi bạn cam kết với nó." Tôi thích nó đến nỗi tôi chỉ tweet nó. ;)
Bob Horn

10

Các bạn đã ở trong tình huống tương tự? Điều gì đã / chưa làm việc cho bạn?

Chủ yếu là những gì làm việc là nói sự thật với sức mạnh.

Thu thập các sự kiện. Trình bày sự thật. Để khách hàng học (hoặc không học) theo tốc độ của riêng họ.

Đội của tôi bị đổ lỗi, cảm thấy nản lòng và có một bầu không khí thất bại chung.

Tại sao nhóm của bạn nhận thức được sự đổ lỗi? Nếu khách hàng bỏ qua bạn và nói chuyện trực tiếp với nhóm, bạn sẽ không hiệu quả và cần tìm hiểu tại sao.

Nhóm của bạn nên thờ ơ với "đổ lỗi" hoặc thiếu trách nhiệm. Họ chỉ nên xây dựng phần mềm và bạn chỉ nên truyền đạt cho khách hàng những gì bạn đang làm và khi bạn đang làm điều đó.

Khách hàng nên --- cuối cùng --- phát triển để hiểu quy trình. Cần rất nhiều sự lặp đi lặp lại để phá vỡ những thói quen xấu. Một thỏa thuận tuyệt vời.


+1 "nói sự thật với sức mạnh." Bạn có thể làm rõ? . Tôi như "không biết gì về '' tuyên bố đổ lỗi Tôi ước gì có thể tìm một công ty ngừng tất cả các ngón tay trỏ mindless.
P.Brian.Mackey

"Thu thập các sự kiện. Trình bày sự thật". Tôi nghĩ rằng đó là rõ ràng. Người ta có thể nói gì hơn nữa?
S.Lott

Tôi nghĩ rằng tôi nhận được nó ngay bây giờ. Tôi chỉ chưa bao giờ nghe thuật ngữ đó trước đây.
P.Brian.Mackey

3
"Dừng tất cả các ngón tay vô tâm chỉ". Nó không thể dừng lại. Nhưng vai trò của một người lãnh đạo nhóm là che chắn cho đội khỏi sự tồi tệ nhất của nó.
S.Lott

Khách hàng không nói chuyện trực tiếp với các thành viên trong nhóm của tôi nhưng sự không hài lòng với công việc của một người có xu hướng lọc xuống bất kể điều gì. Có lẽ tôi nên thay thế "tôi" cho "đội". Âm thanh như tôi đang đi đúng hướng. Cảm ơn ý kiến ​​của bạn.
EightyEight

5

Tôi đã ở trong tình huống chính xác này và nó thật dễ chịu. Tuy nhiên, một cách tiếp cận tôi đã làm là tỉ mỉ giữ một bản ghi công việc hiện đang được phát triển. Khi các nhiệm vụ xuất hiện, bạn nhắc nhở khách hàng, quản lý hoặc quản lý dự án rằng các công việc khác sẽ bị trượt vì điều này đã trở thành ưu tiên của họ (đôi khi điều đó có thể khiến họ đoán lần thứ hai và sau đó bạn tiếp tục đẩy dài thời hạn).

Mặt khác, tôi đoán bạn cần phải cố gắng và tiếp tục rèn cái đục vào bức tường đá đó là người quản lý dự án / khách hàng / quản lý / nhân viên bán hàng đang giao dịch với khách hàng và đồng ý với các thời hạn này. Tôi thường nhấn mạnh rằng nếu họ đồng ý rằng sẽ mất 5 ngày để làm, thì rõ ràng họ đang nói về 5 ngày phát triển, nghĩa là phải mất 5 ngày kể từ khi bạn nhận được (không phải khi họ cúp điện thoại với nhau và sau đó chi tiêu hai ngày tiếp theo soạn thảo một tài liệu từ ưa thích).

Tuy nhiên, vì bạn là người dẫn đầu sự phát triển nên bất kỳ quyết định nào như điều này đều không liên quan nếu không được hỏi ý kiến ​​bạn ngay từ đầu.

Bạn cũng cần cố gắng và che chở nhóm của bạn khỏi điều này càng nhiều càng tốt. Mặc dù khó khăn nhưng họ cần phải tránh xa chính trị khách hàng / quản lý càng nhiều càng tốt. Nếu đây không phải là trường hợp, cần thêm búa đầu.

Về cơ bản, tôi không thích điều đó và dù tôi có vất vả thế nào thì quá trình cũng không trở nên hoàn hảo. Tuy nhiên tôi đã xoay sở để cải thiện mọi thứ.


3

Điều duy nhất bạn có thể làm là nói chuyện với khách hàng. Chỉ cần mô tả những gì xảy ra khi bạn nhìn thấy nó, mô tả tất cả các rủi ro và vv. Tôi đã có một tình huống tương tự và tôi thực sự nổi điên. Ngay cả bây giờ, khi tôi chịu trách nhiệm cho tất cả các ước tính kỹ thuật, tôi thường nghe thấy - chúng tôi muốn nó được thực hiện vào thứ Hai. Tôi chỉ nói - bạn sẽ không nhận được nó, hãy thảo luận chính xác những gì bạn muốn có vào thứ Hai, và sau đó thường có vẻ như tất cả các tính năng quan trọng đều khá dễ thực hiện và thứ Hai hoàn toàn tốt. Tất cả các tính năng khác sau đó được lên lịch để phát hành sau.

Vấn đề là - khách hàng chủ yếu biết giá trị kinh doanh cho tính năng này, nhưng không nhận ra sự phức tạp của nó. Chỉ cần thảo luận và làm rõ. Luôn luôn.


Không bao giờ chấp nhận thời hạn "... vào thứ Hai". Điều đó chỉ có nghĩa là các nhà phát triển sẽ dành tiền mã hóa vào cuối tuần nếu shit gặp fan. Sử dụng Thứ Sáu là hạn chót hoặc tốt hơn là Thứ Tư.
sbi

2

Đó là một khởi đầu tốt khi bạn nhắc nhở khách hàng rằng ngày bắt đầu của bạn muộn hơn ngày họ yêu cầu tính năng. Bạn cũng cần nói chuyện với bất cứ ai nói chuyện ban đầu với khách hàng để biết chi tiết về tính năng này để họ có thể nói với khách hàng vào thời điểm nào là thời hạn tốt hơn. Vì bạn đã liên lạc với khách hàng, bạn chỉ có thể nói "vậy ai là người trong Phòng Y đã đồng ý với thời hạn này?"

Nếu họ sẽ không cho bạn tham gia các cuộc đàm phán hoặc họ bảo bạn im lặng và thực hiện đúng thời hạn mà họ đồng ý, bạn có thể nhắc nhở họ rằng sẽ tốt hơn cho cả công ty nếu nhóm của bạn đúng giờ và đúng cách để đạt được điều đó là nhận được đầu vào của bạn vào thời hạn.


2

Sửa lỗi luồng thông tin.

  • Nếu bạn có nghĩa vụ liên lạc với khách hàng, hãy buộc tất cả các bên liên quan của dự án (bao gồm cả khách hàng) luôn luôn giao tiếp với bạn .

Đáng buồn thay, quyền lực chủ yếu là do chính bạn lấy chứ không phải do người khác trao cho bạn.


1
Vâng, giống như điều đó sẽ xảy ra. Mặc dù, nếu bạn làm điều đó, bạn có thể sẽ bị sa thải và nhận được sự tôn trọng từ một số người bạn làm việc cùng, và từ một số khách hàng (những người có lẽ cũng bị bệnh và mệt mỏi với quản lý công ty của bạn).
Christopher Mahan

2

Một trong những nhiệm vụ chính trên đĩa của tôi là giao tiếp với khách hàng. Một điều tôi cảm thấy đặc biệt khó khăn là xử lý thời hạn vì chúng được khách hàng ủy quyền và tôi thường không được hỏi ý kiến.

Nếu bạn phải có trách nhiệm liên lạc với khách hàng, tại sao bạn không được tư vấn về lập lịch (và lập ngân sách) để bạn có thể truyền đạt thông tin này giữa những người chịu trách nhiệm cho họ trong tổ chức của bạn và đối tác của họ ở phía khách hàng? Tôi nghĩ rằng việc khắc phục vấn đề này sẽ mang lại lợi ích rất lớn cho bạn, nhóm của bạn và dự án của bạn.

Khách hàng đưa ra một tính năng mà họ muốn thêm, Tính năng X. Tính năng X sẽ có vẻ tốt trong bản phát hành ứng dụng vào tuần tới, cách đó khoảng 6 ngày làm việc. Tại thời điểm này, yêu cầu tính năng cần phải được phê duyệt và thường xuyên có các phụ thuộc khác cần được giải quyết. Cuối cùng, N ngày sau, yêu cầu tính năng nhỏ giọt xuống đội của tôi. Ngay cả khi dòng chết ban đầu (được đặt bởi người quản lý không phải là nhà phát triển) có thể đạt được thì nó vẫn không còn nữa.

Hệ thống này để lập kế hoạch có vẻ kỳ lạ, để nói rằng ít nhất.

Theo kinh nghiệm của tôi, khách hàng ký vào một bản phát hành cụ thể. Họ có thể gửi danh sách các tính năng và thay đổi họ muốn và khi nào họ muốn, sau đó đàm phán với nhóm xây dựng phần mềm. Hoặc họ có thể đưa ra một danh sách các tính năng ưu tiên cho nhóm phát triển và nhóm phát triển cung cấp các ước tính khi nào họ có thể gửi các bộ tính năng khác nhau. Có những biến thể khác.

Nhưng một điều tôi chưa bao giờ thấy được cho phép là một khách hàng có thể thay đổi bản phát hành quá muộn trong trò chơi, đặc biệt là không phải là một tuần kể từ khi phát hành. Điều đó dường như không đúng khi đặt các nhà thiết kế, nhà phát triển và người thử nghiệm dưới áp lực đó. Nếu bạn đang thực hiện phát triển lặp lại, nếu đó là một tính năng ưu tiên cao, chỉ cần đảm bảo thêm nó vào hình thức tồn đọng và mang nó ngay khi bạn có thể. Nếu đó không phải là một tính năng ưu tiên cao, họ chắc chắn không cần nó trong phiên bản này và có thể đợi đến lần tiếp theo.

Tôi sẽ khuyên bạn nên thiết lập một số quy tắc cơ bản phù hợp với các nhóm thiết kế, phát triển, thử nghiệm và phân phối cũng như khách hàng của bạn để làm nổi bật việc đóng băng, đóng băng mã và giao hàng. Đặt những điều này bằng văn bản, nhận được cam kết từ mọi người, và tuân thủ nó. Nếu bạn nhúc nhích một lần, bạn sẽ bị bẻ cong nhiều hơn và bạn sẽ mất quyền kiểm soát quy trình.

Thật không may, tôi không thể làm gì nhiều vì tôi không ở vị trí quyền lực ở đây.

Bạn có thể không, một mình. Nhưng có vẻ như các nhà thiết kế và / hoặc nhà phát triển và / hoặc người thử nghiệm của bạn chịu nhiều áp lực phải đáp ứng lịch trình. Bạn nên ngồi lại với cấp trên như một đội và giải thích tình huống. Đầu tiên, yêu cầu tổ chức của bạn cam kết cải tiến quy trình, sau đó làm việc với khách hàng để mua hàng của họ về cách mọi thứ sẽ hoạt động.

Điều này cảm thấy rất nhiều như tôi đang làm cho lý do mặc dù.

Khi bạn bắt đầu đưa ra lời bào chữa, có lẽ đã đến lúc có một cuộc hội thoại khó khăn hoặc một cuộc trò chuyện quan trọng . Tôi muốn giới thiệu một trong hai cuốn sách đó. Đọc chúng đã giúp cải thiện kỹ năng giao tiếp của tôi, đặc biệt là khi bạn cần phải đối mặt với một tình huống khó khăn khi căng thẳng ở mọi phía.


Để giải quyết một số câu trả lời khác.

Đáng buồn thay, quyền lực chủ yếu là do chính bạn lấy chứ không phải do người khác trao cho bạn.

Tôi không biết Andrea đang đi đâu với chuyện này. Có, bạn cần sửa luồng thông tin. Nhưng bạn cần phải làm việc với các PM và khách hàng để đảm bảo rằng mọi người đều biết những gì (tôi giả sử, dù sao đi nữa) đã đồng ý khi bắt đầu dự án. Nếu sự sắp xếp, vì bất kỳ lý do gì, không hiệu quả, hãy xem lại và phân phối lại công việc và vai trò cho những người phù hợp hơn với họ.

Bạn không nắm quyền lực hay chiến đấu với sức mạnh, nhưng bạn làm việc với nó, cố gắng chế ngự nó và làm cho nó hoạt động cho tất cả mọi người.

Vấn đề là - khách hàng chủ yếu biết giá trị kinh doanh cho tính năng này, nhưng không nhận ra sự phức tạp của nó. Chỉ cần thảo luận và làm rõ. Luôn luôn.

Trích dẫn này từ loki2302 là khá nhiều điểm. Một trong những công việc của bạn với tư cách là một kỹ sư phần mềm là đảm bảo rằng những người phù hợp biết những việc như nhiệm vụ khó khăn như thế nào, sẽ mất bao lâu và những loại tùy chọn và rủi ro tồn tại khi làm việc gì đó. Là người truyền thông chính cho nhóm của bạn, truyền đạt thông tin này từ tổ chức của bạn đến khách hàng, theo lý thuyết, là công việc của bạn.


2

Tìm một diễn đàn để tiếp cận bất cứ ai đang thiết lập các thời hạn. Hãy cho họ biết rằng họ có thể tham khảo ý kiến ​​của bạn và trình bày một cái gì đó thực tế hơn. Các lựa chọn thay thế là: bạn có thể nói với khách hàng rằng điều đó sẽ không xảy ra hoặc họ có thể nói với khách hàng.

Bạn có thể trình bày nó như bạn có thể làm điều đó trong X số ngày sau khi nhóm của bạn bắt đầu làm việc với nó. Có lẽ đó là sự nhầm lẫn? Đó là một sai lầm trung thực trừ khi nó xảy ra nhiều lần. Sau đó, nó chỉ bỏ bê.

Tôi đoán rằng nhóm của bạn đã đáp ứng các thời hạn trong quá khứ.


2

Thật không may, đặc hữu của nó trong ngành công nghiệp của chúng tôi, rất nhiều cơ quan kỹ thuật số / phần mềm không biết gì về hoạt động bên trong hoặc yêu cầu của công ty họ. Nhiều người chỉ quan tâm đến tiền mặt nhanh chóng. Như nhiều người đã nói trước đây nếu bạn không cung cấp các ước tính hoặc thời hạn, sau đó thông báo cho ban quản lý. Làm thế nào có thể phân phối một phần công việc kỹ thuật theo thời gian x mà không cần ước tính từ một người kỹ thuật biết về lịch trình của nhóm phát triển.

Nếu vẫn thất bại, rời đi.


1

Đưa cho Quản lý dự án / Sếp / Khách hàng các ước tính và lịch trình có thể đạt được của bạn, yêu cầu anh ấy xác nhận kế hoạch của bạn hoặc tìm ra những gì anh ấy muốn bạn làm trước, sau đó bỏ đi - không tham gia hoặc giải trí anh ấy theo bất kỳ cách nào.
Nếu anh ta quay lại với một kế hoạch dự án không phản ánh ước tính của bạn, hãy gửi lại cho anh ta, với một tuyên bố, "Tôi không đàm phán ước tính." và bỏ đi.

Hãy chắc chắn rằng bạn có nhiều tài liệu CYA. Hãy nói rõ với mọi người liên quan rằng bạn đang giữ những tài liệu này. Tôi đã gửi email các hồ sơ như vậy đến địa chỉ email cá nhân của tôi và CC'd sếp của tôi, rất thành công.


1

Đây là một cách tiếp cận nên đi qua mang tính xây dựng thay vì chỉ ngón tay. Tôi không buộc tội bạn về điều này, chỉ nói rằng nó không chơi tốt để có cớ với người khác có lỗi bất kể sự thật của lời buộc tội.

Sau khi điều này xảy ra, hãy làm một khám nghiệm tử thi để tính thời gian thực sự mất bao lâu để hoàn thành dự án, hoặc sẽ có nếu bạn đã hoàn thành nó. Sau đó tính toán số giờ tài nguyên bạn có sẵn kể từ khi bạn có đủ thông tin và đèn xanh để làm việc với nó. Chuyển đổi những con số này thành số lượng lập trình viên bổ sung cần thiết để đáp ứng thời hạn.

Bây giờ có một cuộc trò chuyện với sếp của bạn dọc theo những dòng này:

Chúng tôi đã có X giờ làm việc giữa ngày bắt đầu dự án Y và thời hạn Z.
Dự án yêu cầu số giờ làm việc của X + C để hoàn thành.
Đã có yêu cầu quay vòng tương tự đối với các dự án khác.
Chúng tôi sẽ cần Q lập trình viên bổ sung để đạt được năng lực cần thiết để đáp ứng mong đợi.
... tất nhiên, nếu ngân sách eo hẹp, có lẽ chúng tôi có thể làm việc với Người quản lý dự án để xây dựng thêm thời gian vào ước tính của họ để chúng tôi có thể hứa hẹn và cung cấp quá mức (hãy chắc chắn sử dụng quản lý trite nói)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.