产品需求返工的问题由来已久，也是很多小伙伴们很头痛的问题，在上一篇《产品效率的提高，关键在于需求返工率》的文章中提到“产品效率的提高，关键在于需求返工率”，那么如何最大程度的降低需求返工率是这篇文章将讨论的问题。
需求返工的问题主要出现在需求的收集分析、概念架构的设计、系统逻辑的设计、开发复杂度的考量、研发周期的限制这些问题上，下面就这几点综合讨论下。
一、需求收集分析
需求的收集分析，可以拆分为收集和分析两部分,在这里容易造成返工的点主要是：
未能对有效需求和无效需求进行分离，致使工作从一开始就偏离了正确方向；
收集渠道过于片面，造成信息与真实状况偏离遮蔽了事实的全貌，样本来源太单一无法印证需求导致需求错误；
未能结合产品定位，抛开用户画像和使用场景谈需求和耍流氓其实并没什么区别；
不符合企业战略规划，产品是为企业战略做支撑的，需求偏离了规划就是不符合内部需要的产品；
脱离了产品现状，每个产品阶段我们都需要有优先级的去考虑需求的排期和版本的迭代，在不合时宜的位置提出需求其实也是一种无效需求。
说完常见问题环节，下面来说说相关处理方法。
1. 需求收集
首先是收集，在上一篇文章中提到需求主要来源于外部和内部两种路径，在收集需求时我们需要考虑的是收集哪些用户的需求，这就要求我们有一个用户画像；
其次是需要收集哪些场景下需求，这就需要场景地图，用户画像和场景地图我们必须做到有主次大小之分，否则很可能出现需求的分布位置在用户和场景边沿交集中。
基于这用户和场景我们对收集到的需求进行核心交集处理，这一步能够相对准确的圈出需求内容，然后对得到的需求进行“拓展需求”的筛选，因为偶然有一些需求是在交集之外却也很有价值，时间允许的情况也是建议过一遍的。
例如我们做女性彩妆的，偶然有一些男性提出的需求，你以为他们就该排除在性别之外吗？其实女装大佬们需求还是很大的。
当完成初步需求筛选后，我们需要基于现状对需求进行优先级整理，首先考量的是产品当前状态下最迫切的任务是什么，例如起步阶段面对非急需的大型系统需求我们就会考虑往后放一放，而能够快速开发且带来用户增长和存留以及转化的会考虑优先解决。
其次优先解决大面积用户的基本需求，所谓的基本需求就是这需求不解决人家都懒得理你了，大家都不理你了难不成咱们去为少量用户重新定位？
这不现实，毕竟不到当前定位的生命晚期谁也不愿意重新定位用户群。最后是对需求的开发量和版本规划的评估进行综合排序。
从上述不难看出，需求的收集从来不是一股脑的堆积，而是需要产品人员去按照一定的方法和规律来整理和筛选，最后得到一个合时合利的有效需求集。
2. 需求分析
有效的整理需求仓库能够从起点就避免掉无效的产品劳动！
收集完了需求，接下来就是需求分析，在开始说分析之前需要提到的是“需求分析从收集需求时就一直在进行，它脱离需求收集而单独拿出来是不具备任何效率意义的”。
关于需求分析主要分析哪些内容，宏观上我们拆分为两部分，分别是业务分析和开发分析。
业务分析是基于产品定位、企业战略需求、产品周期规划这三方面，同时这三方面需要综合并行考虑，而不是串行流程过滤，基于定位考量能够有效控制产品性质的稳定和业务的精准，周期规划是产品成长的规律偏离可能就会造成产品的无效成长和冗余；
至于符合战略需求就不多说了，咱们要做一个社交电商你却做了个微信，相信老板会感谢你的。
（1）业务分析
那么，如何做好业务分析？在做需求分析之前我们必须先弄明白产品定位、战略需求和周期规划。
很多产品在研发时根本就没有过定位的思考，而是想到哪做到哪，这就导致产品功能系统越来越庞大臃肿，业务效率越来越低，程序逻辑越来越杂乱交错，最终形成一滩烂泥，动刀的代价太大只能放弃。
因此我们必须对产品有一个清晰的定位，这里不是指产品的使命定位而是生命周期定位，从定位中我们才能得到阶段任务的方向和范围，而定位来源于用户、场景、数据的分析，再加上企业对它的期望即战略需求！而不符合定位的需求，随着时间的推移必然会越来越凸显出冗余感。
接下来再说说如何理解分析战略需求，其实这是一个相对宏观的东西，但是一个务实的战略需求必然清晰的指明需要解决的问题范围或方向而不是某个精确的问题点，而需求在战略考虑上必须包含或交集于它；
在这个环节常常遇到的问题是战略太模糊甚至空泛，这时候我们需要做的是与高层详细沟通以及精确细化战略，磨刀不误砍柴工。而战略分析主要是指提炼出业务方向和范围，明确出具体涉及的系统和架构。
最后是周期规划，这个规划中主要考虑的还是既定规划和需求的交集，以及版本设定的优先级和逻辑前后置问题，常见问题是经常出现做好的需求发现开发周期过长或者前置内容未建立，以及无后续考虑。
（2）研发分析
符合业务分析后就是研发分析环节了，在这个环节中我们要考虑的就包括需求的开发难度和周期、系统架构设计和调整、需求逻辑转化、数据需求和桥接等众多极度理性和逻辑的事情。
这里涉及到的处理方法我们综合起来主要是，面对新的调整如何让现有机制尽可能的少做调整、对新增数据进行闭环设计、对删减机制做好延伸测评、对新的系统尽可能的组件化、对核心用户体验做到足够考量！
首先如何尽可能少的触碰现有机制，这主要是两个方向考虑，一方面是在之前的工作中就充分的考虑到系统和机制板块之间的解耦涉及，在做逻辑和数据架构设计时尽量秉承着组件式涉及的思想，最大限度的保持各个中大型功能系统之间的独立性。
另一方面是将新的逻辑需求避免在现有系统中做零碎处理，以便减少边缘和孤立机制点的存在，同时尽可能使用通用模块降低架构的零散性提高通用模块的集成枢纽意义。
例如，对于复杂的订单系统我们通常会设计一个独立的订单管理枢纽，各个系统的订单增删查改均会从这里经过，这对整个产品来说就是一个集散点，基本管理和监控在这里都能等到数据和功能支撑，而不必每次涉及到订单就要去涉及和开发一个新的机制;
同时如果订单系统发生大的变动我们只需要在订单系统内部调整即可，其他系统我们在枢纽位置做好兼容处理就完事了。这样的思想在面向对象编程中有个非常类似的概念叫单例模式，有兴趣的小伙伴可以去了解下。
上述订单的例子其实也解释了闭环设计的概念，在这里补充说明一下。闭环的设计关键不是封闭，而是形成完成的循环，例如你增加了一个数据的录入就该考虑到它的整个增删查改该如何处理，而不是放在那就不管了，不然它就是一个冗余数据了。
（3）延伸评测
关于延伸评测，相信了解测试的朋友都不难理解它的必要性，在需求设计中我们不是做一个机制就只看这一个机制，还要看到它涉及到的其他相关机制，这就是往包里放一件东西和在电路板上增加一个元器件的区别，前者是容器概念放进去即可，后者是机制概念需要融入其中并与原主体结合在一起成功运行。
在这个环节我们在常遇到的返工问题就是，新的机制未能与已有系统融合甚至产生各种错误，因此在分析需求时首先必须足够了解原有系统机制，其次是最大限度遍历出所有牵涉的机制，并做好后续兼容考虑。
最后是核心用户体验，一句话说明：任何抛开用户画像和使用场景的用户体验设计必然是空中楼阁，而需求设计离开了用户体验只是一堆粗糙的积木。
总结下来其实所谓的需求收集分析，无外乎结合内外对已知的需求进行有效化、优先级化、逻辑化、数据化以及版本化！
在上文中，相信有不少朋友发现一直未提到另一个核心概念——真实需求。
这个问题在上面文章中其实隐晦的有所说明但不全面，更多的是关于真实需求排除法方面的，而真实需求其核心方法其实是用户同位心，这里就不多做讨论了，以后会单独写一篇关于真实需求的文章，这里主要还是说一些基础的需求管理。
二、逻辑架构设计
下面来说说许多不擅长后端的小伙伴关心的问题——逻辑架构设计。
在上面的内容里以及开始阐述架构设计了，这也是需求整理分析后的下一步工作。
逻辑架构，顾名思义是有逻辑的架构。许多产品在设计稿阶段其实就已经出现了很大的逻辑问题，这就导致设计稿连讨论审核阶段都很难通过，就更别说后续的技术和测试评估了。
在开扯之前先说一句话：“那些对编程一无所知的小伙伴们，可长点心吧！连养猪的理论都不知道怎么养的好猪？”。
生活里确实有不少朋友问过我，为什么概念结构图做的那么好，为什么我的需求设计基本不返工等等问题，答案其实无外乎“逻辑通了吗？”、“耦合性问题考虑了吗？”、“编程逻辑你知道吗？”等等，
对于一个需要将开发需求文档直接给到技术人员的产品经理来说，逻辑是硬道理！在产品工作中需求返工最大的触发点就是逻辑架构环节，而顺畅的逻辑、明确的架构、精准的功能投放、优秀的页面交互、清晰的数据结构将决定着一个架构设计的质量.
那么如何设计逻辑？首先我们需要对需求本体进行解构，一个需求会生成那些系统板块，每个板块需要什么机制，每个机制需要那些功能，每个功能牵涉那些数据？
然后，每个数据作用于哪些功能，每个功能需要哪些界面，每个界面如何交互？最后对界面进行整合调整，提交设计。
说起来简单但每一步都是一堆思考，首先需求解构这就像雕刻时知道我们将会出一个什么东西；然后板块划分这就是知道这个东西大概模样，即雕像是猪还是人有了具体定位；
再进行机制拆解和梳理即在知道这个雕像是人后在脑海中呈现出各种人类的形象，以支撑下一步设定；
再然后设定功能和数据，来清新出这个雕像的性别、职业、年代等细一步的形象；接下来需要哪些界面如何交互，就是确定这个雕像形态和外观的样板；最后提交设计就是等着设计具体样子和着手雕刻了！
例子可能不够恰当，但这就是逻辑思路，面对需求最可怕就是没思路不知道如何拆解，从一开始就把需求一滩化无从下手，只会让后续的功能无法进行。
下面来具体说说如何制作逻辑架构，首先我们必须在通过脑图或者其他工具将单个需求拆解开来能够清晰的看到其包含的业务线和机制；
例如，用户账号登录系统其包含前端登录交互和后端登录系统，登录前置是注册，后置信息管理；注册需要包含验证和录入，登录需要验证正确与否和行为管制（异常验证），信息管理还包括前后端的编辑、新增、验证等等；
通过“需求->概念->抽象->归纳->筛选->具象->逻辑”的步骤等到一个树形架构概念图，然后对这张图各个分支节点进行逻辑规则的初步填充，那么我们就能看到一个相对具体的功能系统的逻辑结构了。
在这个环节中我们的主要问题点在概念抽象环节，许多朋友不知道如何提取需求中的逻辑元素，这一点需要结合功能逆推的方法去思考，需求最后提供的功能是什么，这样的功能需要什么机制和数据支撑，这些数据和功能如何整合等。
所以如果你此时在吃饭且噎住了，请相信我不要妄图再吃一口来堵下去，不然可能你看不完这篇文章，而你需要的是另一个方法——喝一点水来疏导。
同理，在逻辑梳理时不要死命的怼需求原案，适时适量的从结果逆推往往效果更好。
另一方面，在逻辑设定时应提前与技术口头上就需求构思进行沟通，提前了解开发方案能有效避免许多不必要的逻辑与技术方案的冲突。
其次在数据结构设计上也应该与技术保持沟通，对于现有数据模型和逻辑有清晰的认识做到心中有数，这样才能有效避免冗余。
剩下的就是向下兼容的逻辑考虑，许多系统我们在第一设计时其实只是一个核心版本的架构，那么对于后续的叠加就需要做好充足的评估，留好预置的对接点避免下次版本设定时出现历史返工。
这个环节主要是数据和功能前置，以及回避后续系统的逻辑冲突，即耦合问题。
逻辑架构总结起来就是其实也是一句话：“任何庞大的需求体系都必然是由各种细小功能机制组合而成！”。
我们做架构设计时无外乎就是，将需求拆解转化成功能然后将功能组装成系统，至于原型界面在你能将逻辑整理规划好之后，它们只是顺带的。
三、开发复杂和研发周期
最后，关于开发复杂度和研发周期，懂程序的看着自己的需求已然心中有数，不懂程序的应急方案是和程序员搞好关系，不至于估期时忽悠你，询问时懒得理你，长期的建议是花点时间学习下编程达到能够写个简单的小程序就差不多了。
同时，也给不懂编程和不够精通编程的小伙伴们以中肯的建议，小功能很多时候的开发量绝对不小，一定要秉持着兼听的本份仔细和技术沟通，不要过于个人武断，四十米大刀可不是开玩笑的。
总结
关于减少需求返工的问题，主要就是有效的需求收集、准确的需求分析以及逻辑畅通的架构设计，对于需求审核中遇到的问题应勇敢面对、诚恳改进，毕竟开发一半出现问题再整体返工咱们可能要面对的就不是返工了。
