G端需求调研避坑指南

25 评论 19581 浏览 351 收藏 20 分钟

编辑导语:有效的需求调研可以让产品经理更好地了解用户需求,提高开发效率,降低无效成本。而不同于C端,G端需求调研还需要考虑决策者需求。本篇文章里,作者结合实际经验,总结、分享了G端需求调研时可能遇到的问题与解决方案,一起来看一下。

前言导读

  • 你是否遇到过需求频繁变更的甲方,导致项目需求蔓延严重?
  • 你是否遇到过“我不要你觉得,我要我觉得”的甲方?
  • 你是否遇到过上线后客户说“和我们想要的不一样”?

作为G端产品,没遇到此类情节是一种幸运,遇到才知有多坑,本文初心是希望能帮忙提前识别和避免。

此处G端产品的需求调研避坑指南,各项目所遇问题不同,经验总结仅供借鉴,也希望和踩过同样坑的产品,一同交流。

大家携手,让坑少一点,路顺一点。

预计阅读时长:15min。

一、首先,你调研到全部需求了吗?

举个例子,产品接到临时又紧急的需求,但被告知没时间做深入调研,只了解以下信息。

  • 老板说:这个客户很核心,可以不赚钱,但客户要搞定。
  • 客户说:我需要一整套住房,一家五口人住,三世同堂,需要满足所有日常使用功能,配套设施要齐全,但我预算有限。

产品一听,也不是不能做。为满足客户需求,同时获得肯定,还要控制成本,决定利用公司资源,获取一套周边设施完善的经济适用商品房,但客户一家人一直在国外度假,没空确认。眼看工期将至,产品赶紧带团队没日没夜加班装修,将客户所提功能全部满足,准备交房验收。

客户回国一看却大失所望,觉得和自己的理想住房完全不同。

再次沟通才发现,只掌握了需求的冰山一角,且实际财政权在爷爷手里,不在一直沟通需求的男主人这。而爷爷的实际期望,是泳池大别墅,拒绝验收。但能怎样呢,客户哪有错呢,错的只有背锅侠产品。

避坑36计|G端产品的需求调研避坑指南

这是按真实案例抽象改编的故事,属于客户期望与实际落地差距存在一条鸿沟,核心原因是:

  1. 前期需求调研不稳,后期实施落地不准。
  2. 未掌握全部关键相关方的客户需求。
  3. 埋头干活,未阶段性地验收交付。

因此,为避免需求落地的巨大偏差,缩小这种偏差,需明晰各阶段需调研的信息,才能保障方案产出的质量。

二、各阶段调研的内容和产出

ToG需求调研可分为三大阶段,前期背景调研、启动阶段的整体业务调研、交付阶段的需求调研和设计确认

信息来源不限,可来自市场、售前、项目经理、客户、用户、客户官网、招投标等各类渠道。

1. 前期阶段:背景调研

大坑之一:不重视前期调研,将增加客户期望与实际功能偏差的可能性。

在项目启动前期与客户沟通中,产品经理需要充分了解项目背景、客户诉求、使用单位环境情况、业务数据情况,避免在后期调研时存在信息差。

在该阶段,需了解项目背景、客户、使用单位环境、业务数据源信息,详情如下。

1)了解项目背景

首先,要对项目产品所服务的业务领域有一个概括性的了解。

其次,在项目开始前,一定要明确项目终极不可更改的目标是什么,要跟所有相关性方、特别是和大领导要对齐目标。明确为什么做该项目?该项目的长期愿景是什么?短期目标有什么?

  • 项目做什么:清楚项目核心解决的问题,可通过招投标信息、市场和售前人员介绍、网上相关资料搜集了解建设方的诉求,掌握希望达成的目标;
  • 项目是什么:掌握项目现状,是从0-1的新建,或已有版本的迭代,或已有版本的推翻重做,目前现状存在什么问题;
  • 项目怎么做:了解项目预算、项目建设周期、相关政策指导方针、制度要求、行业标准、行业规范。

2)了解客户

了解客户想要什么的过程,需贯穿G端项目的始末。

需求变更、需求反复、需求蔓延在G端项目中难以避免,究其核心是让产品与客户心理期望的“蓝图”实现一致,怎样实现客户“蓝图”甚至超越客户想象,得到较高客户满意度,前期调研明确客户“蓝图”显得尤为重要。

  • 项目客户的组织结构:确认项目的用户机构是哪些,以便后期掌握不同角色对系统的诉求;
  • 客户期望:ToG项目的特殊性造成了使用者和决策者不是同一批人,为此,需要区分掌握决策者、干系人、使用者这几类角色的不同期望,尤其是高层级客户需求;
  • 客户性格:便于更好的沟通。

3)了解使用单位环境

调研使用单位环境主要为掌握使用单位机房情况。政府项目大多为涉密数据,用内网较多,存在外网和内网数据如何打通等问题,需要提前了解系统运行环境。

  • 网络环境:掌握系统运行部署的网络环境,是内网还是互联网?对数据传输和功能实现可能有较大影响。
  • 部署服务器配置:所需内存?cup配置是否满足需求?G端软件项目中,项目经理参与程度不一,产品常承担部分项目经理工作,为避免硬件不符合要求,延误需求上线,需提前掌握该部分信息,及时申请或采购。
  • 用户:用户量多少?并发量多少?

