客户有不切实际的期望时该怎么办？[关闭]

在过去的六个月中，我一直在客户站点上从事一个项目，因为他们需要数据保密并且不希望我们在自己的办公室工作。

当我独自出现在该客户站点时，被告知我需要在两个月内完成该项目。

由于客户不是一家软件公司，并且由于各种政策的限制，大约需要20到25天的时间才能让我在我的机器上安装Eclipse，Tomcat等东西的权利。即使延迟了环境设置，他们仍然希望我在两个月内完成该项目。

他们没有给我任何需求文件，但是由于我是在客户现场工作，我们过去经常定期开会讨论需求。

六个月后，申请仍未完成，每个人都在责怪我，但他们没有意识到我们添加的功能比前几次会议讨论的功能更多。

在此期间，我不得不重做很多事情，例如，将表单分成两部分；几周后，他们让我再次混淆这两种形式，以此类推。

应用程序的范围每天都在增加，但他们仍然认为这是一个为期两个月的项目，因此被推迟了。当我告诉他们范围扩大时，他们问为什么我一开始没有要求。

我已经每天工作11到12个小时，旅行3-4个小时，现在他们希望我也能在周六来。

我必须在这里做所有事情：进行需求，设计，代码和测试。

请告诉我在这种情况下该怎么办？

_{其他详细信息：我们确实提供了可交付成果的列表，但是随后他们在其中添加了一些说明，这些也很重要。他们还更改了一些可交付成果。他们甚至没有UAT服务器，而是通过IP地址在我的开发机器上进行测试。}

这是您经理的失败。您作为承包商的公司，如果没有事先书面确定的明确要求，就不应被公司置于如此紧迫的期限内。这一切都不“他们补充道功能”后废话-每次发生时，他们应该在一个更新的时间表，签了字，你给了他们。

您的经理由于计划与他会面，因此需要从客户那里获得一组特定的要求-项目应该执行A，B，C，D和E。完成之后，它就完成了。客户的签名必须在同意该清单的文件上。您应该从一开始就拥有它。

如果您的经理不支持您，并且在此方面不为您提供支持-而且我也很少这么说-请您开始寻找其他工作。因为您可能最终将成为整个混乱的替罪羊。而且，如果您愿意每天工作11小时和通勤3小时，那么您显然是一个非常敬业的人，应该得到更好的服务。

在这种情况下，重要的是构建CYA纸质记录。没有书面就不能做任何事情，尤其是在复杂的业务关系中。坚持最初的时间表，尽管他们甚至需要20天才能让您工作，这是一个很大的危险信号，它将变得复杂。

您召开需要其他功能的会议吗？然后写下来，在每个项目上标记“ + X天到当前时间表”，并将其邮寄给所有相关人员。如果仅使用客户的内部邮件系统，请另外打印出来，包括“收件人：”，“抄送：”和“密件抄送：”收件人列表，并仔细存档。除此之外，正如GrandmasterB所说，客户应签署对原始要求的此类更改。

如果无法保留所需的时间表，请将其写入。如果发生任何更改，请将其写给他们，包括后果。等等。

这不是为了“我已经告诉过你”。当一团糟最终撞到墙时-无论如何，他们不会听。当客户因为您认为您未履行合同而起诉您，或者公司因客户拒绝付款而起诉客户时，这就是您的保险。

根据您的描述，您似乎正在参加一个经典的Death March项目：

在项目管理中，死亡行军是几种病理项目中的任何一种，涉及到与真实的死亡行进有关的气喘吁吁，黑暗幽默，例如，对一个显然有不良后果高风险（例如，项目失败以及可能对个人和团体声誉造成损害的风险）的项目，基于不充分的理由，使他们过度劳累，并且（通常，尤其是特别）过度劳累。 。因此，“死亡行军”这个名称可能会被应用到一个最终成功的项目中，但是却涉及到不可持续的过度劳累的家庭工作，或者（也许更多时候）被应用到一个任何明智的，有见识的成员注定要失败的项目（或者是处于极高的失败风险），但无论如何，这些成员仍然被上级强行采取行动...

现象是众所周知的，并且有很多有关如何进行的文献-当然包括开创性的爱德华·尤登（Edward Yourdon）的著作《死亡进行曲：完成“不可能的任务”项目的完整软件开发人员指南》。

上面引用的Wikipedia文章是一个很好的起点，可以为参与/感兴趣的死亡游行项目的人们寻找更多信息，研究和建议。

穿上鞋子，我考虑的第一件事就是将对以上文章的引用传递给我的经理。

