【原创干货】作为一名PM，如何提升产品交付质量？

题图 by Sticker Mule on Unsplash

 

​近期工作经常面临交付质量的问题，聊聊自己的想法。

对于产品交付来讲，传统流程涉及的利益相关人主要有：需求来源人（如客户、老板，下文简称客户）、产品经理、设计师、研发、测试、运维。

对于交付质量的定义，我认为是客户主观感受的交付质量。背后的思考是对客户价值的高质量交付才是一个产品的立命之本。也是商业的本质，客户在为产品给自己创造的价值买单。

下面就从产品的研发周期来剖析，作为一名PM，如何提升产品的交付质量？

 

需求搜集

这个阶段最重要的就是“定义问题”，这个是在新手产品经理中最常被忽略的问题。

产品设计过程的第一步就是定义问题，客户表达的问题未必是真实的问题，通过经验的积累，透过层层迷雾找到真正的问题并定义出来，就是一个成功的开始。

如果问题上来就定义偏了，那么后续的步骤做的再好，也只是事倍功半而已。关于这部分，二爷在《需求背后的需求》中曾经进行过介绍，以为然。其中提出的“5问法”也是非常实用的方法。有兴趣，可以下载极客时间，订阅二爷的专栏，文章的质量很高。

这里再分享一个来自《设计方法与策略》中的定义问题的方法。为了定义一个问题，可以试着问以下的6个问题：

• 主要问题是什么？

• 谁遇到了这个问题？

• 与当前环境相关的因素有哪些？

• 问题遭遇者的主要目标是什么？

• 需要避免当前情境下的哪些负面因素？

• 当前情境中哪些行为是值得采纳的？

当然，这只是一些通用方法论。到实际场景中，还是要灵活应变。多多的发挥你的沟通能力，想象力和同理心吧。

 

需求排期

交付质量的核心要素中时间是一个硬指标，排期对于按时交付是起着绝对作用的。虽然交付了，延期了2个月，客户已经扭头投向竞品了。

还有另一点，就是对于研发现状的了解。张三刚做完A客户的需求，对于A的场景理解的很好，那么A客户的新需求交给张三，交付质量就可能会高。李四从业5年，对于异构系统对接具有丰富的经验，那么当一个新的异构系统对接需求要做时，李四就是你的不二之选。

当然，占尽天时、地利、人和是不现实的。在可腾挪的限度内，尽可能好的排兵布阵可以让你赢在起跑线上。

 

产品设计

设计过程第一个是产品经理的左右互搏，从发散到收敛到再发散再收敛，不停的用之前定义的问题，用户的场景，用户的视角去检查自己的设计。恨不得自己钻到客户的脑袋里面，去检查自己方案是否能够解决客户的问题，满足客户的预期。

这部分对于产品工作来讲是人格分裂的，因为设计产品不光要从客户的角度考虑，还要从系统的角度考虑如何满足。这时，“一秒变成小白用户”就成为了一种核心能力。“一秒变小白”有很多种方法，比如：撞墙、撞桌板等等（玩笑）。

第二个是交付物要明确、清晰、完善。传统的交付物是《产品设计图》和《产品需求文档》，他们的主要读者是研发工程师、测试工程师，让他们能够更好的理解需求的内容对于达成高质量的交付至关重要。

 

需求评审

经过一段时间产品经理脑内的厮杀，就要出来和研发、测试social一下了。高质量的评审对于研发和测试理解需求非常重要。最近阅读的《人类简史》和《如何讲好一个故事》启发很大。在评审中，讲好用户故事对于理解需求起着至关重要的作用。

在过去的一个项目中，因为我的时间紧张，没有足够的时间提供完整的需求，就向几位研发提供了用户故事，让他们自己做解决方案。没想到，还勉强及格的完成了任务。这，也许就是故事的魅力吧。（不推荐经常使用）

当然，讲出一个引人入胜的故事，也有助于让与会人不会低头玩儿手机，笑。

 

研发方案设计评审

这个步骤可能比较特殊，因为自己有研发背景也参与过一线的研发，因此会参与研发方案的设计评审。这个阶段主要是看研发提出的方案是否与需求相同，如果发现需求理解错误要及时的纠正，防微杜渐。

当然，也要防止过度设计。过度设计是按时交付的毒药，研发方案讲究好的维护性和拓展性，总会想要将方案做的尽可能完美，越是好的研发越容易陷入这个陷阱。

因为产品经理是连接用户和研发的桥梁，产品经理也会有对于未来产品走向的规划。在这部分，产品经理和研发之间具有巨大的信息不对称，产品经理处于需求信息优势地位，而研发处于需求信息劣势地位。在适当的时机，阐释对于产品未来的规划，对于防止过度设计有着很好的作用。

 

研发进行时

这个时候的产品经理更像传统的项目经理，沟通协调相关的资源，推动研发过程进行顺利的开展。

这里我用一个业界比较形象的比喻，产品经理更像一个“路由器”。早晨参加站会时，总会发现A研发的一个调整没有告知B研发，导致后续修改损失了一些时间。帮助团队内的信息流动起来，会起到意想不到的积极作用。

当A研发发起一项变更时，通过沟通达成一致，及时将沟通内容结果反馈给其他成员。当需求变更时，将相关研发叫到一起，说清楚解释明白，并及时更新需求文档都是不错的选择。

 

测试及验收

测试是质量的第一负责人，前文讲到了高质量的需求评审对于测试理解需求十分重要。专业的测试会围绕着需求撰写测试用例，并进行测试。但是这里面有一个常犯的问题，就是陷入到细节当中。如果先覆盖大面儿，确保主流程的顺畅贯通，再去花时间去扣细节，就可以有效防止最后时间仓促，主流程出现了严重问题，功亏一篑。

如果条件允许，能够让客户参与验收，也会起到积极的作用。这个时候，基于项目实际状况，根据客户反馈进行微调，会让满意度进一步提升。

终于，产品经理要开始验收了。这里要注意的是，我们是对产品负责的人，如果质量真的不达标，就算研发妹子泪眼汪汪的望着你，就算销售拿着刀上来砍你，也要从牙缝中挤出那个“不”字，守住产品经理仅存的“底线”。因为这时的一个心软，换来的是产品口碑的丧失。

 

上线

恭喜！产品马上就要上线了，几周的辛苦就要结果了。别忙，这个环节也经常被忽视，一次高质量的开发也可能毁在运维上线上。这部分通常是要协调研发记录相关文档，进行相关交流和演练。

综上，相信产品上线后交付质量不会太差。但这只是一个开始，因为客户又要开启“吐槽”模式，新的问题又在向你招手👋。

祝你好运，产品经理。

 

作者是谁？

B端产品经理一枚，就职于易快报 。本科毕业于北航，之后一年在瑞典CTH学习交互设计。2011年开始混迹产品圈，曾在腾讯、人人、猿题库实习，曾任时光网产品经理。执着于产品，爱好设计，掌握技术，欢迎聊骚（微信ID:lqchao007）。

 

本文首发微信公众号 PM队长（ID:smallapp），欢迎转载，转载请注明出处。

爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；

想了解更多移动互联网干货知识，请关注微信公众号运营小咖秀（ID: yunyingshow）