记一次联合需求计划（JRP）会议

记一次联合需求计划（JRP）会议

今天参加了一次可以算得上JRP的会议。

与会者有甲方最高领导，二号领导，以及各个部门头头，业务专家，监理公司代表，开发方项目总监，执行项目经理，程序员代表等，层级不可谓不高。

会议在甲方大会议室进行，里面有个超大的屏幕，已经赶上MAX影院了。每个人面前一只麦克风，可关可开。地上是应该很高级的，估计是羊毛的地毯，我们进去都要套鞋套。总之设备一流。

会议有既定议程。甲方二号领导主持，首先甲方代表发言，介绍项目概况和目前的总体情况。接着是开发方介绍技术方案、实施计划，然后演示原型。再接着各部门提意见，这是重点，耗时最长，过程中也暴露出一些问题，主要是：

1）开发方没有紧扣之前他们内部咨询时绘制的思维导图。该思维导图的分类其实已经很大程度代表了他们的初步设想，而我们的原型，只是根据过去2周的需求调研所得到的信息，以及结合过往相关系统的经验而制作，因此原型的许多菜单，都不够全面，甚至有所遗漏。

2）第一点其实也与过去2周的需求调查，只是逐个部门孤立进行有关。有些部门出于一些考虑，自己也并没有按照甲方自己的思维导图要求进行，对一些模块和功能，打了折扣。

3）在会议上，甲方发现有些地方自己内部存在分歧，因此需要内部统一意见再对修改需求内容。

值得一提的是，甲方最高领导在会议过程中，话虽不多，但能击中要害，抓住核心，确实表现出高于一般层级的高度，以及考虑问题的全面性，总揽全局的气势。最后他强调项目对管理的重要性，要求各部门通力合作，全力配合开发方的工作。也强调了项目时间节点不可变更。

这是我最近一次参加的，比较典型的JRP。

什么是JRP?

联合需求计划（Joint Requirement Planning ,JRP）是一个通过高度组织的群体会议来分析企业内的问题，并获取需求的过程。它是联合应用开发（Joint Application Development，JAD）的一部分。

JAD以小组形式定义和建立系统，由企业主管部门经理、会议主持人、用户、协调人员、IT人员、秘书等共同组成的专题讨论组，由这个讨论组来定义并详细说明系统的需求和可选的技术方案。

JRP通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。通常参会人数6 ~ 18人，时间1 ~ 5小时。

JRP的优点：

JRP相对来说成本较高，但是一种十分有效的一种需求获取方法。 1）加快需求获取进度，降低需求获取成本，尤其对有歧义、最不清晰的领域十分有效 2）提升用户参与积极性，提高开发效率 3）采用原型确认系统需求并获取设计审批，具有原型化开发方法的优点

通过这次会议，JRP的这些优点，体会得十分真切。

JRP的原则：

JRP的主要意图是收集需求，而不是对需求进行分析和验证。实施JRP应把握以下主要原则：

1）事先制定议题

2）严格按照约定时间进行

3）对议题逐一进行讨论

4）会议记录

5）避免术语 开发方避免使用专业术语，尽量通俗易懂，利于交流

6）（开发方）应有解决冲突的能力 极力避免与各方，尤其是甲方闹不愉快。就事论事，目的在于解决问题。

7）中场休息 本次会议是一个上午，中午结束，并无中场休息

8）鼓励取得一致意见

9）保证大家遵守会议决议 即会后应有相关跟进，对作出的决议，产生的问题等及时处理。

JRP的一般步骤：

1）让与会者互相认识，力求会议在轻松气氛中进行

2）列举问题，逐一讨论或按照议程，逐一进行

3）鼓励大家对现有系统或现状畅所欲言

4）鼓励大家对新系统畅想，形成清单

5）对清单进行整理，明确优先级，评审，最后形成结论或结议。

当然今天的联合需求计划会议并没有完全按照这样的步骤，但精神是一致的，那就是厘清需求，解决问题，形成结论，为下一步工作做好铺垫。精神贯彻就行，具体做法可以加以裁剪。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。