接ToB产品的迭代工作总结（一）
Part2执行迭代工作：
心里对迭代规划有了底，接下来就得执行迭代工作也是产品经常接触的工作——需求管理工作。从产品经理视角本人将需求管理细分为挖掘、管理、分析、确认、执行、跟踪、完善需求7个小步骤。工作中往往多个需求穿插进行，此种情况下这7个步骤是穿插甚至并行进行的。重点是分析需求与执行需求阶段，个人觉得这是核心。
挖掘需求
围绕该产品的用户目标与非用户目标去挖掘，用户目标就是用户的动机，用户想要什么样的感觉，用户想做什么，用户想要成为什么样的人，这个产品如何一步一步做才可以一一解决这些问题进而达到一个一个目标。有各种目标的存在，团队的其他成员也有义务挖掘需求，身为产品经理就会接收到来自他人的需求。需求就会有主动挖掘和被动接收（别人挖掘）。这样需求的来源大体有：竞品、客户、用户、战略规划、数据、二手资料。这样来自客户的需求就一堆，来自用户的也有一堆，来自竞品的也不少。比如，条件不允许时，且目标用户的属性背景与办公一族有相似时，往往会让内部人员甚至团队开发成员模拟目标用户去体验产品，然后提需求。专业一点会运用可用性测试，用户体验地图、任务路径分析、十秒测试法、视觉评估等方法来挖掘需求。非专业提需求与专业提需求，其实都没有离开用户体验5要素的范围。所以将战略层、范围层、结构层、框架层、表现层作为指导方向再结合具体方法去挖掘需求的，在迭代阶段挖掘需求会更明晰。
管理需求
面对海量的需求，为了方便查找以及追本溯源，而且有的需求被挖掘出来后一时半会是无法判定是否或者什么时候排上日程的，这样把每个需求涉及到的关键属性信息记录清楚就方便后面的工作。具体方法有比如需求池。需求池里面该记录哪些信息可以根据具体的产品来定。经过简单评估的需求就会进入需求池，要将其拿去设计开发上线就还得经过分析确认更严谨的评估。
分析需求
分析需求的目的几乎是确认该需求是否值得投入到设计开发中去，也是分析该需求是否有价值。5W1H、6W2H分析法等等，如果能运用到位，在需求这个大事情身上就会轻松很多，减少考虑不周、反复修改的情况。
why（基于什么动机）、what（大体描述什么样的）、who（用户）、where（何地，该需求转化到产品上时在哪儿）、when（什么情况下）、how（怎么做，涉及流程）、how many（有多少用户会用）、how often、how much等方面提出问题进行思考。
利用以上其中6个方面的关键信息可以进行场景还原，再判定：
1、会有多少用户会用；（how many）
2、频率如何；（how often）
3、动机是否与马斯洛需求层次理论或者人性的7宗罪相吻合，强烈程度；（why）
4、是否符合近期的迭代规划，成本如何。（how much）
经过以上分析，大体能判定该需求的价值。说到价值，价值链基本理论中说到真正创造价值的是价值链的“战略环节”，但是只有完成了价值链中的最后一个环节，这个产品或服务才是完整的。产品的价值也是由一些能满足核心需求的核心功能创造的，但是有的需求不做这个产品就不完整甚至不能很好地跑起来，就不能实现该产品的“大一统”。在产品需求分析上，有的需求可能真分析不出什么价值，但是要是是产品不可缺的一部分，是不能轻易就不要的。如果还犹豫不决，也可以运用逆向思维来分析，不做该需求会对产品造成什么影响。
在迭代阶段，分析需求还有以下三点该注意：
1、这个需求与产品这个系统的关系。在复杂尤其还有终端的产品，要去分析这个需求本身是独立的还是对产品的某一部分造成干扰或者起到协助作用。造成干扰的话，解决方案所需要的成本会不会很大。
2、这个需求的落地环境如何，是否受阻，成本是否很大。
3、这个需求是否会被替代，这个需求比不比要替代的东西要好。
在分析需求过程中，可能why这个是相对较难的，这可以参考《精益创业》中提到“五个为什么”，经过五个或者两三个为什么的追问，往往能够找到更深层的原因，看到问题的本质。
比如为什么用户反馈登录页面太烦了？（1、因为只支持用户名登录，2、因为用户容易忘记用户名）
1、（部分追问）
为什么只支持用户名登录？（因为一开始没有考虑到唯一性的问题，为了填补这个漏洞，转而只支持用户名登录）
为什么会出现上述漏洞的问题？（因为那段时间没有专门的人负责考虑这方面的事情，匆匆忙忙就投入开发了）
为什么没有人负责？（因为原来负责的人离职后，还没有招到人来，也没有人去负责这些事情，导致容易出错）
2、（部分追问）
为什么用户容易忘记？（因为用户拥有的用户名太多了，记不了那么多）
为什么记不了那么多？（因为人的记忆一般适合记住7个词组，互联网发达阶段，一个人拥有的用户名可以是各种各样的）
实际上分析需求的过程在挖掘需求时就应该有过粗略的分析了，甚至也有很细的分析才将需求提出来的，而那些经常提需求需求几乎不通过的情况应该是没有经过深入的分析就把需求提出来了。
（Ps：n个W +n个H这些分析法，可以灵活运用）
有了分析方法，可是分析到何种程度会最佳，这应该是取决于对需求的认知程度，认知的成熟度往往取决于能接触到的信息的广度和深度。所以加油吧......
确认需求（需求决策）
分析需求之后，是否要去做该需求以及大体如何做，就得做出决策，这是需要团队成员以及领导确认的，尤其对于重大一点且比较犹豫不决的需求。如果想要做出正确的决策，除了分析需求的工作要做到位之外，也可以参考《决策与判断》以及《卓有成效的管理者》中提到的决策5要素，这样也许可以更深层次地理解决策进而对快速地做决策有一点帮助。
执行需求
在这一阶段，需要将功能需求定义清楚，输出原型文档，原型文档评审，原型文档交付ui设计师和开发同事。
需求确认要做之后，就得描述清楚通过什么办法来满足该需求，也就是功能需求定义阶段，定义好流程、逻辑规则、功能规则、入口，对于b端复杂产品，逻辑规则特别重要，有的也真的特别复杂，很烧脑。输出文字描述版本，将文字版本找技术负责人员交流一下（本身对技术很了解就略过），在分析需求以及确认需求阶段都是一些比较大体的东西，在执行阶段就得做得很细可能会出现一些之前没有考虑过的东西，所以在输出功能需求定义文字版本后，最好交流确认一下有疑问的点以免后期反复修改，没有很严重的疑问后，可以进入画原型阶段了。
进行功能需求定义时，容易出现的问题是考虑不全，甚至没有实现这个功能的逻辑闭环，以及对于边界条件定义得不合适。在分析需求的时候就已经在运用wh分析法，一般是大体的分析，在进行功能需求定义时，也同样可以运用wh分析法，要深入，就可以实现一个功能的逻辑闭环。以下是大体步骤。
1、按照wh分析法，先找到相匹配的解决方案（分析需求时应该已经有了）；
2、思考如果用户不按照所提供的方案的正常路径去使用产品，会有哪些异常，也就是异常预估，每一个环节都可能出现异常。这可以从用户、产品逻辑链条去分析每一个环节的异常，对于有些功能是可以一起分析的。
3、针对预估出来的每一个环节的异常，给出对应的解决方案。
4、从以上三点考虑对一个功能需求的定义就会比较全面，综合信息并且再次思考需求本身以及从产品设计比较通用的原则尤其体验一致性的原则、成本、公司资源等再去做评估，会减少后期的修改，然后从评估结果中考虑删减以及排优先级。（这个事情往往在评审的时候会进行）但是作为产品在评审前心里最好有个底。
原型画完成后预约时间就可以进入原型评审阶段了。在评审前能对一个功能做较全面的定义以及评估，就不至于在评审时被各方提出的一些问题问得哑口无言。所以尽量形成一个系统的视角层层深入去分析并思考对应的解决方法，这样评审也不会太难看。
评审结束后，一般情况下还是要修改一些地方，最好对评审会议做一个记录让主要负责人员都确认一下，然后提交原型给ui以及开发同事。
跟踪需求
产品提交原型后算是完成一个需求任务，但是还有任务就是要去跟踪ui设计、开发，及时拿到反馈进而沟通，开发基本完成后要去验收，等待测试上线。这些按照路程走，前面工作做到位，是不会有太大问题的。若出现了问题，5why分析，哈哈哈~
上线之后，还有注意对客户、用户反馈信息的跟踪，留意分析各种数据。
完善需求
需求总是源源不断的，那就想方设法去完善。
以上是个人的总结，可能还有不全面不到位的地方，欢迎交流。
联系客服
