论产品经理对传统IT公司的重要性

我如今一家传统的软件公司，专一在监控行业。就客户需求与研发流程管理，如今的研发模式大概以下图：

上图中，我把客户的需求定义为要求，是有带有咱们行业相关背景的，客户是对系统不会有很深的认识的，并且客户绝大部分对其提出的要求是不清晰的，借用伟大乔布斯的话“用户不知道本身要什么”。

在此模式下，咱们的需求人员在对接了来自客户的要求后，分析整理后，输出需求规格说明书，下发任务给开发表明（或系统SE）。在明确需求后，开发表明（或系统SE）输出架构说明(可选)和概要设计，并与开发、测试一块儿明确功能点(测试项)，作好任务分配与排期。后续流程大致也与图上一置。

在这里面，其实有两次的需求分析(需求人员与技术人员对需求的解释角度是有区别的)与相关文档输出。这是与流行的敏捷最大区别的地方，在敏捷的流程里，需求是要直接与研发体系人员（开发，测试）一块儿需求讨论和澄清并完成任务分配的。

再明确一需求的行业定义：功能性需求，非功能性需求，（设计与实现）约束条件。在现体系下，需求人员更多完成的是“功能性需求”。并且需求人员的责任是承接客户要求并输出给开发表明，很容易出现将客户的需求简单转化后就交由后方研发，最终变化为开发表明转化客户要求到系统需求的状况。实际的结果变成：开发表明完成需求的分析，明细，设计与研发任务的转换。

此研发模式个人理解为：对客户咱们是2阶段提交。

在“两阶段提交”模式下。咱们需求同窗在需求收集并分发研发后，对该需求的掌控就失去了。若是这里遇到需求变动，天然就带来了你们的拒绝（名人言：研发不是害怕需求变动，怕变动致使的混乱）。“两阶段提交”中还有一个隐藏的角色：项目经理，他须要监控项目的进度与风险。

有“两阶段提交”，那么咱们应该还有一种模式：“三阶段提交”。

提出此想法是基于一个简单原则：“功能性需求”应该是能够经过原型呈现的。那么需求人员是须要输出原型的，并且还得比较详细、全面的呈现（毕竟要给客户确认嘛）。那么在分析需求并制做原型时，需求到技术的翻译，研发表明要配合。提交研发时能够直接与研发人员（包含测试）同步，也可交由开发表明分配功能，但需求的澄清应该由需求人员发起。

在此图中，我调整需求人员角色为产品经理。由于我以为产品经理的职位是不单单关注系统（或需求）自己，还要关注其价值。应该在原型阶段让客户看到的不单单是功能的呈现，更要感受到其可带来的价值，从客户获得更多Confirm，减小Cancle。

以上都是我在学习需求分析后的感想。欢迎板砖来拍，期待能与优秀的你更多的沟通与交流。