昨天下班后，我在加班。安静的办公室里，传来隔壁开发团队里3个开发同学在慷慨激昂地讨论问题：
FAN：“关键是怎么判断是活动期间的首充，又怎么判断是续充呢？”
LE：“你用时间判断就可以呀”
FAN：“客户是否充值我们获取不到呀，我这个系统只管活动。ZHANG，你来判断活动期间的首充吧”
ZHANG：“活动是你们做的，我又不知道充值跟什么活动有关”
。。。。。。
我听出来了，他们是在讨论正在开发的一个营销系统。
3位同事你一言我一嘴的还一直讨论不出个方案，我走近细听并了解遇到什么情况了。FAN介绍说，营销系统会涉及到诸如活动期间充值返利的活动，一般这样的活动内容包括活动期间充值会返钱或送优惠券等，不外乎首充满返、续充满返等形式。在系统实现方面，新做的营销系统和已经在线上运行的账户系统是2个独立的应用。即营销系统定义了活动规则，客户参与活动充值是在账户系统做的。
这么说，当然会存在营销系统有只活动、账户系统只有充值的情况，自然，这2个系统之间要通过远程服务调用。而3个同学的争执发生在：FAN做营销系统老跟ZHANG说你要取活动期间的充值，ZHANG负责账户系统不懂活动所以很puzzled。其实，解决这个问题很简单，负责账户系统的ZHANG只需公开一个接口就可以了：
接口描述：查询特定账户特定时间段内的充值记录
请求参数：账户标识、起止时间
响应值：一个满足条件的充值记录的集合
我把这个想法解释给3位，FAN同学请求接口，有了这些充值记录，就可以根据营销活动规则来做相应的处理了。大家听后简单思考后表示认可。
这样，这个激烈的讨论算是结束了。
这可能仅仅是一个案例，大家在工作中，可能会经常出现这样的沟通，大家面红耳赤，也解决不了问题。因为各自局限于自己的系统里，总觉得我需要什么你就可以给我，殊不知别人未必明白你做的东西。
身为一名有过一定经历的项目管理者/团队leader，我喜欢从成本和绩效方面考虑（参见我的博客《IT团队绩效提升的一些见解》），大家坐一起讨论了半天才有结论甚至讨论了半天也没有个结论，首先浪费了成倍的时间，时间也是成本，人力方面也是损耗；其次，这种会议产出不明显，低效，从而影响团队或项目绩效。很多的公司都强调有效/高效沟通，在沟通方式、态度、技巧方面大家要注意，另外，专业技能的掌握程度也同等重要。你跟卖猪肉的讲互联网+，恐怕他很难理解。
身为一名有过一定经历的应用架构师，我在接到项目时，习惯在系统分析后做系统设计时，会对关键的业务场景进行设计。本案例的场景对我来说算是小菜一碟了。因此，我在开发team里，经常会做一些系统设计的分享，并强调设计的重要性。BTW，系统设计的能力与技术能力并非息息相关，上面的FAN同学，在技术部是公认的技术达人，zookeeper、redis、canal都玩的很溜，java编程也很棒。系统设计更多靠的是思想，并未必学会了技术就能解决问题，或掌握的技术多或高深，就能解决更多的问题。参见《架构漫谈（九）：理清技术、业务和架构的关系》
