想要通过签订的合同锁定时间估算的项目经理

在以前的工作中，项目经理（PM）对我所在的项目中的代码交付时间不满意。项目负责人告诉我，项目经理正在考虑让我签署一份合同，以锁定我为任务和交付日期提供的时间估计。

该项目的情况是我们正在使用新技术，代码库，编码标准以及非常容易更改的要求。我正在学习新事物，并根据不断变化的需求尽最大可能应用它们。整个迭代过程中的需求增长了2-3倍，而我估计要完成的需求增长了约5-8倍。唯一不变的是估算和交货日期。

是的，我确实错过了大多数截止日期。我正在研究一些非常新的技术，整个开发团队中没有其他人可以真正提供帮助，因为他们对此并不熟悉。至少不容易。

在我看来，项目经理希望将他的数字加起来，因此希望我签署一份合同以“确保”我将始终按时交付工作代码。我想如果我不能按时交货，PM可以通过签订的合同对我不利。

我相信接下来发生的事情是其他项目经理和/或项目负责人为我辩护，并且没有让这种情况发生。

我的问题是，这是否应该引起经理的危险信号？经理通过签署的合同锁定软件开发人员的时间估计是否是惯例？或者在这种情况下，请尝试。

请注意，我是全职员工，而不是独立顾问。

更新：我想补充一下，我确实每周都会提供新的估算值，但是看来原始的估算值和交货日期正是PM所确定的。

我的问题是，这是否应该引起经理的危险信号？

是的。这意味着您是时候更新简历/简历并开始寻找新工作了。或这意味着您的经理将要与您一起玩一些非常讨厌的游戏。

经理通过签署的合同锁定软件开发人员的时间估计是否是惯例？

我从未听说过将其应用于员工。

时间和精力的估算始终很困难。特别是因为我们的职业充满了过度乐观。有一些估算系统可以在将来帮助估算，但是它们需要从您自己收集历史统计数据。一种是PSP。另一个是功能点。许多开发人员都不喜欢它们，您会发现对他们两个都有很强的见解。

估计时间和精力的关键困难是我们的估计启发式方法缺乏反馈。关键之一是写下您认为的估计值以及用于估计的参数。然后，根据您实际完成的工作，将其与您认为的工作进行比较。并使用它来修改您的估算参数。在工程学中，我们称其为“ 反馈”。

是的，那绝对应该敲响警钟。

如果我一直担任我的个人娱乐职务，我会要求经理签定冻结所有要求的合同。我想经理可能会保释。那我就走了

好吧，这很简单。只需告诉您的经理，您将登录以锁定您的时间估算，此时他将登录以锁定规格。因为您做不到，所以请务必为未知的事物提供任何估计。开始之前的完整项目规格，无需更改-您可以及时完成:)

对spec => contract的一项更改无效。可能在您第一天10分钟后，该东西就会失效：)

是的，这是一个危险信号。它告诉您的是，经理不了解如何管理软件项目中的风险。他应该做的是首先弄清楚到底是什么引起了延迟，然后才开始对流程进行检测，以有效地管理在软件项目中不可避免发生的计划风险。

在任何情况下，我都不会与我的经理签订一份保证时间表的合同。其他人提到让他在规格上签名。我认为这还不够。这不考虑工具或技术的不可预见的困难，不完整或不良的设计，其他团队成员的表现等。

这不是一个危险信号，这是武器级的愚蠢。

如果持续不断地估算和截止日期，那么合理的事情就是找出原因并改进流程。

如果您因为不知道要走的路而责备和踢马，那么如果马咬住您并逃跑，也不要感到惊讶！

当经理不符合他的要求时。他没有完全责备。如果您在完全陌生的地区工作，那么说“我不知道”没有任何问题。我花了一段时间才意识到“我不知道”是一个完全可以接受的答案，所以我知道说出这些话有多刺痛。但是，如果您真的不知道，那就是答案。如果他们不愿意这样做，请他们给您一个估计，要像西尔斯大厦（变成威利斯大厦）那样高，要花多少便士。他们愿意签署一份合同，向他们支付每一分钱吗？

