离线下载
PDF版 ePub版

梦里风林 · 更新于 2018-11-18 08:00:36

服务你的团队

如何发展才能

Nietschze 夸大了他所说的:

杀不死我们的,只会让我们更强大。

你最大的责任是对你的团队负责。你应该非常了解他们中的每个人。你应该激励你的团队,但不要让他们过劳。你通常应该告诉他们他们被激励的方式。如果他们觉得划算,他们会被很好的激励。每个工程中,或者在每个其他的工程里,试着同时用他们建议的以及你认为对他们好的方式去激励他们。激励他们的方法不是给他们更多工作,而是给他们一个新的技能或在团队里扮演一个新的角色。

你应该允许人们(包括你自己)偶尔失败,并且应该为一些失败预留一些时间。如果从未有失败,冒险也就没有意义。如果没有偶然的失败,说明其实你没有足够努力。当一个人失败了,你应该尽可能温柔地对待他,不该把他们当做成功了那样子。

为了让每个团队成员被充分激励,问清楚他们中的每个人,如果他们没有动力的话,他们需要什么才能被充分激励。你可能需要让他们保持不满意的状态,但你需要知道每个人需要的是什么。

你不该因为这样的原因放弃,或者让一些人松懈:他们士气低落或者不满因此故意没有承担分担到的责任。你必须试着让他们充分被激励并且有效率。只要你有耐心,坚持这样做。当你的耐心耗尽时,就解雇他们吧。你不能允许故意不司其职的员工留在团队里,因为这对团队不公平。

通过在公众场合这样说,让你团队中的强大成员清楚地知道他们是强大的。表扬应当公开,批评应当私密。

团队中的强大成员会自然地比弱的成员有更多困难的任务。这是完美而自然的,没人为因此困扰,因为每个人都努力工作。

一个在工资中没有反馈出来的奇怪的事实是,好的程序员比十个糟糕的程序员要有效率得多。这导致了一种奇怪的现象。通常,如果你们的弱程序员不挡道的话,你能跑的更快。如果你这样做了,事实上你在短期能取得更多进度。然而, 你的交易会失去一些重要的好处,叫做对弱小成员的训练,对集体知识的传递,失去强大程序员后的恢复能力。强大的程序员对这种现象应该温和些,并且从各种角度去考虑这个问题。

你经常能够给强大的团队成员有挑战的,但细致描绘的任务。

如何选择工作的内容

你需要在你个人的需要和团队的需要间权衡,选择需要做工程中的哪个部分。你应该做你最擅长的东西,但是也要试着去找一种方式来激励自己,不是通过承担更多的工作而是通过练习新的技能。领导才能和交流能力比技术能力更重要。如果你非常强大,承担最困难或最有风险的任务,在工程中尽可能早地完成这部分,以此减少风险。

如何让你的队友的价值最大化

为了让你的队友的价值最大化,发展好的团队精神,试着保持每个人的个人挑战与渴望。

为了发展团队精神,文化衫与聚会是有益的,但不如对个人的尊重。如果每个人尊重其他的每个人,没有会想要让其他任何人失望。团队精神产生于人们为团队做出牺牲,优先思考团队的利益而非自己利益的时候。作为一个领导者,在这个方面,没有付出就没有收获。

团队领导力的一个关键是促进团结,这样每个人都会听你的。有时候这意味着允许你的队友犯错。也就是,基于这种团结,如果对项目没有太大的损害,你必须允许你团队的一部分成员用他们自己的方式做事,即使你有很大的信心认为这是一件错事。当这种情况确实发生时,不要同意他们的观点,简单公开地反对之,然后接受这种团结。不要让人觉得你受伤了,或者认为你是被迫的,简单地陈述你不同意,但认为团队的团结是更加重要的。这经常会导致他们反悔。如果他们真的反悔了,不要坚持他们一开始的计划。

如果在你们从所有合适的角度讨论了这个话题后,有个人会反对,简单地告诉他们,你必须做一个决定,并且这就是你的决定。如果有方法去评估你的决定是否是错的,或者它稍后是否是错的,尽可能快速切换,并感激那个对的人。

询问你的团队,包括集体与个人,这样一个问题:他们认为什么能创造团队精神以及创造一个高效的团队。

经常表扬,但不要浪费。尤其是表扬那些反对你且确实值得表扬的人。公开表扬,私下批评。但有这样一种例外:有时候进步或者纠正一个错误但却没有注意到错误的根源,是不能被表扬的,这种进步应该私下表扬。

如何划分问题

