需求管理的管理模型

在需求管理的流程中,需求的捕获手段固然重要,但在需求的捕获和需求最终成型的过程中,我们会面临各种和需求相关的信息和资料(也可以把这些信息笼统地称做需求),如何发现这些信息之间的关系并有效组织,更为关键 需求类型 在RUP中,我们采用一种金字塔方式的管理办法,来组织和管理我们获取的信息乃至最终的需求

为了建立一个真正满足客户需求的系统,项目团队首先必须确定系统要解决的问题然后,团队必须确定涉众,从中获得业务和用户需要,对其进行描述,并区分它们的优先级从这一组高层期望或需求出发,对产品或系统特性集达成一致意见而后,由产品特性来抽取软件需求,在我们的模型中,软件需求是以用例模型的方式来描述从测试的角度来看,测试项一定来自于软件需求,即软件需求中确定了哪些需求项,测试就要根据这些需求项来制定和实现

系统越大越复杂,出现的需求类型就越多一个需求类型不过是指需求的一个类通过确定需求类型,团队可以把大量需求组织成意义明确且更容易管理的组在一个项目中建立不同类型的需求有助于团队成员对变更请求进行分类,并使相互之间的沟通更为清楚明确从上述的分析中我们可以看到,通常,一类需求可以细分即分解成其他类型的需求这里,我们就把需求分解为几种类型,并在他们之间建立相应的关联业务规则和前景声明包括高层次的需求,团队可以从中导出用户需要,特性和产品需求类型用例和其他建模形式驱动设计需求,该需求可分解为软件需求,并可以用分析设计模型来说明测试需求源于软件需求,它被分解为具体的测试过程如果既定项目中有成百上千个,甚至上万个需求实例时,对需求进行分类可以使项目更容易管理上述的这些需求类型同时保存在对应的RUP文档和数据库中

需求预测模型

1主观判断预测。主观判断预测涉及利用主观判断和直觉，适用于数据有限或无历史数据的情况，例如引入新产品。主观判读预测技术包括调研和类比技术等。

2时间序列预测。其基本假设是未来需求仅由过去需求决定。时间序列预测技术包括但不限于简单移动平均

和加权移动平均。

3因果预测。因果预测假设一个或多个因素与需求相关，而因果关系可用来估计未来的需求。

第一步：

1：找全项目主要干系人,了解他们的想法

2：可用用多种方法进行调研,如问卷调查/头脑风暴/原型法/会议等

 3：做好需求确认

第二步：做好调研表格，如下格式

第三步：

     市场调查工作必须有计划、有步骤地进行，以防止调查的盲目性。一般说来，市场   调查可分为四个阶段：调查前的准备阶段、正式调查阶段、综合分析资料阶段和提出调查报告阶段。

    1：调查前的准备阶段。

    2：正式调查阶段。市场调查的内容和方法很多，因企业和情况而异。

    3：综合分析整理资料阶段。当统计分析研究和现场直接调查完成后，市场调查人员拥有              大量的一手资料。对这些资料首先要编辑，选取一切有关的、重要的资料，剔除没有              参考价值的资料。

其实这题问的是产品的研发管理，我仅从IT研运一体化的角度去谈，那么该题目可等同于项目管理制和产品管理制的区别与痛点，按照如今IT的发展路径，未来企业的IT业务，应该是通过项目制转型到产品制，来实现真正的端到端和业技融合：

一、项目制到产品制的起由

想要知道项目制到产品制的转变起因，我们需要先了解需求分析方法转变的三个阶段：

第一阶段：

来自于20世纪90年代之前的信息自动化时代。在当时，企业只要有单机系统，可以把所有手工工单 *** 作自动化，极大地提升研发效能，当时供小于求，强调用最快的速度做出最多的功能。

第二阶段：

1990—2010年的互联网时代。敏捷方法和精益方法在IT领域开始得到应用，更多的企业开始强调怎样才能在高效交付的同时适应需求的变化，如何让IT方案解决业务问题。

第三阶段：

2010年后的数字经济时代。在2013年前，譬如证券企业，其所有系统都是外部企业采购的，产品企业的产品经理都是从证券公司出来的，他们了解客户想要什么，甚至在卖产品的时候会出现供不应求的情况。但到2010年后，产品企业再给企业做交易系统等证券系统时，当时的产品经理和客户经理已经跟不上时代的变化了，同时就算是从证券公司找一个人过来，也是懂之前的系统，时代变化太快了。所以最懂业务知识的一定是企业业务自身，今时今日再给企业做开发时，就一定要考虑如何调动客户资源来做精益需求管理，通过与客户共创精益需求来助力企业快速发展。

