IT项目管理实践经验分享

hitbird

支持了.随时关注中....

snow-flower

太强了

pwwing

往死里顶!!拼命学习!

pudong315

文章写得很实际，学习了，期待继续。。。。。。

lsgo007

追随
学习

ccjjgg79310

B）同级、下级、供应商
   a  在达不到要求时，引导member继续前进
对于同级、下级、供应商他们都是你的Team Member，不要关键时候不要搬出权利来吓唬他们了。

他们需要被夸奖。听说教育小孩的经典之一是“好孩子是夸出来”，你的member是一样的，好member是被夸出来的。只是他们不像小孩子那样可以说谎的夸，你需要认真的动脑筋想怎么夸才不会显得言不由衷。夸他们除了真的做得好之外，就是你需要他们做得更好的时候了。做得更好其实并不表示他们现在做得很好，恰恰相反，可能他们做得非常糟糕，根本达不到你的要求。

但是发火是于事无补的，甚至可能激起team member的反感，都这么大人了，谁都有个面子问题的，所以我们只是要达到目标，发火不过是手段，不到必要的时候不需要发火，一来让自己心情不好，二来偶尔发火才是杀手锏，发火多了就不值钱了，你已经没有太多可让人畏惧的东西了。

夸他们是要有技巧的，你可以说：做得好啊，我们已经实现了什么什么（他的确有做的东西）——现在该我们考虑下一步的时候了，下一步我觉得还需要做什么什么——这些由你来做？因为前面做得不错。

看上去我们在夸他们，实际上，我们在给他们下套，套住他们，让他们高高兴兴的去实现我们的目的。你不需要说太多的“但是”，这会让你听上去有点虚伪，但是你可以把你的目的拆成两个来说，他实现了第一步，那么第二步不是就该接着做了吗？


   b  翻译能力
PM是什么呢？好的翻译官。客户说的都是他们的业务语言，供应商有的时候说的是技术的语言，PM是什么？多语言外交官。PM有责任将不同团队之间的语言翻译成大家都能正确理解、没有歧义的语言。

只有语言统一了，大家才有交流的基础，否则是鸡同鸭讲，彼此谁也不知道对方说什么。

还是COPY之前已经用到的例子，丰田开发凌志的案例：

日本鬼子做凌志的时候，目标就是改变大家对丰田中档车的观念，要做一款高档车，他做的需求调研就是为客户为什么觉得奔驰、宝马高档，得到的答案就是
（1） 身份地位与尊容的形象
（2）高品质
（3）转售的价值
（4）性能（例如，操控、乘坐、马力）
（5）安全性
最后他根据客户这些感性的词语，翻译出了凌志的目标
（1）最高时速：250 km/h（比奔驰多28，比宝马多30）
（2）耗油量：每加仑行驶23.5英里以上（比奔驰多 4.5，比宝马多4.7）
（3）噪音情形：100km/h 时速为58分贝，200km/h为78分贝（奔驰为 61/76,宝马为63/78）
（4）空气动力……
（5）汽车重量……

项目经理就有必要将交流的内容明确化、易于沟通，常用的就是量化和名词解释，重点说名词解释。要进入一个行业就要先了解这个行业的术语。所以供应商、客户之间说不清楚多半都是名词不了解，举个例子，我们说备份好像很easy，觉得根本没有可解释的地方，可是客户根本听都没有听过。

我们首先要察觉困惑的情绪，当一个人脸上呈现出茫然的时候，我们就可以问了？有什么不明白的么？通常他们都可以清楚的说出没听懂的地方。可以看看当中有没有专有名词，有的话，就解释一下，什么意思，最好打个比方（尤其是要客户明白IT名词的时候）——作用是什么——它的变化带来的影响是什么——我们现在讨论它是为什么——你觉得呢？

举个例子备份，备份就是把每天的数据做一个COPY保存在另外的地方，好比你把重要文件COPY在U盘上，万一你硬盘坏了，可以从U盘上COPY回来，保证文件没有丢——就是保证万一服务器坏了，我们做的历史记录都在——备份保存的时间决定你可以恢复到什么时候的数据，比如，我每天备份，备份都保留15天，如果现在是2月16日，我可以恢复到2月1日、2月2日……2月15日，任何一天的状态，但是想恢复到1月30日就不行。所以备份保存的时间就是可以被追溯的时间。——我们现在就是在讨论这个系统的数据备份应该保留多长时间——你觉得你们希望可以被追溯多少时间前的数据状态？

