本文基于精益思想和精益软件开发，针对研发过程中的“浪费现象”进行深入分析。浪费分成存粹的浪费和必要的浪费，其中存粹的浪费需要消除，而必要的浪费可以进行压缩。结合日常研发过程，本文对如何识别这些浪费、如果消除存粹的浪费以及如何压缩必要的浪费进行剖析，并提供思路和模式。

一．理论基础

精益思想来自制造业，引入软件行业不过10年，目前很多理念还是停留在理论阶段，很难在实际研发过程中进行直接应用和推广。精益的很多思想个人认为是对软件行业有参考价值的，例如本文的主题“消除浪费”。关于软件研发过程中的浪费现象可以总结为：

• 部分完成的工作：部分完成但没有最终落地的工作 
• 未应用特性：开发完成但没有被客户应用的特性
• 额外过程：开发过程中不需要的流程和中间产物
• 再次学习：人员、环节变动导致反复重新学习
• 信息移交：隐性知识信息的传递总是伴随信息丢失
• 任务切换：多任务工作会导致效率下降
• 资源依赖：因任务或资源相互依赖而导致工作停滞
• 系统缺陷：解决缺陷活动本身就是浪费

二．如何识别浪费？

我们有了理念，下一步是行动，首当其冲就是要识别研发过程中的浪费，个人总结如下识别浪费的模式：

1.      价值流图

价值流图（Value Stream Mapping, VSM）是精益思想中用于消除浪费的主要工具，其作用就是帮忙我们找到研发流程中哪些环节中存在浪费现象，整个生命周期中有多少时间是用在创造价值，又有多少时间是存粹的浪费。传统的软件研发过程价值流图可以抽象成如下（下方坐标中凹下去的部分代表产生价值的时间，突起的部分表示浪费的时间）：

2.      项目输入过滤

研发过程通常面向产品，而企业级应用或半互联网半企业级应用的产品最终通过项目进行实施和落地，这样项目线就成为研发过程的一个重要输入，而项目经理们站在项目线和客户的立场上提出来的需求和计划往往会和产品线、研发线有一定出入。如果本不应该进入研发环节的输入最终进入了研发环节就势必会导致浪费。如何通过规划和分析去把控来自项目上的输入，让项目线需求能够尽量和产品线一致是降低研发成本、消除浪费的一个重要方面，所以项目输入也是我们寻找浪费的一个来源。

3.      会议聚焦

我们不得不经常召开这种或那种会议，那开会是一种浪费吗？个人觉得很多时候是的。会造成浪费的会议通常会有一些共性，典型的有：

• 输入输出不明确
• 缺少主持人或主持人不善于引导
• 会议不是结果导向、无法形成有效决策
• 会议议程空泛而不能收敛
• 会议虽然能达成一致，但没有具体工作安排和责任人制度
• 即使有工作安排但缺乏跟踪和监控机制
• 会议相关的资料没有充分准备，也没有提前交付到参会人员

具有上述特点的会议很大程度上不会有实质性的成果，开完一次之后还需要开第二次，如果把握不好浪费的不但是时间还是团队的气氛，需要进行分析和识别，看看我们每天的会议中是否具有以上“smell”。

4.      数据传递有效性对比

目前主流的研发管理方法论中普遍认为沟通和协作是研发成功的关键性因素，而沟通和协作的背后体现的实际上就是数据传递过程的有效性。如果有两个研发团队，其中一个团队中数据从团队中的一个人传递到另一个人的过程无论在时间上或空间上都比另一个团队有效，那两个团队的战斗力无疑是不一样的。数据传递在沟通模式、媒介、工具等各个方面都可能存在效率不高甚至不合理的地方，浪费也就在这些地方不断的滋长，从而消耗着研发团队的战斗力。

5.      管理活动梳理

有人说团队如果足够“自组织”，那我们就不需要管理了。这句话虽然听起来有一定道理，但未必太过虚无缥缈。但从管理工作本身入手分析在工作流程、文档管理、任务分配等各个方面上是否存在冗余或者不合理的管理活动确实不失为一种识别浪费的实践。管理是需要成本的，管理做的好、做的精细更加需要成本，但管理过程本身也可能向代码一样需要随着研发过程和团队的演变不断进行重构，重构的前提也就是需要我们对管理活动进行分析和梳理，找出其中的浪费之处并进行消除或压缩。

6.      流程执行力

三．如何消除存粹的浪费？