任何值得付薪水的项目经理都应该知道，有些东西在电子表格中不太合适。有时事情在完成时就完成了。我认为通过在已完成的工作上取得进展，您的状况很好。只是停止提供数字更新。

另一个练习是将大型任务分解为较小的，更容易估计的单元。此练习将帮助您更好地了解您需要做的事情。分别查看Steve McConnell的软件估计和Stephen Withall的软件需求模式，以获取分解任务和发现隐藏需求的提示。

不要从臀部射击。花时间分解它。估计大量的小任务会给您带来更好的总体估计（由于平均数定律，您的一些估计会低于，但有些估计会超过，并且它们往往会相互权衡）。

问您的“项目经理”：我们是在销售软件还是在截止日期？

我是项目经理和程序员:-)我可能会长期抱怨大多数PM来自行业外部，并且无法处理任何不适用于生产线模型的问题...但是我不会，不在这里。取而代之的是，这里对实际要做的事情有很长的争论（Mod先生，如果时间太长，您将要做什么）。我同意这里已经提出的意见，有些你应该在其他人之前做，但是我认为这最好是你的第一步。哦，您的问题的明显答案是肯定的，但这在下面以彩色和详细的语言进行了详细说明。

在开始之前，请注意，PM很可能会给您带来悲伤，因为食物链上游的其他人正在给他们带来悲伤。他们（我们）是简单的生物...有多种方法可以避免您所描述的情况-Mike Brown很好地说明了这一点。在启动之前连续进行3/4/5 ..小时的工作也没错（实际上，如果没有发生，所有警报都需要关闭）。而且，如果您要进入未知领域，请推迟并要求一个星期来研究该区域和技术，以便做出合理的估算（您需要正确地执行此操作，因为您希望新技术可以与Don一起学习和玩耍不是吗？）。如果您的项目经理和您所在的地方的管理人员对此不了解...，请更新您的简历并寻找最近的出口，让他们拥有他们应得的命运。总理甚至会考虑让一名全职员工签署这样的合同，这是一个糟糕的坏信号……我唯一能看到他们的方法可能并非完全没有能力，因为他们实际上只是在与您的项目负责人和您玩头脑游戏（据我了解，他们并没有直接把这个问题告诉您，也没有最终解决威胁）。 毕竟，PMing是您的标准公司心理变态者的避风港。 很好，其他人根据您的发言对您进行了抨击，因此以下建议最终可能对您有利。我想，如果事实证明不仅仅是谈话，他们本来将有一场革命。

因此，对于您所描述的实际情况/漏洞，因为它会再次发生在某人某处（例如大约5分钟前，然后在另一个5中，scheduleRepeat（））。可能没有合同愚蠢，但基本故事情节始终是相同的。组织会议（！），他们喜欢会议；-)每个人都可以像实际完成的操作一样在最后轻轻拍打自己。 重要：确保在会议邀请中包括技术项目负责人/团队负责人/架构师/设计经理，并邀请他们与他们一起讨论问题并将他们加入董事会。您可以为“身边”的人选择的等级越高，越好。因为您的项目经理会看到这一点，然后尝试将您的设计经理与同等职位相匹配。如果没有，他们就傻了，你已经赢了。通常，这本身会使它们重新排成一行，因为现在可以将它们立即解雇的人可以看到它们。如果他们与您一起玩游戏，则允许您退还该优惠。

