效率提升之需求评审会议篇二

又过了一个星期，需求评审会议再次召开，这次是老大主持的，似乎很快，1个小时左右就结束了。写些开后感吧。

1。需求评审会议，一般都是当前会议支持人主持，所以对于他来说，是件熟门熟路的事情；

2。业务方想什么，手下技术人员怎么样等等背景情况会议主持人很清楚；

3。当需求评审开始时，基本都是会议主持人在发言，让需求方报告需求情况，确认需求优先级，让技术评估需求给出开发时间等，基本一个人全权控制会议进程和结果；

这样有什么好处呢？首先速战速决，开会时间短；其次大家不用想动想西，不用讨论，简单明了给结果；最后即使真的有问题，后续也是向主管报告的，他比我们更了解。因为信任所以简单！

但是这种结果是人的原因，因为会议主持人是主管，具有一定的权限和信息来源的人，并且又具有经常主持这种会议经验的人，如果换个其他人呢？这个会议肯定又是另外一种情况了哦。那么怎么保证下次开会即使不同的人，也能够快速，有效完成呢？用我开发人员写程序的思路想一想，会议就比如一个前台系统，主持人是个被调用接口，后面的实现是各种各样的，比如主管，普通开发人员，测试人员等等，在不同实例化下，系统能够正常运行，我们知道，肯定需要每个实现类要具有前台系统运行的功能，也就是会议主持人接口定义里面，要定义好各种方法，比如：会议提前准备fuction,会议过程控制function，会议后需求结果产出fuction，等等，每个人实现这个接口方法可能不一样，但是这几个步骤正确执行，虽然不能保证一定是高质高量的，但是能保证会议能完整的执行下来，哈哈。如图。

会议召开是个很简单的问题，但是推而广之，为什么会有流程，为什么会有很多流程，就很清楚了。当然扩展起来，这件事，就还有很多东西可以讨论的了哦。