项目协作很重要

从业以来，大部分项目都是从头就参与的，印象中有三个案例是半路接手的，前一任的项目经理都是开发人员出身，有一个项目竟然没有项目经理。虽然三个项目具体情况不同，但是总结起来都是要关注内外部的协同。如今分享出来，我想也许可以给做乙方或者外包行业的项目经理，尤其是技术转管理的项目经理一些提示。

第一个项目是2012年12月从前一个项目收尾后接手的，我的领导交代的背景是项目已经做完了，做了培训就可以收尾了。第二天带我到客户现场，介绍完我，从客户提了一个关于我们产品的问题开始就把主场转手给我了，硬着头皮接手了这个项目。

从这天开始我就跟客户及我们自己的团队在一个会议室开始集中办公，第一天我就发现客户方的一位项目成员跟我们的项目经理（实际是开发负责人）之间竟然是处于一个不断提需求——开发的状态。这位客户每天叫我们开发负责人的名字不少于20次，每次叫他不是提新的需求，就是说系统有bug。而他们之间的所有需求、bug都是口口相传，没有任何记录。

我只好把我们开发负责人叫出来单独沟通，先跟他确认目前项目的阶段，聊了半天才知道现在和客户双方都认为是进入UAT（用户接受测试）的阶段了，但是没有举行任何里程碑式的活动来明确这件事。然后我去找了客户的项目经理，客户方项目经理很儒雅，委婉的表达了我们的同事态度很好、很勤奋也很配合，但是从项目组自己测试的情况来看，心里没底不敢给最终用户推广，希望我们赶紧拿出个方案来看怎么把项目推进下去。

看来情况已经很严重了，回来立刻召集项目组所有成员开会，把我们当前的项目进展情况进行汇总，确定了几个方向：1.本次项目总共涉及五大模块，其中3个模块项目组都是很有信心的，我们立刻准备UAT测试的组织；2.剩余两个模块立刻整理现有问题清单，排优先级快速攻克；3.UAT之后就要进行生产环境安装了，汇总生产环境需要提前准备的硬件、网络等需求，提交客户先行准备。收集完这些信息，并拿出具体的工作计划后，我邀请客户方项目经理并项目组全体成员召开了一次项目例会，把后续的工作安排讲完后，重新澄清了项目章程，恢复项目例会、所有的需求、bug的解决全部要在项目组的需求清单、bug清单中管理，开发人员只从清单中拿任务，不接受口头任务安排。

从这时开始，我负责联合客户进行UAT相关的组织工作、生产环境的准备工作，我们的开发同事负责按照需求/bug清单对剩余两个模块的具体开发和赶工，项目在半年后顺利上线，客户还跟我们持续合作进行了二期、三期的项目建设。

第二个项目是2016年2月接手，我们的开发团队有20多人，因为是外包团队，公司竟然没有设置项目经理岗位，我接手时也是我刚入职这家外包公司。

到现场工作后，发现项目组的情况是这样的：开发团队20多人每天工作到半夜，已经持续两三个月。客户方项目经理说你们这样不行，天天加班，项目还没啥进展。客户方产品经理说这么简单的需求你们怎么就几个月还搞不定。业务部门（需求方）说啥时候可以让我操作系统。项目组的几位开发组长说，我们出差来接项目已经三个月了，啥时候能回去；一帮开发人员都是培训班刚出来的，我们都快累死了；需求天天变，都不知道他们要啥。

因为我也是第一次做java开发的项目，所以开始进入项目学习。当我终于搞清楚我们在做啥的时候，先把已经做了的工作画了一个流程图，然后去找客户方产品经理。产品经理直接蒙圈了，谁让你们搞得这么复杂的。但是事已至此，能做的已经做了，再改回去业务部门不会同意，只能继续往下走。但是我们有了一个规则：业务部门不能直接给开发人员提需求，所有需求先提给我，我报给产品经理确认后才可以纳入开发。

第二个事情是从我接手开始，每周开始给客户方项目经理写周报，汇报我们项目组的工作进展、风险和困难。客户方项目经理由此给我颁发了一个月度最佳新人奖，我其实感觉受之有愧，只是做了应做之事。每周的周报汇报上去后，我和客户方的项目经理开始沟通遇到的问题和需要他们帮助协调的事项，以便推进项目运作难点。

第三个事情是重新画项目组的组织架构，确定组长和组员的工作职责、培训规则。几位组长还是很有经验，需求有序之后，他们的工作也开始有规律，我们开始尝试用敏捷的开发实践来建立团队。很快又从团队里涌现出来一些优秀的同事。

这几件事情理顺之后就开始进入正常的项目交付过程了，我们也在三个月之后顺利结束出差，开始在公司的办公点进行远程交付。我犹记得当年我作为项目经理代表在年终总结会上介绍我们的团队时，标题是：做有思想的合作伙伴。

第三个项目是2020年10月的事情了，我入职了新的公司，接手了一个从未做过的数据库迁移的工作，虽然团队内部要做的事情基本已经成型，但是只是可行性论证通过，没有达到可以批量处理的程度。前一任项目经理也是技术出身，他思路清晰、认真负责，项目相对还是比较顺利的。但因为个人发展的原因，以及项目实在压力太大，提出了离职，公司招聘我入职接受他的工作。

我接手之后发现我们内部虽然做的热火朝天，但是在客户方没什么声音，跟客户之间的沟通基本没有。一旦出现问题，几个团队之间就开始互相甩锅，我们经常需要花很多力气证明锅不是我们的。这让我对这个大团队感到很是迷惑。

接手项目后，因为内部事务比较清晰，我的重点工作就是和客户方的沟通。经过一段时间的学习，搞清楚我们整个大团队由四个专业团队、100多个应用团队组成，这四个专业团队分别属于三个不同的供应商，大家之间的关系既有合作又有竞争，非常微妙。

从我接手之后，在所有的沟通场合，开始刻意以团队所负责的功能称呼每个团队，而不按照之前大家的习惯叫各自团队所属供应商的名字，希望能够弱化大家在平时沟通中的敌对状态，增强合作意识。

然后开始画我们的工作流程图，以及我们和其他团队之间的依赖关系，请客户方的PMO协助打通这些关节。客户方的信息化管理非常强，我刚开了个头，他们立刻铺开让四个大团队强输出工作协作流程，通过几次会议把大家需要写作的点整理成一个完整的大流程，都按照流程办事。

第三步借助客户现有的管理系统来管理我们的需求、各应用团队提出的需求、问题等。客户PMO也快速出台了管理办法，把我们的流程快速落地。

这样经过一年的不断优化，我们的团队效率终于能够迎接批量化的迁移工作了。

从这三个项目来看，我们的开发团队负责人在开发工作上很靠谱、很到位，但是对项目的组织、计划的编排、内外部的协同流程不够重视，有点沉浸在自己的世界闭门造车的感觉。当然这也是有些技术转管理岗位同事的通病，在自己擅长的领域陷得太深，反而顾不上更需要关注的重点了。但是作为一个项目的负责人，最终是要给甲方、项目干系人负责的，所以项目整个过程中内外部的协作很重要，要保证自己在正确的路上行进，且能够主动和相关的干系人沟通推进协作事项。