博客园 - papachong - 基于构件技术的需求管理过程-框架需求调研

基于构件技术的需求管理过程-框架需求调研
基于构件技术的需求过程与传统的需求过程有着非常大的区别，在传统的需求过程之中，更多的是强调需求沟通技巧，而基于构件技术的需求过程则是强调需求复用，很多项目管理人员把满足客户需求与提高客户满意度对等起来，认为越多的满足客户需求，客户满意度就越高，我不认为是这样的，原因如下：
客户希望项目能够完成，并且上线，产生一定的效益，如果这个不能保证，无限满足客户需求，也不能提高客户满意度。
项目负责人应该在满足客户需求和提高客户满意度这两个既对立又统一的目标进行平衡，通过科学量化的需求管理过程来实现其目标。
关于上述问题我想单独再提一个话题进行说明，这篇文章主要讲的是基于构件技术的需求过程，以下则称“框架需求调研”：
框架需求调研的目的是：
l        针对客户的业务领域找到合适的业务领域模型。
l        确保客户、最终用户和开发人员就项目需求在合同的基础上进一步达成共识。
l        导出支持目标组织业务所需的项目需求，并分解成构件，包括已有构件清单、采购构件清单、开发构件清单，另外还包括不属于构件范畴之内的其它需求，如设计约束、性能需求、标准需求等。
l        与客户和其他涉众在需要开发的构件需求方面达成并保持一致。
l        使系统开发人员能够更清楚地了解构件需求。
l        为估算开发构件系统和测试集成所需成本和时间提供基础。
l        定义新开发构件的用户界面，重点是用户的需要和目标。
为实现这些目标，框架需求调工作流程说明了如何采用新的业务构件来改变以前传统的工作模式，并确定该业务模型之中所需要的功能（流程）、角色（岗位）、权限（职责范围），并举例说明采用了信息化的业务构件之后的工作流程。
框架需求调研阶段的工作流程包括初步需求整理、搭建构件演示环境、构件需求调研准备工作、展开调研工作、调研结果的整理、需求评审、客户确认。如下所示：
 