通过本文第二部分的识别工作，团队中的浪费现象已经摊在大家面前。其中有很大一部分的浪费属于存粹浪费，这些浪费需要通过一定的思路和工作模式进行消除。个人总结以下9条作为消除浪费的主要实践：

1.      项目线的介入时机

首先我们来看研发团队的外围接口，这里把项目线看作是与产品研发线并列的另外一条工作线，这样项目线介入产品研发的时机就非常重要。参考“如何识别浪费”中提到的价值流图，我们可以看到第一步是项目线提出开发要求，然后第二步召开需求评审会议，第三步才是正式启动技术开发工作。如果项目线介入时机不合适的话，在第一步和第二步之间可能会有一个时间区间，第二步和第三步之间也可能会有一个时间区间，一方面步骤之间的时间区间本身就是浪费，而且对二步而言，需求评审之后如果技术开发迟迟不能开始，无论从需求管理和风险管理上而言都存在变数，这些变数的表现形式就是步骤内容需要调整甚至重新来过，从而造成浪费。

2.      研发范围管理

范围管理是消除浪费过程中比较容易联想到的关注点，因为范围决定着开发工作量。从项目管理上讲，避免范围“镀金“和范围”潜变“是范围管理的一个课题；从研发过程上讲，现在”简单设计“、”涌现式设计“等理念也被越来越多的研发团队所推崇。研发范围管理一方面要关注由于项目/产品团队提出的一些不必要、不符合产品战略的功能需求，也要在开发人员内部进行诊视，看是否有过度设计等现象的存在。

3.      高效决策

决策是行动的源头，源头如果没有把握好，后续所有环节都可能是一种浪费，这是我们面对决策的一个视角；另一个视角就是决策是正确的，但决策的过程是否高效。

XXXX相关人员定于XXXX召开XXXX会议。
会议输入：
1. XXXXX，请参考SVN地址
2. XXXXX
会议议程：
1. XXXXX，XXX主导
2. XXXXX，XXX主导
会议输出：
1. XXXXX，落实人员和时间安排
2. XXXXX
请各位做好会议前的准备，有任何疑问请与我联系。

一个议题明确、输入完备、责任人导向的会议能确保决策的高效性，避免出现浪费。

4.      跨职能团队

跨职能团队用于消除在信息传递过程中为了确保信息有效性而产生的浪费。跨职能研发团队成员主要包括项目线、产品线、技术线、质量保证线等，大家围绕某一个产品线/平台开展所有工作，确保坐在一起并能够实时、面对面沟通。互联网开发环境下，跨职能研发团队还可能包括运营、客服等角色，但销售、市场等相关人员通常不在该团队中。这实际上是一种强矩阵的团队组织结构，所有人保持在同一认识水平和工作节奏中。针对从“数据传递有效性“、”流程执行力“中识别出来的浪费，很多都可以通过该项实践进行消除。

5.      根本原因分析

缺陷本身就是一种最大的浪费。在开发过程中，bug不可避免，但这些bug的背后可能有其必然性，很多时候并不是开发人员或者技术本身的问题，根本原因分析的目的就是帮忙我们找到出错的背后是否有其必然性，然后通过分析这些必然性并提供解决方法，从而避免类似bug的再次发生。常用的根本原因分析工具包括5个why、鱼骨图等。

6.      产品功能标准化

标准化有很多层含义，项目管理标准化、产品功能标准化、开发流程标准化等都属于这一范畴，这里重点讲一下产品功能的标准化。当一个产品面向多个项目时，产品标准化就是消除浪费必须要做的一件事情。大家可以想象一下，如果每个项目都有不同的输入，这些输入虽然都长得差不多，但如果没有产品的标准化平台，来一个项目还得东抄一些代码、西拼一个功能，不但开发周期变长导致浪费，而且系统本身也会因为确保标准化而滋生bug，导致进一步的浪费。面对处于发展期的产品线功能，开发一套产品线功能，每次来项目时根据产品线生成框架再在其基础上二次开发通常是较好的做法。如果产品线已经比较成熟，那么产品的平台话就可以提上日程，从而为项目线适配产品线提供途径，最大限度减少因为项目线而导致的二次开发。

7.      技术评审

网上有一些技术评审无用论，但个人觉得技术评审在消除浪费方面还是很有用的。个人理解技术评审包括正式的技术评审和非正式的技术评审两大类，两者结合能有效的消除浪费。例如，产品经理在设计完产品需求之后、抛给研发之前，和UED进行产品UI风格和用户交互方面的讨论，这类就属于非正式技术评审，有助于把问题扼杀在开发过程之前。而类似需求评审、代码评审等都是属于正式技术评审的范畴，帮忙我们在研发过程中正确把握方向，避免因需求重复、代码维护等方面所引出的开发成本。

