总结一点项目管理知识，虽然自己还只是一个代码工人
工作中学到的一点知识：
- 细分各模块。将项目的各个模块进行细分，细分为子任务，子任务可以根据实际情况进行再细分。
每周一开会。讨论本周或接下来两周的整体工作，具体要达到怎样的一个目标。每周五开会总结。最好在下班前0.5-1小时时开会，不要占用项目成员的下班时间。总结本周所完成的工作，查看实际效果，将成果与预计的做一番比较，为项目进度做出更好的评估。（对下班后再开会总结感到反感）
控制项目进度。工作细分到1-2天，效率比较高。对项目成员成果的确认。每当项目成员完成某个功能，无论大或小，都要进行确认。最后是在做完以后，项目成员主动发出通知，大家一起审阅一番，同时给出意见。这样能确保功能更加完善，减少后期积少成多各种不完善的修改。让项目成员们更主动些。有下面几种情况经常会延误项目进度，使项目大大超出原有的预算：1)、遇到风险(代码实现上的)没向上级汇报? 2)、开发过程中发现实际工作量超出原有的评估，未及时向上级汇报? 3)、没完全清楚需求，就盲目的进行编码，等发现问题以后为时已晚。 看来许多都还是沟通问题
给项目成员一定的承诺。为了提高项目成员的工作激情，工作劳累的同时，要给予更多的鼓励，给予一定的承诺，前提是这个承诺一定要能够实现，不要让成员们认为你是在忽悠。
说别人的同时请拿出自己的东西，否则只会被大家鄙视。 22 楼 yiding_he 2009-12-01 项目是由人组成的，对项目的管理是对人的管理的一个子集。所以任何对项目的管理方式绝不能违背对人的管理的原则。时常提醒自己这点，才能避免失败。 23 楼 phoenix1100 2009-12-06 <div class="quote_title">hotjava 写道</div>
<div class="quote_div">
<div class="quote_title">zhanjia 写道</div>
<div class="quote_div">
<p>工作中学到的一点知识：</p>
<ol>
<li>细分各模块。将项目的各个模块进行细分，细分为子任务，子任务可以根据实际情况进行再细分。<br>
</li>
<li>每周一开会。讨论本周或接下来两周的整体工作，具体要达到怎样的一个目标。</li>
<li>每周五开会总结。最好在下班前0.5-1小时时开会，不要占用项目成员的下班时间。总结本周所完成的工作，查看实际效果，将成果与预计的做一番比较，为项目进度做出更好的评估。（对下班后再开会总结感到反感）<br>
</li>
<li>控制项目进度。工作细分到1-2天，效率比较高。</li>
<li>对项目成员成果的确认。每当项目成员完成某个功能，无论大或小，都要进行确认。最后是在做完以后，项目成员主动发出通知，大家一起审阅一番，同时给出意见。这样能确保功能更加完善，减少后期积少成多各种不完善的修改。</li>
<li>让项目成员们更主动些。有下面几种情况经常会延误项目进度，使项目大大超出原有的预算：1)、遇到风险(代码实现上的)没向上级汇报? 2)、开发过程中发现实际工作量超出原有的评估，未及时向上级汇报? 3)、没完全清楚需求，就盲目的进行编码，等发现问题以后为时已晚。 看来许多都还是沟通问题<br>
</li>
<li>给项目成员一定的承诺。为了提高项目成员的工作激情，工作劳累的同时，要给予更多的鼓励，给予一定的承诺，前提是这个承诺一定要能够实现，不要让成员们认为你是在忽悠。</li>
</ol>
</div>
<p>?</p>
<p>1.各个模块的细分是在概要设计和详细设计中体现的。 属于设计范畴。任务划分不仅仅是功能点同步。 比如搭建数据库环境， 同步数据， 接口讨论等，都不是功能点，因此要创建WBS进行管理， 任务划分粒度与你的资源有关， 资源就是干活的人， 对于能力强的人，那么任务粒度就可以粗一些， 对于能力较弱的或者责任心不强的人， 任务粒度就要细一些。 这个需要磨合。 没有能一概而论的。</p>
<p>?</p>
<p>2、3周一开会， 周五开会， 或者，上午开晨会，下午开晚会。 都不是我喜欢的做法。 开会最浪费时间， 要集齐那么多人， 要打算人家手里的活，思维。要等人。要找会议室。会上一堆人事不关己。 总之， 我向往的沟通方式是随时沟通， 精确沟通， 没有固定的时间和形式。 大多数时间不需要会议记录。 除非重要的。你需要整天沟通， 而不是会上那一点点时间进行沟通。 </p>
<p>?</p>
<p>4.控制项目进度， 控制进度的最好办法是进行良好的设计和准确预测风险。在业务讨论不清的情况下，开发时间无法控制，也许你完成了，但是要返工。这种情况最难把握。工作原则上，我喜欢控制到半天， 一上午或者一下午。这样至少一天会有两次正式沟通。便于掌握项目情况。</p>
<p>?</p>
<p>5。这个最麻烦，有时候感觉项目经理就是个测试人员。</p>
<p>?</p>
<p>6、7 我唯一能给组员的激励性的承诺就是，咱们上班的时候好好干，下班就不用加班了。。。。仅此而已。</p>
<p>?</p>
<p>?</p>
</div>
<p>5.是不是说项目经理需要review全部的source啊。那么项目经理还有时间去做管理方面的事情吗?</p> 24 楼 sun_in_china 2009-12-16 mock1234 写道你所说的项目管理，是一种没有项目蓝图的项目管理，是没有架构师知识背景下的项目管理。就好象一个包工头找一帮民工来盖楼，之前只是从废品堆中扒拉出一张设计草图。
其实架构和设计还是设计的关键点，只不过核心人物也许不会给你看。
设计者的作用占系统成败的70%以上，如果认为知道点功能点然后分工大家去分解就能代替系统设计，那么往往只能在小软件作坊里做赝品。实际上，如果设计文档可以注定其成功，那么才真正应该敢于继续去投资开发软件。现在有那么多搞软件的人失业，因此不缺抢着干空洞的功能分解工作的小程序员了，则更显出缺乏“先知先觉”的产品负责人了。
敏捷不是不做设计，只是换了一种看问题的角度而已，只不过把过去用教条方式说出来的“计划”现在用测试代码来写，写不出测试代码说明对应的设计也不现实。因此推动了注重扩展性、注重实用性的风格。
学敏捷的人也容易犯一个毛病：回避一个软件真正的技术问题而仅仅抓住一些行政问题，对设计问题张口闭口总是“到时候我会分工给手下人加班加点”来代替提出真正令人信服的系统设计文档，这过于急功近利过于对流行东西现学现卖。尽管知道做任务计划要细分到1、2天，尽管知道布置任务要说的清清楚楚，但是其实是加大了技术难度而不是减少了技术难度！所以既要做细又要做对，就只有更少的真正有经验的PM才能做好，一般人是做不好的。
如果没有掌握很深入很过硬的设计和测试技术（头脑中有独特的理论方法、手中有自己开发的工具），那么单纯去模仿敏捷就会变得很虚伪——其实单纯模仿敏捷跟鼠目寸光有什么区别？时间长了人品也变得虚伪了，所以敏捷绝对是有害的东西，只有真正的架构师、产品设计师才能偷偷研习。
敏捷原理只要知道就可以了，好好研究它技术的一面吧！
PM 和 架构设计师 不是一个概念。
搞混了吧？！ 25 楼 shake822 2010-04-20 主的7基本同意,不有有:
2.不用每天都要,如果目大了,分的模也很多,有可以一模不了解另一模,大家在一起就有意了,建每天小做工作回.
5.有必要大家吧,大家都有自己的要.而且於我的,要格按照文走,文上有的是不能做的,做了就是Bug,所以我只能是修正bug,而不能完善功能
6.要教出,如果是需求或是技法的,一定要出,如果不出你就要了.
7.激工,可以把任表每天都大家,且把完成的任注下,大家建立里程碑,完成了就可以去吃了.效果挺好. 26 楼 抛出异常的爱 2010-04-20 这个模型我用过
1.沟通成本过高（五人）
我个人一天几乎没有省余时间
我希望在个人技术比较成熟后
可以把模块分割大一点
达到自管理项目
但TEAM散了
2.周一讨论，周五总结是为免费加班准备的很不道德（很遗憾我也使用这个方式）。
5.现场演示一下
多找几个人十五分钟的演示
能找到QA 80%的问题
想实践冒烟测试代替这个东西没成功（有点太复杂了而且技术力量不够）
6.每周延个一天二天的延期不重要。
对外我都是忽悠过去的。
对内一般第二天早上都能找到问题核心，
找不到或作不到的问题挂起。
先完成主要大方向
（大方向这种东西一般不会出问题，出问题的都是特别情况，比如权限，生命周期过长等）
7.没有任何承诺。
我想要是人数大于8个跟本实践不了这些东西。