什么是人件
人件这个词是作者独创的, 是参考硬件,软件而来的, 我们常常视硬件软件为公司的核心资产, 但却忽略了人的价值. "人件"的定义就是希望我们对人的管理引起重视, 把人看成是公司的重要资产去培养和投资. 这本书的亮点在于作者觉得在软件领域有自己的一套管理方法, 和传统的管理方式是不同的, 书中也常常提到这两者的差异, 并进行了论证.
社会性因素
作者首先提到一个观点, 软件系统的主要问题不在于技术, 而在于社会性因素. 这个观点对于认为技术为王的管理者来说是个很大的震撼.
从研究来看, 没有一个单纯是因为技术问题而失败的项目. 而"政治"是受访者最常提及的失败原因. 政治归根到底是人的问题, 包括沟通问题, 人员安排问题, 团队协作问题等等.
我们有时候在做项目管理也知道, 一个人能力不管多强, 也无法完成一个庞大的系统, 如何集众人之力完成一个靠一个人无法完成的目标, 做到 1+1>2 的效果, 我们在工作中也常常遇到这样的问题. 但我们为什么还对人的问题没有引起重视呢. 作者认为是管理人员有高科技幻觉.
高科技幻觉
我们的管理人员一般是从技术能力拔尖的人中挑选出来的, 因为能力不行很难服众. 但往往是这群人对技术有种天生的向往. 觉得技术能解决大部分问题. 而且技术问题相对是可控可解的, 而人的问题是难以琢磨, 因人而异的, 因而希望用技术来解决人的问题.
传统的管理学里面也希望用流程和方法论来管理员工, 无论是高矮胖瘦, 只要按照这套方法去做, 都能有不错的产出. 传统的管理学和技术一结合, 就有很多自动化的流程和工具可以去实现. 无法否认技术确实能提升管理效率, 但也要小心对大家造成负面的伤害, 因为软件行业有自己的特点.
在工厂内能提效的手段不一定适合软件开发.
- 工厂不允许犯错, 但软件行业应该鼓励犯错, 这样才能发挥大家的创造性.
- 工厂通过各种方式push大家去工作, 而在软件行业里面应该发挥大家的主观性.
- 工厂的员工替代成本很低, 因为都是流程化的, 每个人都是一颗小螺丝. 而软件行业人员替换成本很高. 觉得不高的大多应该不是一线的管理者.
- 工厂里面员工应该比较趋同, 才比较好管理. 而软件行业里面应该允许员工有自己的独特性, 因为独特性能使团队产生化学反应, 是团队活力和效率的源泉.
- 工厂里面的人不需要团结, 每个人干好自己的事情就行了. 而软件行业里面即使是一个能力不是很强, 但能让团队更有凝聚力的人抵得上一个单纯做事的人.
- 工厂里面掌握一门技能就能长期适用. 而软件行业里面的人需要不断学习.
西班牙理论
西班牙理论就是认为世上只有固定的价值，因此，财富的累加之路是更有效率地从土地和人身上榨取价值。
最直接的体现就是加班, 是无偿的那种.
虽然短期内可能能提升产出, 但长期来看产出会更低. 原因有几个
- 员工会反抗, 会上班摸鱼, 真正的产出和不加班差不多.
- 员工可能会流失, 员工的离职成本很高.
- 牺牲产品质量.
第2,3点的显式成本不高, 但隐式成本却很高. 而且也是相互影响.
员工离职成本
- 显式成本: 书中提到 招聘成本 1-2 个月工资. 熟悉成本 4-6 个月工资.
- 隐式成本: 项目延期损失. 员工短视带来的质量问题.
产品质量低的成本
- 显式成本: bug多一些.
- 隐式成本: 员工赶工导致的维护性问题. 员工的自尊受打击, 可能会离职.
在大部分业务系统里面, 软件的可维护性不是很好衡量, 代码写得好和写的不好, 对于短期项目来说没什么大的影响, 但对于长期维护和修改的项目来说维护成本差的非常远. 软件行业的人都清楚, 从短期来看, 事务脚本的模式写起来最快, 但从长远来看, 面向对象的模式可维护性才是最好的, 但在设计层面上要花比较多的功夫. 很难要求一个离职率高的公司的员工会面对加班的压力写出可维护性高且健壮的代码.
质量是免费的
这句话容易让人产生误解, 觉得质量不用单独投资, 系统有时候有bug也不是不能用, 要花几个月时间去修bug做优化成本太高.
作者认为: 只有为质量拼尽全力, 质量才是免费的.
因为对于高质量产品带来的收益, 投资质量这点成本显得微不足道. 质量和产出并不是成反比的, 而是成正比的. 提高质量的同时也会提高产出. 前面提高的系统的可维护性就是软件行业的直观例子, 提升代码质量能有效提升后面的产出. 另外优秀的员工对质量也会有执着的追求, 会天然排斥只追求短期产出而忽视质量的行为, 选择更好的环境.
帕金森定律
作家帕金森提出一个概念: 工作会不断拓展, 直到用完为之分配的所有时间. 这个常常在项目管理里面也会学到这个定律, 告诫管理者要控制范围和时间.
但从调查研究的结果显示, 帕金森定律并不具有普适性. 对于一个项目的生产力来说, 第三方相对准确的估时和程序员自己进行估时甚至不进行任何估时对比由管理人员相对不靠谱的估算, 程序员的生产力会更高.
生产力对比如下 没有估算 > 系统分析师估算(相对准确的估算) > 仅程序员估算 > 管理者估算
其实也就否定了希望通过减少估算时间来提高生产力的做法. 每个项目或者迭代一般都有明确的发布时间, 因此不估算可能不太现实, 但估时应该尽可能通过在一线的员工来评估, 且不应该以压缩估时为手段去强迫提高生产力. 把你团队成员当成帕金森型的员工只会消磨他们的一直, 让他们失去前进的动力.
给一个项目的进度施加压力, 应该像惩罚孩子一样, 如果平时很少惩罚, 而且时机也恰到好处, 那么惩罚就可能起作用. 如果经常惩罚, 无效的同时可能还会有很大的副作用.
这点可能和我们平时的感知不同, 马斯克在新书里面也有提到他喜欢给团队定一个看似无法按期实现的目标, 目标虽然可能确实没法按期达成, 会存在延期. 但也比之前预估的时间要少很多. 以此来激发团队潜能, 提高生产力. 我觉得这种方法的风险还是太大了, 在短期内质量和时间确实是成正比的, 团队很容易牺牲质量来提升速度, 而且员工也有离职的风险. 在马斯克的书中也常常看到优秀的员工看不惯马斯克而离职的情况. 但提升速度的方式有很多, 如果团队是通过消除官僚主义来提升速度, 那质量可能还会提升, 马斯克的deadline使得生产力提升也有归功于此. 有兴趣可以看看埃隆马斯克的新书<埃隆马斯克传>.
管理没有银弹
错误的认识
作者痛斥了下面的几种错误的认识
有让生产力飙升的方法.
从作者经验来看, 虽然方法很多, 但没有一个能让生产力飙升的. 如果有的话一定已经很快普及了.
其他管理者效率正以100%,200%甚至更高在提升.
软件开发有以自己的开发周期,很难进行压缩.
技术更新换代非常快.
软件开发行业实际上很平稳, 很大一部分时间都是花在低技术含量的需求和规范上.
换编程语言会带来巨大的效率提升.
换编程语言的本质也是希望技术给生产力带来巨大的改变, 但从笔者看来, 水平低的员工不管是什么编程语言都能写出可读性差的代码, 反之亦然. 编程语言只是封装了机器语言, 但其实还是按照机器的思路去实现逻辑. 而程序员的价值在于对业务知识到机器可读语言的转换. 从需求的细化到模型的设计和实现, 编程语言都很难提升我们的效率. 编程语言只是一个工具, 用的好不好取决用的人.
因为工作大量积压, 你需要马上让生产力翻倍
正确的做法应该选择优先级最高的工作去做, 而非寄托于生产力翻倍上面.
与是不是把手下的软件开发人员也自动化了
目前大火的AI能让软件开发人员也自动化吗? AI看来目前更多也是作为工具, 无法替代人类.
如果给员工多施加一些压力, 他们会做的更好
他们不会, 他们只会更讨厌工作.
管理者的作用
管理者的作用不是让员工去工作, 而是创造环境让他们可以顺利工作. 管理者应该更关注于环境, 而非打扰员工的工作.
办公环境
办公环境非常影响程序员的效率.
程序员需要更大的个人空间
研究表明程序员最小需要100平方英尺的独立空间, 30平方英尺的工作桌面. 如果太小会影响效率. 作者发现一个企业人越多, 人均独立空间就越少. 很容易理解从显式成本来看, 空间越小成本会越低, 但隐式成本则是员工生产力的降低. 而一个企业很大部分的成本是人力成本, 从这点来看, 为了降本而缩小空间是捡了芝麻丢了西瓜.
程序员需要更安静的空间
调查发现越安静环境的程序员的bug更少. 虽然程序员可以戴耳机, 但戴耳机也有一定程度影响创造力. 因此开放式工位并不是一个好主意, 更建议把"门"加上, 以频繁交流的员工作为小的单位去分割空间会更适合一些.
程序员不应该被频繁打断
心流是指一种人们在专注进行某行为时所表现的心理状态, 对于脑力劳动者来说, 心流的状态的效率才是最高的. 而进入心流状态是需要时间的, 频繁打断会导致无法长时间进入心流状态, 影响工作效率. 管理者应该尽可能保护员工不受非必要的打断. 员工经常"躲起来"办公就是在反抗这种打扰.
程序员应基于心流来计算工时
E因子 = 不被打断的时间/出勤时间 (E因子越大才能代表生产力更高)
比较理想的环境
理想的环境应该追求有机秩序, 不千篇一律, 但又和谐, 可以参考剑桥大学的设计.
具体的措施如下:
- 套件化工作空间, 做到可定制
- 增加窗户, 每个程序员尽可能拥有一个窗户
- 室内室外空间结合
- 增加公共空间
合适的人
上面很多的内容其实更合适优秀的程序员, 管理者为他们保驾护航, 他们能发挥出极大的潜力和生产力. 而对于没什么追求的程序员来说即使提供很好的环境, 也不见得会有很大的提升.
现代管理学强调天生我材必有用, 管理者应该去挖掘下属的潜力. 但作者认为更应该关注招聘, 去挑选合适的人. 因为如果招到一个不合适的, 你很难在短期内改变他. 而且也有一定几率失败, 如果这种情况很多, 很难组建一支有战斗力的团队.
除了招聘优秀的员工也要避免招聘思维模式相似的人, 因为思维模式相似的人在一起很难产生新的火花.
怎么选择合适的人
- 看作品, 相对类似八股文的专业知识, 应该更看重实战能力, 通过作品来看出一个人的设计和思考能力.
- 组织试演, 查看综合能力, 会考察的更加全面.
- 不进行技能测试. 技能测试只适合短期的评估, 但招聘更应该看一个人的长期发展能力, 因为工作肯定不是一成不变的, 不应短视的只看到目前是否匹配, 要看一个人是否以后面对不同的情况都有高的产出, 且是否值得长期投资.
成本看似很高, 但和质量也是一样的, 长期对于一个人的人力成本来说还是很少的.
领导力
在软件行业中领导力并不是压榨员工的能力, 而是应该作为服务的领导力, 做到能主动承担工作且胜任工作, 最大化每个人的价值, 带着善意做事, 为整个团队着想, 让团队能发挥出自己应有的生产力.
因为管理者往往不是真正意义上的团队成员, 当团队内部忠诚度高于对公司或者对管理者的忠诚度的时候, 低水平管理者可能会对团队心生恐惧, 甚至会通过各种手段拆散团队, 这就要看管理者的觉悟了.
团队自毁
相比什么是好的团队, 作者从反面分析了一下什么样的情况会导致团队自毁,
防御式管理
对员工缺乏信息, 担心员工犯错进而干预过多. 这样会伤害员工的自尊心, 使其无法放开手脚. 好的管理者应该给与员工更多的自由, 而拥有犯错的权利才会让人自由.
官僚主义
繁文缛节过多, 无效的工作会议太多, 导致优秀的员工无法把时间投入到真正的工作上面, 一样会消磨大家的热情.
对员工错误的物理分割
员工的工位分配应该也遵循高内聚低耦合, 把内聚高的员工放一起, 发低耦合的员工分隔开.
时间碎片化
频繁对员工进行打断.
牺牲产品质量
拍脑袋的目标
加班
加班是一种减低生产力的做法,而且因为不是每个人都能加班, 因部分成员无法加班导致团队觉得不公平而引起团队分裂.
大家都知道加班是有害的, 但为什么还有这么多人加班呢? 可能是为了能躲避指责, 逃避责任?
促进团队内部竞争
竞争会降低大家的凝聚力, 对于团队来说, 个人的成功是没有意义的, 即使一个人非常优秀, 但项目失败了, 也没什么意义, 同样的, 对员工进行绩效排名, 可能会引起内部竞争, 产生不必要的内耗.
如何培养好的团队
- 对质量有执着的追求.
- 让团队频繁完成任务的闭环, 给团队成就感, 促进团队的融合
- 建立精英意识, 通过网状管理而非层级管理, 有点类似自组织团队.
- 允许和鼓励差异
- 维护和保护成功的团队, 不要拆散.
- 提供战略方向而不是具体指引.
自我修复系统
确定性系统与不确定性系统
确定性系统只是有标准的方法论或者流程, 只要输入是合理的, 输出就是可预测的, 但缺点是构建成本较高, 因为需要兼容一些异常的情况, 而且这种系统自我修复能力差, 因为大家都习惯了常规的工作, 面对突发的情况可能不知道如何处理.
而不确定性系统则拥有比较强的自我修复能力, 但效率会低一些.
现代管理学即使希望能打造一个确定性系统, 是希望即使员工并不聪明, 但能按照这套流程走下去, 也有不错的产出. 一些大公司经过多年的发展, 也慢慢会变成一个确定性的系统. 但这种系统可能会限制员工创新性思考, 固定模式, 且官僚主义越来越重, 打击员工的热情.
虽然软件工程也有很多方法论, 但在实操的过程中其实遇到的情况非常多, 方法论不可能把所有问题都囊括了, 因此在引入方法论的时候应该因地制宜, 随机应变, 这就很考验团队对方法论的理解能力了.
实现趋同除了靠大型的方法论, 复杂的流程之外有更好的途径. 在这过程中更容易形成团队共识.
- 通过培训去构建统一认知. 有些规范不是简单的靠制度约束就能达到很好的效果的, 例如分层设计, 虽然规定了不同的包属于不同层, 但如果认知不同, 一样会把逻辑错误的放到其他包上面, 看似代码结构看似三层结构, 实际上只有一层. 而通过培训能让大家了解设计原理, 更好的去遵循规则.
- 自动化工具, 把标准自动化下来, 让大家都不用去遵循标准了.
- 同行评审, 也就是代码评审或者设计评审等等.
什么样的规则会成为标准? 是业界定义的标准吗? 还是某个部门设计的标准? 作者认为, 除非某样东西已经在公司内部广泛应用且成功的使用, 否则不能宣称他为标准. 也就是在成为标准前一定是内部已经实践过, 觉得有用的, 才会慢慢变成标准.
学会管理失败的风险
软件行业的风险很大, 否则就不会出现这么多失败的项目了. 而没有对失败的风险管理, 目标就不是一种挑战了, 而更像一场豪赌.
风险管理的本质并不是让所有风险都消失, 而是确保风险出现后能得到有效缓解. 允许员工犯错的前提也是管理者需要对错误进行管理, 避免出现大的影响.
变革模式
人们天生讨厌变化, 人们对变革的基本反应不是有逻辑的, 而是情绪化的. 我们对变革可能会有一个幼稚的想法.觉得只要把旧状态改成新状态就行了.
弗吉尼亚萨提尔则提出了现实的变革模式
变革必须要经过混乱才有机会而成功, 而变革的彻底失败往往在混乱这个阶段.
学习型组织
学习型组织的关键问题不在于如何开展学习, 而是在于何处开展. 当一个组织想要像亚马逊一样自我变革时, 它需要一些小而活跃的学习中心来构思, 设计和知道这种革新. 而这种学习中心一般不会出现在高层和底层, 而是出现在组织的中间管理层, 只有这部分的管理层有意愿且有能力做这种变革.
社区
人类是社会性动物, 天然喜欢社交生活. 当社交意识足够强烈时, 就没有人想离开公司, 对人力资本的投资从而得到报纸, 上层管理者也愿意增加投资, 从而形成良性的循环.
社区不会在工作中自然形成, 而是需要把他创造出来, 而这也是一件非常有成就感的事情.
工作应该是快乐的
程序员应该是快乐的, 因为他们通过写代码能获取很强的成就感. 不快乐的程序员很难做到卓越, 因此有追求的程序员应该主动跳出舒适圈, 去更好的更有挑战的环境去发展, 不断去磨练自己, 让进步也成为快乐的源泉.
总结
书中很多观点我觉得都是非常贴合优秀程序员的特点的. 程序员天生高傲, 有很高的自我要求, 也有很强的自尊性和创造力. 好的程序员组成的团队的产出是较差程序员组成团队的产出的10倍. 因此如何挑选出这批好的程序员, 给予他们合适的环境, 让他们产生10倍的生产力是这本书核心想表达的, 而他们也是企业的核心资产, 企业有必要为他们投入更多, 这才是双赢的局面.
对于程序员的加班问题, 作者在很多地方都有提到, 从长期来看是得不偿失的. 我觉得这也是针对的是优秀的程序员的, 而当大家都习惯了加班的模式, 都成了"加班狂".我想很难产出真正卓越的程序员.
最近看到有视频讲的是程序员要进行"防御性编程", 增加企业的裁员成本, 提升自己的"竞争力". 这同样不是一个优秀程序员会去做的.
