接着 03.29.一.价值是什么 📚 的结论：价值就是我们喜欢的东西。

我们先看看《软件开发本质论》中的观点

如何衡量价值

可是罗恩，听你的意思，价值好想完全是主观的。难到我们不应该根据真实可靠的数据信息来进行决策吗？那么，你都有哪些反对衡量它的理由呢？

你说得对，我的确反对用数值方法衡量价值，即使是估算成本我也不赞成。下面，我来解释一下原因。

首先，我们并非真的知道数据。
对于几乎任何相关的产品，我们都不知道数据。我们既不知道有多少用户会使用功能特性，也不知道产品能挽救多少人的生命，同样不知道人们会给我们最新的想法打五星还是三星。我们还不知道在打完分后，他们是否会购买产品。

鹤说：确实现在是可以通过一些手段收集用户功能特性的使用情况，但我们要论证的是，我们收集到的数据，是能真正的反映现实，还是提供虚假的安全感。


其次，大的差别很重要，小的差别则并不重要。
当我们审视面前所有的功能特性选项时，会发现其中有一些功能特性非常重要，而另外一些则相当乏味无趣。这两者的区别很重要：我们需要区分哪些是特别重要的，哪些是乏味无趣的。

最后，不同类型的价值不具有可比性。
产品推动人会关注很多不同类型的价值，而随着时间的推移，某种价值可能变得越来越重要或者越来越不重要。有时，我们需要知道用户的看法：他们会觉得某个想法有用吗？有时候，我们需要了解开发相关的信息：实现某个想法是需要花费一天，一周还是十年？还有的时候我们更看重的是能否取悦用户或者潜在用户：如果能快速的交付某个功能特性，那么他们可以马上付款。那么，到底该怎么做呢？

但是罗恩，“价值”到底是什么呢？应该如何衡量价值呢？我们怎样才能够确定得到了价值呢？

不必恐慌！其实，对于价值是什么，你已经很清楚了。不妨挑两件你可能要做的事情，问一问自己接下来会去做哪一件。你选择做的就是当前，更有价值的事情。你似乎总会知道要去做哪件事情。若不知道，就再问一问自己是否这两件事情都不值得去做。

如鹤说：果你纠结，是不是说明内心深处认为不值得去做，这倒是一种不错的思考路径。

确定做哪件事情之后，再来想想你为什么会这样选择。将你的想法记下来，然后继续追问为什么。通过这样做，你就能认识到你关注的是那些维度的价值。然后咨询项目干系人（项目利益相关者），问问他们的想法及其理由。这样就能了解什么以及为什么重要。

我们总是很难抗拒用数值表示价值的做法，如果你的确有一套这样的表示方法，不妨试一试。挑两件事情，计算一下两者的价值所应对的数值，看看所得的结果是否与你的想法一致。若一致，就继续使用这一方法；若不一致那就有趣了！继续完善你的方法，直到两者一致。如果总是不一致的话，我建议你干脆放弃这一方法。

使用数值来表示价值可能会使我们滑入深渊。如果公司开发产品的目的是赚钱，那么就可以使用产品的销售收入来衡量它的价值。但实际上，并没有什么好方法来判断这一数值是否是不错的衡量指标，因为他将销售问题，产品问题，当然还有顾客的问题都混在了一起。

更糟糕的是，大多数与金钱有关的衡量指标在时间上都落后，因为等我们得到有关的信息时，为时已晚。同时，也没有真正好的办法来判断收入数据是好是坏。因此，金钱是糟糕的指标：不仅慢，还无法判断它是好是坏。

鹤说：这使我想起了《高效能人士的执行4原则》中提出的“引领性指标”与“滞后性指标”。金钱就是典型的滞后性指标，结果都出来才知道是否已达成。我们更应该关注的是引领性指标，我们做了哪些可能会带来好的结果，这是需要我们不断实践与改进的。

我很希望能有一个简单的答案，像功能点的数量，或者用户点击次数等。如果你发现这些数据有用，不妨绩效使用。不过需要明白的是，所有这些衡量指标的真正作用是帮助产品推动人，项目干系人，以及团队成员理解什么是真正的价值。

相反，更好的做法是与开发人员和项目干系人坐在一起。考虑要做的事情。将所有人都认为最有价值的事情作为接下来要做的事情。这样做的意义在于学习怎样达成共识。

鹤说：简单的答案，可能只代表了部分人的想法，我们本来就是一个复杂的群体，需要一起交流沟通，才可能达成共识，从而选中我们想要的东西。

接着，实现选定的功能特性，并尽快交付，让后倾听用户的意见，再重复上述的过程。

鹤说：如果没有想清楚，那么先做，尽快交付，我们可以从结果中学习成长，让我们下一次更接近我们的目标。

自我总结

衡量价值，没有捷径可走，但也不要着急，因为我们想要的东西，是值得我们一直去追求的。