it业务支撑需求管理人员产品力培养
需求认知能力
产品认知能力是指对支撑载体的产品所属的用户需求、业务架构、能力范围等方面都有一个整体性的认知，这种认知表现为对当前产品项目的现状、目标、存在问题等具备一定的判断认知。
- 用户洞察：对产品服务的用户群体、关键的用户场景等方面有认知能力
- 产品现状：对行业市场、同类竞品等清晰认知当前产品处于何种阶段（发展期、成熟期等）
- 关键目标：每个阶段性都有其关键目标，明确这样的目标对后续的产品执行有很大的方向引导
- 规划路径：当认知已经具备一定的沉淀，就需要规划具体的执行路径，并强调各个路径的目标结果（即里程碑）
业务认知能力其实就是指it系统支撑的业务范围、发展趋势、关键价值点等方面都有一个整体性的认知，从而更好的判断需求的影响范围、衡量优先级和方案合理性等，同时可以作为对模块人员分配的判断依据支持。
行业现状认知
很多人都知道，一个项目肯定有对应的行业领域、关联产品以及直接竞品，所以做一个基本的行业现状分析是十分有必要的。1、行业属性：对于产品项目所属的行业需要了解基本情况，熟悉一个项目前，就需要知道细分领域到底是哪些，透过领域可以知道行业的基本生态，处于什么阶段，是否已经成熟，还是只是大家摸索阶段，这些信息都很重要。2、上下游：行业领域那么大，细分业务同样很多，所以一个产品项目不可能覆盖所有，这时候就需要掌握它处于哪个业务环节，以及对应上下游的关联业务有哪些。比如依赖于上游哪些业务，服务的下游对象又是哪些，这样对整个业务生态有基本认知。而很多人对自己项目所身处的位置是比较模糊的，甚至在找准定位上也是飘忽不定。3、直接竞品：通常产品项目都有直接竞品对象的，除了行业top3外，还有一些重合度十分高的产品，对于这类产品需要掌握其对方所身处的阶段，是成熟还是初创，不同阶段他们的产品服务、产品打法都会有所什么不同。而这些重要信息，都是我们有利于加深对自身项目的认知，可以作为对产品项目的定位有比较大的判断依据支持。用户现状认知
有产品自然有用户，但是产品面向那么多用户，你是否对用户群体有足够的了解，譬如某个业务模块下的用户画像是什么？另外，用户在该功能模块下所反应的使用场景是什么，你对整个从进入到离开，及脱离产品后用户还会做什么，这样一系列的信息都是否足够了解？1、用户画像：首先要对自身产品的用户分层，不同角色下的用户特征分布又是怎样的，他们是基于什么动机使用产品，而产品又为他们带来什么价值2、用户地图：了解了用户特征之后，就要去还原用户的使用场景，尤其是核心场景，从他们进入产品那一刻开始，都浏览过哪些模块、使用了哪些关键服务并最终离开的。也就是说，需要关注用户在产品使用过程中的完整生命周期3、用户痛点：用户是带着需求来使用产品的，那么就需要关注这些服务是否对应上核心问题，在使用过程有哪些愉快或仍旧存在的痛点，这些都是需要关注的这里要注意的是用户包括两类一是使用系统的人员；二是所支撑业务的用户产品现状认知
产品的愿景、当前阶段表现、后续规划路径以及存在哪些问题都是需要了解的。1、产品目标：一个产品首先它要有定位，其次是目标是什么（短期、中长期），只有这样才能清楚明白这个产品的价值在哪里、要解决或者服务什么场景。具备这样的认知，才能与项目保持一致的步调。2、产品阶段：这里的阶段是指当前项目处于产品生命周期的哪个阶段，是初创还是上升、成熟等。并且还需要熟悉产品项目的过往历史，尤其是重大事件。另外，也要关注市场同类产品他们当前的情况，是落后还是领先，这些在面对市场策略上也是需要具备这样认知的。3、产品规划：好的规划，能够带来清晰的方向和产品节奏。所以对于产品项目，需要明确了解项目的规划路线，尤其关注每个阶段的重要里程碑，确保能“踩到点”上。同时因为有长远的思考，能够结合当前表现及时调整当前和整体策略。产品认知能力，就好比一个完整产品行为中最基础的认知信息库，有了这样的“底层建筑”，将会是后续任何工作决策的最大判断来源。4、系统数据流：系统支撑时候，经常会涉及交互，这就涉及数据流动，因次掌握系统数据流对需求交互涉及很重要。业务现状认知
it支撑系统作为一个产品是未所承载业务服务的，只有充分理解业务，对业务现状有良好认知，才能更好地支撑业务，业务现状认知主要包括。
1、业务范围：
不同业务首先有自己的业务范围，只要掌握业务范围，才能很好地判断需求的影响范围和程度。
2、业务用户：
不同业务有不同的用户，it支撑的需求很多是为了更好地服务业务存在的，了解业务用户情况有利用优化需求。
3、业务发展趋势：
业务发展趋势影响业务支撑频率和类型，了解发展趋势一是能更好的安排业务支撑人员二是能够做出预判，利于系统后期扩展。
4、业务相关性：
很多业务不是孤立存在的，往往和其他业务存在相关性，只有掌握这些，才能更好地进行系统数据流交互设计。
需求洞察能力
需求分两类，一个是用户需求，一个是产品需求。前者就是大家所认知的“需求池”，任何用户都可以提出需求，但是真正能作为需求去进行迭代的只有是“产品需求”，那么用户需求是基于什么样的理由、依据去判断，并纳入产品需求呢?(对于项目需求管理来说就是需求做不做的判断)
需求洞察能力，主要分两个内容，首先是需求理解，因为先洞察之前就要对需求做理解，这里要求项目需求管理人员要懂得在需求收集过程中，理解用户提出需求的背景、动机、场景及痛点。第二就是需求分析，在对需求有了充分理解之后，就需要判断这些需求的本质、价值等等。用户提的需求也许会顺带解决方案，但到底是不是需求，是否有其他方式可以解决，这些都可以去分析了解的。其次就是这些需求背后的动机、对项目的价值、投入成本等等，都是需要在转化为产品需求前进行初步的评估。
能力价值
我们每天都会收到很多需求反馈，面对这些大量的需求，如何去有效化处理是值得去锻炼提升的。而通常在处理过程中，总会遇到这些情况：
1、用户：在使用过程中反馈了一些需求，按照这些需求做了简单转化就排期上线，上线后发现并不能完全满足，还得持续迭代优化，结果这个功能模块越来越冗余。其他用户也并不是很买账，更坏的是团队因此还质疑这些需求的价值。
2、业务：在B端产品中，往往更多的是服务业务线用户，所以对业务场景的理解能否透彻十分关键。但很多时候，面对业务线同事提出的一些需求，总是片面去了解，或者说对他们的场景无法很好的去理解，并且带着一系列的“未知”就去策划方案，最后结果发现上线后让业务同事使用，发现不能完全满足业务场景的使用，甚至偏离了方向，极大影响产品对外的口碑印象
3、领导：来自于上级的需求是很普遍的，但是由于两者身处的角色不同，日常工作内容不同，导致在认知信息上是有不一致的。那么在收到来自上级的需求的时候，有些人按照这个方向就直接输出“产出物”，结果并不符合上级预期，被打回去返工。这些都是因为没有充分理解上级的意图，并尽可能去获取更多的信息源，来做有效的需求调研。
4、行业&竞品：关注市场的变化，是获取需求来源之一。那么面对行业的一些举措，有些企业往往会选择盲目跟进，抱着“人有我有”的想法去执行。但是每个需求都是有明确的背景和动机的，在面对竞争对手的需求变化，我们需要关注背后的真实动机，每个项目身处的环境不同在决策上都是不同的，所以在这个时候就需要做有效的需求甄别。
......
显然，不同的需求有不同的呈现方式，我们面对这些纷繁复杂的需求，首先需要学会“理解需求”。大家常说的“同理心”，其实更多的是要站在用户的立场去思考这个需求的背景和目的，甚至完全可以化身为用户，“一笔一画”去还原用户的使用场景，来完全领悟其中的意图。其次在充分理解之后，能直击需求的本质，也就是我们常说的“洞察”，用户提的需求到底是不是需求，他们反馈方案是不是就可以解决问题，是否还有其他的实现方式。就好像一个经典故事，用户想出行更快一些，我们就提供“一匹马”，但实际“一辆车”是否才是更理想的方式？
同时在这些需求之上，我们是否还能挖掘出更多潜在价值需求，通过整合实现更大的升级？以上的这些产品实践，都无不体现了产品的这一核心能力：需求洞察能力。而能否充分具备这样的能力，对后续的产品规划和执行都有较大影响，如果一开始需求发起就有问题，那么结果无论如何都是不理想的。在需求这一环，作为项目启动的起点至关重要，所以就需要项目需求管理人员能在这里找到真正的”产品需求“，让项目明明白白去执行，而不是两头不到岸。
培养方式
正如前面提到，对于需求的洞察，主要体验在理解需求，并从中挖掘真实需求。那么就需要在“理解”和“分析”这2方面进行提升，理解的重要性在于能切身处地掌握需求内容，而挖掘分析就是在理解基础，对需求进行转化为有效产品需求的过程行为。
理解需求
学会理解需求，不是简单去听用户反馈的声音，而是需要对他们各自角色背景下，了解其特定行为、动机及场景，并能完整还原他们的需求痛点
1、来源：用户反馈需求的来源，很大程度上反应了他们与产品之间常联系的互动类型。
2、角色：每个用户都代表了各自的角色。如果是C端的产品，例如微信，就有普通社交用户（发发微信、语音聊天等），也有消费型社交用户（公众号内容消费、电商消费等），不同的角色都代表了不同的需求属性。如果是B端的产品，通过是由用户来代表某些业务线，所以B端的用户角色具有较明显的业务特性。譬如微信公众号平台，它更多是服务大批内容创作者的内容生产、运营等这一系列的内容业务链。
3、动机：每个需求都是有明显“利益诉求”的，也都是为了满足用户自身的某个需求。那么我们在收到这样的需求反馈后，就需要去揣摩对方的出发点什么，是什么原因让他们提出这样的需求，这些信息都是需要去获取了解的。
4、场景：用户和动机往往折射出需求的对应场景，而这里的场景是指用户提出需求的在什么“情景”下触发的，了解这方面的信息，有利于更好地帮助我们在需求分析时，能还原用户的真实场景去了解真实需求，加大理解效果
5、痛点：每个需求的背后其实都代表了一个用户痛点，在咨询时可以了解用户对这个需求的正反情绪。很多时候用户提的需求更像是解决方案，想让你去满足，这时候确实看起来是解决了问题，但都是短暂的。实质也只是用户按照自身的想法去考虑，作为产品具备的信息全面性要更多些，这时候其实是可以作出更多有价值的建议。所以产品更需要去“关怀”用户的问题所在点，做到真正的“对症下药”。
6、现状：用户提出需求大多数是现状不满足需求，那么这里很重要的就是需要明确当前现状是怎么回事，它的解决方案是什么样的，为什么无法满足用户需求，而这些信息也是对输出新方案做一个有效对比。
对于一个需求，需要从各个方面去补齐相关需求信息，只有这样才能真正“吃透”需求，而在分析时就不会因为关键信息缺失，导致无法作出客观的结论。
分析需求
既然已经充分理解需求，那么这时候就需要掌握如何拆解需求、并找到本质需求。大家都说“洞察”，所谓的洞察就是能够在理解的基础上，很好地判断哪些是干扰信息、哪些是关键信息，以及这些需求“表面”背后的真实需求。并且能站在这个点上有更高的全局观去延伸需求的价值点，如何去服务更广大的用户群体。
1、价值性：我们在分析需求的时候，其实自身是带有明显“利益”诉求的，虽然我们是服务用户，并尽可能满足用户，但是评估需求的前提需要明确价值点，就是这样的需求能够产品项目或其他用户群体是否同样带来相应的正面效益。同时我们还需要明确这些“价值点“应该如何去衡量，其标准又是如何建立的。如果无法去建立基准，就说明在未来的效果追踪是不可控的。
2、规模性：通常面对一个用户提出的需求，在理解清楚需求内容后，并不是马上就扔进产品需求清单进行排期上线，而是需要去做前期的调研，去印证是否有同样需求的用户群体。无论是B端还是C端，我们都无法仅为一名用户服务的，这样只会沦为定制化产品。所以我们需要找到同类型的用户群体，从数据层面观察或用户访谈其是否有相似需求的潜在可能性。通过这样的“群体性”挖掘，才能知道这样的需求其影响面有多大。当然也有些需求属于创新性，无法评估潜在规模，这种就例外只能小范围上线不断迭代继而明确路径方向
3、重要性：所有的需求在经过分析之后，都是需要判断优先级的，什么是紧急又重要，哪些又是不紧急但重要的。在这里借助常用的“四象法则”是常例操作，但这也只是面对常规需求。本质上需求是复杂的，带有潜在”利益性“并相互博弈，比如领导需求和项目需求冲突，业务需求和产品需求冲突，到底哪个优先、哪个延迟这些都是需要综合考量，得出一个合理符合现阶段产品规划的。
4、数据性：显然，几乎大多数的需求，都可以从“数据”层面找到一定的佐证依据（前提数据准备充足），比如当用户提出某个需求痛点，可以通过数据去印证在这个场景下发生的用户数量有多大，他们普遍的行为特征是否比较接近的。又比如在某些特定场景下，用户集中在某些服务模块（停留时长、人数有明显高峰等），或者是明显漏斗转化较低的，那么就要知道是否这个地方发生的问题所在。
基于以上的判断，那么就可以输出相应初步的产品结论，是否纳入规划当中进行排期上线。这时候的产品需求是经过了分析及充分评估，并且有大概产品方案支持的需求内容。那么这时候才算是真正的产品需求。
如果当期需求太多，做不完怎么办？
1、平衡：如果是面向B端业务，那么所有业务线对自己的需求都是关注且紧迫的，这时候就需要学会平衡每个业务的需求，不能被业务完全牵着走，这样对产品规划会有极大影响。那么每当这时候，就需要可以一起拉通多个业务，来集中评估各方的诉求，宣导团队的资源是有限性的，让业务之间来取舍他们之间的优先级，这就是让“决策”转移到业务自身上。
2、替代：任何的产品解决方案都是有备选方案的，那么在当前无法尽快满足用户的前提，可以优先采用临时方案，先满足用户最核心的需求，把其他延伸性需求先砍掉，待到条件成熟在上线完整需求。而这就是采用“替代”的方式，一定程度上去满足用户需求，这对挽留用户、提升用户口碑有极大帮助。
3、延迟：这是一个不太“厚道”的方式，前面提到用户对他们自身的需求都关注比较强烈，受限当前的规划和限制条件，确实无法那无法尽快满足的情况，但用户是不会理解买账的，那么如何去“安抚‘用户情绪呢，把负面情绪尽可能降到最低？这就靠一个“拖”字决，可以先给对方的一个明确信号：我们会做（类似先画个饼）。但是由于一些原因（把这些问题夸大），需要稍微往后一些才能支持，那么这个往后的时间就可以相对灵活可变的，在这里也主要是安抚用户的情绪为主。