我们塌到单一价的那次，顺手给自己加了一条看起来很怪的规矩：
以后任何价格，必须是 $0.60 每小时的整数倍。
这条规矩不是定价策略。它是从数据库字段里推出来的。
为什么
我们的每一单里存着一个费率字段，单位是整数的「分/分钟」。
- 现价 $3.00/小时 = 5 分/分钟 —— 整数，正好
- 想定 $3.50/小时 = 5.833… 分/分钟 —— 表示不了
想定一个表示不了的价，得先把字段单位改细（比如改成厘），然后把全部存量单据迁移一遍。
而这件事有个要命的约束：它必须和改价同一次上线。分两次上，中间那段时间里新价按旧单位存，存进去就是错的，而且不报错。
所以规矩是这么来的
$0.60/小时 = 1 分/分钟。所有 $0.60 的整数倍，都能被这个字段精确表示。
于是规矩变成一句话：提案前先除一下 0.6。
除得尽，随便定；除不尽，那不是「稍微麻烦一点」，是一次带数据迁移的上线。
这条规矩救了什么
它把一个隐形的约束变成了显性的。
在此之前，「能不能定这个价」这件事没有人知道答案——它藏在一个字段的类型声明里，而讨论定价的时候没有人会去看那行代码。
于是最坏的情况是这样的：大家开会定了一个价，宣布了，改文案，然后有人在实现的时候发现存不进去。这时候要么改价（刚宣布过），要么临时做数据迁移（最不该赶的活）。
写下这条规矩之后，这个问题在讨论定价的第一分钟就被回答了。
一般化的那一条
你的数据字段，就是你的产品能表达什么的边界。
这句话听起来像技术问题，其实是产品问题。类似的例子到处都是：
- 日期字段只存到「天」，那就做不了按小时计费
- 状态字段只有三个值，那就设计不出第四种状态
- 一个字段只能存一个人，那就永远做不了「共同负责」
这些边界都不会主动告诉你。 它们表现为「这个需求做起来怎么这么麻烦」，而真正的原因在很早以前的一个字段类型上。
怎么用
不用去读代码。只要在提任何一个涉及数字的想法之前，多问一句：
这个数，现在的系统存得下、算得对吗？
大部分时候答案是「能」，问一句只花十秒。而那少数几次答案是「不能」的时候，你省下的是一次已经宣布出去、又得往回收的改动。