《人件》——读后总结
《人件》这本书刚开始听名字，感觉是一本很让人纳闷的书，人件？人贱？
原来人件的意思是，人与计算机发生交互的时候人的那个条件。这么说起来还是有点拗口，简单的说来，就是人与计算机活动的时候，人的那种活动。
这本书，简单总结起来介绍了如下的内容：
1 管理人力资源
2 办公环境
3 使用恰当的人
4 团队的生产力
5 开心的工作
6 续写
下面简单的针对有印象的部分，写下感想。
1 帕金森定律
帕金森定律讲述了如下的定律：
如果一个很平庸的人作了管理，那么摆在它面前的只有三条路：
1 退位给有能力的人。
2 使用比自己更优秀的属下。
3 运用比自己还平庸的手下。
第一条路和第二条路一般是个有欲望的人，都不会采取，那么只有第三条路了。所以，手下的人如此效仿，就演变成整个阶层都是这些平庸的人组成。
这就是帕金森定律，就目前来说，很多公司都有这种情况，尤其是在政府。
另外书中强调了一点，质量的提升会带来成本的降低。
一般来说，公司总是认为质量的提升会带来开发成本的提升，因为公司做的项目一般都是有截止日期的。如果想要提高质量，那么必定意味着开发时拖延开发的周期。有的日本公司，向来以质量为主要目标，因此在日本的很多软件公司中，产品经理有着绝对的决定权来决定是否按照规定的日期交付软件，甚至可以直接回绝上司的要求，必须要保证软件达到一定的标准才行。但是书中的一种说法是这样解释的，质量的提升意味着BUG或者缺陷的减少，这样当然就减轻了维护的成本，而软件的长期维护是一个公司最大的成本，减小维护的成本，当然也就带来了成本的降低。
只可惜，很多公司只看到了眼前的交付日期，看不到长期的成本。
最后第一章介绍了几点误导管理者的“常识”：
1 有快速提高生产力的捷径！——真的没有.
2 技术的发展，你正在被淘汰！——其实我们使用的技术很多都是固定的老技术，比如平时使用的SSH已经用了很多很多年了，真的很多年了！连近几年流行的hadoop不也是网格计算的另一种实现方式么。
3 改变语言，收获巨大！—— 改变语言，意味着学习成本的增加，还有其他的维护开发时难点的解决难度增加。
4 给予开发者压力，效率更高！—— 很多人认为给予开发人员压力，开发人员会有更高的动力来开发。但是很多开发人员会因为压力的增加，身体状态下降，心理产生排斥，效率反而更低。很多开发者需要的是一段时间的“顺流时间”，这段时间甚至开发者会进入一种忘我的境界，一抬头！咦，下班了！对，就是这种感觉，这个时候的效率其实是最高的。
2 办公环境
说到办公环境，对于IT公司来说，最佳的就是几个人的小房间或者小隔间，减少噪音！减少干扰！
但是......
我实习了几天不到，刚好赶上部门拆掉挡板！之前还是很喜欢那种小隔间的感觉，但是后来随着挡板的消失，我觉得我日常的行为毫无隐私，时刻被被人监控；同事讨论问题的声音也很大，经常会被拐着听到他们讨论的内容，真是我无心所为！还是希望部门能把挡板装回去，给开发人员一点自己的空间，至少噪音或者人员的出入不会带来太大的干扰。
3 适当人选
本章感觉最有印象的就是，讲述一个公司的流动率。
一个人员流动的公司，会导致更大的人员培训成本，导致更多的开发干扰，实在是百害而无一利。当然传说中，外包公司就要作另一番解释了。但是目前外包行业每况愈下，也就不去纠结了。
总的来说，还是要关注底层开发人员的生活或者工作需求，恰当的安排以及利用，避免人员流动带来的损失。
4 团队的增长
书中提出一种胶冻团队的概念，提出一个胶冻团队以为这个团队有更高的凝聚力，各担其职，工作效率更高！接着针对胶冻团队的形成，提出以下的几点：
1 不应该对手下有防范意识，古人云：用人不疑，疑人不用。即是这个道理！
2 官僚作风
3 物理上的分离，比如经常搬公司的地址，就不是一个明智的选择，每次搬迁都会导致一部分人员的离开。
4 产品质量的降低，降低产品的质量......这......
5 假的截止期限，中层管理者的常用手段。比如，软件交付的日期是五月一号，那么经理通常会缩短时间，这样即便有突发状况需要延期，也不会干扰真正的交付时间。—— 但是这种假定的交付日期通常很容易让人知道是一个不实际的日期，潜意识的加班就成了必须的加速手段，这样就会带来开发者心理和生理上的排斥。
5 开心的工作
6 其他
最后强调了公司的学习，人力上的投资，技术的变更等等方面。
先说说技术的变更吧，这个我也亲眼见过。之前某个产品使用的是XX技术，但是开发过程中有很多问题出现，使用时也有很多问题。因此有的领导想要改变，引用新的技术，因为新的技术确实可以避免此类的问题。但是老的开发人员却站在相反的对立面，一方面不想重新开发过去的框架和产品；另一方面，也在怀疑新技术是否还潜在着其他的问题。
其实很多时候人们习惯一个东西，不是害怕改变需要的付出成本，而是根本就不想改变！这是人的本性。
另外强调了公司的会议，因为会议很多时候占据了大量人员的时间，而会议的根本是为了针对某一问题达成共识，不是出于这中目的的会议都是一种仪式而已，例如迭代每周的会议。
通过这本书还是了解了很多，对于《人月神话》都忘记的差不多了，改天还得看看。这种类型的书，不仅仅是管理人员需要看，个人觉得对于我这种开发新手来说，也是必须要了解的。
