虽然国内众多创新型企业的产品研发体系日益成熟，研发过程逐渐走向规范化，但对于研发前端的重要输入—产品需求管理均较为薄弱，很难真正实现以市场需求为驱动的产品创新模式，对于产品的需求收集非常零散，信息也不充分，不足以支持产品决策。共创力咨询最近在几家企业调研时发现，市场、销售、研发等人员在提交需求时存在普遍的问题：
- “一句话需求”普遍存在，尤其是销售人员和市场人员在描述客户需求时过于简单；
- 需求在提交时的信息不全，信息失真会极大的影响后续的分析处理，造成无效的反复沟通或错误的理解；
- 很多需求提交时，提交人给出了对未来解决方案的规划，但缺乏对客户原始需求的描述。提交人并非解决方案的专家，很可能不是最佳的解决方案，缺乏原始需求的描述也使得RMT/RAT对客户的本意把握不清；
- 缺乏产品需求相关市场及客户信息：如使用环境等；
- 缺乏对竞争对手的分析和比较；
- 缺乏对产品需求本身的价值描述，比如需求能够带来多大的价值，不实现该需求会造成多大损失？
- 多个需求入口缺乏统一的模板和平台，造成临时需求较多，大部分都通地通过电话和邮件完成需求的传递；
- 一次提交多个需求，需求难以分解。
针对以上问题，结合咨询帮助数十家企业成功导入需求管理模块咨询的经验，我们总结出在提交需求时要遵守的四大原则：
1. 详细的需求描述：
①需求的来源信息
②客户对需求的原始描述
③现有问题描述，而不仅是解决方案的描述
④需求描述：需求标题应简明扼要，尽量不超过30字，能够提取需求内容的主题思想，要简洁直观。
需求标题常见的问题有：
例如：“xxx运营商需求”，没有对需求的内容进行提炼，无法通过标题来识别出其特征。
例如：“某酒店话务台电话分客房电话和办公电话两种，用户要求客房电话拨打外线时显示总机号码，办公电话拨外线显示本机号码，计费是对每个话机单独计费。交换机版本现为5K，可以升级到8K”。
这样的标题如果用“酒店话务台显示及计费新功能”来概括会更加简洁清晰。
2. 应用场景和价值说明：
①用场景
客户希望如何使用该需求？ （例如：地点，谁操作，如何操作），实现该需求有什么约束条件？ （任何已知或潜在的约束，如性能、安全性、可靠性、易用性、自然环境等），需求所处的组网环境是什么？
可以使用必要的图表来辅助说明应用场景。
②需求价值说明
- 需求能够带来多大的价值，实施的必要性有多大？
- 需求能够带来多大的价值，不实现该需求会造成多大损失？
- 涉及的合同金额，销售量，利润率，对后续项目拓展的影响等。
- 客户背景信息，在市场细分中的定位
- 需求所在销售项目重要性（如果是销售项目需求的话）
- 需求的通用性
- 竞争对手实现情况
- 需求的紧急程度
- 需求必要性属性要求
3. 提交需求前先自检
需求提交人在完成需求描述后，可以参照下述标准对需求进行检：
- 正确 正确理解了客户的需求，客户的需求都包含进来，客户没有要求的都没有被包含进来
- 明确 以合适的详细程度进行了描述，不过分简略或过分繁琐
- 完整 包括了正常和例外条件
- 一致 需求之间没有冲突
- 分级的 需求是区分了优先级的
- 可验证的 需求是可以被验证的，有明确的验证标准
- 可修改的 抽取易变量，以备后续修改。例如客户要求12：00之后和之前用不同的计费方式，那么很可能今后会变成11：00为分界点，或13：00点为分界点。需求提交时要标识出这个易变量。
- 可追溯的 需求被清晰的标识，能够追溯到源头
- 可理解的 需求以书面的形式记录下来，并且使得所有利益相关人可以理解
4. 需求提交人信息要清晰
- 为了确保需求信息的可追溯性，保证需求分析团队在必要时与需求提交方进行信息澄清确认，需求提交方在提交需求时，必须提供自己的真实，准确的个人信息，包括：提交人的工号，姓名，电话，email，所属部门信息。
以上四项，是我们提交产品需求时必须遵守的原则。此外，对于一些销售承诺类的需求CCM（Customer Commitment Manager），还应包括以下的内容：
- 地区/合作伙伴/项目类型（投标/议标）
- 项目优先级
- 预计合同金额
- 是否首次进入该国家/地区/新建还是扩容/是否需要准入测试
- 发标日期
- 投标进度要求的最迟答复日期
- 要求交标日期
- 销售项目状态
- 预计/实际揭标日期，预计/实际签单日期
