如何提升产品团队整体PRD的输出质量？

吴天 2023-07-23 02:06:55

还是在做互助的时候，团队里有个小姑娘，虎头虎脑，很有冲劲。因为工作的原因，许久没有联系以前的小伙伴了。前一阵子，突然接到她的电话，很是开心。

当然她找我也不仅仅是叙旧，更多的是关于团队管理的一些探讨。我觉得有些内容还是挺有意思的，也就试着写一写。

一、望闻问切

搞清楚问题，是解决问题的第一步。

根据她的描述，大致是说研发团队吐槽产品这边整体输出的PRD质量比较低，需要反复沟通，影响整体的工程开发效率。

所以她的问题，一言以蔽之：如何提升产品团队整体PRD的输出质量。

我们试着拆解一下这个问题:

首先是”整体”，代表着团队目前人员能力参差不齐，有高手也有菜鸟。一般来说，主要是菜鸟拉低了团队的整体水平，其应为重点关注对象。

其次是”质量”，代表着受众(工程团队)对目前的质量不是很满意。一般来说，RD所说的PRD质量主要是指两点:

由团队水平最高的PM(可能是PMleader/也可能是组内的产品专家)制订一份模板1.0，并在团队内部讨论确认试用。

使用同一模板的好处有两点:

没错，又是模板。

即使是组内专家写的模板，也不一定就会让团队买账。

无论是对于产品团队还是工程团队，管理者都要引导大家科学的思考问题。

明确方向正确性的同时，要承认任何经验性的东西都会有个本地化的过程(否则就是经验主义，生搬硬套)，需要在各个流程中不断的复盘修正，这需要大家的支持。

产品团队leader善于引导团队成员积极捕捉异常(内部评审/工程评审中那些不同的声音)，推进模板的定期讨论升级迭代。

进一步激发研发团队反馈的积极性与理解(能做到这点，即使你现在做的不是很好，产研的沟通成本也会降低很多，因为工程团队也会在这个阶段帮你消化一些隐形的工作量，例如减少不必要的争吵)。

在大多数产品经理的认知里，工程评审就是告诉研发”我需要你做什么”，这没错但不严谨。主观上的忽视了PRD中的存在的技术盲区(个人认为术业有专攻，这个盲区是一定存在的，是不是大小的问题)，可能是经验不足，也可能是自负或是自欺。

组织工程评审会的时候，PM最好要强调一下评审的意义:目前的方案虽然经过PM内部评审了，但是还是会有些工程盲区无法完全覆盖，需要研发各位老板帮忙指出来(谦逊的暗示对方应承担的义务)，避免给后续工程开发带来不必要的沟通成本，提升工程压力(暗示对方不履行义务的代价)。

如下为管理者可能会遇到的一些挑战:

这种情况下，产品leader要主动引导业务方认识到事物本质: 你要的是交付周期(提出需求到上线)更快，不是决策周期更快。

过程对业务方没有意义，结果才是最重要的。

这种质疑很有价值，可以考虑孵化一个敏捷模板，类似于绿色通道一下，快速孵化业务需求。

这个在实操过程中确实有些小技巧，例如。

如果Pmleader对1v1中的需求很有把握(一般是些小需求，非敏感类，该leader为此方面的专家或者团队规模比较小)，可以直接批准进入工程评审，没必要在占用其他产品的时间，组织产品内部评审了。
1v1结束后，作为PMleader一定要相关的PM把会议中的TODO(修改点)和自己过一遍，确保没有遗漏，避免后续的反复沟通与确认。
人的精力毕竟有限，如果你管理的团队比较大，一定要领用好导师这个资源，来分担你方案把关的工作。

互联网就是最好的老师，团队的高手也可以扩展理解为互联网。

一般来讲，是如下的工作没有做好，才会发生这种问题:

没有及时反馈工程评审中TODO的结论，又在开发过程中反复沟通浪费了很多时间，研发承担了很多不必要的工程压力;(这种情况，没什么说的，一次是经验不足，两次就是态度问题了，管理者要及时介入提醒或警告相关的PM。)
每次工程评审被指出来的问题总是相同的，RD的意见并没有被实质性的尊重。(这种情况，应该是管理者的责任，不是在机制建立之初没有针对产品团队做适当的引导和启发，就是在机制执行过程中有些放水，自己都不去提炼一些问题孵化，其他同学自然就不会认真对待。)