53

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

 6 years ago
source link: http://www.pmcaff.com/article/index/1106050385738880?from=selection
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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

640.jpeg

题图 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），欢迎转载，转载请注明出处。


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK