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

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

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

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

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

从中可以分析哪些活动是增值活动，哪些是浪费？活动与活动之间的前置时间可否缩短？整个价值创造过程的用户体验如何？

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

一、运营价值流

我们开发一个产品或者系统，一定是帮助某些人创造某种价值。

假设我们研发物流管理系统，我们要了解和定义客人从「有运货需求」到「货物被运到目的」这个价值被实现的整个过程。

涉及到哪些人，哪些系统？哪些步骤？前置时间多久？客人体验如何？简单来说，如果物流是公司的服务和生意，我们是怎么做这个生意的？

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

二、开发价值流

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

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

举个例子，重要的活动可以是「Lean Value Tree」，它定义产品的战略性目标和北极星指标，确保在后续漫长的开发过程中，团队有一个长远的方向指引。

又或者是「Event Storming」，它是一个确保团队里所有成员对业务有一个基本认知，并且开始建模的工具。这个活动可以避免程序员和产品经理之间的鸿沟。

每个团队的情况不一，Leader 带领团队审时度势地定义对团队重要的活动，这是关键。

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

再比如，团队（而不是产品经理）拆解 User Story，是另一个关键活动。这个决定来自于我的心智模式：开发团队是解决问题的人，拆解 User Story 实质是在分解问题。一个不会分解问题的人或团队，绝不是解决问题的高手。

如上，定义并持续演进团队的「开发价值流」，让它成为团队的「操作系统」，绝非易事，却能深刻决定一个团队的战斗力。

「开发价值流」生产的是产品或者系统。它影响的是「运营价值流」的精益与否。

三、赋能价值流

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

我们需要提供培训、塑造环境、传授经验、构建知识、移除障碍，让「开发价值流」流动起来！

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

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

「赋能价值流」生产的是你的员工，还有比员工更有价值的事情吗？它影响的是「开发价值流」的精益与否，以及是否能自我进化。

综上，所有的活动都可以围绕这三大价值流，三者之间环环相扣，又处于不同的维度。

善用之，天下或定。