Làm gì khi khách hàng có những kỳ vọng không thực tế? [đóng cửa]

Tôi đã làm việc trong một dự án trong sáu tháng qua tại một trang web của khách hàng, vì họ yêu cầu bảo mật dữ liệu và không muốn chúng tôi làm việc tại văn phòng của chính mình.

Khi tôi xuất hiện một mình trên trang web của khách hàng này, tôi được cho biết rằng tôi cần hoàn thành dự án trong hai tháng.

Vì máy khách không phải là một công ty phần mềm và vì nhiều chính sách khác nhau, nên mất khoảng 20-25 ngày chỉ để cấp cho tôi quyền trên máy của tôi để cài đặt các công cụ như Eclipse, Tomcat, v.v. Ngay cả sau khi trì hoãn cài đặt môi trường, họ vẫn mong tôi hoàn thành dự án trong cùng hai tháng.

Họ không đưa cho tôi bất kỳ tài liệu yêu cầu nào, nhưng vì tôi đang làm việc tại trang web của khách hàng, chúng tôi thường có cuộc họp thường xuyên để thảo luận về các yêu cầu.

Sau sáu tháng, ứng dụng vẫn chưa hoàn thành và mọi người đang đổ lỗi cho tôi, nhưng họ không nhận ra rằng chúng tôi đã thêm nhiều tính năng hơn những tính năng được thảo luận trong một vài cuộc họp đầu tiên.

Tôi đã phải làm lại nhiều thứ trong giai đoạn này, ví dụ như tách một biểu mẫu thành hai phần; Vài tuần sau, họ yêu cầu tôi hợp nhất hai hình thức lại vì nó khó hiểu, v.v.

Phạm vi của ứng dụng đang tăng lên mỗi ngày nhưng họ vẫn nghĩ rằng đó là một dự án hai tháng đã bị trì hoãn. Khi tôi nói với họ rằng phạm vi đã tăng lên, họ hỏi tại sao tôi không yêu cầu ngay từ đầu.

Tôi đã làm việc 11-12 giờ mỗi ngày và đi du lịch 3-4 giờ, và bây giờ họ mong đợi tôi cũng đến vào thứ Bảy.

Tôi phải làm mọi thứ ở đây: lấy yêu cầu, thiết kế, mã và kiểm tra.

Xin tư vấn cho tôi phải làm gì trong trường hợp như vậy?

_{Chi tiết bổ sung: Chúng tôi đã có một danh sách các sản phẩm giao, nhưng sau đó họ đã thêm một vài điều nữa để nói rằng những điều này cũng quan trọng. Họ cũng thay đổi một vài sản phẩm. Họ thậm chí không có máy chủ UAT của họ, họ tự kiểm tra trên máy phát triển của tôi thông qua địa chỉ IP của nó.}

Đây là một thất bại của người quản lý của bạn . Bạn, với tư cách là một nhà thầu, không nên bị đặt vào tình huống có thời hạn chặt chẽ như vậy bởi công ty của bạn mà không có một bộ yêu cầu chắc chắn trước, bằng văn bản. Không ai trong số này 'họ đã thêm các tính năng' sau đó vô nghĩa - mỗi lần điều đó xảy ra, họ nên đăng xuất theo lịch cập nhật mà bạn đã cung cấp cho họ .

Người quản lý của bạn, vì họ đang lên kế hoạch gặp anh ta, cần phải nhận được từ khách hàng một bộ yêu cầu cụ thể - dự án nên thực hiện A, B, C, D và E. Và sau đó, nó đã hoàn thành. Chữ ký của khách hàng cần phải có trong tài liệu đó đồng ý với danh sách đó. Bạn nên có điều đó ngay từ đầu.

Nếu người quản lý của bạn không hỗ trợ bạn và hỗ trợ bạn trong việc này - và tôi không nói điều này rất thường xuyên - hãy bắt đầu tìm kiếm một công việc khác. Bởi vì có lẽ cuối cùng bạn sẽ trở thành vật tế thần cho toàn bộ mớ hỗn độn. Và nếu bạn sẵn sàng làm việc 11 giờ ngày và 3 giờ đi làm, rõ ràng bạn là một cá nhân rất tận tụy, xứng đáng được tốt hơn.