这样一来，他们就可以知道我正在发生的事情，甚至可以帮助他们在为该概念提供的框架方面指导我，例如：“看，我们的当前状态已接近XYourdon 一章中描述的状态。请检查一下以及紧密相关的章节Y等等...”

在（不太可能）经理不了解该研究领域的情况下，推荐可以给他们提供很多思考的机会，帮助他们识别情况并决定如何处理。

老实说，如果您可能这样做，最好的解决方案是退出。像这样的情况对您来说是有害的，无论您多么努力，它们都不会随着时间的推移而变得更好。

最好减少损失并找到其他演出。但是，请反思您的经验，并从该主题的其他答案中获取建议。

这是严重的 issue in project management。看来您Project Manager应该在可交付清单上工作，并与客户优先处理它们。

最重要的是，您的项目经理should discuss并要与客户同意评估中的时间范围（包括问题和解决方案的设计和分析）。

拥有clear estimation of your work load项目的可交付项将减轻您的压力，并为您的工作增加内心的平静和信心。

通过在sprint（2-3周）内交付商品并与客户进行UAT（用户接受测试）来尝试使用敏捷方法。请记住，在开始冲刺之前，请务必进行冲刺计划。

编辑：从评论中可以明显看出这确实是您的项目经理的失败。没有为像您这样的严肃项目设置适当的测试和/或开发环境，这对于SDLC流程来说是一个大project漏洞。

我同意这是管理上的失败，但对您而言也是失败。在此阶段将很难修复，因此您需要摆脱的一些问题是如何处理将来的项目。

首先，您需要在项目开始时坚持一份需求基准文档。不必花哨或正式，但您不能成功构建任何东西，除非客户指定了期望的东西。如果您没有书面说明，则客户对最终结果感到满意的机会约为0％。因此，这至关重要。寻找本文档中的歧义并尽早清除它们也是您的工作。当您遇到其中之一而又不确定如何解释时，请不要猜测其含义，请确保您和客户在同一页上了解其含义。是的，这意味着更多地与人们交谈，更多的会议和更少的编码。但是，清除一个不清楚的需求所花的时间要比对它进行编码错误然后再对其进行编码要少得多。此外，您通常必须免费为他们提供重新编码，这对您所在的公司不利。

接下来，您告诉他们完成工作需要多长时间，并确定了截止日期。您绝不会接受除完成工作以达到要求所需的时间以外的其他任何截止日期。如果这样做，您将再次步入死亡之路。通过详细说明将要花费的时间，向他们展示如何无法达到最后期限。无论客户有多大的需求，您都无法仅用一名开发人员就将200小时的开发时间花在一周之内。在截止日期不可更改的那一刻，您询问应将哪些项目移至下一个迭代。

做项目时间估算时，不要忘记开发时间只是项目时间的一小部分。您还必须考虑会议和电子邮件/电话通信，测试，部署，文档，服务器，工作站，软件的物理设置。此外，在计划截止日期时，您只能假设您每天有6个小时而不是8个小时。这是考虑到请假，丧亲，病假，不可避免的延误（例如，当您必须等待他们获得许可时）网络等），培训，与项目无关的工作（时间表，人力资源会议等）。人们没有按时完成任务的最大原因之一是，他们假设自己每天只会做开发工作，并且每天要辛苦工作8个小时。这根本不是一个现实的假设。

每次他们添加另一篇文章时，您都告诉他们需要多长时间以及多少额外的工作将使截止日期移动。您不要求移动截止日期，而是告诉他们由于新要求而正在移动。现在，您应该为此咨询您的经理，但是首先要确保您的经理知道每次更改需求以及将为项目增加多少费用。确保所有这些都在编写中，以便您可以在需要时为自己辩护。

接下来，不要让自己被虐待到每天工作11个小时的工作日和周末。短时间内可以这样做（每六个月左右少于1周），但从长远来看，这是完全不可接受的。疲倦的人编写代码的速度较慢，并且会犯更多错误。与常规的11个小时相比，常规8个小时的工作质量更高，您可以完成更多工作。和周末。

我发现甘特图在这种情况下会非常好。它们可以向客户说明当前的时间表，并有助于说明添加任何新功能/更改的效果。有时，告诉客户功能x将在y天之内影响交付不会向他们注册。通过将其清晰地显示在图表上，他们可以更好地掌握它。

理想情况下，这应该从项目开始就完成。到目前为止，解释“ 延迟 ” 可能没有用，但可能有助于项目的进行。

从维基：

甘特图说明了项目的终端元素和摘要元素的开始和结束日期。