Bạn sẽ làm gì? Quá hạn về cơ bản mọi thứ và bây giờ khách hàng sẽ không nói chuyện với bạn [đã đóng]


8

Tôi đã tiếp quản một dự án khá phức tạp với tư cách là nhà phát triển / quản lý dự án và người thử nghiệm duy nhất vào năm ngoái.

Vào tháng 11 năm ngoái, đã có hạn chót cho một số chức năng mới sẽ được chuyển giao.

Hệ thống tôi tiếp quản được cho là đã sẵn sàng để sử dụng còn lâu mới sẵn sàng.

Ngồi với một trong những người dùng khách hàng của chúng tôi, ông đã đưa ra các tính năng và yêu cầu mới được yêu cầu. Mặc dù các tính năng mà họ yêu cầu đã được triển khai, ông cho rằng nó không giống với những gì họ chỉ định trong các yêu cầu.

Vì vậy, tôi phải quay lại bảng vẽ và thực hiện các thay đổi lớn cho hệ thống.

Hứa sau lời hứa, đây là lỗi của riêng tôi, tôi đã bỏ lỡ thời hạn tiếp theo vì những lý do khác nhau: kế hoạch quá lạc quan thay cho tôi, những đứa trẻ bị bệnh và nhiều vấn đề cá nhân khác.

Và cũng có những thất bại ở phía khách hàng: chỉ thử nghiệm khi tôi xem qua vai họ và cứ thế.

Hôm qua chúng tôi đã đồng ý rằng chúng tôi sẽ phát trực tiếp nếu người dùng của họ chấp thuận ứng dụng.

Tất nhiên một số vấn đề xuất hiện và hôm nay, khi tôi cố gắng gọi cho khách hàng của mình, anh ta cúp máy và không trả lời bất kỳ email nào của tôi.

Điều này thực sự làm tôi kiệt sức, thời gian và thời gian dành cho việc này vượt xa giờ làm việc bình thường và cũng gây ảnh hưởng đến gia đình tôi.

Rõ ràng có những điều trong tình huống này là cụ thể cho dự án này, nhưng tôi không nghĩ rằng mô hình tổng thể (nhiều vấn đề nhỏ, dẫn đến sự cố dự án) là không phổ biến.

Bạn sẽ làm gì trong một kịch bản tương tự?


18
Nếu họ đã trả tiền thì tôi sẽ không làm gì cả.
Pemdas

1
Tôi đã thực hiện một vài chỉnh sửa để làm cho nó chung chung hơn một chút. Có những chi tiết cụ thể ở đây áp dụng cho dự án này nhưng tôi nghĩ rằng mô hình tổng thể (nhiều vấn đề nhỏ dẫn đến thất bại chung) là rất phổ biến và là một câu hỏi hay.
Jon Hopkins

Câu trả lời:


8

EDIT: Khi đọc lại điều này nghe có vẻ hơi khắc nghiệt, nó không có nghĩa như vậy. Những điều bạn mô tả là phổ biến và thường được gây ra bởi các yếu tố hoàn toàn dễ hiểu (và sau đó trở nên trầm trọng hơn khi bạn cố gắng trở nên hữu ích). Dù sao, nếu nó đi qua là khắc nghiệt, xin lỗi, đó không phải là ngón tay trỏ, nó chỉ cố gắng nói "đây là điều dường như đã sai, và đây là cách đối phó với nó".

Điều dường như đã xảy ra từ những gì bạn đang nói là:

  • Bạn đã được giao mã để làm việc mà không phải ở trạng thái mà bạn được tin tưởng
  • Người dùng sau đó tuyên bố rằng ứng dụng không đáp ứng các yêu cầu như đã nêu
  • Các loại kế hoạch (phần lớn không thực tế) đã được thực hiện và bỏ lỡ
  • Kiểm tra không được thực hiện đúng
  • Bây giờ anh ta ném đồ chơi của mình ra khỏi xe một cách hung hăng thụ động.

Và, kết quả là dự án thất bại.

Quan điểm đầu tiên của tôi là bạn cần ngừng làm những gì bạn đã làm cho đến nay (điều này dường như được tiếp tục một cách lạc quan, giả sử rằng nếu bạn cứ tiếp tục thì mọi việc sẽ ổn thôi). Điều đó đã không làm việc trong 3 tháng qua, tại sao bạn nghĩ rằng nó sẽ đi làm bây giờ?

