我，第一次做项目经理，干赔了

我第一次做项目经理，那是十多年前的事情了，当时给国家开发银行做一个财务风险分析的系统，这个项目：

• 金额：200 万
• 周期：起初定的 8 个月做完
• 人员：10 个人左右。除了我之外还有，需求分析师 2 人；测试 1 人；Java 5 人（那时候还没有前后端分离这个词，前后端一起搞）；BI 工程师 1 人。

项目启动之后，我们项目组去国开行驻场，行里给我们腾出来一间办公室，办公室不大，我们十来个人坐进去之后，满满当当的。

我们周围的办公室，也都被其他同行占据了，比如神州数码、用友、中软……本来 IT 行业圈子就不大，这下大家离得就更近了。

离得近了，最方便的就是挖人。A 公司看 B 公司给国开行做了一个系统不错，单子金额也挺可观，A 公司动心了，也想搞一套系统卖给其他银行。从零开始做一套系统，对 A 公司来说难度和成本都不小，现在爽了，有捷径了：B 公司的人就在自己的眼皮底下，时间长了，物色一个合适的人直接挖过来……

有点跑题，继续说我带项目的事。

这是我第一次带项目，第一次做项目经理。以前参加项目，我最多也就是项目的技术负责人，把技术相关的搞定就行了，主要负责搭建环境、数据库表设计、选择技术框架、制定规范、写写代码……

当了项目经理之后，我还是和以前一样，绝大部分时间就是在小屋里和大家一起闷头写代码、开发系统，除了每周和客户开一次例会，基本上对屋子之外的事情不太关心。

几方面原因：

1. 认知不够，我以为把项目按时完成，功能满足需求，让甲方正常验收了，这个项目就算做好了。

2. 我本来就是程序员出身，对技术之外的事情没啥兴趣——这个可能是技术转管理的通病。

3. 国开行里领导太多，随随便便遇到个人就得称呼“张处”、“李处”、“赵局”。我也奇了怪了，总行里的领导这么多吗？本来乙方在甲方面前地位就有的低，再让我巴结这些个处长们……程序员的清高让我干不出来这个。

就这样，我们在小屋里“闭门造车”了三四个月，项目时间差不多过了一半，我要把开发的系统给国开行甲方爸爸演示汇报一次。

在演示之前，我们自我感觉一切良好，进展顺利，按我们的估计，至少可以提前一个月交付项目。

结果，汇报的时候翻车了，甲方爸爸一顿啪啪打脸：

• 系统界面和交互设计，和银行里主流系统的风格不一致；

• 账号和权限体系不能单独存在，要用银行里已有的一套方案；

• 部分功能过于繁琐，使用门槛高；

• 甲方对部分开源技术的稳定性存在怀疑；

总之，这些问题意味着：我们之前做的大部分工作，需要改动甚至推翻重来，整个项目的前景蒙上了一层阴影。

这次暴露出来的问题，我肯定要承担主要责任。就在我被打击的迷茫和萎靡的时候，我的领导，公司的技术总监也知道了这件事，叫我回公司一趟。

回去之前，我做好了最坏的打算：被批评一顿、被撸了项目经理。

幸运的是，最坏的事情没有发生，领导找我长谈了一番，时间久远，谈话内容已经记不清了，大概内容就是理解我第一次从技术转管理会犯错，教了我一些带项目的方法，相信我接下来能把项目做完……

不过，谈话中领导的一句话，我到现在还记得清清楚楚：

项目成功的定义是什么？一个成功的项目，就是让项目的所有涉众都满意。

意思就是，成功的项目，是让项目中参与的各方人员都感到满意。

这句话彻底颠覆我的认知！我之前单纯的认为把项目按时做完上线，客户验收付了款，项目就算成功了。

“让项目的所有涉众都满意”，那么我们项目的涉众都有谁？他们满意的标准是什么？

我回到项目组之后苦思了好几天，同时找银行客户、同事交流，后来基本想明白了：

甲方爸爸：毫无疑问，这是最重要的一个涉众。对甲方项目负责人来说，他们最关注的是这个项目能按时上线，而且能解决业务痛点；同时在项目过程中他们要能完全掌控项目进度。这个项目延期或者没做好，他们也不好交代。

系统的用户：对用户来说，就是要让他们用着满意，符合他们之前的工作习惯。

公司老板：对老板来说，他没有指望这个项目能挣多少钱，他的主要诉求有两个：1、通过这个项目让国开行认可我们公司，争取以后拿到更多项目；2、把这个项目沉淀成标准化的产品，将来卖给其他银行。

团队同事：首先，同事们不喜欢长期驻场做项目，毕竟不是自己的地盘，最理想的是有一个标准化产品（和老板的目标一样），以后再有项目，把产品给客户短期实施就能搞定。另外，团队里大部分都是程序员，他们也需要技术提高、个人成长。

公司销售：销售和老板的想法大概差不多，只不过更看重国开行眼前这个客户，希望项目一期做完至少能先签下来项目二期。所以他希望我跟他一起，多和客户吃吃饭、喝喝酒，拉近一下关系。

想明白这些之后，后面就该我做出改变了。

比如，为了给银行科技处的处长汇报工作，我和销售一起在处长办公室门口站着等，经常一站就是两、三个小时。和销售一起陪银行领导吃饭聊天，给领导们解决电脑上的各种幺蛾子问题……这些更是家常便饭。

这些我曾经抵触的、不屑于干的事情干多了之后，甲方对我们的脸色明显变好了。

再比如，为了让甲方掌控项目进度，我们一两周就迭代一个版本，主动去找甲方沟通确认。

另外，我发现有些事情是有关联的。我在甲方这边花的精力多了之后，在技术方面花的精力自然就少了。这就倒逼着我要把一些技术工作交给同事。随着我责任和权力的下放，对团队里优秀同事来说，他们的技术话语权变大了，空间变大了，对他们来说也是个成长的机会。

其他的不细说了，最终这个项目的结果并不是特别圆满，有好有坏。

坏的是，由于之前挖坑太深，项目最终还是延期了，8 个月的项目干了 10 个月，项目小亏，大家的奖金也受损失。

好的是，项目上线之后用户使用反馈比较正面，甲方项目负责人也比较满意，项目结束后，顺利拿到了二期的单子。

还有一个好事，项目结束后没多久，我们项目组原班人马真的搞出来一个产品，这个产品为以后项目实施帮了大忙。

我第一次做项目经理的经历基本就讲完了，最后再次把这句话送给各位：

一个成功的项目，就是让项目的所有涉众都满意。

真的，这句话可以说是那次项目中，我收获最大的一句话。一直到现在，不管是做项目、产品，还是做其他事情，我时不时的就会想想这句话。

希望这句话也能帮到你们。

我承认，很多时候让所有涉众都满意，是很难的。朝着这个目标努力，最终达到“让大部分涉众基本满意”，也算不错了。就像考试一样，不期望你能考满分，但是你要去奔着考满分去复习准备。

---

你好，我是四猿外。

一家上市公司的技术总监，管理的技术团队一百余人。

我从一名非计算机专业的毕业生，转行到程序员，一路打拼，一路成长。

我会通过公众号，
把自己的成长故事写成文章，
把枯燥的技术文章写成故事。

我建了一个读者交流群，里面大部分是程序员，一起聊技术、工作、八卦。欢迎加我微信，拉你入群