Điều quan trọng trong các tình huống như vậy là xây dựng một dấu vết giấy CYA. Không nên làm gì nếu không có nó bằng văn bản, đặc biệt là trong một mối quan hệ kinh doanh phức tạp. Bám sát lịch trình ban đầu mặc dù họ cần 20 ngày để thậm chí cho phép bạn làm việc là một lá cờ đỏ lớn mà nó sẽ trở nên phức tạp.

Bạn tổ chức một cuộc họp trong đó các tính năng bổ sung được yêu cầu? Viết nó xuống sau đó, gắn thẻ "+ X ngày vào lịch trình hiện tại" trên mỗi mục và gửi cho mọi người liên quan. Nếu bạn chỉ sử dụng hệ thống thư nội bộ của khách hàng, hãy in thêm ra, bao gồm danh sách người nhận :, cc: và bcc: và lưu trữ cẩn thận. Bên cạnh đó, như GrandmasterB đã nói, khách hàng nên ký tắt những thay đổi như vậy đối với các yêu cầu ban đầu.

Nếu lịch trình yêu cầu không thể được tổ chức, viết nó cho họ. Nếu có bất kỳ thay đổi nào xảy ra, hãy viết nó cho họ, bao gồm cả hậu quả. Và như vậy.

Đây không phải là "Tôi đã nói với bạn như vậy." khi mớ hỗn độn cuối cùng đập vào tường - dù sao họ cũng sẽ không nghe nó. Đây là bảo hiểm của bạn khi khách hàng kiện bạn vì anh ta nghĩ rằng bạn không hoàn thành hợp đồng hoặc khi công ty của bạn kiện khách hàng vì anh ta từ chối thanh toán.

Từ những gì bạn mô tả, có vẻ như bạn đang tham gia vào một dự án Death March cổ điển :

Trong quản lý dự án , một cuộc diễu hành tử thần là bất kỳ một trong số các loại dự án bệnh lý liên quan đến một sự tương đồng về mặt hài hước, đen tối với các cuộc diễu hành tử thần thực sự, chẳng hạn như làm việc quá sức, và (thường xuyên và đặc biệt nhất) bị làm việc quá sức vì những lý do không chính đáng trong một dự án rõ ràng có nguy cơ cao dẫn đến kết quả xấu (ví dụ, thất bại của dự án và có thể đe dọa thiệt hại danh tiếng cá nhân và nhóm) . Do đó, cái tên "cuộc diễu hành tử thần" có thể được áp dụng cho một dự án cuối cùng thành công nhưng liên quan đến việc gia đình làm việc quá sức không bền vững, hoặc (có lẽ thường xuyên hơn) cho một dự án mà bất kỳ thành viên thông minh, thông minh nào cũng có thể thấy là thất bại (hoặc là có nguy cơ thất bại rất cao) nhưng dù sao các thành viên vẫn bị buộc phải hành động bởi cấp trên của họ ...

Hiện tượng nổi tiếng và có rất nhiều tài liệu về cách tiến hành - tất nhiên bao gồm cả cuốn sách Death March của Edward Yourdon : Hướng dẫn dành cho nhà phát triển phần mềm hoàn chỉnh để sống sót trong dự án 'Nhiệm vụ bất khả thi' .

Bài viết Wikipedia được trích dẫn ở trên làm cho một điểm khởi đầu tốt để tìm kiếm thêm thông tin, nghiên cứu và khuyến nghị cho những người liên quan / quan tâm đến các dự án diễu hành tử thần .

Đi trong đôi giày của bạn, điều đầu tiên tôi xem xét sẽ chuyển một tài liệu tham khảo đến bài viết trên cho người quản lý của tôi.

Cách đó sẽ cho họ biết tôi biết về những gì đang diễn ra, và thậm chí có thể giúp họ hướng dẫn tôi về các khuôn khổ được cung cấp cho khái niệm này, như "Hãy nhìn xem, trạng thái hiện tại của chúng ta gần với một mô tả trong chương Xtại Yourdon. ra ngoài, cùng với chương liên quan chặt chẽ, Yv.v ... "

