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

工作中学到的一点知识：

1. 细分各模块。将项目的各个模块进行细分，细分为子任务，子任务可以根据实际情况进行再细分。
   
2. 每周一开会。讨论本周或接下来两周的整体工作，具体要达到怎样的一个目标。
3. 每周五开会总结。最好在下班前0.5-1小时时开会，不要占用项目成员的下班时间。总结本周所完成的工作，查看实际效果，将成果与预计的做一番比较，为项目进度做出更好的评估。（对下班后再开会总结感到反感）
   
4. 控制项目进度。工作细分到1-2天，效率比较高。
5. 对项目成员成果的确认。每当项目成员完成某个功能，无论大或小，都要进行确认。最后是在做完以后，项目成员主动发出通知，大家一起审阅一番，同时给出意见。这样能确保功能更加完善，减少后期积少成多各种不完善的修改。
6. 让项目成员们更主动些。有下面几种情况经常会延误项目进度，使项目大大超出原有的预算：1)、遇到风险(代码实现上的)没向上级汇报  2)、开发过程中发现实际工作量超出原有的评估，未及时向上级汇报  3)、没完全清楚需求，就盲目的进行编码，等发现问题以后为时已晚。 看来许多都还是沟通问题
   
7. 给项目成员一定的承诺。为了提高项目成员的工作激情，工作劳累的同时，要给予更多的鼓励，给予一定的承诺，前提是这个承诺一定要能够实现，不要让成员们认为你是在忽悠。

楼主一定要看《人件》、《人月神话》

开发团队的老大一定要对下负责。

说得有道理，真正的牛人总能把复杂的任务划分为细小而明确的子任务，许多小任务就组成了一个完整的项目

人月神话看起来还比较抽象，得结合实际的项目管理进行实践体会。
工作两年，还处于编码阶段

建议楼主系统的去学习一下项目管理知识，有很多培训班，即学习知识又能混个证书，如果运气好的话：）

 

 

 

 

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

 

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

 

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

 

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

 

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

 

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

 

 

1.任务划分好，容易弄清楚难点和控制进度
2.确认项目的分阶段的目标很重要

管理者主动去同开发人员了解项目情况最好是在会议上，不管单独还是和捎带上其他人一起都行。开发人员也可以主动报告，当面或者用邮件都可以。

不完全认同“管理者主动去同开发人员了解项目情况最好是在会议上”，我认为管理者应该定期＋随时去通开发人员了解项目情况，非正式的与开发人员沟通，会避免将大量时间和精力浪费在会议上－－－这是一种官僚。并且，也能毕竟全面深入的掌握项目情况，开会时间短，你就无法确切了解项目实际情况，而开会时间长？我说了，那是一种官僚。