需求调研规范

需求调研规范本文明确项目调研阶段的工作划分及流程，作为产品经理或者项目经理及参与项目调研的项目组成员，在调研阶段的工作指导以及相关约束条件，如何高效的进行调研。通过本文所明确的管理规则，促进医疗事业部需求调研的管理更加透明、有效，为项目开发阶段的设计、分析提供准确依据。需求调研作为一种产品需求验证的手段，在需求搜集中有着比较重要的作用，尤其是在新功能、新业务设计前以及类似方案取舍对比上。需求调研是作为产品经理/项目经理工作最关键的环节之一，也是项目启动先决条件之一。相信已经这个大家一定不会陌生。但是，在实际工作中参与者或者是企业又不太重视的一个工作环节。因为大量的需求调研会消耗公司巨大的人力、物力，且有可能得到的需求调研结果和实际结果大相径庭，得不到正确方向的引导，反而变成一种反向型的引导。所以一般企业会跳过这个环节去直接开展工作。其实，最重要的是我们能不能去解决调研效率问题？需求调研的效率和质量对于一个应用产品来说，是一个极其重要的阶段，它的质量在一定程度上决定了一个软件产品的最终交付结果。那么如何提高产品调研的质量和效率，所以今天我们来聊一聊需求调研到底该如何高效、高质量地进行？首先，我们要来把相关调研的规则梳理清楚，按照相关规范去执行解决相关效率。由于文章篇幅以及产品经理如何进行需求调研的相关知识就不在这里赘述了，大家可以通过人人都是产品经理平台去进行学习调研的交谈技巧、调研表设计以及相关基础性的硬技能。本文明确项目调研阶段的工作划分及流程，作为产品经理或者项目经理及参与项目调研的项目组成员在调研阶段的工作指导以及相关约束条件，如何高效的进行调研。通过本文所明确的管理规则，促进医疗事业部需求调研的管理更加透明、有效，为项目开发阶段的设计、分析提供准确依据。但，此规范要求主要面向软件开发类大项目的需求调研阶段，以为核心开发组提供准确、全面而有条理的现场需求为目标。为保证开发类项目调研过程完整，产品经理项目经理应该按照此过程执行。希望产品经理或者项目经理在调研过程中再结合自己的一些特殊因素，行业经验去丰富、去调整。1.应用范围与版本说明首先我们按照正常文档规范去书写这一份调研规范，让参与者都清楚应用范围定义，以及明确调研任务和项目名称。另外，还有适用对象，适用于开发部内参与需求调研工作的PMPSM运营人员实施人员开发支持人员。同样，对于产品经理的每一份输出文档来说，都必须要有版本变更的记录，方便复盘以及观察功能共性。2.参与者职责范围本规程用于明确医疗产品项目需求调研阶段的工作职责，规范调研过程中所需遵守的规章制度、工作流程。并且，清晰的定义参与此次调研相关人员岗位职责以及清晰分工，这个的作用是避免参与者的重复工作，分工合理的状态去完成调研工作，提高效率。项目经理和产品经理在项目调研过程中负责整个项目的设计以及管理，是项目调研过程的策划和组织者，其职责包括：对于组织项目启动会，负责制定和宣导项目调研的具体工作安排，并且确定需求调研的范围、参与者、进度。调研前准备对客户原有系统做详细了解，特别涉及与新系统差异较大的流程和特有业务的掌握。调研前对客户原有系统做详细了解，特别涉及与新系统差异较大的流程和特有业务。并对系统业务的讲解和客户指导，保证客户充分理解和掌握系统的业务流程和关键点。设计可行的调研计划并推进调研工作的执行。在调研过程中根据软件项目的生命周期进行控制调研进度，负责与开发人员、相关调研对象的沟通，围绕绩效和绩效来确保沟通质量以及成本。风险控制。定期举行项目例会，总结调研工作执行阶段成果，向核管理层和参与者汇报调研工作执行情况。处理好项目组、客户、商务及核心开发组之间的关系，有效利用内外资源。整理并讨论需求调查表收集上来的需求，提请项目组讨论确认以及评审。核心开发支持人员的职责包括：完成调研过程中的提前评审，给项目经理以业务支持，完成提前评审。需求调研完成后完成整体需求的评审。确定后续开发计划并完成需求开发工作。及时整理和完成《需求跟踪矩阵》相关内容。3.相关附件规范在调研规范说明之后，必须事先准备的输出文档就是，需求调研计划、需求调研大纲、需求调研问卷表、软件需求说明书、需求变更控制报告、软件需求说明确认书，风险控制书。接下来，就是进入到产品设计阶段，这样一来我们就可以有依据的去做需求。关于附件文档的一些释义如下：（1）《需求调研计划》该文档用于调研人员到客户现场后根据现场情况确定调研计划使用，可以在现场启动会后根据客户实际安排来完成此项工作。此计划需要通过组织者、管理层评审后方可执行。如果产品经理或者项目经理情况在调研前已经了解足够充分，需要在公司启动会前完成并提交部门评审，到现场后提交现场启动会讨论通过，如果现场启动会对计划有所更改，需再次发回公司评审。那么对于需求调研计划的重点我们要侧重于计划的可行性以及真实性。（2）《需求调查表》该文档应用于正式调研的场景中，下发给被调研对象，在系统演示或者培训后由调研对象以业务单元为单位集中收集并逐个需求确认。如果有条件建议该调查表以电子表格方式下发给被调研对象，并以电子文档方式反馈调研结果，便于后续需求规格说明书的整理。同时，产品经理/项目经理记录“需求描述”，问题描述内容要把问题描述清楚，同时需要说明问题的性质（问题、新增需求、需求变更、需求舍弃）。另外，还要说明问题的优先级别（高、中、低）。明确涉及工作产品”（功能名称）及“涉及项目相关方”（哪些最终用户）；需求调查表经过讨论后需要确认该需求是放弃还是保留，放弃的需求也需要客户确认签字，避免客户事后再次提起，以作为需求变更的依据。需求调查表的内容除调研对象提出的需求描述外，还包括调研负责人拓展的相关需求进行确认。通过的报表格式、文档等形式形成有效力的附件，产品经理复盘以及定责使用。（3）《需求调研大纲》该文档用于项目组对调研工作中功能点及关键流程的指导，防止调研中某些关键流程及功能点的遗漏。项目经理及项目组成员要仔细阅读并熟练掌握其中流程及功能点的应用，以方便项目组在调研过程中对客户的引导和建议。调研大纲的内容为软件系统业务功能点的汇总，在实际工作中需要各项目组加以补充和积累，以便于对其他项目调研工作有更积极的指导意义。此大纲的丰富和积累工作要求在后续章节中重点阐述。（4）《项目风险管理报告》项目风险控制报告是贯穿于项目整个生命周期的风险跟踪和评估的依据，其中的每一个风险项具备两个状态，发生和关闭。风险项的初始状态为发生，产品经理及项目组成员要实时跟踪和关注各风险项的状态和措施的验证，一旦根据风险得以解决或规避，项目经理需要将其状态由发生变更为关闭，表示该风险已规避。其中.“主要生存期”一列中填写该风险存在的主要的阶段，可分过程、活动或子活动进行明确。例如：过程——项目全过程、软件开发过程、系统集成过程；软件策划过程、设计与实现过程、硬件实施过程、软件实施过程；活动——需求分析、项目策划、系统设计、编码实现、软件测试、软件释放、集成策划、实施、试运行、系统验收等；子活动：概要设计、详细设计、代码检查、单元测试、功能测试、系统测试等。如果某风险在不同的“生存期”属于不同的“风险类型”和/或采取不同的“控制措施”，则需作为多条风险分别列出。列在本表中的风险，只能增加不能删减，对于已经不存在的风险，须填写关闭标识与状态。（5）《变更控制报告》变更控制报告是贯穿于项目整个生命周期的所有变更行为的评审依据，亦适用于项目需求的变更。对于已经评审通过的需求，需要项目组提交项目领导小组进行评审，并同时提交开发部评审后方可生效。对于评审通过的需求根据需求的分类，由核心开发组或现场项目组完善设计文档后进行开发。需求变更控制报告需要明确变更的主体及变更提出原因，如果有客户的书面说明，则可以直接引用。此报告可附带附页并同时提交评审。（6）《软件需求规格说明书》软件需求规格说明书用于需求调研结束后对各业务单元所涉及需求的汇总和整理，凡是在需求规格说明书中体现的需求，均为与客户方逐个讨论确认并通过开发部提前评审的需求。软件需求规格说明书是最后与客户确认需求的依据，在整理完成后经过客户和开发部最终确认后生效。该说明书与《软件需求规格说明书确认单》共同构成本次需求调研的最终确认成果。软件需求规格说明书是最终项目验收的重要依据，必须引起足够重视。（7）《软件需求规格说明书确认单》需求规格说明书确认单是与需求规格说明书同时使用，为最终确认客户需求的汇总文档。其中内容详细描述部分需明确本次确认的所包含的需求规格说明书的全部清单，并签署客户确认意见，同时明确对于本次确认的需求变更控制办法，不得有遗漏。4.调研过程规范（1）调研启动会旨在确定调研阶段详细计划、项目组织结构、人员分配等工作，明确调研流程及调研相关资料的使用及提交和确认方式。（2）制定详细调研计划结合产品实际情况，制定出详细的调研计划。计划要明确调研范围、时间进度安排、阶段提交工作产品，明确调研相关业务单元及子单元负责人。计划要做到周密严谨、可行性强。调研计划确定后提交项目领导小组和公司相关负责人评审通过后生效。调研计划要充分体现客户资源的利用，安排客户信息中心人员从需求调研开始全程参与项目。在客户人员充足情况下要确保每一个业务单元都有信息中心人员全程跟踪和监督，明确责任。此项工作可以使项目组人员能够从繁琐的客户指导和需求整理中抽出身来，全身心的投入到需求的分析和引导工作中。此阶段用到项目调研阶段规范中的《项目调研计划》模板，从此阶段开始整理《项目风险管理表》。调研参与者要对调研对象认知差异作出准确判断，了解和记录特殊业务和流程，充分了解需求调研规范中的《项目调研大纲》内容及关键业务点。通过新旧系统的比较，拿出合理的解决方案和需求业务引导措施，保证在调研对象调研及需求讨论过程中，对调研对象提出的特殊业务和需求及时准确的反馈和引导。（3）真实场景调研规范对于调研对象特有的需求，要充分的理解和挖掘。对于其中我们系统能够变通实现的业务，要给予调研对象理性的分析和宣导。激励引导调研对象详细的描述清楚并注明提出的原因，供后续需求讨论时筛选和确认。对于我们系统欠缺的或没有实现的业务，要充分挖掘用户需求，不排除对用户原系统加以仔细的研究和摸索，力求熟悉相关业务，然后仔细的整理并收集相关报表和业务资料。此项工作有利于项目的后续开发和实现，也是对我们系统版本的必要补充。（4）需求的整理和确认《需求调查表》收集工作完成后，由调研负责人将需求内容第一时间发回公司进行需求提前评审，避免开发确认和客户确认出现较大分歧。同时，调研负责人和项目相关负责人对所收集的需求进行筛选和确认。对于由公司提前评审提出的需求意见，项目组要第一时间给客户以反馈，提交项目领导小组进行再次讨论，直到得到客户和公司开发组的最终确认。需求调研产生的需求经过双方讨论确认后，由项目组和信息中心组织整理《软件需求说明书》和《需求说明书确认单》。需求规格说明书的整理要尊重需求原型，做到客观而详尽，力求清晰明了。《软件需求说明书》和《需求说明书确认单》整理完成后提交项目领导小组和公司开发组审阅，经项目经理和院方领导小组相关干系人确认签字后正式生效，作为本次调研的最终成果物。对于调研及确认过程中放弃的需求，也要求客户详细的进行整理并加以确认，并注明‘放弃’字样，防止需求的再次提起引发争议。5.调研质量管理为了保证项目调研的质量和效率，提高核心版本的有效复用