软件项目管理实践之日计划

恩,tuti 所言即是. 我为止付出了整整一年多的时间在反思这些东西.其实我所说的是,一个项目经理的执行力. (作为项目成员大家都想能圆满顺利的完成,尤其是在项目工期比较紧张的情况下. )

正如楼主所说,


从任务分配以及项目进度的控制上,如果项目经理的执行力不够,或者工作重点放错了位置,这无疑是致命的.这也是为什么有的时候楼主亲自实施这个计划的时候,效果就显而易见,而一旦换人就恢复原样的原因.

而我们当时日计划方案之所以会趋于形式化,其实当时情况特别复杂,但,当时的我远没有深刻体会到楼主写这篇文章的深度.认知度的不够就会导致执行力的偏差.而且当时根本没有从全局去考虑问题,只是习惯性的从技术思维来看待管理.所以当时的晨会和夕会成了大家交流出现的bug和技术难题上了(也确实当时在工期紧的情况冒险使用了新技术,这又验证着楼主所谓的项目经理需要识别风险的道理). 从而根本没有从整体来追踪和控制项目的进度. 虽然最终项目还是完成了,但,那次失败的惨烈让我如今仍不寒而栗!

多看看agile的资料，会有很多收益。
我觉得楼主的日计划也可以看作scrum的一种变例。

首先谢谢你参与此贴讨论。

关于日计划流于形势，笔者也深有体会。主要是在我监控的项目中出现。
我们可以分析日计划流于形势的原因（以我本人遇到的情况来看，当然希望大家提出更多的案例）：
1.每天分配的任务都不能完成，使日计划无效
  也就是项目经理每天晨会分配的任务，在下午检查时，发现很少有程序员能够完成当日计划的工作。
  这种情况一般发现在新组件的项目组。项目经理对程序员的能力还没有完全了解。
  我们一定要相信“个体差异”。所以项目经理需要充分的了解每个程序员的能力，特点。分配给他最合适的工作。
  其次就是在分配任务之前，要与程序员讨论。提供思路。也就是对程序员的指导和帮助。但并不是我们帮他去做。
  这就是一个项目经理的预见性和教练能力。
  当分配了一个任务给程序员甲时，我们要充分的识别出这个任务程序员甲是否能够完成，他会遇到什么困难。

  在我监控的一个项目B，项目经理X要求程序员T写一份方案。正好那天我在现场。
  项目经理X：“程序员T来完成这个方案吧？你看要多长时间”
  程序员T：“大约需要3天时间吧!”
  我：“你需要3天时间的理由是什么？”(因为我了解到程序员T只有一年工作经验，属于初级程序员)
  程序员T：“因为我对该方案的逻辑还不清楚，很多东西得请教别人。”
  我：“3天你能保证做完吗？”
  程序员T：“不能，我尽力”
  我：“你写这个方案的最大难点是什么？”
  程序员T：“只有一部份业务逻辑我是清楚，但是另外两部份业务逻辑其它同事做的，我不清楚。需要有人支持我”
  我：“项目经理X，项目组有谁对这些业务逻辑是最清楚的？”
  项目经理X：“程序员G最清楚，而且他已经有一些成型的想法”
  我：“项目经理X，你清不清楚所有的逻辑？”
  项目经理X：“清楚”
  我：“OK，去把程序员G叫过来，再搬一块白板过来！相关的人员也过来，我们一起来讨论整个方案的逻辑”
  .........大家花了20分钟讨论，把方案定了下来。
  我：“程序员T，编写这个方案还需要多少时间？”
  程序员T：“依这样看，一天吧”
  我：“需要一天的理由是什么？”
  程序员T：“这个嘛。。。。。，以前没有写过”
  我：“方案已经定了，现在我们把内容定一下，把模板找来。”
  我：“现在这个方案还需要多少时间？”
  程序员T：“半天吧”
  我：“OK，给你一天时间。因为还有返工的内部评审,在明天中午下班前提交给项目经理X，如果需要修改就在下午完成”
程序员T，项目经理X：“OK”
这是一个真实的场景。
  项目经理X分配任务时犯了一些错误。
  首先人选不适合，但是他当时也没有办法。结合项目当时的实际情况，一定要把项目精干力量都放到最重要的事情上去。
  他把方案编写这个任务给了一个没有相关经验的初级程序员。又没有识别风险。程序员在接受这个任务时承诺的时间是自己瞎猜的。自己根本就没有底。项目经理在分配任务之前根本就没有去做相关的分析。
