技术型管理被俗称为「打杂的」，一点都不夸张。

业务、产品、架构、流程、人员、会议、汇报、外交、项目管理、沟通、培训、激励、代码评审、招聘、解决冲突、持续学习…不一而足。

如何确定每天工作的优先级？如何确保所有的忙碌能产生动量和结果，而不是像驴一样原地打转？

一个简单的方式是：围绕三大「价值流」组织你所有的活动。

三大「价值流」

「价值流」是 Lean 里面最重要的概念之一，表示创造某种价值的一系列长期步骤。包括价值、活动、人员与系统、前置时间等等因素。

SAFe 里定义了两个价值流，我加了一个。如下图所示，应该是我的首创吧。

一、运营价值流

「运营价值流」指的是为了向客户交付产品或者服务、以实现其价值的一系列活动。

比如，作为一个物流公司，客人从「有运货需求」到「货物被运到目的地」这个价值被实现的整个过程，就是我们的运营价值流。

这个过程会涉及到很多步骤，比如询价、下单、确认货物，等等。用「价值流」的视点来看待它，会有几个主要的观测点。

「价值流」，顾名思义，有两个重点，一个是「价值」，一个是「流动」。

一切对客户价值不直接产生价值的步骤都是一种浪费，比如「内部审批」，假设客户来询价时，我们的销售人员需要主管的审批，才能把某种折扣的价格报给用户，这就是一种浪费。

当然，不是所有的浪费都是可以或者需要被消除的。但是，浪费一定是一种信号，它可能代表了一种改进的机会。

另外，步骤之间的等待时间，往往也是不产生价值的，并且形成不好的用户体验。比如，从客户下单到确认货物之间的等待时间，有些公司需要 10 分钟，有些公司需要 1 天。哪个公司的竞争力更强，一目了然。

二、开发价值流

在理解和定义「运营价值流」之后，我们才知道要开发什么样的系统或者功能，去加速和优化「运营价值流」的运转。

而一个研发团队的开发活动本身，也一样可以用「价值流」的方式来审视。这称之为「开发价值流」。

「开发价值流」是为了「运营价值流」中的一个或几个步骤服务的，所以，「开发价值流」的第一步，应该是识别和定义未来的「运营价值流」。

比如买飞机票这件事，十几年前我就亲身经历过这样的「运营价值流」：在报纸上找到旅行社的电话，电话告知想购买的机票，并告知对方姓名和身份证，旅行社买好后，约定好双方碰头的时间地点，然后一手交钱一手交票。

软件显然已经颠覆了这个十几年前的价值流步骤。如果我们开发软件或 App 去支持这样的价值流，那就太傻了。

也就是说，我们开发软件，首先要了解现有的「运营价值流」，但是不能受限于它，要开创性地思考未来的「运营价值流」，为未来设计系统和软件。这就是对「设计思维」的需求。

除了这第一个步骤，再举几个我们团队「开发价值流」包含的重要活动。

Lean Value Tree

所有的团队都容易陷入到「构建陷阱」：构建一堆没人使用的功能。

关于「精益价值树」，可参考。它用于捕捉组织的愿景，以及产品的战略性目标和北极星指标，确保在后续漫长的开发过程中，团队有一个长远的方向指引。

这在涉及多个研发团队的大型产品开发中，往往非常重要，这些愿景和战略性目标，就是「上下同欲」的「欲」。

Event Storming

软件开发是一个共创知识和共同学习的旅行，而不应是知识传递的过程。

「事件风暴」是 DDD 里的一个实践，它确保团队里所有成员对业务有一个基本认知，并且基于共识开始建模，是一个可以避免程序员和产品经理之间的鸿沟的很好的工具。

团队拆解 User Story

很多团队只是把 User Story 变成了另一个需求文档，由产品经理写好后，交给团队去实现。

而另一种心智模式是：开发团队是解决问题的人，拆解 User Story 实质是在分解问题。一个不会分解问题的人或团队，绝不是解决问题的高手。

因此，让团队（而不是产品经理）一起拆解 User Story，就成为我们团队「开发价值流」里的另一个关键活动。

每天代码评审

随着 Github/ Gitlab 的流行，PR 或者 MR 的实践已经非常常见。

可是，有些团队一个 PR 需要 5 天 或者 8 天，评审的时候，面对一堆代码，经常就走过场了。就算看到代码有些问题，可是去挑战甚至推翻对方 5 到 8 天的工作量，谁能下那个决心？影响进度怎么办？所以，睁一只眼闭一只眼吧。