在会议上，详细介绍您正在处理的技术细节以及为什么要花一些时间。他们应该想知道这一点（以及如何帮助您完成任务），但是可悲的事实是这通常不会发生……您可能要等10分钟才能看到他们的眼睛回头。现在我想在这里做的事情可能是不合法的……是的，我检查了一下，实际上这是非常违法的，而且您也不想长期入狱。关键是您已尽全力积极主动，如果您有一些高高在上的人，那么现在您的痛苦就在他们的……应有的。您将不得不对可能的结果进行判断，因为将要发生“升级”。如果您所处位置的领导能力过半，他们会做正确的事，并由您做正确的事。如果不是这样，那么您应该事先将履历表放到市场上……无论如何，您将要抓住第一个机会（并且看起来您最终会这样做）。领导者将分为两组-要么他们在技术上精明，他们将立即看到您的观点；还是他们不是，除了忍受它之外，他们将如何做？如果他们能做您所做的事，那么他们将已经在做。t，除了咧嘴和忍受之外，他们还打算做什么？如果他们能做您所做的事，那么他们将已经在做。t，除了咧嘴和忍受之外，他们还打算做什么？如果他们能做您所做的事，那么他们将已经在做。

保留不断变化的需求问题，作为最后使用的王牌...它将作为所有人的礼物。项目本身和该死的客户/利益相关者将被徒劳地取名。最轻松的方法是在项目上进行某种重置，也许可以将PM悄悄地重新分配到其他区域。偶尔会发生奇迹。如果项目经理在会议上提出合同问题，则撤回需求冻结反合同需求-就我而言，他们开始时已经与您以及整个开发团队建立了桥梁玩那些思维游戏。

在我签字之前：更改范围/要求-采用敏捷方法论的最佳理由之一，因此客户/利益相关者对改变他们对所需内容的想法负有适当的责任...

哦，另一件事：在“我不知道”的声明上，我一直是我个人的基准，用以衡量我的一个项目团队中技术专家或成员的价值。我发现唯一能够直面你的脸的人是最好的，这主要是因为知道自己超出深度的人永远不会说-使他们容易被具有实际能力的人清楚地暴露出来。心跳。另一方面，会挺身而出的人也将有一个基本计划（即使没有经过深思熟虑），以解决未知问题，以便在24小时内提供更有用的答案，在一个星期的时间内，情况会更好。当阿波罗13号在月球的黑暗面附近飞行时，发生了很多“我不知道”的事情。

是的，这应该会引起危险，特别是如果您是全职员工。合同的条件是什么？如果错过最后期限，您会被解雇吗？还是会错过奖金？他们会怎么做？

提出的标志是，经理不知道如何管理一个项目，该项目涉及新的/不熟悉的技术以及转移直接影响估计工作量的需求。尽管有时有时会遇到艰苦的最后期限，但一个了解情况的经理不应试图让员工签署合同以执行合同。深夜和紧迫的时光会很糟糕，但这在整个过程中可能是一样的。有时，截止日期会有所缩短。确实发生了这种情况，就像其他人一样，遵守时间表的唯一方法是尽早冻结需求，以便仍有足够的空间保留时间表。

从您所说的内容来看，闹钟已经太迟了几个月。将时间敏感的项目建立在员工尚未熟悉的技术上通常是有风险的。如果您不了解需求收集和范围管理，那么这样做就很困难。

也就是说，我同意其他答案。另外，如果您尚未更新履历，则可能需要更新。

就像所有其他答复者一样，我完全同意这会引起危险。

似乎PM不想参与开发过程。

在我的个人实践中，我已经远离处理详细的前期规范，签署，完整的项目估算或固定报价（从咨询角度来看）。

这样做的原因是许多敏捷和精益软件专家所谈论的实现，即该软件不是固定的可制造实体，而是主要是发现的过程。

许多人仍然对这个概念有疑问，这听起来像您的PM也一样。它归结为对权衡的简单理解。

刚性的前期规格和固定的估算值适用于变更成本很高的系统。就像建造高层建筑。如果您忘记提前确定电梯井道，那么一旦建筑物竖立起来，将真的很难对其进行改造。高昂的变更成本需要大量的前期计划，了解组件和技术的未知因素以及前期试验。只有完成所有这些作业后，您才能估算预算和成本。

在软件领域，人们已经非常习惯于变更成本较低的想法，因此，他们喜欢利用一旦看到发布就可以进行更改，结合对应用程序，业务和客户的新理解的优势。持续的基础上。正确利用所有这些都是很好的机会，而且是巨大的机会。实际上，我遇到并与之共事的大多数软件人都不喜欢花很多时间进行计划或研究。我们大多数人（包括PM）都希望看到持续的牵引力。这是迭代开发的源代码，它的功能是小的，增量版本。还可以使用其他实践，例如测试驱动的开发，以确保变更成本保持在较低水平，并且可以控制技术债务。

