背景：MCM从2004年8月份起开始执行行业技术交流制度，规定各个行业固定在中层干部述职会结束后一周的星期5或星期6进行。技术交流会制度一来是加强企业内的技术沉淀，二来是让新人接触到业内的一些新东西。在8月份举办的第一次交流会中，由小M（姓麦）给大家讲解了OLTP在社保中的应用。
交流过程：首先行业总工Z总（姓张）分发项目交流资料《李冰和都江堰》；大家利用15分钟的时间阅读资料，阅读过程中可以讨论；然后大家将认为都江堰工程成功的因素写在纸条上，每张纸条只写一条成功因素；最后由Z总统计，并对其逐个说明。当得出最后结论后，Z总再把别人总结的因素与我们的答案对比，找出其中的差别。
资料斜体字摘录：1. 于是他开始对岷江两岸进行实地考察，他和儿子二郎一起，行程数百里，沿岷江逆流而上，亲自勘查岷江的水情、地势等情况；2. 确定了治理岷江的周密方案；3. 组织了上万民工；4. 民工的热情非常高，干劲十足；5. 但是由于开始时施工没有经验，加上玉垒山山石坚硬，工程进度极其缓慢；6. 有一个很有经验的老民工建议；7. 李冰为了观测岷江水位，做了三个石人并把它们立于江中；8. 李冰还建立了维修制度；9. 深沟滩，低做堰；10. 清明节前后的放水日就成为当地人民一个盛大的节日，每年这一天都要举行盛大的放水仪式。
评述：这是一次非常有意义的交流会，其意义在于通过讨论、淘汰备选方案、总结等方法提高了参与度。虽然Answer不一定是标准答案，但重在组员能过程学到讨论的Skill。这个技巧可以直接类比软件工程中的需求分析，对以后各项目组开展具有一定的意义。
从事软件业务的朋友们经常会开一些研讨会、攻关会，但有时候讨论的内容过于空泛、过于理论，会上总是一些人说这个一些人说那个，结果最后得出的结论反而不统一，会后甚至还嘀嘀咕咕。那么为了避免这种情况最好的办法就是量化，说白了就是找个解决办法，2种意见咱们就用淘汰法，3种意见就用专家法…… 总知还是那句话“有办法比有想法实际许多”。
此次交流会还把都江堰和长城做了个比较，其结论是都江堰是成功工程但我们通篇都没有看到它的成本控制；而长城则更是失败，不光质量有问题（孟姜女哭倒长城——一哭就倒，难道是好工程），而且修筑的周期过长、成本过高。