我们的应对之策是「每天代码评审」，当天写的代码当天评审完毕，若有修改，也可以比较快地改完，把问题代码扼杀在摇篮里。

当然，结对编程是理论上更好的实践。在团队并不适应结对编程的时候，守住「每天代码评审」的底线，不失为一种有效的办法。

设计「开发价值流」的原则

每个团队的情况不一，同一个团队在不同的时期，面临的挑战也不一样。所以 Leader 带领团队审时度势地定义并演化团队重要的活动，是非常关键的。

比如，我司因为 Stakeholder 太多且分布在全球，不确定性过多，研发周期过长，「Lean Value Tree」就显得至关重要。

又比如，因为公司的业务非常繁杂，产品经理常常无法凭一己之力定义有效的产品方案，为了团队少走弯路，团队共识显得尤为珍贵，这是 我们团队引入「Event Storming」的背景。

这是设计「开发价值流」的原则之一：识别开发过程中的瓶颈，针对瓶颈问题设计重要的活动，植入到「开发价值流」中去。

另一些活动，比如上面的「团队拆解 User Story」，则是我们心智模式和价值观的体现。它可能不是瓶颈触发的，却也至关重要。

因为这些团队行为，背后是价值观，团队对于这些价值观的践行，就是所谓的「公司文化」。

文化绝不是贴在墙上的口号，它是关于领导和团队如何做事的。团队在不同的情况下如何做事，就是文化。

这是设计「开发价值流」的原则之二：它必须符合领导想要植入到团队的心智模式和价值观。

因此，定义并持续演进团队的「开发价值流」，就是在设计团队的「操作系统」，在践行团队的价值观和文化。

我不认同 SAFe 里说的「开发价值流」可以标准化的说法。确实，一些东西是可以标准化的，比如 Scrum 的会议，Devops 的 持续发布 pipeline。但这些东西，要么不是「开发价值流」的一部分，要么，它不足与让一个团队出类拔萃。

「开发价值流」促进持续改进

如上所说，价值流的重要作用在于提供了一个端到端的角度，去审视开发团队：

举个例子，我曾经一个团队的价值流图如下，（括号里是我的反思）

如上，用精益的眼光去看这个价值流图，它可被改进的空间是巨大的。它让我们有了端到端的全局思维，不再头痛医头脚痛医脚。

三、赋能价值流

最后，管理的职责是确保团队能够理解并且自行优化「开发价值流」。

我们需要解释价值流的概念，需要把精益思想不断地传递给团队。我们还需要提供培训、塑造环境、传授经验、构建知识、移除障碍……才能让上面的「开发价值流」流动起来，

以上面的例子来说，并不是每个人都能那样反思，并且看到问题。这本身是需要知识和经验作为基础的，这就是管理者可以向团队「赋能」的地方。

我们还需要让团队能够自行微调和优化「开发价值流」，而不是守着设计好的「价值流」一成不变地墨守成规。

我最喜欢的一个关于「看板」的说法是

看板不是关于流程的，而是关于流程的流程。

看板不是把流程固化在板上，而是一种团队可以发现问题、调整流程的机制。

在「赋能价值流」上，我们使用的工具可以是 Training，Mentor，Teach，Coach。这个对 Leader 的要求可以扩展地非常广，就不展开了。

在这个领域，我们的工作对象不是软件，而是员工。

「生产你的产品之前，生产你的员工。」

综述

• 「运营价值流」生产的是客户的价值。它影响的是公司的收入和成本。

• 「开发价值流」生产的是数字化解决方案，这些解决方案是为了服务「运营价值流」上某些或者全部活动的。

• 「赋能价值流」生产的是你的员工，而人是「开发价值流」上最重要的元素，没有之一。

这个简单的框架，可以让技术管理者确保自己所有的活动，最终都落在价值上（要么是业务价值/客户价值，要么是产品价值，要么是员工价值）。

再配合上「系统思考」这个工具，根据团队的实际情况，来有所侧重地组织自己的活动。

比如，开发的功能没人用或者不好用，则应多关注「运营价值流」；产品的内部质量出现问题，则多关注「开发价值流」；开发流程一成不变，陷入僵尸敏捷的境地，则可多关注「赋能价值流」。

框架带来的好处还有：个人可以在这个框架下，不断修炼自己的技能（赋能就是一个很深的技能）。我在路上，您呢？