《人件》读书笔记

最近看了一遍《人件》，收获还是蛮多的。第一次听说这本书还是在大三的时候，现在才看，真的是有些惭愧。之前一段时间在地铁上没有看书，只是看看小说，玩玩游戏，刷刷朋友圈，偶尔看一下微信的公众帐号。然后还没到家，感觉很无聊，我是一个闲不住的人。然后就开始看书了。

这本书是讲软件工程中的管理，讲如何管理软件开发人员，如何管理一个团队，如何才能让一个团队高效的工作。

管理人力资源

我们不应该像管理软件的一个模块那样来管理软件开发人员。软件开发更多时候是一项脑力劳动（搬砖是体力活），一项创造性活动。我们应该允许他们犯错。

疯狂加班对项目没有好处，尤其是那种不顾员工个人生活的996，并不是所有人在任何时候都愿意这样加班的。还是一张一弛比较好，该工作的时候就好好工作，高效的，高质量的完成任务。然后休整一下，为下个sprint做准备（我们是跑scrum）。一个合适的目标会激发开发人员的热情与斗志（至少大家是这么认为的，这真的取决于什么样的公司和什么样的员工，还有员工当时的状态）。但是一个瞎扯的目标（尤其是那种老大直接拍板deadline然后让下面的人去拼命的目标），是很愚蠢的做法，大家都或多或少的听过这样的情况：一个项目完了之后，开发人员都走了。

章节最后的一句话很有意思：压力不会让人工作的更好——只是工作的更快

我们应该追求更高的质量，至少是要达到开发人员自己心中的最低标准，不然开发人员会很不开心。

帕金森定律，认为工作会自动膨胀，占满一个人可以用的所有时间。比如说一个任务要2天，如果给3天，那这个定律认为开发人员这3天都不会闲着，都在忙这个任务。然后就有了另一种想法，既然给3天和2天都能完成，那就少给点。然后作者就论证了这个说法是片面。

不要相信有什么软件管理的法宝可以让你的管理效率飙升。如果有，早就普及了。就像减肥，天天都有奸商吹牛逼，如果真的那么有效，为何世界上还有那么多人在苦逼的减肥？

办公环境

这几个章节作者们通过举例来说明办公环境对开发人员的重要性。编码战争游戏（Coding War Game）里面，在好的环境里面的开发人员比在不好的环境里面的人效率高很多。虽然不能直接说明好的环境能直接提升生产力，但至少说明，牛逼的人都喜欢呆在好的环境。

软件开发人员的工作需要进入“流”的状态，频繁的打断开发人员会造成他们无法工作，所以，请给他们提供安静的，不会被频繁打断的工作环境。比如租一个别墅（想太多了，关进小黑屋是可行的办法，至少我听过阿里这么干过）。

这里作者想要表达的观点可能大多数公司都不是很重视，大部分公司都是整齐划一的位置，有的公司还很挤，很难受。说到这个我就想起了办公硬件，我认为好的硬件真的能提升员工的工作效率。不仅编译什么的更快了，电脑也不卡了，员工的心里感受也会好很多。（我其实是想说我在用27寸iMac 5K，爽歪歪，真的）

正确的人

找到合适的人 -> 让他们愉快的工作，不愿离开 -> 让他们自由发挥

这里作者们粗略估计了一下换一个人的成本，简单的可以认为显式成本是4.5个月的人力成本，而且工作越复杂，这个时间越长。而且还没有算上猎头的费用。员工高离职的隐性成本就是大家都很浮躁，没有人去长线思考。这是很可怕的事情。

那怎么留住员工呢？作者们说的不是很多。可以用另外一句话来概括：没有银弹。用钱，用情怀，用牌子……

高效团队养成

团队大概是公司最想要的东西了，因为团队的整体大于部分之和。而且团队成员也会喜欢呆在这样的团队中，这样的团队可能会被认为是团伙，可能会让一些团队之外的人感到不舒服。这样的团队应该说，真的很牛逼，让我想起了海底捞的团队。去过海底捞的人大概都会记得他们的服务非常热情，我甚至会觉得有些不舒服。

