读书笔记 之 软件生产中的约束理论
写在前面：个人觉得作为一个项目经理 或者说 开发经理，其管理能力+技术能力二者相应达到一个合理的比例才能胜任。很多企业经常提拔在企业工作时间比较长的，技术能力强的人来担当这样的角色。个人认为老员工的确更加理解公司的企业文化，技术能力也相应比较突出，经验也更加丰富，但是我觉得这个经验和管理是不同的，更多的是其架构能力，遇到技术问题的解决方法。如果一个人长期关注于技术的积累，但是忽略管理能力的提高，很难成为一个合格的管理者。管理和技术一样是需要学习的，不是随着技术经验的积累成完全正比。衡量管理者的标准就是项目或者产品赚了多少钱，其他的例如人员沟通、开发等等都是保证成功的手段而已，而如何合理运用这些手段的过程就体现了一个管理者的综合能力。昨天刚好看电视，听到孙子兵法的一些思想，觉得很好。为将也，需具备"智、信、仁、勇、严"。之所以写在开头前，一是有感而发，二是这章的后面是各个经理的角色定位。
所谓约束 指的是 软件开发中的 受限资源、瓶颈。
约束理论包含5个过程域：
- 标识系统约束：顾名思义改进的基础就是充分认识现有系统的瓶颈。
- 确定如何利用系统约束
- 一切问题都要依照既定的方案执行
- 提高约束：如果第三点是执行的话，第四点就是改进了
- 如果在1-4中产生了新的约束，则循环往复直到问题解决。 可以理解问题总在不断变化的，当初的约束会随着时间慢慢解决，但是又会产生新的约束。
第二个过程域：在软件开发中一种明显的能力受限资源也就是约束 为 如何利用软件开发人员
开发人员每天法定得到8小时的工资，但是根据某项统计这段时间中会有15%的损耗，正常的效率时间是5.5小时左右，这是管理人员最不愿意听到的：）。--个人比较同意这个看法，很多管理人员认为8小时就得产生100%的效率，我想说不可能，除非在工作压力非常之大，许多公司为什么会加班，其实也可以理解为在8小时之外，来弥补这15%左右的损耗，不是吗？
我们需要做的就是来提高8小时内的效率，尽量使损耗降到最小，从而达到双赢。书中提到：任何时候都积压一些需要完成的开发任务可以避免开发人员无事可做。恩，可以理解，人的思维总是有时会开小差，或者会有些灵感的火花，如果没有足够多的任务积压时，小差开到的目的地就是八卦了。
文中提到的其他方式有：
- 最小化通信联络的沟通方式。
- 安静的工作环境
- 最好的开发工具
- 提供支持人员完成非生产工作等
- 充分的培训
- ……..
软件开发中的其他约束：功能集、进度、预算、资源。
产品功能：在开发过程中，在各种约束面前，可能产品需要的功能很多，那么需要做的就是分清几种需求吧：必须具有的功能、有则更好的功能、不会对签单造成影响的功能、时间要求非常紧迫的功能等。很明显分清这么几种功能，并加以和客户的协商沟通从而达到最佳的目的。使产品的成功对此约束的影响降到最低。这里还有一种需求可能是这样的，我个人把他称之为瞬时需求。假设某个需求市场需求特别急迫，如果满足这个需求那么对于产品市场、公司形象等都是一个促进，那么这种需求做不做呢？那么多银行推出各种各样的奥运VISA卡、某电视剧一经推出市场立马出现相关产品等，当然这种需求需要对市场的准确把握和对各种约束的协调等。
再说进度：文中给出了一个例子假设一个最有可能12天完成的任务，新手的估计可能是5天，有人估计可能是30天，对完成任务有80%把握的开发人员，可能是20天。其实这种估计误差的存在是合理的。但是错误的估计导致的后果可能是项目的取消或者项目的冒进。看完这里我想到一个估计的方法：估计人员的经验系数×估计人员认为的难度系数×估计时间。可以用多人来估计，恩，最简单的就是任务承担人和管理者2者估计的结合了。
除了上面的三种约束，其他2种，相对影响我觉得应该比较小一点。
第三个过程域：服从于约束使用
一切都要服从于保护和利用约束决策。
第四过程域:提升约束
在制造业中通常会引入添加机器等手段，在软件开发中提升约束通常通过无报酬的加班，聘用更多的开发人员或者倒班制。这些其实很多软件工程书籍都提到不是很好的办法，当然也是被实践所证明了的。文中提出了一个比较有效的办法是使用更好的开发人员。我觉得还有其它几个方面：充分激发现有人员的最大激情、流程合理、计划合理等等。
最后：焦点
一切问题的核心在于 投资回报率。这个公式很简单（产出-运营支出）/投入。如果投入增加，消除了这些约束那么产出自然增加，最后的公式是 投入回报=（原有产出+增加的产出）-投入/(原有投入+增加的投入)。
总结：系统的总体生产应该根据瓶颈能力进行平衡。应该保护和利用瓶颈，以最大限度地提高瓶颈的产出。
后记：此乃毫无管理经验之人，在看书时的感想，如果言之不当请批评指正。其实每个人都有自己的成功方式、管理方式、看待问题的方式，所以很多时候大家都是对的。