接手一个软件工程并把它分为可以由个人实现的任务是很有趣的。这事应该及早进行。有时候经理可能会认为不考虑个人的项目能够起作用。这是不可能的,因为每个人的生产力是如此广泛地不同。对某个组件有特殊知识的人也经常改变,并且可以对工作效果有一个数量级的影响。

正如一个作曲家认为乐器的音色会其重要作用,或者运动队教练对每个运动员的体能的考虑那样,有经验的团队领导,通常不能够把工程依据团队成员需要承担的角色那样划分成一个个的任务。这是好的团队不容易解散的一个原因。

因此有这样一种危险:人们在锻炼自己的能力时会感到无聊,并且不会提高他们的不擅长的方向或者学习新的技能。然而,如果不被过度使用的话,精通是一个非常有用的生产工具。

如何处理无聊的任务

有时候避免对公司或工程的成功至关重要却很无聊的任务是不可能的。这些任务可能真的会降低那些必须执行它们的人的斗志。最好的处理方法是使用或者发扬 Larry Wall 的程序员懒惰美德。试着找一些方法让计算机去做这个任务,或者帮助你的队友去做这个。用一个程序花一个星期去完成要手动去用一个星期完成的任务能让你懂得更多,并且有时候这是可重用的。

如果所有其他的途径都不能工作,为那些必须做这个无聊任务的人道歉,但无论什么情况,不要让他们去单独完成它。至少安排一个两人团队去做这个事情,并增强健康的团队协作来完成这个任务。

如何为工程获取支持

要给工程获取支持,需要创建并交流一个能够证明这个组织整体的真正价值的愿景。试着让其他人分享他们对你的创造的愿景的观点。这给他们一个理由去支持你并给予你他们的智慧。独立地为你的工程补充关键的支持者。不论在什么可能的地方,展示,但不告诉。如果可能的话,构建一个原型或者一个模型来证明你的主意。一个原型总是有力的,但在软件中,它比任何书面的描述都要高级得多。

如何发展一个系统

树的种子包含了成长的思想,但不完全实现成长体的形式与力量。胚胎会成长。它会变大。它看起来更像成长体,并越来越有用。最终它孕育果实。最后,它死亡并且它的躯体喂养了其他的有机体。

对待软件我们也应当有这样的荣耀。一架桥不是这样的,永远不会有一架婴儿桥,但只是有一座未完成的桥。桥比软件要简单得多。

认识到软件的成长是有益的,因为这允许我们在有一个完美的思维图景前取得有用的进步。我们可以从用户那里获得反馈,并用之纠正这种成长。修剪掉疲软的四肢才能健康。

程序员必须设计一个完成的可分发可使用的系统。但高级程序员需要做的更多。你必须设计一个终于完结系统的成长路线。你的工作是,得到一个想法的萌芽,然后把它尽可能顺利地变成一个有用的人工制品。

因此,你必须模拟最终的结果,用一种工程团队可以为之雀跃的方式去交流。但你也必须和他们交流一条非跳跃式的路径,从他们所知到他们想要成为的地方去。在整个过程中,这棵树必须活着,它不能在什么时候死去,然后又复活过来。

这条路径会是螺旋发展的。里程碑之间永远不会太远,这对于在路上取得进步是有用的。在极端的商业环境里,如果里程碑可以实现并尽早赚钱是最好的。,即使他们离良好设计的端点还有很远。程序员的一个工作就是通过理智的选择用里程碑表示的成长路径来平衡即时的报酬与将来的报酬。

高级程序员对软件,团队,个人的成长有集体责任。

一个读者,Rob Hafernik,在这一节中写下了这样的评论:

我认为你过低强调了这里的重要性。不仅是系统,还有算法,用户界面,数据模型,等等。当你工作在一个大的系统中,必须有即时目标相关的可测量的进步时,这些也是至关重要的。没有什么比抵达终点却发现一切都不能工作更加恐怖(看看最近的投票新闻系统的崩溃吧)。我甚至想进一步把这当做自然的法则:没有庞大,复杂的系统可以由碎片实现,这只能由一个简单的系统循序渐进成长为一个复杂的系统。

对此,我们只能回答,要有光

如何有效地沟通

为了良好地沟通,你必须认识到它的困难。它本身就是一种技能。与你交流的人本身是有瑕疵的,这一事实使得沟通变得更加困难。他们不会努力去理解你。他们不善言辞。他们经常过度工作或者无聊,至少,有时候只关注他们自己的工作而非你要发表的长篇大论。上课,练习写作,公共演讲,聆听,这些东西的一个好处是,如果你擅长它们,你可以更容易看到问题所在以及解决方法。