既然高效团队这么牛逼，那我们培养一些这样的团队不就好了？说起来容易，作者们也没有一个通用的方法来帮助读者培养这样的团队。反倒是列举了一些会毁坏团队的事情，比如牺牲产品质量，瞎搞截止日期等等。还有假大空的标语，让我想起了那些成功学，说起来头头是道，结果还是毫无帮助。

高效团队不是“管理”出来的，所以，想要靠管理就能管出一个高效团队是不行的。尤其是防御式的管理，只会毁灭一个团队。

最终，作者们还是列出了一些能够帮助培养团队的思路：比如建立对质量的执着最求，提供诸多满意的闭环，允许和鼓励差异性。这里的这个闭环很有意思：“或许有些人闻所未闻，但是人类自己就是需要不停确认他是否正沿着正确的方向前进。”比如对媳妇说我爱你，她肯定知道，但是如果听到我说，她就会很开心。团队也是，比如把大的任务拆成一些小的，每次在小任务完成之后就是一次闭环。

沃土

我们需要好的企业文化，这是员工生长的沃土

我们需要规矩，有时候又不能完完全全按照规矩来。比如创业公司在开发流程上面是各种不规范，甚至很多时候都没有文档，大家口头上说一下。这让后来者很头疼。但是如果只是按照规定一步一步的来，也会有问题：空管会按照规定只能每7分钟降落一架飞机，医生做阑尾切除手术要1周。效率很低。我们需要规定，也需要特例。

对于项目的风险，一定要考虑失败的风险。其实在生活中也一样，要考虑各种情况，不能只是乐观的考虑一下，然后当失败真的来的时候，搞得焦头烂额，甚至无法应对。

大概每个开发都有过会议超多的感受。一天什么事情都没干，全在开会了。其实有些会议是没必要这样搞的，比如每天的例会，大家轮流说下每天干了什么，有没有什么问题。很多时候一个员工是不关心另外的人在干什么，有没有什么问题。如果需要知道，就直接去问了。我以前也觉得应该有每天的例会，现在觉得，没必要。当然前提是员工靠谱，真的遇到了问题及时汇报。没有消息就是好消息，有了坏消息一定要及时让大家都知道。

不要浪费大家时间，比如会议迟到，让别人都等着你；比如把不是很相关的人拉到会议里面。不要发各种“垃圾”邮件，先沟通，后发邮件，我喜欢这样的方式。

让改变成为可能。大家都不喜欢改变，不论是从我之前自己的感受，还是看到的文章，都是这个观点。大家并不喜欢改变，尤其是那些现在的既得利益者，会强烈反对。作者们还提到了一个叫做“改变阻力连续区”的概念。

盲目遵从（不问任何问题）
相信但存有质疑
- 怀疑（“展示给我看看。”）
- 被动观察者（“这关我什么事？”）
- 反对（害怕改变）
- 反对（担心权利丧失）
激烈反对

盲目遵从的人对想要推行改变的人来说，没有帮助，他们不是真正的盟友。激烈反对的人更不用说了。正是那些相信但存有质疑的人才是推行改变的人最应该关注的。一种靠谱的方法就是：感恩旧的方式来帮助推动改变。

作者们还提到了一个对待改变的模式，很有意思：旧标准-> 混乱-> 实践与整合-> 新标准在混乱阶段大家很容易会有情绪化的反应：我操我们这样搞不行，还是之前的办法靠谱。这个时候要小心谨慎，不然很可能改变就推行不下去了。

组织型学习，团队成员确实应该不停的学习新知识，新技术，尤其是在当下，技术更新非常快，就拿iOS开发来说，每年一个大版本，每个大版本会有很多新技术，不学习是不行的。这让我想起了我的第一家公司群硕，公司组织的技术分享真的很好，至今我都很感激公司能够这样教育我们。虽然说是技术分享，更多的时候是共同学习，由于当时我们几个开发人员技术太浅，开技术分享的时候讲的也不是很深入，但是当时的几个人都从中学到了很多。