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

计划是一个逐渐由粗到细的过程。
即然是日计划就是可能是在项目初期就把每天的计划都做完。这正好犯了大忌。
日计划应该是前一天下班前有一个大体的思路。在晨会中与开发人员达成一致。
但千万要记住日计划一定要为周计划服务。
每个小阶段的计划都是为大阶段计划服务的。

关于执行力，就是习惯成自然的事。关键还是在于坚持。只有长期做才会有效果。
关于如何分配日计划，最简单的就是在每天晨会中项目经理把每个人当天必须要完成的任务列出来。在下班前检查任务完成情况。并且与考核持勾。当某个程序员的任务不能完成时就需要查明不能完成的原因是什么？

当然，当在日计划的“任务”分解可能与传统的项目管理不同。但是可以参考SCRUM是怎么分解任务的。
SCRUM的“任务”都是依据于每一个“故事的”。这样可能有些临时性的，不属于故事的任务就不能纳入计划。
而日计划更灵活，任务事情，只要是属于项目开发的任务都可以纳入日计划的“任务中”。

赞同此观点，身有体会

管理成本过高，这个问题比较明显。在有些一个管理人员成本比4，5个技术人员还高的地方，加大管理人员投入的性价比也是需要参考的一个方面。毕竟项目是以收益算的，并不是项目越成功越完美，项目收益就越大。
日计划依赖于整体项目计划，需要严格的项目整体计划，项目日计划才能比较明确到细节，这样也有两个问题，第一，如果项目需求变更频繁，那么在更大程度上会更加依赖于管理人员的能力，需要更加灵活的分解任务，变更项目计划制定日计划，管理成本进一步拉大。第二，客户的信任度问题，客户给定的时间内极大部分看不到项目成果，只是一大堆的计划，文档，在项目需求变更时可能需要等待的时间更长，如果项目失败，对客户信任的打击会更大。
然后日计划跟流水线同样需要预防的副作用，对项目整体的认识度差，可能出现的情况就是项目开发人员对项目的认识就只是一堆task而已，每天只需要等待发来一本任务，然后做完完事，很多日本的外包公司都是这样，需要谨慎预防。

这就涉及到职业道德。这是个整体的素质，很多人都是这样。

如果一过连计划都不想做的项目而取得成功几乎是碰运气的。
如果一个项目连整体计划都没有，阶段计划又没有细化。那这样的项目只是望天收成。
什么叫管理成本过高？
计划就是叫做管理成本过高？
当一个项目能够比普通团队提高一倍的生产率，也就是说普通团队要6个月。而有良好管理的团队只需要3个月。这是管理成本过高还是过低呢？
可能大家还是习惯于想到什么就做什么吧，缺乏规划。

其实不要担心。
比如防止程序员等任务做的情况发现。
但是不做日计划，程序员不就只是等任务做了。而是在那里拖延。
日计划是有目标的，有优先级。而且还要与周计划挂勾。
日计划是为周计划服务的，周计划是为阶段计划服务的。
每个阶段都要有非常明确的目标。
并且要可交付的成果。
日计划就是改变了以前项目经理期待程序员自觉完成。变为项目经理可以在了解程序员的每个过程。
这样项目经理就可以根据实际情况做出调整。
另外，日计划不是在项目一开始就把每天的工作分配完毕。这是不可能。
日计划是依赖于当前的项目情况和周目标或阶段目标。
让程序员做重要的事情。使整个项目团队都是在做最重要的事情。

感谢楼主的原创以及分享这么宝贵的经验. 我们以前也执行过类似楼主的日计划方法,不知道什么地方出问题了,日计划模式趋于了形式化. 看完楼主的文章,我想是执行力和任务的追踪程度上出问题了...

可以参考Scrum 的做法。
跟你这个的目标和做法还是比较类似的

动不动就说什么执行力，多找找靠谱的原因