在之前的一次“需求分析”分享中，我曾经说到过
“当客户描述问题和需求时，你的脑袋里不应该想到字段、布局甚至系统架构。”
有人有疑惑，为什么不应该？这样不是会更加容易和客户交流，评判工作量吗？这不是代表我反应灵敏，经验丰富吗？
今天想具体聊一下，我为什么这样说，或者说我这个建议的理由和原因是什么。
我面试过不少BA，不管他上一份工作是需求分析、运维还是互联网公司的产品经理，基本上在我这边都会问一个问题“有个需求，客户说要做一张报表，你怎么分析这个需求呢？”
基本上从这个问题的答案，我就能知道他的思维方式大概等同于我几年工作经验的状态。
这个报表有哪些字段，这些字段是从哪些表中得到的。
嗯，这个差不多1～3年。
这个报表长什么样子的，里面的字段是否是我们系统中有的，如果没有那么在别的系统中或者来源可以获取到，怎么接口，怎么协调。
这个差不多是5年以下的。
我会问用户为什么要这张报表，这个报表是做什么用的。
这个应该是5年以上的。
一般如果是第三种答案，但是实际工作经验却才有3年左右的，那我会非常满意。对，就这一个问题，我就会觉得你非常有潜力了。
BA也好，产品也罢，重要的是思维方式和思维习惯。你不会UML，不会画原型，不会写SRS，没见过PRD……这些都没有问题，可以学习。但是如果你的思维方式就不对路子，那会是件很灾难的事情，尤其是对做导师和战友的我来说。
言归正传，说了这么多，我其实想说，你如果在客户给你提问题和需求时，脑子里直接绘制出解决方案，那么也就表示你的思维方式，在BA这部分来说，属于小婧的5年以下的评判标准。
这样做到底有什么不好呢？
你的解决方案一定能解决问题吗？
我之前一直在强调，和用户讨论时，应该聚焦在业务问题。
如果你连问题都没弄清楚的情况下，就给出一个解决方案，合适吗？
就有点类似于，你经常抱怨领导安排计划是拍脑袋，搞得你经常加班。
这个是一样的道理。
会有更好的解决方案吗？
你听到需求和问题的时候，绘制出的解决方案其实完全是基于你的经验。
也许你面对和处理过类似的问题，并且相同的解决方案都解决了用户的问题，于是你提出了个一样的或者类似的解决方案，期待也同样奏效。
但是，问题与问题之间其实会有些细节上的不同，用户和用户的喜好也会有轻微的偏差，你能说你第一感觉的解决方案就是最好的吗？
会不会有更好的解决方案呢？
也许你对自己足够自信，觉得不会有比这更好的解决方案了，那请综合考虑下面的几个问题。
是否有什么影响性的分析？
如果是一个增强的功能，特别是要基于一个比较复杂的系统做增强，那么按照你绘制出的解决方案是否会对其他现有功能有影响？
是否会与系统其他对象的业务逻辑有矛盾？
我觉得这个问题可能你一时半会儿是解答不了的。
是否会有什么非功能的需求要注意？
如果是报表或者牵扯到大数据量的问题，那肯定要有性能方面的考量。
如果方案需要随业务的场景不断转变，需要适应，则需要考虑扩展性的问题。
我觉得这个问题可能你一时半会儿也是解答不了的。
是否解决了真正的问题？
这个是最让人担心的事情。
之前我写过一篇文《业务分析第一步：定义真正的问题》里面详细描述过，真正问题的重要性。
所以，如果你了解到的信息只是表象，没有弄清楚用户为什么要这个功能，用这个来做什么。
就草草的给出解决方案是无法解决真正的问题，反而可能让问题被隐藏起来，不知道什么时候就爆发出来。
以上的问题都无法确认的话，你就更不能评估工作量之类的了。
综上，我给出的建议是：
收集充足的信息，弄清楚用户的问题和需求，这个是第一要务。当然这个时候或者下个确认的阶段你可以使用UML的用例图、状态图、活动图进行一些问题的确认。但是不要给出解决方案，尤其是开始把自己脑海里的界面画成草图和用户讨论。这个阶段不要。
如果用户问你何时可以完成，你除了要问清楚这个功能对用户的影响（是否会影响到用户考核绩效等），还要和用户说明需要回团队评估后，12个小时内给出答复。
与团队成员进行评估，对影响性、非功能性以及风险等进行分析，评估和分析过后再和用户进行更深入的讨论或者解决方案讨论时，可以用草图等方式进行。
有想法欢迎和小婧沟通。
