如何以价值流为中心优化工作流程

一次处理多个项目是很难取得实质性的进展的。如果我们根据价值流进行组织，那么我们就可以帮助工作流贯穿系统。

寻找流
当你在做某事或做活动时感觉到时光飞逝，而工作正在进行。每个人都想实现它。我们之所以能实现生产力，并不是因为这很容易，而是因为所有的系统都可以协同工作。但是流量不仅仅针对个人。它是针对团队和组织的，并且是开发运维的第一个核心目标之一，它借鉴了精益(Lean)的思想。
管理流
在所有工作系统中，我们都致力于优化流程。这个概念得到很多人的推广，包括EliyahuGoldratt博士，他在《目标(Goal)》一书中描述了约束理论(Theory of Constraints)。该理论指出，任何系统都存在瓶颈，这个瓶颈导致系统之前的工作堆积如山，而系统之后的下游工作站无活可干。分析工作流程就是为了提高和减轻约束，从而使工作可以更快地通过系统。在我们的业务中，我们常常将这种工作流称为价值流。
将价值流可视化的最佳方法之一是“价值流映射”，这在制造业中得到了广泛的应用，但这也可以在其他过程中使用，例如软件交付。另一种方法在软件交付中则更加普遍了：敏捷板(Agile board)。无论我们使用Scrum还是看板，我们几乎都可以实时地查看工作在白板上从左向右流动的情况。我们还可以看到瓶颈。为什么那个用户故事在同一“等待”栏中停留了3周?为什么这个故事说这是目前分配给在哥伦比亚度假的某个人?
敏捷板使我们可以将各种瓶颈可视化，但是如果未将敏捷板实施成贯穿于系统的慎密的策略的一部分，则工作可视化本身就是瓶颈!
工单系统
我们中有许多人都与大型IT组织打过交道。通常，如果你想完成某件事，答案就是“提交工单”。你需要新手机吗?提交工单吧。想要创建一个新的电子邮件群吗?提交工单吧。想要了解生产情况?提交工单吧。这往往会产生一个冗长而反复的工单提交周期，如被要求对工单做出澄清，检查工单状态，而且你往往还要忍受更长的等待时间，最后才能得到解决。
工作是在人与人之间递交的，因此工单实际上就是交接的任务。在精益思想中，交接以及由此而来的等待被认为是浪费。如果我们根据工单系统中的交接来设计工作流，那么我们就是在设计时将浪费也带进来了，这将减慢我们的流程，因而减少了价值流中的工作流程。
工单是有意使我们的过程中断的。在软件开发中，我们会遇到某一类名为例外情况的错误。一种例外情况的意思是软件不知如何是好而故意中断，因为它需要人来解决问题。这也许是由文件丢失，权限错误或一些可怕的东西引起的。我们的工单系统旨在创建例外!这实际上就是异常行为，或者非程序(在软件中)或流程(在价值流中)的正常组成部分。创建工单后，系统将停止并等人来解决问题。
通常，我们在工单系统中看到的工作类型是重复且简单的。在站点可靠性工程(SRE)中，我们称其为：“劳碌”。在《站点可靠性手册》中，Vivek Rau将工作定义为：“这是这样一种工作，它往往是手动的，重复的，可自动化的，战术性的，没有持久价值并且随着服务的增长呈线性增长”。如果工单系统用于IT部门，则可能是有人需要新的鼠标或电话。如果用于生产运营部门，则可能是将数据从一个地方复制到另一个地方，或者针对数据仓库运行数据报送。
但是，所有这些活动的共同点是辛劳。这种辛劳成为系统中的瓶颈，并阻碍了价值流的流动。作为领导者，我们的工作是减少繁重的工作，将人们解放出来，从事“不乏持久价值”的工作。在脸书或Salesforce，如果你需要新的鼠标或更多的内存，那么你可以使用你的工牌在自动售货机中获取。使生产操作工作自动化的这样一条原则是Amazon Web Services(AWS)API概念的核心。过去，如果你想要一台新服务器，那么你需要提交工单并等待。有了AWS，你则可以通过软件或通过单击Web控制台进行API调用，几分钟后，你将获得一台服务器!
故事流
尽量减少工单系统中的工作量并不意味着我们不需要跟踪工作。任何采用敏捷方法的公司都将在Jira这样的工作跟踪系统中管理项目工作。不幸的是，很多工程师不喜欢项目跟踪软件，正如他们不喜欢开会一样!
为了确保最大程度地使用跟踪系统，最好使其变得尽可能简单(但不要太简单)。从根本上讲，这是一个用户体验问题。如果人们在与系统交互时不能获得良好的体验，那么没有人会乐此不彼地使用这样的系统。我发现，许多热心的项目经理在系统中设计复杂的工作流，其中包含许多必填字段，这些字段对工程师没有任何意义。如果工作流程过于紧凑且缺乏灵活性，那么系统将无法得到使用。如果字段和必填的复选框太多，系统也同样无法得到使用。
通常，在尝试收集大量要报送给高级管理层的优质数据的过程中，我们最终得到了一个系统，这个系统收集的高质量数据要远远少于当它以更简单的形式实施时所收集的高质量数据。我们的目的是使工作可见，以便我们可以查找流程中的瓶颈并确保系统按预期工作。如果我们有优质的数据，我们就知道怎么报送才算好。就像在机器学习中一样，如果我们有不良数据或干脆没有数据，那么我们期望的结果的质量会很差。
我们需要根据“敏捷的猪(而不是鸡)”的形式来组织系统的效用，以最大化该工具的效用。既然工程师们必须通过编写代码为业务创造价值，那么我们就不应该让他们为了高级管理层而花很多额外的时间来解决问题。
按产品而非项目进行组织
一旦我们完成了这两件事——不断消除工单系统中的辛劳并确保我们的工作跟踪系统不会带来过多负担，我们接下来如何组织工作?
MikKersten博士在其著作《从产品到项目(Product to Project)》中讨论了围绕产品组织的工作与围绕项目组织的工作之间的区别。在项目模型中，人员被分配到工作中，工作完成后，他们将被分配到其它的工作中。在产品模型中，工作被带给了人们，并且有这样一层理解，即我们永远也“完成”不了交付品，因为交付品本身就是产品。
例如，如果我们要完成一个修补服务器漏洞的项目，那么我们将组建一个团队，这个团队将展开分工并修补所有服务器，这很有可能涉及大量相关工作。但是，下次需要修补服务器时会发生什么?我们是否重新组建团队，让这个团队像以前一样重做一切?那再下次呢?下次再下次呢?
相反，如果我们将围绕如何为服务器修补漏洞而打造(或购买)一个产品。我们会分配一个团队，该团队的其中一个职责的就是修补服务器。刚开始的一两次尝试，他们也许会像以前做项目的方式一样来完成工作。但是到了第三或第四或第十次尝试时，他们可能会投入大量的工程时间和精力来使修补服务器的工作尽可能快速而轻松。他们希望努力消除辛劳，使工作更轻松，而非重复机械运动。
这是一个很好的例子，这说明了即使是运营团队也可以交付产品。在修补(或监视或部署)产品的例子中，该产品的客户恰好是内部客户，这与我们所面向的普通客户不同。
一种产品
就这些产品而言，我们要这样组织工作，即便于专门交付该产品所需的一切东西能在同样的空间中得到跟踪，这很重要。工作不应分散在同一工作跟踪系统中的多个不同空间中，而应分布在同一空间中。这是我们从跨职能团队那里学到的经验教训：当交付产品的所需的所有功能都具备时，而我们不必等工单系统交接工作。
产品交付中涉及的每个人都应有权使用有关交付产品所需数据的数据。每当我与客户合作时，运营团队会说：“我们尽了自己的职责，这就是开发团队的责任。”我解释说只有一种产品!产品不分开发与运维，只有一种产品。我们的客户不在乎开发团队是否履行了职责。工程负责人不在乎运维团队是否完成了任务。这些客户关心产品是否按时高质量交付给客户。两个团队都有责任齐心协力，以确保实现那些业务目标，毫无疑问，这才叫开发运维。
因此，所有工作都必须在与产品相关的同一空间中得到跟踪，包括修复工作。我发现有很多团队在发生事故后进行事后评估或学习各种评估，然后才提出一些要完成的修复项目，以防止下次中断。但是这些项目是单独跟踪的，而非常规工作跟踪系统的一部分，因为它们是“特殊”项目。问题是，它们并不特殊。Kersten博士告诉我们有四种要应对的工作类型：
功能
缺陷
风险
债务
应对风险只是他所谓的“流程项目”之一。简而言之，补救工作就是工作!这意味着需要分清工作的轻重缓急。如果存在需要为企业偿还的技术债务，或者比补救(风险)任务更为重要的错误(缺陷)，那我们就不应声称风险是特殊的，而应首先进行此项工作。
传统的项目管理
有些人可读到这个可能想知道“传统项目管理适用的地方是什么”。他们一直部分轻重缓急地管理着所有的项目”。项目经理在这种新模型中发挥着更为重要的作用，这才是最妙的地方。
在这个模型中，工程师有权管理自己的工作。他们不需要项目经理来询问状态报告，也不需要将已完成的工作录入为正式的清单，因为这都是系统的一部分。工程师可以轻松录入。在这种新的工作方式中，项目经理可以利用自己最擅长的技能，这些技能通常是与人共事并跟踪进度，但他们可以使用这种工作方式来确保工作在系统中顺利进行。
在任何足够大的系统中(足够大而需要项目经理)，团队之间总是存在依赖关系。这是项目经理可以派上用场的地方。他们不是管理一个或多个团队中的关系，而是管理各大团队之间的关系。
Dominica DeGrandis曾向我们的行业讲授了时间盗贼的概念。那些通常看不见但是拖慢价值流速度的东西。未知的依赖性盗贼是一个不容小视的问题。DeGrandis女士解释说：“依赖性(无论是基于体系结构，专业知识还是活动)，增加了协调的必要性。”
这是我们的项目管理组织非常熟练的地方。他们是主要的协调者，他们可以揭示这些依赖关系并使团队、产品和组织通过价值流对快速的工作流程进行优化。
随着敏捷和云的出现，项目管理发生了很大变化。Kersten博士解释说，擅长实施软件的公司将蓬勃发展，而那些苦苦挣扎的公司将瞠乎其后。人们只要观察一下技术巨头进入新市场和推出新产品并取代已有参与者的这种能力就明白这一点。只要通过消除辛劳和消除流动障碍来优化价值流，我们就可以使公司在市场中以有力的地位参与竞争并与客户一道继续蓬勃发展。