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

理论的东西总不如实际的来的清晰，用一个例子来解释下吧.
以一个7人项目为例，简单的介绍下这个7人项目进行日计划的时间吧，按正常外包项目的成本估计，这个项目是一个10人月的项目，工期是两个月。公司一般会指派6名项目组成员，2名se，2名senior pg，还两名刚毕业不到半年的junior pg。包括项目经理1人，一共是7个人。
简单给下这个项目日计划项目经理的所需要的时间吧。

项目经理花在日计划的时间：
每天早上晨会5-10分钟
下午检查工作20分钟
PM花在项目日计划的时候是30分钟。
不要跟我说，项目组每个人每天都是满负荷8小时的。
30分钟的时候是非常容易抠出来的

项目组最好有一块白板，日计划真接写到白板上。晨会结束后再形成正式的文档。
把白板的草图转为正式的文档，可以你自己做，也可以交给一个初级程序员做。
更多的时候可以选择由一个初级程序员来做。（需要细心和责任心的程序员）
如果你的白板够大，完全可以把一周的日计划都放在白板上。

比如8:30上班，但是8:30所有人到齐的项目组很少。可能9:00才开始正式工作。
（打水，上洗手间，抽烟，吃早餐等等）

所以我的项目组都是要求所有人8:30准时到。
项目组的人养成了一个良好的工作习惯，工作效率也随之提升

按这个意思也就是在项目计划阶段，抽出时间来在完成项目计划的同时，日计划的方案要同时做出来，包括实际各种未知问题出现对日计划的影响以及相应的调整。
这个时间大致需要多久，按上述的规模来说，普通的以任务玩检查方式，一般项目的KT和计划阶段会在两周。如果同时把日计划制定出来大致会用长时间。

之所以日计划就是在每天晨会时制定当天每个人的工作任务，并且要求每个人都完成当天的工作任务。
并不会在项目的计划阶段就把整个后续项目生命周期的工作日的详细计划都列出来。
如果这样做是非常不敏捷的。
项目的计划阶段，只能是制定一个大的计划，阶段性的计划。具体有那些阶段由你采用的开发模型而决定。
如果没有特殊的原因，阶段性的计划一定确定就很少会更改。
但是这个计划太粗了，所以我们在实际的执行过程中需要根据大计划来指导制定不同周期的小计划。
每周要制定周计划，周计划是为阶段计划服务的。
每天的日计划就是为周计划服务的。
粗粒度计划的调整是比较少的
而细粒度计划的调整可以非常频繁。
计划可以贯穿于项目的整个生命周期，并不仅仅是项目的计划阶段

恩，这个我觉得很对，所以才想问一下时间的花费情况。
对于日计划，你的描述中只有早上例会的5-10分钟，下午例会的20分钟。
而日计划的任务分配又是在上午5-10分钟的例会就完成了，所以我才会想要知道需要多长时间来对计划进行细化，任务的分配需要考虑的因素有几个，项目的计划，项目目前的执行情况，每个项目成员的负荷情况，项目组成员目前工作的进度，已经突然从客户那获取的高优先级的变更等等。
5-10分钟的早例会时间仅仅够将准备好的计划告诉给组员的，那么前面综合各种因素，而得到日计划以及任务划分的时间大致回事多少，想具体了解下。

日计划是一个过程，产出就是任务分配。
也可以说任务分配是晨会中的一个重要活动。
任务分配的时间<=晨会时间
任务分配为什么会花这么少的时间？
通过每天下班前的夕会，你已经完全的了解了项目的状况，每个人的工作完成情况。
其实很多时间在夕会结束后你的心里已经有了一个草稿，第二天谁该做些什么？都基本清楚了。
为什么不在夕会中分配第二天的任务呢？因为日计划提倡日清日结。如果有人没有完成任务是要求加班完成的。完成任务的可以按时下班。
在晨会时可以把前一天的工作简单回顾一下。
另外有些任务相对没有那么明确，需要更细的分解。这时就需要由具体负责的程序员来提供一个分解。
所以晨会的时间非常短！
如果在晨会中引发了其它问题，通常是不去深入，记录下来，另外确定时间来讨论。
而不要在晨会中处理所有问题。
晨会的作用：1。明确当前状态
            2.当天工作任务分配清单（任务，优先级，责任人）

对于客户突然的需求变更？
这是一个需求变更的问题，如果项目组有一个良好的开发习惯就会避免这些问题。
比如变更流程，任何变更都不是马上答应用户的，需要有评估，分析。
另外，对于突发事情，也是经常有的。
但是记住一条，"只做最重要的事情。而不是做最紧急的事情"。