Về cơ bản, mỗi vấn đề này cần được giải quyết khi chúng xuất hiện, xử lý cả triệu chứng (ví dụ như thời hạn bị bỏ lỡ) và nguyên nhân gốc rễ (ví dụ như kế hoạch đã quá lạc quan). Vì điều này đã không xảy ra (không phổ biến), giờ bạn đang ở một vị trí có nhiều vấn đề cần giải quyết.

Theo kinh nghiệm của tôi khi một dự án chạy sai theo cách này, điều tốt nhất nên làm là khiến mọi người tham gia lại với nhau và thiết lập lại các yêu cầu và trách nhiệm và đồng ý lại một kế hoạch (thực tế) dựa trên những điều này, v.v.

Khách hàng của bạn cần phải:

  • Xác nhận các yêu cầu rõ ràng và rõ ràng. Đây có thể là một đặc điểm kỹ thuật, nó có thể là một danh sách các sai lệch so với những gì hiện đang được thực hiện, tuy nhiên nó phải đầy đủ và rõ ràng và được truyền đạt bằng văn bản.

  • Chấp nhận một giai đoạn thử nghiệm là của họ để quản lý vào cuối mà họ sẽ báo cáo tất cả các lỗi. Đây sẽ là những gì bạn sẽ làm việc chống lại. Có lẽ họ cũng cần phải chấp nhận rằng sẽ có ít nhất một giai đoạn thử nghiệm tiếp theo để kiểm tra lại các lỗi mà S out phát sinh từ lần đầu tiên.

Bạn cần phải:

  • Đánh giá thực tế các yêu cầu, ước tính chính xác công việc (bao gồm cả dự phòng hợp lý) và đưa ra một kế hoạch để thực hiện điều này. Điều quan trọng là chính xác. Nếu bạn nghĩ rằng nó sẽ đi xuống một cách tồi tệ thì khó khăn, hãy lên kế hoạch để làm cho mọi người hạnh phúc, điều đó không phản ánh thực tế không cung cấp phần mềm.

  • Cung cấp chống lại kế hoạch này.

Về việc liên hệ lại với khách hàng, tôi khuyên bạn nên kết hợp một cách tiếp cận được đề xuất dọc theo các dòng này, nêu rõ lý do và gửi nó cho anh ta. Ngay bây giờ anh ấy muốn biết làm thế nào mọi thứ sẽ trở nên tốt hơn và đó là những gì bạn cần phải cung cấp cho anh ấy nếu bạn sẽ xây dựng lại mối quan hệ.


1
Tôi không đồng ý với hầu hết tất cả những điều này, OP rõ ràng không thể ước tính chính xác việc phân phối, làm thế nào để thực hiện quá trình thác nước tương tự khiến họ thất bại thảm hại sẽ làm bất cứ điều gì ngoài việc dẫn đến một chu kỳ thất bại lặp đi lặp lại trong trường hợp này, họ cần đưa ra một số cách tiếp cận mới sẽ đại diện cho sự thay đổi!

@fuzzy, Rút ngắn dòng thời gian ở đây và thực hiện các bước lặp chặt chẽ, mang nó gần hơn với phong cách scrum. Câu trả lời này không thực sự giống như nó nói rằng tất cả những điều này phải được thực hiện dưới dạng một "thác nước" dài.
kẻ hèn nhát ẩn danh

Trong mọi trường hợp, hãy xem phần "kết nối mọi người lại với nhau" và đi đến thỏa thuận "mới" - bất kỳ phương pháp nào bạn quyết định sử dụng. Tôi đồng ý với việc mờ nhạt rằng thực hiện mọi việc trong các lần lặp ngắn và biến khách hàng thành "chủ sở hữu" (và là người thiết lập ưu tiên, có trách nhiệm) có lẽ là cách tốt nhất ... nhưng bạn có thể không bao giờ "thoát" mà không sa thải khách hàng .
kẻ hèn nhát ẩn danh