8.      过程资产建设

过程资产建设是一个组织级别的行为，体现在研发过程就是为了消除团队成员“再次学习“的成本。关于研发过程资产建设可以参考我的文章《轻量级研发知识管理--如何帮助研发人员建设过程资产》，具体不再展开。通过文章中提到的轻量级的流程和实践可以在很大程度上确保新人培训、开发交接、系统维护等方面所暴露出来的问题，从而消除浪费。

9.      流程重构

四．如何压缩必要的浪费？

上文阐述的是如何消除浪费的主要实践，但有些浪费通常是必要的，也是不可避免的，对这些浪费而言，我们的思路是尽量进行压缩，下面是个人梳理的7项压缩浪费的实践：

1.      代码质量

在消除浪费的实践中我们提到的“根本原因分析”关注的是消除那些引起产品质量问题的必然性因素，通常涉及的是开发流程、环境部署流水线上的因素。除了这些必然性因素之外，产品质量的提高需要质量保证部门的努力，但在精益思想中，通过测试手段进行质量管理是低效和不被提倡的，精益思想提倡的是内建质量，个人理解至少在技术开发人员内部要确立质量意识，典型的由于开发人员轻视代码质量导致浪费现象发生的场景有：研发团队没有确立开发环境和测试环境分离原则，前后端开发人员各自完成代码开发之后，只是通过简单的联调就提交测试，没有在专属的开发环境中进行集成测试，导致提测的服务在测试环境中根本无法运行，需要开发人员、测试人员多次交涉和调整才能部署成功，这是一方面；另一方面，由于开发人员没有进行充分的自测，导致很多本应该在调试阶段就应该发现和解决的问题最终通过内部测试流程由测试团队暴露出来，这里流程运转所需要的额外成本实际上就是我们讲的可以压缩的浪费。

2.      可视化

可视化同样与数据传递的有效性有关，虽然我们可以通过“过程资产建设”等实践消除浪费，但沟通成本是一种实实在在的必要浪费，需要进行压缩。个人认为可视化是一项需要推广的实践，信息的透明在敏捷等方法论中也备受推崇。可视化通常需要使用一定的媒介并配合一定的协作流程和报告系统，可以参考系列文章《研发范围和时间的“信息透明化”》。可视化的作用就是为团队和相关干系人提供信息辐射器，确保所有人对研发的范围、进度等达成统一认识。

3.      过程自动化

从过程改进角度而言，过程的自动化是一个可以持续进行尝试和探讨的入手点，对提高开发效率、降低由人为因素所引起的错误和浪费起到促进作用。日常工作中，过程自动化在潜移默化中影响着研发团队内部以及跨团队协作流程，通常包括程序开发、功能测试、系统部署和服务发布等领域，我们通过Ant、Python等脚本或Jenkins等工具平台进行过程自动化建设。

4.      并行工程

并行工程虽然听上去比较难把握，但可能很多时候我们都在不知不觉中使用这一思想。例如需求评审之后，开发人员编写代码和测试人员准备测试用例、前后台开发确定交互协议和接口之后同时进行开发等都是简单的并行化例子。并行就是分批思想，通过合理安排人员和顺序，可以把原来需要串行的任务变成并行从而提高效率。个人认为并行工程的难度在于管理接口和系统集成，如果能够保证接口的稳定性以及系统集成的成本控制，并行工程在某些场合可以很好的压缩浪费。

5.      短迭代

通过上图，我们可以很清晰的看到短迭代在压缩浪费过程中的价值所在。

6.      Feature粒度

关于Feature粒度的讨论关注的是如何在研发管理活动上达成一种平衡。对Feature粒度的划分可以采用以下方式：模块->功能线->功能点，即无论何种规模的系统，通过三级层次把范围划分到功能点级别，而研发团队面临的粒度即为一个个功能点。个人觉得一个系统的功能点在20~50之间可能是最优的，过少增加开发人员之间的信息传递成本，过多则导致管理活动成本的增加，两种情况都应尽量避免。

7.      单件流

五．小结

本文对精益思想中的识别和消除浪费理念在研发管理过程中的表现形式，以及结合个人平时的体会对如何有效的识别、消除和压缩浪费的模式和实践进行了梳理。对精益思想中提到的推迟决策、整体优化等理念还需要进一步加深自己的理解并争取能够应用到日程研发管理过程中去。

精益之识别和消除研发过程中浪费的思路和模式