感觉还是和实际有一些差距，讨论了这么长时间，有几个地方仍然感觉和目前自己管理的项目有一定差距，可能还是由于项目类型不同的原因。
第一，即使在前一天已经了解项目目前情况的前提下，进行日计划得到任务分配的时间远远高于5-10分钟这个理想状况，如果说提前准备好了任务分配，用5-10分钟告诉组员今天的任务，并达到共识，6个人的项目大致需要15-30分钟的例会。但是从夕会结束，打好腹稿根据跟中情况得出任务分配大致需要30-60分钟时间。感觉根据目前状态给出明天一个员工的任务，不是简单的通过这个员工应有的效率，一霎那就可以得出任务量应该是多少，需要考虑的问题还应该有，这个任务完成对某个功能点时间的影响，推迟完成可能出现的问题，如果提前完成应该增加的任务，等等。另外有些特殊情况也是考虑的范围，比如某个任务对项目很重要，而执行任务的人员突然需要假期的问题。
第二，如果说晨会中只是通知下任务，而不与执行任务的员工达成共识而是另外确定时间来讨论的话，改任务的分配其实并不能算是成功的任务分配。额外的讨论时间仍然应该算是日计划任务分配的时间消耗。只有在达成共识后任务的分配才能基本算是有效的。
第三，其实在外包行当里，大多数情况下客户就真的是上帝，所以客户最紧急的事情就是最重要的事情，欧美的客户还好说点，通融度和态度比较好，应为欧美客户的概念就是，无论如何，最后结果是好的就好，所以如果他们的请求错了，你做了对了，结果没有问题。但是如果碰到日本客户，尤其比较变态的，他们的态度就是，无论项目成功与否，你给的服务我满意了就好，也就是说，他们说什么你们做什么就好，如果他们给出的错误的请求，你不执行而进行了正确的任务，他们反而会很生气，甚至直接用严厉的批评语气找你上级主管，你为什么不按我说的做，这种事以前公司遇到过几次了，血淋淋的例子。

通过讨论学习日计划，有一些收获：
在公司环境和项目类型适合的前提下，对项目计划尽量的细化，使得工作执行情况相应的细化，可以更加方便的监控项目，提高组员工作效率和项目进行效率。
通过任务分配时的会议形式，可以提高任务分配的效率，强化沟通，同时可以相应的以对比竞争的形式提高组员工作的积极性，也有助于所有组员对目前项目整体情况的了解，以后对自己工作的紧迫感认识。
日事日清的态度，可以理解为对于项目任务每天进行清查，即使任务是3天或者4天的，在时间允许的情况下，项目经理尽量多去检查，了解任务的进行。

这个需要去实践，实践了才会知道。
为什么我说8个人以内的项目晨会时间只需要5-10分钟呢。这是长时间的实践得出的结果。
而你说要15-30分钟，我就不知道了，最好是把你的实践说出来。
关于分配任务，并不只是简单的下达命令。如果真是这样，管理就太粗暴了。
对于成熟度比较低的项目，日计划是由项目经理来主导的。对于成熟度比较高的项目，项目经理来引导，程序员则占主导。
首先项目组要有统一的开发方式。也就是把任务分解为任务有一个套方法，大家都认可的。
因为分解为任务了，都是细粒度的工作，所以程序员很容易估算工作量。加上日计划进行多了之后，每个人的生产率已经有一定的数据了。
所以任务分配一般就是与程序员达成一致的过程。这个过程很简单。
当然也有“故事”不明确的，或者程序员对分解有不同意见，或者说程序员对这一块的需求还不明确，就不能够在晨会中来讨论。因为这会浪费大家的时间。可以先放下，先把其它人的任务分配完。
然后定时间与程序员讨论。让程序员明白要干什么。这是非常关键的。
对于需求变更，不管是什么客户，项目组都需要有一个变更流程。客户也是人，蛮不讲理的还是少数。主要还是在于沟通的方式。注意沟通的细节。如果没有流程，轻易承诺，其实对客户和项目组都是一种伤害。
但是要注意方式和方法。目的就是要双赢，站在对方的立场考虑，弄清楚他想要什么。

我非常喜欢“敏捷软件开发”。
但我始终不认为它是一个方法，而是一种思想。
如果你在实践敏捷时完全按照敏捷去做，反而就不“敏捷”了。

去实践一个方法是都会遇到一些困难，包括失败。很多情况不是方法有问题。而是执行的时候犯了错误。
比如有一个项目经理Q在实践日清日结时，他要求每个人每天都要把任务做完。
（首先这种方法没有问题，在我的项目组执行得非常好）
他项目组有一个工作年限比较长的程序员K，这个程序员的工作年限比项目经理Q的工作年限长。
项目经理Q在检查工作时，几乎是一种命令的方式和责骂的方式。结果程序员K要不就是不理他，要不就是直接顶撞。
一段时间后，程序员K离职走人。
后来，我们聊起这个问题。他说为什么会这样？是不是这个方法不行。
我跟他说，不是方法的问题。而是在执行的时候出了问题。
第一、尊重。（管理人员的责任之一就是要让员工获得尊重）
第二、找出问题的原因
第三、不要上升到人格问题，不追究历史旧帐
第四、给予指导，一起制定解决方法

这是一个很常见的案例。

还有就是要灵活运用，不能生搬硬套。不同的环境，不同的阶段会有不同的方法。

比如我监管的几个项目组。有一个项目组，几乎天天跟他们在一起。有些项目组却是一个星期去几次。
这个跟他们的成熟度有关系。成熟度高的项目组，因为他们已经形成习惯了，每天知道该做什么，并且不会拖延。
这样的项目组我并不需要天天监管。
相对于成熟度较低的，程序员工作都没有重点的，还没有形成良好习惯的就需要把他们的能力培养起来