3
@fuzzy - Tôi tin rằng OP có thể ước tính tốt hơn nếu anh ấy thay đổi một điều - anh ấy muốn bù đắp lỗi lầm của mình bằng cách nói với khách hàng những gì họ muốn nghe hơn là sự thật. Theo kinh nghiệm của tôi, các lập trình viên lỗi lớn nhất mắc phải là trong việc xoa bóp những gì họ tin là đúng để thể hiện gần hơn những gì họ hy vọng sẽ là sự thật mà tôi khá chắc chắn là phần lớn những gì đã xảy ra ở đây.
Jon Hopkins

Tôi không nghĩ rằng "kế hoạch" được đề xuất để lập một kế hoạch là thực tế do không thể thực hiện được cho đến nay. Tôi nghĩ, "kế hoạch" nên là thay đổi quy trình, và lập kế hoạch, chúng tôi sẽ cung cấp những thứ quan trọng nhất cho bạn trong tuần này, sau đó là những điều quan trọng nhất tiếp theo vào tuần tới và khiến khách hàng chịu trách nhiệm giao hàng. Tạo ra một khối nguyên khối, đây là kế hoạch "kế hoạch" chỉ là thiết lập cho cùng một thất bại một lần nữa. Bạn nói "điều quan trọng là chính xác" Tôi không nghĩ OP có thể sống theo điều quan trọng đó, trước đây họ không thể làm được điều đó, đó là điều khiến họ bắt đầu ở đây

6

Điều tốt nhất để làm là giao tiếp cởi mở và thẳng thắn về những thất bại của chính bạn và ân cần yêu cầu được giải tỏa các nghĩa vụ của bạn.

Nó sẽ không giúp bạn hoặc khách hàng chỉ ra tất cả những thất bại của họ, và bạn sẽ cảm thấy tốt hơn mà không có nghĩa vụ treo trên bạn.

Lấy kinh nghiệm này như một lớp học đau đớn trong trường học của những cú va chạm mạnh, và chuẩn bị tốt hơn cho khách hàng tiếp theo.


Tôi thực sự thích câu trả lời của bạn và sẽ thực hiện điều này nếu thực tế tôi không phải là nhà phát triển duy nhất tại văn phòng của chúng tôi.
dùng17971

2
Tôi cho rằng bạn đã thực hiện cam kết ban đầu với khách hàng. Bạn là nhân viên hay bạn tự làm việc? Nếu bạn là nhân viên, công ty của bạn có thể có nghĩa vụ theo hợp đồng mà bạn cần phải lội qua.
John Weldon

Tôi là một nhân viên. Tôi đã không thực hiện cam kết ban đầu với khách hàng. Chỉ cần cố gắng theo dõi trên đã hứa.
dùng17971

5

Tôi đã bị mắc kẹt trong các tình huống như thế này trước đây.

Hứa sau lời hứa, đây là lỗi của riêng tôi, tôi đã bỏ lỡ thời hạn tiếp theo vì những lý do khác nhau: kế hoạch quá lạc quan thay cho tôi, những đứa trẻ bị bệnh và nhiều vấn đề cá nhân khác.

Công việc của họ cần thực hiện điều này và bạn đã thất hứa sau lời hứa. Bạn cần ngừng thực hiện những lời hứa quá lạc quan. Khi tôi ở trong những tình huống này, tôi rất khó lấy lại uy tín với khách hàng . Khi bạn làm việc trong kinh doanh, danh tiếng của bạn là vô cùng quan trọng. Nếu bạn định ước tính, bạn cần phải đánh chúng. Nếu con cái / gia đình của bạn bị bệnh trong tương lai, có ai đó giúp chăm sóc chúng như vợ / chồng hoặc gia đình khác không? Nhìn để hướng tới một tương lai "không có lý do".

Tất nhiên một số vấn đề xuất hiện và hôm nay, khi tôi cố gắng gọi cho khách hàng của mình, anh ta cúp máy và không trả lời bất kỳ email nào của tôi.

Anh ta muốn kết quả, không bào chữa. Anh cúp máy vì anh không muốn nghe một lời bào chữa nào khác. Bạn có thể làm gì để đưa dự án trở lại đúng hướng? Bạn có thể làm gì để hoàn thành dự án này? Làm thế nào bạn tham gia vào dự án này ở nơi đầu tiên?

Nếu tôi là bạn, tôi sẽ dành thời gian hôm nay để chuẩn bị tài liệu để giao dự án này cho người tiếp theo.

