空降架构师如何用2周让领导刮目相看？

文章首发公众号『风象南』

一个故事

书接上回 『当年我靠着这个回答，顺利应聘了架构师岗位』，我以架构师身份空降到团队后，接到的第一个任务就是优化当前公司正在销售的一款产品的性能，技术副总要求我先出一个方案。

那么如果作为你，你会怎么落地这个事情，最终产出什么东西 ？

下面分享下我当时的做法以及最终交付了什么东西。

1. 业务

首先我先自己从公司的资料库找到了产品相关的材料对产品功能、关键业务流程及应用场景建立对产品的基本认识。

这步我结合公司的演示环境边看资料边进行系统操作验证，确认自己的理解没有问题，并在这个过程记录了存在疑问的业务和产品功能。

然后找到相关人员进行咨询，进行问题澄清。

2.技术

接着我找到相关技术文档及从仓库拉取了代码，了解了系统当前的架构、模块划分及依赖关系、使用到的技术组件及组件之间的交互方式和依赖关系、与外部三方平台、系统的对接等。

这一步除了从技术层面整体了解系统设计之外，重点需要梳理可能存在的性能瓶颈点，为后续的方案设计提供参考。

然后通过同事了解当前QPS最高的几个关键接口，以及当前还存在什么样的技术卡点，另外通过业务触发端到端的代码流程串联，借此能更详细的了解技术框架和组件的一些使用细节。

同样，将其中存在疑问的部分进行记录，然后找到相关人员进行咨询，进行问题澄清。

3.数据

很遗憾，产品没有详细的数据库设计视图，只能连着数据库实例查看表结构，再结合业务、代码梳理核心的数据表及表关系。

然后，对数据的存储方案，如分表策略、集群模式、如何同步等等进行了解。

同样，将其中存在疑问的部分进行记录，然后找到相关人员进行咨询，进行问题澄清。

方案输出

经过上面两周的熟悉后，从各维度上基本上掌握了产品的基本情况，接下来就是重点针对性能部分进行优化方案设计。

优化方案我从背景、现状、系统架构、问题分析、优化方案、实施路径、风险控制、预期效果等几个方面进行了描述，最终形成了 『XX系统性能优化方案讨论稿』，并完成了其中几处关键方案的预研以验证方案的可行性，将结果一并附在了讨论稿中。

额外的产出

『XX系统快速入门指南』

在熟悉产品及技术阶段花费了较长时间，主要是因为没有一个系统性的文档来作为指导手册，各种文档比较零散，看起来比较耗时费力.

所以为了避免后面再入职的新人碰到和我一样的问题，我在完成产品和技术部分的熟悉后顺便整理了面向技术人员快速了解业务的《XX系统快速入门指南》

其中包含了熟悉产品所需要的必要业务知识、系统架构概览、核心功能模块介绍、本地代码环境搭建、以及常见问题解答等，旨在帮助技术人员快速上手并融入项目开发工作。

『数据库设计』

在梳理数据阶段由于没有ER设计作为参考，费了老鼻子劲，这个过程我又通过PDMan逆向数据库结构又进行了手工调整形成了一份完整的《数据库设计》文档

另外，从性能和扩展性方面梳理了其中可以进行优化的设计调整，合并在了讨论稿里面。

总结

其实通过这个事情是想跟大家提一个概念叫超预期交付

什么是超预期，就是在别人的潜意识或者经验里认为这个事情你大概能做到60分，但是你做到了70分，甚至85分，给人一种惊喜。

能让别人感觉惊喜这也算提供了一种情绪价值。

其实按照技术副总的期望应该我第一阶段提交一份优化设计方案就OK了。

但是我做到了方案的尽可能完善，同时又在这个过程从团队角度出发，输出了『XX系统快速入门指南』与『数据库设计』两份材料，那么这个产出就超出了领导的预期，作为刚入职的员工通过这次产出就建立了一种初步的信任。

不管是在职场还是在生活中，人与人之间，信任是合作的基础。

而超预期交付是能加速信任建立的一种有效措施。