个人站点地址：nowherewoman.com
最近项目组接到一个需求，需要在销售订单上添加折扣信息，并且可以添加多条折扣信息（比如生日折扣，圣诞节折扣等等）。这个很好理解，因为我们处在什么都需要打折来安慰消费者心理的时代，当然打折信息的记录也很重要，方便以后进行数据分析。
然后开发人员做出来的成品是这样的。
1. 用dropdown列出所有的可选择的打折类型
2. 当用户通过这个dropdown选出打折类型后，啪，显示出一个添加按钮把选择的类型添加（这个添加按钮一开始是隐藏的）。同时这一种打折类型不再出现在dropdown列表下
3. 当添加完一种打折类型后，啪，神一般的出现一个table，table中的信息就是刚刚添加的那一条
4. 当dropdown下所有的类型都添加尽了的时候，dropdown 和添加按钮无声无息的消失。
看似小小的一块界面，其实包含了很多的联动操作，每一个操作都有可能引起界面是一部分的出现和消失。且不从用户体验角度来评价这样的设计。这么多的联动操作，无非想实现一个功能 --用户选择的打折类型的唯一性。而这个功能花费了开发人员一周的时间。
这个事情让我很头痛，我无法说服开发人员把这样的花了一周时间按做出来的东西重新做，并且PO认为目前这样的实现可以接受（其实PO不在意这个功能，所以做不做这个功能都可以接受）。因为木已成舟，再做只是增加更多的成本。我想问的问题是
- 用户是否需要这个唯一性的功能，是否是开发自己人员在YY？
- 当用户不知道自己需不需要这个功能，或者用户说不出来加这个唯一性的限制有什么价值的时候，我们是不是要做？
- 当着手开始编码时，是否应该跟PO确认下？
- 这样的投入和产出比是否值得？
- 如果用户真有这样的需求，这样的唯一性的功能设计，是否有好的用户体验？
这让我想到了“可行走的骨骼”，
我们在做产品的时候总是喜欢去死抠每一个细节，把每一种if else 都加上内容。希望需求分析人员把每一个需求都弄的巴巴适适的，而且最好需求永远不要变。这种理想是丰满的正确的，但是现实很骨感。如果你没有同感证明你还没有进入软件开发圈。
在这种情况下，我们为什么不先做出一个“骨骼”，满足用户的最主要需求，不要有过多的假象，不要自己YY。等用户需要加肉的时候就加，用户需要穿衣服的时候再穿。
有的开发人员说，我不想用户在做这些操作的时候犯错误，所以我想多加些限制。但是你能预知用户会一定犯错吗？你能预测用户会犯什么仰的错误吗？您不试一下怎们知道呢？不要怕用户会因为软件没有加限制而犯错误，因为你永远无法预知用户是否会犯错，会犯什么样的错误。把你的每一个假象先通过用户的实际操作得到验证后再去实现。请做好你的“骨骼”，并且这个“骨骼”是“可行走的”，要把地基打好，保证现有的可以交付的东西是经得住考验的。用户可以尽早用功能，团队可以尽快的交付，而且让用户在验证我们的假象，我们这样做怎么样！