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

工作中学到的一点知识：

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

评论

6 楼 tuti 2009-08-15  

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

5 楼 hiwzg 2009-08-15  

<div class="quote_title">同RE。可以多看看软件项目管理方面的知识，在日常工作中多体会。</div>
<div class="quote_title">ybbkd2 写道</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><br>建议楼主系统的去学习一下项目管理知识，有很多培训班，即学习知识又能混个证书，如果运气好的话：）</p>
<p> </p>
<p> </p>
<p> </p>
</div>
<p> </p>

4 楼 ybbkd2 2009-08-09  

<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><br>建议楼主系统的去学习一下项目管理知识，有很多培训班，即学习知识又能混个证书，如果运气好的话：）</p>
<p> </p>
<p> </p>
<p> </p>

3 楼 zhanjia 2009-08-06  

yiding_he 写道

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

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

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

2 楼 zhanjia 2009-08-06  

mock1234 写道

那些简单的，靠人头堆砌就能“成功”的项目，仅仅强调如何开会这种行政得东西就行了。

对于复杂的系统，靠的是设计师，靠的是在主管以行政手法把任务分解和推卸底下的人之外直到如果准时地调配人员工作，而不是仅仅靠没有多少技术含量的开会督促法。

说道每天开多长时间的会议，这能说清楚任何解决技术问题之道吗？不过是从未当过领导的程序员这次过把领导瘾罢了，不要借口说成是软件工程开发之道。

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

1 楼 yiding_he 2009-08-06  

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

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