需求流程

我的一点想法和经验：

我一般倾向于将需求分为两类：
1，满足核心需求的雪中送炭型需求
2，作为非主要卖点但是可以增强产品竞争力的锦上添花型需求

第一类需求应该放在1期项目中做，通过销售、市场以及工程人员尽早接触核心业务，让他们更深入的理解系统，并对产品解决客户问题拥有充分的信心。同时核心业务的实现对于团队是鼓舞，也能够有效降低风险。在实际操作中，我可以选择硬编码、手工修改配置文件的方式来对非核心业务的部分进行处理。目标是尽快出一个只具备基本功能，能跑起来，界面不复杂，流程不复杂，配置不繁琐，运行稳定的系统。
在一期工程进行完整迭代，直到内核系统出来。发布基线是运行稳定、能解决核心问题、流程简单。我不要花哨的功能，只要实用，只要能解决最核心的问题。

第二类需求应该在1期完成核心需求后开始策划，在实际操作中，我需要把硬编码的内容提取出来，尽量放权给开发人员进行讨论、设计和实现。在一个稳定内核的基础上的扩展，会让团队成员有较高的执行力和驱动力。

关于需求的问题，分为以下几个步骤：

需求确认、需求强化、需求挖掘、需求验证

产品化需求分析工作流程:

1，邀请销售、市场以及技术支持相关人员介绍产品出台的背景以及产品需要解决用户哪些问题？如何带来价值。用户希望看到哪些东西，想用它来做什么？召开需求会，让每个开发人员直接参与，让他们知道他们做的东西的意义。让他们知道他们在解决什么样的问题。（经验证明，这个过程可以有效提高产品质量和开发效率，虽然我还没深入思考其中的原因）

2，对于需求进一步深入，给出用户使用的场景（用例场景），让开发、测试人员对系统有深入的认识。给出建议的工作流程场景。着重解决核心问题（雪中送炭类）

在开发工程中，每一次集成，都应该邀请相关市场和技术支持人员或者用户进行试用，在试用的过程中提出对核心功能、流程的改进意见（选择性接受锦上添花类功能变更，主要处理雪中送炭类）

直到核心业务能够满足需求，一期需求工程结束。结合原型迭代法，在开发过程中进行不断的需求强化，当项目结束后，每个开发人员都能作为技术支持人员进行支持。

3，深入挖掘需求，制定锦上添花类的场景（2期往后，具体还没思考好）

4，需求验证（后续）