tititea

LZ贡献好大，谢谢了

tony_sy

顶！
我是做乙方的，我们有很多共同点啊。
收藏了。

^_^。

tony_sy

最初由 ccjjgg79310 发布
[B]看样子说得太详细了，决定说简单点。喜欢知道细节的，想知道为什么当时会那样决定的可以再详细讨论。

直接说结果吧，当初因为 C 部门的人和我都喜欢 供应商b，所以 W 顺从了我们的意愿。选了b，但是不幸，在 是否提前进场这个问题上，W 又和 b 干上了（其实甲方和乙方的利益点是不同的，在这种问题上几乎是一定会出问题）。之后W和b 公司的高层吵了一架，大家彻底崩了。我们再度建议改为供应商 a ，但是因为许多的原因， C 部门的人选择了 供应商 b。
之后项目出了很多问题，从源头上讲，选择错了供应商是最根本的原因。我把W选择供应商的几条标准和原因告诉大家，给甲方和乙方的人一点参考。

1、高层关系良好。这是为了实现W的第一目标，供应商可控。不要觉得奇怪，我的几个老板都是这条原则优先的。W常用的几个方法，比如，供应商实施顾问在我们一开始这里不听话的时候，他会当着实施顾问的面打电话给 供应商的高层，把实施顾问臭骂一顿，声色俱厉，如果这个时候供应商的高层马上道歉，并且接着声色俱厉的把手下骂一顿，那么这个供应商基本还是可控的；反之，这个供应商非常危险。当然还会有要求提前进场一类的事情发生，W 就是要突破供应商的底线，但是前面说了，W绝对遵守承诺。

2、项目资源明确并优良。因为供应商不管多大，里面的人一定是良莠不齐的，再好的公司也有不好的实施顾问，但是公司的管理不一定跟得上，常常是项目delay了，客户忍无可忍了才被发现。业界超牛的公司做砸项目的比比皆是，而成败，常常是系于做项目的这几个人身上的，其中最重要的当然是项目经理。

3、重视案例。方法论每个公司都有，见多了绝对没啥新鲜的，方法论是必须落地的，所以案例就是方法论啊、公司的资历啊一大堆的落地表现，所以我们常常花更多的时间去了解供应商的案例情况。

4、公司成长性和稳定性。这是两个有点矛盾的要素，成长性当然是为了能跟上我们公司的发展，但是又要稳定的成长。风险投资的企业常常的问题就是发展神速，管理跟不上，我们的项目就是吃了这个亏，没人管了。所以一年规模就翻个翻的企业，其实值得甲方好好考虑。当然如果甲方足够的大，大到什么公司都不敢轻视你也不会有这个问题，但常常就是甲方只是一般的大而已，己方在发展过程中，对新员工的培训等等根本不足，大项目多，人手不足，于是一个新手就成了你的项目经理，后患无穷。 [/B]

看来你们公司是属于强势的甲方。

tony_sy

最初由 ccjjgg79310 发布
[B]其实项目前期的需求分析，就是招标之前写初步需求也是一个非常重要的环节，只是这个项目失败是因为供应商选择的问题，所以先写那个了，这里补上 需求调研 环节。

做项目的需求分析，就叫RFP吧，免得和后面的供应商的需求搞混了，在企业做项目，一定要知道自己的Stake Holder（利益干系人）是谁，尤其是部门长级别的Stake Holder，一方面要知道他对这个项目的定位，也就是范围、深度，另一方面要知道他们的兴趣点是什么。现在没人会指着你做个系统就所有事情OK了，只要你解决了他头疼的2-3个问题，他就会开心了，IT部门的绩效就出现了。

不是说不关心下面人想什么，而是说要优先关心那2成的东西。事实上我的感觉是比如做10个模块，就2个是部门长感兴趣的，也是让他决定要不要说你项目有用、做得好的2个决定性的模块，或者2成的功能是他感兴趣的，项目实施过程中客户提出来的问题8成都是些不好用之类的小问题，真的有问题的就2成，看起来2/8原则基本上是处处成立的。

