传统企业，太缺会写需求的人才了！

厚厚 2023-08-03 01:30:03

写需求、画原型，是互联网产品经理的基本功，却不是核心竞争力，产品经理的核心竞争力是创意与想法。而产品经理的基本功对于传统企业来讲，却可以成为实实在在的核心竞争力，因为传统企业太缺会写需求的人才了！

传统企业的需求质量非常糟糕，亟待提高。这里说的需求的质量，不是指与决策有关的需求的价值，而是指需求的方向明确以后需求的梳理与表达。

在互联网公司，提出高价值的创意与想法不容易，想要把需求梳理合理、并且清晰地表达出来实际上没有那么难，属于工作量的问题。而相对于互联网公司，其实传统企业的需求往往更为明确、需求变更少，但想要把需求合理清楚地表达出来却不是一件容易的事，主要在于传统企业中并不具备需求方面的专业人才和队伍。

或许你听说过，有些传统行业内本身也有产品经理的岗位，但这个岗位属于业务领域，比如保险公司的产品经理是指保险产品经理，即保险产品的设计者，此产品经理非彼产品经理，与IT不相关。

或许你也打探到，随着互联网对传统企业的渗透，有些传统企业内设置了产品经理岗位，但实际上这只是表象，绝大多数传统企业的产品经理队伍并不是真正意义上的与互联网公司相对应的产品团队。这些传统企业的产品团队，来自于原有业务部门内负责系统的业务经理直接进行原地划转，成为了产品经理队伍。但实际上，这仅仅属于换了个名字，人员还是原班人马，能力也不可能因为改个Title就能瞬间提升一大截。

常见的情况是，传统企业根本就没有产品需求人员，只有业务人员和技术人员，由对IT行业与互联网产品只有浅层认识、完全非软件行业的业务人员直接将想法表达给技术人员，技术人员根据自己的理解去完成需求、设计、开发甚至测试一条龙工作。

通过以上可见，在传统企业，业务人员是真正需求的输出方，但业务人员是业务领域的专业人才，并不具备产品需求方面的专业知识与技能。由业务人员来输出需求，会出现各种在互联网产品经理看来无法想象的问题。

一、传统企业需求质量问题的表现

也许有不少人会说，互联网公司产品经理提的需求也非常乱啊，有的简陋的不行，有的根本都没有文档都靠口头传达，有的刚提完需求就要变……

是的，这样的现象的确存在，但我们要认识到的是，这属于少数情形，大部分互联网公司的需求质量是过关的。而我们下面要谈的传统企业需求质量的问题，却是一个普遍性的问题，这值得我们好好来看一看。

传统企业各类流程的完备性并不比互联网公司差，实际上很多都优于互联网公司，特别是中大型企业。相较于传统行业，互联网公司虽然也有各种流程，但却没有那么严格。传统企业对于需求相关的流程要严格和完备的多，有完善的需求研制流程、需求评审流程、需求提交与下达流程、需求变更流程、需求模板等等。

但所有的这些流程与模板，所有的需求管理手段，起到的都只是规范、保障和助力作用，不解决需求质量的核心问题。

实际上，互联网公司恰恰是摒弃了部分流程性的控制与管理，交给了团队自己进行选择。可以没有模板，可以没有流程，一些紧急情况下甚至也可以没有文档只有一句话。需求的形式也不限，可以是Word文档，也可以是产品原型，甚至可以是别的任何形式。所有工作的目的只有一个：只要你能把需求合理清晰地说明白就好。在这一体现需求质量的核心点上，互联网公司无疑是出色的。

那么在这一个核心点上，传统企业需求质量方面的问题主要表现在哪些方面呢？

1. 传统企业的需求中常常会提出新建产品线或产品功能，缺乏关联性思考

传统企业在提出一项需求时，常常更喜欢新建，新建功能或产品，而通常与现有产品线的关联性考虑不足。

