pain_happy
2004-08-16 10:12
我部门于2月前打下外地一软件实施项目的单，随后即派项目经理和技术经理前往启动项目。

客户方看过我们项目经理的简历后并不愿与其合作，让其来承担该项目的实施，因为其虽工作多年但是没有做过与该项目有关的实施，对该项目所需的业务知识也并不具备，但是老板硬派该项目经理前来，针对客户的强硬反对，老板前后派出了几位部门重量级人物来协助项目经理最初的工作，几经谈判，客户终于同意了该项目经理的位置。与此同时项目也在进行。

由于该项目要求5个月实施完毕，而部门以往的该类项目的实施时间最少为8个月，所以该项目的时间是很紧迫，对方肯付出的费用也恰恰是5个月实施完部门方能赚钱。

在项目启动之后，pm开始调动人员，并做项目的筹建工作，但是非常遗憾的是该pm总是有些底气不足，和客户说话总是低头哈腰的；该项目任命的技术经理是为中专学历有着多年开发经验的技术型拼命三郎！该技术经理没有参加过大的项目实施，只是参加了规模比较小的项目实施，针对本次规模并不算大但是却参考我部门以往大规模项目的技术和业务要点来做的项目部分业务也不是很清楚。

pm很多地方都是听这位技术经理的经验，自己拿主意的时候并不是很多，为了控制项目成本，把大家的生活费用降至最低（就是请假一天也会把该员工一天的餐费13元扣除）……

在项目开始的需求阶段，pm定的计划为一个月，但由于pm的不作为（在任何需求会议上该pm从来不发表意见，即使客户方提出不合理的需求，我方小组长提出合理的解释不能做，他也不表态，以至客户认为我方员工在推卸工作，和我方小组长有不愉快的争执），该客户领导层当着我们所有项目成员的面交代他们的需求人员：要广开思路，多多参考同行业的做法，多多提需求；发出“只要能想到了，技术就能实现”的谈需求原则……

由于客户以往没有做过系统，没有项目实施经验，再加上需求谈的及其广泛(某种程度上说还包括一些异想天开的想法)，需求谈的比较辛苦，各组小组长力争本项目的需求范围，但是由于pm的不表态，该客户想公司投诉说pm管不住自己的员工和项目需求中的其他问题，于是老板赶来协调项目，并开会对我们说：错误的也要执行，避免客户误解我们的不团结……

原计划一个月的需求在这种情况下谈了1.5个月，于是原计划两周的设计时间变为了一周，各组小组长按时间要求写出了概要设计和详细设计，于是一周后我们进入编码阶段，此时需求还在审核阶段。在我们编码的第二天客户方总体负责项目的头出现了，（该头被我们的头称为比较强势的人，做过卖方和买方，对这种合同双方的情况和心态都比较了解），客户的这位头提出了一周做出概设和详设的质疑，并查看了我们的详细设计报告和我们做为模板
项目的设计报告，发现差别不大，只是若干无痛无痒的修改，于是和我们做出了争执，认为这是在增强项目日后返工的风险……

为此我们的头又再次来到项目中与其协调，最终的结果是我们推翻了pm的项目计划，进行详细设计的返工。pm给出了我们详细设计的模板，其实那模板和我们项目最终的操作手册几乎一样，只是多了处理流程,

pain_happy
2004-08-16 10:23 对于该设计模板我们技术人员大都持反对态度，认为这样一个模板其实并不是设计模板，以这个模板写出的文档是针对客户的而不是针对技术人员的，但是pm还是坚持了这个模板的使用，我们于上周结束了详细设计，今天没有
分配任务，但是应该是编码了，我们很多人也开始编码……

对于这个项目的实施，很多人都报了失败的念头

lfkcn
2004-08-17 08:45 我看包括你们的PM和老板都不够强势。
另外有一点疑问，客户怎么那么关心你们的设计模板？而且作为外地软件实施的项目，你们的编码工作是不是太多了一些，而且把大批开发人员拉到现场，是不是浪费了？

pain_happy
2004-08-17 14:50 客户要求每个阶段都要提交规范的文档，客户希望在实施这个项目的同时我们能提供好的项目管理。

我们的人员几乎都是拉到现场实施的，人员成本的确很大，所以pm才拼命地从小节上控制成本。

