好久没来了，最近这几天项目比较忙，回家只剩学英语那么一点点时间了，所以一直都没写，今儿继续我们的项目管理细节。

      第二期谈的是如何与业务方打交道，那我们今天继续往后说，把业务方的工作做完后，下面就该是研发团队的沟通工作了，在第二期的结尾我说过，研发团队是最好打交道的团队，他们就好比机器人，只要输入指令，就可以执行动作。那么一个PM唯一要做的就是输入正确的“指令”。

      什么是正确的“指令”，我们在谈这个名词前，有做过研发leader的童鞋可以回忆一下，项目初期你们都在做些什么？是排期，还是评估可行性，还是需求理解？我觉得你说的都对，工作上都是做这些，但为什么要做这些呢？那些告诉我为了项目顺利完成的都是Bullshit。如果搞不清你为什么要做这些，那你可以考虑去做一名架构师了。我来告诉你是什么？答案是：规避风险。什么风险，排期是为了进度风险、可行性分析是完成风险、成本预估是成本风险，我们要做的就是让这些风险远离我们，并给出一个自认为合理的方案。别理解错了，规避风险可不是逃避责任，逃避责任是指是你的错，你缺不承认；规避风险就是把责任划分清晰，什么样的后果我才会承担责任。

       那么说回PM与研发团队沟通的主干，PM要清楚，跟研发团队沟通只需要同研发团队一起划出风险范围，并双方达成共识。这就是正确的指令。就这么简单吗？其实不然，如何同研发团队一起划出风险呢？那么我们来看看研发团队都关心什么。

       1、可行性——是否可以实现、是否会冒风险、会不会为了实现你的需求而使代码“扭曲”。

       2、系统风险——你的系统并发量多大、是否采用新技术、对新技术是否有掌控力、会不会涉及到被黑客攻击。

       3、排期——时间是否够用、是否要连续加班、业务方会不会需求不断改。

       4、干系人分析——PM是否给力、是否涉及外部系统、涉及到多少外部系统、有没有涉及难合作的部门、冒烟测试需要多少部门配合。

       5、成本——有没有奖金、加班费、项目成功会不会给予表彰或奖励。

以上，是我大概总结的一些研发团队常碰到的问题，这些问题都需要你与他们一起来指定，那如果现实中碰到了这样的问题，我建议一下大家如何来解决：

       1、可行性差、业务方又强硬

            解决方案：作为PM，你不能让研发团队冒这个风险，他们也不可能束手就擒。所以，你要先降级方案，跟研发团队研究一套可实现的，再与业务方商量，能否先上线这版可实现的，随后研发团队会在进行过程中对新技术进行研究，很有可能中途会实现你的要求，如果不能的话，我们可以以二期的方式，找其他技术更好的研发团队做，而现在研发资源不够了，如果着急上线功能的话，只能由这个团队来担任。

       2、要求采用新技术、却没有掌控力

            解决方案：直接暴露出风险，如果公司不能支援这块技术的话，项目很可能会失败，相信哪个业务方都会退而求其次的。如果业务方是在强硬，好办，写一封“责任认定书”，如果出现问题，研发团队会积极配合，但不承担任何责任。

       3、排期紧，要求上线时间不合理

            解决方案：第一种可以要求组建敏捷团队进行开发，如果没有条件的话，第二种方式，切功能上线，把主要功能先上线，后续的功能给业务方承诺，会陆续完成。但在与业务方沟通的时候，切记不能“太实在”，要以为业务方担心的程度，“如果您执意要求全功能上线的话，我会让研发团队全力加班加点，但不仅不一定能完成，还会使系统的稳定性会下降很大。”

       4、涉及到外部系统过多，责任分不清

            解决方案：这是大家往常中最常碰到的吧，为了研发团队之间能相互分清责任，甚至能把一个项目拖入失败的深渊，这种事情屡见不鲜，如何避免。这里需要PM主动站出来承担责任了，减少这种扯皮事件，对于扯皮严重的，要敢于拍板并承担全部责任。这样研发团队才能安心给你干活。

       5、成本超支了

            解决方案：成本的问题各个公司都不一样，我这里主要讲在乎成本的公司。研发团队开发时间超了怎么办，找业务方去沟通，多要几个需求，这样在最后结算的时候，把这些需求加进去，就可以抵消一部分赤字了。这要看与业务方的关系够不够好，也是我第二期说的，一定要先搞定业务方。

总结：今儿就说这么多了，以前是公司项目管理部的负责人，这方面见识的还是不少的。其实要写的话，这块多少都能写，这也只是冰山一角。欢迎大家咨询我这些问题，我也挺喜欢跟大家讨论这个问题的。