本文列举了精益开发的七条原则，以及对这些原则做了进一步的分析解释。

精益开发

我先把精益开发的概念和七条基本原则列一下，然后再逐条原则表述一下我的理解。

概述

精益（Lean）管理的思想起源于丰田公司，旨在创造价值的目标下，通过改良流程不断地消除浪费。这种方法现已被广泛用于生产制造管理，对于IT系统建设，精益开发的常用工具模型是价值流模型。

精益开发的基本原则

1. 杜绝浪费：将所有的时间花在能够增加客户价值的事情上。
2. 推迟决策：根据实际情况保持可选方案的开放性，但时间不能过长。
3. 加强学习：使用科学的学习方法。
4. 快速交付：当客户索取价值时应立即交付价值。
5. 打造精品：使用恰当的方法确保质量。
6. 授权团队：让创造增值的员工充分发挥自己的潜力。
7. 优化整体：防止以损害整体为代价而优化部分的倾向。

对原则的理解

1. 杜绝浪费

浪费是可耻的，这个很好理解，但是在这条的描述中，精益提出“把所有的时间都放在能够增加用户价值的事情上”，这样太容易被曲解了，最值得考究的就是什么才算**能够增加用户价值**的事？

及时交付对用户有价值的产品算是增加用户价值，那么我们要做的事就仅此一件了吗？

显然太片面，我们需要做的远不止这一件事。

**健康的团队才能产出优秀的产品**，“毕其功于一役”的大决战当然是一场拼尽全力的冲锋，但是“路漫漫其修远兮”，“上下求索”显然又是个长跑的过程，不健康的团队谈不到长远的发展，所以“所有时间”中必然要包括培养出一只有战斗力的团队。

再有，概述中就提到的，我们需要通过什么手段消除浪费呢？

**通过不断地改良流程**，敏捷宣言中说“个体的主观能动性以及个体之间的互动优于既定流程和工具”，这只是强调个体的主观能动性和互动更加重要，但是并没有抹消掉流程的重要性，而且敏捷非但没有忽视流程的重要，恰恰相反，在敏捷开发的原则中说“简洁是减少重复劳动的艺术”，而流程就是保持简洁有力手段，这一点在精益中被尤为强调，所以在制定更加简洁高效的流程上花时间绝不是浪费。

2. 推迟决策

提出尽可能多的可行方案，有利于针对实际情况做出选择。

我们应该把重点放在后半句的“时间不能过长”上。

假设我们把相当宽裕的时间留给了提出尽可能多的方案上，我们得到了相当多的可行方案，但是方案再多总要根据实际情况选择最行之有效的那一个，那么怎么评判是不是最行之有效的方案呢？

简单点讲就是找到这些方案中最能满足“时间”、“范围”、“资源”三者之间平衡的方案，耗时太长显然就压缩了项目的可用时间，对“范围”和“资源”也必将产生影响。推迟决策是为了找到平衡“时间”、“范围”、“资源”的最佳方案，那么掌握不好“推迟”的时间就是在舍本逐末。

3. 加强学习

这和上面讲到的培养有战斗力的团队相呼应，学习是强化团队、保持团队活力的最佳方式，至于什么是“科学的方法”，我觉得应该是最适合自己团队的方法，是组建读书会、学习小组这类组织，还是搞黑客马拉松、分享讲座这种活动看你对团队的了解，哪种方法最有效，最能持续发展就选那种。

4. 快速交付

精益开发是敏捷开发的一种形式，既然是敏捷开发那就不能不提快速交付，在我们软件开发中的实践就是尽可能缩短迭代周期，并且在每次迭代中给用户提供稳定可运行的并且有价值的软件，这是敏捷开发的核心手段，精益中如此，其他的敏捷方式比如“极限编程（XP）”、“水晶方法”、“动态系统开发法（DSDM）”、“SCRUM”也是如此，只是各种方法都有自己具体实践，几种的方式对迭代的实践我会放到后续的文章中讨论。

5. 打造精品

“XX出品必属精品”，当一个公司被冠以这样的评价，如果这个评价是正面的而非带有讽刺意味，那么说明这家公司得到了用户极高的认可，“赢在用户”一语双关，既是说精品的受益者是用户，也是说只有精品才能在竞争中赢得用户。

6. 授权团队

团队，还是团队，好产品离不开好团队，好团队要培养也要被信任，授权团队可以最大化地激发团队中成员对产品的主人翁意识。

用人不疑，疑人不用，需要的是睿智和胸襟，不能放任不管任由其自生自灭，也不能大权独揽，手里攥着大印把角都磨圆了，还怎么激发团队的主观能动性。

7. 整体优化

整体优化不应该被简单理解为全面优化，我认为对整体有利的优化就可以称之为整体优化，当局部优化的程度达到足以提升整体的成效时就是一次整体的优化，这条原则强调的是局部优化的投入不应该大到拖延整体的进度。

当你跟上级说我要优化一下项目架构（不要以为架构层面的就是整体，说到底研发团队也只是整个项目的一部分），大概要花两三个月的时间时，可以让软件的执行效率提升20 ~ 30%，否则将来软件的执行效率会很差，一般情况下你会得到什么答复？

糟糕一点儿当然是被一口回绝，好一点儿的可能会被问问“现在的架构有什么局限？”、“新架构能带来什么好处？”，多数人在多数情况下是争取不到这么长的时间去做这种拖慢产品进度的优化的，无关于这次优化是关乎局部还是整体。

或许经过几个版本的迭代后你所担心的问题终于发生了，软件运行的效率大大降低，这个时候我们应该暗暗冷笑上级只顾眼前利益吗？

我觉得我们应该考虑一下自己给出的方案是不是真的考虑了整体，方案够不够敏捷。

其实张口就要几个月的时间本身就是没有考虑到整体，技术停下来优化各两三个月，那让产品、设计、运营放三个月长假吗。或者你独立出来搞几个月，你确定几个月后你还追的上产品这几个月来的迭代？

一个优化需要两三个月的时间这显然是不够敏捷的，甚至无法保证最终优化的框架是不是真能达到预期的效果，“不能达到预期效果”正是困扰瀑布流模式的问题，也是敏捷开发提出短周期提交可用软件所要解决的问题，当你坐在上级的位置上肯定也要考虑局部优化对整体利益的影响，既然我们是在敏捷开发这个大的项目开发流程下，那么局部的优化也应该遵循敏捷的原则，化整为零，逐步迭代。

我想针对上面说的花两三个月的时间优化框架这个请求，如果我们提出的方案是三到五个迭代每个迭代两到三周，每个版本都可以让项目开发的效率提升5~10%，再跟上级讲讲不优化可能带来的软件运行效率问题，我想上级点头的可能性会大大增加吧。

本文由@汪仔8925 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash, 基于CC0协议。