今天旁听了开发上和客户的一个方案讨论会，会上提到了一个名词“暂存”功能。当时没有仔细听，只隐约听到技术上给客户说，我们做过“暂存”功能，能解决这个问题，用户表示接受。
回来后，和开发聊得时候，我问到这个暂存的功能是做什么的？因为第一次听说这个功能，所以比较奇怪。
我：这个暂存功能是做什么？
技术：临时保存下录入的工单。
我听到这里，差不多明白什么意思了
我：为何要提供这个功能？
技术：正常的保存功能，会校验输入的数据，如果检查通不过，会拒绝保存。所以客户要求加暂存功能。
我：是客户提出的“暂存”按钮功能吗？
技术（犹豫了1下）：这个，，，，用户只是说要暂存下单值，比如输了一半临时出去有事，需要保存下。我们另外一个项目做了这个功能。
我：能否保存时保存时不校验数据，提交时再检查？
技术：那不行，怎么能保存错误的数据呢？再说了，我在提交时要再写一遍校验逻辑，还要写提交的校验逻辑，太麻烦了
我：为啥，我不提交不就可以了，只是保存，不提交，草稿状态，为什么不能保存？
技术想了一下，显然之前没有考虑过数据不提交不会生效的问题。
技术：那保存时最好还是要检查，用户好及时修改
我：嗯，有道理。可以检查。只是提示，不影响保存
技术：这样做可能会有问题。比如有的业务部允许做两个？（说了个例子，我没理解）
我：提交时检查不就可以了？
技术：那要是查询的时候，如果用户想查制单状态的，岂不重复了?
我：重复了怕什么，反正没生效。如果增加暂存功能，你是不是要给单子增加个“暂存“状态。如果用户选择查询暂存的单子，不一个道理吗？
最后。。。
技术：加暂存，我把另外项目的代码靠过来就好了，几分钟就搞定，如果按照你的方案，那得折腾一阵子，没必要................
总结一下：
1、技术上错误理解了用户的需求，而且误导了客户
客户的本质需求是，现在的系统在录完单据后，如果单据的数据项校验不通过，系统拒绝保存。这就导致，我辛辛苦苦录了很多数据进去，就因为一项数据搞不定（可能需要找别人确认，但是别人又不再），导致前功尽弃。再一个我临时出去下，单子录了大半，却保存不了。所以希望系统能给我先存上，先别校验数据。
技术上随即抛出了一个现有的“暂存”方案，客户感觉解决了问题，接收了这个方案。
2、这个方案是多余的。
（1）增加了个新的概念“暂存”，单据增加了一个状态‘’暂存“，单据的状态复杂了，并且增加了额外的控制代码。（果然，后来我注意到单据被退回至制单人，暂存按钮消失了，不允许暂存了，肯定开发上嫌处理状态麻烦了）
（2）优化保存功能即可实现客户的需求，简单而且更直接。
（3）上面我提到方案，是标准的模式，是大多数软件的做法，也是非常合理的做法。
输入-保存-提交 三部曲。无论是否有流程，都是这三部。如果没有工作流，数据不需要其他人审核，保存和技术上说的"暂存"一个意思。提交就是是数据生效的操作。
3、至于技术最后说的查询制单状态的数据会重复是个假命题。
（1）制单状态的数据是未生效的，重复了不影响业务数据
（2）用户已经明确要查询未生效的（制单）的数据了，数据重复了，他不会认为是问题。这个问题是技术上臆想出来的。
