下面每一段话都源于近半年的亲身经历，很多话是拥有十几年软件经验的老兵的原话。

　　当了pm，尤其是没有界面不需要Axure的底层Web Service的pm，依赖一支巨大的分布式团队，面对不止一家强势客户，交流就成了最关键的任务。半年前我还是中科院里一个不折不扣的技术宅男，与生人聊非技术话题有障碍，害怕给陌生人打电话，外出聚餐拿菜单看半天也不知道点什么。幸运的是，跳槽后碰到几位好上级，每次掉进坑里都能获得诚恳的建议，甚至专门帮我复盘。

　　我有每天记录想法的习惯，很多内容整理之后就发BLOG。但这个“团队交流”的主题等了很久。涉及公司内部信息，无法带上具体场景，很多血泪经验就成了糖水大道理。也因为积压太久，即使只放是糖水大道理，慢慢也存了很多段。不管怎样还是发出来吧。

　　公司一直在剧烈重组。以往我设计软件架构很少考虑人的交流因素。现在算是理解了著名的Conway’s Law: A design reflects the structure of the organization that produced it。这条定律的意思是：什么样的团队组织结构，最终就会开发出一模一样的软件架构。如果有四个团队合作开发编译器，系统最终一定会长成一个四阶段编译器。所以大型软件组织内，在重构系统之前往往先reorg团队。对分布式的团队，更加如此。前一阵很多人在Blog里写分布式团队的交流问题，用了很多招数，例如两边架起摄像头和大屏幕，形成一个虚拟的统一环境。

　　到飞天团队，发现与以前在pFind倡导的工程实践没太多区别：SVN、BugFree、定期重构、单元测试、站立会议、代码review……所不同的是执行。飞天主力是微软出来的，有软件工程基因。制度和团队平台给力，就算是大三实习生也能大展拳脚，两三天内完成千核并行复杂算法的剧烈重构和测试。实际上pFind团队规模已经很大了。飞天内很多小team总共才四五条枪，而且大多是本科刚毕业甚至实习生，有些专注于统计机器学习的算法团队，工程产品也非常宏大。这是人际沟通和工程效率问题，不是学术或工程的非此即彼的投资方向选择。对pFind感情很深，希望后继者有勇气和智慧做到我没能做到的。

　　敢提出傻问题是有责任心的表现。很多新人、边缘人、接口人都有交流障碍：不敢把点子或疑问拿到桌面上来，借口是：还不了解情况，等我彻底变成“自己人”再说。怕问错了显得不够牛，或者问对了牵涉别人的利益。明哲保身是动物本能，但它仅仅在黑暗森林低级生态环境下才算是最佳策略，在一个有序、专业、理性的团队里，过分谨小慎微只会显得无能，让别人放弃对你分享信息。反过来，直言不讳也是一种压力测试，可以借以观察团队氛围是否正常。

　　tech lead最重要的素质是充分沟通的勇气和器量，“领导和下属之间应该’下棋’而不是’打牌’，在信息对等的情况下决策。尤其是坏消息，必须第一时间告知下属，坏消息往往传得很快，最好让下属从你这里首先获知。”反过来，最愚蠢的举动就是伤害团队对自己的信任。情绪管理、私人利益、交流效率都对信任感造成影响。

　　网络公司的技术团队往往被分为前端团队、后端服务团队和基础平台团队。不同类型的团队交流和思考的方式不同。出色的基础平台团队，节奏感往往非常强，知道先做什么后做什么，一开始只做最难最重要的事。

　　需求分析的时候，用户经常是在告诉你怎么做（How），这些信息没用，你要问清楚他们的本质需求(What/Why)。用户说要什么就做什么往往死得很惨。福特说：“如果最初我去问顾客想要什么，他们一定会说：一匹更快的马”。

　　技术->项目->产品->服务，这是个漫长的进化过程。和一个陌生的技术团队聊，最重要的就是评估他们在这条打怪升级的不归路上位于何处。已经拥有成熟服务的团队会问你：“需要多大程度的可用性？我们的服务目前能达到五个 9，也就是一年无故停机最多5分钟。”（关于服务怎么运维，现在DevOps讨论很热，推荐看看这个）