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

第一部分团队开发

第一章决策，决策

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

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

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

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

第2章一致意见与折衷

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

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

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

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

第3章达成一致意见

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

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

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

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

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

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