进行这项工作需要双方，产品所有者（为您的PM或客户或QA团队敏捷地说）和开发人员之间的“合同”。开发人员同意只处理对于给定迭代最重要的事情，而不是永远花时间，而是努力频繁地发布完全集成的功能块（例如，每周或每月）。相反，产品负责人同意持续审查增量版本并提供及时反馈。他们还同意为下一次迭代设置优先级，并且一旦设置为在迭代持续时间内不改变主意。

协议的后半部分是您的PM可能不理解的内容。许多传统的PM实际上没有。他们中的一些人认为当他们脱离规范时，他们的工作就完成了。他们不想听到有关问题，替代方案，更好的方法等的消息。不利的一面是，这不仅阻碍了软件开发的流程，而且还给企业留下了很多机会，从而伤害了组织。

看一下《敏捷宣言》：http : //agilemanifesto.org/它可能会引起您的共鸣。一本好书也是Mary Poppendieck的“精益软件开发”

祝好运。

听起来经理在向上司汇报时正在寻找某人的责任。

我发现如果您有一个不合理的经理认为“估计”与“固定期限”相同，那么最好的办法就是考虑一个非常慷慨的估计期限，然后将其加倍！

另外，强制经理确保要求完全详细和固定。如果没有新的完成时间与项目经理进行“正式重新谈判”，此后的任何更改都将无法解决。

最终，项目经理了解了想法并制定了相应的计划。

我对这类事情的个人经验是，项目经理试图建立一个文件记录，以处理您的问题，同时使您的解雇是您自己的错。那将使其成为一个危险信号。当然，您的里程可能会有所不同。

到处都有好的答案，但让我加2美分。

如果您曾经研究过概率，那么就有“随机变量”之类的东西。那是一个您不知道其值的数字，但是您可以用正态（钟形曲线）分布或其他分布来描述您的未知。

关键是，这项工作将花费一些时间，但是任何先前的估计都会在消极方面或积极方面有所或多或少的错误，因此存在风险，因此有人必须承担风险。通常，如果人们冒险，他们会为此付出报酬。保险费钱。

当我是一名顾问时，我通常可以选择签订时间和材料合同，而不是固定价格合同。使用时间和材料，客户将承担风险。以固定价格，我要承担风险。使用固定价格，我可以保证安全，因为如果我未能达到目标，那么谁也不会赢。

要求您约定一个固定的交货日期，尤其是在没有固定要求的情况下，这听起来像是试图将风险转移给您，即使您不清楚您实际上在冒险什么。在任何情况下，一个响应就是简单地增加安全性。

PS：您始终可以通过政府合同看到这一点。最初有一个投标请求，一个投标，一个低价被接受，然后变更请求开始出现，因此成本激增，承包商被指责。如果客户和承包商之间存在团队合作关系，而不是对抗性合作关系，那么事情会好得多。

是的，这当然会引起您前任老板的经验和能力方面的信号。是的，正如大多数人建议的那样，这是更新您的简历的好时机。

是的，正如其他答案所述，在大多数情况下，您都不想签署该协议。但是，我想建议您可能在某些情况下考虑对其进行签名。

大多数开发人员和管理人员都意识到功能，截止日期和预算之间的不断摩擦。许多人也将质量作为第四维度来提名（“我可以在明天以较低的预算交付任何您想要的要求，只要您愿意接受它就行不通了！”）

但是还有另一个方面：风险。如果我只需要成功完成50％的时间，就可以大大降低估计值；他们被填充以处理更高的交付率。

我们可以通过多种方式解决风险（填充估算是其中之一）。经理不愿承担任何风险，并希望将风险放在您的肩膀上。通常，除非您得到充分的补偿，否则您应该拒绝这样的举动。

