【工作相关】如何了解清楚公司的业务？

正好之前写过一篇文章来讲这个问题，我摘录一些给你：

假设我入职一家新公司，负责一款已存在的产品，可能会做的有以下几件事：

1、问问题。

入职公司后，第一件事，是整理问题，并向自己的直属领导提问。这也是我觉得需要强调的一点，就是不要“上来就开干”。积极主动是好的，但公司招来一定是要你解决问题的，相信你自己也会通过一些渠道了解到一些情况，也有自己的疑问。那就要第一时间去收集、了解、思考这些问题，把这些问题形成一些“todo list”，以此来迅速切中要害，事半功倍。可能的一些问题如下：

* 这个岗位的职责是什么？权利是什么？明确权责，方便后续更顺利地开展工作。

* 如何衡量岗位职责是否执行到位？也就是如何考核？明确考核方式，让自己更有针对性地使力，分清主次和优先级。

* 我要负责的是哪款产品？这个产品高层认为最大的问题是什么？明确公司对产品现状的理解。

* 我认为这个产品当前优势是XXX，劣势是XXX，当下最需要解决的问题是XXX，对么？明确自己对产品的理解是否正确。

* 这个产品给用户带来的最大价值是什么？这个价值如何衡量？讨论产品定位和目标达成的客观标准。

* 你希望我来发挥什么样的作用？再一次明确自己被选择的理由和领导对自己的期望。以确认自己和公司的匹配度。

2、看数据。

有些问题可能好解释，有些则要带着问题寻找线索，而数据则是最能客观反映问题，对于数据的观察结果，本身也可能产生新的问题，带着问题又可以回归到第1步，继续讨论。

具体如何看数据呢？仍旧有如下几步：

第一步：确认产品埋点情况。埋点是所有产品的基础，也是决定分析结果的关键因素。我见过太多由于胡乱埋点导致无法通过数据验证功能的情况。如这一环节有问题，就推进解决。比较好的办法，1是建立清晰的埋点表格。按“版本、功能模块、埋点名称、触发行为、参数说明、备注”几个维度记录，2是完善埋点验收流程。表格清晰后，就要求产品、测试在发版前进行埋点验收，确认是否正确触发。这一过程很枯燥也很容易出错，但却非常必要，由于要通过数据验证功能，产品经理需要对验收更为上心。3是和技术商量，尽可能把埋点放到服务端进行。通过日志分析、API接口统计的方式记录，减少App发版延迟带来的影响。

第二步：确认数据指标定义方式。由于是成熟产品，相信已存在一些数据报表。那就要对报表上每个指标的统计口径进行一次复盘，看看实际是否能对应到已有埋点上。确保让所有人对报表的结果理解是一致的。

第三步：观察数据。上述准备工作做好了，才可以真正观察数据。实际观察的包括：宏观趋势，指那些新增、日活、留存、启动次数、使用时长、使用频率这样的通用数据，通过这些数据来确认自己的产品，和行业已有产品的差距；行为路径，定义出用户完成一次产品使用的关键行为，把行为投射到漏斗上，确认哪些环节存在较大流失风险；流量分配情况，确认从首页开始，用户流量如何被分流到各子页面上，以评估产品核心价值是否有传达给用户。

3、明确组织架构。

对老鸟而言，有人的地方就有江湖。如何在这个江湖中游刃有余，取决于你怎么“站队”。当然这里的“站队”不代表要参与“办公室政治”，而是希望当遇到问题，能找到合适解决这个问题的人，这个人可能是你的领导，但更多应该是和你合作的各部门相关业务负责人。产品经理是要求多人协作的角色，所以理清公司架构能迅速帮你进入角色。具体要了解的情况包括：

* 各部门层级结构；

* 各部门职责、权利、分工；

* 部门成员、部门Leader都是谁，坐在哪儿；

* 自己部门和其他部门的交叉合作关系、合作方式、合作流程都是什么。

务必让自己的Leader带自己去认识一圈，先混个脸熟，尤其是会有紧密合作的技术、设计、测试、运营部门同学，以后好办事。

4、浏览文档。

我在新人时，入职后第一时间会去要大量历史文档阅读，尤其是各种产品原型、需求文档。但现在看来，看文档其实反而应该是最后一步。因为产品是在不断进步的，过于关注历史包袱反而会影响发挥。文档的作用更多在“查询”，也就是当你遇到实际执行问题，回过来看看之前的规则，以帮助自己理解前人思路。

不过在阅读文档时，有一类文档很有用，值得仔细研读，就是“流程”文档，它能帮你迅速理清产品逻辑、业务逻辑，同时也希望你能在阅读时对流程进一步完善，加入自己的理解。

以上就是我总结的产品新人入坑指南，希望对你有帮助