如何快速适应环境

多几个“点”

以下几个方法，能够帮助你快速成长：

多想一点

在实际开发过程中，需要跳出自己负责的部分，了解业务全貌，切忌偏安一隅。业务整体的目标、策略以及核心诉求是什么？其他人负责的部分是做什么？如果你来做，你的思路是什么，你的方案如何助力业务实现目标？如果有能力的话，从整条技术链路的角度来思考和理解技术和业务，带来的帮助会很大。

多做一点

主动发现并解决问题。如：思考当前方案是否有改进的空间？通过技术手段，是否可以对业务需求进行额外的优化？团队当前的技术栈有哪些需要解决的问题？

多问一点

没有太多技术含量，纯粹因为不了解导致的问题不要过分纠结，多咨询团队里的小伙伴，其他人可能 1 分钟就能够帮你解决 1 个小时都搞不定的事情。但对于自己需要进行的技术设计，不能依赖他人，先自主设计，再由团队的小伙伴 Review 并完善。

多说一点

建立个人影响力，手段包括但不限于团队内分享，输出技术文章等。做好本职工作的同时，也要让其它的小伙伴看到你。

凡事有交代，件件有着落，事事有回音

凡事有交代，是指任务分配过来，必须要能够清晰正确地理解当前的任务，进行合理的拆解和时间安排。

件件有着落，是指每件接受的任务都能够主动推动，快速执行，承诺过的事情，尽可能地完成妥当。

事事有回音，是指每次在完成任务时或过程中遇到问题时，要及时反馈。好处有二：其一，可以让合作方或老板及时的更新任务的状态，提高对完成任务过程和结果的体感。其二，能够尽早的发现问题，从而有针对性的预防并做出应对方案。出现问题不可怕，可怕的是小问题随着时间流逝逐渐积累，变成大问题。

如果以上三个原则能够牢记并加以运用，成为一个让别人觉得靠谱的人，并不难。

看起来简单的东西，背后会有很多很多思考

我们在看其他人的技术方案时，第一直觉往往是并没有什么特别高深莫测的地方，但这通常是由于把复杂的部分留在的内部，暴露给开发者时已经是足够简单和符合直觉的，如果不去刨根问底，仅仅停留在使用阶段，很难理解背后成体系化的设计思路。在业务团队，技术本质上是为业务服务的，技术设计基本都会从效率、质量或体验中的某一角度来入手，因此，要学会挖掘在看似简单的技术实现下解决的痛点是什么，从源头理解技术方案的思考和设计思路。

关于转正/晋升答辩

转换视角

转正和晋升答辩类似，通常分为两部分，述职和回答问题。通常情况下，我们更关注于答辩的 PPT 内容是否丰满，亮点是否突出，但是往往起决定性作用的，是述职结束后的提问环节，leader 的视角会更从更高层次关注实习生的成长。

1.1 从协作角度，是否了解本团队内各自负责的业务，是否能很好地完成和其它各方的沟通和协作。

1.2 从技术角度，是否深度了解团队内各系统和技术方案的设计思路，解决了什么样的问题、设计的优劣等等。

1.3 从业务角度，是否能清晰地获知业务想要实现的价值和我们做的事情有何关联，是否能通过技术手段帮助业务更好地实现目标，以及业务上线后是否对业务数据敏感。

关注时间

一定要关注给自己的时间是多少，10min/15min/20min 能够讲述的内容和讲述的策略都会受很大影响。基本原则是讲最优亮点，最容易让别人记住你的部分，时间越短，亮点内容的比重就越大。

分清楚听讲人和场合

分清楚听讲人的角色很重要，如果听讲人是你的直系主管，那么他对你平时做的主要的事情都有了解，能否抽象并描述清楚你所做的事情，就相对比较重要；如果听讲人是更高一级的 TL，可能并不清楚你负责的业务和具体的技术细节，这是需要更高屋建瓴地讲述你所做事情的亮点，减少细节，突出个人的思考和落地结果，突出你在其中的不可替代。分清楚场合的道理就比较简单了，述职就需要事无巨细，总结就需要抬高视角，晋升就需要凸显亮点。

学会结构化思考，PPT 不是内容越多越好

很多时候我们会担心自己做的事情没办法很好的传达给别人，不知不觉把整个事情拆解出很多张 PPT，以为能够通过更多细节来让听讲人理解，实际情况下，听讲的人是没办法完全集中精力听讲的，会让人感觉抓不住重点，在有限的篇幅内讲清楚同样的事情的抽象能力是不可或缺的。

未来的方向也很重要

很多时候我们只看到的当下有的东西，但很多时候，未来能增加或者完善什么，更重要，也更考验技术功底。无论是规划还是实现时，一定要记住，想想还有哪些可以完善，不断进化的点。技术和业务都是再不断迭代向前走的，我们做的事情就像走路，一直在路上，要经常看看我们希望的终点的方向，不断校准并向前迈进