Trong trường hợp (không có khả năng) mà người quản lý không biết về lĩnh vực nghiên cứu này, việc giới thiệu có thể cung cấp cho họ nhiều thực phẩm để suy nghĩ giúp xác định tình huống và quyết định cách xử lý.

Thành thật mà nói, nếu bạn có thể làm điều này, giải pháp tốt nhất là bỏ việc. Những tình huống như thế này là độc hại đối với bạn và chúng hiếm khi trở nên tốt hơn theo thời gian, bất kể bạn có cố gắng thế nào.

Tốt nhất để cắt lỗ của bạn và tìm một hợp đồng khác. Nhưng, hãy suy nghĩ về kinh nghiệm của bạn và nhận lời khuyên từ các câu trả lời khác về chủ đề này.

Đó là một nghiêm trọng issue in project management . Có vẻ như bạn Project Managernên làm việc trong danh sách có thể giao được và ưu tiên chúng với khách hàng.

Quan trọng nhất , PM của bạn should discussvà đồng ý với Khách hàng khung thời gian (bao gồm thiết kế và phân tích vấn đề / giải pháp) trong các ước tính của bạn.

Có clear estimation of your work loadvà giao các mặt hàng của dự án sẽ giúp bạn giảm căng thẳng, Cũng như, thêm sự an tâm và tự tin trong công việc của bạn.

Cố gắng sử dụng phương pháp Agile bằng cách phân phối các mặt hàng của bạn trong giai đoạn nước rút (2-3 tuần) và thực hiện UAT (thử nghiệm chấp nhận của người dùng) với khách hàng. Hãy nhớ rằng, luôn luôn làm kế hoạch chạy nước rút của bạn trước khi bắt đầu chạy nước rút.

Chỉnh sửa: Từ các bình luận, rõ ràng đây thực sự là thất bại của người quản lý dự án của bạn . Không có môi trường thử nghiệm và / hoặc phát triển phù hợp được thiết lập cho một dự án nghiêm túc như của bạn là một lỗ hổng lớn cho projectquá trình và SDLC.

Mặc dù tôi đồng ý rằng đây là một thất bại trong quản lý, nhưng đó cũng là một thất bại từ phía bạn. Ở giai đoạn này sẽ rất khó để sửa chữa, vì vậy một số điều bạn cần để thoát khỏi điều này là làm thế nào để xử lý các dự án trong tương lai.

Trước tiên, bạn cần nhấn mạnh vào một tài liệu cơ bản yêu cầu khi bắt đầu dự án. Không cần phải cầu kỳ hay trang trọng, nhưng bạn không thể xây dựng thành công bất cứ điều gì cho đến khi khách hàng chỉ định những gì được mong đợi. Nếu bạn không có điều này bằng văn bản, cơ hội của khách hàng hài lòng với kết quả cuối cùng là khoảng 0%. Vì vậy, điều này là rất quan trọng. Công việc của bạn là tìm kiếm sự mơ hồ trong tài liệu này và làm cho chúng được giải tỏa càng sớm càng tốt. Khi bạn gặp một trong những điều này và bạn không chắc chắn cách diễn giải nó, đừng đoán xem bạn nghĩ nó có nghĩa gì, hãy chắc chắn rằng bạn và khách hàng ở cùng một trang về ý nghĩa của nó. Vâng, điều này có nghĩa là nói chuyện nhiều hơn với mọi người và nhiều cuộc họp hơn và ít mã hóa hơn. Nhưng phải mất ít thời gian hơn để làm rõ một yêu cầu không rõ ràng hơn là viết mã sai và sau đó phải mã hóa lại. Hơn nữa, bạn thường phải cung cấp cho họ mã hóa lại miễn phí và điều đó không tốt cho công ty bạn làm việc.