如果我们没有花20分钟去帮程序员T做分析，把方案的草稿确定下来。程序员T承诺的时间根本就是一个不可靠的时间。
如果这样的事情出现过多，日计划也就失去了作用。因为他总是不能完成嘛。

二、事务性的任务没有列日计划。
 
在日计划中，项目经理X给程序员T，C，D和自己分配了当天的开发任务。
但是我在抽查中，发现所有的程序员都没有做当天的任务。
项目经理X突然接到客户方的要求，要为项目上线做一些准备工作。
程序员T说昨天还有一些工作没有处理完，要继续处理。
程序员C在修改昨天的BUG
程序员D自己在写一个DEMO程序（后期会要用到这个技术）

这是一个什么情况？
首先，当日的待处理任务清单里面有遗漏。
可能项目经理X认为：“为项目上线的准备工作”不熟于开发任务。所以不列进日计划。
这也正是SCRUM的一些不足之处。
但是这的确是今天想要做的事情之一。
每个人都有自己想要做的事情，肯定没有充分的反馈给项目经理，项目经理也没有了解到这些情况。

我们该怎么办？
首先要明确本周或本阶段的目标是什么？
其次就要把今天需要做的任务统统列出来，陈芝麻烂谷子的事都可以列出来。
然后为每个任务设计优先级。
然后确定今天必须要做哪些事情，哪些可以放在一边。

这样就避免了，做事没有主次，轻重。
特别是在有突发性任务时，项目经理一定要清楚。然后再进行取舍


三、放纵
  我们一定要相信个人差异。有些人能力强些，有些人能力差些。有些人做事快些，有些人做事慢些。
每个人的生产率并不相同。
  在项目A中，程序员Y做事比较慢，习惯了慢速度。而且别人不能打扰他。一旦受到打扰，当天的工作很难完成。
项目经理J向我反映说程序员Y总是不能完成日计划的任务。
  我：“任务是否过重？”
  项目经理J：“不是,大部份人都能完成”
  我：“任务难度大，相关技术Y没有掌握？”
  项目经理J：“不是，技术没有难度”
  我：“原因是什么？”
  项目经理J：“主要是程序员Y不能受到打扰，如果遇到突发事件或别人打扰，任务就不能完成？”
  我：“你是怎么处理的？”
  项目经理J：“ 我也没有办法，他还是很努力的。”

这才是真正的执行力差，所以日计划是要与考核挂勾的。如果做完和不做完一个样，那大家都选择不做完好了。
所以项目组一定要有制度，制度不是用来压人的。但是是一个底线，任何人都不可以越过底线。否则就绝不手软


 

我觉得根据当天的工作完成情况，计划第二天的工作任务，并分配给适合的开发人员，是一个比较耗时的过程。
这个工作是由项目经理来完成的吗？是不是项目经理就需要加班才能完成这些事情呢？

那你们的情况是怎么样呢？

  这个案例没说完啊，后来怎么处理的，效果如何？


能否说具体是什么样的制度？实施效果如何？

跟考核挂勾。
1、如果不是因为任务分配问题导致的不能完成，则要求加班完成。
2、每天，每个人的工作完成情况记录在案（工作量，效率，质量），月底考核以此为据。具体的制度我就不说了。

工作量，效率，质量 都是以什么指标来度量呢？

记得以前的公司,曾经实施过一种工单制,项目经理把每项任务量化成一张张的工单.在填写工单前,会和开发人员进行详细的沟通,以确认工单派发的合理.然后签字画押...

每张工单的完成情况会由技术总监派发给测试组进行考核,然后综合评定.

每月工资 =  基本工资+(实际完成工单数*日工资*老总定的一个百分比的基数) 

(该公式在后来本公司的OA中进行了更详细的算法,也会根据员工最近的表现以及工作态度等等指标进行综合评定)

想实现多劳多得,而且如果能在10-15天时间完成本月工作量,你可以选择继续完成工单多拿钱,或者选择休假.

PS:该制度最后由于大量人员因为工资拖欠的问题的流失而最终流产.. 

感悟:

一个好的制度需要有一个良好的环境和boss的全力支持!

我们目前不是这种开发方式，因此无从谈起。
我只是从你说的开发方式，感觉到项目经理(或者说是故事划分，分配的角色)的任务比较重，不知道你们是不是这样的？
或者是不是项目前期开发人员也参与故事划分？