有机会负责过大型 to B 系统软件产品迭代设计工作，是物联网行业产品，该系统产品由终端、PC web端、手机app端组成，可以通过pc web端系统或者手机app来控制终端。增加或者减少一个功能，往往会有牵一发而动全身的感觉，同时接手时几乎是没有任何规范的文档来记录背景信息的。（没有那就一边开展迭代工作一边建立对应的规范，然后不断修改补充。）以下就是一点总结。
产品在开展迭代工作前，得去理解这个产品是如何从0到目前阶段的。
方法有：
- 写产品体验分析报告；
- 带着分析报告中遇到的疑问，充分利用公司的资源去了解该产品的相关背景来寻找答案，可以向团队成员甚至向市场人员、客户了解，同时也要快速了解这个产品所在的行业涉及到的相关专业知识。比如在系统软件上看到并不熟悉的专业文案，那不一定是会造成误解，有可能在行业里面就是那样称呼的，不了解的话还容易闹笑话。
- 如果想要了解的信息，无法从别人那里获取那就只能依据自己的专业能力来判定了。比如从别人那无法得知目前产品所处阶段、所在市场、生态形式、目标用户、驱动力，那可以通过综合能了解到的信息做出判定。
当对产品有了一定的了解后，就去形成一个迭代规划，然后执行迭代工作。
Part 1 迭代规划的思路
to B 产品，一般的商业逻辑是通过向客户售卖硬件以及配套软件授权来赚取回报。而当一个toB产品充当一个组织想进入并垄断某个行业的切入点的角色时，该产品在迭代规划时所要考虑的维度可能就会更多。
比如一个诞生在一家初创物联网公司的toB产品，该公司也有远大目标，迭代计划要考虑的包括可能还不限于以下维度：
- 该产品目前情况（自身情况，外界情况（竞品、行业））
- 产品所处公司目前业务情况（公司所拥有的资源，可采用SWOT分析法）
- 公司目标（更高层级的商业目标）
- 产品目标与市场反馈、客户目标与客户反馈、用户目标与用户反馈
- 如何更好为另一产品做铺垫（比如导流）
（可能还有疑问说版本规划还得考虑团队成员本身情况，执行迭代过程中确实需要考虑，但是产品版本规划是不会停的只要这个产品想要发展下去。）
这些维度在实际迭代过程中是需要做出平衡与取舍以及排列优先级的，如何取舍以及安排优先级常用的衡量标准是由目标以及价值来决定，当然也会受到各种条件的制约，而且这些维度的状态、衡量标准以及制约条件是随着时间而动态变化的，在某些时间段内侧重的维度也可能会不同。在版本规划中还要注意把握时间的节奏点，可参考兰彻斯特战略中的市场占有率原则，别在大家都有机会的情况下错失时机，让对手领先牢牢占据了市场。基于这些维度的思考，大体梳理出适合该产品发展的大方向。在执行迭代规划的过程中，不要偏离这个大方向。
比如公司要利用该产品达到的目标仅仅利用公司自身的业务发展可能比较漫长，通过与某一方面更有优势的第三方合作（客户需求的产生）可以有助于达到该目标，价值很大，那么在迭代过程中就会插进来客户的需求，在某一段时间内尤其注重去执行客户的需求，把产品要达到的目标先暂时放一放。
而当要准备依靠产品自身去打开市场前，就会将迭代计划集中在产品核心功能的优化上。to B 产品在产品的0到1阶段，为了保证安全准确，也会先上核心功能，但是可能实际开发出来后用户体验还不是很好，在合适的时候迭代计划就会注重打磨细节，毕竟toB产品注重稳定性、效率，尤其对于复杂型产品，如果不注意打磨细节认知负荷增大、操作负荷增大，用户使用产品的效率就达不到好的效果了，产品整体价值也会被降低，何况toB产品的发展趋势也是越来越注重产品的易用性好用性。尤其当产品推向市场的时候，外界评价产品的维度往往会由核心功能的价值转变成细节上的问题而使产品推向市场受阻。就比如平时我们购买一个商品，有一些小瑕疵都会放弃购买进而去选择别的同类商品。所以在合适阶段，toB产品也得注重用户体验，尤其是要让产品有一致的良好用户体验。
想要更好地理解目标，可以看看《交互设计精髓》相关部分。《交互设计精髓》中将目标划分为用户目标与非用户目标，用户目标是用户的动机，成功的产品首先要满足用户目标，但是也必须承认并考虑以及解决非用户目标。而《用户体验要素》中所阐述的战略层包含的产品目标与用户需求（用户目标），结合理解会更深刻也会对工作有更足够的指导。toB产品也是可以运用目标导向这一工具的，在版本迭代规划中，在时间这个维度上优先实现哪个目标就得结合产品以及公司具体情况具体分析，同时要坚持用发展的眼光看待问题。一个toB产品有本身的发展逻辑，而将其放在具体环境中发展时，就得采取对应策略来保护、推进这个产品的发展，使其实现目标。
迭代规划中的价值如何去衡量，可能谈论最多的就是迭代了这部分内容，哪个回报更大。有没有一成套的方法，本人也想知道哈。
这一部分涉及到的内容也属于商业计划书的内容，有的公司并没有一个完整的文档来记录或者还没有考虑清楚。无论这部分内容清楚与否，如果产品的核心功能已被市场验证是对的，在迭代阶段同样得思考并完善这些内容，并依据围绕这些内容来开展迭代工作。
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）
经过以上分析，大体能判定该需求的价值。说到价值，价值链基本理论中说到真正创造价值的是价值链的“战略环节”，但是只有完成了价值链中的最后一个环节，这个产品或服务才是完整的。
产品的价值也是由一些能满足核心需求的核心功能创造的，但是有的需求不做这个产品就不完整甚至不能很好地跑起来，就不能实现该产品的“大一统”。
在产品需求分析上，有的需求可能真分析不出什么价值，但是要是是产品不可缺的一部分，是不能轻易就不要的。如果还犹豫不决，也可以运用逆向思维来分析，不做该需求会对产品造成什么影响。
在迭代阶段，分析需求还有以下三点该注意：
- 这个需求与产品这个系统的关系。在复杂尤其还有终端的产品，要去分析这个需求本身是独立的还是对产品的某一部分造成干扰或者起到协助作用。造成干扰的话，解决方案所需要的成本会不会很大。
- 这个需求的落地环境如何，是否受阻，成本是否很大。
- 这个需求是否会被替代，这个需求比不比要替代的东西要好。
在分析需求过程中，可能why这个是相对较难的，这可以参考《精益创业》中提到“五个为什么”，经过五个或者两三个为什么的追问，往往能够找到更深层的原因，看到问题的本质。
比如，为什么用户反馈登录页面太烦了？（1、因为只支持用户名登录，2、因为用户容易忘记用户名）原因可能有括号里面的两点，然后分别对这两点展开追问。
（针对第1点的追问）
- 为什么只支持用户名登录？（因为一开始没有考虑到唯一性的问题，为了填补这个漏洞，转而只支持用户名登录）
- 为什么会出现上述漏洞的问题？（因为那段时间没有专门的人负责考虑这方面的事情，匆匆忙忙就投入开发了）
- 为什么没有人负责？（因为原来负责的人离职后，还没有招到人来，也没有人去负责这些事情，导致容易出错）
（针对第2点的追问）
- 为什么用户容易忘记？（因为用户拥有的用户名太多了，记不了那么多）
- 为什么记不了那么多？（因为人的记忆一般适合记住7个词组，互联网发达阶段，一个人拥有的用户名可以是各种各样的）
经过一番的追问，往往就看到了问题的本质。
实际上分析需求的过程在挖掘需求时就应该有过粗略的分析了，甚至也有很细的分析才将需求提出来的，而那些经常提需求需求几乎不通过的情况应该是没有经过深入的分析就把需求提出来了。
（Ps：n个W +n个H这些分析法，可以灵活运用）
有了分析方法，可是分析到何种程度会最佳，这应该是取决于对需求的认知程度，认知的成熟度往往取决于能接触到的信息的广度和深度。所以加油吧……
4、确认需求（需求决策）
分析需求之后，是否要去做该需求以及大体如何做，就得做出决策，这是需要团队成员以及领导确认的，尤其对于重大一点且比较犹豫不决的需求。如果想要做出正确的决策，除了分析需求的工作要做到位之外，也可以参考《决策与判断》以及《卓有成效的管理者》中提到的决策5要素，这样也许可以更深层次地理解决策进而对快速地做决策有一点帮助。
5、执行需求
在这一阶段，需要将功能需求定义清楚，输出原型文档，原型文档评审，原型文档交付ui设计师和开发同事。
需求确认要做之后，就得描述清楚通过什么办法来满足该需求，也就是功能需求定义阶段，定义好流程、逻辑规则、功能规则、入口，对于b端复杂产品，逻辑规则特别重要，有的也真的特别复杂，很烧脑。输出文字描述版本，将文字版本找技术负责人员交流一下（本身对技术很了解就略过），在分析需求以及确认需求阶段都是一些比较大体的东西，在执行阶段就得做得很细可能会出现一些之前没有考虑过的东西，所以在输出功能需求定义文字版本后，最好交流确认一下有疑问的点以免后期反复修改，没有很严重的疑问后，可以进入画原型阶段了。
进行功能需求定义时，容易出现的问题是考虑不全，甚至没有实现这个功能的逻辑闭环，以及对于边界条件定义得不合适。在分析需求的时候就已经在运用wh分析法，一般是大体的分析，在进行功能需求定义时，也同样可以运用wh分析法，要深入，就可以实现一个功能的逻辑闭环。以下是大体步骤。
- 按照wh分析法，先找到相匹配的解决方案（分析需求时应该已经有了）；
- 思考如果用户不按照所提供的方案的正常路径去使用产品，会有哪些异常，也就是异常预估，每一个环节都可能出现异常。这可以从用户、产品逻辑链条去分析每一个环节的异常，对于有些功能是可以一起分析的。
- 针对预估出来的每一个环节的异常，给出对应的解决方案。
- 从以上三点考虑对一个功能需求的定义就会比较全面，综合信息并且再次思考需求本身以及从产品设计比较通用的原则尤其体验一致性的原则、成本、公司资源等再去做评估，会减少后期的修改，然后从评估结果中考虑删减以及排优先级。（这个事情往往在评审的时候会进行）但是作为产品在评审前心里最好有个底。
原型画完成后预约时间就可以进入原型评审阶段了。在评审前能对一个功能做较全面的定义以及评估，就不至于在评审时被各方提出的一些问题问得哑口无言。所以尽量形成一个系统的视角层层深入去分析并思考对应的解决方法，这样评审也不会太难看。
评审结束后，一般情况下还是要修改一些地方，最好对评审会议做一个记录让主要负责人员都确认一下，然后提交原型给ui以及开发同事。
6、跟踪需求
产品提交原型后算是完成一个需求任务，但是还有任务就是要去跟踪ui设计、开发，及时拿到反馈进而沟通，开发基本完成后要去验收，等待测试上线。这些按照路程走，前面工作做到位，是不会有太大问题的。若出现了问题，5why分析，哈哈哈~上线之后，还有注意对客户、用户反馈信息的跟踪，留意分析各种数据。
7、完善需求
需求总是源源不断的，那就想方设法去完善。
以上是个人的总结，可能还有不全面不到位的地方，欢迎交流。
作者：一篇森林
来源：人人都是产品经理
