进入新公司，我们都希望自己能快速熟悉需求了解业务，以便能迅速开展工作。有没有具体的方法可以实践的？本文作者分享的了解业务和熟悉需求的经验，希望可以帮到大家。
小花：“每次入职新公司，总是有点茫然，不知道从何下手，感觉好像应该有一套流程的，梳理着梳理着就有点乱套。”
小A：“别着急，你一定已经有了一部分自己的方法沉淀，只是还没来得及沉淀出来。”
小花：“诶，自己好像有那么一点感觉，但又不强烈，你有什么建议吗？”
小A：“我也是刚刚整理了自己过去5年的产品工作经验，梳理了一下自己的工作思路，如果需要的话，可以一起来看看。”
行业情况：
我一般会对行业现状、头部企业及其运营情况进行了解，可以快速对全行业有个基础的认知，对于一些专业领域的特定知识开始初识，针对性的根据报告中不易理解的专业性内容，但又与未来负责业务紧密相关的知识做一次深入洞察/研究。很多公司的发展路径都存在一定的雷同性，站在巨人的肩膀上了解事情、思考问题，总会对自己的业务带来一定帮助或启发。
可供学习的网站也比较多，以下是我常用的几个网站：
数据分析层面都比较全面，均有各自的侧重点
1）艾瑞网：
提供大量的行业研究报告，涵盖了互联网经济的各个方面，包括电子商务、在线广告、社交媒体、移动应用、游戏、视频等。
报告内容详尽，包含市场规模、发展趋势、竞争格局、用户行为等关键数据和分析。
2）CBNData：
聚焦消费领域的数据研究和市场洞察。
发布的行业研究报告涉及互联网、消费品、金融、房地产、健康等多个领域。
3）199IT：
提供全球范围内的市场数据和统计报告，涉及互联网、科技、金融、消费、文化娱乐等多个领域。
报告来源广泛，包括知名咨询公司、研究机构。
定期推出专题报告，深入探讨特定行业或市场的热点话题。
4）TalkingData：
领先的大数据服务平台，提供了大量的行业研究报告和数据分析。
专注于移动互联网、用户行为分析、市场趋势等领域。
发布的行业报告覆盖广泛，包括移动互联网、游戏、电商、金融、广告等多个行业。
产业链：
拿近几年爆火的短剧行业举例：可以从业务流程成主要涉及的环节到各环节所需消耗的成本进行梳理。
从公司发展历程中，可以深度了解企业软硬件迭代过程的大背景、原因，对于后续的业务理解会有一定帮助，如在搭建新业务时，因为了解了公司发展过程，由于客观原因或既定事实，又或者跟随公司发展的走向，去思考的业务更贴合公司未来规划、更符合当下现状，也可以避免一些之前已经出现过的坑，可以走得更远一些。
了解途径：
1）可从公司官网直接查阅，举例如下
2）可与中高层领导/公司前辈了解企业发展历程，核心/重大事件
无论哪种途径，知道了某一阶段的结果，我尽量还会让自己多思考一下，比如为什么做这件事？不做这件事会怎么样？有没有其他更好的选择？这件事对后续哪些事情带来了比较大的影响？
我一般从业务主线开始了解。
企业的主营业务是什么？业务流转是怎么样的？营销模式是什么？组织架构是什么？所在行业头部企业是哪些、运营模式分别是什么？
或者简化一些的版本，可以参照以下结构进行分析，基本可以对企业的商业模式有个大体了解，再在业务熟悉的过程中，不断完善补充即可。
了解了商业模式，再来熟悉公司的产品矩阵，可能会更有思路一些，大概知道为什么做这些产品，以及这些产品的作用和解决的问题大概是什么。
从主业务流转中梳理每个环节涉及到的干系人、系统平台、目标等，将已有产品串联起来，更深入的理解每个产品背后的用户故事与作用、当前发展阶段及未来发展规划。
可参考下图进行部分内容的结构化梳理：
核心业务的用户地图，可以采用脑图或泳道图的形式进行梳理，梳理的过程中，会查缺补漏从宏观分析中没有涉及到或遗漏的重点内容，梳理方式可参考下图：
这项一般年初或年终的大会上进行宣讲，若错过了大会也不要紧，可以找部门领导沟通了解，我一般会了解公司整体近1～2年的营收目标、发展方向、对核心产品的迭代目标、预计投入资源，及最终要的目前已经达成的进度情况，结合当前已了解的公司背景再提出一些疑问。
老生常谈的事情，谁在什么场景下用这个产品为了解决什么问题。
我总是容易先入为主的认为这个用户只有一个，但其实不然，根据实际业务出发，有主线有支线，支线往往容易被忽略，但其实缺少的话很有可能影响主线的走势，使用体验，甚至影响产品的完整性。
可以从几个问题出发，开始着手了解，我一般会问：
目前产品的迭代阶段是什么、近期的迭代目标是什么、是否碰到什么阻碍。
产品通过什么获利、其中的干系角色有哪些，分别负责哪些工作，内部干系人的KPI指标有哪些。
我习惯在每次整理好前面那些内容后，再理一下业务ER图、流程图、产品结构图，会帮助我更清晰的从全局角度观察整个系统，了解来龙去脉。
举例产品结构图如下：
1）若业务流转类需求：
从获客到中间的页面流转再到最后的客户转化，各个核心环节的流程和限制分别是什么；
例：建筑行业需对工程计划的修改进行审批管控，需梳理已有流程的线上化都具备什么能力，对计划的管控到什么程度；
2）若是数据报表类需求：
一般会梳理数据报表统计的业务维度是什么、主要能力是什么（如监控核心指标变化趋势是否异常等）、数据范围是什么、数据来源-上游业务是什么、数据的更新频次是什么、与其他页面的关联情况及其对下游的影响；
例：需将用原有用户转化漏斗分析进行细化，需梳理原漏斗包含了哪些流程，数据表现情况一般是怎么分布的等。
对相关功能有了透彻的梳理后，再找业务方进行详细需求调研，了解需求的真实目的背景， 不要做需求的搬运工，我尽量让自己多问一些问题，挖掘客户深层次的需求原因。
例：上面提到的建筑行业需对工程计划的修改进行审批管控，调研了解到真正原因是，原线下管控流程过于复杂且为纸质版管理，极易出现数据丢失、周期漫长、不知道审批卡在哪里等问题，导致决策层对计划修改的频次、进度、效果等无从知晓，无法快速决策管理。
未成体系化或未做到系统之前，业务处理的方法是什么、是否有固定流程、参与方都有哪些，原流程有遇到什么问题吗？ 思量后，再进行大致框架设计，和可能存在的问题点。
例：将用户原有转化漏斗分析细化，调研后发现，原来解决该问题都是通过人工取数（数据分析师根据业务方要求去获取数据）的方式导出为excel表格供业务方使用，2~3次/周。
若完全独立的新功能相对好一些，历史数据的问题可能相对较少；当对已有核心功能进行改造，需要考虑历史数据兼容的情况，不能因为新上的功能导致历史数据或老用户无法正常使用；
例：共享单车调度功能，若原有2套功能逻辑，分别针对不同模式代理商使用，里面的调度逻辑可能都不相同，由于公司发展规划，后期会着重其中一个模式进行重点发展，系统上要求功能逻辑合并统一，此时，需要考虑如何合并，才能既不影响历史数据正常使用，又能让更换模式的客户快速上手；方向建议：内部评估讨论后，结合公司系统现状，基本倾向于配置化方式进行解决；当然也可能会有其他更好的方案，我们只是站在当时公司的具体情况进行评估，如果大家有什么建议，欢迎评论区一起讨论。
这是我一开始总会遗漏的点，整个方案梳理好后，需要明确功能的操作权限角色、数据的权限角色，有些业务是有严格的部门业务属性、或保密属性，需要按照业务要求进行权限管控。
例：公司财务相关的的数据，一般管控的比较严格，只有财务部门、资金部门等相关性较强的业务部才有权限进行查看，若权限随意开放给其他业务部，可能出现数据泄露等问题（这里可能存在一些无意间的调侃导致的泄露）。
今天就和大家分享到这里了，欢迎大家在评论区一起讨论学习~
本文由 @不知名产品露 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。