Hệ thống tôi tiếp quản được cho là đã sẵn sàng để sử dụng còn lâu mới sẵn sàng.

Tôi cũng đã từng ở trong những tình huống như thế này. Trong tương lai, không bao giờ dành năng lượng đáng kể để mô tả điều này cho khách hàng bởi vì nó có vẻ như bạn đang dát vàng. Tại sao anh chàng trước đó lại để nó trong tình trạng dang dở?

Và cũng có những thất bại ở phía khách hàng: chỉ thử nghiệm khi tôi xem qua vai họ và cứ thế.

Đây là một trong những phần đau đớn nhất của dự án mới nhất mà tôi bị mắc kẹt như của bạn. Chuyên gia về vấn đề này (người đã nghỉ hưu vào mùa hè này) không ghi nhận bất cứ điều gì, vì vậy hầu hết các lỗi xuất phát từ trí nhớ không hoàn hảo của tôi về các cuộc trò chuyện với anh chàng này. Thêm vào đó, anh ta đã quen với việc giữ bí mật mọi thứ để biến mình thành không thể thiếu, và thói quen đó cực kỳ khó khăn để anh ta rũ bỏ trong 2 năm cuối cùng làm việc.

Thất bại nghiêm trọng khác là không có môi trường thử nghiệm. Trong năm qua, tất cả các mã được kiểm tra đã được quảng bá trực tiếp vào sản xuất, nơi nó sẽ được QAed bởi người dùng cuối.

Tình huống cuối cùng là cơ quan liên bang này không có ngân sách để thuê bất cứ ai và tôi đã hoàn thành dự án này để cứu bạn tôi khỏi bị kiện. Cuối cùng, họ cho tôi đi (yippie!) Và sử dụng ai đó làm việc trong một dự án khác (chưa được tài trợ). Đã hơn một năm trước khi tôi tham gia, và mặc dù họ đã tăng gấp đôi ngân sách cho dự án, nhưng ngân sách đó đã bị bắn vào lúc tôi tham gia.

Đi về phía trước, bạn cần học cách làm ước tính tốt hơn. Một cái gì đó giống như cuốn nhật ký được đề nghị trong PSP ( cuốn sách ). Dự án này là một thất bại. Ngoài ra, bạn có thể muốn thảo luận mọi thứ với bạn bè cá nhân của mình, có ai trong số họ có kỹ năng và băng thông để hỗ trợ bạn trong những lần vặn vít trong tương lai như thế này không? Lần tới khi bạn vượt lên trên đầu, bạn sẽ lặp lại thất bại này hay bạn có thể làm gì để giảm thiểu thất bại vào lần tới?


Nâng cao cho cung cấp quan điểm kinh doanh của khách hàng rất tốt.
David Thornley

đây là lần đầu tiên tôi gặp rắc rối như thế này Tôi có các dự án khác mà tôi quản lý tốt và tôi đã quản lý các dự án khác nhau trong quá khứ, chưa bao giờ có bất kỳ vấn đề nào trong số này. sự khác biệt chính đối với tôi là dự án đang hoạt động mạnh mẽ này là một dự án thực sự lớn với nhiều mã và nhiều phụ thuộc và có lẽ là dự án phức tạp nhất mà tôi từng thấy trong đời.
dùng17971

3

Nếu bạn đã viết phần mềm sẽ được sử dụng / triển khai bởi khách hàng, khách hàng có trách nhiệm trả tiền cho phần mềm đó và trả lời các yêu cầu. Nghe có vẻ rất giống như khách hàng đã rửa tay về vấn đề này, vì vậy trừ khi bạn chuẩn bị ra tòa về vấn đề này, cuối cùng bạn có thể đưa người này vào chỗ ngồi.

Bạn cần phải có tài liệu, hợp đồng, yêu cầu bằng văn bản, thời hạn, giao hàng và thiếu hụt. Nếu bạn có thể cho thấy rằng bạn đã siêng năng trong việc đáp ứng hợp đồng và khách hàng thì không, thì bạn có một cái gì đó. Nếu bạn không thể thì đó chỉ là "Anh ấy nói anh ấy sẽ trả tiền cho tôi để làm điều này, vì vậy tôi đã làm điều đó, và giờ anh ấy sẽ không trả lại cuộc gọi của tôi."

