做业务产品时，如果接到了含糊不清、关键信息不全面的需求汇总，你会不会十分头疼，甚至不知道如何下手？而面对同样的难题，作者进行了思考，并给出了建议。
long long ago，我还很天真地以为PRD都是产品经理汇总好的业务需求，我再进行下一步的需求分析，理清主次功能、主次流程并转变为可执行操作的产品界面……
事情并没有那么简单……
交付性的项目产品，产品经理往往是这么一句话：
“这个产品我们以前有个类似的平台，就做一个类似这样的平台产品，多了几个XXXX功能，然后原有的xx流程去掉，有问题再问我”
许多交互/UI在接需求时也会遇到这种情况，是不是感同深受？
每次有新业务就有新产品设计的我，意识到并不是每个需求方都有能力将需求描述的符合我意。甚至于做产品设计时，每一个平台的行业、功能、业务需求也不一样，很多设计规范和组件并不能复用。我之前也跟很多做业务向设计的小伙伴讨论过，设计价值在交付性产品中很难被界定，而且设计环节在整个开发流程的夹缝中很难做人。
可能我们理想中的开发流程，如下↓↓↓↓↓
理想状态：大项目，长周期
可以根据功能迭代排期，合理安排产品开发进度、设计进度。低保真原型还原需求是否合理，高保真原型还原功能表现是否合理，并进行优化体验。除非是企业级/工具类产品做大版本更新，不然很少会有这种情况出现。
但实际遇到的项目流程是这样：
常见状态：大项目，短周期
看到这个流程是不是很懵逼？
这种流程结构，交互在进行产品设计、开发进行底层架构时都很痛苦。交互需要把整体产品的功能用低保真表现出来方便测试和底层架构；然后再根据功能优先级和排期，与产品、视觉一起对核心功能进行再设计和细节功能优化、删减。
近期项目真的是经历了一场大型砍功能现场：
合同里没有这个小功能，砍；
前端实现不了，砍；
底层没架构，砍；
时间来不及了，砍；
项目按照复杂需求设计的功能流程，因为开发周期的缘故砍了很多功能，导致甲方对最终产品反馈说使用有点复杂。那这时我能有什么办法？我也想有用户体验，我也想优化功能和改善需求，但基于现实，也只是我想……
当然还有这样的流程：
常见状态：小项目，短周期
这种流程由于项目的产品需求较为简单，底层框架逻辑可以复用，整体开发流程会压缩的更短，甚至于会有“交互和视觉”职能杂糅的情况。
根据项目和需求的“成本预算”去进行产品设计、功能设计，不能本着“体验最优”去考虑整个项目开发。既然不能要求每一个项目的需求方都能输出较为精准的需求，保证后期设计输出无误，不会更改需求和设计增加开发风险。身为“交互狗”只能尽量精准的进行需求分析，力求需求评估时保证产品设计方向的正确，以下也算是复盘怎么对接、思考B端业务需求的几个环节，可以根据不同项目开发的时间成本择优进行需求分析和功能设计：
01 明确目标
曾经有个产品经理给我一张原有平台的截图，在图上标注上“增删改查”的内容，让我做一个新的后台管理产品，说实话接到需求的我当时就懵了。我很难一下子明确产品的业务目标、产品目标，甚至是目标用户，只是简单的对接了一下业务流程，就丢出来这么个需求信息量比较太少。
需求方甚至会觉得做一个后台产品很简单啊，我们有现成的，我的诉求表达清楚了啊。
确实，对于业务性产品而言，业务是带来利润的，产品只是一个辅助的工具，好不好用不打紧。
但是在执行侧下游的同事并不能完全了解需求方背后的业务逻辑和商业诉求，如果连需求都描述不清楚，来回沟通返工设计的成本太高，需求变更带来的开发代价也太高。
因此，设计前期，做需求分析前最重要的就是明确“项目背景”的内容：
01 明确项目目标
优先级：★★★★★
首先明确这个项目的大小（产品需求量+项目成本+时间成本），如果是短周期小项目，产品功能不会过于复杂，肯定是优先满足合同书里面明确的基础需求。毕竟开发周期短，有短开发节奏的解决方案，长开发周期有长开发周期的解决方案，部分优化体验功能在项目中可以适当削弱，满足常规基础功能即可。
对于项目整体目标是提升业务效率、提升产品易用性还是满足招标需要的从0→1……一定要始终谨记项目目标，这可是影响整个产品的“首要纲领”。
02 目标用户与业务之间的利益关系
优先级：★★★★
在对接快速需求时，由于不同的业务、项目、产品经理，大家很容易忽略这个平台使用者与业务流程之间的关系（即业务流程），以及相关的载体表现（APP还是web）和传递过程（如信息流、数据流、资金流、权限功能）与业务之间的关系，这其实会影响到主次功能的流程逻辑是否符合目标用户的心智模型（目标用户的业务逻辑关系会映射到使用产品时对功能逻辑的预期）。
03 确定项目涉及的平台和技术范畴
优先级：★★★
需要设计的功能平台较多时，肯定需要后台类产品管理功能、引擎、数据等，针对不同的项目平台需要积累对应的设计规范和组件来提升效率，许多功能虽然业务不同但也有基础的共性操作。
例如后台管理类“增删改查”“审核状态”等都有类似的异常情况可以通用，确定技术范畴也会影响功能提出后，该项目的开发人员能否实现。
04 按照时间节点来进行把控
优先级：★★★
设计环节在整个立项周期中，属于压缩时间周期最短的一环，在既定时间完成功能需求，要根据整个团队的能力评估当前的解决方案是否是最优方案，因此在时间范围内尽可能提出多个方案供团队评估。
05 甲方
优先级：★★★
为什么要在这里把“甲方”列举出来呢？
在既定时间内甲方会根据原型提出功能是否合理，可能会导致功能原型返工，耽误后面开发流程进度的情况。因此，在分析团队情况后，决定是否满足甲方提出来的非合同标注的需求时，需要打个大大的感叹号，会增加团队的开发成本！至于需求满不满足还是要跟产品、项目、技术讨论之后决定。
理清以上的内容，基本就能清楚项目的业务逻辑如何影响产品功能，可以进行下一步需求分析了 。
02 理清功能
为什么在上一part我没讲“产品定义”？
能够一两句话讲清楚这个产品是在干什么，对于2B产品而言，很多都是满足业务目标的产品目标解释，有时不太能明确知道产品的主次功能，明确的大都是业务的解决方案和利益相关者的描述。
因此具体的需求分析通过以下几个模块来明确⬇⬇⬇
（大家也可根据自己业务需求自行补充）
01 首先要明确产品的需求是怎么来的？
可能是业务流程有问题，可能是用户有某些痛点没有得到解决，也可能是当前数据反馈出来这个功能不合理……这些才是我们需要解决的“痛点”（即需求）。所以在还原需求时我们可以借用“问题描述”来拆解需求到底该怎么表达，以及我们要做一个什么“功能”来解决这个“需求”；
问题描述：__（谁）__在__（时间、地点、情景）__，遇到__问题；
功能描述：要为__（谁）__做一个__功能，从而实现__指标提升；
我们都知道在做功能时要还原“需求”的来源，即场景/业务还有目标人群。
拿我之前做的转写功能来讲，市面上具有转写类功能的产品，多为笔记类产品，能够满足日常办公/备忘录笔记即可，做的比较好的产品可以“转写+翻译”功能同时实现。
但我们项目里基于功能分层以及商业模式考虑，需要分开处理，因此“转写”为一个大功能（包含3个小功能），“翻译”为一个大功能（包含2个小功能），这就是同样的“功能”由于“需求”还原不同，带来具体解决方案不同的做法。
03 竞品分析会告诉你这类“需求”怎么解决
同一个“功能”对应的“产品目标”不同，带来的解决方案也不同。而竞品分析除了可以理出“功能”具体在界面的信息架构和层级关系的展示方式、信息层级和小功能点有哪些外，还可以分析“功能”带来的用户操作行为与功能目标，拆分功能与产品结构之间的关系就能知晓这是针对什么“需求”的解决方案，参考产品的定位和发布公司，也能大概了解其背后的竞争格局、推广策略等。
03 产品差异化
交付类产品一般不太会进行产品差异化分析，这需要对行业、市场、人群有精准的定位和细致的区分。牵扯到to B一定会有大的业务变动和商业模式的变化，产品/项目的目标才会发生差异化的变更，这时一般都是我们认为需要进行改版来满足这个“大目标”的时候。一般交付性产品到2.0的需求分析就已经足矣，可以出具较为符合业务需求的产品功能并提供解决方案（产品原型）了。
由于在我经验范围内，经手的这些交付性项目需求分析基本也就到2.0左右，所以有补充的内容也可以根据自身的业务情况/需要进行更加细致的补充。