4)了解业务数据源

数据获取程度由数据基础决定,需逐步明确数据情况,在足够了解数据基础后进行系统设计与产品方案设计。

  • 有什么:该阶段的数据调研,掌握需要什么业务数据;
  • 为什么:为什么要有该类数据,核心解决了什么问题;
  • 怎么做:怎么获取该部分数据,以明确数据对接方式、网络环境。

2. 启动阶段:整体业务调研

在项目启动签订合同前后,会对整体的业务进行调研,需预留准备时间,做充足的调研准备。

在该阶段,需关注用户角色、业务流程、业务数据、功能架构信息,详情如下。

1)角色调研大坑之二:未掌握高层客户底层需求。

各层级都有各自角色形成的期望,掌握各层级期望,有助于方案设计和成果汇报更加顺利。

  • 需求分析:站在用户角度分析高层决策者、干系人、使用者各角色的需求,分别存在的痛点,以及是更关注尽早上线、功能完善程度还是界面美观程度;
  • 用户习惯:通过提前了解用户已有系统,掌握用户的整体风格与交互习惯,了解用户对已有系统的不满,及时规避不足;掌握上层平台,提前规划数据对接及应用对接方案。

2)业务流程梳理大坑之三:业务调研深度广度不够。

客户不是每个流程和业务都知道,需要留时间给客户去了解和调研,引导客户深度参与。

若是以部门为单位的集中式调研,调研清单要设计合理,给客户足够的考虑时间,最好提供相应的建议和案例,让相关部门提前思考和准备,能提前拉群沟通和提前获取业务相关资料更好。

在业务调研环节,主要调研和输出业务流程、场景、核心需解决的问题、业务流程中的输入输出。

  • 绘制业务流程图:了解业务场景,梳理每个流程节点内容与负责人;业务涉及使用角色说明;业务流程中的表格、报告,最好都有真实样例数据;
  • 业务数据源:涉及到哪些数据源;数据来源网络环境;数据更新时间;数据量多大;字段标准等;业务流程中的表格、报告,最好都有真实样例数据;
  • 业务流程优化建议:存在什么痛点,有什么建议与想法。

3)业务数据源

该阶段明确业务数据源的来源和内容,掌握需对接的第三方平台及单位,确认需要协调的资源,避免不确定的风险,为方案选择和实施能带来较大便利。并能保证项目开发进度,比如由于数据无法如期对接、推送延迟、数据质量较差等原因,将影响我方项目交付。

  • 系统对接类:提前明确和什么系统对接;网络环境及数据传输方式如何;接口规范如何,需明确输入输出,最好提前获取对接文档,梳理数据流图;明确系统对接人单位、姓名、联系号码、岗位,和研发人员建群提前沟通;明确接口提供时间,是否影响项目进度;
  • 数据填报类:需掌握填报内容和填报业务流程,如填报角色是谁,是否需要审批,更新要求是什么;
  • 数据情况:获取样例数据、数据更新时间、数据量、字段标准。

4)功能框架确认

在整体业务调研基本完成时,需同时梳理整体功能框架,并进行确认。在确认阶段,尽可能避免在沟通中出现理解偏差。最可怕的是,双方都认为对方理解了彼此的意思。

面对信息化建设经验较少的甲方,建议准备首页、能体现平台架构的主页面的视觉稿,确认架构和整体风格,更能被理解;面对决策层级较多的甲方,并需要针对不同客户角色关注点,准备不同颗粒度的方案。

  • 项目整体框架:项目的整体模块功能层级,确定子系统和功能模块;梳理模块功能清单;梳理各个模块之间的关联;确认和上级系统的关联;
  • 确定阶段目标:确认业务功能优先级;制定阶段性功能目标;梳理里程碑目标。

3. 交付阶段:阶段性调研确认

交付阶段遇到技术明确,需求不明确阶段,增量交付方式返工概率大。产品原型设计需预留足够时间进行多次确认,设计采用敏捷方式多沟通确认,开发使用瀑布流方式,确认需求并验证方案后再开发,去降低推翻重来的风险。

在该阶段,需关注需求列表、整体功能架构、业务数据、系统设计信息,详情如下。

1)需求维护

大坑之四:从不了解业务/没有决定权的角色获取需求,九成返工。有时方案确认像闯关,层层规则不一样。明明因为方案未确认而无产出,但甲方只觉得你没干活。

需针对不同层级领导沟通实现想法,了解真实期望,和项目经理一同分析领导信息化认知阶段和关注点,准备不同材料,客户是想早点上线?还是更关注界面美观?还是功能完善?还是成本控制?

