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

第一部分 团队开发

第一章决策，决策

讲述了中庸的风险以及轻度领导

　　研究表明，集体的决策比从集体中的个体独立做选择更具有风险倾向。如果将这种决策模式应用于软件编程，我们可能会看到这样的结果：团队可能使用更奇特的数据结构、更古怪的算法或者更晦涩的语言来编程，这样做必然会给这个软件带来风险。然而，团体动力学的研究还表明了另外一种倾向：在做决策和解决问题时，团队有一种均衡的效果，这会将个人的贡献和能力降到最低。从上面两种研究可以得出结论，似乎单独做出决策更具有效力。其实这两种倾向都是可以尽量避免的。

　　只要领导在所有的成员或者绝大多数成员发表完意见后，最后表达自己的看法，就会对最终的解决方案起到积极的促进作用。

　　一个领导说话速度过快，就会降低团队工作的质量。对于那些自信的领导，如果他们总是认为自己是正确的或者知道的是最多、最好的，也会使解决问题变得更加困难。

第2章一致意见与折衷

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

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

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

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

第3章达成一致意见

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

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

第4章记录员，低下还是高贵

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

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

执行列表(do-list):记录讨论中做出的决策，为什么做这样的决策
决而未定 :记录暂时无法决定的问题，放到下次会议或者获得更多“事实”之后再讨论，并且确定下次讨论的时间。
片段箱 :记录一些不完善的想法
否决箱 :记录已经被否决的方案，并且一定要记录否决的原因
感悟：对于上面四个方面，1 和 2还好，3和4的确是很容易就忽略的部门。当时就因为缺少记录 否决的方案，而吃了不少亏。

第五章办公空间

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

第六章讨厌打扰

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

 本部分总结：

第一：团队成员之间应该建立起相互信任和尊重的关系。一个能够充分信任和尊重彼此的团队可以增强团队凝聚力并实现更好的结果。

第二：在团队中，应该明确各个成员的角色和任务，以便更好地协作，无论团队成员是开发人员、测试人员还是管理人员。

第三：在团队中推行敏捷开发，以更快地响应变化并实现软件开发的快速迭代。

这本书第一部分的主要目的是帮助读者理解在软件开发团队中，如何有效地协作并确保开发出适合客户需求的软件。它突出了人性化开发的重要性，鼓励开发人员和团队成员积极地沟通并相互支持，以充分发挥团队的潜力，创造高质量的软件。