信息不通是其中的一个最重要的原因，每个业务人员都只关注自己业务相关的产品系统支持，对全局的产品系统没有概念。有时即使考虑到了，也不愿意与其他部门共享使用现有的产品线或产品功能。相对于互联网公司，传统企业的领地意识更强，自然，在产品上他们也更希望拥有自己的专属领地，而不是与别人共用。所以，很容易出现类似的功能只因在不同的业务场景下也需要再重新做一遍。

不合理地新建产品线或者新功能，其维护成本其实非常高。大部分业务人员都只关注建设成本而对后期维护成本不重视。除此以外，还有一点也基本会被传统企业相关人员所忽略：一旦一个功能或者产品上线以后，很难再下线，即使有比较少的用户。一旦下线，就会影响他们的使用，用户会叫，所以会存在很多使用人数不多的老功能或产品线迟迟不能下线。

2. 传统企业的需求常常是就问题解决问题，缺乏体系性思考

传统企业的需求常常是针对单点，缺乏发散性、延伸性、通用性、扩展性等方面的体系化思考。就当前问题提出当前需求，就当前业务点提出当前功能点。常常会因为限制太多、只解决某个特定的具体问题、只适用于某个特定的场景而导致适用性非常差，最终导致开发的功能或产品用不了多长时间就被废弃掉了，然后每次有需求时再重新建，导致存在一大堆零散的、适用范围非常窄的功能体系，这些功能或产品系统一直并行运行着，凌乱不堪。

当然以上问题，技术人员也会提出一些建议、反馈、拒绝等，但这些内容业务人员的接受程度不一，有些可能被业务人员接受规避掉了或者修改为更好的方案，有些则被打回。另外一方面，技术人员提出这些优化措施时，是从技术和系统角度出发，对于业务场景，他们也拿捏不准，与业务场景相关的一些问题或者优化建议就无人能给出建设性意见了。

3. 逻辑不通，是传统企业需求中最常见的问题

传统企业的需求中常常会出现产品逻辑不通的问题，在互联网产品经理看来，这是基本功，这种问题是不可接受的。

逻辑不通，意味着产品功能在逻辑上不能形成一个闭环，产品链路是断的。对于用户来说，意味着其在使用产品时，用着用着就走不下去了、被卡住了，前面费了半天劲，到这里不能再继续，无法完成自己的目标了。

这时，用户只能在尝试无果后骂上一两句扭头走掉。这导致的用户流失率，几乎是百分之百。每当发现需求中存在这样的问题时，作为需求输出方的业务人员常常是临时现场思考然后回答你，这个没有经过深思熟虑的回答并不总是靠谱，不少时候会带来新的问题。

需求撰写人员需要有非常强的逻辑性，而逻辑性常常是业务人员所非常欠缺的，很多业务人员可能对此非常不服气，至少经过了大学本科教育，怎么可能会逻辑不过关呢？

的确，大学本科毕业代表了逻辑方面的基本能力，这当然不可否认，但其实很多人不知道的是（包括很多产品经理都没有意识到）：不同于大学时期功课题目或者开发岗位上代码的逻辑性，产品需求上的逻辑性往往隐含在一些事物的背后，表现的不会那么集中，所以看起来不会那么明显，以至于一些部分会被忽略掉。

与之相比，写代码虽然也要求很高的逻辑性，但它的逻辑性常常比较集中，自然而然放在一起考虑，而不容易被忽略。

4. 传统企业的需求表达效率低、内容混乱

传统企业业务人员输出的需求，对于业务背景和业务目标的描述是清晰而准确的，但对于产品功能的描述常常是内容冗长而重点不清晰的。

一份小需求还好，能基本描述明白，虽然流畅性差些，但对于理解需求不会造成严重影响。遇到业务场景复杂、涉及模块和功能点比较多、产品逻辑结构层次多的大需求，需求的表达常常就会存在章节分隔不合理、内容结构层次不清晰、功能点描述混乱、功能设计不合理、前后内容不一致、内容冗长重点不突出等众多问题，这些问题都十分常见。

