彼得·格鲁克 说：一个专业人员的产出必须与其他人的产出结合在一起，才能产生成果，知识工作的产出需要被转化才有意义。而我们一般将知识工作的转化称为 “价值交付”。由于经常跟 “价值交付” 打交道，就像修炼武功秘籍一样，脑袋里总会浮现出各种各样的 “小人” 指导自己应该如何行走下一步。
本文就跟大家分享一下，我脑袋中的这些 “武学套路”。
模型思维
从认知角度来讲的话，这些 “小人” 其实指的是一种 “模型”，它们就像 “提线木偶” 一样，建立了思维世界与真实世界的联系。
拥有 “模型化” 是思维习惯，会增加我们分析问题的角度，我们可以截取某一个片面，来对真实世界用各种 “模型” 进行分析。所以，人们经常这样说：The model is a tool, not a mirror. 或者说：All models are wrong, but some are useful.
模型只是真实世界的一种抽象，而不是真实世界本身。
下文我们就用 “模型” 来介绍 “价值交付”。
“夹心饼干” 模型
在软件开发领域，各项工作是有纵深的，或者是有上下游关系，分为上层开发和底层开发，底层开发提供了上层开发需要的各项基础设施。有不少人会觉得 “底层开发” 是一项比较 “体面” 的工作，其实不然。因为对我们来说 “底层” 工作，其实还会由更 “底层” 的工作来支撑。每一层工作，就像一个 “夹心饼干” 一样，我将它分成了 3 层结构。
- 业务需求
- 转换
- 技术资源
为了完成本层工作，我们需要：最大限度的利用技术资源，做最高效率的转换，来尽可能多满足业务需求。
“二八分层” 模型
接上文，每个层次的工作可能会有一个或多个团队来进行支撑，这些团队的人员，会自发的进行分工。大概有 80% 的人员进行业务开发，20% 的人员进行技术支持。并且这 20% 的人员跟更底层团队 80% 的人员，其实做着类似的工作。
这就给了我们一个启示，在当前团队中追求 “技术” 也许不是一个最好的选择，也许下沉到更底层团队做 80% 的工作，才是更好的选择。同时，做业务开发的人员，也许上浮到更上层团队做 “技术支持” 是一个更好的选择。
“辐射” 模型
图中 “方块” 表示价值的提供方，“圆圈” 表示价值的接收方，有以上三种比较常见的价值交付模式。
- 做 “加法”：每增加一个价值提供方，就多交付固定的一些价值
- 做 “乘法”：每增加一个价值提供方，就多交付 N 个价值
- 做 “指数”：每增加一个价值提供方，就多交付指数级的价值
“加法” 是堆人靠武力解决问题，“乘法” 是制造工具提高 N 个人的效率，“指数” 类似于传销产生链式扩散效应。
“事件网” 模型
我们每个人其实生活在 “一瞬一处”，“一瞬” 指的是在某件事情发展过程的一个瞬间，“一处” 指的是众多事件的某一个。有句古话说：不谋全局者，不足谋一隅，不谋一世者，并不可谋一时。所以我们要能看到 “一世” 和 “全局”，看到事情的发展趋势（规划），看到它跟其它事件的关联关系（结合点）。
“滚雪球” 模型
在电视或电影中我们看到过以上场景，一个雪球在沿着坡道往下滚动的时候，越滚越大。这其实很符合价值的积累和交付规律。
雪球上方的积雪，由于被推到了 “上面”，由于受重和旋转的原因能提供动力，让雪球滚起来，这像极了一个团队或一件事情创造的外部价值 —— 有价值才能滚起来。单纯只能滚起来并不行，因为如果不产生积累，雪球就会越滚越小最后无力支持下去。上图中雪球可以越滚越大原因在于 “积累”，雪球下方会不断吸纳积雪，让雪球越来越大。这像极了一个团队或一件事情的内部沉淀 —— 有沉淀才能长远发展。
“问题驱动” 模型
我们每个人的工作其实是受外部 “问题” 压力而驱动的，每一个问题就像一根 “针” 一样穿透进来。必须有针对性的解决它，才能避免这个问题对自己造成伤害。也有一些时候，我们会忍不住解决一些尚未形成问题的 “问题”，这在开发领域也许可以称为 “过早优化”。其实这是不好的一种习惯，我们应该想到但不一定去做，要看得远，但不一定做的快。
一个比较常用的办法是 “藏锋”，把所有的预判都藏起来，一旦时机成熟随时可以拿出来解决。但是从外面看来，我们总是 “迟钝的”、“仅仅够用的”。
结语
上文记录了我经常使用的一些价值交付 “模型”，用图形化（或者说 “模型化”）的方式描述了大脑中的画面。
使得我们在遇到相关问题时，大脑中可以立即浮现出这些画面，指导我们少走弯路，一击制敌。
当然这些模型肯定不能说是 “典范” 甚至不能说是 “最佳实践”，只能说是我自己小打小闹的一种 “套路” 罢了。
《九月鹰飞》中有这样的一句台词：自古以来，真正的武林高手都有自己独特的性格，如果一个人连自己的个性都没有，又怎么能练出独特的武功来呢？
网友评论