程序员是一种社会动物,他们的生存依赖于与团队的交流。高级程序员是一种社会动物,他们的满意依赖于与团队外的人的交流。

程序员从混沌中带来秩序,一种实现这一目标的有趣方法是从外部的一个提议开始。这能用稻草人白纸模式或者口头的方式来完成。这种领导对于让团队置身于辩论中有极大的好处。这也把你暴露到批评,或者,拒绝与否定中。高级程序员必须准备好接受这些,因为他有特殊的能力,也因此有特殊的责任。非程序员出身的企业家需要程序员在某些方面提供领导。程序员是思想与现实之间的一部分桥梁。

我没有很好地掌握沟通的技巧,但我正在尝试的是一种四叉路径:在我有了一些有序的主意并且充分准备好后,我试着口头表达,交给人们一张白纸(可能是真实的纸,也可能是电子的)来给他们展示一个 demo,然后耐心地重复这个过程。很多次我想过,我们在这种困难的沟通里还是不够耐心。如果你的想法没有马上被接受,你不应该丧气。如果你在准备中投入了能量,没有人因此会看低你。

如何告诉人们他们不想听的东西

你会经常需要告诉人们一些让他们不舒服的事情。记住,你必须为某种原因才这样做。即使没有什么可以用来解决这个问题,你也该尽早告诉他们,这样他们才能充分警觉。

向别人指出一个问题的最好方法是同时提供一个解决方案。其次的方法是呼吁他们寻求帮助。如果你可能会不被信任,你应该为你的主张寻求支持。

一种你必须说的最不舒服且普遍的事情是“时间不够”。尽责的程序员讨厌这样说,但必须尽早说。没有什么比 deadline 抵达,不得不推迟进度更加糟糕,即使唯一的行动是通知每个人。更好的做法是,作为一个团队整体来做这件事,如果物理上做不到,至少是精神上这样做。你会想要得到你的团队对你的观点以及你为之所做的事情的支持,团队必须与你共同面对这样的后果。

如何处理管理神话

神话这个词有时候意味着虚构。但这有着更深层的内涵。它也意味着一些宗教内容来解释宇宙和人类与之的关系。管理者倾向于忘记他们作为一个程序员时学到的东西,并且相信某种传说。试着让他们相信这种传说是错的,正如让一个虔诚的宗教信徒从他们的信仰中醒悟过来一样粗鲁而失败。因此,你应该认可这些信仰:

  • 文档越多越好。(他们需要文档,但他们不会想要你在这些东西上花时间。)
  • 程序员是平等的。(程序员可以按重要程度分类。)
  • 分配更多资源给迟来的项目可以让它加速。(与新人的交流的代价大多数时候很繁重并且无用。)
  • 程序员的效率可以用一些简单的标准尺度来度量,比如代码行数(如果简洁才是力量,那么代码行数是坏的,而非好的。)

如果有机会,你可以试着解释这些东西,但如果你没有成功,不要觉得悲伤,不要好斗地反对这些神话以致损害了你的声望。每个这样的神话增强了管理者关于他们有一些对正在进行的事情的实际控制的想法。真相是,如果管理者是好的,他们会帮助你,如果他们是坏的,他们会妨碍你。

如何处理组织混乱

经常会有短暂的组织混乱,比如解雇,收购,IPO,新雇佣,等等。对每个人来说这都是令人不安的,但可能对于那些将自尊建立在能力而非位置上的程序员来讲,这种不安不会那么严重。组织混乱对程序员来讲是锻炼他们的魔力的好机会。因为这是一个集体秘密,在最后我会有所保留。如果你不是一个程序员,就不要再读下去了。

工程师有能力创造与维持。

非工程师可以安排人们,但,在典型的软件公司,如果没有程序员的话,他们不能创造与维持任何东西,正如工程师通常不能有效地销售产品或者管理商业。这种力量对于大多数与临时组织混乱相关的问题是一种抵抗。如果你有这种力量,你应当完全忽视这种混乱并当做什么都没发生那样坚持下去。你可能,当然,被解雇,但如果这发生了,你可能因为这种力量得到新的工作。更普遍的,一些紧张的没有这种魔力的人会进入你的空间并告诉你做一些蠢事。如果你真的确信这是一件蠢事,最好的做法是微笑,点头,直到他们走开,然后继续做你认为对公司最好的事情。

如果你是一个领导者,告诉你的员工做一样的事情,告诉他们忽视其他任何人告诉他们的东西。这种行为的过程对你个人是最好的,对你的公司或工程也是最好的。

上一篇: 机智地妥协 下一篇: 词汇表