这篇文章是软件工程系列知识总结的第四篇,前面的几篇文章聊了软件工程的基础理论和项目管理相关的知识。这篇文章,我会将软件工程中关于需求分析相关的知识进行总结梳理,并以自己理解的方式进行阐述。
做技术的同学对于需求应该是既爱又恨,一方面软件产品的源头来自于需求,另一方面日常工作中面对需求的不明确和经常变更,只能无能狂怒。日常的工作流中,需求分析和需求评审的结果往往决定了这个版本交付质量的好坏。
需求的来源有多种,有用户建议、客诉工单,也有通过对市场调研和判断,得出的一些结果需要进行验证。需求分析是一个过程,这个过程主要有如下三个步骤:
举个例子:
用户客诉:有用户反馈某电商APP下单不方便,给了差评; 挖掘需求:用户常用的支付方式是支付宝,但该APP暂不支持; 解决方案:应该支持多种支付渠道,比如支付宝、微信等支付渠道; 筛选验证:调研活跃和潜在用户使用占比较多的支付渠道,按优先级去接入这些支付渠道;
产品需求的来源不是单一的,而是一系列的需求来解决用户的痛点,不断迭代不断改进,从而做出更好的软件产品。完整的需求分析流程应该是一个闭环,整个过程需要迭代进行,如下图:
收集需求:对需求进行收集整理(头脑风暴、用户调查、竞品分析);
分析需求:分析用户需求,挖掘真实需求(表层是支付宝支付,深层是多支付渠道,底层是便捷的购物流程);
需求评估:对需求进行评估,筛选掉不可行需求(成本、可行性、风险和收益、需求的紧急性和重要性优先级);
需求设计:针对需求提出解决方案,变成产品设计方案(草图、原型图、MVP产品、演示Demo);
验证需求:验证产品设计方案是否可行(产品验收、灰度发布、A/B测试);
日常工作中大家都会进行需求评审,这个时候最理想的情况是产品掏出原型图和PRD告诉大家,这里要什么那里是怎样。当然,有时候产品也会甩出一句话:“这个需求很简单,怎么实现我不管”。对于这种一句话需求,技术同学特别是研发和测试同学相信都很恼火。
不明确的需求和需求变更,是大家最不待见的情况,这些问题也会导致研发效率大大降低,进一步影响线上交付质量。所以前期需求阶段就确认好要做的事,后期大家的效率和交付质量往往都会比较好,这就有赖于做好产品原型设计。
原型设计简单来说就是将抽象的需求具像化为可视可见可理解的过程。
要做好原型设计,不单单是设计页面,而是要综合考虑很多因素。主要的考虑点有如下几项:
产品原型设计的过程,可概括为四个部分:
产品意识本质上是一种思维逻辑,即能否站在用户和产品角度思考并解决问题。主要包含如下几方面:
技术同学要培养产品意识,可以从如下几方面去实践:
需求变更在日常工作中特别常见,频繁的需求变更会带来很多问题,比如:
应对需求变更,常见的解决方案有如下几种: