总结一点项目管理知识，虽然自己还只是一个代码工人

把自己看做是代码工人的人，也只能看到这些东西。

 

1.各个模块的细分是在概要设计和详细设计中体现的。 属于设计范畴。任务划分不仅仅是功能点同步。 比如搭建数据库环境， 同步数据， 接口讨论等，都不是功能点，因此要创建WBS进行管理， 任务划分粒度与你的资源有关， 资源就是干活的人， 对于能力强的人，那么任务粒度就可以粗一些， 对于能力较弱的或者责任心不强的人， 任务粒度就要细一些。 这个需要磨合。 没有能一概而论的。

 

2、3周一开会， 周五开会， 或者，上午开晨会，下午开晚会。 都不是我喜欢的做法。 开会最浪费时间， 要集齐那么多人， 要打算人家手里的活，思维。要等人。要找会议室。会上一堆人事不关己。 总之， 我向往的沟通方式是随时沟通， 精确沟通， 没有固定的时间和形式。 大多数时间不需要会议记录。 除非重要的。你需要整天沟通， 而不是会上那一点点时间进行沟通。

 

4.控制项目进度， 控制进度的最好办法是进行良好的设计和准确预测风险。在业务讨论不清的情况下，开发时间无法控制，也许你完成了，但是要返工。这种情况最难把握。工作原则上，我喜欢控制到半天， 一上午或者一下午。这样至少一天会有两次正式沟通。便于掌握项目情况。

 

5。这个最麻烦，有时候感觉项目经理就是个测试人员。

 

6、7 我唯一能给组员的激励性的承诺就是，咱们上班的时候好好干，下班就不用加班了。。。。仅此而已。

 

 

你所说的项目管理，是一种没有项目蓝图的项目管理，是没有架构师知识背景下的项目管理。就好象一个包工头找一帮民工来盖楼，之前只是从废品堆中扒拉出一张设计草图。

其实架构和设计还是设计的关键点，只不过核心人物也许不会给你看。

设计者的作用占系统成败的70%以上，如果认为知道点功能点然后分工大家去分解就能代替系统设计，那么往往只能在小软件作坊里做赝品。实际上，如果设计文档可以注定其成功，那么才真正应该敢于继续去投资开发软件。现在有那么多搞软件的人失业，因此不缺抢着干空洞的功能分解工作的小程序员了，则更显出缺乏“先知先觉”的产品负责人了。

敏捷不是不做设计，只是换了一种看问题的角度而已，只不过把过去用教条方式说出来的“计划”现在用测试代码来写，写不出测试代码说明对应的设计也不现实。因此推动了注重扩展性、注重实用性的风格。

学敏捷的人也容易犯一个毛病：回避一个软件真正的技术问题而仅仅抓住一些行政问题，对设计问题张口闭口总是“到时候我会分工给手下人加班加点”来代替提出真正令人信服的系统设计文档，这过于急功近利过于对流行东西现学现卖。尽管知道做任务计划要细分到1、2天，尽管知道布置任务要说的清清楚楚，但是其实是加大了技术难度而不是减少了技术难度！所以既要做细又要做对，就只有更少的真正有经验的PM才能做好，一般人是做不好的。

如果没有掌握很深入很过硬的设计和测试技术（头脑中有独特的理论方法、手中有自己开发的工具），那么单纯去模仿敏捷就会变得很虚伪——其实单纯模仿敏捷跟鼠目寸光有什么区别？时间长了人品也变得虚伪了，所以敏捷绝对是有害的东西，只有真正的架构师、产品设计师才能偷偷研习。

敏捷原理只要知道就可以了，好好研究它技术的一面吧！