上一篇 找到能做好研发效能的人 ，我介绍了如何找到研发效能的领域专家，这一篇我来分享一下之前在带团队做产品的时候一些需求管理的经验，尤其是做研发效能平台涉及到的一些情况。后面还会陆续更新，敬请期待。
本篇主要分成「需求来源」「需求优先级」「需求文档质量」「需求评审」「需求验收」和「需求上线」六部分。
需求来源
我们在公司做内部支撑平台的产品，一开始一穷二白啥都没有，所以主要需求有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验证的环节。千万不要边改边上，而是改过之后需要有人在单独的环境中验证没有问题再上线。在线上直接改，这么业余的骚操作咱们就不提了，我觉得很大一部分公司还是可以避免的。千万别在线上调试，真担心变成面多了加水，水多了加面。
上线失败怎么办？立刻回滚。回滚到上一个版本后再去追因。
总结
软件开发活动是生产活动的一种，也是平均智商比较高的一类生产活动。说一千道一万，每个小伙伴的自驱力是最关键的。如果大家的心往一处想劲往一处使，遇到问题，有人能主动站出来，而不是放任问题恶化、发生，很多问题都不会出现。每个小伙伴都是团队中不能缺少的一个伙伴，要把做产品做需求当成自己的事来做，那么很多问题都不是问题。很多人提到流程建设，其实我个人觉得流程只是保证大家整体处在一个能接受的水平，如果想突破有更高的产出，人的主观能动性才是最关键的。流程都是不完美的，不能一出了事情就怪流程，最后流程成了背锅侠。我期望能有高效务实流程规范下，有更多主观能动性的体现。控制团队规模，提高专业度，优化组织架构是提高团队战斗力的三个方法，但这又是另外一个话题了。
这里面的一部分做法来自大叔也是前同事 @甄诚 的指点，也有部分是我从「Team团队」的日常管理中学来，从@罗振兴 身上也学到了很多，也有很多是耳濡目染从老板的身上悟来的，三人行必有我师，从我们的团队学到了很多。欢迎加我进入我们这个圈子 :-)
网友评论