本文作者对To B 产品的迭代工作进行了总结，主要分为两部分，一是形成迭代规划个人总结的思路；二是执行迭代工作的执行步骤。enjoy~有机会负责过大型 to B 系统软件产品迭代设计工作，是物联网行业产品，该系统产品由终端、PC web端、手机app端组成，可以通过pc web端系统或者手机app来控制终端。增加或者减少一个功能，往往会有牵一发而动全身的感觉，同时接手时几乎是没有任何规范的文档来记录背景信息的。（没有那就一边开展迭代工作一边建立对应的规范，然后不断修改补充。）以下就是一点总结。 产品在开展迭代工作前，得去理解这个产品是如何从0到目前阶段的。 方法有：
- 写产品体验分析报告；
- 带着分析报告中遇到的疑问，充分利用公司的资源去了解该产品的相关背景来寻找答案，可以向团队成员甚至向市场人员、客户了解，同时也要快速了解这个产品所在的行业涉及到的相关专业知识。比如在系统软件上看到并不熟悉的专业文案，那不一定是会造成误解，有可能在行业里面就是那样称呼的，不了解的话还容易闹笑话。
- 如果想要了解的信息，无法从别人那里获取那就只能依据自己的专业能力来判定了。比如从别人那无法得知目前产品所处阶段、所在市场、生态形式、目标用户、驱动力，那可以通过综合能了解到的信息做出判定。
Part 1 迭代规划的思路
to B 产品，一般的商业逻辑是通过向客户售卖硬件以及配套软件授权来赚取回报。而当一个toB产品充当一个组织想进入并垄断某个行业的切入点的角色时，该产品在迭代规划时所要考虑的维度可能就会更多。 比如一个诞生在一家初创物联网公司的toB产品，该公司也有远大目标，迭代计划要考虑的包括可能还不限于以下维度：- 该产品目前情况（自身情况，外界情况（竞品、行业））
- 产品所处公司目前业务情况（公司所拥有的资源，可采用SWOT分析法）
- 公司目标（更高层级的商业目标）
- 产品目标与市场反馈、客户目标与客户反馈、用户目标与用户反馈
- 如何更好为另一产品做铺垫（比如导流）
Part 2 执行迭代工作
心里对迭代规划有了底，接下来就得执行迭代工作也是产品经常接触的工作——需求管理工作。从产品经理视角，本人将需求管理细分为挖掘、管理、分析、确认、执行、跟踪、完善需求7个小步骤。工作中往往多个需求穿插进行，此种情况下这7个步骤是穿插甚至并行进行的。重点是分析需求与执行需求阶段，个人觉得这是核心。1、挖掘需求
围绕该产品的用户目标与非用户目标去挖掘，用户目标就是用户的动机，用户想要什么样的感觉，用户想做什么，用户想要成为什么样的人，这个产品如何一步一步做才可以一一解决这些问题进而达到一个一个目标。有各种目标的存在，团队的其他成员也有义务挖掘需求，身为产品经理就会接收到来自他人的需求。需求就会有主动挖掘和被动接收（别人挖掘）。这样需求的来源大体有：竞品、客户、用户、战略规划、数据、二手资料。这样来自客户的需求就一堆，来自用户的也有一堆，来自竞品的也不少。 比如，条件不允许时，且目标用户的属性背景与办公一族有相似时，往往会让内部人员甚至团队开发成员模拟目标用户去体验产品，然后提需求。专业一点会运用可用性测试，用户体验地图、任务路径分析、十秒测试法、视觉评估等方法来挖掘需求。非专业提需求与专业提需求，其实都没有离开用户体验5要素的范围。所以将战略层、范围层、结构层、框架层、表现层作为指导方向再结合具体方法去挖掘需求的，在迭代阶段挖掘需求会更明晰。2、管理需求
面对海量的需求，为了方便查找以及追本溯源，而且有的需求被挖掘出来后一时半会是无法判定是否或者什么时候排上日程的，这样把每个需求涉及到的关键属性信息记录清楚就方便后面的工作。 具体方法有比如需求池。需求池里面该记录哪些信息可以根据具体的产品来定。经过简单评估的需求就会进入需求池，要将其拿去设计开发上线就还得经过分析确认更严谨的评估。3、分析需求
分析需求的目的几乎是确认该需求是否值得投入到设计开发中去，也是分析该需求是否有价值。5W1H、6W2H分析法等等，如果能运用到位，在需求这个大事情身上就会轻松很多，减少考虑不周、反复修改的情况。 why（基于什么动机）、what（大体描述什么样的）、who（用户）、where（何地，该需求转化到产品上时在哪儿）、when（什么情况下）、how（怎么做，涉及流程）、how many（有多少用户会用）、how often、how much等方面提出问题进行思考。 利用以上其中6个方面的关键信息可以进行场景还原，再判定：- 会有多少用户会用；（how many）
- 频率如何；（how often）
- 动机是否与马斯洛需求层次理论或者人性的7宗罪相吻合，强烈程度；（why）
- 是否符合近期的迭代规划，成本如何。（how much）
- 这个需求与产品这个系统的关系。在复杂尤其还有终端的产品，要去分析这个需求本身是独立的还是对产品的某一部分造成干扰或者起到协助作用。造成干扰的话，解决方案所需要的成本会不会很大。
- 这个需求的落地环境如何，是否受阻，成本是否很大。
- 这个需求是否会被替代，这个需求比不比要替代的东西要好。
- 为什么只支持用户名登录？（因为一开始没有考虑到唯一性的问题，为了填补这个漏洞，转而只支持用户名登录）
- 为什么会出现上述漏洞的问题？（因为那段时间没有专门的人负责考虑这方面的事情，匆匆忙忙就投入开发了）
- 为什么没有人负责？（因为原来负责的人离职后，还没有招到人来，也没有人去负责这些事情，导致容易出错）
- 为什么用户容易忘记？（因为用户拥有的用户名太多了，记不了那么多）
- 为什么记不了那么多？（因为人的记忆一般适合记住7个词组，互联网发达阶段，一个人拥有的用户名可以是各种各样的）
4、确认需求（需求决策）
分析需求之后，是否要去做该需求以及大体如何做，就得做出决策，这是需要团队成员以及领导确认的，尤其对于重大一点且比较犹豫不决的需求。如果想要做出正确的决策，除了分析需求的工作要做到位之外，也可以参考《决策与判断》以及《卓有成效的管理者》中提到的决策5要素，这样也许可以更深层次地理解决策进而对快速地做决策有一点帮助。5、执行需求
在这一阶段，需要将功能需求定义清楚，输出原型文档，原型文档评审，原型文档交付ui设计师和开发同事。 需求确认要做之后，就得描述清楚通过什么办法来满足该需求，也就是功能需求定义阶段，定义好流程、逻辑规则、功能规则、入口，对于b端复杂产品，逻辑规则特别重要，有的也真的特别复杂，很烧脑。输出文字描述版本，将文字版本找技术负责人员交流一下（本身对技术很了解就略过），在分析需求以及确认需求阶段都是一些比较大体的东西，在执行阶段就得做得很细可能会出现一些之前没有考虑过的东西，所以在输出功能需求定义文字版本后，最好交流确认一下有疑问的点以免后期反复修改，没有很严重的疑问后，可以进入画原型阶段了。 进行功能需求定义时，容易出现的问题是考虑不全，甚至没有实现这个功能的逻辑闭环，以及对于边界条件定义得不合适。在分析需求的时候就已经在运用wh分析法，一般是大体的分析，在进行功能需求定义时，也同样可以运用wh分析法，要深入，就可以实现一个功能的逻辑闭环。以下是大体步骤。- 按照wh分析法，先找到相匹配的解决方案（分析需求时应该已经有了）；
- 思考如果用户不按照所提供的方案的正常路径去使用产品，会有哪些异常，也就是异常预估，每一个环节都可能出现异常。这可以从用户、产品逻辑链条去分析每一个环节的异常，对于有些功能是可以一起分析的。
- 针对预估出来的每一个环节的异常，给出对应的解决方案。
- 从以上三点考虑对一个功能需求的定义就会比较全面，综合信息并且再次思考需求本身以及从产品设计比较通用的原则尤其体验一致性的原则、成本、公司资源等再去做评估，会减少后期的修改，然后从评估结果中考虑删减以及排优先级。（这个事情往往在评审的时候会进行）但是作为产品在评审前心里最好有个底。
6、跟踪需求
产品提交原型后算是完成一个需求任务，但是还有任务就是要去跟踪ui设计、开发，及时拿到反馈进而沟通，开发基本完成后要去验收，等待测试上线。这些按照路程走，前面工作做到位，是不会有太大问题的。若出现了问题，5why分析，哈哈哈~上线之后，还有注意对客户、用户反馈信息的跟踪，留意分析各种数据。7、完善需求
需求总是源源不断的，那就想方设法去完善。 以上是个人的总结，可能还有不全面不到位的地方，欢迎交流。 作者：一篇森林，微信公众号：yipiansenlin38，一枚产品。 本文由 @一篇森林 原创发布于人人都是产品经理。未经许可，禁止转载。 题图来自 Pexels，基于 CC0 协议 爱盈利-运营小咖秀 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；【转载说明】 若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com
