与在行上一个网友的沟通（一）

       一个网友针对我“在行”上的话题“如何打造零Bugs产品，如何提高产品质量”约了电话沟通。他给我留言说“我是一家初创企业的IT研发负责人，在研发团队管理、研发流程建议方面有些问题向您请教，谢谢！”收到他的电话约聊后，我又进一步了解到他目前的情况，他自己是以产品为主（对技术有一些了解），现在负责带整个研发团队，包括产品，开发和测试。现在主要遇到这几个问题。

*总您好，我现在负责一个10人的研发团队，面临的问题主要有：

1. 研发流程的规范性 - 项目时间紧，流程无法严格执行？

2. 绩效管理 - 不知道如何对不同岗位进行有效的绩效管理？

3. 晋升通道设计 - 如何设计不同岗位的晋升通道？

      我告诉他，这三个问题范围都很大，一次简单的电话沟通可能无法全部解决。所以建议他排个优先级，先解决当前他最关心的问题。最后沟通下来，他目前当务之急就是“研发流程的规范性 - 项目时间紧，流程无法严格执行？造成产品质量不高，研发团队很累”针对这个问题，我们进行了电话交流，在沟通的过程中，我逐步了解到，现在公司研发人员每个人都是身兼数职，既要承担公司产品新版本迭代，还要同时支持项目的交付以及临时的POC任务，每个人都是多线程工作。特别是项目交付和临时POC支持，节奏很乱，没有计划性。都是销售临时打电话说，后天或下周有个POC，需要研发支持，临时做几个页面或简单实现某个功能。有时项目经理也会突然打电话来说，客户之前提的需求又变了，要临时改需求或者加新需求。整个研发团队被压的喘不过气来，每天都是疲于奔命应付各种突发事件。造成交付的产品质量不高，现场暴露出很多bugs客户不满意，经常被项目经理和销售投诉。另外，研发内部管理也有点乱，没有一套规范的研发流程。

      这其实个非常普遍的问题，特别是在很多创业型小公司都遇到过。人员少，项目紧，任务重。研发计划经常被随意打断，研发人员经常被临时调用。项目需求不清楚 ，产品测试不完整，最终造成恶性循环，“产品质量不达标，现场客户不满意，研发团队不开心”。针对这种情况，我给了两点建议。

第一、对外严格控制临时任务和需求变更。

      我也作过开发，对于开发人员，最怕的就是需求不确定，临时改需求。软件产品质量最大敌人就是“需求不清，随意变更”。古语有云：“一鼓作气，再而衰，三而竭”。对于研发人员，一气呵成的代码质量最高，中途修改则容易出Bugs，反复修改质量则无法保证。他也同意我的观点。也想这样做，但现实情况是“臣妾做不到啊！”。他说：“有时销售和售前为了拿单子做项目，经常临时提需求，他也明白，这样对研发团队压力非常大，但同时站在公司整体角度考虑，为了公司的生存和发展又需要这些项目，老板也会给他压力，所以他也是两头为难！”我完全理解他的处境和难处。因为我也有过类似的经历。做为团队的管理者，我对自己的一个定位就是团队的“保护者”，我有责任保护好团队的“利益”，这里面的利益除了经济利益外，还有其他方面的，比如让团队在一个合理的计划和稳定的节奏下工作。

       所以我的当时的应对方案是，首先和我的领导（公司二把手、技术合伙人）沟通，把我的想法告诉他。销售POC配合和项目经理的要求，我们研发团队会全力支持。同时，为了提高大家的工作效率，希望销售和项目经理能提前与研发团队沟通，尽量避免随意的临时改计划，提需求。因为这样不只是为研发团队考虑，而是从公司整体角度出发，避免出现恶性循环，如果销售和项目经理经常提临时需求，研发团队只能匆忙应对，势必会影响产品质量和交付时间，从而对POC的结果产生不好的影响，造成项目机会减少，回款不及时，最终大家都不满意。所以希望大家能相互配合，销售和项目经理做好工作计划，有事提前沟通，研发团队提高效率，全力配合，让大家都开心！这应该是大家想要的结果。在得到领导的支持后，我又找到销售和项目负责人进行私下沟通。他们提出一些建议后，大家达成初步一致的意见，最后由技术合伙人出面把研发，销售，项目等部门负责人招集起来开会，确认具体执行办法后，开始试运行。经过一段时间的运行，大家反馈都比较不错，销售和项目部门与研发团队互相配合，从而形成良性循环。

第二、对内加强需求管理，对每个需求都要先了解清楚然后再实现

      作为开发人员，大家都可能存在一定的“通病”，就是拿到需求后，就急于动手，直接撸代码。我的建议是“磨刀不误砍柴工”，在做之前一定要把需求细节整理好。越清楚、越细致越好！道理也很简单，避免开发到一半或在测试的时候，才发现需求描述不清楚或理解有偏差，然后再重新确认，不停的修改和变更。另外，对于不清楚的细节和一些隐藏的问题，开始的时候不了解清楚，不表示这个问题不存在，它只会在未来的某个时间点“暴雷”，那么我们当然希望是越早发现问题越好，而不是等到测试阶段甚至上线部后被用户踩暴这个“地雷”。所以，需求的理解和细节确认是很重要的。真正的编码其实反而很“简单”。这些理念需要他给团队进行灌输和建立。同时，我把目前我们团队中的研发流程和制度给他做了分享。

       关于他提到的绩效管理和晋升通道设计，后面也简单介绍了一些我的实际工作经验。让他自己结合公司的实际情况进行完善和执行。

       他对这次约谈还算比较满意，也给我的“在行”服务给予了自己的评价：*总在研发流程建立、绩效管理通道设计等方面给了我很切实可行的建议，并且特别指出作为管理者应该是团队的保护伞，团队的改变要先从我开始。*总提到的“开发人员是产品质量的第一责任人”我也很认同。和*总的首先沟通很愉快，收获满满，感谢*总！