需求挖掘

需求分析阶段，往往有两方面的难点。一是如何准确理解用户的需求，二是如何帮助用户挖掘需求。

---

2B，面向业务用户时，往往第二点，更是困难。第一点，如何准确捕获用户的需求，可采用技巧，弥补能力、经验上的欠缺。2C，通过用户反馈、调研收集得到的需求，对于提出方是没有代价的。也就是说用户仅代表自己，基于自身判断提出了需求。这就需要PM额外的甄别工作，是否为伪需求？区分needs and wants。用户提的是requirements，还是基于自己给出的solution？我们是否理解到了用户需要的？而对于2B，当然也面临与2C类似的问题。可是需求提供者，往往是用户代表，代表着某一业务领域。最简单的一个方法，需求文档需要业务领导签字，否则不受理。领导要签字，自然是要背责的，保证了对需求的把关。此外，需求评审会议，确保需求干系部门拉进来，即使是基础业务人员也行。因为业务需求，基于特定立场提出的局部优化，会对其他业务产生影响。借助评审会，其他业务部门挑战需求。再者，要以适当"找茬"的态度来分析需求，2C当然是没法这么弄的。提供的需求文档争取返工两三次要求业务修改，并同时要求用户输出业务架构。这个需求是对应规划中的哪一环节？在整个业务流程中处在哪一节点？当然“找茬”的度要衡量好，毕竟我们是在服务用户。在这默认大家都是职场resonable man，提前讲清楚，之所以分析需求阶段这么严苛，不是我为了获得权利租，故意卡你一下，而是为了把事情做好，多花功夫在前期打磨，才不会后期再变更，代价极大， 对双方都带来不利影响。

---

所以回到主题，需求挖掘，往往更加困难。但同时，又是更有价值的工作。因为需求挖掘，专注在痛点上，若能挖到root cause并解决了，价值将成倍的做提升。但root cause可不是那么好挖出来的，首要问题是，哪个业务用户会陪你挖？这属于组织的重要但不紧急事项，若是个人维度的重要不紧急，那是需首要投资的。但群体的重要不紧急，等于没有这事。大家都知道找到root cause很重要，但一是具体到个人、到本部门，能有多少改善？二是没信心，根因若那么好找、那么好解决，还会留到现在等你来挖？此外，挖掘的过程，犹如顺藤摸瓜，一开始问题在A，聊着聊着发现在B，最后定位到C上，ABC可能分属不同部门、系统，有多大权力能在过程中把相关方叫来一起讨论？权利不够全靠个人魅力，因此一般得到达行业专家level才能胜任。一是凭借知识、经验知道大概往哪个方向挖掘，二是业务信任、愿意配合。短期技巧是白板作图能力，画格子结构化分析问题，让所有人的焦点都在白板的流程、方案上。先在左上角写明目的、思路，来一个业务用户先给讲一通。作为整合者，即是不是业务专家，也要作为绝对的主导者