其实人生有捷径。重要决策可想办法,通过商务、项目侧各方面拿到决策方、拍板人的意见。

  • 可建立需求初步筛查规则,在需求首次被提及时,需求获取人可对需求进行初筛和答复客户;
  • 和甲方针对各需求获取渠道建立统一需求对接人,将承接的需求汇总;
  • 建立共享需求反馈池,根据需求类型及迭代状态进行分类管理,让需求采集及时记录,需求规划及进度一目了然;
  • 对已上线的需求、已提测的需求、挂起的需求、当前迭代已确认的需求,单独建表管理;
  • 需求变更很常见,也需长期和甲方“博弈”,需分析客户关注哪个需求,聚焦于核心需求,在变更时及时调整优先级,和甲方沟通确认;
  • 分析客户关注哪个层级信息。

避坑36计|G端产品的需求调研避坑指南

2)维护整体功能框架

  • 项目整体框架:交付阶段及时维护子系统和功能模块;维护功能清单;维护各模块功能关系;
  • 跟进阶段性目标:根据项目变化,及时调整需求优先级,阶段性验证功能目标的完成情况。

3)业务数据源

该阶段需在项目经理和技术人员协助下获取信息。

  • 了解和第三方系统对接处于什么阶段;
  • 已对接的数据进行数据验证,判断是否满足系统设计要求;
  • 短期无法对接、对接后有数据问题的模块准备预备方案。

4)确认系统设计大坑之五:忽视决策高层与使用者需求之间存在的差异。

有决策权的高层需求与系统用户的使用需求,同等重要。宏观到整体架构,微观到字段,需分层明确。

项目有计划,研发有流程。再确认环节为不影响项目整体进度,需想尽办法拿到决策方、拍板人的意见,向客户阐述现状及利弊,必要时通过市场、项目侧推动,否则因需求反复造成的返工情况,会严重影响工期和团队积极性。

  • 客户需求:区分业务使用者和高层的关注点;决策干系人关注业务场景;使用者关注是否能满足日常使用;
  • 业务流程:调研现有的业务;规划系统使用之后的业务流程;确认通过系统完成的流程优化;
  • 产品页面设计:需对系统输入输出、页面布局、涉及字段进行细节确认。

在这设计逐步确认过程中,甲方才能逐步明确自身想法,偶尔也需要一些沟通“技巧”。

三、G端与C端的调研异同

比较G端与C端调研的差异,两者都需要通过调研构建用户画像,也同样说的不等于想要的,但也有很多不同点。

对用户而言,G端产品的替换成本大于C端,因此需关注用户已形成的习惯和认知。另外需对已有系统和环境的调研更为重要,如硬件设备的分辨率情况,将严重影响设计方案。

在业务需求调研方面,C端属于用户就是客户,使用者至上;G端的使用者和决策者往往是两批人,需求提出方和建设方也往往是两批人,更多的是决策者至上

四、总结

总之,需求调研是需求分析的前提,需求分析是产品方案决策的依据,需求确认是对需求调研准确性的验证。

只有足够的输入才有好的输出,所以明晰各阶段需求调研所需内容,做好需求调研,才能保障方案的产出质量,从而为客户带来价值,获得客户对我们服务的认可。

望共勉之。

 

本文由 @wenda 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 前期调研,客户说:什么,你问我?你们写的解决方案,你问我?我也不懂。想让负责人帮忙协调业务单位,协调不到。只能基于行业认知,基于售前写的方案去假设,出完原型、需求后,跟客户确认,客户指指点点,这不对、那不对。

    来自江苏 回复
    1. 哈哈哈,感同身受。

      来自江苏 回复
    2. ….激动的都 用错词了..→_→

      来自江苏 回复
  2. 文章每一个字都仔细看了,感同身受的同时学习到很多,感谢分享!

    来自浙江 回复
  3. G端的业务流程图有案例吗?比如G2C项目有可能会涉及面向C、B、G的多个平台,怎么来系统化搭建?

    来自浙江 回复
    1. 同想问

      来自广东 回复
  4. 感谢分享,最深的一句话,G端,决策者至上

    来自湖北 回复
  5. 总结,以上的坑都踩过

    来自江苏 回复
  6. 很有帮助,可以加你讨论一下吗

    来自福建 回复
  7. 很有帮助,感谢分享!

    来自浙江 回复
  8. 同G端,收获很大,在需求调研这一块理得很清楚,尤其是高层次领导的需求这一点,感同身受👍👍👍

    来自浙江 回复
    1. 😁😁😁

      回复
  9. 很有用,谢谢

    来自浙江 回复
    1. 会越来越好的

      回复
  10. 好完整,受用了,谢谢

    来自广东 回复
    1. 不客气~一起加油

      回复
  11. 赞!新人刚刚入行G端,有收获

    来自广东 回复
    1. 加油 多学习多总结,找到最适合的节奏

      回复
  12. 来自江苏 回复
    1. Thanks♪(・ω・)ノ

      来自广东 回复
  13. 同G端 加个微信一起沟通下?

    来自北京 回复
    1. 可以呀,欢迎沟通交流:Wenda_T

      来自广东 回复
    2. 我可以加你不

      来自江西 回复
    3. 抱歉偶尔忘记处理未通过申请,申请时麻烦简单介绍下自己所在城市和岗位,以便更好交流

      来自广东 回复
    4. OK的 可以拉你进同行交流小群

      回复