再回到企业本身对待需求的态度，我们也可以观察到，以往的银行客户可能在需求和开发之间还会有一个需求管理处，所有的需求先到需求管理处，不合适就退回，但现在都为了业务，下沉到各个处室。这体现的正是整个行业进行数字化转型时的决心，以业务价值和产品价值为导向，每阶段均以产品价值进行度量。

二、敏捷后时代背景下的产品制

何为项目制、产品制？

项目制是建立在职能分割的基础上，由甲乙方交接棒的方式进行推进。项目思维以管理确定性为主，由此可能会造成目标割裂，项目内各职能都进行了局部优化，导致了异构的发生，也导致了IT与业务的割裂。

而产品制，则是建设为产品或者产品线管理，需要关注产品和产品线给用户创造价值。产品管理是矩阵式结构，有时候是强产品，有时候是强职能，或者是弱产品和强职能。即使是完美统一的企业，它开发一款新产品时，也可能不会服务当前的技术架构，但这会给企业发展带来第二曲线，帮助企业更好地生长。当然到了合适的时机，一定要与企业整个产品体系建立连接，否则就真正变成筒仓了。

何为产品思维？

产品思维的主要原则在于，是不是需要所有人都对自身的业务领域、市场和用户有深刻洞见？显然，通常情况下并不是。但我们所希望的是一个产品经理或者需求人员能够对业务领域、市场和用户都有洞见，接下来能把它转换为需求，让研发人员可用。如果产品研发不能以客户、用户为中心，以成就用户为己任，IT研发就无法用业务来度量和衡量价值。

另外要解决常见的像多团队协作和产品需求控制等问题，也需要首先了解客户情况，才能进一步解决，否则无法管控。

三、如何由项目制转向产品制

产品管理全貌

从企业转型情况来看，可以理解为数字化的转型也是产品管理的转型。企业做产品制转型时，首先要明确纵向的企业战略是什么，横向的战略规划是什么。

纵向：

要从企业战略开始进行层层解构，拆解至企业架构，再到业务架构。

横向：

我们需要从产品或者产品线规划、需求、设计、开发、交付、上下架，整个产品全生命周期进行管理。

纵向和横向的改进，需要一个智能产品工厂作为底座支撑。DevOps是什么？DevOps是智能产品工厂的核心，也是数字化转型的底座。如今，软件在“吞噬”着整个世界，通过新技术使能商业模式创新，其中IT因素占70%，业务因素占30%。而占比70%的IT则希望能由DevOps作支撑，未来IT人员只要懂代码，懂业务知识就可以在上面运转，这样的企业才足够灵活向前推进。

当然，很多企业已经在往这个方向发展，但项目制到产品制的转换不能一刀切。企业可以先在纵向做一些切入，先做试点尝试。例如先试点单个产品，再扩展产品数量，然后扩张到一条产品线，一步一步走提升企业的能力，而不是一步到位。

产品制思维转变的主要方法论

通过贯穿探索-定义-验证-交付的方法论，我们可以推动转变为产品制思维。初期的想法阶段可以使用商业画布，中间阶段可以使用影响地图，再到用户故事地图，以及版本规划、任务拆分、精益敏捷交付和运行。这些方法论为什么要坚持使用？因为如果只是浅尝辄止是没有意义的，只有真正将方法论落到实处，才能展现能力，才能带来业务的价值和认可。

产品全生命周期的流程和实践

产品全生命周期流程实践，从产品的快速启动、迭代交付、上线运营，再往后是Scrum。

团队的建设至少需要花费半年以上的时间，因为企业首先要做到能量化团队产能，要了解人员在做什么，做到需求排序、需求置换、需求后评估，从而推动业务转型。而进一步实现跨团队协作，则可以通过SoS组织、需求梳理、跨团队计划会、团队计划会、跨团队站会、每日站会、SoS回顾和迭代评审会等手段来进行。

产品线转型做需求时也要进行优先级排序，优先级排序可以先半定量，全员达成共识，所有人都目标一致前进，才能管控好需求。

让业务逐渐围绕产品转型，推动业务和技术持续融合。一旦当业务都进行了相应程度的转型，量变就形成了质变，完成企业数字化转型。

四、产品制下，思维的导向及价值的传递

IT要满足业务的需要，提升包括业务投资汇报在内的业务价值，才能实现效能价值。而要解决IT管理混乱的情况，以及基础异构的IT问题，就需要有DevOps平台和流程体系内嵌，才能帮助企业持续运营和推广。

嘉为蓝鲸DevOps将作为企业IT转型的内驱力，从作业规范、工具体系到运营服务进行多维度落地，持续助力企业的数字化转型。

以上就是关于需求管理的管理模型全部的内容，包括:需求管理的管理模型、如何进行IT项目的需求调研、常见的研发管理等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！