如果您能够提名自己的截止日期，并且双方都可以接受填充量以应对意外的延误，并且能够达成（非常大的）红利（如果达到），并且在财务上能够处理如果您不能接受处罚（例如被解雇），您可能会发现自己冒风险并签署合同是值得的“赌博”，并带有处理要求变更的合适条款。

这真是愚蠢。我不知道最终的目标是什么，但是负责软件产品的每个中途的项目经理都应该意识到估算值就是所谓的：估算值。它们不是承诺，如果不耗尽软件开发人员的全部精力或强迫他们破坏其“承诺”，就不可能实现它们。

如果您想显示这样的合同多么荒谬，这里可能有两个建议：

a）高度高估，以至该项目需要的时间是没有合同时的五倍或十倍。如果项目经理问为什么估算值如此之高，只需说您只是确保可以履行合同即可。

b）已经建议这样做：要求一份合同，以确保没有一项要求发生变化，并确保其中包括纠正拼写错误。根据我的经验，在开发过程中某个时刻需求不会发生变化的软件项目并不多。项目经理比您更有可能不得不违约。

如果项目经理会同意这两个建议中的任何一个，那么您肯定会知道它们不在脑海中。

顺便说一句，全职员工的合同将如何运作？我不了解其他国家/地区的工作规定，但是作为公司的全职员工，我认为没有人会强迫您签署具有约束力的合同，以在截止日期之前提出并拥有有效的案例。当然，如果您没有按时完成任务，他们可能会给您带来地狱，但是他们不需要为此而签订合同。没有人可以解雇您或给您更少的钱。他们可能在最坏的情况下削减您约定的奖金。因此，除非在其他国家/地区有所不同，否则这似乎是一种空洞的威胁，而不是您应该认真对待的任何事情。

我要反对这里的粮食。

您所描述的情况在工程团队一级并非异常，尤其是在项目/发布特别晚之后。在许多情况下，您的管理层和整个组织实际上可能已经签署了特定的发布日期，组织的其他部门也将为此日期作好准备。您的管理链可能要承受巨大的压力才能实现这一目标。

这是常规工程过程的起点。您可能听说过瀑布模型。还有其他车型，但所有这些的最终目标是始终如一地提供东西时预期以及含有什么商定。功能规格，设计，任务列表等都将使该过程成为可预测的过程。交流，风险分析以及（如您所说的）定期更新对计划的期望，可以减少意外情况并尽快提供信息，以便可以调整计划。是的，无论何时添加或删除功能，都应对计划进行调整。

在与我合作过的一些团队中，我会毫不犹豫地将我的估计视为已签署的承诺，但这反映了团队和管理层的素质，而不是任何特定的估计技能。一队是愿意签订合同交付时间是一个很好的工作团队的指标，而不是一个红旗。

我说让自己穿上鞋子，然后尝试了解是什么促使了这一点。从经理/会计的未来出发，他们需要一个数字来证明正在发生的事情以及事情的发展情况。

可能是因为要更改截止日期而在董事会会议室被嘲笑，错过了太多的最后期限，他尝试了最简单的方法将其锁定。请给我一个数字并在此处签名！您在另一端，可能只意识到这是对您不利的事情。他如何进行估算以及意识到需要对其进行调整，这对他来说更有用。如果您了解促使该请求的动机以及他面临的真正问题是什么，那么您也许可以为他和您自己提供帮助。作为程序员，我们解决问题。没什么两样，理解并解决他的问题，他将是您最好的朋友。有太多的工作要做，没有人有时间绘制个人仇杀！他的工作需要帮助，最简单的解决方案是让某人签字！可能他是从《傻瓜管理》一书中得到的：“让您的工人签名并帮助对数字负责。” 有趣但悲伤

“如果两者都被冻结，那么按照规范进行水上行走和开发软件很容易。”

爱德华·贝拉德

如果您的要求在变化，那么期望您的初始估计是准确的是不合理的。是的，这应该是一个危险信号。

合同是否规定了未按时完成的罚款？如果不是，那根本不是问题，您只是根据当时的知识在估计上签字。