我的员工中有一位开发人员长期超过截止日期和估计.在过去一周或两天的几个项目中,我听到"它应该在一天结束时完成".这个开发人员做得很好.
我已经和他谈过他的问题.他似乎真的很沮丧,并且对如何纠正他们感到恼火.
我的问题是:
通过截止日期的哪种惩罚措施有效？
我可以通过哪些方式强迫这名员工自己监督他的行为(时间估算等)？
更新:根据回复; 这就是我想到的.
惩罚是个坏主意.
员工很自然无法在没有干预的情况下解决估算问题.
除非因为当时没有完成公司后果(合同丢失),否则不要截止日期.
利用可用的方法(Agile,Joel的检查表)来帮助开发人员更好地估算.
感谢您的链接和信息.还要感谢更新我的想法.
我不认为问题在于他错过了这些截止日期.
我认为他在估算完成任务所需的时间方面存在实际问题.
让他开始记录他说任务将要采取的内容以及实际完成任务需要多长时间.最终,这本期刊将成为他创造更好估计的指南.一旦他变得更善于估计,他就不应该感到匆忙或匆忙.
Joel Spolsky撰写了一篇有趣的文章:循证调度
1)打破呃
当我看到在几天甚至几周内测量的时间表时,我知道它不会起作用.你必须将你的日程安排分成几小时内可以衡量的非常小的任务.不超过16小时.
这迫使你实际弄清楚你要做什么.写子程序foo.创建此对话框.解析Fizzbott文件.个别开发任务很容易估计,因为您之前编写过子程序,创建对话框和解析文件.
如果你是草率的,并选择大三周的任务(例如,"实施Ajax照片编辑器"),那么你没有想过你将要做什么.详细地.一步步.当你没有想到你将要做什么时,你不知道需要多长时间.
设置最多16小时会迫使您设计该死的功能.如果你有一个名为"Ajax照片编辑器"的手工波浪三周功能而没有详细的设计,我很抱歉成为那个打破它但你正式注定的人.你从来没有想过要采取的步骤,你肯定会忘记它们中的很多.
重点是他(和你)应该从他的错误中吸取教训,并在下一次估计中考虑到这些错误.
此外,如果您是开发人员,我会在一天结束时定期进行代码审查,以便更好地了解他的开发过程.
当然,更小的迭代次数和更多的任务粒度.将最长任务持续时间设置为1天.这是我们的规则.
如果你的第一个问题是 要考虑什么样的惩罚, 我认为你是直接失败的.如果你觉得他做得很好,你可能需要查看最后期限/估计,看看它们是否真的是现实的.谁设置了它们,如果有问题的开发人员没有参与,则可能是问题的一部分.
我同意@OTisler认为,结合编程以及可能与自己定期结束一天的进度审查可以帮助他完成......尽管如果最后期限/估计从那开始是不切实际的,那不是你的问题所在.
对一些具体任务进行更密切的监测应该突出问题所在.
通过截止日期的哪种惩罚措施有效？
没有.如果你激怒他,他就不会做这项工作,或者他会找到另一份工作.你应该帮他弄清楚为什么他的估计没有了.史蒂夫麦康纳尔有一本关于估计的书.我会从那里开始.
我可以通过哪些方式将该员工与他自己的行为(时间估算等)联系起来？
通过帮助他找到正确的估算方法.
首先,确保您的要求非常清晰.
我讨厌这么说,但根据我的经验,最后期限通常是一个不明确的要求或主管的规格薄弱的问题.首先要做的是确保问题不是源于您,也不是由您加剧.
此外,确保您的要求是现实的,以及他的估计.
确保你自己的期望不会促使他做出不切实际的估计,以满足不切实际的要求.
记住,你做了这些要求,但是开发人员总是做出估计,不应该动摇"我们能不能更快地做到这一点",除非你还要指定要删除的功能.
然后,确保他准确地跟踪他的时间/任务,这样您就可以很好地了解项目的进展情况.
此过程将显示缺少适当的时间/任务跟踪,这可能最终成为改进的第一步.如果你在项目之后看不到特定项目花了多长时间,那可能是问题的原因 - 估计中没有足够的定义,或者缺少在项目中间发现的"依赖"任务,但从未估计过.
你必须知道在找到蠕变的位置或者可以做些什么之前,准确地做了多少时间.
然后,看看他的估计失败并找出原因.回顾一个被吹制的项目的估计,把它变成一个项目本身 - 一个有待解决的问题.
一旦你确定他的估计确实是问题的根源,那就回过头来看看他和其他开发人员的估计,并找出原因.
这将帮助您找出问题的原因.对问题的充分理解可能是实际的解决方案.
最后,如果你真的达到了你必须尝试惩罚或胁迫的程度,那么现在是时候解雇他并重新开始.
在某些情况下,惩罚和胁迫是对故意不法行为的恰当回应.
但是,如果这位开发人员积极努力做好工作,那么你只会通过产生消极的态度和挫败感来恶化局面.
如果问题无法解决,而且你确定问题出在他身上,而不是你,那么现在是时候解雇他并找到一个能够满足最后期限的开发人员.当你的成本被炸毁并且利润消失时,伟大的工作并不意味着什么.
好的,这是相当普遍的 - 开发人员乐观.处理它是管理层的职责.如果有人应该受到惩罚,那就是经理(你？)
我很高兴你至少问过,看起来你从这个列表中得到了一些好的答案,我希望他们帮助你找到一种方法来实际实现一些工作.
当我年轻的时候,我的第一个好经理就是这样处理的:
首先,他让我提出了一个逐项列表 - 将任务分解为几个小时,并以非常宽松的估计估算每个任务 - 无论任务有多小,任何时期都不应少于4小时.
然后他看了看他们,并告诉我将我的估计加倍.(开发人员,特别是年轻的开发人员,如果你很幸运的话,你不会想到你只有大约一半的工作效率 - 而且其中一半用于你不希望有的事情.做).
然后,在创建他的日程安排之前,他将我的所有估计值加倍(不告诉我).
无论上面的时间表要求如何,他都以这种方式转向他们.一个好的经理应该意识到说它需要在2天内完成,但是不可能.
随着我在估计方面做得越来越好,我们都注意到并相应调整
管理人员的工作不仅仅是建立一个项目,而是建立一个团队.通常情况下,这将需要某种类型的培训.这也是非工程师的工程经理不能接受的原因,他们无法真正帮助解决这类问题.
项目或时间表的失败绝对不是开发人员的错(除非在一些他不能确定或有任何价值且需要被解雇的慢性案例中).经理在聘用开发人员,信任他,管理他或为项目配备人员方面做出了错误的决定.
真的,无论如何,什么是错？我想如果经理不是很擅长项目的实施,那他就需要有人指点......如果HIS经理有任何好处,他会问为什么会这么做,你做了什么来解决它等
聘请经理正在雇用某人来解决问题.使开发人员富有成效.如果他不能使他们富有成效,他就不是合适的人.
京公网安备 11010802040832号 | 京ICP备19059560号-6 