为截止日期设定切合实际的期望

我是一个小型团队的技术主管。我的主要任务之一就是与客户沟通。我发现特别困难的一件事是处理截止日期，因为截止时间是客户委托的，而我却经常没有得到咨询。

通常，交互遵循以下模式。客户端提供了他们想要添加的功能，功能X。功能X在下周的应用程序发布中（大约6个工作日后）看起来不错。此时，功能请求需要经过批准，并且经常需要处理其他依赖项。最终，在N天后，功能请求被滴落到我的团队中。即使原始的最后期限（由非开发人员设置的期限）可以实现，也不再可行。我的团队受到责备，感到灰心，并且总体上有失败的气氛，我感到灰心和失败。

显然，整个过程被打破了。不幸的是，我无能为力，因为我在这里没有权力。我目前的做法是向客户温和地提醒我们开始日期，截止日期，功能的范围等。这感觉很像我在找借口。

你们遇到过类似情况吗？有什么/没有为您服务？

您确实需要与老板讨论此事并制定一些基本规则：

• 除非您承诺，否则期限不是期限。
• 除非您给出估计，否则它不是估计，然后它是一个“估计”而不是一个艰巨的截止日期。

罗伯特·马丁（Robert Martin）的清洁编码器（Clean Coder）关于如何将此内容传达给老板的一章非常好。如果销售团队做出不可能的承诺，那不是您的错。

获得新功能时，您可以对其进行估算并使用PERT，以便获得概率分布。“我应该在4天内完成该操作，但可能最多需要8天”。坚守阵地。永远不要与业务员协商估算，您最终将致力于不可能。

经过几次这样的迭代后，销售人员有望被装扮成傻瓜，并将行为调整为“我将与开发团队核实，看看我们何时才能完成”，而不是承诺最终打破。

你们遇到过类似情况吗？有什么/没有为您服务？

在大多数情况下，有效的做法是向权力说话。

收集事实。陈述事实。让客户按照自己的进度学习（或不学习）。

我的团队受到了责备，感到灰心，并且总体上感到失败。

为什么您的团队意识到这一责任？如果客户绕过您并直接与团队交谈，那么您将失去效率，需要找出原因。

您的团队应该对“责备”或缺乏责备一无所知。他们应该只构建软件，而您应该简单地与客户交流您在做什么和何时进行。

客户应该-最终-成长以了解该过程。打破坏习惯需要大量重复。好的折扣。

我一直在这种情况下，这并不愉快。但是，我采取的一种方法是精心记录当前正在开发的工作。当任务完成时，您提醒客户，管理人员或项目经理，其他工作将会拖延，因为这已经成为他们的优先事项（有时可以使他们重新猜测，然后您会不断努力以延长截止日期）。

否则，我想您需要尝试继续将凿子敲入石墙，这是与客户打交道并同意这些期限的项目经理/客户联络员/管理/推销员。我经常抨击一个事实，即如果他们同意要做某事需要5天，那么他们显然是在谈论5天的开发，这意味着从获得它起需要5天（而不是他们挂断电话然后花钱）。接下来的两天，起草了一个精美的字词文档）。

但是，由于您是开发主管，因此，如果不首先与您协商，任何类似这样的决定都是无关紧要的。

您还需要尽最大努力使您的团队免受此影响。尽管很难做到，但必须尽可能地将它们排除在客户/管理策略之外。如果不是这种情况，则需要更多的头部锤击。

基本上，我并不喜欢它，而且无论我多么努力地尝试，这个过程也并没有变得完美。但是，我确实设法有所改善。

您可能唯一能做的就是与客户交谈。只需描述您所看到的情况，描述所有风险等等。我也有类似的情况，我真的很生气。即使现在，当我负责所有技术估算时，我也经常听到-我们希望在星期一之前完成。我只是说-您一无所获，让我们讨论到星期一您到底想要什么，然后通常似乎所有关键功能都非常容易实现，而星期一绝对好。然后将所有其他功能安排在以后的版本中。

问题是-客户大部分都知道该功能的商业价值，但没有意识到其复杂性。只是讨论和澄清。总是。

这是一个很好的开始，提醒您客户的开始日期晚于他们要求功能的日期。您还需要与与客户进行初始交谈的任何人进行交谈，以获取有关该功能的详细信息，以便他们可以在当时告诉客户一个更好的截止日期。由于您已经在与客户进行沟通，您可以说“那么Y部门谁同意了这个期限？”

如果他们不让您参加谈判，或者他们告诉您保持安静并遵守他们同意的最后期限，您可以提醒他们，如果您的团队按时完成，那对整个公司来说会更好。为了实现这一目标，您需要在截止日期之前输入您的意见。

修复信息流。

• 如果您应该与客户沟通，请始终强迫所有项目涉众（包括客户）直接与您进行交互。

可悲的是，权力多数是由您自己掌握，而不是由他人授予。

我的主要任务之一就是与客户沟通。我发现特别困难的一件事是处理截止日期，因为截止时间是客户委托的，而我却经常没有得到咨询。