Lời khuyên của tôi cho bạn là liên hệ với thư ký / trợ lý của khách hàng này / bất cứ điều gì bạn có thể để sắp xếp một cuộc gặp mặt trực tiếp với anh ấy. Đừng lãng phí thời gian của anh ấy, đừng đánh đập xung quanh bụi rậm. Nói với anh ấy rằng bạn đánh giá cao cơ hội mà anh ấy đã cung cấp cho bạn để thực hiện dự án này và bạn nhận ra rằng đã có một số thiếu sót trong kỳ vọng. Đừng che giấu vấn đề bằng những lý do hoặc lý lẽ quid-pro-quos. Họ sẽ khiến cả hai bạn tức giận trong thời gian dài và không nhận được gì cho bạn.

Hỏi khách hàng những hành động cần thiết để có được sự lăn lộn này theo cách anh ta muốn nó lăn. Xem xét khả năng của bạn, trạng thái, sẵn có, tất cả mọi thứ. Thành thật với chính mình. Bất cứ điều gì bạn đưa ra với chi phí / thời gian / vv, NHÂN ĐÔI NÓ. Nếu điều đó không nằm trong khu vực thỏa hiệp, thì bạn cần phải cắt mồi và chia cách.

Đây có lẽ là một kết luận bỏ qua vì nghe có vẻ như khách hàng khá hân hoan, nhưng nó có thể được biến thành một kinh nghiệm học tập. Có vẻ như bạn cần rất nhiều sự chuẩn bị thêm trong các vấn đề khác nhau liên quan đến các hợp đồng có tính chất này:

  1. Nhận nó bằng văn bản. Hãy ký tên. Tìm hiểu những gì khách hàng thực sự muốn, và có được nó bằng văn bản.
  2. Nếu có những thay đổi trên đường đi, hãy viết chúng thành những thay đổi trong tài liệu, yêu cầu khách hàng đọc nó và ký tên. Bao gồm bất kỳ thay đổi trong việc cung cấp, bảng thời gian, chi phí.
  3. Tìm hiểu để ước tính thời gian của bạn tốt hơn. Bạn thực sự cần phải biết bạn có thể phát triển một số loại dự án nhất định nhanh như thế nào, làm thế nào để nhận ra khách hàng khó khăn sẽ làm mất thời gian của bạn, khách hàng thiếu quan tâm sẽ lãng phí nó.
  4. Ngân sách thời gian và tài nguyên của bạn tốt hơn. Khi bạn ước tính một dự án, hãy trung thực nhất có thể với thời gian cần thiết để làm một việc gì đó. Nếu bạn không biết, hãy lấy một miếng. Dù kết quả thế nào, hãy nhân đôi nó (hoặc ít nhất là tăng nó lên một nửa). Điều này sẽ cung cấp cho bạn phòng ngọ nguậy khi phân chạm vào bộ điều biến không khí dao động.
  5. Có cho mình một khu vực làm việc yên tĩnh, không bị xáo trộn với ít phiền nhiễu hơn. Có vẻ như bạn đang làm việc ở nhà cho rất nhiều điều này. Bạn cần đối xử với thời gian này như thể bạn đang ở một văn phòng công ty. Khi bạn "ở nơi làm việc", bạn đang ở nơi làm việc. Vợ bạn không ở trong phòng khác, con bạn không ngồi trên sàn cạnh bạn la hét để được chú ý. Nếu bạn không thể đáp ứng nhu cầu làm việc cơ bản này, bạn sẽ không sẵn sàng đáp ứng mong đợi của bất kỳ ai.
  6. Học cách chọn khách hàng của bạn một cách khôn ngoan hơn. Gặp gỡ họ, quan sát hành vi của họ. Cung cấp cho họ các mẩu tin nhỏ để phản hồi và đánh giá phản ứng của họ. Những khách hàng không thể làm hài lòng là những người dễ nhận ra nhất. Bạn có thể nhận ra điều này trong bữa trưa vì không có gì sẽ ở ngay trên bàn. Những khách hàng quá khắt khe sẽ ở trên điện thoại của bạn nhiều hơn mức họ nên có. Khách hàng không phản hồi rõ ràng không quan tâm đến dịch vụ của bạn hoặc cải thiện lĩnh vực kinh doanh của họ. Những khách hàng này nên được đổ một cách lịch sự. Đừng làm điều đó một cách trẻ con, chỉ đơn giản là thẳng thắn. Tôn trọng tất cả các hợp đồng hiện có, và chỉ cần từ chối bất kỳ hợp đồng nào trong tương lai. Nói rõ lý do của bạn, "Tôi không có đủ nguồn lực để đáp ứng nhu cầu tiếp tục của bạn."
  7. Nếu đây là sự cố thường xuyên xảy ra ở phía khách hàng (không phản hồi, không thanh toán, v.v.) không thể tránh được, hãy xây dựng mối quan hệ với một công ty thu gom gần đó (họ ở khắp mọi nơi). Mở một tài khoản, kết bạn. Có một bên thứ ba có khả năng dựa vào nhịp đập là một tài nguyên rất tiện dụng cần có.
  8. Nếu bạn sẽ tham gia vào một nghề, hãy chuyên nghiệp. Không có trẻ em bị bệnh hoặc các vấn đề cá nhân trong thế giới kinh doanh. Đó là một tuyên bố lạnh lùng, nhưng đó là một sự thật. Chúng tôi không làm việc cho gấu keo và thanh kẹo, chúng tôi làm việc vì tiền.

