当我们入职一家新的公司，或者新接手一个产品的时候，都需要一段时间去熟悉，以下主要讲述如何快速地掌握一个全新的业务和产品。
一、把框架弄懂（一天）
首先我们需要找人讲给我们听，集众人所理解，帮我们勾勒出一个最基础的框架模型，对新的业务和产品，产生一个初步的印象，之后再去慢慢地印证和完善自己脑海中的这个雏形。可以找leader，前任产品，共事产品，相关对接系统的产品各讲一遍，主要听产品规划，框架、业务流、数据流，这些比较大的东西。
二、把逻辑弄懂（三天）
看留存的文档，尤其是PRD，一遍看懂，二遍质疑，三遍优化。在看懂逻辑后，最需要的是学会提问，盲目的接受之前大批量的文档内容，只会让自己的思维变的更窄，容易被前任所做的东西限制，新人新入一个行业所具有的便是创造力。所以记录下此刻产生的所有疑惑，直到未来别人为你一一解答，或者自己给了自己一个回答。在第三遍的时候，便是去优化前人的逻辑，以自己的经验和思路，去重新看待一个问题，如果不能有更优的解，那么只能说明之前的逻辑无懈可击，但是这基本是不可能的，最多做到在当时是最优解。
据说在程序员界，每个人都会觉得前任写的代码和屎一样，宁愿重写也不去review。
三、把功能弄懂（两天）
这个方法就是写测试用例，测试可以不会产品，但是产品一定是会测试，无论是验收功能，还是测试思维，都是很重要的技能。创造和发现本就是需要兼容的两种能力，而把功能弄懂的最专业最全面的方式就是写测试用例，写完后，再对比测试写的测试用例，验证下自己的测试思路，总会有所获。
四、把业务弄懂（两天）
去业务方那里轮岗，或者做客服，当我们接受完来自产品的正面信息时，就可以去听听业务方或者用户的负面吐槽，任何事物的看待都需要正反两面的，才能立体地展现，而不仅仅单纯地看一个面，其次使用者的理解才是产品的灵魂所在，你设计的有没有灵魂，不是你说的算的，在于使用者有没有发现灵魂、发现价值。
最后，在业务的理解层次中，业务方就算能力再弱，他也属于中高层，当你可以用产品去指导业务发展的时候，你才是处于比他更高的顶层。
五、把数据弄懂（一天）
找研发要数据库表结构，数据口径定义，算法的基本逻辑，脚本的作用和运行逻辑以及接口文档。
首先了解数据库表的结构在今后会有很多的作用，毕竟B端产品的一个设计思路就是对数据的处理。一个是提数的需求，一个是新增字段新增表结构等需求，以及部分功能的取数逻辑设计，最重要的是和开发的沟通效率和专业度，都需要基于你对数据库表的理解。简单地就是知道系统的哪个字段在哪张表，并且知道这些字段和表的联系，即使不懂技术也能知道这些。其次就是脚本的运行逻辑，这个在出现bug的时候，对于排查特别重要，还有就是之后的一些流程的设计都会关联到脚本的运行时间、顺序、触发、输入输出等逻辑。最后是接口文档，接口的调用，可以让你知道你的系统有和哪些系统做对接，有哪些数据是来源于其他系统，还有哪些系统是消费了你的数据，之后在重构、或者排查bug的时候，都需要注意到这些。
例如，某个功能挂了，快速定位是某服务商的接口挂了，推动对方修复，避免损失。
例如，自己重构了某个数据口径，需要告知调用方做调整。
例如，部分特殊订单不在总订单表里，所以取数的时候要取两个表，避免数据遗漏。
例如，表里有假删的数据，原本做了过滤，新设计的一个界面也调用了这个表，也需要做过滤。
例如，业务方的作业时间调整了，而你的脚本运行时间却忘记调整了，导致数据没有产生或者同步。
六、把思路弄清（一天或长期）
主要了解这个行业的背景，我一般会先去知乎、人人都是产品经理、pmcaff、自媒体或者专业论坛看一些碎片化的文章，看很多大概几十篇以上，集百家之长，看过的文章第一遍都会用印象笔记剪藏，第二遍会去改写文章，主要是去掉没用的表述，以及标红重点的内容，去其糟粕，取其精华。第三遍是归类这些文章的内容，写一些输出或者笔记。最后如果自己有实践了，就会去写一篇文章。很普通的输入输出模式，但是上手又很快。一周就可以把一个行业表层的东西弄清楚，甚至一些大牛的理解可以让你先看到一些深层的东西。到了你真正要理解深层的时候，则需要长期去沉淀、系统化学习和实践。
综上，新入职一家公司，新接手一个业务和产品，多加点班，一周就可以上手，两周就可以接需求，三周就可以做项目，甚至能力强的，有想法的，其价值已经超过了前任产品。可以在业务池子中任意遨游，没有瓶颈的限制，直到把自己的池子扩大，再去加深。