pain_happy
2004-08-17 15:25 客户要求每个阶段都要提交规范的文档，客户希望在实施这个项目的同时我们能提供好的项目管理。

我们的人员几乎都是拉到现场实施的，人员成本的确很大，所以pm才拼命地从小节上控制成本。

lfkcn
2004-08-17 17:57 还是把需求确定下来然后安排开发人员在自己公司开发比较好，现场实施不要安排太多人，这不利于控制成本，也不利于现场实施，容易造成混乱的局面。
另外，客户要求提交规范的文档，这没有错，但是用不着他来关心你们自己技术人员使用的模板，这是两回事。

迷惘夜车
2004-08-17 18:25 这个项目不一定会失败,但是很可能会是一个烂尾工程,合同款怎么付清楚不?

这个PM也确实够失败的,部分项目组成员已经如此悲观了.

我看这个项目也难以验收。

pb123
2004-08-18 08:57 你的想法PM是否知道，是否充分沟通过？PM是否有其他的原因？
沟通不能解决所有的问题，但是不沟通肯定出大问题。
老板让他做PM总是有一些道理的！
和老板，和PM对事不对人的谈一谈，否则这个项目。。。

gonglunjun
2004-08-18 11:08 和我一个朋友参加的项目如出一辙，只是客户的强势头快完工的时间才提出异议，最后是搞一个够呛。

迷惘夜车
2004-08-18 14:12 我感觉你们公司的内部沟通太少了，项目小组现在像一盘散沙。

客户强势只是一种表面形势，事实上，客户方一样有一份自己的项目进度表，不能按计划完成该项目会对客户方造成一定的损失，同样需要有人来承担责任。把这层厉害关系理清楚了，把握好一个度与客户方项目负责人沟通交流，双方多多协调配合，这个项目还是有希望顺利完成的。

既然你公司已经中标，应该把握住项目管理的主动权，要求客户多多配合而不是支配项目进展，一味的迁就和退让一定会坏事的，还是一句话，内部和外部都多多沟通吧。时间还来得及！

pain_happy
2004-08-18 16:55 我们现在的局面是有些混乱，不过大家还都是做事的人，项目组中也没有刺头，按客户要求已做完详细设计了，我们自发地进入编码了，之间我们项目组一直没有开过会，对于我们各小组在需求、设计及现在编码的情况，pm一直也没有开过会，技术经理也只是从他项目安排上给我们分配活。

pm平时只和技术经理沟通，很少和其他员工沟通；有些老员工不满意pm的计划和做法，直接说出来时pm也并不表态，只是在打哈哈，

客户希望我们能给他们带来好的项目管理，同时也希望这个项目成功，所以对项目的要求比较苛刻，处处怕风险，处处严标准，而我们pm所提供的又不能满足客户的要求，就我个人而言，我觉得我们pm没有了解到客户的心里
和心态，也没有掌握客户头的性格，只是埋头按时间干活.

迷惘夜车
2004-08-19 09:44 中国的很多项目管理都不是非常规范的,很多项目经理的实际管理只停留在理论上,对于实际项目该如何理论结合实际还缺少足够的经验,重视技术多过重视管理,甚至有的PM亲自带队进行技术攻关,而忽略了管理的重要性。

管理结果的好坏，直接表现在PM的沟通层次上，对于上级的沟通，主要以汇报的形势开展即可，适当的利用上级充分的调动相关资源有利于促进项目提高完成质量；对于客户的沟通，主要体现在对客户需求及心理的理解和与客户关系的把握，客户关系协调好了，项目压力就会减轻许多，项目验收（这是每个项目必须经过的一道坎）也方便通过；与项目实施人员的沟通才是推进项目实施的关键所在，项目实施人员能不能正确理解PM的意图，进度安排
是否合理，相关人员能否按时按质量完成任务，这才是项目成败的决定因素。

客户要求高怕风险这是每个项目都存在的共同情况，几乎每个客户的项目负责人都希望能够更多更详细的了解到项目进展情况，他们比公司高层更关心这个项目的成败，这就要求PM与他保持很好的沟通，一方面通报项目进展状
况，另一方面要求他提供尽可能多的配合。

一味的埋头苦干，最后连苦劳可能都没有。

