我现在一家传统的软件公司，专注在监控行业。就客户需求与研发流程管理，现在的研发模式大概如下图：
上图中，我把客户的需求定义为要求，是有带有我们行业相关背景的，客户是对系统不会有很深的认识的，而且客户绝大部分对其提出的要求是不清晰的，借用伟大乔布斯的话“用户不知道自己要什么”。
在此模式下，我们的需求人员在对接了来自客户的要求后，分析整理后，输出需求规格说明书，下发任务给开发代表（或系统SE）。在明确需求后，开发代表（或系统SE）输出架构说明(可选)和概要设计，并与开发、测试一起明确功能点(测试项)，做好任务分配与排期。后续流程大体也与图上一置。
在这里面，其实有两次的需求分析(需求人员与技术人员对需求的解释角度是有区别的)与相关文档输出。这是与流行的敏捷最大区别的地方，在敏捷的流程里，需求是要直接与研发体系人员（开发，测试）一起需求讨论和澄清并完成任务分配的。
再明确一需求的行业定义：功能性需求，非功能性需求，（设计与实现）约束条件。在现体系下，需求人员更多完成的是“功能性需求”。而且需求人员的责任是承接客户要求并输出给开发代表，很容易出现将客户的需求简单转化后就交由后方研发，最终变化为开发代表转化客户要求到系统需求的情况。实际的结果变成：开发代表完成需求的分析，明细，设计与研发任务的转换。
此研发模式我的理解为：对客户我们是2阶段提交。
在“两阶段提交”模式下。我们需求同学在需求收集并分发研发后，对该需求的掌控就失去了。如果这里遇到需求变更，自然就带来了大家的拒绝（名人言：研发不是惧怕需求变更，怕变更导致的混乱）。“两阶段提交”中还有一个隐藏的角色：项目经理，他需要监控项目的进度与风险。
有“两阶段提交”，那么我们应该还有一种模式：“三阶段提交”。
提出此想法是基于一个简单原则：“功能性需求”应该是可以通过原型呈现的。那么需求人员是需要输出原型的，而且还得比较详细、全面的呈现（毕竟要给客户确认嘛）。那么在分析需求并制作原型时，需求到技术的翻译，研发代表要配合。提交研发时可以直接与研发人员（包含测试）同步，也可交由开发代表分配功能，但需求的澄清应该由需求人员发起。
在此图中，我调整需求人员角色为产品经理。因为我觉得产品经理的职位是不仅仅关注系统（或需求）本身，还要关注其价值。应该在原型阶段让客户看到的不仅仅是功能的呈现，更要感觉到其可带来的价值，从客户得到更多Confirm，减少Cancle。
以上都是我在学习需求分析后的感想。欢迎板砖来拍，期待能与优秀的你更多的沟通与交流。
