0%

《极客与团队》书摘

本书是专门写给程序员看的团队管理书籍。比起其他管理书籍,这本书比较薄,才170多页。我没看此书此前,在自己项目管理中或多或少用了里面的一些理念,这本书很好的把精华写出来了。本书其实围绕如何维护一个健康有效率的社区,很多经验可以借鉴一下。

​ 此书分为六章。第一章以天才程序员开头,毕竟天才极少,还是要靠团队完成任务。由此引出去全书的主题:HRT(hummer respect trust),谦虚、尊重、信任。第二章培养团队文化,文化是啥?为什么要培养团队文化?以及一些好的方法。第三章把项目经理(主管)比作是大海航行的船长,”仆人式主管”,须为团队服务,然后还讲了领导的一些处世之道和激励。第四章将如何对付害群之马,保护团队。第五章如何管理团队组织。第六章程序员也要有服务用户意识,软件需要用户友好,需要包装和营销。

第一章 天才程序员的传说

帮我把代码藏起来

  • 人的本性——没有人喜欢人批评,特别是未完成的工作。缺乏安全感,可能会隐藏更大的问题。

天才的传说

  • 迈克尔·乔丹、莱纳斯·托瓦兹、比尔·盖茨。集体荣誉算在一个人身上。
  • 我们需要榜样的激励。

隐瞒是有害的

  • 闭门造车。
  • 确保失败尽早发生,尽快发生,经常发生。尽早分享不仅仅可以防止一开始就步入歧途和检验创意。
  • 公车因子,保证工作的可替代性。
  • 足够多的眼睛可以确保你的项目保持正确的方向。

团队才是王道

  • 软件开发是集体项目

三大支柱

  • 谦虚、尊重、信任

HRT实战

  • 放下自负

  • 学会批评和接受批评。建设性批评,谦虚的把问题归到自己头上。别把你的自尊和你的代码等同起来

  • 快速失败-学习-迭代

  • 不要等到完美的时候才出来,只要产品大致可以,就立刻把他按照原样公布给大众。

  • 事后检讨。”学到了什么”,”怎么改正”。

    简要
    时间线
    主因
    影响和损失评估
    立即修改正问题的步骤
    防止此事再次发生的步骤
    得到的教训
  • 为学习预留时间。人一旦攀至顶峰,往往就会停止学习。偶尔跳出舒适区,接受挑战。

  • 学习保持耐性。

  • 学会示弱。承认自己的无知

培养出色的团队

什么是文化

  • 团队文化就像是一块含有酵母的面团:酵母(团队创始人)能将菌群培养物植入生面团(团队新人),从而变成一块好吃的面包(团队)。
  • 团队文化不仅仅包含编写代码的方式或者是成员之间的相处之道,它还包含所有人都认可的经验、价值观、目标。

为什么要关心它

  • 接受有益改进,同时防御有害的激进变化的团队文化。
  • 将大部分的时间放在开发优秀软件上面。
  • 近朱者赤近墨者黑。自我选择。
  • 招聘文化契合度高的人。

文化和人

  • 让出色的工程师们放心地分享创意,并且在决策过程中拥有发言权。
  • 基于共识决策的团队。”共识”是指每个人都对产品的成功抱有强烈的主人翁精神和责任感,同时领队愿意倾听团队的意见。
  • 大方向一致,设立章程。

优秀团队文化中的沟通模式

  • 同步沟通,如开会,人越少越好。异步沟通,如Email,听众越多越好。

高层面同步

  • 任务宗旨。准确定义好产品的方向和范围。什么该做,什么不该做。任务宗旨应该是与时俱进的。
  • 开会要有效率。
    • 只邀请一定要参加的人。
    • 开会前要决定好议程,而且要事先通知所有人。
    • 达成目的后应提早散会。
    • 注意别跑题。
    • 尽量把会议安排在休息时间前后(比如午饭时间,下班前等)。
  • 地理分散的团队,除了用媒介沟通,还应该时不时的见见同事。
  • 设计文档。随项目变化而变化。权衡时间,不要唯设计文档论。

每日进行讨论

  • 邮件列表
  • 在线聊天

使用bug跟踪系统

沟通也是工程的一部分

  • 代码注释。一般是用来说明代码里缺失的部分,以及起得不好的名字,然后把代码的功能注释一遍。注释应该尽量解释为什么代码要这样写,而不是解释代码做了什么。
  • 在源文件署名。团队中,可以不署名,在版本控制中可以查到谁的修改。
  • 每个提交都经过代码审查。
  • 真正的测试和发布流程。高自动化,方便可以频繁发布

说到底真正重要的还是代码本身

大海航行靠船长

市面上写给经理们看的管理书很多,而本章却是专门写给那些客串管理的工程师看的

自然界中没有真空地带

  • 软件项目就和船一样:如果没人领航,那群极客只会闲坐在那里无所事事。

@Deprecated Manager

  • 以前的经理对待的员工的办法通常和赶骡车的马夫用的差不多:”萝卜+大棒”,但是工程师需要时间和空间进行创造性思考,这种方式不适应。

主管才是新经理

  • 经理要关心怎么干,而主管只负责设定大方向。

  • TL(技术主管,tech leader): 负责产品整体(或者部分)技术走向。

    TLM(技术主管经理,tech leader manager):除了负责产品整体(或者部分)技术走向,还需关系手下工程师的职业发展和愉快程度。

