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

代码行数跟技术没啥关系

同样功能或者业务逻辑，实现同样的效果，技术好的同学可能会用更少的行数完成，也会更注重复用性和扩展性。

实际上我见过有些人一个action里一个方法写几百几千行代码，那是一层一层的if else
但实际上每个方法里面80%的代码是可以抽象出另一些方法的

如果我当时是项目经理的话，这种写法我肯定要他打回去重写

灌水充行数很容易做到的

非常好的一篇文章。。

用代码行来计算工作效率是有问题的

本文使用代码行作为工作量单位也是不得而为之。
当然还有功能点等，可能更复杂。但它都不是本文讨论的重点
欢迎一起讨论日计划。本文的主题是日计划。

楼主提到的 “工作成熟度”很有道理。
日计划初期实施对项目经理要求比较高，一旦形成惯性，对项目管控非常有帮助。
赞同楼主

是的。项目的成败与项目经理的关系非常大。
很多人初次管理项目时，就陷入编码去了。没有划出时间去进行管理。
日计划就是要求项目经理每天抽出时间进行项目的管理。
这样占用的时间其实非常少。
晨会10分钟，夕会20分钟。
很多项目经理都说没有时间，以项目进度很紧，人手不够等理由来为自己推脱。
其实一天抽出30分钟是很容易的事情。少两次则所，小抽两次烟。

程序员个人管理和经理的管理相结合，要程序员听话，有安全感对经理素质要求很高

不可能在项目初期就形成那么详细的日计划吧？

我现在做的就是把项目分成1-2天的工作模块，然后制定进计划里。
但是针对于每天的详细计划，感觉还是比较困难。

看得出LZ写的这篇文章是通过自己很好的实践过，得出的一套经验办法
很值得学习，先谢谢LZ了

不过就像LZ说的，这些东西都还是要看执行力，及项目经理的能力，就像每个的日计划，想做好也是一件不容易的事情，很期待LZ对如何分配日计划的讨论

项目的执行力，项目经理占了很大的原因。
同一个项目，相同的人，换了项目经理后产生了完全不同的执行效率。
这就是管理的作用。
如果大家都认为这不可能，也就没有管理这门学科了。

管理最核心的几点就是目标，计划，实施和监控。
项目管理也是一样。
如果所有的项目都依赖天程序员听话，那是很难的。
程序员听话与话还是看项目经理的手段。看你对他的支持度有多大，看你对工作的追踪力度有多大。
无限度的加班也是因为追踪和检查的力度有很大的关系。

如果要想把项目做好，就需要把追踪做到位。时时了解项目的真实情况，不致于使项目失控。