《人件集》笔记（一）

《人件集:人性化的软件开发》

内容简介：如果提到软件开发中人的因素。那么没有谁能比LarryL_Constantine更有发言权了，全世界的开发人员和管理人员都通过《康斯坦丁人件集》一书认识了这位人件领域的大师。而《人件集:人性化的软件开发》也成为了人件领域中的经典著作。在《人件集:人性化的软件开发》中。作者对《康斯坦丁人件集》一书中包含的52篇著名的专栏文章进行了重新整理，并加上了25篇首次以书本形式发表的文章。 在软件开发中经常会遇到各种各样的挑战。比如：技术问题和社会问题难以完全分割、心理学问题和控制论问题相互干扰、理论和实践相互交织。这类问题统称为“非人性化开发”问题。《人件集:人性化的软件开发》针对上述问题进行了深入浅出的介绍。起到了极其重要的指导作用。《人件集:人性化的软件开发》主题包括：项目管理、团队开发、纪律与无序、工具、模型、方法、过程、个人特性、可用性等。 《人件集:人性化的软件开发》还包括两个全新的部分：一个是组织文化。另一个是如何让软件对象更为可用，这些文章包括了作者提倡的突破性方法——“以使用为中心”。

30年前的巨著《人月神话》读过了，是时候读20年前的巨著《人件集》。《人月神话》对于软件这样的行业来说可能真的是上古天书了，尤其是《人月》里面有不少的当时技术实现的描述，什么汇编，纸带都出来了。

虽然《人件集》是《人月》十年之后的书，但是毕竟离现在13年也有20年时间，那个时候我才3 4岁的样子啊！还没看之前，我就想，估计《人件》中的内容对于现在环境也不适用了吧？

但是看了第一部分 团队开发，发现书中提及的方式和理论一点都没有过时，对于现在还非常实用，我总结原因有2：

1. 《人件集》讨论地更多是人，是心理学；软件会过时，会新旧交替，但是方法论不会
2. 虽然现在移动领域，云，大数据这样的技术兴起使得从外看，软件开发已经变得完全不一样了，但是可能在公司内部开发还是那样的流程，没有太多变化，只是使用的技术变化而已。

---

《人件集》本身是一本很有趣并且使用的书，每一章节都给出了不少中肯可操作的意见。或者在以后工作中可以参考：

第一部分 团队开发

1.决策，决策

研究表明，集体的决策比个体独立做选择更具有风险倾向。在做决策和解决问题时，团队有一种均衡的效果，这会将个人的贡献和能力降到最低

我们知道如果使用“一致意见”方法来做决策，而且想要获得第一流的问题解决方案，最重要的因素之一就是采用中立领导。讨论会的主持人尤为重要，无论哪个领导来主持讨论会，他都必须时刻努力保持中立，这样才能从所有的意见中得到最好的结论。

TODO:当我作为一个Team Leader或者比其他团队成员在某件事情上更有经验的时候，切记要自觉站在中立的位置，这样才能保证不同意见能够顺利高效地提出。

2.一致意见和折衷

折衷意味着所做出的选择是一种似是而非的东西。

感悟：产品经理一定要有自己的想法。如果一个产品是由老板意志，个别用户反馈，研发和设计贪图方便的想法混杂而成的产物，那这个产品肯定没有前途。

将事实和意见分开。对于一个协同工作的团队来说，如果期望创造性地解决问题并获得最好的结论，他们必须知道他们已经掌握了那些信息，并能够随时所得更好的信息。

TODO：在团队讨论或者会议之前，一定要将当前已经的情况和资料共享出来。随后的讨论应该在这些事实之上产生。如果有成员希望开展其他方面的讨论，那对不起，请在下次会议之前将资料准备好，并且共享出来。当然如果情况紧急，也可以再启动一次临时会议。不过资料还是提前准备好。

3.达成一致意见

书中对于“为每个指标设置不同的加权指数，并将最后要得到的结论简化为一个数学公式”这样量化的设置优先级方式表示不同意。 主要的原因是：

1. 这样的公式是“伪客观的”，不一定就能表示真实的优先级，可能会忽视一些重要的因素
2. 这些公式，或者直接说就是部门KPI，容易造成部门之间扯皮，也容易造成部门单纯优化自己的目标而忽视总体的目标

感悟：可能对于团队和部门之间的合作，公式化的设置优先级不是最优的办法。但是对于个人来说的确是一个不错的方法。我在做一些重要的决定是，例如，选择升学，选择工作这样重大的选择时，使用公式化的方法，可以帮助我认清我需要考虑的因素以及不同因素之间的重要性。所以，我个人还是比较喜欢公式化优先级设置方法。

缺乏明确的标准并不是达成技术一致意见的唯一障碍。过分强烈的讨论，很有可能演变为争论，对于软件开发团队来说不是好事。

TODO： 团队讨论不应该让最能说会道的人主导，应该鼓励每一个人开口，尤其是那些表达能力欠佳的技术大牛开口。

4.记录员，低下还是高贵

组织的学习依靠的是记录，而不是人的大脑，组织应该将政策，实践，执行的过程都记录下来。在工作的过程中，所记录的内容越多，组织学习的能力就越强。

对于软件开发来说，如果过程记录以一种连续的，非结构化的形式存在，那么这些信息使用起来是非常不方便的。

我们可以将讨论或者会议结构化为以下四个方面 ：

1. 执行列表(do-list):记录讨论中做出的决策，为什么做这样的决策
2. 决而未定 :记录暂时无法决定的问题，放到下次会议或者获得更多“事实”之后再讨论，并且确定下次讨论的时间。
3. 片段箱 :记录一些不完善的想法
4. 否决箱 :记录已经被否决的方案，并且一定要记录否决的原因

感悟：对于上面四个方面，1 和 2还好，3和4的确是很容易就忽略的部门。当时就因为缺少记录 否决的方案，而吃了不少亏。

项目的后台结构由于个人版和企业版的功能相互不确定，导致有点混乱，并且加上过度设计，导致后台比较混乱。两三个月之后功能最终比较清晰了，需要添加新功能的时候，发现后台很多地方都已经不知道当时为什么这样设计，也不知道为什么不使用一个更加简洁的方式设计了。

TODO:一个会议没有一下几个条件就是不完整的，每日的会议都应该不断实践，形成一种本能反应：

1. 议题
2. 记录
3. 结论

另外，以前做记录并共享是一个比较痛苦的过程。但是现在很多轻量级的团队协作工具可以很好的帮助到我们，我现在就是用Teambiton，已经挺方便了。

5.办公空间

建筑或办公室的设计和装修情况极大地影响着人与人之间的交流和协作。为了有效地协同工作，项目组确实需要足够的工作空间，他们需要一个能够容纳整个小组的空间。另外，团队需要一个可以当作“指挥部”的地方，整个团队可以在那里方便地开会，讨论问题，借以躲避外面的喧嚣嘈杂。

TODO:办公环境我暂时还没有能力设置，但是有可能的话，还是尽量使用"指挥部"吧！还有，以后找工作的时候一定要预先观察公司的办公环境，办公环境很容易看出公司的办公风格。

6.讨厌打扰

工作团队需要一个简短，简单，轻便的词语表来表达打扰，所以我们的办公室里，我们使用“中断（IRQ）”，“相应（ACK）和“拒绝（NAK）”来进行一次打扰。

感悟：外部干扰的确是一个头疼的问题，一不留神就被中断了，然后自己的工作也无法完成。对于书中这样团队的暗语，现在感觉还是有点GEEK，还有点奇怪。所以我还是按照番茄工作法里面的方法来对抗外部中断吧。