如果您应该负责与客户沟通，那么为什么不咨询您的日程安排（和预算），以便您可以在组织内负责他们的人员与客户的同事之间交流此信息？我认为解决此问题将为您，您的团队和您的项目带来巨大的好处。

客户端提供了他们想要添加的功能，功能X。功能X在距离下一个工作日大约6个工作日的应用程序版本中看起来不错。此时，功能请求需要经过批准，并且通常还需要处理其他依赖项。最终，在N天后，功能请求被滴落到我的团队中。即使原始的最后期限（由非开发人员设置的期限）可以实现，也不再可行。

至少可以说，这种调度系统看起来很奇怪。

根据我的经验，客户签约使用特定版本。他们可能会提交所需的功能和更改的列表，以及所需的时间，然后与构建软件的团队进行协商。或者，他们可能会向开发团队提供功能的优先级列表，然后开发团队会估算何时可以发布各种功能集。也有其他变体。

但是我从未见过的一件事是，客户可以在游戏中这么晚就更改发行版本，尤其是离发行版本不到一周的时间。使设计人员，开发人员和测试人员承受这种压力似乎并不正确。如果您要进行迭代开发，如果它是高优先级功能，则请确保将其添加到积压的形式中，并尽快进行。如果它不是高优先级功能，则在此版本中他们绝对不需要它，可以等到下一个。

我建议设置一些基本规则以适应您的设计，开发，测试和交付团队以及您的客户的功能冻结，代码冻结和交付。用书面形式写下这些，得到每个人的承诺，并坚持下去。如果您一次弹奏，则可能会弯曲得更多，并且您将失去对过程的控制。

不幸的是，我无能为力，因为我在这里没有权力。

您可能并不孤单。但这听起来像您的设计师和/或开发人员和/或测试人员承受着很大的压力来满足进度。您应该与上级团队坐下来讨论情况。首先，让您的组织致力于流程的改进，然后与客户合作，以​​使他们对事情的进行方式有所了解。

虽然感觉很像我在找借口。

当您开始找借口时，可能是时候进行艰难的对话或重要的对话了。我会推荐这两本书之一。阅读它们有助于提高我的沟通能力，尤其是在您需要面对各方都高度紧张的困难局势时。

解决其他一些答案。

可悲的是，权力多数是由您自己掌握，而不是由他人授予。

我不知道安德里亚要去哪里。是的，您需要修复信息流。但是您需要与项目经理和客户合作，以​​确保每个人都知道在项目开始时达成的共识（无论如何，我想是这样）。如果由于某种原因该安排没有奏效，请重新考虑一下，并将工作和角色重新分配给更适合他们的人。

您不会掌权或与权力抗争，但您会与之合作，试图驯服它并使之为所有人所用。

问题是-客户大部分都知道该功能的商业价值，但没有意识到其复杂性。只是讨论和澄清。总是。

loki2302的这句话很明显。作为软件工程师，您的职责之一是确保合适的人知道诸如任务的难度，任务需要多长时间以及执行某项操作存在哪些选择和风险之类的事情。从理论上讲，作为团队的主要沟通者，将这些信息从组织中传达给客户是您的工作。

寻找一个论坛来与谁设定这些截止日期。让他们知道，他们可以与您协商并提出更现实的建议。替代方案是：您可以告诉客户这将不会发生，或者他们可以告诉客户。

您的团队开始研究后，您可以在X天之内展示它。也许那是混乱？除非一遍又一遍，否则这是一个诚实的错误。那就只是疏忽了。

我猜您的团队过去已经达到了这些截止日期。

不幸的是，它是我们行业中的地方性疾病，因此许多数字/软件代理商对其公司的内部运作或要求一无所知。许多人只关心快速兑现。正如许多人之前所说，如果您没有提供估算或截止日期，请通知管理层。如何在不知道开发团队日程安排的技术人员的估计的情况下，在x时间内完成一项技术工作。

如果其他所有方法均失败，请离开。

给项目经理/老板/客户您可以实现的估计和进度，请他确认您的计划，或者先弄清他希望您从事的工作，然后走开-不要以任何方式参与或招待他。
如果他回来的项目计划无法反映您的估计，请用“我不协商估计”的声明将其发还给他。走开

确保您有大量的CYA文档。向所有相关人员明确说明您正在保留这些文档。我已经将此类记录通过电子邮件发送到我的个人电子邮件地址，并抄送我的老板，这非常成功。

这是一种建设性的方法，而不是指责的方法。我不是在指责您，只是说不管指控的真相如何，找个有过失的人找借口都不好。

发生这种情况后，请进行一次事后验算，以计算完成该项目实际花费的时间，或者完成该过程所需要的时间。然后，从您获得足够的信息和绿灯开始计算出您有多少可用资源小时。将这些数字转换为在截止日期之前需要增加多少程序员。

现在，按照以下方式与您的老板进行对话：

在项目开始日期Y和最后期限Z之间，我们有X可用工时。
该项目需要X + C工时才能完成。
其他项目也有类似的周转要求。
我们将需要Q个额外的程序员来达到满足期望所需的能力。
...当然，如果预算紧张，也许我们可以与项目经理合作，将更多时间投入到他们的预算中，以便我们承诺不足和超额交付（一定要使用传统的管理方式）