昨天和team leader就产品上的一个问题进行开会讨论，会议的内容包括背景，问题原因，解决方案，执行方案。会议用时将近三个小时，得到的具体方案仍然不是完全可执行的，也就是说会议仍然没有达到理想的效果。那么就有一个值得反思的问题:如何开展一个时间短，效率高的会议。我对这个问题有一些我的思考。
首先我所说的这种会议是“分享式”会议，主要是组织会议者提供问题阐述及解决方案，与会者只需要对问题进行了解，对方案进行评估。也就是有一人或一方主导的会议。那么第一个问题，什么样的会议模式才是“健康的”呢?
第一种模式:单方面的陈述，参与者变成了完全的倾听者，不是不想提问，而是不知道如何发问。造成这种问题的原因可能在于:背景交代不清，或者没有给予参与者足够理解背景的空间，站在技术层面或自己的领域谈问题，参与者因不了解具体项目或技术无法参与。会议结束无论是组织者还是参与者收获都不大。
第二种模式:讲述变成了讨论，会议变成了各抒己见，权衡方案的模式。虽然没有说这样不好，但是发展成这样会无法控制会议时间。造成原因在于:组织者的方案被推翻或者对一些问题无法给出有说服力的解释，被迫进入讨论权衡阶段。
第三种模式:组织者主导，有问题交流。这样的会议现象说明组织者问题交待清楚，有合理的解决方案，经得起提问和推敲。通过会议可以进一步确认方案的可行性，也许可以产生进一步的优化，这也是建立在参与者理解并思考的基础上。
接下来是对会议流程的思考以及一些想到的可能对会议的开展和收益有帮助的方式:
1.组织者应在开会前进行软硬件准备。硬件包括会议室，以及会议室设备（之前有一次就是因为无法及时加入网络会议，耽误了十几分钟），在发出会议邀请中加入会议的背景（还包括问题产生的原因），会议阶段及每阶段要讨论的内容，会议目标。这种方式可以让与会者提前了解背景知识，大概清楚会议流程和时间，对会议目标有所共识，如有步骤和目标疑惑和补充，可以在会议前解决。比如组织者只进行了方案的准备，但是没有考虑到测试计划，那么如果与会者认为这是这的讨论的内容，就会补充到目标中，让组织者可以提前考虑。
2.会议中，要对背景进行比较清晰快捷的阐述，引用两个关键词就是“三句话就能概括”，“老板都能清楚”。对问题的解决方案或者实施方案，不能停留于猜想和假设，要有理论和数据支撑。如果是新的需求或者改动的设计，最好有图作为支撑和呈现，便于参与者理解。一些情况下，可以准备多个plan，但是一定要有理论分析，在组织者视角要有一个最优解，而不是在会议上讨论最优解。之后就是组织者要准备好具体的实施方案以及预估的时间节点，需要准备的东西（协调的人，准备使用的环境），尤其注意测试的设计，要和方案的设计一样，考虑测试的有效性，可行性，以及可能出现的问题等。
3.组织者应在会议结束后整理邮件并发出，主要包括会议得出的结论（具体采用哪种方式解决问题），具体的设计方案和执行步骤，会议中留下的需要会后解决的问题。在记忆最清晰的时间，将最正确的会议结论记录下来，并且可以让与会者review。这样就不会出现最后的方案和讨论时候有差异的问题，而且也是对组织者自己的一份实施指导。
下面我会讲述一些在准备会议或者准备解决方案的时候会遇到的一些思考的误区或者可能的盲点:
1.对需求有清晰的理解
先举几个例子，阐述一下可能出现的问题。之前接到一个需求，是要求将输出的文件名设置为源文件名。需求很清晰，很有可能直接就做了。但是问题在于是不是思考为什么要有这样的需求，这样的需求合不合理。好的，在进一步和application讨论之后发现，他要将原来一个流程能处理的事情分成两步，所以需要保证文件名不变才不影响整个流程的完整性。虽然能解决问题，但是不是很好的方案，之后我们又提出了更好的solution。所以可以看出，不了解需求背后的需求，即使完成了，也不见得是优化了系统。再一个例子就是有一次我负责的application出现了问题，查到原因是因为datasource的配置从LLR改成了XA。那么分析这个问题首先要知道为什么要对我的application的datasource进行改动，是因为另外一个application要使用LLR，且同一个weblogic只能有一个datasource配置LLR,再进一步，为什么另外一个application要使用LLR，原因是为了解决connection leak的问题，换成了LLR之后提升了performance，所以解决了connection leak。那么问题来了，这种修改配置的方式是解决connection leak的正常手段吗，答案是否定的，所以要从根本上解决问题就要从此着手。当然就这个例子而言，要了解的不仅如此，还要了解很多相关的知识，比如为什么我的application一定要使用LLR，如何使用LLR，为什么weblogic对它有限制等等问题。在理解了这些内容，才能得出一个有说服力的解决方案。所以，如果对需求没有深入的了解，可能会造成直接的结果就是，之后的设计或者实现是无用功。即使完成了，效果也不是很优的，整个会议可能会演变成问题的讨论，因为组织这对一些问题并不能给予准确的答复。
2.代价评估
有的时候我们常常专注于我们所提出的方案解决了问题，却忽视了额外的代价。这里的大家包括:软件资源（CPU，内存，执行时间……）和人力资源。期中软件资源好理解，就是有的设计可能对开销没有进行良好的设计，什么时候需要用时间换空间，什么时候反过来，这些是比实现功能本身更进一步的考量。我特别想说的是第二点，人力资源开销。我还是用一个例子说明问题，之前有一个需求:就是收到文件之后会根据内容进入不同的流程，所以每一个流程就要配置一个条件，然后新的需求要求多加一种配置，实现类似于“else”的效果，也就是当其他条件都不满足时进入这个流程。首先，这个需求有价值吗?答案是肯定的，因为确实能减少配置者的开销，但是再思考一个问题，这个需求有马上开发的价值吗?可能不然，因为调查发现，几个月都不会有一个这样的配置被使用，并且可以通过比较复杂的过滤条件解决这个问题，也就是说可能用户每几个月都会多花一次两分钟。但是考虑到开发成本，可能需要两三天，在这段时间中有更多优先级更高，更有价值的事情可以做，所以这个虽然有用的需求，最终还是被delay了。通俗的来讲，要看清自己的价值，并不是所有应该做的事情都是应该做的。
3.将设计理想化
我经常发现有的时候会被问住，而被问住的时候很多时候都是一个句式:“你怎么确认/证明/保证xxx一定会/一定不会发生呢?”，然后有一种恍然大悟的感觉，虽然被提出的这种情况发生的可能微乎其微，但是设计中并没有对这种情况提出解决方案，于是又变成了讨论式的会议。其实这种问题是比较难避免的，我想到的方式就是给自己讲述一遍，在讲的过程中就会发现一些新的问题，不断的从自问自答中完善自己的设计。其实被这种问题问住并不是有意的认为这种事情不会发生，而是并没有考虑到这种情况（能不能全面的考虑到各种情况，也是经过不断思考才能提升的）。只有三种情况会出现在设计中:只要是能想到的就是会出现的，通过手段控制的不会发生的，和存在出现概率但出现概率可测可控的概率性事件（尽可能避免）。那么我们最终的设计所要交出的答卷就是存在或可避免，这才是真正实施起来不会出现问题的设计。
主要分享的内容就是这些，最后还有一个附加的问题，就是准备一个解决方案的“度”，因为有的时候比如说要在明天和后天想出一套解决方案，这个时间可能并不足矣把所有问题想清楚，这其中的干扰因素可能有未知的技术，相关的知识等。那么我觉得可以先得到一些肯定的答案，比如“使用llr就是可以保证事务的顺序”，才用某某技术能解决这个问题。之后再具体实施，或者在其他时间再去对其根本原因进行深究，but，一定要记录这些问题，尤其是知识上的，要定一个时间给自己一个答复。
希望能够在不远的将来顺利主导一个，一次通过的，双方收益的，时间节约的，高效的会议。
网友评论