团队每年都会来实习生、新人，最后两星期准备转正串讲时候都会感慨“转正好难”。平时循规蹈矩做一些日常迭代需求，团队也没有给留出足够的技术项目时间，PPT 里实在没有可写的东西，本文对转正需要注意的事项做了一些梳理，供大家做参考。
实习期间的矛盾在于，大家既希望实习生可以广泛接触团队的业务和技术体系，这样在工作思维转换和技术能力上都会有均衡的发展；又希望实习生可以 focus 在某个垂直领域，结合业务痛点深入研究，做出些个人特色的改善和突破。不少师兄在第一种思路上尝试一两星期后，在转正的压力下被迫用第二种思路培养实习生，甚至会有拔苗助长的现象。现在回头来看这种焦虑感下的“亮点”期望，既不现实，又没必要。不现实是因为整个团队在本业务深耕了几年，实习生很难在短时间内发现比较明显、并且可以小成本改善的问题；没必要是因为自己作为师兄、主管参加过不少新人转正，也做了几次转正评委，和大家交流下来，发现关于转正大部分评委内心的评判依据是类似的，并不会不切实际的要求什么亮点，而更在意候选人的：
技术思考力
这两条乍一看没什么特殊的，但重剑无锋、大巧不工，在这两个点上出问题会让实习生的转正会遇到评委的“刁难”。事情说的很清楚，你在其中的角色是什么？
这件事情是你想做的，还是主管、师兄分配给你的？
其实这两个问题是在核对上面的标准，不清楚角色是因为在阐述事情的时候没有突出解决问题的过程、难点、应对之道，感觉是在侃侃而谈别人做的事情，自己其实只是其中的一个普通参与者，整个阐述过程没有提现自己的技术实力。第二个问题甚至会让有些答辩的实习生情绪激动，代码从头到尾都是我写的，不信我们来看看 commit 记录。其实评委纠结的是候选人用了完美的方式把问题解决，兵来将挡水来土掩，更像是个团队庇护下不错的执行者，为什么做了这些正确的技术决策，其中的技术思考没有体现出来。
我们经常会忽略大道至简很多时候是因为这些道理听起来毫无新意，甚至近乎废话，这点不用多说，因为试图绕过的时候总会发现处处碰钉子；还有一个原因是道理我都懂，依旧过不好这一生。很多道理需要方法论的指导才能发挥最大作用，业界也有很多成熟的方法论，比较好用的是 STARSituation: 可以理解为背景分析，做一件事情都有前因后果，分析出为什么当下需要做这件事情
Task: 明确整个事情的目标，既要有定性的目标，又要有定量的目标，做到整个事情是可衡量的
Action: 根据目标拆解出具体的、可行的执行策略和执行节奏
- Result: 对结果复盘（总感觉应该是 Result & Review），有没有完成既定目标，过程中有哪些技术沉淀
很多同学可能会困惑，按你这么说循规蹈矩、不需要亮点就可以转正通过了？其实并不是这样，转正的过程是优中选优，自然需要候选人身上有些亮点，但我们需要的是人的特质导致做的事情出亮点，而不是参与了一个重要的项目，做的事情很重要就是有亮点，换句话说需要在看起来最平凡的事情上做出特色，体现个人技术实力和技术思考力，于无声处听惊雷。用个团队最近的例子来说说我对转正方法论的理解，事情的背景是这样的：团队有个技术产品叫七巧板，可以不通过 Aone（发布系统） 发布流程将代码片段同步到应用，很多同事利用这个特性将页面上经常需要变化的内容做到了七巧板；同时七巧板提供了可视化的编辑界面，可以让非技术同学通过填写表单的方式把更新推送到应用，比如 Alibaba 首页上的很多广告内容是运营推送的。因为最近集团安全生产的要求，无灰度不发布，所以给新人安排了一个任务——七巧板接入 changefree（变更管控系统）。
了解七巧板发布的原理
了解 changefree 接入方法
设计实现架构、写代码
配置 changefree 规则
发布界面添加用户提醒
测试
通知七巧板用户要接入 changefree，非窗口期变更要走审批流程
这看起来是一个无懈可击的流程，但如果用这样的思路做出来，作为转正 PPT 中的一部分去讲就会被评委问上面的两个问题
整个事情的目标是什么？
我的用户是谁？
如果我们这样思考了很容易发现第一种思路做事情的问题，我们的目标明显不是七巧板接入 changefree，这是策略。我们的目标是保障七巧板发布的稳定性，做到安全生产。虽然任务交代下来是接入 changefree，这是师兄想好的应对之策，那么我们应该系统的思考一下七巧板不稳定的因素还有哪些？接入 changefree 解决的是哪个问题，其它问题严重性如何？当下要不要解决？最起码可以还原师兄策略的分析过程，映射到上面 的 STAR 法则可以对背景、目标做到清晰的认知，来指导策略的设计。回到执行策略，接入 changefree 是个明确的 action，解决了安全生产的问题会不会有什么副作用？上面提到了发布界面添加用户提醒、通知七巧板用户要接入 changefree，非窗口期变更要走审批流程，这就是其中的一个考虑，但是否全面？我们可以从用户的角度分析。开发：经常对非功能、bug 的修改快速发布。我们做了上述的修改后开发的诉求仍旧可以得到满足，非窗口期走审核流程虽然会让发布过程受阻塞，但根据安全生产要求也是合理的。
运营、PD：可视化修改，快速把广告、营销内容推送上线。看起来仍旧满足，但仔细一分析是有问题的，因为出了常规时间的封网，很多封网是因为大促导致的，而大促期间正需要对广告、营销内容频繁修改。
这样就会发现我们的策略其实是有漏洞的，针对这部分用户的诉求我们可以在做分析，这部分用户修改的代码是固定的，只是坑位的素材发生变化，风险是很低的，我们可以简单得出一个针对策略。封网期间对代码级别变更锁定，可视化内容可以通过一次申请免走审核流程，或者仅仅是主管审批；
虽然事情可能不会当下就去做，但可以体现个人在其中的思考。前面也提到整个的目标是安全生产，那么梳理出七巧板不稳定的因素及后续的计划也是合情合理的事情了。并不是只有落在 Gitlab 中的代码才能体现技术实力，做合理的决定往往是技术实力和技术思考力的综合体现。
很多同学对技术思考力这个概念觉得抽象，我对技术思考力的理解是：面对一个问题的时候可以去思考：这是不是一个问题？现象的背后真正的问题是什么？
这是哪个环节触发的问题？这是哪个环节造成的问题？
有哪些手段可以修复问题？有哪些方法可以根治问题？
这些手段和方法的可行性、优先级是怎样的？
才开始工作时候有个习惯帮助我很多，我经常会试图揣测这个问题如果是我师兄、主管会怎么分析，他们会做怎样的决定，我对每个层级的理解是 P5 解决问题、P6 发现问题、P7 定义问题，P8 可能是创造问题吧，展开一些理解大概是这样（仅代表个人理解，不代表官方定义）：
P5：事事有回声，交代的事情干净利落做完，对既定方案、流程有自己的思考；
P6：独当一面，可以独立负责业务项目、改善技术流程，并且对相似问题有一套方法论；
P7：领域专家、辐射上下游，某一类问题到自己这里终结，领域方案对上下游工作流程都有改善；
总结而言按照 STAR 法则思考自己手头的任务，把任务转为，尤其要注意目标和策略的制定（很多同学容易混淆这两个概念），然后在过程中注意多思考我们的用户是谁，他们的诉求是什么，可以帮我们完善策略。
周报的重要性，一个十几人的团队主管很难有精力面面俱到，了解所有人每天的细节，给大家找出合适方向和机会，很难做到你有一个不错想法的时候主管恰好找你聊聊。很多同学的周报极其敷衍，就是一周的流水账，发送出来都是浪费自己和收件人的时间，团队不会有人认真读完所有人的周报，取决于周报的质量。实习生在这个问题上要比正式员工更注意一下，毕竟正是员工的考核是半年一次，还有路遥知马力的机会，而大部分实习生的的实习期只有两三个月，和主管的主管沟通的机会几乎只有（双）周报。为什么周报这么重要呢，在上面文章中也提到过向上管理，对于实习生而言最重要的是做好对主管的预期管理。在工作中很多时候我们羞于说出问题、表达个人意愿，怕老板觉得自己能力不够或者太自大。但很多时候问题就出在主管对你、做的事情没有预期，出现任何风险都会觉得是突如其来的刺激，如果总是出现心理预期偏差，就会怀疑你的工作能力，无法对工作进度和风险进行有效控制。
做到这些主管会给你安排他认为最合理的工作，也会及时帮你解决风险，可以在短暂的实习期间做出更大的价值。实习生转正、项目总结、晋升答辩，这个句式也许后面要听数十次，每次都特别委屈，我明明做了那么多，怎么就得到一句这种评价！前面也提到了评委经常会问的两个问题，这句话就是两个提问的综合体。说是反击，首先我们要意识到一个问题，当评委问出这句话的时候，说明我们的述职过程就已经出了问题，我们最好的反击不是针锋相对，而是做好前期工作，让评委问不出这句话。前面提到了 STAR，一般情况下评委问是因为我们讲背景和结果用的篇幅过多，讲目标分析、策略执行篇幅太少，又让我想到团队的一个例子：一次大促上线第一天 PD 看到我们的会场页面多语言表现问我，谦行，我们页面为什么有的做阿拉伯语镜像反转、有的没做，有的上面做了，有的下面做了，你们如果资源有限，是不是可以做的统一些？
面红耳赤，和团队一位新同学讨论了一下方案，最终选定了自动构建 RTL 版本的 css 代码解决，业界有一个 rtl-css 的包非常好用，新同学了解了一下接入方式之后，修改代码构建器等前前后后忙活了很多，然后完成了任务，写转正材料时候却犯了难，评委还没问自己都感觉就是用了业务的一个包，没有技术亮点呀。
当下业务有很多问题，为什么这个问题要现在被解决？
问题有多少种可行的解决方案？如何做出选择？
我们重新盘点了一下支持阿拉伯语、希伯来语镜像反转的方案 | |
| Alibaba.com 秉承着马老师“让天下没有没有难做的生意”的使命，支持 RTL 理所应当是正确的事情 |
| - 考虑到流量、转化，RTL 上投入产出比有些低，没有引起足够的重视
|
| - 提供 RTL css 工具包，和方向相关的使用工具包类
- 使用构建工具，根据 LTR 代码自动构建出 RTL 代码
|
| RTL 短期内的产出避讳提升太多，我们需要做的是降低投入，达到 ROI 平衡，这就意味着提供开发无感的方案会更加合理，因此选择了方案 3，其中的 LTR 代码识别转换业界用通用包 rtl-css 可以使用，集成到 build scripts 即可 |
| - 老代码仓库升级：IDE 插件自动检查，老代码仓库一键升级
- 自动构建逃生出口提示：使用说明通过脚手架写入 README
- 老代码兼容：渐进式增强方案，通过 solution 写入 <html dir="rtl">，客户端加载前判定修改，解决异步判断首屏闪烁问题
|
| 是，不只是会场，多个场景都存在人工支持 RTL 的情况，应该在 ICBU 内部形成规范（客户端写入 dir 属性），工具推广到 BU 使用 |
最有技术含量的 LTR 代码识别、转换工作确实是用业务 rtl-css 包实现，但不是有了这个包才有的方案，而是我们制订了方案，这个包满足我们的诉求，可以节省我们的时间才被用到；
- 我们不仅仅是解决了构建问题，还考虑到了老代码升级、自动构建逃生入口、开发一键预览对比、更快的 RTL 判定渲染等方案，这是一个完整的、考虑周到的技术方案升级过程；
纯技术难度可以作为答辩的亮点，做事情思路和执行过程也可以，从某种意义上同样重要，候选人可以举一反三做好后续工作中每件“小事”。这是个回击质疑的简单方法，仅在转正时候用是投机取巧；而在日常工作对待每个平凡的小事都如此思考、行动，不去绞尽脑汁去挑选在聚光灯下的大事才肯用心做，那这就是个人特质，天道自酬勤。
虽然不能确定上面说的是对的，但我知道怎样肯定是错的，也看到过太多实习生前赴后继往深坑里跳。
所有的转正、晋升、项目等 PPT 中最后一部分都是一样的——总结规划。说明这是个很重要的步骤，PPT 最后需要有规划大家都知道，但很多同学在平时做事情的时候会忽略这个环节，事情做完了就是做完了，没有下一步的规划，立足当下，着眼未来这反而是最能体现一个人技术思考力的部分，平时做事情、项目少了这个环节实在可惜。说到转正 PPT，规划总结应该是继往开来的，而不应该是没头没尾，见过不少实习生最后一页 PPT 是类似的模板：深入了解业务，可以独立负责 XXX
学习 React、Spring boot
我们看选秀节目，评委问你的梦想是什么，从来不会有选手直接说：我的梦想是成为明星。你看到这样的回答都会觉得不切合实际，大部分回答是这样的：我有多惨、多不容易（背景 & 问题）
但我多喜欢音乐/舞蹈，我希望 xxx 为我骄傲 （愿景）
不是要大家学习套路，而是说没有来龙去脉的规划会让人疑惑
他为什么会这么想，有这样的规划？
- 达到这样的目标后会怎么样，对团队、业务的影响是什么？
大家可以换位思考一下，今天我们是转正评委或者公司的老板，实习生规划是要做 NodeJS 专家，是不是有点太远？一个理想的模式（模式，不是模板、不是套路）应该是我当下面临的问题是什么，我看到未来业务、团队还有哪方面的挑战，我能力方面还有哪些不匹配的地方，所以我想怎样，然后希望能带来怎样的改变。
谦逊是一种美德，但初入职场不要因此把自己姿态放的太低，无论是外包、实习生、试用期，当加入团队的第一天就是这个团队的一员，团队每位同学都有帮助团队变得更好的责任。当然这很难，从学校切换到职场，了解当下团队的工作流程 & 业务需求已经让人很头大，如何有精力和能力帮助团队？这里面有些核心的原则，也有些简单的方法。Everybody matters, every step counts.
很多实习的同学在实习期间对自己的工作表现很满意，但到了转正的时候被评委说的要哭出来，很大程度是因为把按时完成任务作为满分的标准，有任务的时候很投入，没有任务的时候会觉得清闲。一定要知道完成交代的任务从来不是满分，是及格！及格不是团队对实习生的期望，大家希望实习生可以发挥主观能动性，自己看到问题、想出方案、甚至在某个问题上找主管索要资源，不是要大家加班，但希望大家自己觉得很充实，理想状态是整个银河系要去拯救的感觉 ~~
转正串讲不是一场考试，也不需要我们把做过的事情罗列一遍，重要的是通过几件事情让评委了解自己是如何发现、分析、解决问题的，在团队帮助下理清楚思路，相信对后续的职业生涯都会有很大的帮助。视频化时代，未来80%的数据和计算将发生在边缘，边缘云靠近终端与数据源头，推动端侧算力赋能，助力万物业态革新。本电子书精选了云栖大会边缘云与视频云的系列内容，从战略与产业发展、技术与创新应用、场景实践与生态合作等维度，全方位演绎边缘云与视频云创新融合的极致进化。通过本书，你可以学习到：1.云栖大会演讲合集 2.云栖大会精选文章 3.《边缘云技术演进与发展白皮书》。
点击阅读原文查看详情。