pain_happy做为这个项目小组的实施人员，有责任向PM提出所担心的问题和已经发现的问题，以便项目小组及时的召开项目小组会议，讨论和纠正项目实施过程中出现的各种问题。不要担心他会恼你，你是站在这个项目的立场上说话，站在公司的立场上说话，同样也是在帮助他，把你想说的话说了出来，你会轻松很多的，上吧，哥们！

goldeagle
2004-08-19 14:26 happy，你也开始学我啊？等我晚上有时间，回一下你这个帖子。

pain_happy
2004-08-19 17:40 迷惘夜车：我试着找个机会和pm谈谈我对项目的看法和感受吧！希望我所做的判断比较客观吧。不过pm总是和技术经理在一起长谈，也不知道谈什么呢？

现在大家自发地编码，但是工作中要发现了很多问题，包括尚未明确的需求和其他事情，pm还是没有召开内部会议，不知道他在忙什么。（不过前两天他病的上不了班，大家都说他是积劳成疾 ：（）

pain_happy
2004-08-19 17:45 goldeagle：

^_^，很高兴你回贴呢！平时在qq上逮不着你，偶尔碰见，你也是忙的没有说话的空，所以偶就来这里请高手们赐教了。

goldeagle
2004-08-20 13:53 首先第一个感觉就是：你们的PM绝对的不合格。
PM在与客户沟通的时候，
最重要的工作就是需要清晰需求的界限。
第二个重要的工作就是给自己留下与客户讨价还价的余地。
第三个重要的工作就是要客户明白你们这个团队究竟是做什么的。

如果这三点做不到，压根不用谈什么项目管理的内容了，这个项目失败几乎是必然的。当然，这个失败也许可以依靠国内客户的“愚昧”来争取一些机会，但是总体来说，绝对不是一个成功的项目了。

对多数项目来说，PM是成败的关键，技术反而是次要的。因为技术问题永远都是相对容易界定范围的，风险相对容易控制。遗憾的是，你们这个项目没有在其他方面获得什么突破。

pain_happy
2004-08-23 09:09 迷惘夜车：

再你提出和PM谈的下午，我们有个同事向技术经理提出了我们在编码时候的问题：有些需求还不明确，编码任务比较重，一个月完不成编码（pm规定一个月完成编码），项目计划不明确等等。

但是我们的技术经理却很轻松和自信地告诉他我们的计划做的很好（也就是最初项目启动时候做的计划），一个月内能够完成编码。
我们很久已经没有开过例会或者项目会议了，也不知道我们的技术经理如何把握了我们编码的动态……

还有我们一旦象我们的pm提出计划的不合理性，pm就比较生气，认为时间这样紧迫（客户要求），我们还这样找借口……

pain_happy
2004-08-23 09:22 goldeagle：
我们的pm的确那三点都没有做到，需求阶段的不表态、不明朗的确给我们后来的设计和编码带来了很大的问题，一个月内实现编码是众人都认为不大可能的事情，但是对于计划的强迫实施，我们都抱着什么时间出什么活的想法
。

由于在外地项目实施的过程中，pm太计较我们消费的细节，（比如我们个人掌握的伙食费是：一天13元，公司规定我们外出实施项目每45天可探亲一次，天数不超过3天，pm就连我们实施人员回去探亲的13元也扣除了
，哪怕只探亲一天），等等一些在其他项目组根本没有出现的生活细节问题，都在我们这个项目组出现了，导致大家心都郁闷，觉得pm该抓的不抓，总是在一些并不碍原则的事情上扣大家的费用，从心里上都不愿意拼命干……

另：我们公司的我们部门本来就处于动态的局面，很多员工都抱着另找工作的心态，只是尚未合适的，所以还留在项目组继续干活，部门现在的流动性比较大，这个项目的利润并不高，打单时候的价格也偏低，大家也都明白这是
个没有利润、奖金的项,……，

总之，种种的一些事情纠集在一起，大家的心本来就有些散，pm的一些做法我个人认为是在加速我们部门的瓦解!

pain_happy
2004-08-23 09:31 在我们自发进入编码的一周在后，我们pm发出了编码期间的进度模板，让我们自己根据模板制定出编码计划，计划必须在规定日期之前完成，由于我们已经开始编码，很多项目人员根据以往的项目经验基本上都做了自己的计划
，所以再一周之后再发进度模板，大家觉得模板跟不上进度，现在在去做另按一个模板罗列编码内容并做计划比较浪费时间，也算是引起了比较大的波动吧……

