图片来自网络

导读

前文已经和大家提及到了产品经理工作的前三个阶段，名为接受任务，分析，产品设计，这篇文章则和大家聊聊我们工作中的后四个阶段，即交付产物，跟进进度，验收发布，结果分析。

交付产物

我一直信奉团队至上的观点，个人的力量无论多么强大，也需要团队的支撑。

我们在工作中，常常感叹，有一位助理多好，那就能帮我们分担许多工作了。

我们希望有位助理，或者有人协助，本质上是对个人能力的一种危险预警，潜意识在告诉我们，你不行了，你需要团队。

正确处理团队关系，高质量提供交付产物，是我们获得团队帮助所必须要付出的代价。

与不同角色合作，需要交付不同的产物，需要记住的是，没有谁是谁肚子里的蛔虫，也不要寄希望和谁心意相通，正如我们无法揣测BOSS的想法，反之他人，也是相同的。

在我们与团队合作的过程中，90%以上的分歧，不愉快都是因为产品经理没有严谨的对待自己交付的产物。

原型图和需求文档 是我们最基础的两份输出产物，可直到现在，仍然有许多产品经理以思维，思考的名誉，剥削产物的意义。

产品经理确实是一个强思考的行业，但这不代表我们不需要执行，不需要输出，不需要将我们的思考过程交付给团队。

我把我应该做的做完，我就成功了，置于对方有没有做完，抱歉，这不是我的责任，可我们真的知道自己应该做哪些事情吗？

绝大部分的时候，我们是不知道自己要做哪些事情的，这是这类角色的一个特性，似乎没有人为我们安排明确的任务，于是，我们出现了各种问题，各种花式秀矛盾，如果我们是开发人员，我大概会这么说。

你不是来写代码的，你是来写bug的。

我们来简单罗列一下要交付的产物。

原型图，原型全景图，需求文档，变更记录，业务流程图，数据流向图，迭代故事，材料准备，沟通，调整。

并没有完全列举完，我并不想去堆砌交付产物，这似乎没有价值。

交付产物并不是越多越好，而是越有效越好。

以需求文档举例，我们可以看看自己写的需求文档，是否方便研发阅读，是否有歧义，是否已经将功能大部分都覆盖了，一份好的需求文档可以极大的增加团队效率，减少低效时间的耗损。

我曾关注过一个现象，相同的团队，相同量级的需求，实际开发中所消耗时间的差异高达60%期间，发生变化的只是需求文档更为精致，交付产物质量更高。

仔细想想，平时耽误团队时间的，不恰恰是因为需求描述不清晰产生的沟通成本，调整成本，以及由于需求颗粒度不够导致的变更成本吗？

而这些问题，只是需要提高我们交付产物的质量，就能有效解决。

所谓的交付产物是指接力的介质，产品经理所需要做的事情做好了，然后慎重的将我们的努力交给我们的团队。

这是一个很庄重的仪式，很严肃，是对团队的尊重，也是对自己的尊重。

在野外，我们猎杀了一头野猪，大概有100kg，我们嫌弃搬运太重了，就只切了一条猪腿，带回部落，大概只有10kg。

当我们再回到狩猎地时，被猎杀的野猪已经被其他野兽吃完了。

野兽就是我们所接受的任务，由于嫌弃麻烦，我们很粗暴的对待自己的原型图，很粗暴的对待需求文档，对待我们的交付产物。

似乎是没有时间，实际上只是因为我们偷懒，而且还是很不聪明的一种偷懒。

如果用正确的方法画原型图，写需求文档，你会发现，这样才是最大限度的偷懒。

现在你知道如何面对交付产物了吗？ 他并不难，只是需要我们额外的细心，额外的认真，同时，也需要我们尊重团队，尊重自己。

切忌将产品经理等同于思考者，我们除了强思考以外，也是团队中的一份子，思维固然重要，团队力量却远胜于个人的思维。

想的再多，做不出来，有什么作用呢？

跟进进度

产品经理需要跟进版本进度，毫无疑问，我需要再强调一下，只有思想，只有想法，是无法做好产品经理的，我们不缺少想法，每一天我们都有许多想法，成出不穷。

2011年，在我第一次创业时，认识了一位灰色产业的朋友，他告诉了我一个很棒的想法，他想要消灭钱包，消灭现金。

