极客与团队:软件工程师的团队生存秘笈

极客与团队:软件工程师的团队生存秘笈

暂无评价综合评分的显示会考虑用户真实性等多项因素,每部作品出现综合评分的时间不定。

作品简介

《极客与团队:软件工程师的团队生存秘笈》是一本写给程序员看的,教你怎么交朋友,怎么影响团队中的其他人。书中充满了操作性极强的建议和意见,让你在技术团队中过得更开心,变得更有效率,更加如鱼得水。本书旨在帮助程序员改进理解他人,与人沟通,以及与人合作的能力,进而在编写软件的过程中变得更有效率。

布莱恩·傅攀勃现在是Google数据解放阵线和透明度工程两个团队的负责人,之前他还领导过Google的项目托管团队以及电子商务伙伴团队。他帮忙建立了Google芝加哥分部,并且为Google在开放数据上提出了很多想法和建议。 本·科林斯-萨斯曼是Subversion的初创成员之一,领导过Google的项目托管团队,现在是Google电子商务伙伴团队的负责人。他帮忙建立了Google芝加哥分部,并将Subversion移植到Google的BigTable平台上。

作品目录

热门划线

  1. 确保失败尽早发生,尽快发生,经常发生5 人
  2. 反模式:无视表现不佳的人5 人
  3. 反模式:雇佣听话的人4 人
  4. 不要低估社交的力量。社交不是勾心斗角,或是操纵别人,它是通过建立起人与人之间的关系来把事情做成功,而且这种关系延续的时间肯定比项目本身更长。3 人
  5. 共识决策3 人
  6. 反模式:和谁都是朋友3 人
  7. 反模式:降低招聘标准3 人
  8. 反模式:把团队当小孩子3 人
  9. 不管技术债务有多少,团队也永远不应该花超过三分之一甚至一半的时间和精力去做防御性的工作,否则就等于政治自杀。3 人
  10. 一个项目成功的关键不仅仅是写出漂亮的代码:所有人向着同一个目标一起合作也是同样重要的。2 人
  11. 真正做出产品之前不愿分享好创意实际上是一场很大的赌博,你很容易在一开始就犯下很基本的错误,你有可能是在重新发明轮子2 人
  12. 尽早分享不仅仅可以防止一开始就步入歧途和检验创意,它还可以强化所谓的“公车因子”。公车因子(名词):一个项目里,需要有多少人被公车撞到才能令其完全瘫痪。2 人
  13. 公车因子(名词):一个项目里,需要有多少人被公车撞到才能令其完全瘫痪。2 人
  14. 基本上所有的社交摩擦最终都是由于缺乏谦虚、尊重,或是信任而造成的。2 人
  15. 别把你的自尊和你的代码等同起来2 人
  16. 快速失败;学习;迭代2 人
  17. 你越是容易受影响,你就越能影响别人;你越是示弱,你就越强壮。2 人
  18. 接受意见改变自己没什么大不了的。不要随意挑起争斗。不要忘了,要别人听你说话,首先是要学会当一个听众。注意在被影响的时候,如果你要听取意见,一定要在你下定决心或是确定宣布你已经做好决定之前——要是你的主意老是改来改去的,别人会觉得你这个人没什么立场。2 人
  19. 沟通的指导原则之一就是在同步沟通的时候(比如开会),人越少越好。而在异步沟通的时候(比如E-mail),涉及的听众越多越好。2 人
  20. 任务宗旨可以帮助团队求同存异2 人
  21. 开会要有效率2 人
  22. 有关开会的五条小贴士:1.只邀请一定要参加的人;2.开会前要决定好议程,而且要事先通知所有人;3.达成目的后应提早散会;4.注意别跑题;5.尽量把会议安排在休息时间前后(比如午饭时间,下班前等)。2 人
  23. 主管为团队铺好道路,为他们解决各种后顾之忧,同时还要设法满足员工的需要。2 人
  24. “希望可不是一种策略。”2 人
  25. 尽快处理表现不佳的人的好处就在于你还有机会帮他的忙。假如你立刻出手,常常会发现他只是需要一些鼓励,或是点拨一下就能大大提高生产力。但是如果耽搁久了,他和团队的关系就会变得棘手,你也会因为没办法再帮忙而感到失望沮丧。2 人
  26. 规定好一个期限(比如两到三个月),然后设定一些你希望他达成的目标。目标要设得小一点,循序渐进,这样才有机会累积很多小成功。每周都要跟他碰个头检查一下进展情况,每个里程碑的目标都要清楚无误,这样才能轻易衡量成功和失败。如果他跟不上,双方也都能在一开始就意识到。这样,他也能认识到不足,自觉退出。反之,他会鼓起雄心不辜负期望。无论如何,只要手把手地帮助表现不佳的员工,你都可以借此激发必要的重大改变。2 人
  27. 反模式:无视人际关系2 人
  28. 设置明确的目标2 人
  29. 只做正确的事,随时准备被炒2 人