一、观念转变
1、以产品思维，代替项目思维
2、以成本意识，控制免费需求
3、以甲方视角，消除歧义和不确定性，避免返工
二、需求登记
每天的新需求，应登记在册，有利于我们分析工作量在哪产生
需求登记不要每人一个风格，应统一模板，提高需求录入效率
比如说，报表的需求模板，遵循以下格式：
统计条件：下单起止时间、代理手机号、代理区域
统计口径：指定统计条件的订单数据，统计已完结订单的实付金额（不含优惠金额、运费、已退商品）
展示字段：所属区域、代理名称、统计开始时间、统计结束时间、累计业绩、订单笔数、会员个数
三、需求保持纯粹性（遵循第一性原理）
合理的需求，符合“短平快”的，主题明确，工作量相对少（两三天就能完成）
好处：工作容易分配，开发愿意接受安排，需求简单，沟通快捷
不合理的需求，逻辑臃肿，不易拆解，开发也容易推诿，涉及多人协作，无人负责，增加沟通成本。
四、需求五要素
需求的理解偏差，往往是我们不知如何表达导致
需求应尽可能包含五要素，描述背景和应用场景，价值和交互逻辑，异常情况等。
注意：
需求保持纯粹性，一个功能对应一个需求点，不把多个需求，打包成一个庞杂的需求，不包含技术方案
好处：我们把需求分给不同的人，同时去做，而打包在一起，复杂度增加，也不利于分工。
1、问题还原
【谁在什么情况下，遇到什么问题？】
引导需求方描述问题而非解决方案，成为沟通组织者；提需求前，先明确核心问题是什么？
“问题”不是“用户要一个…功能”，而是“用户在做…时，为了达到…的目的，需要通过…功能完成”。
2、期望方案
【希望通过新增/优化什么功能解决此问题？】
3、应用场景
【具体是在什么场景下需要用到该功能？】
4、实现价值
【功能实现后，带来哪些改变？对业务产生价值？节省多少人力？提升效率？】
5、相关截图
【提供期望方案的功能参考截图】
6、正确示例
（1）问题还原【谁在什么情况下，遇到什么问题？】
初吻的代理在H5扫码出货时提醒，“您没有该商品或者商品已出货”
代理并不清楚到底是没有该商品，还是已经出货了
（2）期望方案【希望通过新增/优化什么功能或其他方式来解决此问题？】
代理希望能调整文案，提示“XX商品已出货”以及“您没有XX商品”
（3）应用场景【具体是在什么场景下需要用到该功能？】
代理在扫码出货时，可以清晰了解商品状态
（4）实现价值【功能实现后，带来哪些改变？对业务产生价值？节省多少人力？提升多少效率？】
节约代理了解商品情况的时间
（5）相关截图
7、错误示例
（1）问题还原【谁在什么情况下，遇到什么问题？】
PDA扫码退货增加限制，已经领取积分的不允许退货
（2）期望方案【希望通过新增/优化什么功能或其他方式来解决此问题？】
希望扫了积分的货不能退回来
（3）应用场景【具体是在什么场景下需要用到该功能？】
PDA扫码退货
（4）实现价值【功能实现后，带来哪些改变？对业务产生的价值？节省多少人力？提升多少效率？】
避免扫了积分，货还能退回来，不用手动去查验处理
（5）相关截图
错误示例的问题点：
业务场景描述不清晰，不明确，比如退货场景中，货品是已经运回，还是没有运回？
如果货已经运回，扫码又不正常退，该如何处理？如果货没有运回，怎么扫码？
五、需求边界
需求原则、需求边界
1、需求原则
一个需求解决一个问题，保持需求的“原子性”
确保一个需求被完整执行，或者完全不被执行
2、需求边界（问题边界）
保证需求对应问题的纯粹性
问题归因：推论客户需求原因，细化业务场景，具体遇到什么问题，希望获得什么帮助？
结构归母：判断问题产生的根本原因，需求的真伪性，通过什么合理结构解决用户问题
六、需求管理
需求定义、分类、来源
1、需求定义
需求是客户希望通过使用某一功能解决某问题或达成某业务场景下的诉求
它是目前还未实现的功能或因功能不完善而无法满足的需求
（1）示例1
客户（圣霓兰）的门店包括社区店，商场店等。
不同门店希望在扫码活动中拿到不同的奖励，支持对门店发放不同类型的奖励（问题还原）
客户希望新增对指定门店发奖的策略组件（期待方案）
达到精准化营销的扫码活动（实现价值） 。
（2）示例2
客户（初吻）希望在不同的节日活动，让网店显示应节日的个性海报（问题还原）
让不同的代理，可以装修自己的网店（期待方案）
实现千店千面的诉求（实现价值）
2、需求分类
（1）某客户定制化需求
（2）新增通用功能
（3）通用功能优化
（4）性能优化
（5）交互优化
3、需求来源
（1）已签约客户需求
（2）意向客户的需求
（3）研发的需求
七、需求跟踪
需求状态、需求跟踪
1、需求评审
（1）需求统一录入TAPD，不要靠说，要写。
简单的，能说清楚的，紧急需求可线下沟通处理；
（2）评审要设置时间期限
若需求超过1个工作日还未评审，需求提交人和评审人最迟次日完成评审；
（3）需求评审的争议要及时协调
若需求提交人对需求评审结果有疑义，由【项目总监】参与协调沟通；
2、需求评审的状态
（1）待规划
经过评审，需求合理，列入计划排期。
（2）已立项
需求已完成立项，待开发。
（3）开发中
该需求正在开发中，待上线。
（4）已上线
需求已开完开发，并已发布上线。
（5）已拒绝
经产品经理评审，判定此需求不合理。
3、需求反馈
（1）提测通知
需求完成开发上线后，项目经理需当天将信息同步给【项目总监】，并通知测试查验。
（2）变更通知
如有特殊情况需要变更需求评审时定的时间，
需提前一周与需求提交人沟通确认，
经协商后在TAPD中记录变更原因及变更后时间，
同一需求变更次数原则上不得超过2次。
（3）延期通知
若需求未在约定时间实现，或需求上线时间变更次数超过2次以上的，
需求提交人应当与【项目总监】反馈，并协调资源，限期给出解决方案。
八、需求区分
1、怎么区分需求与BUG？
（1）需求
是描述一件事情，作为什么用户，希望如何，这样做的目的或价值何在。
需求需要构建用户角色，描述使用场景，定义用户问题。
（2）BUG
是程序中隐藏或被发现的功能缺陷或漏洞。简单说就是使用软件时，出现的错误问题。Bug需要描述重现的步骤，环境及其他因素，以便定位问题。
（3）区分
需求是有与无，好与坏的问题。Bug是对与错，是与非的问题。需求先于产品，BUG后于产品。
2、需求思考
提需求前，项目经理需思考3个问题
（1）需求背后的问题清晰明确了吗？
充分有效沟通才能解决问题
通过主动对接客户，用专业知识引导客户明确问题，确认客户想达成的目标。
比如：问需求方，“你遇到的问题是什么？”，是操作习惯问题，还是现有的产品无法满足？
先引导需求方，把问题场景聊出来。
（2）已有产品功能确实无法满足需求？
（产品功能就是用户操作后能够解决某种需求而设置的入口）
首先查看产品手册，与产品经理沟通，了解产品结构与对应功能
思考各模块的用户价值，了解各个模块商业价值，深入挖掘已有的功能是否能扩展，
判定现有功能是否真的无法满足需求
（3）该需求真的紧急吗？
需求方往往觉得当下问题都紧急，恨不得需求今天满足，明天上线
但资源永远是有限的，无法同时满足所有的需求。
所以，对需求优先级划分，目的在于实现有限资源高效利用
根据需求的优先级，需求价值高的优先满足。