Tiếp theo, bạn cho họ biết phải mất bao lâu để thực hiện công việc và điều đó đặt ra thời hạn. Bạn không bao giờ chấp nhận một thời hạn dựa trên bất cứ điều gì ngoài số giờ cần thiết để thực hiện công việc để đáp ứng các yêu cầu. Nếu bạn làm thế, bạn sẽ lại ở trong một cuộc diễu hành tử thần. Chỉ cho họ cách thời hạn không thể đáp ứng bằng cách khám phá chi tiết về số giờ cần thiết. Bạn không thể phù hợp với 200 giờ thời gian phát triển trong một tuần chỉ với 1 nhà phát triển cho dù khách hàng muốn bao nhiêu. Tại thời điểm đó, thời hạn là bất động, bạn hỏi những mục nào sẽ được chuyển sang lần lặp tiếp theo.

Đừng quên rằng thời gian phát triển chỉ là một phần nhỏ thời gian dự án khi thực hiện ước tính thời gian dự án. Bạn cũng phải tính đến các cuộc họp và liên lạc qua email / điện thoại, thử nghiệm, triển khai, tài liệu, thiết lập vật lý của máy chủ, máy trạm, phần mềm. Hơn nữa, trong việc lập kế hoạch thời hạn, bạn chỉ có thể giả sử rằng bạn có sẵn 6 giờ mỗi ngày chứ không phải 8. Đây là lý do nghỉ phép, mất người thân, thời gian ốm, sự chậm trễ không thể tránh khỏi (chẳng hạn như khi bạn phải chờ họ nhận được giấy phép trên mạng, v.v.), đào tạo, công việc không liên quan đến dự án (bảng chấm công, cuộc họp nhân sự, v.v.). Một trong những lý do lớn nhất khiến mọi người không đáp ứng được thời hạn là họ đưa ra giả định rằng họ sẽ chỉ thực hiện phát triển và làm việc 8 giờ đồng hồ mỗi ngày. Điều này chỉ đơn giản không phải là một giả định thực tế.

Và mỗi khi họ thêm một phần khác vào, bạn cho họ biết sẽ mất bao lâu và công việc bổ sung sẽ di chuyển thời hạn. Bạn không yêu cầu di chuyển thời hạn, bạn nói với họ rằng đó là di chuyển do yêu cầu mới. Bây giờ bạn nên đi qua quản lý của bạn cho điều này, nhưng nó là đầu tiên của tất cả các reponsiblity của bạn để đảm bảo quản lý của bạn biết mỗi khi yêu cầu được thay đổi và bao nhiêu mà sẽ thêm vào dự án. Hãy chắc chắn rằng tất cả những điều này là trong văn bản, vì vậy bạn có thể tự bảo vệ mình nếu cần.

Tiếp theo, không cho phép bản thân bị lạm dụng vào làm việc 11 giờ ngày và cuối tuần. Điều này là ổn trong các lần ngắn (Trong vòng ít hơn 1 tuần mỗi sáu tháng hoặc lâu hơn), nhưng về lâu dài, điều này chỉ đơn giản là không được chấp nhận. Những người mệt mỏi mã chậm hơn và họ mắc nhiều sai lầm hơn. Bạn có thể hoàn thành nhiều việc hơn với chất lượng cao hơn làm việc thường xuyên 8 giờ so với thường xuyên 11 giờ. và cuối tuần.

Tôi đã tìm thấy Biểu đồ Gantt có thể rất tốt trong các tình huống này. Họ có thể minh họa cho khách hàng lịch trình hiện tại và có thể hữu ích trong việc minh họa hiệu quả của việc thêm vào bất kỳ tính năng / thay đổi mới nào. Đôi khi, việc nói với khách hàng rằng tính năng x sẽ ảnh hưởng đến việc phân phối bởi y ngày không đăng ký với họ. Bằng cách có nó rõ ràng trên một biểu đồ, họ có thể nắm bắt nó tốt hơn.

Lý tưởng nhất là nên được thực hiện từ khi bắt đầu dự án. Có thể không hữu ích để giải thích " sự chậm trễ " cho đến thời điểm này, nhưng có thể giúp cho dự án trong tương lai.

Từ Wiki :

Biểu đồ Gantt minh họa ngày bắt đầu và ngày kết thúc của các yếu tố đầu cuối và các yếu tố tóm tắt của một dự án.