38 | 新入职一家公司，怎么快速进入工作状态？

1.我会在权限允许的范围内，时不时的到处翻翻 ftp、内部 wiki 等资源，星星点点构建全貌（业务、技术、团队）； 2.梳理系统数据流。去年很火的电视剧「大江大河」里，宋运辉初入职场的方式就很值得借鉴：先走通全部流程，有个全貌，利用图书馆、师傅等资源再自己动手各个击破并绘制流程图，最终实践检验认知以技术说话融入团队。 「他就每天只要天气晴朗，绕着设备上上下下、里里外外地跑。一个星期下来，全部流程走通；两个星期不到，原理搞通，仪表能读，普通故障能应付；第三星期开始，他可以开出维修单，但得给师父过目；第四星期起，谁有事请假他可以顶上，坐到仪表盘前抄表看动态做操作。师父说他学得很快。 第四星期起，没人可以让他顶替时候，他在仪表室后面支起绘图板。先画出工艺流程图，经现场核对无误，又让师父审核后，开始按部就班地根据液体走向，测绘所有设备的零件图、装配图、管段图等。这工作最先做的时候异常艰难，首先是绘图不熟练，很多小毛病，尤其是遇到非标零件，还得到机修工段测绘，一天有时都绘不成一个小小非标件。如果车间技术档案室有图纸还好，可以对照着翻画，可档案室里的图纸残缺不全，前后混乱，想找资料，先得整理资料。资料室中年女管理员乐得有个懂事的孩子来帮她整理，索性暗暗配把钥匙给宋运辉，要是她下班不在的时候，让宋运辉自己偷偷进来关上门寻找资料。 机修工段的人本来挺烦这个宋运辉，说他一来维修单子多得像雪片，支得他们团团转，有人还趁宋运辉上班时候冲进控制室指桑骂槐，被寻建祥骂了回去，差点还打起来。但后来集中一段维修高峰后，维修单子又少了下去，上面还表扬跑冒滴漏少很多，一工段和机修工段各加一次月奖，可见设备性能好转。再以后遇到维修，他们不能确定要用什么零件，打个内线电话给控制室问宋运辉，一问就清楚。双方关系渐渐变得铁起来。基层有时候很简单，只要拿得出技术，别人就服。 」

有朋友正在转型，从乙方商业化产品的交付经理转向新公司的产品经理。原本得心应手的思维方式和工作习惯，遇到了巨大挑战。以前只需依据已有产品的功能出解决方案，能做就能做，不能实现就是不能实现，到某个时间交付什么功能很明确，考核是以交付签字为准。现在需要面对各方需求，自己想明白用户真正的问题是什么，最终要交付的价值是什么，没有一个实体的谁来签字，只有不断地迭代。 借鉴领域驱动设计，可以采用以下方法。简单描述的话，是一个点、一个圈再加一个箭头线，是不是有点像丘比特？ 一个点，指的是用户核心价值。这是最关键的一条，基本上只能靠自己想明白。想，不是闭门造车式的苦思冥想，可以是已有的领域经验，可以从书本中学习，可以是大家的各种吐槽，可以是自己从旁边观察用户的实践，还可以是自己变身为用户的实践。有些人会纠结点想的对不对，迟迟不敢动手。其实一开始想得对不对不是那么重要，关键是要有这点，然后快速到市场上验证，根据反馈再调整。 一个圈，指的是围绕核心价值划出的范围，即领域驱动设计中的限界上下文。产品经理面临的一个现实是，各种人都会给你提需求，只要他们觉得和你有关，还时不时来问什么时候可以实现。需求轰炸之下很容易焦虑，不光自己焦虑，所有的利益相关者都会焦虑。依据核心价值，框出需求范围，在和各方交流过程中可以有一种确定性，减少焦虑，利于行动。大家（不光是研发团队，也包括其他需求方）就能明白，哪些和当前核心价值密切相关我们优先考虑；哪些与核心价值有关但它不在我们的范围内，属于其他团队需要他们协助；哪些有关系，但目前没想清楚价值大不大并且代价可能很高建议先搁置。范围不是一成不变，它随着时间会发生变动，所以我们不要追求固定，只要保证在某个时间段内，大家一致认同即可。 一个箭头，指的是实现路径，箭头指向核心目标（核心价值）。目标（核心价值）和范围描绘的是终极，而从现实到终极还有很多路要走，可能的路径还有很多条。我们需要琢磨怎么走更稳当，怎么走代价比较低，路上关键的里程碑是什么。路径对不对其次，重要的是思考过程，可以把关键点需要交付的价值、需要支持的资源等等梳理清楚。 以上

昨天看的这篇文章，今天看《架构整洁之道》，第21章也讲到，团队新成员应该先了解系统用例，而非技术细节和交付方式。互相对应上了。

产品文档缺失，文档缺失，代码日志也没有，更不说单元测试没有。代码结构混乱，到处都有相同业务的特殊逻辑。原始架构依稀可见但早已面目全非。 更要命的事产品经理离职，剩下一些只言片语的PRD。和其他兄弟部门的对接报文，只能扣代码😂 解决：1.先加日志和性能监控 2.整理流程图（参考代码，PRD以及仅有的几个元老同事口述） 3.适度重构 4.重写系统。搞清业务边界，有序整理分类合并业务入口，优化程序处理流程以及性能。 在此过程还在接新需求

了解业务这一步是最难的，要么需要有人给讲，一般都没那么多时间，要么有详细的文档，一般文档都是零碎化的。

问题是，我们该如何想到是先了解业务而非技术？这种有相应的思考工具或者体系来帮助我们抉择吗？是否能抽象成通用的方法论应用在不同的领域？

三年前入职新公司的时候，本来认为是一个小问题，让对应的开发人员看一下代码是怎么处理逻辑就可以了？结果他们回答说不知道，那时还有点生气的说，这个你帮我看一下代码不就可以了嘛！后面才知道他们是属于前端的开发人员(C#)调用了是另外一位副总的服务端接口(C#)。

文章干货太多，划线笔记整不过来了，要用个思维图好好梳理下

优先理清楚业务的运作是最主要的。要不就是一头雾水。无从下手

有一个问题，就是在对业务不了解的时候，就算对方讲解，也是一知半解，似懂非懂，而自己最后上手的可能只是很小的一部分，这个问题要怎么处理呢？