还是在做互助的时候,团队里有个小姑娘,虎头虎脑,很有冲劲.因为工作的原因,许久没有联系以前的小伙伴了. 前一阵子,突然接到她的电话,很是开心.
当然她找我也不仅仅是叙旧,更多的是关于团队管理的一些探讨. 我觉得有些内容还是挺有意思的,也就试着写一写.
一、望闻问切
根据她的描述,大致是说研发团队吐槽产品这边整体输出的PRD质量比较低,需要反复沟通,影响整体的工程开发效率.
所以她的问题,一言以蔽之:如何提升产品团队整体PRD的输出质量.
我们试着拆解一下这个问题:
首先是"整体",代表着团队目前人员能力参差不齐,有高手也有菜鸟.一般来说,主要是菜鸟拉低了团队的整体水平,其应为重点关注对象.
其次是"质量",代表着受众(工程团队)对目前的质量不是很满意.一般来说,RD所说的PRD质量主要是指两点:
可读性差: 表述方式没有逻辑,关键信息要找很久,找到了还要读几篇才能理解的意思,或者还是无法理解需要和产品再次沟通确认.
内容不详细: 开发中需要的物料(文案/图片/逻辑)不全,需要提示PM补充.
二、对症下药
由团队水平最高的PM(可能是PMleader/也可能是组内的产品专家)制订一份模板1.0,并在团队内部讨论确认试用.
使用同一模板的好处有两点:
PM不用担心自己考虑的不周全,因为模板是团队最高水平的人出的,基本上该考虑的点都会以模块的形式体现.完成每个模块的填写,及时把该考虑的事情都考虑了.
提升PM撰写PRD效率,类似于研发的开发框架.支持产品集中精力在每一个具体模块填写上.
2.2 建立品控机制
PM输出PRD (基于模板)
PMleader评审: 把握方向/业务流程/核心逻辑
PMteam评审: UE/文案/逻辑
工程评审: 引导研发积极反馈PRD工程盲区
PM输出工程版PRD (前提: 已针对流程中暴露的问题,完成修改或解释)
2.3 升级模板
没错,又是模板.
即使是组内专家写的模板,也不一定就会让团队买账.
无论是对于产品团队还是工程团队,管理者都要引导大家科学的思考问题.
明确方向正确性的同时,要承认任何经验性的东西都会有个本地化的过程(否则就是经验主义,生搬硬套),需要在各个流程中不断的复盘修正,这需要大家的支持.
产品团队leader善于引导团队成员积极捕捉异常(内部评审/工程评审中那些不同的声音),推进模板的定期讨论升级迭代.
进一步激发研发团队反馈的积极性与理解(能做到这点,即使你现在做的不是很好,产研的沟通成本也会降低很多,因为工程团队也会在这个阶段帮你消化一些隐形的工作量,例如减少不必要的争吵).
2.4 重新认识工程评审
在大多数产品经理的认知里,工程评审就是告诉研发"我需要你做什么",这没错但不严谨.主观上的忽视了PRD中的存在的技术盲区(个人认为术业有专攻,这个盲区是一定存在的,是不是大小的问题),可能是经验不足,也可能是自负或是自欺.
组织工程评审会的时候,PM最好要强调一下评审的意义:目前的方案虽然经过PM内部评审了,但是还是会有些工程盲区无法完全覆盖,需要研发各位老板帮忙指出来(谦逊的暗示对方应承担的义务),避免给后续工程开发带来不必要的沟通成本,提升工程压力(暗示对方不履行义务的代价).
三、缓解副作用
3.1 新流程执行后,业务投诉产品决策流程过长,响应效率不如以前了
这种情况下,产品leader要主动引导业务方认识到事物本质: 你要的是交付周期(提出需求到上线)更快,不是决策周期更快.
修改前: 没有品控机制,产品决策周期短,PRD质量低,产研沟通成本高,最终交付周期长
修改后: 由品控机制,产品决策周期长,PRD质量高,产研沟通成本低,最终交付周期短
过程对业务方没有意义,结果才是最重要的.
3.2 一些小需求的处理,使用模板是不是太形式主义了.
这种质疑很有价值,可以考虑孵化一个敏捷模板,类似于绿色通道一下,快速孵化业务需求.
3.3 PMLeader 即要1v1的评审还要参加团队评审,会不会很浪费时间
这个在实操过程中确实有些小技巧,例如.
如果Pmleader对1v1中的需求很有把握(一般是些小需求,非敏感类,该leader为此方面的专家或者团队规模比较小),可以直接批准进入工程评审,没必要在占用其他产品的时间,组织产品内部评审了.
1v1结束后,作为PMleader一定要相关的PM把会议中的TODO(修改点)和自己过一遍,确保没有遗漏,避免后续的反复沟通与确认.
人的精力毕竟有限,如果你管理的团队比较大,一定要领用好导师这个资源,来分担你方案把关的工作.
3.4 团队水平差不多,没有高手
互联网就是最好的老师,团队的高手也可以扩展理解为互联网.
3.5 工程评审的时候研发还是不配合
一般来讲,是如下的工作没有做好,才会发生这种问题:
没有及时反馈工程评审中TODO的结论,又在开发过程中反复沟通浪费了很多时间,研发承担了很多不必要的工程压力;(这种情况,没什么说的,一次是经验不足,两次就是态度问题了,管理者要及时介入提醒或警告相关的PM.)
每次工程评审被指出来的问题总是相同的,RD的意见并没有被实质性的尊重.(这种情况,应该是管理者的责任,不是在机制建立之初没有针对产品团队做适当的引导和启发,就是在机制执行过程中有些放水,自己都不去提炼一些问题孵化,其他同学自然就不会认真对待.)
四、医者仁心
如下是我总结的一些常规解决问题的思路,仅供参考:
搞清楚问题 : 不要扩散,一下子想很多问题. 还是要聚焦,一个问题一个问题的去解决;
梳理好现状 :不要着急出方案,搞清楚现有流程,理解清楚问题的诱因.要相信充分的信息收集,是理性决策的基础.
规划好流程 : 打样,逻辑上不通的,执行就别想有效果.
推进好迭代 : 不仅要自己明白,还要引导团队明白.目标是清晰的,道路是曲折的.
升华好意识 : 不同的业务需要不同特质的人员,这点需要在实践中不断总结,不断强调.团队管理包含物理和精神两个层面,两者缺一不可.
好了,就写这些吧,希望对一些产品leader有一些启发吧~
题图来自unsplash, 基于CC0协议。
>>更多吴天原创文章，请关注微信公众号「竹林杂记」（ID：pmwutian）查阅！