这本书讲的不是技术，主要讲的是开发过程，属于软技能。
image.png
我先说一下这本书说了些什么，以上这个金字塔式的图就是贯穿全文的逻辑，书中并没有正面解释这个金字塔模型的意思（我估计是翻译的问题），我按自己的理解解释（瞎扯）一下。
首先看金字塔内的几点，从上至下是「价值」一直到「指导」，就是每个软件项目或者版本从计划一直到落地实施的思考过程；而下面每一项左右都有一个描述，左边称之为愿景，右边就是我们为了达到愿景需要具体输出一些什么，下面我的解释：
- 「价值」，每个项目肯定都会有目标，甚至是愿景，就是需求方想要的东西，这个称之为价值。软件发布后看是否成功，其实就是看结果跟价值的匹配度有多少。
- 「质量」，这个是每个软件的基础，如果软件的质量达到及格线以上，才有评判价值的可能；否则一个质量欠佳的软件，平时日常就陷于救火状态，那就没有时间追求所谓的价值。高质量的愿景就是「零缺陷」，为了尽可能每一个发布的版本都要无限靠近「零缺陷」，那就需要「设计良好」来支撑。
- 「划分」，保证每次输出的质量要好的话，那每次输出版本的功能划分就必须要「小」，将功能特性划分为小块，使每一块尽可能小，前提是它们仍然「完整」的小功能，而且这个小功能是按价值优先排序的。这样就能够尽早地构建出有用的产品，并在交付日期到来之前对产品进行优化与提升。
- 「构建」，通过逐个实现功能特性来构建产品，这样就能够频繁地进行价值的交付，这个构建出来的产品功能是以「价值优先」作为依托；同时能够尽早、经常地看到项目的进展，看得见才能真正「逐渐完善产品」。
- 「计划」，计划重点在于「持续」计划，因为我们把任务切成小的，所以我们的计划只能把当前的版本做详细，后续的我们需要「持续」做计划，有了计划我们就知道「接下来做什么」。
- 「组织」，为了更好地完成工作，需要对「团队」进行组织。而团队分工，就是对人员与技能的分工。
- 「指导」，通过组建以创造价值为己任的团队来实现价值的创造，因此需要确保团队成员知道客户需要什么，以及客户留给我们的开发时间。我们通过观察实际构建出的产品来对团队的工作进行指导。
看上面的图金字塔，「价值」在顶端，从视觉上也感觉到这个概念的重要性，是所有事情的起源。其实估计大家都知道价值的作用，但我们经常在执行的过程中，特别是过程时间比较长的时候，就容易会忘记了价值的初衷，导致方向的偏移。
价值肯定跟用户是有相关性的，如果做事发生偏移，肯定是价值目的有所偏差，原因可能是目的跟用户无关，可能甚至是用户都是错的。
我们搞技术的肯定一般会更容易遇到偏移价值这个问题，我认为有一些原因：
- 技术人员通常离真实用户都有点距离，甚至很少直接接触到用户，需求在传递可能已经被转了几手，甚至已经面目全非。技术人员遇到一些技术困难或者不合理的要求时，就很容易聚焦到已经设定眼前的问题中，也就是钻牛角尖。
- 技术人员在实现方案上本来就已经要花费大量精力，相应考虑价值的精力就会变少。所以技术人员通常会把方案落地、需求实现作为目标，而容易忽略人的因素。
- 我们it人员其实属于服务业，其实跟去餐厅的服务员类似的，只是工种不同罢了。服务对象是「人」，我们的产出实际都是跟人用的，有人用起来有数据才彰显it人员的服务价值，但干it的都以为自己干的高科技，都觉得出了问题都是用户“不会用”、“用户不懂”，没意识到其实自己也是服务行业，不管是“不会用”还是“不懂”，其实就是价值没有体现出来的症状。
举一个常见的例子，大家可以对号入座感受一下，我自己也经常犯这些毛病。
- 程序员看到了某个流行的架构或者语言，就很想有冲动在项目中应用，继而大刀阔斧重构一番。我是过来人非常明白这种心情，但实际却不是那么容易的事。新技术不单只考虑是否适合实现方案，还要考虑维护成本、生态成熟度、能不能招到人、跟公司内部契合度、配套工具是否成熟等等，这些每一个的考虑项，在需求方那里称为「风险」，风险就是实现不了用户价值的可能性。不是说不能用新技术，但我们要以风险的概念去考虑新技术使用的可行性，并不是纯粹自己的练手，让用户为风险买单，练手也需要讲「武德」。
- 产品经理做需求的时候，通常画的第一个图就是“用例图”，用例图上面主要有2个标识：用户是谁、用什么功能，其实这就是一个项目的可视化的核心价值。我们做小项目或者临时需求的时候很可能没这张图，有时候就会出现功能和用户理解脱节，我们技术人员一个劲讨论功能怎么实现，结果连这个功能给谁用的都可能不清楚。
- 项目需求来了，我们需要设计方案和估时，但花了很多时间排期用户都不满意，想要的东西都太慢了；我们技术也很无奈，就几杆枪又不可能随意加人也不能随意承诺，做计划也不能把加班就计划进去，这都是缓冲时间呢，也不能无中生有一些生产力吧，就这样进了一个死胡同。这个时候我们可以回到原点，看看用户其实最在意的是什么，究竟最优先的要解决什么问题，技术人员跟用户在一条战线而不是对立面，才可能把问题化解。
我们在开发过程中，如果遇到任何异样的时候，其实可以尝试回到原点，看看自己是否清楚自己做的事情价值在哪里，究竟为了什么而做；特别是对用户的价值，可以多跟用户确认一下大家对这个项目的价值是否有共识。有时候用户自己也不知道怎么表达这个价值表达有误、表达得不专业，甚至会有可能因为某些原因掩盖了一些真实的价值，所以需要多问几层“为什么”来挖掘才能找到真正的价值所在。
最后说一下，看得见的事情才能管理得到，看不见说不明白的事情就容易放飞自我脱离轨道。
价值是要通过事实来证明和呈现，而通常事实的痕迹就是数据。所以我们做项目的时候，要考虑如何从数据上证明自己带来了价值。
- 业务系统做一个功能，我们需要埋点统计用户行为，有人用的吗。
- 优化做性能对比，优化前后数值都是多少，效果好不好。
- 有一些量化不出来的，就需要进一步细化可以量化的目的，比如重构就不好量化，但重构是为了减少运维时间，那我们就有意识统计故障维护时间，来对比重构前后的效果。
我看过罗翔老师的视频和书，他多次提的一句话是“人是目的，不是手段”。
对应技术而言，技术都不是目的，而是手段，用户价值才是目的。
网友评论