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

工作中学到的一点知识：

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

评论

26 楼 抛出异常的爱 2010-04-20  

这个模型我用过
1.沟通成本过高（五人）
我个人一天几乎没有省余时间
我希望在个人技术比较成熟后
可以把模块分割大一点
达到自管理项目
但TEAM散了
2.周一讨论，周五总结是为免费加班准备的很不道德（很遗憾我也使用这个方式）。

5.现场演示一下
多找几个人十五分钟的演示
能找到QA 80%的问题

想实践冒烟测试代替这个东西没成功（有点太复杂了而且技术力量不够）

6.每周延个一天二天的延期不重要。
对外我都是忽悠过去的。
对内一般第二天早上都能找到问题核心，
找不到或作不到的问题挂起。
先完成主要大方向
（大方向这种东西一般不会出问题，出问题的都是特别情况，比如权限，生命周期过长等）

7.没有任何承诺。

我想要是人数大于8个跟本实践不了这些东西。

25 楼 shake822 2010-04-20  

樓主的7點基本同意,不過有幾點有異議:
2.不用每天都要開會,如果項目大了,分的模塊也很多,有可以一個模塊不了解另一模塊,這樣大家在一起開會就沒有意義了,建議每天開發小組做工作回報.
5.沒有必要讓大家夠過來測試吧,大家都有自己的碼要編.而且對於我們編碼的來說,要嚴格按照文檔走,文檔上沒有的是不能做的,做了就是Bug,所以我們只能是修正bug,而不能完善功能
6.這點要教會組員拋出問題,如果是需求或是技術無法實現的問題,一定要拋出來,如果不拋出來你就要負責了.
7.激勵員工,可以把任務表每天都發給大家,並且把完成的任務標注下,給大家建立幾個里程碑,完成了就可以去吃飯了.這個效果挺好.

24 楼 sun_in_china 2009-12-16  

mock1234 写道

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

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

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

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

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

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

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

PM 和 架构设计师 不是一个概念。

搞混了吧？！

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>

22 楼 yiding_he 2009-12-01  

项目是由人组成的，对项目的管理是对人的管理的一个子集。所以任何对项目的管理方式绝不能违背对人的管理的原则。时常提醒自己这点，才能避免失败。

21 楼 terryh 2009-11-29  

tuti 写道

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

说别人的同时请拿出自己的东西，否则只会被大家鄙视。

20 楼 aishangtao 2009-09-20  

不错， 学习了。实际项目开发就应该这样

19 楼 star022 2009-09-20  

tuti 写道

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

楼主只是很谦虚罢了。

18 楼 star022 2009-09-20  

<div class="quote_title">hiwzg 写道</div>
<div class="quote_div">
<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>
</div>
<p>项目研发的最佳实践就是：在实际项目中的发现，反思，改进和总结！</p>
<p>楼主是个善于总结的人。</p>

17 楼 hotjava 2009-09-10  

<div class="quote_title">zhanjia 写道</div>
<div class="quote_div">
<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> </p>
<p>1、现在基本都是几十万的项目，其实大多数需求都是经理们自己在提，自己做Demo给客户看，引导出客户的新需求，总感觉是为了赚钱而在忽悠，但如果不是这样的话恐怕又没什么项目做了...。有些需求很虚，有些比较实在</p>
<p> </p>
<p>2、开会一般周一还是会开，会提一提本周大概要完成哪些工作，上周完成了哪些工作。其他时间的开会就比较灵活了，看具体情况。如果这块工作需要两个人来做，那么会找那两个人到小的会议室友聊一下，分配一下任务。如果工作需要所有人参与，那么会叫大家一起去开会，其实也就那么四五人，不多。</p>
<p> </p>
<p>3、任务的分配与工作完成情况的确认，经理喜欢采取半天、一天、两天的形式进行，这样给我们开发人员有一定的压力，效率可能会高点，不好偷懒。不定时的加班，项目开发过程中，偶尔都会有一些加班，时间长短看项目需要，一会儿、半个小时、两个小时、周末一/两天。</p>
<p> </p>
<p>4、承诺倒没咋的，反正看部门的目标，如果达不到预定的金额，奖金就很少。如果超出了，纯利越多，奖金就会多一些。如此而已</p>
</div>
<p><br>1.你最好先看看合同， 看看技术方案建议书，看看客户的建设目标是什么，别做了一大堆看起来很像样的东西， 结果客户的根本问题没解决。几十万的项目不过是小项目。满足其建设目标就好了， 乱七八糟的不做。 </p>
<p> </p>
<p>2.周会看个人爱好，有的有官瘾的人天天开我也没意见。 不过，不要浪费别人太多时间。 设计的东西，找张纸，弄个小黑板就OK了， 别再借什么投影仪。我做为一个组员根本不关心别人干了什么。 我只关心我的任务和工作。 别人演讲的时候我一般都睡觉。 我做项目经理的时候， 别人不用向我汇报， 我就知道他们干了什么， 你说这周会有必要开么？除非你的项目特别大， 组织机构复杂， 你下面还有组长， 还有项目经理。这时候才必要。</p>
<p> </p>
<p>3.水平低的分到一小时， 水平高的分到一周。 因人而异。 对于水平高的人， 设计讨论清楚了， 代码随便写去吧。 我是不管的。</p>
<p> </p>
<p>4.利益分配不是你我这个层次的人能够决定的。</p>
<p> </p>
<p> </p>
<p> </p>