有时，甚至还会出现需求中一部分功能模块缺失的情况。这时，需求就变得非常难以理解和把握了，光需求分析可能就需要花上很长时间，还不能保证全部理解到位了。

撰写软件产品需求也是有要点和技巧的，这些要点和技巧也需要在工作中不断地训练才能运用自如。撰写软件需求，也需要对产品与系统、基础IT知识、行业内相关术语、代码编写及运行原理有基础的认识和了解。而传统企业的业务人员并非IT相关专业毕业，对这些知识了解有限。这些现状意味着业务人员对于需求的表达并不擅长。

5. 传统企业的需求细化程度不够，研发过程中容易反复

传统企业业务人员输出的需求，其细化程度远远不够。在需求细化程度这一点上，业务人员输出的需求是不过关的。常见的情况是只关注了主路径以及正常情况的处理，对于分支路径以及各类异常的处理缺少描述。

如果技术人员在评审需求时能把这些问题一一都指出来，业务人员进行补充完善，那就还好，否则就会把所有这些问题遗留到开发阶段，造成研发过程中因为这些细节问题来回反复确认和现场需要再进行思考及决定，甚至会因为细节问题导致产品功能的重新梳理与思考，造成研发周期延长与失控。而且在时间的紧迫感和压力之下，考虑问题常常不够深入和全面，导致决策错误或者被迫采用临时方案、折中方案。

实际上，我们仔细思考分析后就会发现一个事实：开发过程中的每一个代码分支逻辑都会在需求中有所体现，一一对应，即需求中需要一一反映出所有的分支逻辑，否则一定会存在某些细节丢失的问题。

优秀的产品经理输出的需求文档，不仅层次清晰、表达效率高，其细化程度甚至可以与开发编码相媲美，也就是说，其输出的需求覆盖了所有应该考虑到的情况，在研发过程中基本不会或者很少会因为漏掉什么内容而被开发人员找上门要求进行补充。这样不仅可以让开发更省心，产品经理也可以安心地投入到下一个需求中，而不会在这个需求的开发阶段还需要投入很多精力来跟进。

6. 传统企业的需求产品设计内容缺失或缺乏专业性

传统企业业务人员对于产品设计没有经过专业的训练，没有标准，几乎全凭自己的理解与想象。

在这个大背景之下，需求中关于产品设计相关的内容，或者缺少描述，或者描述中存在很多不合理之处，造成用户体验很差。如功能划分不合理、页面层级过多或过少、页面内容层次结构不清晰、页面设计重点不突出、页面内容过多过长主题不明确、页面元素不直观不贴切、用户路径混乱、交互方式不合理、文案表达不清晰不准确、缺少合理必要的提示等等。

有时一个页面少则几个问题，多则十几个、几十个问题，甚至有时一个页面基本框架存在严重问题或者满眼看上去哪哪都是问题。

产品设计不合理，会让本身非常好的创意与想法大打折扣，会让产品变得非常难用。

而这样的产品，除非用户别无选择，否则用户会扭头就走。

互联网行业在产品设计方面有着成熟的设计原则、行业规范和设计案例。中大型互联网公司还设置了专门的交互设计师岗位，即便没有专门设置这样的岗位，一般也会由产品经理来覆盖这块内容，这也在产品经理这个岗位的能力要求范围之内。而传统企业基本上不会设置专门的交互设计师岗位，也没有可以覆盖这块内容的专业人员，这部分内容属于传统企业的真空地带。

以上提及的需求中的种种问题，当然不是说应该由业务人员来背锅。业务人员是业务领域的专家，我们应该敬畏，但目前传统企业中主要是由他们来完成需求输出的，人岗不匹配是需求中存在各类问题的根源。

二、业务人员输出需求的局限性

业务人员是业务领域的专家，他们更了解业务规则、业务场景、市场、客户、行业动态等，是传统企业中对于需求敏感度和方向把控最好的一群人。由他们结合业务目标、业务场景来提出需求的方向、创意、想法无疑是最佳选择，但由他们来负责需求的落地、撰写与输出却不是一个好的策略，原因在于由业务人员来输出需求具有局限性。

