研发效能需求管理之互联网大厂

lsekfe

需求来源
　　我们在公司做内部支撑平台的产品，一开始一穷二白啥都没有，所以主要需求有：
　　1）产品规划
　　2）系统缺陷
　　3）用户反馈
　　来到公司我们做的第一件事情，就是摸排公司在研发效能这个方向上的水位，公司都有哪些活动，哪些流程，有哪些工具，每个工具都在哪些部门的谁手里，工具的使用程度如何，大家都有哪些诉求等等。经过和相关小伙伴聊了N遍之后，我们定下了主要方向和相关的时间节点。所以大部分需求都是产品规划中的需求。另外一种是系统缺陷，这部分改动大的就放到产品需求里，小的直接修复，主要考虑工作量大小和优先级。用户反馈的需求，这部分要仔细判断。大量用户反馈的共性需求，可以考虑；但是对于很多专家型的小伙伴提出的诉求，评估时一定要慎重。尤其是产品前期，要把精力绝对地放到基本诉求，核心功能上。而不是很多「高级」「酷炫」「最好有」的需求。用户的痛点很多，要投入到真正的痛点上，做那些「立刻马上必须有的」需求。当然研发小伙伴也会发现一些技术方面的需求，我们也会视轻重缓急排期修复。
　　需求优先级
　　我个人觉得作为业务负责人和产品经理，对这些需求优先级都会有自己的判断的。这也体现出了业务负责人和产品经理的领域知识、业务素养。我们团队都是领域专家，也就是对研发效能领域有很深的认识，对需求高优与否有判断能力，基本上不会受嗓门高低影响。
　　需求文档质量
　　我们团队很小，一开始只有5个人（1前端，2后端，1设计师，1产品）。
　　很惭愧，一开始我们的需求都是没有文档的。最开始我们的很多想法都直接落到 confluence wiki 上，那里有我们最初的一些思考。比如现在公司整体情况如何，各个方面的成熟度如何，我们从哪里入手，做什么，预期什么时候完成。这些都是写到了 confluence wiki 上，当然也不是所有都写上去了。因为咸鱼(二伟哥)那个时候就坐到我对面，有事情张嘴就说，有问题拉到白板旁就画。我们做第一个产品的时候，需求还是写到 confluence wiki上，然后在 Team 上创建一个任务，把 confluence wiki链接贴上去（那个需求的模板还是从 confluence 上搜来的，形式不重要，内容是关键）。如果遇到中间有变更的，我们团队就坐到一起讨论，讨论完毕后把结论直接写到任务下面，这事就这么定了，决策链路短且高效。
　　团队内中间讨论的一些产物基本都在白板上，那个时候就是讨论完了，手机拍个照片发到群里。重要的贴到 confluence 上，也就这种程度了。团队小，这种程度也就够了。
　　后来团队大了，需求文档质量要求也高了，后来的需求都转到了在线文档上。在线文档比wiki 太好用了，尤其是可以对每一行进行评注讨论，在线协作，方便省心。
　　当然我们也从其它团队那里听到了一些不太好的案例。一句话的需求和回字有四种写法是需求的两个极端，两种做法都不好，这里涉及一个度的问题。只要团队里的所有人的目标是做成产品，向着同一个方向努力，做成一件事，那么我认为大方向就是可以接受的。
　　总结一下，在团队小的时候，在产品啥都没有的时候，把握好大的方向，只要「整个团队」都了解需求没有歧义，只要产品进度不受大的影响，我可以接受文档质量不高的情况。小步快跑么，如果跑不起来那就放弃一些目前不重要的。
　　需求评审
　　一开始我们的需求评审可以说是随时评审，也就是没有正式评审。前后端和产品都坐到一个地方工作，有问题随时沟通，几乎没有因为需求评审造成了延期交付、功能不符等。
　　后来团队大了，正式的需求评审也就有了。我们团队那个时候是每周二四评审。其实我认为这种评审节奏是不好的。我比较认可当时「 Team团队」的做法，每天下午2点到3点是预留需求评审时间，有需求就评审，没有就过。
　　需求验收
　　对于中小规模（3PD）的需求，其实不用经过业务负责人和产品经理验收，完全可以直接上线，直接线上预发环境验收。因为功能简单、明确，前期都经过了几轮评审，测试用例也评审过了，设计稿也通过了，要上线的功能基本不会出现问题。对于中大型需求（5PD～）功能上线前，我们有两轮产品验证，第一轮是在测试环境验收，第二轮是线上预发环境的需求验收。
　　测试环境的需求验收，主要为了避免重大需求的实现和最初的功能不符、不满足要求、重大bug等问题。
　　需求上线
　　预发环境是线上环境稳定性的重要保障，是把问题不带给用户的最后一道保障。建议各个团队都要建设好自己的预发环境。对于上线时机，我觉得产品研发的前期，只要有信心可以随时上线。尽早地把需求放到线上让用户感知到产品改进，也可以让用户对产品慢慢地建立起信心。
　　虽说是可以随时上线，我也是建议要有产品或者QA验证的环节。千万不要边改边上，而是改过之后需要有人在单独的环境中验证没有问题再上线。在线上直接改，这么业余的骚操作咱们就不提了，我觉得很大一部分公司还是可以避免的。千万别在线上调试，真担心变成面多了加水，水多了加面。
　　上线失败怎么办？立刻回滚。回滚到上一个版本后再去追因。
　　总结
　　软件开发活动是生产活动的一种，也是平均智商比较高的一类生产活动。说一千道一万，每个小伙伴的自驱是最关键的。如果大家的心往一处想劲往一处使，遇到问题，有人能主动站出来，而不是放任问题恶化、发生，很多问题都不会出现。每个小伙伴都是团队中不能缺少的一个伙伴，要把做产品做需求当成自己的事来做，那么很多问题都不是问题。很多人提到流程建设，其实我个人觉得流程只是保证大家整体处在一个能接受的水平，如果想突破有更高的产出，人的主观能动性才是最关键的。流程都是不完美的，不能一出了事情就怪流程，最后流程成了背锅侠。我期望能有高效务实流程规范下，有更多主观能动性的体现。控制团队规模，提高专业度，优化组织架构是提高团队战斗力的三个方法，但这又是另外一个话题了。