Điều cuối cùng tôi có thể đề nghị cho tương lai là thành thật với chính mình. Nếu bạn không thể đáp ứng yêu cầu của khách hàng một cách chuyên nghiệp thì đừng cố gắng. Khi tôi gọi thợ sửa ống nước đến sửa bồn rửa bị rò rỉ của mình, tôi không muốn nghe về những đứa trẻ bị bệnh của anh ấy hoặc làm thế nào anh ấy không biết rằng việc sửa nó sẽ mất 7 giờ. Tôi muốn nó cố định. Tôi sẽ trả thêm thời gian nếu anh ta có thể cho tôi thấy rằng điều đó là cần thiết và không chỉ anh ta đang lảng vảng trong đường ống của tôi. Khách hàng của bạn có kỳ vọng. Nếu bạn hứa ngày 1 tháng 5, hãy thực hiện vào ngày 1 tháng 5. Nếu có gì đó từ khách hàng cản trở, hãy viết bằng văn bản rằng ngày đó sẽ bị đẩy lùi vì yêu cầu của khách hàng. Nhận nó bằng văn bản. Nếu đó là một cái gì đó cuối cùng của bạn, sửa chữa nó. Nếu bạn biết điều đó sẽ gây ra vấn đề và thời hạn sẽ không được đáp ứng, hãy trung thực và thừa nhận nó. Sau đó được chuẩn bị để cung cấp một giảm giá của một số loại.


Tôi nghĩ rằng điều này là khá khắc nghiệt. Mặc dù tôi đồng ý với bạn về mặt lý thuyết, nó không bao giờ rõ ràng như thế này, đặc biệt không phải khi bạn là nhà phát triển / quản lý dự án / người kiểm tra / quản lý tài khoản duy nhất trong dự án và khi mọi thứ xảy ra sẽ có ảnh hưởng trực tiếp. mặc dù những từ khó nghe tôi nghĩ đó là những gì tôi cần đọc / nghe. +1
dùng17971

@ user17971 - Nó khá khắc nghiệt. Nhưng 2 điều tôi đọc được trong câu hỏi của bạn cho thấy nó có thể cần thiết. Khách hàng đang cúp máy bạn và bạn dường như đang đưa ra lời bào chữa. Tôi đã từng ở đó. Tôi đã mất khách hàng vì những lý do tương tự, và đó là một nhà thầu có kinh nghiệm đã chữa cho tôi một số sự thẳng thắn tương tự. Tôi đã thừa hưởng rất nhiều tình huống khủng khiếp từ các nhà phát triển trước đó (cả độc lập và khi làm việc cho các công ty), và những khái niệm này đã cho tôi sự trao quyền để nạp lại tất cả.
Joel Etherton

2

Tôi đã ở trong tình huống chính xác như vậy. Tôi đã có một khách hàng muốn nhiều hơn tôi có thể cung cấp và đang thay đổi kỳ vọng mỗi tuần. Lúc đầu, đây là một công việc đơn giản nhưng rất nhiều thứ đã được giải quyết ... Tôi đã mất rất nhiều giấc ngủ và nó ảnh hưởng nặng nề đến các khía cạnh khác trong cuộc sống của tôi.

