度量的方法与途径,及其依据。
价值(value)不必以绝对单位来衡量。在许多决策中,只需确定现有行动中哪一个能使特定主体更接近期望状态即可。本文提出一种具有多个深度层次的方法论:从快速评估到集体专家判断和实证验证。 它从目标状态而非分数出发,检验因果联系和替代方案,考虑心理偏差,并以实用的决策卡和面向研究所的研究计划作结。
在职能层级中,每个单元都拥有一个流程,但没有人拥有跨越各单元并在接收方行动者处实现的价值流。本文面向管理者、产品与工程负责人以及运营人员,介绍 Æilus v2.0 角色与流程模型,作为在不增加指挥层级的情况下使价值归属明确化的方法。文中阐述了六种角色、必备的流程组和事件、按角色分配的工件、采纳路径,以及角色膨胀、官僚主义和价值作秀(value theatre)的风险及其防范措施。
OKR 设定方向,KPI 控制质量,但在管理系统中所有目标看起来都同等重要,因此方便且可衡量的事项往往胜过重要的事项。本文面向管理者以及产品、工程、运营和战略负责人,提出在现有目标之上建立价值层(value layer):每个目标和指标都获得以 Æ 计的计划价值和反价值估计,并关联到一个具名的价值系统和负责人,随后与已实现的价值进行核对。文中给出每个目标所需的记录、八步采用流程、一个示例,以及防范虚假精确和人为操纵的保障措施。
从其他组织复制来的实践往往无法达到预期效果,因为实践只带来了其形式,却没有带来使其奏效的价值系统。本文面向管理者以及产品和工程负责人,将实践定义为带有明确声明的价值假设的局部价值系统,阐明在领域政策下何时实践是可接受的,并给出构建和维护实践集的结构。
速度(velocity)、吞吐量(throughput)和 DORA 式交付指标描述了工作如何在流水线中流动,却无法说明它交付了什么价值,或产生了什么反价值。本文为产品和工程负责人提供了一种方法:使用价值系统图式(VSS)和 VSS Editor 对软件产品的价值系统进行建模,并按版本比较计划价值、已实现价值和回溯价值。内容涵盖流动阻力、泄漏、授权和 API 网关等共享节点、角色、节奏以及该方法的局限。
技术支持通常被当作成本中心来管理,这掩盖了它为客户和产品所创造的价值。本文将 Æilus 的支持模型重新表述为一条把反价值转化为价值的转换器链,为来源中的两个系数(VAM 和 ACM)给出最简公式,确定它们衡量的是谁的价值,并提出一套支持组织可以采用的测量协议。
管理者不断使用价值一词,却很少说明它是为谁而存在,并退回到把金钱作为唯一共同的衡量尺度。本系列的这篇入门论文以价值管理理论为基础,为实践者提供一套可用的词汇:价值系统、价值的四种形式、价值要素、反价值、价值流与转换器、不借助金钱的观察、视角反转以及转换器效率公式,最后附有一页的术语表。
回答由 AI 根据研究院页面内容生成。对话内容不会被保存。