一个业务顾问，跟用户谈需求，聊销售订单的后续操作。

问题：订单创建保存后要不要审核？

回答：可能要，不确定。

问题：如果要审核，要几级审核？是否上一级管理人员是必须的层级。

回答：可能多级，现在想不清楚。是不是直接上级审的事情，有很多情况，不同单子，可能管理归属不一样，现在这方面也不明确，可以到时候我自己选么？

问题：订单创建后要不要自动触发生成交货单？还是全部手工创建？

回答：可以吧，都行，可不可以都可以？

好，如果你是业务顾问，你会怎么办？

某个业务顾问是这么做的：好的，既然你们很多功能需求不确定，那么这样，我给你设计成可配置化，给你们设置界面，到时候你们自己设置一下，后面要改的话，就自己简单调一下就好了。

用户说：好极了，太棒了。

。。。。

然后业务顾问就设计了：

订单，可以设置成需要审批，也可以不审批。

审批的话，可以随便选审批人，一层也行，多层也行。

订单后可以自动创建交货单，也可以选择不自动，全部手工。

你觉得如何？会不会赞扬这个顾问，水平真高！

我只能说：呵呵了。

作为一个数据顾问，跟业务顾问一起进场，同步过来跟用户谈数据分析需求，注意，是业务设计的同时，不是业务系统跑了一段时间以后。当你想跟用户聊聊订单处理时效性，有没有延迟审核分析，有没有延迟交货分析时，当你了解到业务设计是上述时，你会怎么想？直接崩溃。没有既定的业务分类，没有既定的业务规则，怎么做分析？怎么设计分析路径？

我们常说，看一个顾问好不好，负不负责，是初级的还是高级的，一个点就是看他有没有设计了一堆hard code的功能，还是在必要的地方设计做成配置项，具备灵活性。

我们也常常说，做项目和做产品不同，把项目交付物产品化还需要好长路要走，更复杂，对需求分析人员的要求更高，因为产品需要更多完整性和灵活性。

所以，好像上述那个业务顾问很厉害啊。

大错特错了。这是个灵活性陷阱。

做项目不是做产品，或者说，如果你愿意，你有能力，做项目也可以做成产品，但关键是不能只做到产品级别。

把一个产品抛给用户，然后结束，那不是高级，不是负责任，而是不负责任，用灵活性的谎言去掩盖不负责任的态度和管理想法的缺乏。

讨论需求是讨论什么？讨论业务该怎么做，不该怎么做，怎样的业务流程是正确的，怎样的业务管理模式是正确的，是有所谓标准和规则的。这样也可以，那样也可以，代表了用户没有想法，顾问也没有带给他想法，这不是个合格的顾问，这不是应有的业务流程再造咨询过程。

功能可以设计灵活，可以把项目做成产品，可以都做成配置项，但得进一步，把配置方案都做出来。要不然，不就等于扔了一个空的sap系统给用户让用户自己实施么？

所以，当面对用户需求的不确定时，提供灵活性确实是个方向，但千万不能滥用，更好的、更负责任的办法是，和用户继续深入讨论，得出结论，那才是真正的业务蓝图。