Điều tốt nhất bạn có thể làm chỉ là tắt nó đi và tiếp tục. Thất bại trong các dự án đôi khi chỉ xảy ra và tốt nhất là cả hai bên nên nhận ra các dấu hiệu và nắm bắt sớm. Một khi nó bắt đầu đi vào cuộc sống cá nhân của bạn, nó đã đi quá xa.

Học hỏi từ nó và cố gắng không lặp lại. Bạn sẽ hạnh phúc hơn.


Điều gì sẽ là cách tốt nhất để OP "tắt nó đi" để họ có thể "tiến lên" từ tình huống này?
Chris

1
"Tôi bỏ" có lẽ? Hay "Căng thẳng"? Trong tình huống của tôi, tôi đã đi với "Tôi bỏ" vì khách hàng đó rất tệ (và thực sự rẻ).
WalterJ89

1

Hỏi khách hàng những gì họ muốn. Nếu nó nằm trong hợp đồng hiện tại làm điều đó, nếu không thì đàm phán lại hợp đồng. Dù bằng cách nào, hãy đảm bảo bạn hiểu rõ về những gì khách hàng thực sự muốn trong một tài liệu mà họ đăng nhập để sau đó họ không thể nói rằng bạn đã bỏ lỡ điều gì đó muốn.


1

Yếu tố chính ở đây, như tôi thấy, là các yêu cầu không được thỏa thuận.

Tôi không biết bạn đã thanh toán như thế nào. Nếu đó là một hợp đồng giá cố định, với các yêu cầu linh hoạt, bạn có thể không có sự truy đòi. Không bao giờ ký hợp đồng khi bạn được trả số tiền X mà không có thỏa thuận chắc chắn bằng văn bản về những gì bạn phải cung cấp. Nếu bạn phải làm một cái gì đó như thế này, hãy chia dự án thành các giai đoạn và không thực hiện giai đoạn N + 1 cho đến khi giai đoạn N được ký kết (nếu không thực sự được thanh toán). Luôn xác định trách nhiệm của khách hàng cũng như của bạn.

Trong trường hợp này, người tiền nhiệm của bạn rõ ràng đã chấp nhận các yêu cầu bổ sung mà không cần đàm phán lại hợp đồng. Điều đó thật xấu. Nếu một dự án đáp ứng các yêu cầu đã thỏa thuận, việc bổ sung vào đó sẽ được đàm phán như là một phần của các thay đổi trong hợp đồng. Bạn không nhất thiết phải tính phí nhiều hơn, nhưng rõ ràng trong trường hợp này, thời hạn cần thiết phải được đặt lại.

Bạn có thể có các yêu cầu linh hoạt, miễn là bạn không có giá cố định hoặc ngày hoàn thành.

Các vấn đề ước tính của bạn là điển hình trong ngành, nhưng hãy cố gắng học hỏi từ chúng. Các vấn đề bất ngờ sẽ xuất hiện khá thường xuyên, vì vậy đừng bao giờ đưa ra bất kỳ con số nào về ước tính trường hợp tốt nhất.


Tôi đã cố gắng để họ đồng ý với một hợp đồng khi tôi tiếp quản dự án nhưng họ từ chối chấp nhận điều này dựa trên việc họ đã tạo ra danh sách này. Vài tuần sau tôi tìm thấy danh sách này trong một bảng excel. Yêu cầu rất rất mơ hồ / không xác định. Tôi rất tiếc mỗi ngày rằng tôi đã không đứng vững trước nhiều niềm tin và cách thức quản lý dự án của mình đối với khách hàng này.
dùng17971

1

Bạn cần một quy trình tốt hơn , đặc biệt là Phương pháp Agile, SCRUM, cung cấp tính minh bạch tốt hơn, bắt buộc tương tác với khách hàng bằng cách biến khách hàng thành chủ sở hữu và thành viên nhóm cũng như người kiểm tra với tư cách là thành viên nhóm, mọi người đều có trách nhiệm giao hàng không chỉ là nhà phát triển.