1初步需求整理
目的：
l        以合同为蓝本，对项目需求进行深入沟通
l        将客户对目标应用系统的框架需求文档化，便于达成共识；
l        分析出已有构件、外协构件、开发构件，从而评估应用系统规模；
l        根据应用系统规模来评估该应用系统的成本和初步的项目进度；
如何配备人员：
团队负责人需要完成框架需求的整理工作，整理工作的结果是《框架需求说明书》，团队负责人可以在构件咨询员的协助下完成该项工作，如果项目规模较大，构件咨询员可以直接参与并主导该项工作，团队负责人需要对该客户的业务领域有较深的理解。
工作指南：
根据构件资源库以及构件发布清单来确定客户哪些需求是可以采用构件予以满足，这部分形成已有构件清单，不能满足的需求则需要考察构件资源合作伙伴是否有外协的构件清单，如果没有，则需要自行开发新的构件。
针对构件发布状态清单，对于低稳定性的构件应予以优先升级。
所有的构件清单分类非常清晰之后，团队负责人应该邀请公司内部有项目经验的人员对该项目予以评审，评审的重点是构件清单选择是否合适，业务需求差异是否大到足够要开发一个新的构件，还是在原有的构件上予以升级。
可应用以下技巧示例来帮助团队负责人收集正确、相关的信息：
l       集体讨论并整理提议
l       制作示意板
l       角色扮演
2搭建构件演示环境进行确认
目的：
l        快速构件目标应用系统，争取市场订单；
l        通过演示环境使客户快速对目标应用系统有了非常深刻的理解；
l        缩短对目标应用系统理解的时间，客户可以直接操作，甚至可以直接部署安装；
如何配备人员：
构件测试集成人员根据已有构件清单来搭建该演示环境，并由团队负责人组织演示数据。
工作指南：
演示数据应该贴近客户实际情况，如果不了解客户实际情况，则采用通用的演示数据。
如果项目涉及面广，则可以同步制作PPT，通过会议形式进行演示，在向客户进行演示时应该注重说明这是一个可运行的目标应用系统，而不是说明让客户看这还需要哪些改进，应该将提意见的重点部分放在新开发的构件或拟定要升级的构件之中。
搭建的目标应用系统如果沟通情况良好，则可以直接组织培训和运行，需要进行新开发的构件则后期通过构件集成方式进行集成到运行环境之中。
可应用以下技巧示例来帮助团队负责人收集正确、相关的信息：
l        进行演示会议
3构件需求调研准备工作
目的：
l        为深入了解需求制作调研工具，包括调研表格、原型系统、调研问卷；
如何配备人员：
团队负责人和资深的构件开发人员可以担当此工作任务，最好是开发该业务构件的开发人员，进行需求调研的准备工作人员应该具备项目调研工作经验和新开发或升级构件的业务领域知识，懂得如何制定项目调研表格。
工作指南：
根据开发构件业务清单和业务构件建模文档来制定项目所有的新开发/升级构件的调研表格，所有的调研表格必须以最终用户进行分类，不要让最终用户分开填多个调研表格。
团队负责人协调美工制作人员进行原型系统的设计，原型系统的设计应该遵守《构件设计开发标准》和《构件互操作性及界面标准》。
团队负责人也可以从公司历史项目之中找到一些案例，并修改一下界面或在网上找到其它公司的产品进行说明。
可应用以下技巧示例来帮助团队负责人收集正确、相关的信息：
l       集体讨论并整理提议
l       鱼刺图
l       Pareto 图
4展开调研工作
目的：
l        深入了解需求，与客户达成一致的需求理解；
l        扩大项目在客户方的影响；
如何配备人员：
团队负责人、构件咨询员、资深的构件开发人员可以担当此工作任务，如果能事先指派构件开发人员，则可以直接委派该开发人员参与调研工作；
工作指南：
项目调研人员应该能充分利用调研工具与客户进行交流，但每次交流项目调研人员都有非常明确的目的，而不是漫无目的的交流，比如说你们的网络结构是什么样的？目前有什么应用系统，为确保每次交流都是富有成效，所以项目调研人员必须对每次交流做好充分的准备。
调研过程应该可以采用笔记、录音等方式，以便于调研完成之后进行调研结果的整理；
可应用以下技巧示例来帮助团队负责人收集正确、相关的信息：
l        访谈
l        演示会议
l        需求研讨班
5调研结果的整理
目的：
l        形成书面的需求文档，以便于内部评审以及客户达成一致；
l        更新业务构件建模文档，为将来设计业务构件做好准备；
如何配备人员：
团队负责人、构件咨询员、资深的构件开发人员可以担当此工作任务，如果能事先指派构件开发人员，则可以直接委派该开发人员参与调研结果的整理；
工作指南：
项目调研人员应该立刻记录下调研的信息，以免长时间调研会遗漏细节，需求调研以构件为基础，所以需求文档应该包括业务构件需求和其它需求，业务构件需求应该直接引用更新了的业务构件建模文档，其它需求主要是环境方面的需求，如数据库环境、部署范围等等；
对所有的业务构件需求整理完毕之后，应该邀请有经验的人员对该系统进行需求评审，以有利于项目商务工作和业务构件的积累。
需求整理完毕之后，应该形成客户可以签署确认的文档，此份文档可根据国标或者其它软件工程方法学之中的需求文档编写，但在以下方面应该做调整：
1、  以业务构件为基础的需求文档；
2、  应该添加客户可签署确认的位置；
6需求评审
目的：
l        对需求的充分性、合理性、确切性进行全面评审；
l        对项目复用程度进行评审；
l        建立需求变更管理配置环境
如何配备人员：
团队负责人提交需求评审申请，公司可组织专家委员会对其进行评审；
工作指南：
每一条需求应该是可以实现的、确切的，且对客户产生了价值，并具备充分性、合理性。
需求评审的过程也是对需求难易程度、优先级、工作量等指标进行排序的过程。
在公司的构件资产之中找到合适的构件来满足项目需求，从而增加项目复用度，加速项目实施。
_xyz