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

#1 楼

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


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


经理通常会用签订的合同锁定软件开发人员的时间估算吗？


我从来没有听说这是应用于员工的。

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

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

#2 楼

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

如果我一直担任这个职位，出于个人娱乐考虑，我会要求经理签署一份冻结所有要求的合同。我想经理可能会保释。那我就走了。

#3 楼

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

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

#4 楼

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

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

#5 楼

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

如果持续不断地估算和截止日期，合理的做法是找出原因并改善流程。

如果因为不知道要去哪里而责备和踢马，那匹马咬住你并逃跑也不要感到惊讶！

#6 楼

当经理不符合他的要求时。他没有完全责备。如果您在完全陌生的地区工作，那么说“我不知道”没有什么不妥。我花了一段时间才意识到“我不知道”是一个完全可以接受的答案，所以我知道说出这些话有多刺痛。但是，如果您真的不知道，那就是答案。如果他们不愿这样做，请他们给您一个估计，要像西尔斯大厦（变成威利斯大厦）那样高，要花多少便士。并且他们愿意签署一份合同，向他们支付每分钱的薪水吗？有时事情完成后就完成了。我认为通过在已完成的工作上取得进展，您的状况很好。只需停止提供数字更新即可。

另一个练习是将大型任务分解为更小的可估计的较小单位。此练习将帮助您更好地了解您需要做的事情。分别查看Steve McConnell的软件估算和Stephen Withall的软件需求模式，以获取分解任务和发现隐藏需求的提示。花时间分解它。估计大量的小任务会给您带来更好的总体估计（由于平均数定律，您的一些估计会低于，但有些估计会超过，并且它们往往会相互权衡）。

#7 楼

问您的“项目经理”：我们是在销售软件还是在最后期限？

#8 楼

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

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

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

在会议上，详细介绍您正在处理的技术细节以及为什么要花一些时间。他们应该想知道这一点（以及如何帮助您完成任务），但是可悲的事实是这通常不会发生……您可能需要10分钟的时间才能回过头来。现在我想在这里做的事情可能是不合法的……是的，我检查了一下，实际上这是高度违法的，您也不想长期入狱。关键是您已尽全力积极主动，如果您有一些高高在上的人，那么您的痛苦现在就在他们的……应该如此。您将不得不对可能的结果进行判断，因为将要发生“升级”。如果您所处位置的领导者过半体面，他们将做正确的事，也将由您做正确的事。如果不是这样，那么您将事先将履历表放到市场上……无论如何，您将第一个机会离开（并且看起来您最终会这样做）。领导者将分为两组-要么在技术上精明，他们将立即看到您的观点；还是他们不是，除了忍受它之外，他们将如何做？如果他们可以做您想做的事，那么他们早就已经做了。项目本身和该死的客户/利益相关者将被徒劳地取名。最轻松的方法是在项目上进行某种重置，也许可以将PM悄悄地重新分配到其他区域。偶尔会发生奇迹。如果项目经理在会议上提出合同问题，则撤回要求冻结反合同需求-就我而言，他们开始时已经与您以及整个开发团队建立了桥梁玩这类智力游戏。

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

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

#9 楼

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

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

#10 楼

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

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

#11 楼

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

项目经理似乎不想参与开发过程。

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

之所以如此，是因为敏捷和精益软件专家中的许多人都在谈论这种实现，即该软件不是固定的可制造实体，而是主要是发现的过程。

许多人仍然对这个概念有麻烦，听起来您的PM也一样。归结为对权衡取舍的简单理解。

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

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

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

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

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

祝你好运。

#12 楼

听起来好像经理在向上司汇报时正在寻找某人的责备。最好的办法是考虑一个非常慷慨的估算期，然后再将其加倍！

，还迫使管理者确保对要求进行充分详细和确定。如果没有新的完成时间与项目经理进行“正式重新谈判”，此后的任何更改都将无法解决。

#13 楼

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

#14 楼

到处都有好的答案，但让我加2美分。那是一个您不知道其值的数字，但是您可以用正态（钟形曲线）分布或其他分布来描述您不知道的值。

重点是，这项工作将需要一定的时间，但是任何先前的估计都会在负面或正面方面或多或少错，因此存在风险，因此有人必须冒险。 ，他们就为此付费。
保险要花钱。使用时间和材料，客户将承担风险。以固定价格，我要承担风险。使用固定价格，我可以保证安全，因为如果我未能达到目标，则没人会赢。

让您承诺一个固定的交货日期，尤其是在没有固定要求的情况下，听起来像即使尚不清楚您实际上在冒险什么，也要设法将风险转移给您。在任何情况下，一种反应就是简单地增加真正的安全裕度。

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

#15 楼

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

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

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

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

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

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

#16 楼

这真是愚蠢。我不知道最终目标是什么，但是负责软件产品的每个中途的项目经理都应意识到估算值恰好是他们所说的：估算值。他们不是诺言，也不能做到这一点，否则要么耗尽软件开发人员的全部精力，要么反正迫使他们打破他们的“承诺”。

如果您想展示这样一个荒谬的做法合同，可能有两个建议：

a）高度高估项目的时间是没有合同的情况下所需时间的五到十倍。如果项目经理询问为什么估算值如此之高，只需说您只是确保可以履行您的合同即可。而不是单个需求更改，并确保其中包括纠正拼写错误。以我的经验，在开发过程中某个时刻需求不会发生变化的软件项目并不多。项目经理比您更可能不得不违约。

如果项目经理同意这两个建议中的任何一个，您肯定会确定他们不在意。

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

#17 楼

我要反对这里的粮食。

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

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

在与我合作过的一些团队中，我会毫不犹豫地将我的估计视为已签署的承诺，但这反映了团队和管理层的素质，而不是任何特定的估计技巧。愿意签署按时交付合同的团队是一支工作良好的团队的标志，而不是危险信号。

#18 楼

我说让自己穿上鞋子，然后尝试了解是什么促使了这一点。从经理/会计人员的角度来看，他们需要一个数字来证明正在发生的事情以及事情的发展情况。尝试了将其锁定的最简单方法。给我一个数字，然后在此处签名！您在另一端，可能只意识到这是对您不利的事情。他如何进行估算以及意识到需要对其进行调整，这对他来说更有用。如果您了解促使该请求的动机以及他面临的真正问题是什么，那么您也许可以为他和您自己提供帮助。作为程序员，我们解决问题。没什么不同，理解并解决他的问题，他将是您最好的朋友。有太多的工作要做，没有人有时间绘制个人仇杀！他的工作需要帮助，最简单的解决方案是让某人签字！可能他是从《傻瓜管理》一书中得到的：“让您的工人签名并为数字负责。”有趣但难过

#19 楼

“如果将两者冻结，则可以轻松进行规范的水开发工作。”
-Edward V. Berard

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

#20 楼

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