做一个设备管理工具，先记录设备，再加库存，再加维修。既然要维修，似乎还需要人员排班；有了不同人员，权限管理也不能少。
每一项都说得通，合在一起却越来越难结束。
这就是产品范围容易膨胀的地方。新需求不必荒唐，只要它与现有需求挨得足够近，就很容易被认作“顺手一起做”。
Basecamp的《Shape Up》提出先确定愿意投入的时间，再收窄问题，用固定时间、可变范围寻找可完成的方案。资料来源 对个人做产品，这个思路有助于解释一件事：范围本身就是一个决定，不能全部交给开发速度。
把上面的场景具体化。假设一个仓库负责人眼下最需要的是知道本月哪些设备待检。他已经有台账，缺的是按既有日期整理出一份可以确认的清单。
这一项工作，与建设完整设备管理平台，规模很不一样。
它可能只需要识别一类表格、读取设备编号和检查日期，再列出结果。跨仓库协作、读取纸质资料、预测故障，都有各自的价值，但未必属于眼前这次交付。名字叫“设备管理”，不等于所有相关事情都必须同时进入第一版。
这里又有一个容易走偏的地方：收窄范围，也可能把价值一起切掉。
如果为了省事不保留设备编号，负责人拿到清单却不知道对应哪台机器，那么功能虽然完成了，事情还是没法往下走。有些步骤实现起来麻烦，却决定结果能不能使用，不能只因难做就拿掉。
我觉得好的范围很像一句讲清楚的话：谁遇到了什么事，这次负责到哪里。说得越明确，哪些需求属于现在，哪些应该另外讨论，就越容易判断。
这也关系到客户的理解。开始时说明不支持某种输入，与交付失败以后临时解释“这种情况不算”，是两种完全不同的做法。边界需要提前存在，才能帮助双方理解承诺。
软件以后当然可以继续长大。但第一版是否完整，可以先看一个更小的终点：那位仓库负责人，能不能拿着清单找到本月该检查的设备。这个终点保住了，少做一些相邻功能，产品仍然有自己的用途。