产品经理工作概述谈谈我眼中的个产品工作环节二

　　前文已经和大家提及到了产品经理工作的前三个阶段，名为接受任务，分析，产品设计，这篇文章则和大家聊聊我们工作中的后四个阶段，即交付产物，跟进进度，验收发布，结果分析。
　　交付产物
　　我一直信奉团队至上的观点，个人的力量无论多么强大，也需要团队的支撑。
　　我们在工作中，常常感叹，有一位助理多好，那就能帮我们分担许多工作了。
　　我们希望有位助理，或者有人协助，本质上是对个人能力的一种危险预警，潜意识在告诉我们，你不行了，你需要团队
　　正确处理团队关系，高质量提供交付产物，是我们获得团队帮助所必须要付出的代价。
　　与不同角色合作，需要交付不同的产物，需要记住的是，没有谁是谁肚子里的蛔虫，也不要寄希望和谁心意相通，正如我们无法揣测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%。
　　这里提升的是注册率而不是绝对值，因此我们可以忽略运营或者市场情况带来的影响。
　　如果我们每次发布后，不对结果进行分析，我想一年经验和两年经验，区别真的不大，甚至再做到第三年，第四年也是相同的。
　　我们在入门的时候，是以能做出产品为目的的，但当我们能做出来以后，就要学会去分析，去改进，而不是一层不变。
　　相关阅读