Nó cho phép các chu kỳ giao hàng ngắn hơn, theo cách đó khi bạn sẽ bỏ lỡ và thời hạn thì chỉ là 1 hoặc 2 tuần Sprint và cả bạn và khách hàng đều biết rằng bạn sẽ bỏ lỡ nó trước khi kết thúc Sprint.

Nếu bạn sắp thất bại, vì bạn chỉ lập kế hoạch cho một Sprint duy nhất từ ​​1 đến 2 tuần, bạn sẽ thất bại nhanh chóng, nhỏ thay vì muộn và lớn.

SCRUM cũng đưa ra sự chấp nhận cuối cùng về việc giao trách nhiệm của Chủ sở hữu sản phẩm (khách hàng), điều đó có nghĩa là nếu họ tiếp tục thay đổi các yêu cầu và những gì không minh bạch đối với mọi người gây ra sự chậm trễ và được ghi chép rất rõ.

Nhiều thứ khác được hoàn thành 100% và được thử nghiệm và chấp nhận trước khi các tính năng mới được thực hiện. Hãy tưởng tượng bạn có một danh sách 100 tính năng. Khách hàng sẽ hài lòng hơn với điều gì?

80% các tính năng quan trọng nhất hoàn thành 100%, được kiểm tra và chấp nhận là không có lỗi?

hoặc là

100% tất cả các tính năng hoàn thành 80%, chưa được kiểm tra và lỗi?

Các quy trình như SCRUM buộc khách hàng (Chủ sở hữu sản phẩm) ưu tiên các tính năng cho bạn, vì vậy bạn chỉ cung cấp những gì họ đang yêu cầu cho Sprint hiện tại. Công việc quan trọng nhất đối với Chủ sở hữu sản phẩm được thực hiện trước tiên, những việc khác ít quan trọng hơn có thể không bao giờ được thực hiện, nhưng theo quyết định của khách hàng không có giá trị.


Tôi là nguồn tài nguyên duy nhất trong dự án này. Làm SCRUM là khó khăn với điều đó trong tâm trí. Tôi sử dụng một số phương thức nhanh, cố gắng để khách hàng chấp nhận một số trách nhiệm nhưng đó là một thách thức ..
user17971

1
là nhà phát triển duy nhất trong dự án làm cho quá trình trở nên quan trọng hơn và cung cấp cho bạn một vị trí để đàm phán từ

1
Đúng. Tôi rất định hướng quy trình nhưng vì một số lý do, dự án này chỉ quyết định có một cuộc sống riêng. Cảm ơn những hiểu biết của bạn, bạn đang nói với tôi chính xác những gì tôi cần nghe.
dùng17971

1

Học từ nó. Lời khuyên tốt nhất tôi nhận được về việc đưa ra ước tính thời gian là: tính toán những gì bạn nghĩ sẽ mất, sau đó nhân đôi và thêm 10%. :)

Xin chúc mừng, bạn đã học được một bài học quý giá về quản lý dự án phần mềm. Cố gắng tránh bị ám ảnh về việc làm hài lòng khách hàng của bạn đến nỗi cuối cùng bạn sẽ khiến họ khó chịu hơn.

Điều này không phải là duy nhất cho ngành công nghiệp phần mềm. Bạn sẽ mong đợi điều gì nếu bạn đến một nhà hàng và máy chủ mất một giờ để mang thức ăn đến. Và khi bạn nhận được nó, đó không phải là những gì bạn đã mong đợi? Bạn muốn giảm giá hoặc xin lỗi, phải không?

Cung cấp những gì bạn có thể cho khách hàng, và chỉ cần di chuyển. Đôi khi đó là lựa chọn duy nhất bạn có.

Chỉnh sửa: Tôi sẽ xem xét Scrum hoặc một số phương pháp Agile khác trong những ngày này để giảm sự không hài lòng của khách hàng.


0

Gọi đó là kinh nghiệm học tập. Lần tới, khi người dùng cố gắng thay đổi các yêu cầu đối với bạn, hãy thương lượng lại dòng thời gian và nhận nó bằng văn bản.

Bạn có thể gửi hóa đơn nếu bạn cảm thấy hợp lý. Âm thanh như bạn không.


Trên thực tế, họ không trả bất cứ điều gì cho dự án. Họ trả phí giấy phép hàng tháng cho ứng dụng mà thậm chí không trả tiền lương cho tôi.
dùng17971
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.