[大话IT]一个项目经理的一些个人体会

·向高价医疗费用说不·不可多得2006商机·天涯社区诚征广告代理·是人才你就进来！·广发送你小新暖手宝
·双眼皮火爆价299元·她让我一个月会说英语·★女人时尚玩不尽★·最大刺激高潮不断!!·英雄晚上都在做什么？
『IT视界』 [大话IT]一个项目经理的一些个人体会
作者：西蒙泥 提交日期：2005-7-28 11:38:00
本人做项目经理工作多年，感到做这个工作最要紧的就是要明白什么是因地制宜、因势利导，只有最合适的，没有什么叫对的，什么叫错的，项目经理最忌讳的就是完美主义倾向，尤其是做技术人员出身的，喜欢寻找标准答案，耽误了工作进度，也迷茫了自己。以下是本人一些做项目的个人体会，写出来供大家指点，在讨论过程中共同提高水平。
千奇百怪 个性洗手间全搜罗
作者：西蒙泥　回复日期：2005-7-28　11:39:31
项目开始阶段是一个最重要的阶段。项目经理在接手一个新项目的时候，首先要尽可能地多从各个方面了解项目的情况，如：
1.这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题。在国内很多客户都很不成熟的情况下，千万不要根据项目的名称望文生义地去想象项目的目标。一个名为“办公自动化”的项目很有可能在你进场以后一个月才发现客户其实需要的是一个计算机生产管理辅助信息系统系统。前期了解情况的工作越详细，后面的惊讶就越少，项目的风险就越小。
作者：西蒙泥　回复日期：2005-7-28　11:41:47
2.这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等，很多项目里除了业主单位的结构很复杂以外，还有一些其他单位也会牵涉进来，如项目监理公司、业主的行业主管机构等。项目经理需要了解每个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望，可以让你在做项目碰到问题的时候，就每件事情分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前准备联合朋友去对抗敌人，让事情向你所希望的方向发展。没有永远的朋友，也没有永远的敌人，只有一致的利益，这句话作为项目经理是一定要记住的；
作者：James_Peer　回复日期：2005-7-28　13:40:53
项目经理就这么多体会
作者：Jack-Sparrow　回复日期：2005-7-28　13:45:48
还有吗？
作者：西蒙泥　回复日期：2005-7-28　14:21:21
3.基本了解了客户的情况后，下面的事情就是了解自己公司各方面对这个项目的看法。首先是高层领导是否重视，这个决定了你在需要资源的时候，公司是否会根据你的要求提供最有力的支持。领导口头肯定是说支持的，你需要做的是了解公司对这个项目的实际期望，是想把项目越做越大还是想赚钱？是想做样板工程还是干脆想敷衍了事，公司领导对项目的态度决定了你做这个项目的战略，而这个战略方针将对你做项目计划产生直接的影响；
作者：西蒙泥　回复日期：2005-7-28　14:23:57
4.在做整体项目计划前，还要大致计算一下你手上的资源。首先是时间，现在市场竞争激烈，往往很多项目要求在几乎不可能的时间范围里完成。对于这一点，你在做项目的风险控制计划的时候要充分考虑。其次是人员，根据项目预算和已往经验，大致计算一下未来的项目小组有多少种角色，每个角色目前公司是否有人，是否能完全归这个项目使用，是否需要另外招聘一些人员，招聘的准备工作要尽早启动。最后就是一些设备的准备，项目所需大件关键设备要尽早预定，以后不管发生设备等人还是人等设备的情况，浪费的都是你的时间；
作者：O_V_R　回复日期：2005-7-28　14:25:40
没错。
作者：西蒙泥　回复日期：2005-7-28　14:31:40
5.现在是做项目说明书的时候了。一份好的项目说明书不仅将要做的事情描述得很清楚（主要是讲做什么，而不是说怎么做），而且把如何检查也说明得很透彻。也就是说它不仅说明白了要做哪些事情，也让客户的业务人员（一般不懂技术）知道项目做成什么样就算完成了。简单地说，项目说明书描述项目做哪些事情和每件事情做到什么程度以及如何检查每一个结果。
6. 是到做总体计划的时间了吗？不，你现在已经知道了客户的目标和你手上的资源，那么做计划以前，你还需要和你的经理和客户充分沟通资源的问题。因为很多资源是还不明确的，你需要写一份报告，详细分析这个项目的风险以及对资源的需求情况。如果一些问题不能得到解决的话，将发生什么样的后果。如果资源不够，就要高层改变策略，增加对这个项目的投入。甚至在条件许可的情况下，有些公司会放弃这个项目。总之，没有人能完成一个不可能完成的任务，如果项目经理不能尽早发现风险，那么就只能去当烈士了。
作者：西蒙泥　回复日期：2005-7-28　14:34:30
7.明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略，现在是成立项目小组的时候了。很多项目经理都没有自己选择组员的权利，那么，就尽量发挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不同，相差较大，很难有什么具体要求，但是，一定要有精通客户业务的人，很多小项目里，这个人就是项目经理本人，大项目里会配备行业专家（Industry expert），这样和客户沟通起来才不会鸡同鸭讲，双方才可以相互理解。我经常看到的情况是我们的技术人员和客户交谈时满口的专业术语，结果搞得客户一头雾水，反过来，他还指责客户不懂技术。其实，明白自己想做什么的客户已经是很好的客户了，不知道自己要做什么，更不懂怎么做还要指手画脚的客户到处存在，但是要明白，是客户选择了你，而不是你选择了客户，有了客户你才有工资拿，心平气和一点吧；
作者：大风往北吹　回复日期：2005-7-28　18:42:35
看着有点面熟,lz原创?
作者：冬瓜123　回复日期：2005-7-28　21:34:18
搂住好像说的不是很专业～～～我觉得应该从项目规范入手，讲你的体会，效果会很好的
作者：冬瓜123　回复日期：2005-7-28　21:38:00
补充：我认为一个项目经历能够结合规范和经验流程的话，应该很成功的
作者：受伤的鹰　回复日期：2005-7-28　23:00:01
不错不错。
作者：瑶琴心事　回复日期：2005-7-28　23:23:09
楼主应该没做过什么大项目，否则理解不会这么浅．
作者：瑶琴心事　回复日期：2005-7-28　23:52:00
刚才发帖开个玩笑，：）
楼主不要见外啊，项目管理方面的知识大家多交流．
作者：skin-dive　回复日期：2005-7-29　8:55:38
不是很专业的项目管理,要不就是写的不够专业,不过和我们很贴近,不错不错!
作者：gz_martin　回复日期：2005-7-29　8:55:40
在项目运行过程中,很多时候会资源不足,要巧妙的利用客户的资源.还有做项目,不同搞生产,搞生常如果出了偏差,马上便能有反馈,就可以及时发现问题,解决问题.但如果是一个长期性的项目,在运作中如果出了问题,也许要很长时间才能反映,导致的结果可能是收不到项目款,或被扣款.所以,项目经理要从宏观上主导项目,在微观上把握项目的.
作者：gz_martin　回复日期：2005-7-29　9:00:27
关于项目规范,当然是很有必要的,但是,很多时候会因为特殊事件,或者是因为客户的原因,跟项目规范发生了冲突,甚至超出了合同范围......这是比较头痛的,我的项目中,就常有这样的事
作者：西蒙泥　回复日期：2005-7-29　9:15:51
感谢大家的跟帖！
to 大风往北吹：这是我自己写的，所以才写得这么口语化，没有一点很严肃的感觉，让冬瓜123和skin-dive兄弟觉得不专业；
谢谢受伤的鹰的夸奖；
to 瑶琴心事：我写这篇东西的目的就是拿上台来给大家批的，所以任何的建议都是欢迎的，除了没有建设性的谩骂。你说得没错，我没有主持过很大的项目。
to gz-martin，一看就知道你也是同行，需求变更管理是国内项目经理最头痛的事情，其实我也谈到了，这个和客户的不成熟有关，也和我们很多人，包括我们自己做事情不规范有关。
再一次谢谢大家支持！
作者：Mac_J　回复日期：2005-7-29　9:18:42
作者：gz_martin　回复日期：2005-7-29　9:00:27
关于项目规范,当然是很有必要的,但是,很多时候会因为特殊事件,或者是因为客户的原因,跟项目规范发生了冲突,甚至超出了合同范围......这是比较头痛的,我的项目中,就常有这样的事
~~~~~~~~~~~~
同感啊！～～～～老板昨天去收钱，客户说我们的软件还没有达到他们想要的目标（一个“权限申请表管理”的功能），拒不付钱。
可这个功能在合同和开发方案里都不包含。在开发过程中，用户不断的提出一些修改和功能的增加，一些好处理的我们怕得罪客户都做了，这功能则实在要些时间。公司给我的成本只有这么多，冤啊！
这个客户的情况算好的，还有更恶劣的，有一家国有大公司仗着财大气粗，欺人太甚，屡次变动需求，甚至朝令夕改。好好一个项目足足拖了两年。把这些需求变动拿给他们要求他们签字认可，居然TMD死不认帐，对上面一个劲说我们工作做差。公司亏了不少钱，却能认栽，他们是大客户，我们跟他们的下级单位有很多业务往往来，他们一句话就能封杀我们。好在他们也自知理亏，现在还在保持业务往来。
作者：gz_martin　回复日期：2005-7-29　9:33:33
其实,关于项目规范,客户要求等等,实际上也在考验我们的专业水平或者综合业务水平.如果我们前期就能预知客户的潜在的需求变化以及向客户表明,就可以在后期减少这种被动的局面.在现有的消费意识中,如果在项目运行过程中才想着去引导,改变客户的观念是很难的.所以在谈项目时一定要多方考虑啊.有时候,客户本身也不知道知道需要什么,所以好的方案,就成功了一半了.
作者：西蒙泥　回复日期：2005-7-29　9:57:23
对于这种需求天天变的客户，你就一定要事先做好规矩：
一、统一联系人，客户指定一个人和项目组进行沟通，不能张领导、王领导都来说几句，如果他们意见不一致，那你只有得罪领导的选择了，所以，项目的最初就要定好规矩，我项目组只认一个的意见，有什么要求你们内部先统一再和我谈，我不想卷入你们内部业务部门之间的矛盾之中；
二、所有需求变更全部要有书面文字，这点切记！这样做好处多多：
*有书面证据，以后他还想改，你有了他以前要求的证据，告诉他：你以前可是这么说的；
*便于需求变更管理，需求如何慢慢演变的历史可以看清楚，从而更深切地体会客户的目的；
*对于客户来说，嘴巴一动最方便，反正是你们做，不花他的资源，所以要求是否合理，是否和项目的目的一致，他是不负责任的。但是如果要他写书面要求，还要签字盖章，他就要谨慎多了，而且一写东西，思想就会更加深入，很多无理要求也就这样胎死腹中了；
作者：truesword　回复日期：2005-7-29　10:08:07
做项目管理的过程就是对项目经理克服个人自身能力弱点和性格缺陷的过程。面对问题的决心，对决策承担后果的勇气，理解他人的耐心。。。。。结果呢，项目经理几乎成了一个完美的人，勇敢，头脑清晰，交流坦诚，方法灵活，感觉敏锐，态度谦和，果断有力，体贴下属，尊重他人，勤于学习，善于沟通。。。。。。不知道其他人的感想是不是这样的呢？
作者：厚简　回复日期：2005-7-29　10:14:18
国内项目大多不正规。
合同大不过人情，很多的时候是和项目外的因素来协调，所以灵活运用才是最重要的，不可太执著形式。
作者：肖克一百　回复日期：2005-7-29　10:27:05
做项目难,难的是客户不知他想把这个项目做到什么效果,达到什么目的.
作者：supper3000　回复日期：2005-7-29　10:50:53
我觉得做项目是分阶段的，开始的时候是想做“卓越”然后就是”好“，然后就是”安“，然后就是”稳“，然后就是”不慌“，然后就是”慌“，最后就是”平“。每次都在这么个循环
作者：西蒙泥　回复日期：2005-7-29　12:21:36
8.现在你要面对三群人：你的领导、你的组员和你的客户，和这些人沟通，让他们知道你打算怎么做，什么时候要他们做什么准备这些事情将是你的主要工作。既然沟通这么重要，那些事先定义一下沟通的原则也是一件很要紧的事情。很多沟通原则都是潜规则，如果你在一个部门时间做长了，对这些规则的运用觉得是一件理所应当的事情，但是，你现在面对的是多个部门甚至多个单位，不把沟通规则说清楚，你以后就会吃亏。下面的东西看起来无聊，其实还是很管用的：第一个是规定信息的流动方式和介质，是推还是拉。推的意思就是项目经理将主动发布信息，不管通过电话、邮件还是书面方式，保证将信息传达到每个人。这种情况适合小项目，人少；拉的意思就是项目经理就是一个类似web服务器，你自己需要什么信息就去问他。当然，没有项目经理把自己搞得那么累，他会用发布信息到公共介质的方式公布信息，简单的是白板，复杂一点的是项目的公共信息交互区，潜规则就是我发了你没去看就不要说我没告诉你。说这些看似很无聊，其实里面牵涉信息传达不完全的责任问题。当然，这些都是指一般的方式，而且不要绝对化，一般情况下，主动沟通和被动访问是同时存在的，尤其是对领导，项目经理更加应该主动去和领导沟通。第二个问题就是文档问题，很多人怕写文档，但是项目经理一定要牢记“好记性不如烂笔头”的道理。有理有时候为什么会说不清呢？就是因为没有证据。所以项目经理开始就要和客户说清楚有些文档是必须签字的，比如项目经理的项目日志，每个星期至少让客户签字，另外所有达成共识的东西，比如会议纪要，甚至领导的讲话记录，都要写成文档，双方签字，这样以后扯皮的时候，就能做到有据可查。记住：说了的就和没说一样，只有写下来大家签字后才算真正发生了的。还有一些问题，比如你提交的报告，给领导（包括本方领导和客户领导）做一个选择题，结果领导压住不批，让你无所适从，结果拖延了进度。这时候，你可以等，但是注意要留记录，标明是谁的责任；另外，如果你在开始阶段就和领导商定：如果批示提交三天后没有得到领导答复就算对方同意，这样你就会主动很多。再比如不同事件的审批流程问题：什么等级的事情记录在项目日志里、什么等级的事情要双方项目经理专门签署备忘录、什么等级的事情要双方领导出面签署合同附件等等。事先想得越周到，以后的工作就越主动。
作者：冬瓜123　回复日期：2005-7-29　13:05:29
我的贴怎么丢了～～？
作者：冬瓜123　回复日期：2005-7-29　13:18:38
哎呀，眼花了，发现我的贴那么渺小的躲在那～～～首先我不是个项目经理，参加过的项目最大也才2百wan,有些体会的。西蒙泥已经讲到了很多在项目实施过程中应该注意的地方，讲的很详细。个人项目的实施应该软硬结合，软：就是西蒙泥的经验之谈，体现个人风格。硬的就是规范，体现专业。但项目的实施应该是在规范的指导下完成的。不注重规范的人，充其量就算个业余，再好听点就是专业的业余程度，还是处在逃不出业余算不上专业的尴尬。
作者：naeco2005　回复日期：2005-7-30　16:42:28
现在的文档大都是以电子形式，如何进行签字？
作者：0点01公分　回复日期：2005-7-30　17:47:24
前期了解情况的工作越详细，后面的惊讶就越少
作者：yellowstarye　回复日期：2005-7-30　18:08:20
请问，一个小小的程序员要怎样才能走到一个项目经理呢
请教一下！！
作者：西蒙泥　回复日期：2005-7-31　11:56:26
to 冬瓜123：我承认你的观点是对的，以前刚做项目经理的时候，我以为去考一个PMP的认证，然后做项目的时候，搞一大堆规章制度和文档就没问题了，结果后来还是吃了很多亏。西方的项目管理经验，包括管理经验，在中国实施的时候，只能作为参考，否则行不通。我写这个的目的就是交流一下项目管理的潜规则，一般是不在教材里说的，都是个人体会，哈哈。总之，我们这个社会就是人治大于法治，不要太迷信规范，^_^
to naeco2005:
打印出来签字，切记！电子文档没有法律效应的。
to yellowstarye:
如果你确定你的职业方向就是做PM，那么你就慢慢积累做事情的经验，尤其是一些技术人员认为是打杂的事情。
作者：西蒙泥　回复日期：2005-8-2　13:37:09
这几天比较忙，我很快就将继续写下去，大家有什么建议也谈谈嘛！
作者：渔阳鼓动　回复日期：2005-8-2　14:30:42
不错不错，深有体会。难得楼主总结的这么清楚
作者：蒲裳　回复日期：2005-8-3　14:46:03
很好很好。。。我在努力学
作者：dr_ly　回复日期：2005-8-3　21:51:09
很好
努力
作者：快乐的熊猫猪头　回复日期：2005-8-4　0:24:50
很欣赏（佩服）楼主跟大家分享自己心得体会的做法，把心里想的写出来，整理自己的思路，加深了印象；并通过讨论进一步的加以扩充，这种double win做法很值得学习。
作者：快乐的熊猫猪头　回复日期：2005-8-4　0:27:58
如果你确定你的职业方向就是做PM，那么你就慢慢积累做事情的经验，尤其是一些技术人员认为是打杂的事情。
学习就是不断的积累，应用，加深，再积累的过程。对于纯技术人员，可能比较重视技术本身的积累；我觉得做事情的经验的积累也是不可或缺的。
作者：yhzz　回复日期：2005-8-4　9:36:30
市场关系没处理好，，，自然会挑你毛病，
作者：火翼鸟　回复日期：2005-8-4　10:53:43
我也是做pm出身的，时间紧，没来得及看完楼主的话，先说说我的一些感触吧，也供大家交流交流。
国内的项目，最开始存在的问题常常就在合同上面，市场人员很多时候为了尽快拿单子，先迎合客户签下一个合同再说。这样经常会导致合同有关项目范围的语句含混不清，给后来项目组的工作带来很大困扰。我就碰到过好几次，客户的实质要求和合同内容相差很大，而合同里根本就没写明白。这种项目很容易出现方向性错误。
其次，外国人推崇的合同观念，是双方平等的，一切相关项目的问题需要双方协商解决。但是本国的国情是，买方永远高人一等，客户最大，供应商只能顺应客户的意愿做事，哪怕超出合同范围也是常事。碰到那种朝令夕改的客户是最让人头疼的，就算你让他签字确认需求，回头他还要再次推翻，也是不能制止的。以国营企业和机关单位碰到这种情况最多。
我觉得最忌讳的还是上层领导的干涉太多，不给pm充分自主权。如果按照领导的去做，做好了，是他的成果；没做好，责任是pm的。我现在的总工就是这样，经常因为一时性起去变更项目过程，完全无视于项目进度计划。回头还会责难项目经理为什么进度没有合乎计划安排。碰到这种事情真是让人无语。前面两种提到的两种情况，如果是通过项目经理的个人经验和领导能力，还是可以想办法克服的。但是碰到那种横加干涉的领导多了，再好的项目也有做砸的危险。
最近一直在准备9月份pmp的考试，系统学习了美国pmi的项目管理知识理论。真是觉得国外的项目管理思想的成熟度非国内的企业能比拟。希望以后能有机会按照这种理论去运作项目，也不枉自己选择了pm这条路。
作者：amorcupt　回复日期：2005-8-4　11:19:50
收到，仰望美国的管理制度，体味国内的管理经验。
作者：西蒙泥　回复日期：2005-8-4　11:30:20
首先谢谢大家的鼓励！你们的鼓励是我写下去的动力源泉。
火翼鸟一看就知道是过来人，我对你写的东西也是深有同感。里面有两点：一是国内的市场和客户不成熟；二是公司里的政治问题。有时候我们无法改变环境，也只能适应环境了。自己写这两句话的时候觉得那么地无力，没办法啊，希望我写的东西能给那些做PM的人一些启发，大家一起商量出一些对策来。有空我们聊聊。我的qq:199707086
9.好了，做了很多前期工作，定义了一些游戏规则，现在是坐下来做计划的时候了。这一节，任意找一本项目管理的书都会说得比我好，所以我就少写一点，说一些自己的体会就是了。首先是找几个关键组员，比如客户业务专家、系统分析员等等，做一下项目模块划分工作。项目分成几块去做，每一块完成什么，模块之间的信息如何交换等等。需求定义的是做什么的问题，而这里说的是怎么做的问题。这里要强调一点：完成一个目标有很多种方式，你要选一种你最熟悉的，而不是看上去最完美的，这个思路会让你的项目减少很多风险。有时候客户会被某种新技术打动，坚持要你采用那种新技术，你就应该告诉他：你选我做这个项目，就应该容许我采用自己最喜欢的方式做事情，新技术之所以有诱惑力，就是因为吃亏的人还不多，我不希望你成为第一批受害者。采用一个计划会让你的工作更加明确，比如用微软的Project软件，你填写完表格以后，就可以知道这个项目有多少件事情要做，每件事情需要什么资源，他们之间的前后关系如何，消耗的时间有多长，完成后有什么标志等。所有的结果最后用一个叫做干特图的形式表现出来。你做完这个表以后会惊奇地发现，干特图上项目的结束时间会远远落后于你的计划结束时间（签合同的人永远不会先征求你的意见的）。当然，学过项目管理的人会大谈什么WBS、优化路径之类的东西，但是我的经验是你再优化也不可能把这些东西安排到计划的时间结束。如果你没碰到这个问题，在我恭喜你挑了一个轻松活之前，请你再去确认你是否罗列了所有要做的事情和正确评估了他们所需要的时间。这时候，你就要考虑牺牲一些任务的时间（也意味着质量）了。按照什么标准牺牲？这个项目的战略！我们在第三节提到过的战略。我的经验是如果你什么都赶进度，其结果可能就是十件事情你一件也没做好，想想多么失败啊。所以，把资源投到你熟悉和有把握的事情上，最后的结果是十件事情，你有三件做成了精品，三件完成，还有四件因为某些原因延误，成绩单是否靓丽了很多呢？战略决定优先级，而正确排列事情的优先级是一个项目经理能力的主要体现。
作者：bucuan　回复日期：2005-8-4　12:59:31
不错,做个记号
作者：脚后跟之老茧　回复日期：2005-8-4　13:49:07
忽悠, 接着忽悠. 看你能把我再忽悠瘸了不
作者：西蒙泥　回复日期：2005-8-4　14:12:25
楼上的，其实我真希望自己的忽悠能力能上一个新的台阶。做项目经理的，一种就象我这样的，老老实实干活的，我写这些也是给和我一样做牛做马的项目经理提个醒，做项目时候要注意什么，免得吃力不讨好；另一种就是能忽悠的，把客户忽悠晕了，签了字，把领导忽悠得觉得他的事情最重要，这样忽悠也是本事啊，学习中......
作者：火翼鸟　回复日期：2005-8-4　14:42:22
^_^，同意楼主的忽悠理论。项目没有完美的，只要能搞定客户，及时回款，领导满意，那就是皆大欢喜。项目经理需要这种能力还不止一点点。在中国做项目，现状就是要不顾一切让客户签字验收算数。
作者：Headcoach　回复日期：2005-8-4　15:49:02
>>在中国做项目，现状就是要不顾一切让客户签字验收算数。
作者：海_原　回复日期：2005-8-4　20:02:37
若干时间以后,我也谈谈我的感受,刚毕业,现在是一程序员!关注!
作者：keke89　回复日期：2005-8-4　21:38:39
如果一个项目经理下面人强马壮，做起来就舒服多了，但是这种情形不多。这个年代，人心散了，队伍不好带了。
一个项目经理，除了良好的技术功底，人格、人性的魅力很重要。
能震的住项目中的牛人，能团结人，能提升项目组的士气，很好的洞察能力，能及时发现风险，沟通能力；对进度的把握能力；利用矛盾的能力..............
说白了，是一个保姆ing
作者：煮不熟的鸭子　回复日期：2005-8-4　23:08:03
不同意楼上，往往一群强人作不出什么好事。
我们没有太多的理由来筛选资源，更关键的是要把合适的人放在合适的位置。
人格魅力是很重要的，我赞成。
作者：ydc　回复日期：2005-8-4　23:15:38
达到楼上水平的那种人，都自己创业去了，做什么PM？
要谈PM经验，最好把软件开发，集成等区分开来，当然其基本原理都是一样的，看完PMbook，大家都能说的头头是道，但在实际困难面前经常手足无措。
做过几个具有我国特色软件项目，个人觉得在这方面首先要沉着冷静，因为你会面临很多deadline，所以保持平稳的心态是非常重要的。
实施项目之前，kickoff是必要的，一方面可以让双方增加了解，一方面可以定今后的一些规章制度。
另外，还有就是PM必须熟悉对方的企业文化，组织架构，负责开发项目的PM，由于大都是开发人员出生，很少关注这方面，不要说对方的组织架构，管理流程，可能自己公司的管理路程都不是十分清楚，这在项目实施过程中，往往会很吃亏。
作者：西蒙泥　回复日期：2005-8-5　9:24:09
keke89:
你说得太对了，PM就是一个保姆，什么事情都要操心。对外应付客户领导、业务部门、技术部门的各位大爷，对内面对自己的领导、公司的领导、其他部门的领导、其他职能部门的人（如财务、采购等）、项目组的人，经常是没决策的权力，但是操心比领导还多。做好了是别人的功劳，是应该的；做不好就是你的事情了；但是我不太同意你的兵强马壮理论。一、兵强将不强就会更加乱；二、你往往没有选择组员的权利，只能把现有的人用好，没有无用的人，只有用错的人，想想猪八戒吧。这点我和煮不熟的鸭子的理论一致；
ydc:
我写这个帖子的目的就是吸引象你一样的同行出来发表意见。我十份赞同你关于流程的看法。一个公司做一件事情有流程，所以搞清楚流程十分关键。比如验收、付款这些你及其关心的事情，客户那边的流程是怎么样的，谁牵头组织、哪些人参加，要什么文件、走什么程序、哪些人签字、最后出什么文档等等，都要搞清楚，特别要事先分析和打听哪个环节容易卡壳，做好事先的准备。对于你的第一点观点，我认为是符合PMI的思想，但是在中国，PM不懂点技术是很难和组员沟通的，要PM懂技术的确不合理，但是现实就是这样，没办法。欢迎大家就这个问题再讨论。
再一次谢谢大家的支持！
作者：love_蝈蝈　回复日期：2005-8-5　12:45:52
学习呀!!!
本人马上就要不如项目经理的角色，觉得楼主讲的很实际呀,谢谢!!!!!!!!!!!!!!!!1
作者：love_蝈蝈　回复日期：2005-8-5　12:46:54
步入
作者：young_fun　回复日期：2005-8-5　14:21:21
楼主说的好实在，做中国特色的软件项目开发就是这个样子。
作者：lulualgodon　回复日期：2005-8-5　15:26:54
楼主有一句话讲得非常对，本文是在讲“项目管理的潜规则”
作者：火翼鸟　回复日期：2005-8-5　19:07:13
的确要求pm懂得技术不是一件很合理的事情，在项目组里面，术业有专攻，应该是有专门的技术人员完成技术方案和开发的过程。项目经理需要把注意力更多放在计划和进度控制、项目干系人沟通上，对技术把握太多，往往会削弱大方向上的管理力度。
但是老板往往为了节省费用等等考虑，要求pm作为一个全能者，既要会技术又要懂管理，人情世故也要精通，形象又要好，旁门左道也要会。所以很多公司总是在哀叹pm不好找，另一方面又是很多pm在手下郁郁不得志。
另外我觉得，潜规则是具有中国特色项目中的一个非常重要组成部分。例如说客户方领导和本公司有私下协议利润分成的话，那么好好利用这一点，项目经理可以轻松摆平很多阻碍的人和事，更有把握的完成项目。本人就曾经干过这种事情。只是辛苦对方的局座大人，为了提前完成验收，居然给我当了一整天的司机。^_^
作者：金白沙　回复日期：2005-8-5　21:05:42
项目经理是干啥地？
作者：煮不熟的鸭子　回复日期：2005-8-5　22:05:10
从技术出身的人很难割舍技术情节的。
我觉得PM一方面应该队技术的全流程清楚，另外一个方面不应该过多的去干涉技术负责人的管理范畴。
PMP就是个理念，真正运作起来的困难都是实际的，一个优秀的PM需要提高自身各方面的素质，特别是沟通能力。
作者：无名无欲　回复日期：2005-8-6　10:54:58
精彩!
我刚要上研一(计算机应用技术),不想做纯粹的程序员,以后可能往这个方向发展.
作者：西蒙泥　回复日期：2005-8-6　13:31:45
我觉得不管你是做什么出身，做项目经理还是懂一点技术为好，一方面和开发人员有沟通的基础，减少沟通环节；另一个方面对工作量的大致评估也有很好的帮助。现在的趋势，项目经理是个万金油，懂点客户的业务，懂点技术，懂点管理，懂点财务，晕！楼上的怕了没有？还想来做项目经理？嘿嘿......
作者：菜汤面　回复日期：2005-8-6　14:14:47
PM原则上来说，做的不过是硬、软两点
1。硬：项目完成的原则框架时刻把握
2。软：协调参与各方面的利益（台面上的、台下的），在硬的原则无重大变化情况下，让参与者都满意。
做到这2点，并不容易，斗智斗勇斗力。能做到80%，项目也就搞定了。
作为PM个人来说，捉鸡摸狗斗蛐蛐，五花八门，懂得越多，工作越有利了。
作者：风998　回复日期：2005-8-6　17:19:28
项目管理都是人精干的．什么专业知识，只要你会做人，会协调，会用人，啥事搞不定．
作者：hcjcdtk61　回复日期：2005-8-6　18:55:10
受益匪浅，收藏了！！！！！
作者：dyflie　回复日期：2005-8-7　23:28:40
楼主经验，先收了再说。
作者：茅厕中的石头　回复日期：2005-8-8　4:32:16
本人的看法，在国内项目经理就是万金油，你不但在技术上是顶刮刮，在项目组有重大变化的时候自己要顶上去；而且你还要是一个总协调的角色，客户，客户的领导，团队成员以及你自己的领导都需要你去协调。而且国内的项目经理基本与西方的项目经理就是两回事，这也是东西方文化差异造成的，西方文化强调先制定规则再做事，而东方文化是先把事情干起来，再制定规则。
作者：网络电话机　回复日期：2005-8-8　11:39:18
谢谢了！

