我们应当怎样做需求调研：研讨会
程序员文章站
2022-05-18 23:32:46
...
经过一番努力，我们终于在客户中找到了一批人，可以解答困扰我们多时的业务问题了，真是不容易呀。但是，如何以合适的时间、合适的地点、通过合适的形式与客户研讨业务需求，是摆在项目经理面前的一道难题。在我所经历的项目中，业务研讨会没有一个是相同的。
我曾经做过一个*机关的项目，在这个项目中，从总局到省、地市、区县，形成了一个多组织机构的管理系统。虽然全国管理流程大体相同，但各地因各地实际情况的不同、领导管理思路和政策理解的不同，管理模式在许多细节上存在着差异，也就是说，这个项目存在着需求个性化的问题。在项目进行之初，客户方领导提前意识到这方面的问题，因此在组织需求研讨时，分别从各个省市抽调业务人员，集中在一起进行研讨。同时，在研讨时，根据与会人员的业务特点，将他们分成若干个业务组，分别对某个相对独立的业务模块的需求进行研讨。采用这样的组织形式，各地的业务差异在会上都会被提出来。一些地区不合理的管理模式，一经提出，就会得到其它地区业务人员的纠正，进而避免了不合理需求的提出。当然业务人员之间也会出现意见分歧。在会议启动之时，高层领导就明确提出了必须形成全国统一版本。因此，一旦出现分歧时，业务人员就会通过激烈辩论、各抒己见，进而形成统一意见。如果分歧双方谁都说服不了谁，业务组指定的组长则拍板采用哪个方案。如果他不能做出决定，就立即反映到总局领导那里当场做出决定。采用这种集中式的研讨，可以使问题的处理变得高效而及时。当然，也会因地区化差异而出现多个方案，每个方案都是合理的，我们必须在软件中分别对其进行处理的情况。出现这种情况时，至少我们很容易理清楚有几种情况，有没有可以合并的地方，使得差异最小化，最终在软件维护中体现出来，让客户自己去选择自己的管理模式。
另外，将业务人员划分为多个业务组也是一项比较成功的经验。由于业务人员自身的局限，不可能对所有业务领域的细节全面掌握，往往总是有自己熟悉的部分，也有自己不熟悉的部分。划分业务组，可以让业务人员分别在自己最熟悉的业务范围内参与讨论，可以有效提高业务讨论的质量。同时，一个管理系统涉及的业务是复杂而系统的，如果划分成多个模块并行地进行业务讨论，也可以大大提高业务研讨的工作效率。这个项目采用这种方式，使这个项目在运行数年后依然能保持统一的版本，而不至于形成一个一个的地方版本。统一的版本使得软件的升级维护成本大大降低，使项目进入良性的进化、完善的循环中。
以上讲的是一种集中式的业务研讨形式。采用这是形式固然好处多多，但并非所有软件项目都能够采用这种模式。我参与过的另一个项目就没有如此幸运了。在这个项目中，虽然也是多组织机构管理系统，但总公司对各分子公司的管理是松散的，所以很难组织各地的业务代表集中在一起讨论，甚至不能要求各分子公司采用统一的管理模式。企业信息化的目的就是要建立统一的、规范化的管理形式，它本身就是一场企业管理的变革。我们的软件，如果不能规范各分支机构的管理，抑制个性化差异，而是照猫画虎地一家一家为分子公司做软件，不仅我们的成本是巨大的，客户的信息化管理效果也不能发挥出来，而且为日后的运行维护带来巨大的隐患。毫无疑问，它是我们做管理软件的一个雷区，我们必须小心应对。
起先，总公司领导带着我们一家一家地去分子公司开需求研讨会。每个需求研讨会，我们都要着力注意各个单位管理模式的差异。当业务代表在描述自己业务流程的时候，我们常常提示业务代表，×××公司是这样管理的。这时候，业务代表会思考，采用×××公司的管理模式是否会更好，或者采用×××公司的管理模式行不行。如果他提出×××公司的管理模式可能会出现什么什么问题时，我们也会着力记录下来，下次再和×××公司讨论，他们是不是会出现这些问题。
采用这种分散式的业务研讨形式，让我们作为外人来规范客户的管理模式，常常会有这样那样的不便，但这也是我们可能面对得最多的需求研讨形式。在这样的形式中，寻找一个典型范例也许可以算是一种最佳实践。当我们面对管理松散的多组织机构时，寻找一个管理规范、对我们的支持度高的分支机构，首先将他们的信息化系统建立起来，产生预期的效益，这就树立了一个范例。它的成功就会为其它分支机构带来一种精神动力和成功案例，照着做肯定不会错。这样就可以更容易地说服其它分支机构，摒弃现有的管理模式而朝着规范化管理迈进。
业务研讨形式比较容易出现的另一个问题，就是将各个方面的业务代表拉过来开大会。在大会上，你说你的，我说我的，杂乱无章，一些重要的需求被不经意地漏掉。遇上这样的情形，项目经理应当有清醒的认识，我们需要再下来开小会。销售部门的需求跟销售部门谈，采购部门的需求跟采购部门谈••••••既然是小会，每次谈的时候人不在多，在精，参会的业务人员对自己的业务了解精细而全面。这样的会议，通常有一至三个业务人员，和一个负责人（负责拍板）参加。会议之后，我们最好询问与会人员的联系方式，便于日后建立长期的联系，毕竟业务需求不是一蹴而就的事情。同时，如果我们今后采用的是迭代式开发，他们也就成为了我们业务验证的客户代表。
业务研讨会是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能称之为会议。项目经理需要根据实际情况，合理地与客户组织研讨会。但不论怎样组织，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会。
我们应当怎样做需求分析
我们应当怎样做需求调研：初识
我们应当怎样做需求调研：拜访
我们应当怎样做需求调研：研讨会
我们应当怎样做需求调研：需求研讨
我们应当怎样做需求调研：迭代
我们应当怎样做需求调研：需求捕获（上）
我们应当怎样做需求调研：需求捕获（下）
我们应当怎样做需求分析：功能角色分析与用例图
我们应当怎样做需求分析：业务流程分析（上）
我们应当怎样做需求分析：业务流程分析（下）
我们应当怎样做需求分析：用例说明
我们应当怎样做需求分析：查询报表分析
我们应当怎样做需求分析：子用例与扩展用例
我们应当怎样做需求分析：行动图和状态图
我们应当怎样做需求分析：业务领域分析
我们应当怎样做需求分析：原文分析法
我们应当怎样做需求分析：领域驱动设计
我们应当怎样做需求分析：非功能需求
我们应当怎样做需求确认：需求列表
我们应当怎样做需求确认：一个需求列表的实例
我们应当怎样做需求确认：快速原型法
我们应当怎样做需求确认：需求规格说明书
我们应当怎样做需求确认：评审与签字确认会
（续）
我曾经做过一个*机关的项目，在这个项目中，从总局到省、地市、区县，形成了一个多组织机构的管理系统。虽然全国管理流程大体相同，但各地因各地实际情况的不同、领导管理思路和政策理解的不同，管理模式在许多细节上存在着差异，也就是说，这个项目存在着需求个性化的问题。在项目进行之初，客户方领导提前意识到这方面的问题，因此在组织需求研讨时，分别从各个省市抽调业务人员，集中在一起进行研讨。同时，在研讨时，根据与会人员的业务特点，将他们分成若干个业务组，分别对某个相对独立的业务模块的需求进行研讨。采用这样的组织形式，各地的业务差异在会上都会被提出来。一些地区不合理的管理模式，一经提出，就会得到其它地区业务人员的纠正，进而避免了不合理需求的提出。当然业务人员之间也会出现意见分歧。在会议启动之时，高层领导就明确提出了必须形成全国统一版本。因此，一旦出现分歧时，业务人员就会通过激烈辩论、各抒己见，进而形成统一意见。如果分歧双方谁都说服不了谁，业务组指定的组长则拍板采用哪个方案。如果他不能做出决定，就立即反映到总局领导那里当场做出决定。采用这种集中式的研讨，可以使问题的处理变得高效而及时。当然，也会因地区化差异而出现多个方案，每个方案都是合理的，我们必须在软件中分别对其进行处理的情况。出现这种情况时，至少我们很容易理清楚有几种情况，有没有可以合并的地方，使得差异最小化，最终在软件维护中体现出来，让客户自己去选择自己的管理模式。
另外，将业务人员划分为多个业务组也是一项比较成功的经验。由于业务人员自身的局限，不可能对所有业务领域的细节全面掌握，往往总是有自己熟悉的部分，也有自己不熟悉的部分。划分业务组，可以让业务人员分别在自己最熟悉的业务范围内参与讨论，可以有效提高业务讨论的质量。同时，一个管理系统涉及的业务是复杂而系统的，如果划分成多个模块并行地进行业务讨论，也可以大大提高业务研讨的工作效率。这个项目采用这种方式，使这个项目在运行数年后依然能保持统一的版本，而不至于形成一个一个的地方版本。统一的版本使得软件的升级维护成本大大降低，使项目进入良性的进化、完善的循环中。
以上讲的是一种集中式的业务研讨形式。采用这是形式固然好处多多，但并非所有软件项目都能够采用这种模式。我参与过的另一个项目就没有如此幸运了。在这个项目中，虽然也是多组织机构管理系统，但总公司对各分子公司的管理是松散的，所以很难组织各地的业务代表集中在一起讨论，甚至不能要求各分子公司采用统一的管理模式。企业信息化的目的就是要建立统一的、规范化的管理形式，它本身就是一场企业管理的变革。我们的软件，如果不能规范各分支机构的管理，抑制个性化差异，而是照猫画虎地一家一家为分子公司做软件，不仅我们的成本是巨大的，客户的信息化管理效果也不能发挥出来，而且为日后的运行维护带来巨大的隐患。毫无疑问，它是我们做管理软件的一个雷区，我们必须小心应对。
起先，总公司领导带着我们一家一家地去分子公司开需求研讨会。每个需求研讨会，我们都要着力注意各个单位管理模式的差异。当业务代表在描述自己业务流程的时候，我们常常提示业务代表，×××公司是这样管理的。这时候，业务代表会思考，采用×××公司的管理模式是否会更好，或者采用×××公司的管理模式行不行。如果他提出×××公司的管理模式可能会出现什么什么问题时，我们也会着力记录下来，下次再和×××公司讨论，他们是不是会出现这些问题。
采用这种分散式的业务研讨形式，让我们作为外人来规范客户的管理模式，常常会有这样那样的不便，但这也是我们可能面对得最多的需求研讨形式。在这样的形式中，寻找一个典型范例也许可以算是一种最佳实践。当我们面对管理松散的多组织机构时，寻找一个管理规范、对我们的支持度高的分支机构，首先将他们的信息化系统建立起来，产生预期的效益，这就树立了一个范例。它的成功就会为其它分支机构带来一种精神动力和成功案例，照着做肯定不会错。这样就可以更容易地说服其它分支机构，摒弃现有的管理模式而朝着规范化管理迈进。
业务研讨形式比较容易出现的另一个问题，就是将各个方面的业务代表拉过来开大会。在大会上，你说你的，我说我的，杂乱无章，一些重要的需求被不经意地漏掉。遇上这样的情形，项目经理应当有清醒的认识，我们需要再下来开小会。销售部门的需求跟销售部门谈，采购部门的需求跟采购部门谈••••••既然是小会，每次谈的时候人不在多，在精，参会的业务人员对自己的业务了解精细而全面。这样的会议，通常有一至三个业务人员，和一个负责人（负责拍板）参加。会议之后，我们最好询问与会人员的联系方式，便于日后建立长期的联系，毕竟业务需求不是一蹴而就的事情。同时，如果我们今后采用的是迭代式开发，他们也就成为了我们业务验证的客户代表。
业务研讨会是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能称之为会议。项目经理需要根据实际情况，合理地与客户组织研讨会。但不论怎样组织，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会。
我们应当怎样做需求分析
我们应当怎样做需求调研：初识
我们应当怎样做需求调研：拜访
我们应当怎样做需求调研：研讨会
我们应当怎样做需求调研：需求研讨
我们应当怎样做需求调研：迭代
我们应当怎样做需求调研：需求捕获（上）
我们应当怎样做需求调研：需求捕获（下）
我们应当怎样做需求分析：功能角色分析与用例图
我们应当怎样做需求分析：业务流程分析（上）
我们应当怎样做需求分析：业务流程分析（下）
我们应当怎样做需求分析：用例说明
我们应当怎样做需求分析：查询报表分析
我们应当怎样做需求分析：子用例与扩展用例
我们应当怎样做需求分析：行动图和状态图
我们应当怎样做需求分析：业务领域分析
我们应当怎样做需求分析：原文分析法
我们应当怎样做需求分析：领域驱动设计
我们应当怎样做需求分析：非功能需求
我们应当怎样做需求确认：需求列表
我们应当怎样做需求确认：一个需求列表的实例
我们应当怎样做需求确认：快速原型法
我们应当怎样做需求确认：需求规格说明书
我们应当怎样做需求确认：评审与签字确认会
（续）
上一篇： PHP异常处理详解