做了差不多快三年的产品经理，在此过程当中很少对自己的工作进行总结，因此会很难形成一个体系化的思维，也就是我们常说的方法论，所以写这篇文章的目的是对自己工作进行总结，以下此内容是我做产品从0-1的方式方法，比较基础性的东西，通过梳理后希望能够分享给大家同时巩固自己的经验。
在规划整个产品过程当中主要分为两个阶段；
①.需求准备阶段
②.需求实施阶段。
首先说下“需求准备阶段”。我们要去“多问为什么”，每当我们接到需求的时候，这个需求可能来自公司内部需求，接到他们的需求时首先要做的就是问需求方为什么要这么做，其目的是为了判断这个需求的合理性，那么我们如何去判断这个需求到底合不合理呢？其实有一个非常简单的办法是判断需求方回答问题的逻辑是否合理，例如需求方回答问题的时候模凌两可，那么这个需求肯定是不靠谱的，反之能够直击要害，那么这个需求基本上是成立的，例如：“我想要吃饭”，那么我为什么想要吃饭呢？“是因为我饿了”那么这是一个刚需，所以我想要吃饭，但是如果回答说“我也不知道，我就是想吃饭”，最终这个需求肯定是不成立的。
确定需求方的需求没有问题之后，我们就进入了 “需求分析” 阶段，假设这个需求是比较大的项目，首先你要考虑的是这个需求是针对哪部分目标用户，提取用户画像（例如：年龄、性别、职业等），其次要知道他是在什么样的时间段内会触发此需求，例如“我吃早饭想吃的稍微简单点喝一碗粥”，中饭想要吃的好点吃红烧肉，晚饭想要吃的少点吃一些面条，半夜想来一份麻辣小龙虾，因此不同的时间段需要满足不同的需求，于此同时我们确定主抓哪个时间点比较合适，这个要结合自身的产品定位，这样才能够更好的满足用户的需求。然后我们要考虑在何地点会触发此需求，例如“我在公司吃饭还是在家里吃饭”，不同的地点吃饭他们的需求同样也有所不同，在家里吃饭的时候会随便吃一点或是自己出去买菜煮饭等，在公司吃饭可能和同事们一起点外卖或者一起下馆子。之后要知道吃饭的起因是什么，可能是因为饿了，也有可能是因为馋了，假设仅仅是饿了可能吃饱就行，如果是因为馋了想吃东西，那么我不仅仅要吃饱，我还要吃的爽。最终用户做这件事情的经过是怎么样的，假设我们是做一款外卖软件，通过我们软件里面的某个功能来达到他想要吃饭的目的，例如“下单、浏览、配送等”，一步步的达到他想要吃饭的需求，是否能够填饱了自己的肚子或者是解决口腹之欲。
需求分析过程当中还要进行 需求确认，其目的是为了进行查漏补缺，确认是否达到了需求方的目的，如果这个需求是自己发起的，那么就要问自己是否达到了自己的预期。
需求确认完毕之后进入 画原型 的阶段，在画原型之前我们要列出对应的功能模块、信息架构、流程图以及所要跳转对应的页面，这里要注意的是“画原型我们不一定要画的多好看，但是一定要画的整齐干净把每一个对应的模块进行区分，将逻辑梳理好，将每一个需求都考虑到位。因为是给开发和设计同学看，所以在体验上要注意，不然在开发的过程当中可能由于原型的不明确他们会反复的与你进行沟通，还是有些开发同学性别比较内向不擅长沟通，由于你原型画的不够明确，那么开发可能就按照他们自己的理解来写逻辑了，最后要想改就比较麻烦了。同时我们也不要太过于依赖工具，因为工具只是一个辅助而已，原型画的再好也不能证明你产品做有多牛X，但是可以通过工具来体现出我们产品汪的专业性。在画原型写PRD的过程中其实是对我们规划的产品进行重新梳理，将每个细节都考虑到位，但需要注意的是一定要写修改记录（需求变更记录）、文档导航（当我们一个项目内容过于庞大时可能通过搜索文档导航来找到对应的模块）、名词解释（对某个专业名词不理解时可以翻出来看看）、产品介绍（例如这个产品的目标、以及做这个产品的目的等）。
原型和PRD写完后进行 需求评审 阶段，其实有很多人都说需求评审更像是一个战场，因为开发与产品立场的不同，所以各自的想法也会不一样，当然我们自己一定要控制好情绪，避免与开发出现争吵等情况。需求评审大致可以分为需求评审前、中、后。每个不同的阶段所要注意的事项也会有所不同，例如“在需求评审前 我们要先考察下相关的开发同学手上是否有活、积压了哪些需求，如果有看他们大概是什么时候完成，有的时候开发同学的心情、状态可能会影响对你需求的评估，所以要需求评审之前先去探探路。当然有时我们也不知道自己手上的需求会分配给谁，这个时候我们需要跟对应的开发负责人去沟通，这里有一个小技巧“平时要跟开发负责人搞好关系，这样对于你接下来的工作开展非常的有帮助”。需求评审之前准备工作是否做足了，例如“需求是否已经确定了、需求评审中的资源是否准备充分了、原型以及文档是否已经写完了”，如果这些事情都没确定下来，那基本上可以说是被开发彻底“秒杀”了。当然我们可以拿一个比较重要的需求或者是自己没有把握的需求跟开发对下这个需求的难易程度、技术上是否有难点、可能会用到哪些资源，如果对应的技术难点没有解决方案，我们可以自己在百度上搜索下，将对应的解决方案记录下来，那么我们在需求评审的时就非常的有底气更加自信。以上就是需求评审前的方式方法。
在 需求评审中 首先要跟开发同学讲清楚需求目的和背景，让所有参与你项目中的团队成员都朝着一个目标前进，同时不要以一种说服人的心态去讲需求，也不要认为自己的需求已经想的很完善了，有些时候开发提出的问题其实还是有道理的。当开发提出诸多疑问时，我们还是要适当的坚持自己的想法，因为我们已经经过了需求分析，所以我们对于这个需求的理解程度肯定要比开发来的深入，而开发所提出的问题可能只是临时起意而已，如果他们提出的问题确实是动摇了你的想法，那么这个时候我们就要回到原点来看，我们这个需求的目的是什么，这个需求能够解决用户哪些问题，假设这个需求偏离了我们的目标，我们应该及时的调整过来。当然这也仅仅是我自己总结出来的经验，可能还有其他更好的方法，这个是根据自己的经验因人而异。
在 需求评审后，需要总结下需求评审过程当中有哪些问题，能当场解决的就不要拖到会后，有些解决不掉的，事后一定要尽快的处理，之后将需求评审的内容以及未解决的问题还有已解决的问题全部都捋出来，以会议纪要 的形式发给每一位参会的人员，原型以及文档需要更改的及时更改，更改完之后重新以邮件的形式告知对应的开发人员，若当中需求过了好几天才开始，那么这个时候我们一定要再次跟开发进行确认，因为过了一段时间之后开发人员可能会忘记某个关键点。
以上需求的准备阶段基本上已经完成了，接下来就是需求的实施阶段，在需求的实施阶段角色要进行相应的转变，在需求的准备阶段可以说是整个项目的策划人，但在需求实施阶段我们更偏向于项目经理的角色，要在整个项目的过程当中充当一个润滑剂的作用，确保项目能进行正常的运转。
在项目的跟进过程中，要把控好每一个节点及时对需求更新，尽量将延期的风险降到最低。且在项目跟进的过程当中肯定会经常询问开发进度，但这也是有技巧的，一周大概可以问个一到两次，这个时间自己把控好即可，但也不必每天过问或者硬生生的问需求做的怎么样了，什么时候可以完成等，此等询问势必会引起开发的反感，所以我们得找一个合适的时间点去问，例如组织下出去小聚吃个饭啥的顺带把项目的进度给问了或者在大家休息的时候过去唠下顺便问下进度，还有一个方法是可以在每周周五的时候去问下，因为这个时候大家都是要写周报的，所以这个时候可以跟开发沟通说：“你这边的进展如何啦，我们两个对下看看是否都保持一致，咋们也好向领导汇报”，或者是问下开发这边是否有遇到什么问题需要我去协调解决的或者是有些资源没有到位的等等，这时我们会更加顺利的知道需求的状态，还有要记住的一点是尽量不要在开发写代码的时候去询问。
其实产品和开发一样都不希望有 需求变更，因为需求变更意味着之前做的工作很多都要推倒重来，开发写的逻辑一但出现更改的情况是一件非常麻烦的事情，所以能不变更的尽量不要动。但是有些时候我们确实是避免不了需求变更的可能，我总结了一下主要包括以下这几点，
①.刚开始的时候需求没有想清楚，造成这样的主要原因是可能留给自己分析的时间太少了，因为有时自己身上可能会压着有很多需求，但是可以对需求进行优先级划分，如果有需求方，多和需求方进行沟通。
②.自己在产品规划的过程当中出现遗落或者是设计上不合理的地方，赶紧跟开发同学认错，主动背锅，请开发喝个下午茶或者请吃饭等等之类的。其实有的时候确实是挺无奈的，很多时候在做产品规划不一定能够想的非常完善、想的非常清楚，最终导致开发的对你的抱怨“你下次能不能想的清楚、想明白一点把每一个细节都想到位”，其实我们也想，但是人的思维总是有漏洞的，不可能把所有的事情都想的非常周全，我们能做的只有让开发同学尽量的去理解我们。
③.在开发的过程当中遇到了一些问题，例如：在开发的时候遇到一些技术难题绕不过去了，或者是开发所需要的资源比当时想的要多，所要投入的成本也会更高一点。那么这个时候责任就在开发这边了，但是我们不能把这个态度变现出来，因为开发毕竟是干活的人，所以在沟通的时候要稍微委婉一点，并且高效的做出正确的决策，快速的想出解决方案。其实我们产品经理跟开发之间都是要经过不断的磨合相互理解才能完成。
老板从中插手需求，其实老板从中插手有好处也有坏处，好处在于可以帮我们催促开发的进度或者给我们争取到更多的资源，更好的帮做我们这个需求。坏处在于可能老板觉得我的需求不太合理又或者是有更好的想法希望推到重来，那么这对我们来说是一个非常不好的消息，并且加强了沟通的难度，如果老板说的不是很合理，那么我们要尽量的去说服老板，若他说的头头是道无力反驳时，那我们还是老老实实的去跟沟通协商吧！跟开发协商的时候切忌不要说 “这个需求是老板要求这么做的，是老板要求这么改的” 这样相当于是把锅甩给了老板并且会导致你在开发的心目中信任度会大打折扣，他们有时候会跟你抱怨说“老板说改你就改啊，能不能有点自己想法，就不能挡回去吗，要你这个产品经理有何用等等”
其实我自己之前就有同样的经历，有一个运营同学跟我说要改需求，我问她为什么要这么改，她直接来一句“我也不知道啊，是老板要求我这么改的，我有什么办法” 当时我就很反感她对我说的这句话，完全没有自己的想法，别人说怎么做就怎么做，这种就纯属于无脑的行为。所以我们应该适当的把这个锅替老板给背下来，同时说道：“可能是我们当时需求考虑的不够周全，之后老板从他战略的眼光当中发现我们的这个需求可能不太合理，需要进行整改，我也是在万不得以的情况下才这么做的，大家努努力将需求改改，若时间上有问题的话我再跟老板争取一些时间，又或者是大家加加班等”。
其实 在测试阶段 我们也要把把关，如果我们有时间可以协同测试人员一起测试，但是要注意的一点，如果我们的需求文档或者原型有出现变更的情况一定要及时做好变更记录，因为测试同学是要根据你的需求文档来些写测试用例，所以信息要做好同步，若当中测试同学对这个需求提出一些疑问时同样也要做好相应的决策。
在验证阶段，开发出来的东西可能跟你所想的或者没有达到你的预期时，前期做了这么久的准备工作，开发出来的东西还是跟之前有出入，此时你的心情一定很气愤，但是一定要控制要自己的心态，把自己身上的怒火给压制下去，不然开发会认为你是一个非常急躁的人做事不靠谱。遇到问题我们首先要想办法先解决，例如页面上的功能模块位置不对、弹窗没有提示等等，该改的我们让开发改就行了，有话好好说。
最后一个阶段 产品上线，刚开发出来的需求不完善其实很正常，例如体验不好等等，下个版本再进行迭代优化即可，但是我们也要保证产品的可用性。产品上线之后一定要第一时间去体验产品是否有问题，有问题及时更改，同时我们还要告知需求方需求上线了，让他们进行验收。若需要APP发版一定要通知渠道，让他们将对应的“apk、Ipk”发到对应的应用市场，有时候可能需要应用市场的推荐位，但是是有时间限制的，所以一定要及时告知渠道，准备好相应的上架资源，同时我们还要跟对应的客服同学进行培训，例如版本更新了哪些，产品的使用方法等等，以便应对用户的问题。
产品上线之后仅仅只是一个开始，下一个阶段就是进行产品运营，因为上线之后问题肯定会越来越多，同时还要把产品给运营好， 就需要和运营市场相配合。
总结下，一个产品从0-1所要经历的阶段其中包括以下几个阶段，需求准备阶段：①.为什么要做此需求 ②.需求分析 ③.需求确认 ④.画原型写PRD ⑤.需求评审。需求实施阶段：①.需求跟进 ②.需求变更 ③老板插手 ④.测试阶段 ⑤.验证阶段 ⑥.产品上线。
网友评论