作者：西蒙泥　回复日期：2005-8-8　15:33:56
很多时候，理想和现实的差距总是让我们唏嘘不已。作为我本人的原则，我绝不赞成项目经理自己象救火队队长一样也忙东忙西去填窟窿；但是另一个方面，尤其是我们这些技术出身的项目经理，项目做到最后阶段，往往自己就成了一块大抹布，哪里脏就往哪里擦。至于运筹帷幄，决胜于千里之外，谈笑间强虏灰飞烟灭，都是空中楼阁咯。出现这种情况，一方面说明计划没做好，项目的前期准备工作不够；另一方面也说明很多项目，计划赶不上变化，领导旨意，长官意识，客户的嘴是最大的，这时候，项目经理即使是孙悟空，又能如何呢？
作者：HexKK2　回复日期：2005-8-8　16:42:09
heihei xue xi
作者：小风吹　回复日期：2005-8-8　22:22:41
获益非浅，继续关注中。。。。
作者：煮不熟的鸭子　回复日期：2005-8-9　0:05:02
同意西蒙泥，小的项目里项目经理可以兼职，但是在大项目里如果过多的兼职简直就是灾难。
PM需要具备很强的大局观。
作者：西蒙泥　回复日期：2005-8-9　10:23:39
好，现在项目已经完成了前期工作，了解了项目的目标、搞清楚了手上的资源，制定了项目的策略，然后编制了项目的整体计划，项目进入实施阶段。进入这个阶段反而是项目经理比较空闲的时候，不像前期的时候项目经理要象记者一样到处和不同的人接触，搞清楚他们在说什么，努力猜测他们在想什么和他们的真正目的，那才是最累人的事情。当然，小项目的项目经理往往自己也是一个资源，要做很多事情，这时候反而比谁都苦。项目经理这段时间的主要工作是保持和客户领导以及自己领导的沟通。和客户领导沟通时特别要注意，除非你需要对方给你支持，那么你才需要讲得具体一点，否则，告诉他一切正常就可以了，而且态度要积极一些，千万不要说一些领导不懂的细节，比如：“王局长，最近项目进度还算正常，就是JVM经常发生一些内存泄漏的情况…”王局长：“(*&$@@”。和自己的领导汇报也要注意这个问题，除非他是一个技术高手，你需要他的技术经验，否则一般就汇报进度是否正常以及有问题时你的对策和打算就可以了，有些需要他支持的地方，比如资源调用需要说详细一点。和组员开会，除了一些项目进度跟踪会议以外，还有很多讨论会，需要大家用头脑风暴方法给出解决问题。与会人员很多都是技术人员，他们的特点是注重细节、缺乏大局观、有点消极悲观、自尊心强（如果总结得不对，欢迎大家拍砖），所以，你作为会议的主持人，只要负责提出问题和记录下他们的观点，千万不要做评判者的角色。一个问题，有很多方面，从不同的角度看，现象是完全不同的，想想盲人摸象的故事吧。这些技术人员，他们往往精通一个方面，就自己的角度发表见解，除非一些很特别的情况，你都应该认为，他们提出的方案，从他们的角度来看是最合理的。你的长处是掌握事情的优先级，评估各个方面的轻重缓急，从而根据他们的意见得出一个合适的（而不是正确的）方案。所以，在会议上，你要充分尊重每一个人和他的意见，夸奖那些意见提得比较好的人，千万不要把会议带入无休止的争论（你要让大家知道事情不是非黑即白的，而是多元的，唉，我们的教育惹的祸…）。会后，你自己写文档，做决定。会议上大家的面子都被照顾了，自己实施起来的阻力就小，如果还有意见的，你就私下找他聊，如果还不能说服他，你就要让他明白，因为你负责这个项目、你担当风险，所以，这个优先级应该你来判断。组织中的高层，并不见得水平会比一般的成员高，但是，他要承担组织的风险，加之信息的不对称性，所以，对事情的优先级的判断肯定比下属强。
作者：西蒙泥　回复日期：2005-8-10　9:09:57
在开发过程中，内部管理还要注意的一点是时刻强调以验收为目的的思想，每个任务的最终可交付成果一定要是可以被检查的，比如，【界面要求：美观大方、简洁明快】，这个要求我就不知道如何检查。所以，给开发小组布置任务的时候就要考虑如何检查结果，比如我见过一个计划，里面有一个任务【开发人员熟悉EJB编程】，这个任务，除了让这些人去参加一些专业认证考试，否则，结果很难被检查。所以，时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情，我听说有些老项目经理拿到项目是倒排计划的，即首先看如何验收和验收标准，然后决定工作计划。很多项目开始了很久，还不知道如何验收，那么这个项目出问题的可能性就很大了。做项目就是为了验收，我们的角色不是研究机构，我们的目的就是在付出那么多劳动后得到结果。
另外我插一句：我是极其不主张到客户现场开发的。尤其是一大群技术人员直接和客户交流，很容易引起冲突和矛盾（技术人员的本性决定的）。我的做法是项目经理和项目实施人员到现场，软件开发人员还是在公司做项目。项目实施人员就是初级项目经理，他们了解自己的产品，懂得一些客户的业务，关键是在于他们具有良好的沟通能力，俗称“皮厚”。他们是客户和研发人员的桥梁，其职业方向也是很机动灵活，以后可以有很多方向可以转，比开发人员的路要宽得多。
作者：西蒙泥　回复日期：2005-8-10　11:38:21
成了我的自言自语咯....@^@...
作者：西蒙泥　回复日期：2005-8-11　14:43:19
接着，我们再谈谈最让人头痛的需求变更问题。变更通常分为两种：一种是部分更改了原先的目标，即需求变更；另一种是没改变目标，但是客户不满意目前的实现方式，大到流程的实现，小到界面的布局，都是属于这类。碰到这种情况是难以避免的，主要是事先沟通的不够充分和客户随着项目的进展，慢慢想清楚了问题，改变了以前的思路。这时候，如果需要改并且你的战略是容许这种情况的，那么注意下面几点：
1. 确保以前的文档，就是记载着以前的结论的东西，客户是否签过字，如果没有，赶紧把你的工作停下来，赶快再和客户自己确认一下你的方案，然后让他签字，避免以后说话没有凭据；
2. 和客户坐下来，自己探讨他修改的根本目的是什么，是不是有同样能达到相同目的，但是对你来说有代价更小的选择？
3. （项目初期的工作）明确更改流程，一般是客户指定一人签字（否则客户每个领导都有权力来插一杠子，你就废了），以正式项目文件的方式提交给你，然后，你做评估分析，分析对成本、进度的影响，在你的领导同意后，出相应意见书，主要是要说明更改设计的原因和指出由此带来的不确定后果（这个东西先写出来，后面如果真的发生了，至少不是你的错）。然后再让客户在上面签字。见过医院给病人做手术以前让家人签的免责条款吗？对，就学习那个，让大家都意识到任何的更改都有成本和代价。
作者：枪杆出人权　回复日期：2005-8-11　21:11:17
不错,顶楼主
作者：走走看11　回复日期：2005-8-11　21:43:47
hehe
作者：火翼鸟　回复日期：2005-8-11　22:06:56
关注楼主讲讲项目中的客户培训和推广过程中各处系统（包括数据库）的升级问题。个人认为这是实施中最麻烦的两处细节。期待能看到有效的解决办法。
作者：西蒙泥　回复日期：2005-8-12　11:30:34
火翼鸟：
我理解你的问题是：一、如何解决项目中客户的配合程度不高的问题；二、如何解决在新项目上马时，新老系统的关系问题，比如新系统要用到老系统的数据，以前的数据如何规范化等问题；我的理解正确吗？
作者：火翼鸟　回复日期：2005-8-12　19:05:08
回楼主：
其实我的意思是：第一条关于培训，对于一个全新的系统而言，如何把握在上系统和培训之间的时间先后关系，并且能够在较短的时间内教会客户正确接受很多功能，不至于因为熟悉系统的时间过长而影响业务或者产生厌烦情绪。要做好这一点，好的培训人员和计划只是一部分因素，更多要把握如何调动客户和过程的合理循序渐进。我觉得这一点很有些学问。
关于第二条系统的升级，主要是指本公司的程序和数据库升级。如果客户的系统分布在多个地方，而客户自己又没有得力的技术人员，那么如何在合理完成这些升级服务的同时，尽量减少人力和时间的消耗就是个学问了。特别是数据库的更新，光靠制作自动升级程序可能无法实现吧。
静待楼主的建议。谢谢先。
作者：西蒙泥　回复日期：2005-8-15　9:16:12
这几天比较忙，没有写新的东西，这两天抓紧写点和回答楼上的问题。
顺便说几句今天，抗日战争六十周年纪念日。我无意再煽起一些反日的情绪和激烈的词语，其实，日本人很现实，他看不起不如他的，但是绝对尊敬比他强的。我们如果要反日，最简单的就是把自己的事情做好。中国人其实很聪明，但是，集团作战能力就相对偏弱，这个有文化的原因，也有组织者的因素。所以，我们做项目经理的就是最基层的组织者，我们的水平提高了，整个社会的很多运作就会更加顺畅、更加有效率。
－－－与所有项目经理共勉
作者：西蒙泥　回复日期：2005-8-15　10:22:39
火翼鸟：
我还没写到培训和验收阶段，你的题目就来了，那么，就你的第一个问题，我尝试着谈一下自己的看法，希望能对你有参考价值。
系统开发告一段落后，就进入客户培训、系统验收阶段，这个阶段，我一般会注意以下几个问题：
一、给客户做培训前，多注意一些表面功夫。很多程序员认为，系统的逻辑核心是否正确是关键，至于界面如何，界面上的用词是否准确，那是无关紧要的问题，而且培训的时候也是信手拈来，想到哪里说到哪里，下面听讲的人不知所云，云山雾罩，培训效果自然可以想象。我的体会是，给客户做培训的版本，如果你在做多次测试以后仍然不能确定逻辑是否合乎要求，那么，你至少要在界面上多花一点功夫。注意每个界面的布局、用词、链接的正确性等等，总之不要让客户看到一些他不该看到的东西。文档方面，准备至少两个文档：用户手册和培训手册。这两个文档的内容很多都是一致的，但是角度完全不同。用户手册往往是站在系统设计者的角度，按照自己的思路，分模块讲解系统的操作和功能；而培训手册，一定要站在客户业务人员的角度，根据每个角色面对不同业务的办理，如何通过使用本系统的一系列功能来实现目标。所以，第一次培训以前，系统界面是否完整正确、培训文档是否完备都是很关键的因素，第一炮打不响，以后就麻烦很多。
作者：半里不留行　回复日期：2005-8-15　10:31:15
需求变更，其实哪里有这么难得。
做到一半就知道客户是怎么样子的了。以刁对刁，以客气对客气。但明确一点，需求变更有记录，用户提出的须签字。连这都做不到的客户，又为什么非要做呢？在没做完之前，尤其是一半的时候乙方还是老大。做完了，到收钱的时候才轮到甲方。
国内项目经理最大的问题其实是资源不足，什么权力都没有。这个市公司的问题，所以项目经理还是有点技术比较好，起码知道需要资源的底线在哪里，必要的时候自己也算资源上去干。
作者：hentian5858　回复日期：2005-8-15　12:29:49
顶楼主！
我是一个刚刚开始PM之路的年轻人，你的经验让我学到了不少！
PM给我的感觉是：人际关系很重要，你要学会与各式各样的人沟通！譬如，我是在深圳搞手机项目的！我们公司比较大，主要是手机贴片，但在这个基础上也做自己的产品。所以我们PM事情就很杂，要和各式各样的人联络。从最初的项目确认，到中间物料的确认，和生产中碰到的问题，甚至连售后都要负责！有时感觉自己一天都很忙，但就是没具体做什么事！
“我觉得最忌讳的还是上层领导的干涉太多，不给pm充分自主权。如果按照领导的去做，做好了，是他的成果；没做好，责任是pm的。我现在的总工就是这样，经常因为一时性起去变更项目过程，完全无视于项目进度计划。回头还会责难项目经理为什么进度没有合乎计划安排。碰到这种事情真是让人无语。前面两种提到的两种情况，如果是通过项目经理的个人经验和领导能力，还是可以想办法克服的。但是碰到那种横加干涉的领导多了，再好的项目也有做砸的危险。”
这段话说的很有同感，我们公司是由BOSS直接负责的。项目的变更很频繁，因为主要是贴牌手机，所以经常碰到各式各样的状况，BOSS做出调整也是正确，问题是生产自然就无法正常进行，这往往就成了我们PM的责任。譬如前期做南方高科的手机，可南方高科一出问题，我们就得换品牌，自然，结构料等东西也得更换，既浪费了物料，也耽误了生产，没在五一以前正常量产！为此，BOSS还发了火，可这到底算是谁得问题啊 ！
感慨了这么多，希望和这一行得聊聊！我的QQ是22998270！多多学习！
作者：西蒙泥　回复日期：2005-8-15　15:39:09
上面讲的是培训的时候，丑媳妇要化妆好再去见公婆的问题。其实，项目实施中还有一个考验项目经理功力的就是如何调动客户积极性的问题。一般来说，客户是懒的，这就是他花钱找你做事情的原因。一个项目的成败，和客户的配合程度很有关系。根据我的分析，一般项目中的客户都可以分为三类：支持的、消极观望的、抵触的。他们人数的分布一般是一个纺锤形：支持的和抵触的人少，观望的人多（如果你接了一个人人都抵触你的项目，那你还是不要做了）。首先，分析一下那些人为什么支持你和抵触你。很简单，于公于私两个方面分析，上了新系统，谁的工作量有所变化？谁的潜在利益是否受到威胁？谁的岗位是不是因为新系统而消失？传统的利益格局因为新系统的使用而发生怎么样的变化，这些东西，都是项目经理必须去了解的，这样，你才能团结那些支持你的人，消减那些抵触你的人。项目经理是一个很奇怪的角色，属于典型的责任大、权力小的角色，他能做的只有借力打力，不管在自己公司还是在客户那里，一定要依靠别人才能完成自己的目的。只有了解哪些人会因为什么而帮助你，哪些人会因为什么而抵触你，你才能让客户配合你做工作。比如上一些内部计算机辅助管理系统，其必然后果就是让本来管理混乱时有人可以浑水摸鱼的一些利益消失掉了，这样，有些人肯定就要捣乱，到处诋毁这个系统。这时候，你就可以散布一些“谁抵制新系统就说明自己屁股上有屎”这类的论调去压制他们，减弱他们的影响。
作者：cybereagles　回复日期：2005-8-15　15:56:39
同意楼主，很多时候，在一个领导嘴里，垃圾项目也能变成一个合格产品，合格产品也能变成垃圾工程
作者：sdac　回复日期：2005-8-15　16:03:23
我虽然不是PM，但前后几个公司实施SAP的时候与不少PM打过交道。觉得现在PM最大的问题就是不了解客户的需求，也没有能力了解客户需求。国内的公司一方面是很难达到西方的工作标准流程，另一方面社会经济发展太快，公司流程的不断进步、完善而改变导致项目很难按照最初设计完成。这个时候我真希望PM是一个工作流程的明白人，不过实在太少了。一般就是照着例程干完了项目，就抱怨客户不结款，TNND能气死我。
作者：西蒙泥　回复日期：2005-8-15　16:23:27
同意楼上的看法，如果项目组没有办法和客户用客户的业务语言进行沟通的话，那么项目的目标定义就会有问题。最后项目组觉得需求一直在变，客户觉得你帮你挠痒，就是挠不到那关键的地方，总是在旁边抓啊抓，呵呵...
作者：西蒙泥　回复日期：2005-8-16　10:30:47
火翼鸟：
就你的问题，除了我上面说的：
一、第一次培训要做好准备功夫，一炮打响；
二、团结支持你的人、减少抵触系统的人，带动大多数观望的人；
以外，我觉得还有一些要注意的：
一、抓住一切机会给客户灌输你的实现方式，给他们心理准备，不会感觉新的东西太突然；
二、培训、试运行过程不宜过长，免得搞得双方都很疲劳。从编码结束、培训、新系统数据准备到试运行，一定要紧凑，让大家在忙碌中上线。否则，时间拖长了，再给客户挑出几个小毛病，你的组员士气下来了，人心散了，队伍就不好带了....
三、等下我再写验收的问题，试运行很短时间就尽快验收，否则也会拖得很惨。
作者：西蒙泥　回复日期：2005-8-17　21:52:50
我以前碰到过的最悲惨的情况：带着一个项目组在客户那里，客户到了试运行阶段才提出这样和那样的问题，而我们又是异地开发，大家都觉得做得差不多了，天天催客户验收，客户要么就是拖，要么挑你一个小毛病不验收，结果大家士气越来越低落，整天和客户吵架......
大家觉得有什么好办法摆脱这种情况吗？
作者：水煮鱼ok　回复日期：2005-8-18　15:57:12
我的奋斗方向就是pm，没想到pm做起来这么难，看来以后的准备工作还是很多的，学习中....也希望更多的pm参与到经验畅谈中来。
作者：水煮鱼ok　回复日期：2005-8-18　16:01:00
收藏！等待大家再发表些意见和自己的经历。
作者：拈花浅笑　回复日期：2005-8-19　13:03:09
真实的体会
作者：冬瓜123　回复日期：2005-8-19　13:40:42
又看到这个贴了，～～～～～～～顶
作者：一定不回来　回复日期：2005-8-19　15:04:51
好东西
作者：激情之后的宁静　回复日期：2005-8-19　15:51:21
ÎÒÃÇÊdzɶ¼Ò»¼ÒÅàѵÖÐÐÄ£¬Í¬ÊÇÒ²ÊÇVUE PROMETRICÊÚȨµÄ¿¼ÊÔÖÐÐÄ£»ÎÒÃÇÒ²ÌṩITÈÏÖ¤´ú¿¼·þÎñ£»ÊÔÌⱦµä£¬Ô¶³ÌÅàѵ£»´úÖØ·¢Ö¤Ê飻´ú¿¼·þÎñÌṩ´øÓиÖÓ¡µÄ³É¼¨µ¥Ô­¼þ¡£²ÉÓ÷ÖÆÚ¸¶¿î£¬¾ø¶Ô±£ÕÏÄúµÄÀûÒ棻ÏàÐÅÎÒÃÇÊÇÄú×î¼ÑÑ¡Ôñ£¡ QQ447242940
作者：激情之后的宁静　回复日期：2005-8-19　15:55:57
我们是成都一家PROMERIC和VUE的授权考试中心,我们提供IT认证代考服务, 试题宝典,代重发证书,代考服务提供带有钢印的成绩单原件.采用分期付款,绝对保障你的利益.QQ447242940
作者：火翼鸟　回复日期：2005-8-19　18:11:44
好久没空来看楼主的帖子了，先谢谢楼主有耐心回答了我的问题。有些东西稍后还希望能与你探讨。
作者：西蒙泥　回复日期：2005-8-17　21:52:50
我以前碰到过的最悲惨的情况：带着一个项目组在客户那里，客户到了试运行阶段才提出这样和那样的问题，而我们又是异地开发，大家都觉得做得差不多了，天天催客户验收，客户要么就是拖，要么挑你一个小毛病不验收，结果大家士气越来越低落，整天和客户吵架......
大家觉得有什么好办法摆脱这种情况吗？
×××××××××××××××××××××××××××××
这种事情说实话我也碰到过，起因是合同的定位实质上与客户的真实需求相差较大，导致做出来的东西不满足客户的要求。而客户刚开始也不懂，随着项目的深入才逐渐明白自己到底需要什么。这个项目毫无疑问做到后来已经进行不下去了。到了这个时候，决策已经超出了项目经理的权限，需要执行组织的高层来决定，是牺牲利益保市场，还是砸掉项目避免亏损。
所以我觉得这种情况的出现，就意味着这个项目很难善终了，没有什么很好的办法能摆脱困境。最妥善的方式就是双方平心静气协商，对验收的目标做一个修正，主要是客户能接受在那种程度上完成验收。即双方都让步来达成妥协再作打算。能这样的话，还可以拉拉扯扯把项目搞完验收。不过到了这个地步，客户关系也很难指望能好到哪里去。
作者：火翼鸟　回复日期：2005-8-19　18:18:41
再请教一个细节：例如说项目客户是企事业单位的办公人员，其中还有不少是各科室的头目。他们事务繁忙，又对新事物不是很敏感。如果给他们集中培训的话，可能连人都凑不齐，而且上课的时候明显心不在焉。但如果分别讲解，在他们使用的时候才随传随到，以家教老师的角色去培训的话，会投入大量的人力和时间，造成资源浪费和工期延长。
碰到这类情况，各位pm如何解决？
作者：偏心小鬼　回复日期：2005-8-19　22:05:06
汗，
没遇以过此类事件
静待各位前辈的解决方法，
见谅
作者：老阿三　回复日期：2005-8-20　1:47:54
回复火翼鸟的问题：
我建议可以做一个自动演示的Demo，最好加上配音，先提前发给所有客户，过两天后来一次集中培训（最好把具体做事的人培训好，他们可以去再培训那些头目），之后如果他们还要随传随到的话，就告诉他们看Demo，配合电话指导就可以了。
作者：西蒙泥　回复日期：2005-8-21　11:32:09
回复火翼鸟的问题：
这个问题和前面的一样，都是客户配合的问题，只是角色换成了中层领导。按照我上面的思路，分析一下这些人的想法：
如果这个项目是客户高层推动型，比如是对方领导的政绩工程，那么最简单了，擒贼先擒王，拿他的领导压他，当然，沟通的时候注意技巧，摆出他领导热切关注状，呵呵...
如果这个项目是为了解决业务部门的需要的，那么，你就抓住那些从这个项目中受益的业务人员，领导嘛，以后再说；
如果这个项目客户这边都很不感兴趣，那么，你的确是接了一个挑战性的活，那只有发挥个人魅力和寻求自己领导的帮助了。如何激励人是项目管理中一个看上去简单，其实及其复杂的事情，涉及公共信仰、企业文化、个人价值观等。
最后，有一个体会和大家分享：千万不要觉得对方的领导（中层干部）是应该配合你工作的，特别是一些国营单位，多一事不如少一事，他干吗要帮你？我的经验是：对方领导如果没有拿你的事情作为内部斗争的武器而从中作梗（当然，他针对的不一定是你），那已经是算合作的了，记住，他不捣乱就是帮你忙了。
作者：O_V_R　回复日期：2005-8-21　19:42:39
掌握基本的流程和方法并不困难，到最后，还是一个驾御人的问题。
作者：火翼鸟　回复日期：2005-8-22　14:48:23
个人觉得楼主这个贴子发到天涯真是浪费了，整个IT视界里面全都是华为中兴的内容，真正的技术类贴子是很少有人关注的。
作者：西蒙泥　回复日期：2005-8-22　15:02:30
谢谢楼上的关心！这个帖子我在项目管理者联盟上也发了一份，那里很多人指出了我很多不足的地方。
大家关心华为中兴，说白了就是想找个好工作，这个无可指责。但是，我劝大家一句，在找工作以前，你自己已经明确定位了吗？你自己已经有了明确目标了吗？这个工作在你的计划中是起什么作用？把这些想明白再找工作，对自己，对用人单位都有好处。
不过天涯还是高人很多，比如我以前看到的《笑傲职场》和老雾的一些帖子，对自己帮助就很大，如果早十年看到这些，也许自己的发展就会更好一点。
作者：火翼鸟　回复日期：2005-8-22　21:26:55
楼主那个帖子发在项目管理者联盟的哪个位置？给个地址好吗？我一直也想发这么一个帖子讨论一下项目管理的得失，更多想探讨探讨在中国当前的企业环境中，一个pm的走向问题。不知道那边的专业同仁们能不能给些启发。
作者：西蒙泥　回复日期：2005-8-23　09:31:54
首页最新推荐链接：http://www.mypm.net/articles/show_article_content.asp?articleID=8144
论坛链接：http://www.mypm.net/bbs/article.asp?titleid=31008&ntypeid=24
作者：西蒙泥　回复日期：2005-8-24　14:31:36
继续自拉自唱，呵呵......
作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的，属于典型的又要马儿跑，又要马儿不吃草的类型。考虑问题的轻重缓急方面，往往是把快放在第一位，各方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，企业的根本目的是盈利，如果收入不能增加的话，至少费用要控制住；好是第三位的，没办法，谁都想精益求精，但是，没有强大的资源保障，质量只好先牺牲了；最后是多，客户的要求源源不断，如何降低客户的期望值，让他们从理想回到现实也是项目经理的分内工作。
验收前，除了做好文档工作，即可交付成果以外，多花时间搞清楚客户的做事情流程是很重要的事情，这些在前面已经有所提及，这里就不再多说。
我对验收最大的体会就是举证问题。即千万不要让客户这么想：你必须有证据证明你的系统是没问题的。这样你就没戏了，微软那么多天才，做了XP还天天打补丁，要你的程序没问题，既不可能，你也没办法拿出证据。你要让客户明白，所谓验收，就是我按照测试文档的测试用例跑一遍，结果和预期结果一致就应该算通过了，而且还容许有一些小错误留在验收后改正，他可以对测试用例提意见。所以，验收前双方要确认测试计划和测试用例。如果他认为系统不符合要求，那么他应该举证，证明这个系统和最初设计相背离的。所以，参考法律概念，千万不要举证倒置。另外，认为系统完美了才能验收的想法也是错误的，软件开发合同里一定要注明验收以后维护期的费用问题，否则，客户担心一旦验收就得不到你们的支持，自然不配合验收，那么，你这个项目经理就很难交功课了。
作者：游遍天涯　回复日期：2005-8-24　14:56:10
精品贴，攒一个
作者：whtrelax　回复日期：2005-8-24　16:01:01
希望可以结识你这位朋友，我是做强弱电系统集成的，在这个行业也有几年的光阴了，多交流也希望有机会可以合作。QQ21439908
mesn:whtrelax@hotmail.com
作者：卡爱牵牵　回复日期：2005-8-24　18:57:58
很粗略地看了一下，不知道你们在讲什么东东，但是心里觉得很舒坦，非常喜欢参与这个帖子讨论的这些人，尤其是楼主。
在天涯逛了这么久，越逛越没劲，几乎每张帖子里面都在打口水仗，很少看到这个帖子里面这么平和安详的氛围，尤其是楼主，谦逊随和，不像别的帖子的一些楼主和随贴者，一看到不同意见，马上跳脚骂开了，骂的那个话真叫难听啊。
不过，还好，还是有这些有素质的人啊。
作者：keke89　回复日期：2005-8-24　21:02:10
项目管理是一门艺术。
让大家可以从项目中各有所得，是一个关键。
了解项目的进展，发现风险存在的地方。
项目管理是一门EQ。
让你的意志得以灌输和执行，你必须充分利用项目中的矛盾（一团和气不利于相互推进），你必须树立项目中的标竿，你必须有规章制度（控制不住了，就可以用制度要杀鸡敬猴），你必须会化解矛盾，你必须保持士气，你必须培养技术氛围，你必须能和上级沟通顺利，你必须和下级接近，你必须把私人感情抛开来公平评价下属............................
作者：西蒙泥　回复日期：2005-8-25　12:45:49
楼上说得好！
所谓科学就是经过反复论证，输入和输出有必然规律的东西，种瓜得瓜；而艺术就是思想火花的闪耀，主要靠灵感。项目管理这个东西，据一个前辈说，在国外是科学，80%是有规律可循的；在国内是艺术，主要靠个人魅力、感染能力等东西。看明白了PMBOK，学会了一些做事情的方式，就象我这样，只是搞懂了那个20%的科学的东西，还有80%的空间，属于见仁见智的领域了。
作者：西蒙泥　回复日期：2005-8-25　16:44:32
写这个文章的目的是想提出自己对项目管理很多方面的一些自己的看法，然后得到大家，尤其是同行的帮助，指出同一问题的其他方面。我感谢很多人对我的夸奖，但是，如果你认为项目管理就是要记住很多条条框框就可以把事情做好，那就大错而特错了。对事情最有效的处理就是把握事情的各个方面的优先级，也就是人们常说的度，根据托利德定理定理，有些方面甚至可能是相反的。
托利德定理：测验一个人的智力是否属于上乘，只看脑子里能否同时容纳两种相反的思想，而无碍于其处世行事。
提出者：法国社会心理学家h.m托利得
点评：思可相反，得须相成。
作者：西蒙泥　回复日期：2005-8-30　15:17:15
最近忙着做一件无聊的事情：翻译PMBOK2004，私人帮忙，不牵涉版权问题。如果谁有现成的，麻烦发一个给我，谢谢先！
作者：痞子文文　回复日期：2005-10-6　09:58:59
怎么干什么都哪么难呀
作者：用一生下载你　回复日期：2005-10-6　10:13:31
lz
实属不易，能写的如此流畅，估计在这行当混了不少年头了。
做项目最重要的一点就是 按照自己的计划把它结了！！
作者：lane_cn　回复日期：2005-10-6　11:12:53
我觉得做软件，管理软件项目，重要的是需求。需求调查的目标在于调整项目的目标，使得项目目标和企业的业务目标一致。一旦达到这个目的，你会发现客户提出的需求变更，其实早就在你的掌握之中。
文档打印，签字画押的方式能解决一定的问题，但是不是根本解决问题的方法。做软件的人要去理解客户的业务，真正的为客户着想。
对项目范围做一些限制是必要的，但是人为地给客户提出需求制造障碍，最后可能会带来一想不到的后果。
从客户角度来说，业务在随着时代发展，电信公司不断推出新的服务项目，推出新的优惠形式，企业决策者可能会关心新的数据指标，这些业务发展就注定了软件需求必须不断的变化。适应变化的能力就意味着软件项目的生命。软件要拥抱变化，而不是拒绝变化。
作者：西蒙泥　回复日期：2005-10-8　9:19:33
楼上的说得对，做项目的人如果不了解客户的业务，那是一定会失败的。我以前几个做得比较成功的项目，项目完成后，我们已经比客户更加了解他的业务流程，系统上线后，业务人员经常还打电话来问某些业务如何处理。另外，目前的系统越来越复杂，很多系统在开始阶段是没有办法搞清楚需求的，所以，只能是双方坐下来，在一些纲领性的东西上达成共识，然后，随着项目的推进，需求渐渐明朗，具体的开发工作才可能进行下去。现在的软件理论也慢慢地开始适应这种方式。但是，这种做法，大大提高了对项目经理的要求，使得范围管理成了一件极其有挑战性的工作。
作者：西蒙泥　回复日期：2005-10-30　19:18:54
项目在进行时，要做很多文档工作记录项目目前的进度。这种工作，一些工具软件，如Project就有相关的功能。但是，项目进度汇报经常牵涉领导，领导一般不用那么专业的工具，那么，大家有什么好办法去做这些项目进度汇报呢？
作者：O_V_R　回复日期：2005-10-30　19:35:03
LZ， PMBOK2004在国内中文版已经出了。
http://www.mypm.net/books/show_book_info.asp?BookID=1051
作者：迷宗腿　回复日期：2005-10-30　20:15:48
记号，学习中！期待高人出现！
作者：ydc　回复日期：2005-10-30　22:42:23
如果涉及给领导汇报项目进度，PM除了用邮件，最好亲自去汇报，比如到了里程碑或者进度需要变更等比较重要的事件。
周报需要甲乙双方项目负责人都签字认可，避免以后口说无凭。
Project工具虽好，给领导看可能就比较够呛了，最好打印出来给领导。总之，这些东西需要OO，看对方的习惯决定采用什么形式。
作者：ydc　回复日期：2005-10-30　22:47:12
对于需求，我觉得应该是架构师，SA更需要关注的问题。可能我们的PM一般都身兼数职，所以大家觉得PM也应该关注需求。
对于我不熟悉的业务需求，我倾向于改变开发过程，调研需求可以借助原型法，开发的时候采用更加敏捷的过程，一般没有超过5个人的Team，我都倾向于采用敏捷的过程。
作者：西蒙泥　回复日期：2005-10-31　10:37:36
谢谢O_V_R，这本书我知道，但是有人说翻译得不好。我以前看这类书也有这个感觉，因为翻译的人绝大多数是高校里的研究生，没有实际的项目管理经验，所以，很多东西都是按照字面上翻译。不过我最近也很忙，翻译的公司也停了下来。英文水平还是不过关啊，呵呵。
ydc，谢谢你的答复。我是一个懒人，现在汇报工作都是自己写报告，然后把project里的一些进度条粘贴到word里去，感觉很麻烦。我听说有一些项目管理的工具，每个人都有自己的工作界面，这样，项目组的人知道详细的进度以及和自己相关的工作安排、项目经理知道总进度和一些相关的细节，而领导自己也可以登陆进去，看到一些图形化的进度报告。我是想打听这方面工具的情况。
对于项目分工，国内的小项目，一般都是项目经理自己兼任架构师，下面的人一般都是具体干活的了，很少还有某方面的专家。即使项目大一些，有专门的架构师，如Lead Architect，项目经理也需要具备一些专业知识，以保证能够和他们做沟通，了解他们的想法并且在一些关键选择上做出自己的判断。所以，项目经理是个万金油，什么都要懂一点，否则很难控制一些细节，除非有很专业的好帮手，而这个在很多大项目里都不一定能碰到。
作者：与象共舞　回复日期：2005-10-31　15:06:40
我觉得需求是项目经理的关键工作，需求就是范围管理的部分。
ydc说需求的系统架构师(SA, System Architecture)的工作是不对的，他是做系统架构的，如果说是系统分析员(System Analyst)才合适，当然项目组中可能没有那么多角色。同意后面说的，需要借助软件开发过程，我想不光是不熟悉的业务需求，即使相似的业务需求，到了后期也有可能发现需求不符，和你想的不一样。原型法，迭代式的开发过程就是为了解决需求问题的，XP希望用更频繁的迭代来拥抱变化。UML的用例分析也为需求分析提供了方法。
说客户需求老变得问题还是出在自己，拿老厚的需求说明书给客户确认有什么用（里面很多就是从客户需求抄的，那有很大的可能是不全的，那还要你分析干嘛）。客户确认了他赖再账你也没办法，因为这个漏掉的对客户真的非常有用。
与需求变化相关的更加技术一点是软件体系结构,设计模式和重构等等。如果系统采用了一些合适的模式，将使变化的产生的代价更小。同样重构也有这个作用，设计模式也是重构的一个依据。
需求分析和管理是项目生命周期中最重要的部分。
另外，我想说的是。现在国内的IT项目，管理不是最大的问题。大学教育主要学习的是开发语言等，软件工程学的是比较老的书，在项目中提高主要通过向前辈学习。也学会了浮躁，想做几年技术转管理的多，能把软件工程师当好的真的很少(可能是合格的程序员)。等成了项目经理也不会对大家要求做测试驱动开发，采用更适合的开发过程，采用UML&OOAD。更多的是，项目上来先做一篇word的需求分析，word的数据库结构，然后word的系统设计，详细设计，project的项目进度安排--开发-测试-用户测试-上线，感觉很完美，事实上是开始了冒险的旅程，再好的项目管理也改变不了这个旅程。
对于一个软件项目整体, 我认为软件过程>>>项目管理。CMM的角度，项目经理是要参与项目的过程改进的，这也是项目经理的责任。
对于需求的影响，我认为 软件过程=需求分析>架构和设计>项目管理(谈判，签字，扯皮...)
作者：很胖的胖子　回复日期：2005-10-31　16:40:50
哎呀吗呀，这文章老长了。
作者：hyacthin　回复日期：2005-10-31　17:35:33
见到这么多高人在一起讨论问题,而且还是在这么和谐的气氛中,真的是非常的惬意,不过大家都用的是专业术语,本人看不懂!呵呵!谢谢楼主,你讲的方法虽然我用不到,但是可以用到别的地方,你的经验是放至四海皆准的,hoho!谢谢楼主!
作者：hyacthin　回复日期：2005-10-31　17:36:53
虽然我不懂,但是我会继续关注的!楼主,你好样的!
作者：sxh2　回复日期：2005-10-31　23:26:22
确实收益很多啊,以后会经常关注的
作者：ydc　回复日期：2005-11-1　8:32:42
to以象共舞，我觉得软件项目管理包括了软件过程的控制。对于复杂的业务，一个具有良好伸缩性的系统架构是很必要的，对于复杂的业务（或者Team成员都不熟悉的业务），重要程度 架构〉系统设计〉编码。
to 西蒙泥，如果你的公司够大，还是自己开发一个工具，或者你就用project server，它可以发布出来的。
对于UML，它仅仅是语言/工具，并不能提高设计人员的能力，但或许有助于发挥设计人员的水平。
作者：与象共舞　回复日期：2005-11-1　11:07:00
to ydc
呵呵，我们在讨论项目管理职责呢。软件项目管理包括了软件过程的控制，应该是整个项目的计划和控制。但软件过程就像一条生产线，项目经理只负责控制监督它的运行，它的建立是依靠经验的积累或公司整体的计划。我们说的过程改进就是要改进这条生产线，这不是项目管理的范畴（可以看PMBOK），但项目经理和项目成员都应该参与其中的。
我前面说的可能不清楚，就是说我们很多依经验建立的生产线已经太老旧了，很多环节或整条线都有新的技术和手段来代替。这时候就算项目经理把它控制到最好，生产出来东西还是不好的。
我的中心思想是项目管理重要，过程改进更重要，设计分析技术是基本功是基础(软件体系结构，分析模式，设计模式，......)。
对于UML他的确是个工具， 但OOAD是方法，我学习UML不是学习rose而是应该学习OOAD。我见过很多把UML用的一蹋糊涂的例子。
作者：西蒙泥　回复日期：2005-11-1　16:04:52
很多项目出问题都是出在需求变更这一块，为什么呢？还是对客户的业务不了解。
需求这一块有几样工作：需求调研、需求分析、变更管理。调研就是听客户说自己的业务，所以出来的东西就是与象共舞说的“老厚的需求说明书”，这个活技术含量不高，做好记录员就可以了；真正显示公司实力和水平的是需求分析，通过那么多素材，总结出几条业务主线，根据行业经验，弄明白哪些数据的变化大，哪些数据变化小，什么东西容易变，以后往什么方向变。一句话：分清楚主要矛盾和次要矛盾和相互之间的层次关系。这些东西和IT是无关的，都是需要提炼、总结、归纳能力，这个工作，大项目由Industry Architect去做，小项目只要PM自己上了。最后的成果是一张和本项目相关的客户业务的总表。
下一步，在这张表上的每一个点上细分下去，目的是划分项目范围，知道哪些要做，哪些不做，哪些以后再说。这样，一份做什么、做到什么程度的范围清单就出来了，当然，所有这些都需要客户的确认。这些东西也可以用UML表现出来，尽管我觉得UML还是比较麻烦，而且价格高，客户的接受程度都不是很高（专业程度）。到这里，还是项目经理的事情，而且，项目经理对这些东西要十份清楚，以便判断以后出现的，没有列在计划里的东西按照什么原则处理。
最后，才是IT Arichitect，或者叫系统分析员出马，他根据你们描述的业务和数据情况，决定用些什么IT技术去实现。比如Java里的集合就一大堆，如果系统采用j2e
作者：走在退化路上　回复日期：2005-11-1　16:20:25
to 与象共舞：
你说的这个改进是应该的，也是必然的，但是真正实施的时候要求非常高。如果谁来和我讨论说要改进那个地方的流程，那么我会问依据呢？数据呢？按CMMI的体系，要做到持续改进型。这需要在项目的流程中，对不同阶段进行数据的积累，然后综合历史纪录，做数值分析，得到改进的方向。
BTW：我也是软件PM，当的不好，看诸位的讨论，获益良多，致谢！
作者：fhqiplj　回复日期：2005-11-1　17:03:09
mark
作者：西蒙泥　回复日期：2005-11-2　09:40:10
昨天发了一半，系统出问题，晕...
最后，才是IT Arichitect，或者叫系统分析员出马，他根据你们描述的业务和数据情况，决定用些什么IT技术去实现。比如Java里的集合就一大堆，如果系统采用java开发，他知道这样的数据应该用哪一种类型去实现。另外，产品架构师也是一个角色，根据系统框架图，他会根据这个系统的特点，决定每一个部件采用什么厂家的产品，如数据库到底是用MySQL还是Oracle，j2ee服务器是WebSphere还是WebLogic等等。
所以，我认为，需求调研和需求分析的前期，包括scope的定义，都是项目经理的职责，而后面的IT技术具体实现设计，项目经理可以关注，但不是唱主角。
两位提到的工具不代表方法这个观点我坚决同意，并不是你用了Java就表面你OO了，用Java写过程程序的我见得多了去了，呵呵。
作者：爱上郁闷　回复日期：2005-11-3　8:18:46
做个记号
作者：forests4197　回复日期：2005-11-3　11:30:44
留名
作者：fhqiplj　回复日期：2005-11-4　9:08:33
收藏
作者：mmaxb　回复日期：2005-11-10　17:04:41
留名，下次接着看。
作者：瞎取个名字　回复日期：2005-11-10　17:33:38
：）
作者：szasam　回复日期：2005-11-10　18:00:35
政府项目里,真正办事的没有签字的能力,,有签字能力的今天忙,明天忙,,根本难以见到身影...
作者：资深潜水师　回复日期：2005-11-10　18:54:33
做个记号
作者：西蒙泥　回复日期：2005-11-10　21:03:57
作者：szasam　回复日期：2005-11-10　18:00:35
政府项目里,真正办事的没有签字的能力,,有签字能力的今天忙,明天忙,,根本难以见到身影...
说得蛮有道理，所以你看你要签的文件是什么东西，有些对方的项目负责人签字就可以了，有些就要最高领导签了，这些东西在项目的一开始就已经说好了的，否则突然要别人签字，谁敢给你签？先定规则，让大家习惯嘛。
作者：云淡风轻看海时　回复日期：2005-11-11　17:28:04
作者：西蒙泥　回复日期：2005-11-2　09:40:10
所以，我认为，需求调研和需求分析的前期，包括scope的定义，都是项目经理的职责，而后面的IT技术具体实现设计，项目经理可以关注，但不是唱主角。
充这个 LZ前面某些不专业的东西都可以抹去
这是一个做过项目经理所必须理解的，自己的工作职能都不清楚还在这里议论他人什么呢？
为LZ的实际操作经验与对本职能工作的理解---我DING
作者：小糊涂蛋　回复日期：2005-11-12　10:26:01
PM未必要对所负责的项目有很深刻的了解或者偏执。我们公司的PM很多对他们负责的技术都是不懂的。关键是要协调，控制进度和BUDGET。还有， 就是给我的所有需要他签字的报销单和加班单签字。
作者：西蒙泥　回复日期：2005-11-12　20:16:25
楼上的同学，PM的确可以不懂IT技术，但是如果连客户的业务都不懂就比较麻烦了。我看书上说（我没见过，不好意思）在很大的项目里就存在只负责沟通，不懂任何专业东西的PM，但是在一般规模的项目里，这样的PM似乎很难生存下去。不知道还有没有高人对这个话题发表些意见。
作者：莎歌　回复日期：2005-11-14　19:24:10
在项目管理过程中,我个人认为重要的,也是最难控制的是需求获取与分析、
作者：别来真的　回复日期：2005-11-15　01:26:14
做个记号
作者：梦里醉　回复日期：2005-11-15　09:55:20
我觉得在人员储备上也需要注意,曾经有个项目关键位置上的人病倒,组内没人顶的上去,短时间也招不到合适的人,最终导致项目流产.这个风险也必须考虑进去,在关键位置上人员最好有储备.
作者：云淡风轻看海时　回复日期：2005-11-15　15:23:35
TO: LZ
作者：西蒙泥　回复日期：2005-11-12　20:16:25
楼上的同学，PM的确可以不懂IT技术，但是如果连客户的业务都不懂就比较麻烦了。我看书上说（我没见过，不好意思）在很大的项目里就存在只负责沟通，不懂任何专业东西的PM，但是在一般规模的项目里，这样的PM似乎很难生存下去。不知道还有没有高人对这个话题发表些意见。
PM的概念问题,在不同的项目中PM将扮演的是不同的角色
所谓的大项目中PM的职能是被细分的,也就是一个项目策划组的概念
具体的看项目需要去配备相关的项目人员,需求调研和需求分析的前期，包括scope的定义是PM的基本职能,对项目的风险控制和相关沟通都必须在这个基础之上的
P.S: 小弟不是高人,只是对自己工作的认识,如有错误大家指正. ^_^
作者：fhqiplj　回复日期：2005-11-15　17:09:37
mark
以后慢慢学习
作者：wangshangxing　回复日期：2005-11-15　18:24:37
收藏
作者：harmoniousness　回复日期：2005-11-15　21:17:27
PM最痛苦的，不是客户不走需求变更，而是客户被迫做需求变更（某些行业因监管单位要求）。这种时候，哪怕客户为需求变更付费，也非常痛苦，因为整个项目遥遥无期。
作者：云淡风轻看海时　回复日期：2005-11-17　13:44:55
作者：harmoniousness　回复日期：2005-11-15　21:17:27
PM最痛苦的，不是客户不走需求变更，而是客户被迫做需求变更（某些行业因监管单位要求）。这种时候，哪怕客户为需求变更付费，也非常痛苦，因为整个项目遥遥无期。
同感 我up下
作者：伤心的狗　回复日期：2005-11-17　13:49:14
楼主 俺理解你!!!!!
作者：zhujianf　回复日期：2005-11-17　15:00:16
做软件，关键还是人的问题。理论方法什么的是后话，是衍生物。
作者：ianhwang　回复日期：2005-11-17　17:13:02
乏味。
作者：西蒙泥　回复日期：2005-11-18　14:57:11
作者：harmoniousness　回复日期：2005-11-15　21:17:27
PM最痛苦的，不是客户不走需求变更，而是客户被迫做需求变更（某些行业因监管单位要求）。这种时候，哪怕客户为需求变更付费，也非常痛苦，因为整个项目遥遥无期。
其实，客户的很多变更也是因为自己的需求分析没做好造成的，以前大家都没水平看出来，等到真正上马，才发现问题一堆，于是扯皮开始。我一直做乙方，所以也一直站在乙方的立场说话。需求变化后产生的新工作量往往成了扯皮的焦点，即使有监理在场，也很难说清楚这到底是谁的责任。
作者：micro_wy　回复日期：2005-11-18　17:28:40
讨论的非常精彩
学到了很多东西
以后还是要注重修炼个人能力，主要是提高情商吧！
作者：xingzhikong　回复日期：2005-11-18　19:06:08
获益良多，谢谢楼主
继续关注
作者：pixyfly　回复日期：2005-11-18　19:29:05
感觉这里做PM的人好厉害。。
我想请教一个问题，我是05毕业的MM,本科是工科，第二学位是工商管理。大学里考过 IPMP D
现在在一家公司做硬件研发（台湾的公司，不是纯粹的研发，很清闲），觉得好象也没学会什么实际的东西，目前天天还在看资料。。英文的，关于什么电压控制呀，驱动之类的。觉得女孩子做技术很痛苦，想转行。
可以建议一下吗？其实我很喜欢PM，可是感觉做得比较牛PM都是技术很专业的，我估计我很难达到那个水平。
谢谢了
作者：xuyongzhuzhi　回复日期：2005-11-18　23:13:46
西蒙泥，感觉你好像是HW公司，可是今天2点你却上网了。
作者：西蒙泥　回复日期：2005-11-19　20:34:42
哇，楼上的观察得那么仔细？不知道我哪里露了马脚，呵呵。
作者：西蒙泥　回复日期：2005-12-6　12:49:24
自己顶一下，欢迎大家对我的一些观点进行探讨。
作者：火翼鸟　回复日期：2005-12-6　14:02:41
好久没来了，楼主这个帖子还是热火朝天啊。
对于上面的有个观点，我想重点支持一下。就是在项目团队中，项目经理可以不是一个精通技术的工程师，但是他一定要能熟悉和理解客户的业务，能在客户和系统设计开发人员之间进行流程的解读，并得到双方的认可。所以pm可能是一个富有行业经验的专家，或者是一个很有沟通技巧的人士。他在项目进程中主要是能负责定下系统的基调，然后交与专职的设计人员来完成具体的技术性工作。pmp中对pm的定义就是个综合者，我觉得这个定位很确切。pm就应该更多把精力放在节奏的把握和方向性的决策中，技术性的事情，不需要项目经理分散过多精力。
另外楼主对验收一段的描述，真是让人受益匪浅。我以前也反过类似的错误，做系统总是希望能尽量完美，结果耗费了很多不必要的人力。其实所谓验收，应该就是在双方都对系统内容认可的前提下，保证正常流程能够正确使用就可以了，小的bug，自然有维护期来处理。
作者：zhjohny　回复日期：2005-12-6　15:50:48
项目管理的东东一直在www.mypm.net逛，没想到天涯也出现此等精贴，天涯的PM们幸也。
粗略的看完了楼主的文字和大家的回复，体会颇丰！
记得听一个顶尖的PM说过一句话：“做PM心态一定要好，这是最基本也是最重要的素质。”工作多年来，一直用这句话省试自己。无论是听到“抱怨国内用户不成熟”还是“抱怨PMI在中国水土不符”等等的时候，都在用这句话总结自己的不足。
谈点个人的体会：无论目前国外的项目管理外环境和内环境有多成熟；无论是现在外企的项目管理工作有多么的规范。他们都经历过我们这样混乱的局面。IBM也曾经有过超烂的项目（为了了解这个项目除了赔了几百万美元甚至动用了该国总理）。规范和成熟是需要一个过程的。
很钦佩楼主和坛内的一些同行，碰到困难没有气馁，而是以积极的心态去面对。通过你们让我看到了国内项目管理的希望，也对自己的职业选择充满了信心。希望此贴不沉
-做PM也是做人
作者：fox0007　回复日期：2005-12-7　13:45:14
过客无语
作者：西蒙泥　回复日期：2005-12-11　10:27:48
感谢火翼鸟和zhjohny的精彩论述。
的确，既然选择了这个职业，我们就不必整天去哀叹客户的不成熟、行业无规范等等困境，一方面，有挑战才能显示我们的价值；另一个方面，如果通过我们这些人的探索和总结，为这个环境的改善能做出自己的一些贡献的话，那么我们是何等的欣慰！
作者：nonie　回复日期：2005-12-11　16:10:16
新人，学习ing
作者：solozou　回复日期：2005-12-21　09:04:04
来向前辈们学习学习的，都已经做成word收藏起来了，希望楼主别收版权费。：）
作者：错过开始　回复日期：2005-12-21　9:53:28
其实针对楼主的项目管理,能提出在项目管理中出现的问题,再找出解决方法就OK了.
看了这贴,找项目管理的工作,比较好哈哈.
作者：阿原在这　回复日期：2005-12-21　11:27:04
有空再看
作者：难道如果　回复日期：2005-12-23　16:12:39
顶起，突然有个建议，这么多做PM的，我们建个群讨论可好，小弟也希望和各位同行讨论，共同提高，QQ5280187
作者：wsclf　回复日期：2005-12-24　0:32:21
和很多人的体会一样，我在天涯时间不短（年轻人，长年混迹篮球公园，其他地方也逛逛），却很难看到一个气氛如此和谐的帖子。我是一个计科专业大四学生，大学没学到很多东西但一直想进入软件行业，近几天看天涯上关于软件行业加班问题的讨论看得我直想打退堂鼓，原想到这个帖子看看有没有PM（刚刚学到的词）对这个问题的看法，没想到这是一个专业性质很强的帖子，考虑到我若干年以后也许会走上PM这条路，于是我慢慢看，居然也产生了兴趣，似懂非懂地把他看完了。本人曾在他人督促和指导下写了一个完整的约3000行代码的工程方面的软件（姑且称之为软件吧，实在让各位高手见笑），当然没有任何需求报告，分析之类的，甚至连完整的结构图都没有，作到哪儿算哪儿，所以在后期的修改过程中也吃了点苦头。这学期学软件工程才发现这次实践是大学以来学习上最有收获的事情，对老师提到的很多问题都有所体会，今天看贴，更觉的自己要学的还很多，以后一定要在工作中多多积累。
作者：招架不住　回复日期：2005-12-24　1:30:58
留个记号，改天好好看看
作者：西蒙泥　回复日期：2005-12-24　11:06:37
把自己的观点写出来，在网上得到这么多人的肯定，我感到很欣慰，也感谢大家的支持。
做IT项目经理的人，最重要的能力就是在最短的时间内，把自己面对的一系列事情抽象成一套完整的理论，然后补充完善后，再指导自己的工作和团队的方向。我写的这些东西，都是我在实际工作中总结出来的，但是因为自己经验的局限，提升到理论的程度有深有浅，所以，恳切地希望大家在看到某些观点得到共鸣的同时，能根据自己的经验，将这些东西再理论化、抽象化，提升到一个新高度，一起总结出一套适合目前国内IT环境的项目管理理论，不说什么为中国IT产业做贡献的大话，只要能切实解决一些我们一线项目经理的苦恼，让大家少走弯路，已经是我很大的心愿了。
作者：第72条鳗鱼　回复日期：2005-12-25　1:25:20
收藏
作者：CFYKING　回复日期：2005-12-27　23:08:11
我从毕业就开始做一个项目，做到现在…2年了…感觉都快吐血了……需求是必然要改动的……人家是大客户，而我们公司又是小公司，客户对软件也没有具体的要求，只想在使用中发现问题，要求改动；由于需求的不停改动，项目以近做的非常凌乱了；现在开始要求客户签需求分析方案，但人家说了……你做就是了，我现在签，明天就推翻，你做不做？呵呵~！~！真快吐血了……公司不满意……客户又限开发进度慢……哎……真没办法混了……索性决定明年不干了……开发无止境……感觉也没什么前途。永远都没有社会背景，天天对着电脑……呵呵`！~感觉没有希望……生活静的和死水一样……
作者：西蒙泥　回复日期：2005-12-28　13:23:10
楼上的，既然你把帖子发到这里，我就说几句，只是作为参考，我没权对你的事情说是或者否。
我认为你的问题是职业生涯的规划问题，即个人定位问题，你是打算以后做一个项目经理还是技术高手抑或一个领导者，这个问题是大问题，值得你抛下手上所有的事情去认真考虑。首先考虑自己喜欢什么、擅长什么，然后想上天赋予自己的使命是什么，想成为一个什么样的人，等等，想清楚了方向，行动才有指引。
另外，我觉得你碰到的是项目的正常现象，是项目管理没做好的表现。即使你觉得苦，也是一件好事情，人都是在痛苦中成长，而在快乐中提高的几率会小很多。
作者：ydc　回复日期：2005-12-28　13:44:37
to CFYKING，我觉得你所做的不是项目，而是工作，正如你每天要上班一样，所以不要想太多，也不要觉得苦闷，如果实在接受不了，就去找其他机会。外面的世界很宽，只是很多时候我们都不太愿意迈第一步。
作者：可夫　回复日期：2005-12-28　15:09:57
好帖，顶了
作者：wnb　回复日期：2005-12-28　16:44:40
请问楼主，贵公司CMM多少？
替你总结一下，所谓做项目，就是开会，会开的越多，越频繁，参加人员越多，项目越“完美”
作者：CFYKING　回复日期：2005-12-28　17:49:39
首先在此非常感谢 西蒙泥 与 ydc 的留言，分析一下你们的话，很有道理，这是我的真实现状，我也一直在想这些问题……我也明白自己不能一直停留在犹豫状态，这样什么都做不好，也就象ydc说的‘很多时候我们都不太愿意迈第一步’，但又有点患得患失了……呵呵。我目前的思想比较趋向于 ydc 的说法吧。怎么说那……心有点浮躁了。还是非常感谢两位前辈，谢谢。
作者：西蒙泥　回复日期：2005-12-29　08:07:31
作者：wnb　回复日期：2005-12-28　16:44:40
请问楼主，贵公司CMM多少？
替你总结一下，所谓做项目，就是开会，会开的越多，越频繁，参加人员越多，项目越“完美”
CMM是个好东西，可是很多好东西到了我们实际操作中就成了花钱就可以买到的证书，失去了原来的意义......
开会是沟通方式的一种，面对面，比较有效率。但是会太多，也说明有问题，至少他不是项目成功的前提。当然，也许你只是幽默一下，讽刺一些喜欢做秀的人吧。
作者：西蒙泥　回复日期：2006-1-6　12:17:57
新的一年，根据自己的梦想，制定今年的目标，然后根据目标制定详细的计划，具体到通过哪些认证、看完哪些书、参加哪些培训、帮助了多少失学儿童。如果我们总能完成这样的目标，我们离成功就不远了。
作者：xiongl　回复日期：2006-1-11　11:48:43
目标，计划，实施，控制，收尾，呵呵。人生就是一个大项目啊
作者：边城老虎　回复日期：2006-1-17　10:35:35
试一下
作者：边城老虎　回复日期：2006-1-17　10:58:23
浏览了大家的帖子,大多数是做乙方的项目经理,本人一直做的是甲方,所以看法与大家不尽相同,如能对大家有所帮助,本人不胜荣幸。
项目管理涉及到技术、管理、商务三个方面。比如，谈到需求、确认，这是技术问题，谈到任务分派、协调资源，这是管理，谈到签合同及回款，这是商务问题。
项目管理还是一门综合学科，是人的多项能力的综合运用。单纯强调某一方面，最终都会导致失败的结果。
按这个思路写下去，恐怕我要准备出书了，因此，我以下的论述，主要以技术为中心，谈谈自己项目管理的一些思路和做法。
1. 关于项目评估。甲方需求不明确这是中国软件项目存在的最大问题，但也是中国软件行业的基础，中国IT人必须承认这个现状，然后想办法去克服它。个人建议，乙方接项目的时候，要学会辨别这不是个项目，如果条件不具备，强行上马，最终会导致一个失败的结局。通常说来，甲方酝酿一个项目，需要2-3年时间，但通常的做法，甲放在第2个月就开始张罗项目，召集一大堆乙方进行招投标，最终的结果不是不了了之就是项目匆匆上马。我个人的做法是；条件不具备，坚决不投入，领导爱怎么说就怎么说，公司几个IT项目快被我敷衍2年了。
作者：边城老虎　回复日期：2006-1-17　11:26:16
2. 关于项目需求。项目启动后，面临的问题是如何做需求。乙方希望甲方拿出规范、齐全、完整的任务描述、流程说明和表格定义，而甲方希望乙方承担承担咨询顾问的角色，希望借助外力梳理业务，提高管理水平，现实和希望的巨大落差导致了项目需求流于形式。个人建议：①乙方应承担需求引导的责任，比如，组织甲方参观相关的成功项目；在需求调研前开展理念培训，介绍国内先进的经验和做法；安装原型系统，组织甲方业务人员试用。这个阶段不宜太短，个人建议2星期到2个月，虽然看起来是浪费了时间，但经过这一轮磨合，以后的需求进度和质量会有很大提高②乙方的需求调研人员要加强业务学习。在调研过程中用心熟悉业务，从而真实把握甲方的需求。在调研过程中要多与甲方的业务人员交谈，用你的嘴巴描述甲方的业务，并请甲方纠正，目前普遍存在的是收集好资料就走，回到办公室就写需求分析报告；资料收集完后，要组织相关人员规划未来的业务系统，未来的系统需结合甲方的现状， 不宜拔得太高，并多与甲方的业务负责人沟通；需求分析报告完成后，还有一个组织评估的过程，在与公司中高层沟通汇报之前，如果能有一个第三方的相对中立的评估报告，对需求达成共识，会有很大帮助。
我发现乙方存在的普遍问题是：
1. 乙方没有相关行业经验，理解能力差，一个简单的东西，讲三至五次，还是不能理解。
2. 乙方调研人员不愿意理解业务，这种情况一般存在在资深的IT人员身上，他们拿以前的经验来对待现在的项目，在甲方现场转几天，就回去写需求分析报告了，提交的东西简直就是牛头不对马嘴了。
这样做出来的东西，要求甲方不做更改，应该比较困难，进而要求甲方签字和付款，简直比登天还难。
作者：西蒙泥　回复日期：2006-1-17　13:37:19
任何问题，站在不同的角度，看到的问题自然不一样。我这篇文章说的都是站在乙方项目经理的角度看项目中存在的问题和建议的办法。楼上的是做甲方的，观点自然不同。
乙方存在的问题，我自己也清楚，除了楼上说的没有行业经验积累以外，还有产品不稳定、人员流动情况严重等问题，这些都是项目中常见的风险。
现在ERP项目为什么失败率那么高？很多人见仁见智，提出了很多看法，包括我们上面说到的一些，也不乏甲方乙方的相互指责。我认为，最核心的问题没找到，主要矛盾没抓住，以后项目还会继续失败下去。
什么是核心问题呢？我认为，一个企业ERP项目的实施，其实是一个企业内部利益（包括话语权、决策权）重新分配的过程。分配过程中，各种力量相互斗争直到达到一个新的平衡。而乙方往往成了这种斗争的牺牲品。这个观点其实也不是什么新观点，大家去看看哈耶克关于知识经济的论述就会明白。
欢迎大家继续探讨。
作者：非洲小蚂蚁　回复日期：2006-1-17　15:55:35
好多口水话
看起就累
作者：vblearner　回复日期：2006-1-17　19:19:41
to 作者：边城老虎
你说乙方没有相关行业经验，理解能力差。
其实是你们只是理解了表面的东西。而你们其实并没有透彻的了解实质，变化趋势。你们只是从使用的角度去考虑问题，而程序员是从更深的层面去考虑问题的。
作者：西蒙泥　回复日期：2006-1-18　9:16:50
楼上提出了一个很普遍的问题：谁来把控业务的全局和关键细节？即做哪些事情和每件事情做到什么程度。甲方的优势是业务熟悉，但是一般缺乏抽象能力和大局观，一个系统的使用者和建设者往往不是一个层面的；而甲方如果缺乏沟通能力很强的业务顾问去引导、挖掘、归纳、总结、提升乙方的业务需求的话，那么就会出现边城老虎说的情况，这个项目就会走向深渊。
这个业务顾问在哪里呢？
作者：西蒙泥　回复日期：2006-1-18　9:18:37
甲方如果缺乏沟通能力很强的业务顾问去引导、挖掘、归纳、总结、提升乙方的业务需求的话
晕，写错，应该是：
乙方如果缺乏一个沟通能力很强的业务顾问去引导、挖掘、归纳、总结、提升甲方的业务需求的话
作者：雷禅乌鸦　回复日期：2006-1-18　09:51:40
有点好笑,有钱鸟就大,甲方领导叫你干什么你就得干什么,论的到你指手画脚吗?做东西做好的标准是甲方说好,而不是你说的从更高的角度看的好,一句话,说你好,你就好,不好也好
作者：边城老虎　回复日期：2006-1-18　12:41:45
呵呵,扯到甲方乙方及实施顾问的问题了。
甲方经常提过分要求的问题，这是全地球人都知道的事情，这里不需多说，我下面还是围绕技术来项目管理。个人建议，在乙方做过几年的人，可以找机会去甲方干干，同样，甲方如果不怕辛苦，也可以考虑去乙方发展。角色互换后，对项目管理的理解会更加深刻的。
关于软件项目需要实施顾问的问题，已经在国内逐步形成共识，并且有些IT公司也是这么做的，但由于业务顾问急缺，导致项目实施不尽人意，但这也给大家发展提供了一个广阔的空间啊。各位朋友，特别是在甲方工作的朋友，建议充分利用工作的便利，尽可能多接触业务，思考如何利用信息化的手段提高管理水平。几个项目坚持下来，既可以想办法改行干业务，也可以去知名的咨询顾问公司干顾问，前途比写程序好得多。
作者：边城老虎　回复日期：2006-1-18　12:57:59
3. 关于总体设计。需求完成后，接下来就是怎么做的问题。个人建议：在需求文档移交给设计人员之前，组织一次甲方业务人员，乙方调研人员、乙方设计人员参与的讨论会，请乙方的调研人员详细讲解分析报告，设计人员、业务人员进行分析及核实，以克服书面文档不准确，不详实的问题；设计方案出来后，也应该请调研人员、业务人员参与讨论，由设计人员介绍解决方案，以纠正可能造成的偏差。
4. 关于编码和测试。编码主要注意规范、规范，还是规范。一个系统，一般是由几个人共同完成的，没有规范将对程序的质量和后续维护造成极大的困难。我就见到一个资深程序员要花1个上午来熟悉他2个月前写的代码的现象。测试建议增加代码阅读环节，我个人喜欢组织人员阅读乙方提交的代码，程序看过一篇，能发现各种各样的问题，比白盒/黑盒测试方法效率高很多。
作者：lifegame　回复日期：2006-1-18　23:05:42
郁闷。。昨晚写了一个帖子本来想回，结果老是发送不成功，不过现在看来差不多还能接得上话题。。补发一下。。
作者：lifegame　回复日期：2006-1-18　23:08:32
比较赞同 边城老虎 的观点～
可能这里很多人都是做项目管理的背景，当然在管理方面会看得比较重。这让我联想到近几年很流行的一个观点，就是说很多人以为有了管理经验，而且又读了个MBA出来，然后就可以很容易地胜任各种管理岗位了。这在我看来，似乎有点手里拿着锤子就满世界都是钉子的味道。我觉得 边城老虎 遇到的这些问题，除了可以从管理方面入手以外，其次还可以考虑其他的切入点。
首先一个切入点就是沟通。大家不要觉得奇怪，管理的主要工作不就是沟通么？是的，没错。但是当我们站在一个管理者的角度去沟通，和站在一个学习者的角度去沟通，效果是完全不同的。为什么甲方乙方这么多抱怨？乙方抱怨甲方不懂计算机，甲方抱怨乙方不懂需求；乙方担心搅入甲方内部的利益斗争，最后自己被拖死；甲方又担心乙方产品质量不过关，我甚至还见过一些甲方脚踏几只船，或者频频更换乙方，最后丢了夫人又折兵。为什么不能心平气和地坐下来，放下成见，承认困难（尤其是沟通困难），然后选择合理的期望值，用一步一步携手向前呢。
大家会讲这话说起来简单，谁不希望这样，但谁又能真正做到呢？说实在的，现在各种敏捷开发、迭代模型的书籍和资料满天飞，又有多少人真正做到迭代？其实按我自己的经验看来，真正把迭代做起来，哪怕只是做起来一点点，就可以减少项目里面很多风险了。不过软件工程毕竟只是方法论，好的方法论，加上双方放下架子坦诚沟通的态度，我觉得还是比较有信心的。
另外一个切入点是技术。大家可能又会觉得奇怪。很多管理者好像总以为技术无关紧要，因为技术到处都可以买到。也正是这种“无关紧要”的态度，导致买到的技术很快也重新流入了市场，然后又在感慨说现在的年轻人浮躁啊，太功利啊。。甲方看到这样的情况，比如一些主要的开发人员东西没做完就跑路了，当然也会放不下心。
不过我这里讲的技术，主要还是指人，尤其是那些既精通行业又精通软件的人，我们通常称他们为业务专家或者领域架构师，而且这些人通常对管理也会有很好的理解。如果你的项目组有这样的人担任项目经理，那你就比中了彩票还要幸运了。毕竟在大多数公司里，能长年专攻一个行业领域，并且忍受这么慢慢爬升的工资而不跳槽，同时还能自我激励并抓住机会锻炼自己，以至从一个小小程序员最后成长为领域专家的人，实在少之有少。不管现在的软件工程如何完善，如何抨击个人英雄主义，但至少是我所见所闻的范围内，产品质量其实很多时候还是很大程度上取决于项目成员水平的，尤其是项目经理个人的水平。
总结一下，还是一些老话。项目最大成本其实是沟通的成本。另外看看那些做得大活得久的软件公司，没有一个是不重视人才和重视技术积累的。当然这些对中小企业可能还是奢侈品，但一旦他们活下来，那就是厚积勃发的时候了。
作者：lifegame　回复日期：2006-1-18　23:10:20
呵呵，看来我们一些想法还是相似的，你说的业务顾问应该就是我指的业务专家，这样的人真的很可贵，有这样的人项目简直如虎添翼。
作者：黛沫沫　回复日期：2006-1-19　01:38:54
目标，计划，实施，控制，收尾
作者：西蒙泥　回复日期：2006-1-19　10:25:17
这个帖子渐入佳境，高朋满座啊！这正是我开这个帖子的目的。
现在IT项目对项目经理的要求越来越高，表现在：
一、懂业务，能准确理解客户的要求，包括发现客户的潜在需要。业务上不仅要理解客户目前的状态，也要知道那个行业的发展趋势以及这个项目将达到的业务水准。如果不清楚这些，那么就会出现边城老虎说的那种乙方的情况；
二、懂管理，PM（不是PoorMan）要和很多人打交道，经常要在很多人的利益中做平衡，没有良好的管理技能，包括沟通能力，这个PM是很难做的；
三、懂技术，这里的技术不是写程序的本领，而是系统架构能力。当然，你的项目组里有一个资深架构师而且他的沟通能力很强的话，那么我就只有羡慕你的份了，否则，那些技术上的抉择，你想靠谁？
项目经理的工作就是在理想和现实之间取得平衡，如果你连理想和现实的具体情况都不明白的话，凭什么能做好这个工作呢？
作者：西蒙泥　回复日期：2006-1-23　08:33:50
刚看了Edward de Bono的《平行思维》，说的思想就是和我的平衡是一个道理，所以感觉如浴春风。顺便说一句，平行思维的方法论就是著名的“六顶思考帽”。这两本书，作为有志做项目经理的人来说，看了会大有裨益的。其作用可能会超过那本PMBOK2004。
作者：PantherMW　回复日期：2006-1-25　13:56:49
值得学习，留个记号。
作者：西蒙泥　回复日期：2006-1-29　10:25:15
大年初一，给大家拜年！祝大家身体健康、家庭幸福、新年更上一层楼！
作者：sangzhen　回复日期：2006-1-29　23:23:38
乱七八糟
小小一个项目经理，就一地鸡毛
让你做总经理，你还不要上吊自杀啦
让你当微软主席，估计你要自我凌迟了
没办法，水平有限，好好当你的项目经理，别那天有人把你取而代之，你连饭碗都没了
作者：candrew　回复日期：2006-1-30　1:21:28
收藏！
作者：薛定锷的猫　回复日期：2006-1-30　04:00:02
总结有什么不对,sangzhen你也太敏感了.
作者：西蒙泥　回复日期：2006-1-30　09:19:00
sangzhen:
人和人之间虽然智力相差不大，但是经历却相去甚远。看了你的几个帖子，知道你想创业，很佩服你。等你有过那些经历以后，你看问题的态度和方式都会有所变化的，那时候我们再探讨一些问题，你就会有和现在不同的看法。
祝新年快乐！

注意：非注册用户没有发表信息的权利。登陆社区>>注册>>
用户：  口令：
图片链接：HTTP://
    申请博客
. 非注册用户不能发表文章。未注册用户请返回社区首页注册。
. 请确认您发表的言论遵守国家法律法规、本社区规则，并符合本栏目的主旨。
. 作者文责自负，由此产生的一切后果由作者负责，本网站不承担任何责任。
接收邮件地址： 关 闭
_xyz