关于敏捷讨论的感想

两种过度

讨论的确是必要的，很多时候，只有经过大家详细的讨论，集思广益，才能定出‘最优’的设计方案。

但沟通有时也是毫无生产力的，尤其是当我们陷入了对实现细节的争论时。

大连和武汉（我们公司的两个分部），在这方面可谓是两个极端，所以也体现出各自不同的优缺点。或者说真正的善，必须要做到不偏不倚，把握好度。 

 

武汉大多数情况是没有讨论的，产品经理大概的过一下需求，开发人员很快凭直觉给出了解决方案。这样做的缺点很明显，会经常有需求或者设计方案的变动。

但是也有自己的优点，就是能够快速投入开发，哪怕开始的方案是错误的。因为如果你的代码足够优雅，经常变动的方案并不会浪费你太多时间，有时相对于‘无休止的争论’，快速开发还是值得的。

（足够优雅是指，项目的每个小模块，做到高内聚，低耦合，且尽量无业务，无状态。当需要修改方案的时候，这些核心的原子模块已经实现了，修改方案不过是一些微调，不过是另一种组装。）

接下来说一下第二个优点。开发之前，无论你怎么讨论，所有的方案都只是假设，没有开发，很多的坑，很多的不合理，你根本就想不到；没有开发，你根本就想不到，很多的坑，很多的不合理，根本就不存在。

有时实实在在的开发，才能拨开迷雾，让真正的问题显现出来。

 

大连这边讨论的比较多（印象中想找大连的伙伴了解问题，大多是在开会^_^）。这次来大连，亲身体验 感受很多——特别是关于讨论。

第一次迭代关于课次的设计，考虑到上传和转码的耗时，从最开始的一个页面到最后的两个页面拆分，考虑到并发的情况，用写入version检查，最终的方案可谓是完全变了个样子，但是却是一个近乎完美的方案。第二次迭代，在修改上架课程班级，考虑到上架信息必须完整，也是改成了更好方案。
这种充分讨论带来的结果，给我的冲击很大——武汉是没有这样的，所以总是要花精力去调整方案，或和产品经理协调沟通！

当然大连这边有时讨论会过多。有好几次，明显感觉到不需要继续了，可是讨论却没有停止的迹象，时间就在无意义的讨论中流逝。好在这方面，大连已经意识到了，并且正在改进。

探寻解决方案

到底该讨论什么？

这不是一个好问题。因为讨论不只是和内容有关。

如果仔细推敲的话，讨论任何内容包括需求细节，技术实现，设计方案等，在某些时候是浪费时间，在某些时候却能给你的方案带来gift。大量的讨论经验也说明了这一点，任何内容都不是绝对的。
经常回想之前开会讨论的种种细节，想给这个问题写出一个答案，但是发现这根本不可能。

但是有一点是肯定的，人员的技术水平，表达能力，个人修养，做事态度，非常重要——优秀的人是开放的去交流，能大胆的抛出问题，更能及时的止住自己的交流欲望（或说服欲望）。及时的止住自己的欲望，既节省了时间，也照顾了别人！

 

还有一点可以肯定的是，有意义的讨论带来结果是 对既定方案进行修改和优化。
而这一点似乎是可以预见的。有时候明显的感觉到讨论是在浪费时间，可是讨论者却乐在其中。有时候讨论明显不足，方案明显不够确切，却匆匆进入了开发。

我们并不能要求每一个人员都是全方位的优秀，但是却可以让一个头脑清晰的人调控讨论的趋势。这也是我强烈建议的——安排一个主持人，并建议主持人不要是讨论的主角（讨论的主角是指，需求 方案 的关键阐述者和制定者）！

 

我的另一个建议是会议人员的互补，特别是性格上的互补。不同性格的人，思维方式，看问题的角度，做事风格不一样，正因为这样，‘完美’的方案才变得可能；但也正因为这样，融合好各个性格的人，是有一定的挑战的，这就是一个团队的魅力了。

外向性格的人，有发起讨论，并让讨论尽可能全面的可能，而内向性格的人，有制止讨论，并综合出完美方案的可能。遗憾的是武汉人员较少，性格基本相似，这也是武汉一直做不好的重要原因。