来了现在这家公司三年，我从 B 端做到 G 端，又做 B 端加 G 端，企业、农业、财政、住建、组织、民政、社工、人社，各个条线基本都接触了一遍。
有时候刚把一个领域的专业名词认全，转头又被拉进另一个项目，从头学习一套新的政策、流程和业务规则。
产品经理大概就是这样。
现在这些公司成本控制得可怕，不会等你成为行业专家之后再把需求交给你。更多时候是项目已经来了，客户下周就要调研，领导过几天就要方案，你只能一边查资料，一边听业务讲，一边假装自己没有那么慌，对外人均“业务专家”。实际都是外强中干地在“干中学”。
接手陌生业务，最怕的还不是完全听不懂。
完全听不懂的时候，至少知道自己不懂，还会老老实实地问。
更麻烦的是，对方说的每个字你都认识，连在一起好像也能理解，于是你自信地回去开始画原型写需求。等到评审的时候才突然发现，你理解的“审核”和业务说的“审核”根本不是一回事。
你以为自己已经入门了。
但其实业务看你，大概像看一个刚学会几个行业名词就开始指导别人工作的外行。
01
我刚开始做行业研究的时候，习惯先找资料。可能因为我本身做行研出身。
看政策、看行业报告、看竞品、看专家观点，把能找到的东西都搜集起来，再从里面归纳出一个相对完整的结论。
这个习惯后来对做产品帮助很大。
尤其是做 G 端项目，很多业务都能追溯到一份政策文件。为什么要建设这个系统，监管范围是什么，上级部门要求报送哪些数据，政策里通常都能找到答案。
但做产品久了以后，我也越来越清楚：资料可以帮你认识一个行业，却不能直接告诉你，一线的人每天到底怎么工作。
之前我们接过一个农业口的集体资金监管项目。
从监管部门的角度看，这套系统要解决集体资金管理不透明、运行不规范以及资产流失风险。
于是大家围绕集体组织日常运行，提出了组织建立与撤销、重大事项、收支管理、用章、资源利用、资产租借和财务处理等一系列需求。
放在方案里看，逻辑很完整。
甚至可以拼成一套“社员+财务+资源资产+阳光公开+监管”的大型综合系统。
后来我们去找实际使用系统的基层人员调研。
第一眼就懵了。办事儿的基本都是五六十岁的老人，好多电脑都不会用，你还想要他学记账？
人家一年也没有几笔账，花几千块找代理会计就做了。你现在让他专门学一套系统，人家还不如直接原地退休。
监管方希望系统完整、过程留痕、风险可控。
一线人员关心的却是：要填多少东西，会不会增加工作量，出了问题算谁的。
两边说的都是同一项业务，但看到的是完全不同的世界。
如果产品经理只看政策和汇报材料，很容易做出一套领导看起来很满意、一线用起来很痛苦甚至完全用不起来的“办公室产品”。
如果只听一线人员的，又可能忽略监管、合规和责任追溯这些系统必须承担的目标。
所以，接手陌生业务的第一步，不是急着记住多少专业名词，而是先弄清楚：这项业务为什么存在，组织希望解决什么，一线人员又是怎么把它做完的。
这两个答案，往往并不完全一致。
产品经理要做的，就是先看见这种不一致。
02
面对一个完全陌生的领域，我通常不会一上来就研究整个行业。
因为一个行业实在太大了。
你想在几天内弄懂财政、农业或者人社，基本不现实。最后很容易看了几十份材料，收藏夹越来越满，脑子里还是一团浆糊。
更有效的方式，是先抓住一件具体的事情，跟着它从头走到尾。
比如做财政资金监管，不要先急着设计一张看起来特别全面的监管驾驶舱。
可以先挑一笔具体资金，顺着它往下走：
这笔资金从哪里来？
根据什么政策或者预算安排？
由哪个部门负责分配？
下达到哪些单位和项目？
资金在什么时候形成实际支出？
支出对应的项目进展到什么程度？
发现使用异常以后，由谁核实和处理？
项目完成后，又如何判断这笔钱有没有实现预期目标？
顺着一笔真实资金走下来，你会慢慢接触到四类东西：人、事、物、规则。
先看“人”。谁安排资金，谁负责分配，谁具体使用，谁查看进度，谁发现问题，谁最终承担监管责任。
G 端产品里的“用户”通常不止一种。财政部门、业务主管部门、项目单位和具体经办人员站在不同位置，看到的自然不是同一个问题。如果连谁在使用、谁在拍板、谁在背责都没有分清楚，后面的产品设计基本只能靠猜。
再看“事”。不要急着问系统需要哪些功能，先问现实中这笔资金是怎么流动和使用的。从哪里开始，经过哪些环节，在什么条件下可以支出，出现偏差后如何核实、整改和反馈。
然后是“物”。业务不会只存在于人的口头描述里，它一定会留下东西。一份预算文件、一张资金分配表、一份项目申报材料、一条支付数据、一份项目进度报告，甚至是业务人员自己维护的 Excel 台账，都可能比半小时的抽象介绍更有价值。
最后是“规则”。资金可以用于什么，不能用于什么；什么情况下需要调整；出现执行偏慢、用途异常或者项目进度不匹配时，应该由谁处理。
把人、事、物和规则串起来，一项业务的基本轮廓才算真正出现。
说白了，快速理解业务不是把整个行业装进脑子里。而是先找到一条真实的线，顺着它把散落的信息串起来。
03
很多产品经理调研陌生业务的时候，最喜欢问一句：
“你们现在的业务流程是什么？”
然后对方就会给你讲一套非常标准的流程。资金安排、项目申报、审核下达、项目实施、资金支出、监督检查、绩效评价。
听起来很顺。
等真正往下梳理才发现，不同类型的资金可能有不同的分配方式，不同主管部门维护着不同的项目材料，有些进度在线上更新，有些仍然依赖线下报表。系统里看到的资金执行进度，也不一定等于项目真实进度。
现实业务永远比流程图更野蛮。
所以，听完标准流程之后，还要继续往下问：
“最近一笔实际下达的资金是怎么处理的？”
“这份数据是谁提供的？”
“资金执行慢的时候，你们现在怎么发现？”
“发现异常以后，具体由谁联系谁？”
“有没有系统里看起来正常，实际项目却没有推进的情况？”
很多真正决定产品设计的细节，都是这样问出来的。
然后你会发现，理解陌生业务的时候，至少要分清三层东西。
第一层是规定怎么做。它通常写在政策、制度和操作规范里，是这项业务在原则上应该遵循的方式。
第二层是大家说自己怎么做。这是调研和会议中最容易获得的标准答案。
第三层是大家实际上怎么做。这里面可能有线下表格、人工核对、电话确认和各种约定俗成的处理方式。
三层信息都很重要。
只看规定，系统可能无法落地；只看实际习惯，又可能把不规范流程原封不动地搬到线上。
产品经理需要判断，哪些现实做法应该保留，哪些问题应该通过产品纠正，哪些矛盾根本不是一个系统能够解决的。
这才是业务理解真正费脑子的地方。
04
还有一个很容易踩的坑，是把做过的相似业务直接套进新项目。
比如说，集体资金监管做完以后，再接触财政资金监管，很容易产生一种错觉：不都是监管资金吗？
无非是看钱从哪里来、到哪里去，有没有违规使用。之前做过的流程、预警规则和监管驾驶舱，改改应该就能继续用。
但真正梳理后就会发现，虽然都叫“资金监管”，两个部门关心的根本不是同一件事。
集体资金监管更贴近日常经营和基层组织运行。监管部门会关注一笔收入从哪里来，一笔支出为什么发生，经过谁审批，凭证是否完整，有没有按要求公开，是否存在资金和资产流失风险。
它面对的是大量具体、琐碎的日常业务。产品既要考虑上级部门怎么看，也要考虑基层人员会不会填、愿不愿意用。
财政资金监管关注的则是另一条链路。一笔财政资金根据什么安排，下达到哪个部门、哪个地区和哪个项目，预算执行到什么程度，实际支出与项目进度是否匹配，有没有偏离规定用途，最后有没有形成相应的产出和效果。
财政部门关注资金整体运行和风险。业务主管部门更了解项目为什么实施、进度是否正常。项目单位掌握最具体的材料和使用情况。
有些异常能从支付数据中直接看出来，有些问题却必须结合项目现场和业务背景才能判断。
同样是“监管”，集体资金监管可能要深入到一笔具体收支和一次内部审批；财政资金监管则更需要把预算、资金、项目、支付和绩效等信息串起来。
一个偏向基层组织的日常规范运行，一个偏向财政资金全链条的追踪和分析。
如果只因为名字里都有“资金监管”，就把前一个系统的产品逻辑直接复制过来，很容易出现功能看起来很完整，真正的监管问题却没有被解决。
这也是做陌生业务的时候最容易掉进去的坑。
我们会下意识地用自己已经掌握的概念，去解释眼前的新问题。做过审批，就觉得所有业务都能抽象成发起、审核和办结。做过资金监管，就觉得无非是资金流向加风险预警。看过成熟产品，就觉得别人有的功能，我们也应该有。
但经验的价值，不是让你更快地套用答案。而是让你更快地提出问题。
监管对象是谁？监管方真正担心什么？系统里的数据来自哪里？发现异常以后，谁有权处理？所谓的“资金安全”，在这个部门里具体指什么？
业务名称相同，只能说明它们共享一个名词，并不代表它们共享一套产品逻辑。
05
前期资料看了，真实案例也跑了，是不是就算懂业务了？
还不算。
很多东西在脑子里感觉很清楚，一旦讲给别人听，就会发现中间缺了好几段。
所以，我会把自己理解的业务重新表达一遍。
不需要一开始就写几十页需求文档。可以先画一张简单的流程，列出涉及的角色、关键材料、业务数据和暂时没有确认的规则，然后拿回去找业务人员核对。
沟通时也不要只问：
“我理解得对不对？”
这种问法太宽泛，对方很容易顺口回复一句“差不多”。
可以直接带着具体判断去确认：
“我的理解是，这笔资金下达之后，我们需要同时关注资金执行和项目进度，对吗？”
“目前资金数据来自现有系统，项目进度则由主管部门或者项目单位补充，对吗？”
“系统发现异常后，只负责提示，具体核实和处置仍然由对应主管部门完成，对吗？”
越具体，越容易暴露理解偏差。
不要害怕被业务指出错误。这个阶段发现问题，最多只是改几笔流程图；等原型画完、开发做了一半再发现，改的可能就是数据库、接口和排期。
产品经理理解业务的过程，本来就不是一次性听懂。而是不断形成假设、表达出来、被人纠正，再重新完善。
06
那么，做到什么程度，才算基本摆脱了外行状态？
我觉得可以用几个问题检验自己。
你能不能用自己的话，说清楚这项业务为什么存在？能不能跟着一笔真实资金，从来源讲到最终使用结果？能不能分清不同部门、单位和经办角色的目标、动作与责任？能不能说清楚业务中最重要的文件、数据和判断依据？
遇到执行缓慢、数据异常、项目停滞和用途偏离时，你知不知道现在由谁处理、怎么处理？
更重要的是，当别人提出一个功能需求时，你能不能判断它来自哪一个环节，想解决什么问题，又会影响哪些人？
如果这些问题还说不清楚，就先别急着画原型。再多听一点，再多问一个为什么，再找一笔真实业务走一遍。
当然，产品经理不可能在短时间内变成财政专家、农业专家或者人社专家。也没有必要。
业务人员掌握的是长期积累的专业深度，产品经理更重要的价值，是把不同角色看到的局部信息拼起来，看见完整流程、关键矛盾和系统可以介入的位置。
我们不需要假装自己什么都懂。但至少应该知道，哪些地方自己还不懂，哪些结论不能想当然，哪些问题必须继续追问下去。
所谓快速入门陌生业务，不是快速记住一堆行业术语。而是尽快知道，什么地方不能说外行话。
发表于 1 小时前
|
查看: 5|
回复: 0