如果大老板们和下面的人提出的东西彼此之间可以有一定的独立性的话，建议把项目分成几个阶段（RFP里面就要告诉供应商要分阶段），不是传统说法上那种，需求-实施-测试……这种阶段，也不是一期二期那种，就是一个合同之内，一个项目之内的事情分成几个阶段。比如，打算做8个模块，就先做大老板关心的1-2个模块+报表模块，其他的再慢慢做。建议周期在3个月以上的项目都可以考虑一下分阶段。这个当然不是每个项目都成立的，有的时候很不幸几个模块彼此关联性非常大，必须一起做，这就没辙了。

分阶段实施的时候，可以第一阶段需求完成了，供应商开发的时候，就开始做第二阶段的需求，一来时间可以向前挪动一些，二来，用户和咨询顾问不会出现在开发阶段无所事事的空当期，三来，用户使用模块的周期比较长，有更多的机会在前期就暴露出开发中的问题。

下面是以前写的分阶段和不分阶段的比较（当初还写了个文档，哈哈，现在就把比较这段摘出来了，想问更多的再联系），不一定有道理，大家随意反驳
一、分阶段实施
1、项目时间：在供应商人力资源的充足的情况下，可以缩短项目周期
2、客户buy-in：因在短周期内可以出现可使用的成果，客户保持对项目的持续关注和忠诚
3、供应商的buy-in ：因在短周期内可以出现可使用的成果，供应商获得价值被认可的成就感，能保持对项目的忠诚度
4、项目新增需求：在分阶段的过程中，用户通过持续对产品的使用，存在提出更多需求的风险；但同时，这仅是把新增需求的风险放在了项目前面一些的阶段暴露
5、项目质量：因客户可以迭代使用软件产品，软件的二次开发也存在一个迭代的循环，所以这样开发出的产品更符合客户的需求；运行上经过了更长的时间，也更加稳定可靠
6、适用情况 ：实施周期长于一个月，需求不够清晰
二、不分阶段实施
1、项目时间：存在因客户长期处于松弛期，失去对需求的认可，提出“这不是我想要的东西”而导致需求一再变动、项目周期变长的风险
2、客户buy-in：因中间松弛期过长，客户对项目的关注度和忠诚度都较低，极端时，可能会出现“这是信息部的项目，不是我的项目”的想法
3、供应商的buy-in ：因中间松弛期过程，客户与供应商的交流不够充分，供应商逐步遗忘最初调研的需求，做出来的产品存在不够符合客户需求的风险；同时，因为过长的没有出成果的工作期，存在士气低下的风险
4、项目新增需求：因在实施的后期才进行客户测试，客户需求变动的风险较大，这会导致整个项目周期变长
5、项目质量：在实施阶段的剩下1/3部分开始的用户测试导致缺乏一个迭代的过程，软件质量验证、客户需求稳定的周期都不够长，存在较大的质量隐患。
6、适用情况 ：实施周期短，需求清晰

当初还做了个示意图，可惜不知道怎么贴图，就给个文字描述算了。 [/B]

个人谈几点：
强势的甲方对自己的需求一定要清楚。因为你们老总当着实施顾问的面向乙方的面向他的顶头上司发火。
我了解大部分的甲方是对高层发火，但从不对底层发火。
原因是由于你们表现得比较强，顾问主动性还是会受很大的影响。很多事情就看你们自己作主了。

此外，关于项目干系人方面，有几点建议：
1、项目的发起人是项目非常重要的干系人，他的需求是非常重要的。
2、如果项目发起人是老总，就可以扯虎皮做大旗了，把各部门的头都圈进项目组，一旦他们进了项目组，需求就是他负责了，管理人员嘛，具体工作可以由底下人做，但必须他来拍板。

3、对于企业IT 部门，业务需求是业务部门提出的，一定要把握住自己所处的位置，IT部门很大程度上相当于内部的IT 监理。当然，如果需要对业务进行了解，是另外一方面的情况了。

个人建议，供讨论。