＋设为首页 ＋添加到收藏夹
做了一阵子项目经理，有点想法，和大家交流一下。
个人觉得项目经理比较重要的是
1、“随时可中断”。必须随时做好准备去应付一些突发的事情。
因此项目经理不应该给自己分配需要集中精力和较长时间才能完成的事情。
一旦必须要这么做的时候，尽快安排人接替。
明确哪些事情自己该做，哪些事情不该做，不该做的事情要坚决扔出去。
换句话说，项目经理的第一任务是“让自己空下来”。
2、“团队优先”。
我一般给团队中人分配两件任务，一件是主要的、固定的，有时间限制的，
一般是需要八到九成时间。
一件是次要的、灵活的，无时间限制的，但是有目标要求。
通常后一件会带有一些技术探索意味，属于该成员个人比较感兴趣的部分。
换句话说，项目经理的第二任务是“让团队中的所有人都有事情做”
3、“控制客户”
控制客户包括多方面的意思，搞好关系是一层，但如果软件做的实在太差，
没法用，关系再好都没有用。
而且关系好是双面的，客户同样可能以关系好为由来要求你这里改改那里
改改，结果造成项目无限期拖延。尤其是市场/销售人员经常去开空头支票。
我觉得，应该是对客户领导要搞好关系，告诉他一切没问题，一般这是
市场/销售人员搞定的
但是对软件的实际使用者也就是客户的底层人员诉苦。这个就要项目小组
自行解决了。
如果是小项目，往往是开发人员直接见用户。前者由项目经理来自行，后
者直接由软件开发人员进行，挑一个比较会说话的，多往用户那边跑跑，
聊聊天。当软件投入运行时，这是很有用的。再好的软件也架不住用户
不断地需求变更，因此最好的办法是“把需求变更扼杀在襁褓之中”。
如果是大项目，用户方应该会有专门的项目负责人，和用户
代表绑定在一起是非常必要的。但是底层的人员一样要搞定，那就可以有
专门的支持人员，更需要和用户多接触了。
操作的时候注意多留文档，哪怕是再小的问题也要留档，过一个月整理一
下，往客户领导那边一放。统计一下本月共发现多少问
题，哪些是新需求，哪些是软件BUG，哪些是用户使用问题，解决了多少，
有哪些遗留，我方技术人员现场支持多少小时，诸如此类。总之让对方感觉
我们劳苦功高，服务周到，响应及时。
来上几次就可以由销售出面谈维护或者二期之类的事了。这样就赚到了。
即使软件还有很多问题一样可以继续操作。
4、“对付领导”
现在有事，过会再写
呵呵，说两句。
楼上的兄台体会到了国内传统软件公司的开发模式和管理方法，从各方面都谈到了一些，以下说说我的看法：
1、项目经理的职责
项目经理的两个主要职责是项目策划、项目的跟踪与监控。如果项目较小或者公司的规模不大，往往项目经理还得担任软件需求经理的角色。
2、项目经理的具体工作
围绕着上面的两个职责，项目经理的具体工作就比较杂而多。项目策划的内容很多：组织需求分析，项目规模估计，风险估计，进度安排。此外在项目的跟踪与监控方面，包括周报内容的收集及整理，风险的跟踪与监控，问题日志的维护，项目变更及重新策划。如果还要担任需求分析的角色与客户谈具体的需求，那么在软件需求分析、系统架构方面项目经理都是主要决策者，我认为这样会影响项目管理，如果是小项目尚可，要是规模大周期长的项目，建议有专门的需求分析师，系统构架师。
另外我想谈谈"把需求变更扼杀在襁褓之中"：
很多老前辈常常认为是不断变更的需求导致了大多数项目的失败，我想开发人员把角色可能倒置了。我们不可能因为需求变更导致系统架构变动很大 而不让用户去改变他们的需求。现在的竞争很激烈，用户需求变动很大，常理使然! 所以我们应该尽力去调研需求，了解客户所在那个行业，抽取出不变的或变动很小的需求，构建成我们的主要架构，再辅以常变的部分。现在系统架构都相当"柔性"，我们可以尽量向那种分布式的、多层体系方向迈进。
一点拙见，欢迎讨论，共同提高！
讲的太好了！！！
这才是真正的实用项目管理！
这才体现出了项目经理们同软件学院里的软工硕士的差别！！
我也把我的一点心得与大家分享，请大家多多指教。
2. 任务分配
进行任务分配时应当注意任务之间的耦合程度以及任务的内聚程度，以减少项目内耗。尽量做到低耦合，以降低对成员之间交流的依赖程度，让大多数成员无需考虑太多繁杂的、不相干的东西；尽量做到高内聚，让成员可以尽量发挥他的能力以及已经获得的项目相关信息。
如果工作量实在太大，或是工期要求太紧，不得不把高耦合工作分给多个成员负责，这时候就要特别注意成员间工作相关知识的同步的问题。
要给所有成员一份详细的工作内容说明，并要注意所有成员得到的相关资料的一致性。在所有成员都做好自己工作的有代表性的一部分的时候，要把这些成员集中起来进行一次review，以消除成员之间知识／理解上的差异。如果在开发过程中出现了需求变更，则要及时通知与这部分需求相关任务的负责成员。做一个简明的变更索引，按索引定期review，以检查变更的落实情况。
如果由于成员调度、个人进度、需求变更、以前遗漏的任务或者某种不可抗力等原因，而不得不更改任务分配，这时候一定要考虑如何最大化地利用项目人员已经做过的工作、已经获得的项目相关信息，尽量减少任务更改而引起的交流、培训和再教育花费。
大家说的太好了，我没做过项目经理，但我喜欢到软件工程/项目管理中来学习学习前辈们的经验。
我感觉我所在公司的项目管理真是太乱了，举例来说我本来被定位是现场施工的负责人，到后来我发现我的角色似乎变了很大。不仅仅是把开发组的软件在现场安装、调试、运行，更多的职责是
1. 做系统测试，还有很多单元测试就应该解决的问题；
2. 长达半年的测试中，要整理用户的需求，与用户讨价还价，自然还要做客户关系；
3. 因为在现场施工，系统上除了问题，总是替开发人员挨骂，所以不得不协调各项目小组的活动，抓进度、抓质量。
感觉整个项目乱糟糟的，特郁闷。
记得n年前看过一本企业管理的书，说管理的首要原则是则、权、利的统一，整个项目职责就是不清，有权利的人不怎么管，没权利的不得不管。有的事好象有几个人可以管，好象谁不管也都没责任。
领导们在斗争，员工就更没有沟通、协做的精神了，再加上超负荷工作，money又少，领导的工作方式还有问题，哪个士气低呀，项目怎么能搞好！！！
发一点牢骚，请各位指点迷津。
clamp_chen (燕归来) 说的很好。
我也来叽叽歪歪几句：
1、第一条，随时中断，让自己空下来。
非常赞成。
2、第二条，团队优先。
除了让每人有事情做以外，还需要以整个团队的进度为第一。
先满足解决组员的要求，项目经理就是组员的仆人。这也是为什么要第一条。
3、第三条，控制客户。
其实是注意客户的反映和要求，很多时候客户提出修改和新增功能，
将心比心替客户考虑一下，有些是没有必要的或者违反其他客户要求的或者实现违反已经
定义的大的框架的，的确不能给他做，通常能解释得明白。
很多时候客户的要求没有实现也不是很要紧，但是一定要给他反馈，
告诉他为什么，客户会觉得自己受尊重，不能口头答应，回头就忘。
4、第四条，控制领导。呵呵，没有这么大能耐。
5、个人意见： 团队人不是越多越好，而是要有合适的人。
一些不合要求的坚决不要。特别是缺乏合作精神的绝对不能要。
最好要有女组员，能够调节开发气氛。
6、注意要有计划节点，在开发的时候某个时间交出什么样的东西要和用户沟通，
尤其是现在用户不停地改变需求的时候。不能用户一提就修改，那样会影响质量。
7、团队开发的时候一个功能模块最好能够有2个组员知道，一个开发，另外一个
了解，在项目人员变动或者任务分配的时候有余地。
8、做好版本控制，不许组员修改他人东西。没有经过测试的东西不要交给客户，哪怕整个软件只改了一个很小的地方。
9、注意组员的状态和情绪，帮助解决组员问题，组员矛盾，让他们集中精力在工作上。
各位都有心得,我扔两句:
1.没错,PM的活比较零碎,主要作为项目组和领导以及客户的信息中转站,因此,项目分配任务的时候考虑尽量少安排一些工作,因为总会有意想不到的工作干扰你.
2.权利下放,考虑TSP(我们实行过,效果不错),将组员分成角色,例如每天的备份,由专人负责,你只管检查备份是否完成,这样同样能调动组员积极性,让他自己对项目有责任感,自己也省心.
3.放下追求技术的心态,看问题的眼光放在项目上.
4.多看看管理的书,尤其是激励的方法.
1.通常项目经理身兼数职才会出现需要“随时可中断”的情况，而且这种思想有些不对，感觉PM成了救火队员。我做过一项目，有专门的业务分析人员、程序经理，我一周只要花两到三天的时间就可以做下来，剩下的时间是把部门做过程改进，呵呵。
2.“团队优先”这还要说吗，做什么事不要团队优先；
“让团队中的所有人都有事情做”有些莫名奇妙，怎么会有人没事做，成员自己的任务完成了可以自行学习或者部门有培训计划，不用PM管，PM还需要管理成员的个人发展不成，有些职责不清；如果一直没事做，会调到其他项目组。
3.“控制客户”感觉象搞公关一样，做PM的自然有一定的沟通能力，当然不会能客户，也根本没那个必要，做之前，项目的目标需求应该比较明确，只会有一些细节上会有出入，需求不明确，当然会有扯皮了，不是搞不好关系的问题，对于新的需求让客户写好，要与客户代表、销售代表开会商定到底怎么做，一定不能由开发人员直接修改，如果要继续做，要定立协议盖章生效，不要以为烦，以后就会有好处。
4.“对于领导”怎么要什么“争夺人才”、“软硬兼施”，需要与部门经理做成那样程度，需要什么讨价还价等，这种项目也不要做了。
综合以上几点，对楼主的观点，真是不敢恭维，尽是些旁门左道的东东。也难怪，国内很多项目都是这么做过来的，形成了恶性循环。
