软件研发和团队交流

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

  当了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讨论很热,推荐看看这个

1 thought on “软件研发和团队交流

  1. 孟佳明

    “傻问题”一段写得不错,写出了我长久以来的心境,这一点意识到容易,改变起来的确需要勇气,需要时间。刚进组师兄就走了,不曾交流过,我也是软件工程出生,对架构设计的热情多于算法创新,以后多来你博客上逛逛吧。

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.