it-swarm.cn

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

在以前的工作中,项目经理(PM)对我所在项目的代码交付时间不满意。我的项目负责人告诉我,PM正在考虑让我签订合同以锁定我的时间估算值我给出了任务和交货日期。

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

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

在我看来,PM)希望将他的数字加起来-因此要我签署合同以“确保”我将始终按时交付工作代码。如果签订了合同,PM如果我不能按时交付,可以对我不利。

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

我的问题是这是否会引起经理人的危险信号?经理人通常会锁定签订了合同的软件开发人员的时间估算吗?或者在这种情况下,请尝试。

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

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

116
spong

我的问题是,这会引起经理人的危险信号吗?

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

管理人员以签署的合同锁定软件开发人员的时间估算是一种惯例吗?

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

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

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

109
Tangurena

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

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

160
whatsisname

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

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

59
Slawek

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

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

31
Pemdas

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

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

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

27
Steven A. Lowe

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

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

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

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

19
Michael Brown

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

14
ThomasW

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

在开始之前,请注意PM很可能会给您带来悲伤,因为食物链上其他人正在给他们带来悲伤。他们(我们)是简单的生物...为避免您所描述的情况-Mike Brown对此进行了很好的介绍。在开始之前连续进行3/4/5 ..小时的工作也没错(实际上,如果不这样做,则所有警报都需要关闭)如果您要进入未知的领域,请往后推并要求一个星期来研究该区域和技术,以便能够做出合理的估算(您需要正确地执行此操作,因为您希望学习新技术并与您一起玩吗?)。如果您PM)和您所在位置的管理人员不了解这一点,请更新您的简历并寻找最近的出口,让他们拥有应有的应有的命运。PM甚至会考虑让全职员工签署这样的合同,这是一个糟糕的坏信号。 n ...我看到他们可能并非完全无能的唯一方法是,他们实际上只是在与项目负责人一起玩思维游戏,而您(根据我的阅读,他们并没有直接将这些信息提供给您,也没有最终解决威胁)。 毕竟,PMing是您的标准公司心理变态者的避风港。最好的是其他人也照着您的话为您效劳,所以下面的建议会最后可能对您有利。我想,如果事实证明不仅仅是谈话,他们本来将有一场革命。

因此,您描述的实际情况/漏洞,因为它将再次发生在某人某处(例如大约5分钟前,然后在另一个5中,scheduleRepeat())。可能没有合同愚蠢,但基本故事情节始终是相同的。组织会议(!),他们喜欢会议;-)每个人都可以像实际完成的操作一样在最后轻轻拍打自己。 重要:确保在会议邀请中包括您的技术项目负责人/团队负责人/架构师/设计经理,请他们与他们一起解决问题并将其加入董事会。您可以为“身边”的人选择的等级越高,越好。因为您PM ,因为现在他们可以被当场解雇的人看到了,如果他们与您一起玩游戏,则您可以退还该收藏。

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

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

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

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

10
nomaderWhat

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

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

9

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

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

8
Larry Coleman

就像其他所有受访者一样,我完全同意这会引起危险。

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

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

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

许多人仍然对这个概念有麻烦,听起来您的PM也确实如此。这归结为对权衡的简单理解。

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

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

进行这项工作需要双方,产品所有者(代表您PM或客户或质量检查团队)的敏捷代表)和开发人员之间的“合同”,开发人员同意仅处理优先事项。对于给定的迭代而言,它是最重要的,并且不会花很长时间,而是努力频繁地(例如每周或每月)发布完全集成的功能块;相反,产品所有者同意持续审查增量版本并提供及时反馈。也同意为下一次迭代设置优先级,并且一旦设置为在迭代持续时间内不改变主意。

协议的后半部分是您PM)可能不了解的。许多传统的PM实际上不了解。其中一些人认为当他们脱离规格时就完成了工作;不利的一面是,这不仅阻碍了软件开发的流程,而且还给企业留下了很多机会,从而伤害了组织。

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

祝好运。

4
Wolfram Arnold

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

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

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

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

4
martinws

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

2
PSU

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

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

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

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

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

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

1
Mike Dunlavey

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

爱德华·贝拉德

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

0
Bill the Lizard

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

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

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

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

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

如果您能够提名自己的截止日期,并且双方都可以接受一定数量的填充,以应对意外的延误,并且能够达成(非常大的)奖金(如果达到了),并且在财务上能够应付如果您不能接受处罚(例如被解雇),您可能会发现,冒风险并自己签署合同是值得的“赌博”,其中包括处理要求变更的合适条款。

0
Oddthinking

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

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

0
Arjang

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

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

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

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

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

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

0
Anne Schuessler

我要反对这里的粮食。

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

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

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

0
TREE