人们每天买东西要带钱包，多么麻烦，还要找零，现在手机那么方便，做个软件出来，直接扫一下就能付钱，多方便

光是手机付费还不够，金额太高，用手机也不方便，我们还得带个手机，最好还是刷身份证，刷脸，这样什么都不用带，要付钱的时候，扫一下脸就好了。

很遗憾，他不是马云，也不是马化腾，他只是一位不那么普通的普通人，现在，人们手机支付已经非常方便了，平时的生活中，我也很少再用现金了。

移动支付产品经理的想法与我这位朋友的想法并没有什么不同，但将想法实现出来却是截然不同的两个概念。

想法固然重要，但也只是重要，真正起到决定因素的，还看我们的做法。

当我们把产物交付给团队以后，我们的事情并没有结束，你需要留意一下，此时你的身份已经变化了。

你的产品从交付的时候开始，出现了变化， 此时，团队就是你的产品，团队效率就是你的产品质量。

如果一个团队中没有更高的角色，那产品经理就是这个团队的leader，产品负责人就要对这个产品负起责任，还要对这个团队负起责任。

早会，需求卡片，周会，进度跟踪，风险报警，日报，周报，需求调整，需求管理，资源协调。

这些是我们最常看见的在交付后的任务，尽管我们在交付产物之前，有做技术调研和需求评审，但这并不能保证在开发过程中出现需求障碍。

实际上，无论我们的技术调研和需求评审做的多么细致，总会出现意料之外的问题，这是因为我们的开发同学，在技术调研和评审时，只能根据大概情况进行预测，而在执行时，却会考虑的更深更全面。

在研发阶段，开发会遇到一些较为复杂的需求，会消耗较多的时间，此时，我们就需要根据开发的反馈进行再评估。

慎用 技术强攻关，大部分的产品并不是以技术决定胜负的，超过80%的团队，并不需要过于强硬的技术，尤其是小团队，初创团队。（技术性项目例外）

在我接触的许多项目中，再也没有任何一个方法比修改产品方案更快捷了，当出现研发障碍时，修改需求方案，能够节省1天至1个月以上的时间，这需要我们每天跟进跟进研发进度。

仔细想想，我们真的有必要花费这么大的成本去实现某个功能吗？

当我们参与到进度跟进时，会收获许多的调整，为了避免出现需求不统一，也是为了提高交付给测试同学的产物，我们还需要对需求进行有效管理。

需求管理

目的：统一需求，提高需求溯源性，也是为了测试时能依据最新的，正确的需求进行测试，减少我们的沟通成本，也减少需求的不确定性。

需求本身首先要能被管理，我并不提倡word版本的需求，也不提倡原型图上写需求，两者皆因为需求无法被管理。

其次，当需求评审以后，不再对已评审的需求进行编辑和删除操作，原则上，我们将以取消和新增的状态进行标示。

同时，我们还要维护变更记录，让变更原因，变更内容清晰可见。

这并不是一件简单的事情，需要我们掌握一些方法，比如尝试用excel来编写需求文档，并且在需求文档的撰写过程中，遵守一些规范。

资源协调

产品开发过程中，其实需要用到很多资源，包括内部的和外部的。

当我们需要使用第三方系统时，需要为开发同学准备好第三方系统的账号，key或者其他什么，比如第三方统计，第三方图片处理，第三方登录，第三方地图。

而内部的资源集中体现在接口API 和设计图输出上，许多时候，我们都是由前端驱动的，我们设计的多数是前端的产品，比如APP， H5 ，WEB， PC ，但前端的功能需要依赖后端的接口，以及UI的效果图。

等接口，等设计图，这两种时间的耗损虽然很可惜，但却是我们经常遇见的问题，如何妥善的安排资源，如何取舍，便是我们要做的资源协调，尽量的减少等待，这需要我们知晓各个功能的优先级，复杂度，尽快进入并行轨道，避免等待。

验收发布

我带产品团队时，会经历两次验收，这里提到的验收是整体验收，我并不是很提倡在开发过程中频繁打包，但我也很理解许多团队，都会频繁的打包验收。

当开发阶段结束后，测试介入前，产品经理有义务进行一次验收，目的是确保主要功能逻辑与需求符合，没有遗漏需求功能，可以称之为需求验收。

