客制化需求评审流程
2020-03-17 11:23:39 1 举报需求评审
作者其他创作
大纲/内容
和客户明确需求，需求录入进需求列表
产品部通知相关销售，通知客户
需求优先级列表(Excel)&需求文档(JIRA)
客户需求通过邮件正式发给车晓产品部
<技术部>
Y
End
销售部给出大客户服务名单，需要考虑当前业务量和潜在价值，此部分开发需求由产品部直接对接，对外身份为技术团队；非大客户产品部不进行对接，由运营技术支持部做系统答疑和需求拒绝（如技术支持部对用户需求认为对平台有较大帮助，可提出需求建议）客户主要集中在大客户：需求由产品部直接接收。
评审会评审需求
技术部排期开发
N
需求分类，排列优先级，完成需求文档
<客户>
通用功能?(平台优化/功能补充)
需求分类：Bug需求、接口对接、功能优化( 包括：工单管理、)、本地化需求，扩展需求需求标准（通用产品匹配）：高度匹配、中度匹配、低度匹配、不相关需讨论部分：招标前需求的满足规则，完全满足 or 根据实现难度判断 or 根据产品价值判断需求邮件会提供模板，并给销售部、其他部门做相应的培训
<评审委员会>
技术部 和产品部讨论需求实现
客户广义包括内部的部门，包括：销售（售前需求）、供应链、安装、客服、测试、技术支持部客制化需求评审会，对应需求迭代，每两周举行一次，由产品部召集（如没有需要评审的需求，委员会停止一周）；评审委员会成员包括：刘总、张总
<客制化需求评审流程>
产品部提供非技术解决方案
需求邮件：需求目的、提出客户和人员、功能描述
<产品部>
Start
功能上线
需求丢弃
观点一致
同意开发
0 条评论
下一页