pain_happy
2004-08-23 09:35 我个人觉得我们这个项目目前最大的风险是人员风险，虽然我们的实施人员都有着多年的项目开发经验，高手也汇集不少，但是由于部门本身的动荡，加上对这个项目实施的不满，以及对pm胜任的不满，人心已经很散了，再加
上我们技术经理在工作上的严要求（很多要求如果计划的好，其实不用向他安排的那样辛苦），人心就更散了。

都说项目是以人为本，我觉得我们这个项目恰恰丢掉的就是这个……

迷惘夜车
2004-08-23 10:35 pain_happy：就你所说的这些情况，这个PM确实是舍本逐末了，在我认为，控制成本的最有效的方法是充分调动各种资源和调动起项目小组人员的积极性，尽量缩短项目开发和实施时间，比计划提前一天完成项目也
许比一个月所节省下来的费用开支都可能要多。
我以前做项目经理的时候，经常为项目小组的成员承担部分开支，虽然只是一些小恩小惠，虽然自己会吃点小亏，但是项目完成质量高，所失跟所得很难去比较的。
照这样下去，这个项目迟早会是个烂尾工程。
你自己觉得自己尽力了就安心好了，这个项目的成败主要责任还是在于PM的水平。我也觉得你们的PM太自负了。
对于中国人的儒家思想传统来说，怀柔政策远比大棒政策奏效。

pain_happy
2004-08-25 15:43 现在进入编码的第二周了，涉及到很多业务细节，因此也发现了一些在需求阶段并未细化的业务，因此一些需求细节需再次考虑，很是麻烦！

lindawei31
2004-09-01 17:32 做项目最重要的需求。做项目不比做产品。应该多和客户交流。可能你们PM有点什么。需求一定要掐死了。不然，软件在10个月也完成不了。

迷惘夜车
2004-09-02 09:12 需求、工期、资源、质量四个要素本来就是环环相扣的，某个要素的不确定性必然会影响到其他要素的预定目标。
这个项目也未必会失败，项目最终还是要上马，最后的结果是双方妥协的结果，不过对以后的项目管理是个很好的经验教训。

pain_happy
2004-09-06 15:48 由于前面需求阶段和设计的拖延，我们编码时间规定为一个月内编完，现在也就是只有一周的时间了，大家一致认为时间不够，但是pm已经发送了下周开始进入测试阶段的测试计划。由于从我发贴到现在一直未开过任何有关项
目的会议，我们中有人提出异议，pm都认为是个人的缘故，现在我们均采用先完成主流，测试阶段在逐步完成程序控制。

多少有些担心测试阶段会爆发出之前工作的漏洞。对于此，大家也都是在一天做一天的事，个别一些老员工也逐步地退出项目组，也就是说测试阶段将会留下一些小兵在，不知道测试阶段情况如何。

pain_happy
2004-09-11 09:35 下周一就要进入测试阶段了，我们的系统也已导入测试环境了，但是我们还是在进行编码，很多都来不及自测了，只是编完程序后编译通过就可以了，真是很担心下周一开始的测试。

上周末部门派了技术总监过来。技术总监过来之后将我们开发人员根据业务编排成两个大组，并指定了两个项目经验比较丰富的人员做组长，有这两位组长把握项目进度，汇总各组情况后向项目经理汇报工作进度。

我感觉这样把我们技术人员和pm、技术经理连成一个整体了，不象以前明显的两个层：pm不询问我们的进展，直接埋头做他的成本预算和进度安排；技术经理努力搞定自己所负责的平台及技术部分。

但是马上就进入测试期了，我们的编码不能结束，只能提交所有程序，边测边编了。

另：我们的系统上线时间又提前2周了，不知道真的能否如期上线。

小李飞刀14
2004-09-13 10:32 一个合格的项目经理的一个重要基本素质就是“沟通”，没有这个能力其它的优势都无从发挥，或者说不能全部发挥。

小李飞刀14
2004-09-13 10:34 不过你们那个项目经理肯定也是很为难的，第一次作这种实施项目，又不知道该怎么做，我能够理解他的心情。每个人都有第一次，我觉得现在你们公司一定要赶紧给他派一个强有力的助手来，否则……

One Aim,One God,One Life. || 最爱:偶家阳阳 || 博客:愚人camer || MSN:camellxr@hotmail.com