当测试结束后，产品经理还需要再进行一次验收，目的是确保产品无明显Bug，能够正常使用，此时，才是真的产品验收。

需求验收

有时，我们需要做好心理准备，也许开发实现的功能与我们的想象的有所区别，甚至南辕北辙。

我们首先需要确认一下，有没有需求遗漏的，通常情况下，会有开发漏做了部分功能，此时，我们就要判断这部分功能是否可放到下个版本迭代，还是当前版本非常重要的功能。

面对一些实现效果与预期效果不一致的功能，我们还要冷静的分析判断，开发这样的调整，能否接受，如果能接受，那就要根据调整结果，来修订我们的交付产物。

原则上，我们希望尽快的切换轨道，需求验收是一个阶段，更多的却是一个节点，我们要把关，但也要灵活，尽量避免过多时间的反复调整。

如何判断哪些需求调整是可被允许的，哪些需求遗漏是可悲允许的，便是我们在这个阶段所需要锻炼提升的技能，MVP原则在这个环节也是适用的。

产品验收

确保产品上线没有明显BUG，不只是测试同学的职责，也是产品经理的职责，当然，我们无法像测试同学一样细致，成体系，成规范的进行模拟操作。

但我们却可以从自己的角色出发，确保主要路径不出明显bug，我们需要保证业务是正常的，核心功能是能被使用的，大部分使用场景是没有明显Bug的。

同时，产品验收阶段也是我们对需求逻辑的最后审核阶段，我们的业务逻辑，功能逻辑这样做是否正确。

这需要我们站在用户的角色，真实的进行体验，可以说产品验收时，我们便是这个新功能的第一位真实用户。

当我们已经完成产品验收了，此时，我们就会通知开发同学。

没有问题，可以打包了。

打包的意思是将已经验收的程序独立生成安装包，在android平台，我们往往需要打多个渠道包，每个渠道一个唯一的标示，这样我们就能知道我们的用户都是从哪里下载的。

当然，发布一个版本可不是这么简单的。

产品发布

从硬性角度来讲，我们要为产品发布准备一些材料，比如更新文案，上传安装包以供审核，特别是IOS平台，要预算3-7天的时间进行审核，且可能审核被拒绝。

从软性角度来讲，当我们发布一些特殊的版本时，还需要配合运营的规划拟定发布策略，必要时，可以封包待发布。

即，我们将可发布的版本准备好，但却不真的发布，等待机会成熟，再进行发布。

为什么在一些重要节庆日，成熟的产品都能准时准点的上线特殊版本呢？比如圣诞节版本，如果延期一两天，是否表示这个版本的时间完全浪费了，毕竟圣诞节可不会等你两天。

特殊的版本，我们往往会提前将安装包准备好，进入封包待发布的状态，只要等待某个特定的时间，便可以直接发布版本。

结果分析

这是最后一个环节了，也是最容易被大家忽视的环节，我们习惯性的将希望寄托在下个版本，寄托在下个功能，却很少对结果进行分析。

当我们产品已经发布了，此时要注意观察相应，观察数据，通过实际市场结果，我们再来思考和评估。

这个功能是否被用户所喜欢，用户使用情况怎么样？有没有提高的方法？

我们知道一个页面，不同的位置，人们的点击欲望是不一样的，相同的发布功能，以点击次数来判断，右上角的发布只占底部菜单的发布的1/10。

我们需要通过产品发布后的结果来持续的去改进，去分析，为下一个版本提供总结性材料。

作为产品经理而言，我们所设计的功能，应该是越来越有效的，而不是越来越多的，我至今仍然记得一个案例。

某网站，进行了一次改版，改动内容是将注册的按钮做的比以前更突出了一些，新版本的网站，注册率比老版本的提高了30%

这里提升的是注册率而不是绝对值，因此我们可以忽略运营或者市场情况带来的影响。

如果我们每次发布后，不对结果进行分析，我想一年经验和两年经验，区别真的不大，甚至再做到第三年，第四年也是相同的。

我们在入门的时候，是以能做出产品为目的的，但当我们能做出来以后，就要学会去分析，去改进，而不是一层不变。

文末撒花

这次真的是超长篇了，上下篇加起来8000于字，希望看官您满意，后续我会将两篇文章进行合并，再发一篇。

若觉得有所收获，希望大家能转发一下， 嘿嘿~