1. 业务人员绝大多数是业务相关专业毕业，非IT出身

保险的业务人员出身金融学、保险学，教育的业务人员出身教育学及各类教育专业。参加工作后，也一直是在自己的专业领域内深耕细作。对于他们来说，负责软件需求方面的工作是一种跨界，并非他们所擅长，如同刚进入传统企业的产品经理不懂业务一样。

非IT出身，对于理解软件相关的事物具有一定的难度，难度还不小。关于这一点，别说传统企业的业务人员了，就连天天处于产品、研发、代码氛围中的非IT出身的产品经理来说，也是一道不小的难题。不然，也不会有那么的产品经理探讨关于“产品经理应该懂点儿技术”一类的话题了。

通过产品经理对于技术话题的关注和探讨也可以看出，负责需求方面的工作是非常需要了解一些技术相关的基础知识的，特别是在需求落地与撰写过程中会有很大的好处，毕竟这个需求是软件产品的需求，是关于系统、技术、代码的需求，而不是市场需求、业务需求。不了解技术，写软件需求，谈何容易。

非IT出身，限制了业务人员输出需求的质量。产品的系统化、一体化、通用性、兼容性、扩展性以及性能，需求表达的效率、需求的细化程度等等，均受限于此。

2. 业务人员拥有业务思维，缺少产品思维

互联网产品经理经过几年的工作以后大多具备了很好的产品思维，如果能够在此基础上继续发展，吸取积累业务知识、向行业及上下游深耕、拥有了业务思维，那么就会在某个行业极具竞争力。而传统企业的业务人员天然拥有业务思维，但却缺少产品思维。

业务思维和产品思维是不同的思维方式，其思考的问题和关注点有非常大的不同。

业务思维讲求的是目标和结果，讲究投入产出和效率，常常涉及计划、KPI、业务方案、执行、分析与评价等。业务思维的出发点是我的目标是什么，要采取什么样的方法来达成这个目标。

产品思维更加讲究系统化，站在未来看现在，面对某个需求，产品思维思考的是这个需求的价值是什么、如何一次性解决未来可能再出现的同质需求、还有没有与之相关联的其他需求或问题等。

产品思维的出发点是通过一个什么的产品或功能，可以解决业务上的哪些需求和问题，既要考虑得周全，还要考虑得透彻。

业务思维是互联网产品经理进入传统企业后所要学习和提升的，如果只有产品思维没有业务思维，那么产品经理无法全面把握产品对业务发展的支撑作用。而只有业务思维没有产品思维的业务人员，提出的需求常常会出现适用性差、使用周期短、复用性低、用户体验差等问题，造成产品系统重复开发、无法快速支撑业务、开发资源浪费等。

3. 业务人员仅关注自己的业务目标，缺少全局性视野和动力

业务人员是被KPI驱动的，他们最关注的就是自己的业务目标，他们需要思考的是KPI的分解，即分别通过什么手段和渠道来完成这些KPI，因此会向技术所在的其他部门提出需求，对于完成他们的KPI起支撑作用。

由于每个业务人员只关心自己的KPI，向技术部门提出的需求常常是局部的，缺少全局性视野和动力。他们常常专注于自己工作范围内的事物，对于其他条线的事物不太了解，这是缺少全局性视野的主要原因。此外，他们也没有全局性意识的动力，即便他们了解到了其他条线的一些情况，也没有为别人做嫁衣的意愿。

这也限制了需求的局部性和不彻底性，对于技术部门来说是一个极大的考验。技术部门对于业务的发展与规划了解有限，当业务人员提出一份需求时，技术部门难以判断是否具有局部性，大一点的公司或集团还会存在部门墙等问题。开发人员只能先按照需求来实施，直到另外的业务人员提出了类似或者相关联的需求，才发现原来的方案需要扩展或者甚至原来的方案需要推翻重新思考，常常为时已晚。