16 楼 gloryfuture_taiyuan 2009-09-08  

1、wbs的使用是必须的，为的是有一个整体的计划，整体的时间点，但是可以随时调整，达到计划敏捷；
2、需求分析、架构设计等一定要成文档、评审、讲演；
3、周报、日报必须写，项目经理通过这些文档来把控具体项目进度，可以让QA做具体的监督；
4、代码的review可以交给架构或者高程来做，定时反馈代码中的问题；
5、良好的项目经理除了掌握一些项目管理技巧方法外，我认为最好能有一些职业规划方面的知识，可以用到组员中，给每个组员做一个贴切的职业规划，这样你给他安排的活他也就愿意做！

15 楼 earthsky 2009-09-02  

使用恰当人做恰当的事，让员工既感到不累，又感觉做了很多有意义的事，这才是项目经理个人魅力，见笑。

14 楼 orpheus 2009-08-27  

mock1234 写道

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

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

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

我感觉楼主的总结对于2年的工作经验的人来说还是可以的了,他的重点显然也不在开会上.我理解楼主所谓的开会就是team中的一种集体沟通方式而已.

不论是开会督促或者所谓的"随时沟通",都是项目经理不称职的表现.必要的时候是需要督促的,但是如果这种方式成为了项目经理的管理方式之一的话,我只能说他混不了多长时间的.
项目进度质量成本都是项目经理需要考虑的,不是只简单的以行政手段分解就行了,这样可行的话,项目经理还有必要懂技术么?
我觉得无论是通过什么手段,是技术手段,行政手段,人格魅力,个人能力,最美好的管理方式就是让团队中的每个人可以具有团队目标概念,项目责任感以及达到自我目标驱动,自我管理的目标. 这个方式同样适用于项目中的各个角色.

最后一句话,一定要目标驱动,我们都是打工者,不同的职位只是不同的,大家的目标都应该是一致的,千万不要为了管理别人而学习管理,管理的最高境界就是不管,哈哈.

13 楼 Rush_2008 2009-08-18  

与楼主相同，也是工作两年，我很支持楼主有这样的想法，把自己平日里所学到的，或者所想的项目管理知识总结起来。只有不断的总结和思考才能进步。

在工作安排上，我趋向于用WBS进行工作分解，便于规范管理，同样也可以使用一些软件如jira或者urtracker等。

在与程序员沟通方面，我觉得这是比较重要的一块，项目经理需要以认真、负责的态度去与程序员进行沟通，不能抱着自己是领导无视下属感受的态度去进行沟通，不然只会越沟越不通。

另外项目经理不单单只是要与开发团队进行沟通，更总要的是要与客户进行沟通，客户满意了，才会有助于推动项目，不会在开发和实施的时候遇到太大的阻碍。项目经理是要保证项目的顺利完成，除了开发，测试、实施也是要关心的事情。

12 楼 zhanjia 2009-08-17  

tuti 写道

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

1、我没有很刻意的去说代码工人，只是想委婉的说明自己不是项目经理，如此而已，并没有你想得那么深，别误会。

2、看到这些，是因为我自己想进步，把自己学到的一些知识记下来。我还没当过项目经理，没做过项目管理，你说我真能看到你想的那些的话，那我就是你了。呵，开个玩笑

3、个人感觉做开发工作这么久要慢慢学会从更高一层来思考、对待一个问题

谢谢指教！

11 楼 zhanjia 2009-08-17  

寒江雪 写道

luck_donkey 写道

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

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

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

1、现在项目基本就是采取“定期＋随时”，随时的多，定期的应该是说该开会的时候，就会每个人问一下，上周或前些天都做了什么，计划接下来做什么等

2、其实感觉逼得太紧也不是太好，总感觉经理可能过会儿又要过来问你什么了，自己是不是已经完成了一些什么可以交待的东西，如果没完成又会怎么样...

3、个人认识跟开发人员了解项目情况，应该以一种比较平和的语气，制造宽松的气氛

10 楼 zhanjia 2009-08-17  

<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> </p>
<p>1、现在基本都是几十万的项目，其实大多数需求都是经理们自己在提，自己做Demo给客户看，引导出客户的新需求，总感觉是为了赚钱而在忽悠，但如果不是这样的话恐怕又没什么项目做了...。有些需求很虚，有些比较实在</p>
<p> </p>
<p>2、开会一般周一还是会开，会提一提本周大概要完成哪些工作，上周完成了哪些工作。其他时间的开会就比较灵活了，看具体情况。如果这块工作需要两个人来做，那么会找那两个人到小的会议室友聊一下，分配一下任务。如果工作需要所有人参与，那么会叫大家一起去开会，其实也就那么四五人，不多。</p>
<p> </p>
<p>3、任务的分配与工作完成情况的确认，经理喜欢采取半天、一天、两天的形式进行，这样给我们开发人员有一定的压力，效率可能会高点，不好偷懒。不定时的加班，项目开发过程中，偶尔都会有一些加班，时间长短看项目需要，一会儿、半个小时、两个小时、周末一/两天。</p>
<p> </p>
<p>4、承诺倒没咋的，反正看部门的目标，如果达不到预定的金额，奖金就很少。如果超出了，纯利越多，奖金就会多一些。如此而已</p>

9 楼 寒江雪 2009-08-17  

luck_donkey 写道

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

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

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

8 楼 luck_donkey 2009-08-17  

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

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

7 楼 hotjava 2009-08-16  

<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>