编写软件和在流水线上简单地组装产品可不一样。有些工作只需要几天培训和一些基本的工具就可以完成,如果有工人退出或离职(或者就是学不会),你只需要替换为另一个工人就可以了。在流水线环境里,员工通常只要机械性地完成简单的任务即可,而不需要什么创造性思维或是解决问题的本领。但在软件行业里,产品工程师则需要大量的创造性思维<sup>1</sup>,这就是说如果你想要出色的产品,那么就离不开出色的工程师。而且如果你希望这些出色的工程师能做出漂亮的产品(并且留住这些优秀人才的话),你就需要为他们建立起一种团队文化,让他们可以放心地分享创意,并且在决策过程中拥有发言权。
如果你想要优秀的工程师为自己的团队工作,首要的就是雇佣出色的工程师!这听起来有点奇怪,不过事实就是大多数优秀的工程师都喜欢加入那些拥有优秀工程师的团队。我们认识的很多优秀工程师都倾向那些可以向业界巨人学习的团队 <sup>2</sup> 。那么一开始的时候怎么才能吸引这样的工程师呢?
对于初创人员来说,他们需要的不仅仅是为产品开发贡献力量,更重要的是能参与到产品的决策中来,这通常就意味着某种程度的共识驱动管理。在自顶向下的管理模式中,首席工程师就是团队主管,其他工程师则被雇为团队成员。这是因为这些团队成员的成本比较低,也比较容易指挥。但是你很难在这样的团队里找到优秀的工程师,毕竟,要是能在另一家公司里主导开发的话,她何苦屈尊在这里听指挥呢?但是在共识驱动管理之下,整个团队都能参与到决策中来。
很多人一听到“基于共识决策的团队”时,立刻就会想到一群嬉皮士围着篝火唱着“Kumbaya”<sup>3</sup>,却做不了任何决定或是完不成任何工作的画面,但是这种固有印象其实更符合功能失调的团队所具有的症状,而非基于共识决策的团队。所谓的“共识”,是指每个人都对产品的成功抱有强烈的主人翁精神和责任感,同时团队的领袖也真的愿意倾听团队的意见(即HRT中“尊重”的部分)。这表示有时候产品成功需要反复的讨论和检讨,而有时候团队又必须搁置争议先行动起来再说。在后面这种情况下,团队成员会决定把日常的决策工作托付给一位或者少数几位领导 <sup>4</sup> 。为此,团队作为一个整体必须在大方向上达成一致,不管你信不信,要做到这一点,关键就是要为它设立一个章程(本章后面会详细讨论)。
和团队的决策过程同样重要的是同事之间的相处方式,因为这是最具备自我选择性的方面。如果你的团队习惯骄傲自大,对同事大吼大叫的话,你能吸引(和挽留)的也只能是这种攻击性极强、极端自我的人(事实上,我们认识的绝大多数女性对这种环境都非常厌恶)。如果你能建立起HRT的氛围,同事之间能友善相处,提出的都是经过考量的建设性批评,那么你不但能吸引更多的员工,而且大部分精力都可以分配在编写软件上。培养强烈的团队自豪感是好事 <sup>5</sup> 。若团队被个人的自负盖过,那就是灾难的源泉。我们会在第四章里讨论防止这种情况发生的办法。
建设性批评是任何工程团队成长发展的基石。接受批评是需要一定的自信心的,而我们觉得建设性批评是最容易接受的一种。另一方面,给出建设性批评要比直接批评嘲笑对方困难得多。而且我们也清楚,请别人批评指正是非常困难的事情,大多数人只会觉得你想听的是赞许和褒扬罢了。如果你身边有朋友和同事能在你需要的时候真正提出建设性批评,千万不要疏远他们,诤友难得。
如果你想要在工作上有所进步,或者改掉自身的坏毛病的话,这样的朋友和同事可以帮助你认识到阻碍自己成为优秀工程师的缺点。除非自我意识和自我反省的能力异常突出,在没有别人批评的情况下,你只会不断重复同样的错误——这就好像有人告诉你牙齿上有菜渣一样。例如,在本书出版的过程中,我们请了十几个人来帮忙审稿,告诉我们写作上存在的问题,这些建设性批评大都非常详细,是十分宝贵的意见。不管你是不是喜欢本书,如果我们忽略甚至不敢去请求这些珍贵的反馈的话,它只会比现在更糟。
攻击性性格的人(通常)也能够适应比较平和安静的环境,但是比较内向的人却很少能在激烈的环境里生存(或者开心地工作)——这样的环境下,他们的声音不但很容易被杂音盖过,而且会逐渐影响他们参与的积极性 <sup>6</sup> 。如果你想找一个能让大多数人高效工作的环境,那还不如自己去建立一个谦虚、尊重和信任的文化氛围呢!
建立在尊重之上,气氛随和的团队文化更容易受到性格激进的人的影响,其程度要大于随和的人对于激进的团队文化所产生的影响。因此随和的团队文化要特别小心这一点,不要被激进的新人牵着鼻子走,特别是要避免和这样的人发生激烈的冲突。有时候,团队的资深成员要挺身而出,正面迎击这样的新人,防止他们对团队的随和氛围产生破坏。我们在第四章里还会更进一步讨论对付这类“害群之马”的办法。
* * * * *
<sup>1</sup> 有的人认为只要雇佣一个超级架构师,再配几个普通程序员就可以做出好产品了。我们承认这的确是可行的,但是和一群能激发你的灵感、挑战你、教导你的优秀同事一起工作比起来,这种方式实在是太无聊、太无趣了。
<sup>2</sup> 优秀工程师还需要有优秀团队负责人的领导,因为糟糕的领队不但会在和优秀工程师打交道的时候显得不自信,通常还是那种喜欢瞎指挥人的家伙。
<sup>3</sup> 译注:指盲目乐观。
<sup>4</sup> 在无法达成共识的情况下,有些团队会将决定权交给负责人,而有些团队则会采取投票的方式。采用什么方式并不重要,重要的是要事先决定好在意见不同时采用什么方式来解决它,并贯彻之。
<sup>5</sup> 也就是集体荣誉感。
<sup>6</sup> 参见苏珊·凯恩在TED上的出色演讲——“自省的力量”(http://www.youtube.com/ watch?v=c0KYU2j0TM4)和她的著作《安静:自省的力量》。
- 内容提要
- 致谢
- 本书宗旨
- 对本书的赞誉
- 前言
- 第一章 天才程序员的传说
- 帮我把代码藏起来
- 天才的传说
- 隐瞒是有害的
- 团队才是王道
- 三支柱
- HRT实战
- 下一步
- 第二章 培养出色的团队文化
- 什么是文化
- 为什么要关心它
- 文化和人
- 优秀团队文化中的沟通模式
- 高层面同步
- 每日进行的讨论
- 使用bug跟踪系统
- 沟通也是工程的一部分
- 说到底真正重要的还是代码本身
- 第三章 大海航行靠船长
- 自然界没有真空地带
- @Deprecated Manager
- 主管才是新的经理
- 唯一要担心的就是……好吧,所有的事情
- 仆人式领导
- 反模式
- 领袖的处事之道
- 人是植物
- 内部激励和外部激励
- 结语
- 第四章 对付害群之马
- 什么是“害群”
- 保护团队
- 发现威胁
- 第五章 操纵组织的艺术
- 优点、缺点和策略
- 理想的情况:团队在公司里应该是怎么运作的
- 现实的情况:当环境成为成功路上的绊脚石
- 操纵你的组织
- B计划:走为上
- 不要放弃
- 第六章 用户也是人
- 管理大众的印象
- 管理和用户之间的关系
- 结语
- 附录A 延伸阅读
- 版权