唯一要担心的就是……好吧,所有的事

  • 管理工作不好量化,会感到成就感低,但是要反过来想,如果领导一支优秀工程师组建的团队,那代码的产量能达到多少!

仆人式领导

  • 遵循HRT,消除官僚作风。

反模式

  • 反模式:雇佣听话的人。
  • 反模式:无视表现不佳的人。设定好一个期限,完成一些目标。目标要设的小点,循序渐进。手把手帮助表现不佳的员工。
  • 反模式:无视人际关系
  • 反模式:和谁都是朋友
  • 反模式:降低招聘标准
  • 反模式:把团队当小孩

领袖的处事之道

  • 放下自负,鼓励多提问,学会聆听,学会道歉

  • 做一个禅师。保持淡定和冷静。多问问题,引导工程师解决自己的问题。

  • 成为催化剂。引导大家达成共识。

    让你的团队了解到你的帮助他们解决障碍的意愿和能力。

    给与他们安全感,培养敢于冒风险的氛围。

  • 当一个导师。三个基本条件:

    • 熟悉团队的流程;
    • 向他人解释事物的能力;
    • 估计被指导的人到底需要多少帮助的能力。
  • 设置明确的目标。每个人都在同一方向上使劲吗?定期检查他们有没有偏离方向。

  • 坦诚。坦诚有些事不能告诉成员。避免使用”三明治赞美法”,这样可能不能准确传达自己的意图。直接了当反馈和批评,但是注意自己的表达方式,不要让工程师被你弄得很防备。

  • 记录快乐程度。不但关注职业生涯,更是可以让你的队员有机会得以成长。每次在会议结束之前问队员”你还有什么要求吗”

  • 其他建议和窍门:

    • 不必事事躬亲,但也不能当甩手掌柜;
    • 寻找接班人;
    • 知道什么时候做恶人;
    • 保护团队不受混乱干扰;
    • 帮团队遮风挡雨;
    • 告诉团队他们做得很好。

人是植物

  • 人像植物一样:有些需要更多的光照,有些则需要更多的水分。对应着方向和激励。

内部激励和外部激励

  • 达到内部激励目的的三样东西。
    • 自主。自主权,激发主人翁精神。
    • 精通。让工程师有机会学习新技能。
    • 目标。让他们知道自己的努力是有价值的。

对付害群之马(会拖累团队的人)

作者是结合自己的实际,由于SVN项目是开源项目,里面涉及到很多外部人员的相处之道。

什么是”害群”

  • 是指行为,而不是指人。规定好哪些是不可容忍的行为,然后予以惩戒。

保护团队

  • HRT
  • 第二章内容

发现威胁

  • 团队的注意力和专注力最容易受到威胁。
    • 不尊重别人的时间;
    • 自负;
    • 过分索求;
    • 幼稚或是莫名其妙的交流;
    • 偏执妄想;
    • 完美主义。转移注意力;
    • 别去搭理哪些挑衅的家伙;
    • 别太感情用事;
    • 抓住重点;
    • 对付挑衅要不卑不亢;
    • 关注长远。问自己两个关键的问题:
      • 虽然短期内会损失一些注意力和专注力,长远来讲你真的相信项目会因此受益吗?
      • 你相信这些冲突最终会以有益的方式解决吗?

操作组织的艺术

优点、缺点和策略

理想的情况:团队在公司里应该是怎样运作的

  • 在完美经理手下干活。要求更多的责任,不单要专注手头的任务。
  • 用于冒险

现实的情况:当环境成为成功路上的绊脚石

  • 在糟糕的经理手下当值。特点:害怕失败,缺乏安全感,保守,自私
  • 办公室高手,敬而远之。
  • 糟糕的组织。不以工程师为核心,鼓吹商业

操纵你的组织

  • 向上请求许可,向下请求谅解。

  • 路是人走出来的。寻求改变的办法就是拉拢群众。

  • 学习向上管理。做承诺的时候要谨慎,而干工作的时候要尽最大努力。

    “进取型”(用户看得到的)和”防御性”(产品长期健康的)工作。

  • 运气与互惠的经济学。

  • 晋升到安全的位置。掌控自己在公司的命运。

  • 和有能量的人交朋友。

  • 如何通过E-mail向忙碌的管理层求助。10秒钟读完,”三个论点,一个行动”。

B计划:走为上策

  • 只做正确的事,随时准备被炒

不要放弃

用户也是人

主要是用户体验方面的。营销、易用性、客服

管理大众的印象

  • 软件也需要营销
  • 关心用户对软件的情感诉求
  • 注意第一印象
  • 承诺的时候要谨言,做产品的时候要超过预期
  • 尊重业界分析师
  • 关注用户,其他东西会随之而来
  • 目标用户
  • 考虑入门的门槛
  • 衡量使用数量,而不是用户数量
  • 速度很重要
  • 不要大而全。与其拙劣地解决所有问题女,还不如解决大多数用户都真正会遇到的问题,然后做到最好
  • 隐藏复杂性

管理和用户之间的关系

  • 听取用户反馈
  • 不要有优越感
  • 保持耐心
  • 营造信任和愉悦的氛围

欢迎关注我的其它发布渠道