从4个角度谈谈：B端需求的演变路线.pdfVIP

从4 个角度谈谈：B 端需求的演变路线 要想做出好的产品，前提就是要深刻的理解需求，需求不止是个问题，它贯穿了产品的全生 命周期，它的形态不断发生变化。 需求是什么？需求本质上就是问题，问题是什么？问题本质就是现状和预期的差距，产品经 理终其一生要做的事就是发现问题并提出问题的解决方案，同时让这个解决方案在商业上获 得成功，这个解决方案就是我们所说的产品。 要想做出好的产品，前提就是要深刻的理解需求，需求不止是个问题，它贯穿了产品的全生 命周期，它的形态不断发生变化，需求的变化过程也是从产品从一个初步构想的点子、到形 成解决方案、完成功能设计到最后形成产品的过程。 1. 用户需求 随着产品的推进，需求形态也会发生变化，最开始的时候，当这个需求被发现时，我们管它 叫用户需求，也许这个需求是运维或者市场人员传达过来的二手需求，也许是产品经理和用 户调研后获取的一手需求，也可能是通过系统的数据分析得到的优化需求，本质上都是用户 需求。 用户需求是最原始的需求，有以下4 个特点： （1）烟囱需求 这是一个特立独行的需求，类似的用户都没有这个诉求，完全是一个个性化的需求，用户的 意图是追求满足个人的需求，而非满足带有集体人格的角色需求，这类需求被称为烟囱需求， 在需求采集阶段发现了这类需求要果断抛弃掉 。 曾经我们做PMS 系统，需要管项目的流程，一个项目可能涉及很多个流程环节，这些环节 有严格的前后关系，有个别的项目经理提需求，希望能有项目信息补录功能，可以在项目执 行完毕后统一补录，或者可以跳过某些环节。 显然这个需求不符合企业管理上对项目经理这个角色要求的定义，管理就是要固流程，规范 项目经理的操作，领导可以实时看到项目的进展，如果按照某个项目经理要求开个后门，管 理目标就达不到了，这个需求就是烟囱需求。 （2）重复需求 在需求调研时，从不同渠道、不同用户收集来的需求，可能存在很多相似或者重复的需求， 这类需求在下一阶段需要进行合并处理，有时这些重复的需求带有一定的隐蔽性，只从用户 的需求描述上感觉完全是两个不同的用户需求，但实际上是相同的需求。 这个时候就需要了解需求的层次，不能只看表面的需求，需要理解用户更深层次的需求，比 如：一个用户说希望把某个功能菜单改为一级，另一个用户希望把这个功的菜单改为特殊颜 色标志，只看表面确实是两个不同的需求，我们的解决方案可能最终按照用户的想法把菜单 提升到一级并且修改了颜色，这么做是典型用户说什么，我们就做什么，最后的结果就是把 系统做烂掉。 往深层次分析一下用户的动机，这两个用户的动机其实是一致的，都是为了快速找到自己常 用的功能，只是分别提出了不同的解决方案。 分析到这个层次机会发现，要解决用户的这个问题，比较好的解决方案，不是改变现有的菜 单体系，而是在个人首页单独增加一个快速菜单的入口，这是个通用的功能，用户可以定制 自己经常访问的功能。 （3）矛盾需求 用户需求很多都是矛盾的，不同人提的需求有矛盾，比如：一个功能按钮的颜色，有的用户 希望是灰色的，这样整体色调显得更协调，有的用户希望按钮颜色更深一些，可以更显眼。 还有就是一个人提的需求，前后存在矛盾的地方，针对这类问题一定要及时和用户沟通，有 时候可能是表述上的失误，也有可能是我们理解上问题，一定和用户确认清楚。 （4）不可实现需求 用户一般不会考虑技术的可行性或者开发的成本，大部分用户都是不懂技术的，他们提出这 些需求很多时候是被互联网产品教化的结果，用户接触太多互联网产品，总觉得实现起来都 很简单，人家能做你们也应该能做。 比如：原来我们做订单管理模块，用户就说你们按照淘宝做就行了，有现成的可以借鉴，不 用你们单独造轮子，这就是典型的不计成本，大公司互联网产品背后的研发团队岂能和一个 项目组同日而语，遇到这这种情况也就只能呵呵了。 2. 业务需求 业务需求是对用户需求第一次过滤、分析后形成的需求， 业务需求本身并没有很抽象的功 能设计，用户很容易看得懂，研发也能清晰的知道要做什么，所以业务需求更像一个用户思 维和系统思维的转换器。 用户需求和业务需求之间的关系是多对多，也就是说不同的用户需求可以合并为一个业务需 求，一个用户需求也可能拆分成多个业务需求，最终产出业务需求需要经过需求识别、场景 分析、流程分析、数据分析4 个步骤. （1）需求识别 这个步骤就是对用户需求的重新筛选、整合的过程，去除技术上无法实现和烟囱需求、整合 重复需求，明确矛盾需求，初步产出一个需求列表，这个需求列表还不是最终的业务需求， 而是明确要做、能做、无歧义的用户需求。 （2）场景分析 对这些明确