发挥个人的能力才是最关键的

事情起源于动态语言和静态语言之争，最后争论焦点转移到：「相信人本身的能力重要，
还是通过语言/工具来约束人重要」。
我认为项目开发中最重要的是个人能力和团队协作能力，工具只是加分项。
如果代码质量差、监控难、性能难以优化，解决根本问题的关键还是在人身上。
并不是静态编译和工具检查就能搞定了。

我愤愤的在 QQ 对话框中写道：

> 我工作第一年痛苦于开发流程，阅读了《人月神话》，就开始坚信软件工程的哲学
> 后来痛苦与代码质量，阅读了《重构》，开始坚信代码质量决定产品质量
> 现在痛苦于人和语言的冲突，动态和静态的冲突，我想读《人件》了


人件已经绝版，只能在找线上版，我花了两个星期把它读完。
书中给了我一部分答案，另外还有一些意外的收获。

<!--more-->

《人件》其实讲了一件事情：怎样将脑力劳动者管理好，打造出一个高效的团队。

《人件》@豆瓣： [http://book.douban.com/subject/1108725/](http://book.douban.com/subject/1108725/)

《人件》在线阅读地址： [http://book.zi5.me/books/read/2206](http://book.zi5.me/books/read/2206)

吐槽：翻译太烂太烂太烂了，下次要看直接去看翻译版。

## 以人为本 ##

> 我们工作的主要挑战，与其说来源于技术，不如说来源于团队成员本身

技术人员转成项目经理经理之后，往往继续用工程化思维管理人员，
认为人是可以设计成标准化接口，是可以替换的。很可惜，这种想法不是那么 **有效**。

因为脑力劳动和体力重复劳动不一样，不是在卖汉堡这种重复工作，
而是需要创造、思考和发明的工作。软件经理需要提供有限额的错误机会。
错误无法完全避免，并且是工作内容的健康组成部分。一旦硬性阻止犯错，
会让团队成员失去创造的勇气。
我相信这也是为什么 Facebook 早期会践行「Break it Down」。

## 何不双赢 ##

> 西班牙人的理论坚持认为地球上只有一个固定数量的价值，
> 因此通向积累财富的道路就是学会从土地或者从人身上更有效地榨取财富。
> 而英国人的理论认为价值可以通过天才和技术创造出来。因此英国就产生了工业革命，
> 而西班牙人就转动起了车轮，开始开拓疆土和剥削在新大陆的印第安人。
> 他们从海上运回大量的黄金，
> 他们所有努力带来的却是通货膨胀（太多的金钱追逐太少的有用货物）。

我坚信公司和员工并不是对立面的，双赢才是正确的路线。
大部分情况下，我愿意牺牲个人时间和精力来完成公司的任务。
前提就是对产品有认同感，对公司有归属感。

## 最好和最坏 ##

作者通过一个持续两年，有来自 92 个公司的 600 多名开发程序员参加的比赛，
分析出以下数据：

* 成绩最好与成绩最差的人之间的绩效比率是10 : 1。
* 最好选手成绩大约是中等成绩选手成绩的2.5倍。
* 成绩中等以上的一半选手与另外一半选手的绩效比是2 : 1

[外刊 IT 评论](http://www.aqee.net/)的
[为什么程序员的工作效率跟他们的工资不成比例][] 一文中也提供一些数据支持。

我离最好还有很长的距离，但是我相信个人能力是可以提升的，
并且在个人能力上面的投资汇报比极高。

## 高效工作的秘诀 ##

> * 进入顺流：咦？怎么时间过得这么快？！
> * 邮件比电话更不容易打乱人的思绪

## 团队的力量 ##

> * 团结起来，工作的更高效更开心
> * 有目标的团队，1 + 1 > 2
> * 为一个共同的目标走到一起
> * 优秀的团队里的成员，不会因为钱、阶层、晋升的问题离开团队
> * 优秀的团队往往是带有个性的

《人人都是产品经理》中当时讲了一个愿景（Vison）问题，
我相信一个好的愿景可以吸引更多高质量人才，为赚钱而创建的团队是不会长久的。

## 烂团队的苗头 ##

> * 防范团队成员
> * 官僚作风
> * 不挨在一起工作（空间上）
> * 某个成员的职责被分割多份
> * 对产品质量要求降低
> * 无意义的截止日期（不可能达到的目标）
> * 结党营私
> * 加班
> * 绩效考核 / 目标奖励
> * 早期时候人员超编

这里和上文的愿景问题是对应的，无论是强制加班还是通过考核回报激励，
都不是激发人的创造力和战斗力的好方法。老大们应该学会画饼，画大饼。
另外，管理团队果然好难：做的事情必须靠谱，才能吸引到人才；
需要能管理好有个性的人才（比如伞哥这样的）； 在中国大环境下，还要不错的物质回报。

## 经营好团队 ##

> * 崇拜高质量：因为市场和用户需要高质量的产品
> * 通过里程碑的方式管理任务，提高士气
> * 崇拜精英
> * 允许和鼓励异端：异端代表创新和进化，没有异端就会种群灭亡
> * 给予自由度：对成员信任，而不是纯粹服从权威工作
> * 交流，唤醒那些有潜力的巨人（唤醒了才能将脑力劳动能力发挥到极限）
> * 内部竞争和培养
> * 管理层自身的学习，公司自身定位的不断改变
> * 将公司内部建设出社区文化（我觉得就是公司团队文化建设嘛）

我有一个观点是工程质量决定产品质量，产品质量决定整个团队。
质量的一个标准是：**我以此为荣**

## 工作是一种乐趣 ##

> * 将混乱重建成秩序是有趣的
> * 敢于用小项目来做尝试
> * 组织竞赛游戏
> * 团队头脑风暴

这本这么老的书居然提到团队竞争游戏，和 Facebook 的 Hackday 异曲同工啊。
再为这种乐趣补充一点：将公司的成果分享到开源社区。

> 团队成员需要做到：
>
> * 界定自己工作，成为主人翁
> * 促使自己成长为多面手，而不是单纯某个职位

给了成员足够的自由度，那么就会有相应的风险，需要对他们进行监测，
另外招人时候就需要找靠谱的人，这也是为什么 Facebook / Google / 早期百度对招人要求极其严格。

## 流程改进 ##

> * CMM 是标准，是标准的话就一定不是对于个体的最优情况
> * CMM 自身也在改进，说明上一个版本的 CMM 不是最优
> * 流程的目标是：提高质量 / 提高生产力 / 减少风险

## 读后感 ##

发挥个人的能力才是最关键的，要点在于信任、自由、乐趣。原则是 Pull 而不是 Push。

我会继续学习和思考这些原则，因为总有一天我也会面临这样的挑战。

[为什么程序员的工作效率跟他们的工资不成比例]: http://www.aqee.net/why-programmers-are-not-paid-in-proportion-to-their-productivity/

-----
via: http://blog.log4d.com/2013/04/peopleware/