| 概述 | 预计耗时 | 预计发布 | 实际发布 | 最后一次修改 |
|---|---|---|---|---|
#高效工程师所需的成长环境
在互联网行业中，工程师是利用程序代码解决业务问题的角色。在这个过程中，我们会遇到很多需求。有的需求可能只是要你改个字段，有的需求可能要你出份数据报告，也有的需求可能要你花上好几个月的时间，将算法模型落地到业务场景。更多时候，我们需要对需求进行甄别和排序，特别是从初级到资深这一过程，我们不再是单一的接收需求，而是需要辨识需求，掌握自己的主动性。
在上一篇文章里，我们总体陈述了高效工程师需要理解的三个要点。今天我们从思维出发，展开讲讲什么样的思维叫正确思维。这里将包含三个要点，分别是：聚焦高杠杆活动，优化学习以及常去更新优先级。
聚焦高杠杆活动
在我职业生涯的早期，时常遇到一些无法抗拒的需求。简单来说就是，这个需求很急因为这是某个总监想看的；但是又不那么重要，因为你今天加班加点弄出来了一周后都没人看。当时的我碍于组织氛围，不太敢表达自己的想法，导致整体效能低下。后面经历多了明白了，其实好的工作环境是需要良性互动的。如果你觉得这个需求不合理，你做了和没做，并不会带来多大差别，就应该和需求方、和上级好好谈论这件事。如果没有回旋的余地，一方面可能真的是有你没看到的点很重要，但如果给你需求的人讲不清楚，那将更多是他的失责。
以上说了那么多，想表达的核心点就在于：大家都是成年人了，需要对自己的表现负责。无论这个需求是别人挑剩下的，还是由于沟通不畅导致的非必须需求，你有责任去澄清它。用杠杆去衡量产出。想一想如果自己不做这个事，可以做其他产出比更高的事情吗？如果有，就去争取它。拒绝低效活动，是对自己负责任的表现，也是对组织负责的表现。
我们可以有很多方式，去聚焦到高杠杆的活动上。为了使得我们的开发效率更高，我们可以将过去的开发经验总结成pipeline以复用，也可以通过自动化测试，提高交付的效率。在做一件事时，考虑其杠杆有无可能更大。做了这个项目，可否抽象迁移到下一个项目。同时，去关注客户的真实需求。如果你的产品交付千万用户，那就去关注客服团队用户的真实诉求。如果你的客户是内部团队，那就去团队内部收集真实的一线反馈。这些都是为了聚焦更高杠杆的活动。
优化学习
没有人从大学毕业后，可以自信地说自己掌握了职业发展的所有技能。终生学习是一种态度。学习这件事也存在复利效应，越早去积累，到了后期其作用放得越大。
寻找能提供成长的环境
很多朋友在换工作时，会综合考虑公司的环境。除了公司的价值观一类，也会考虑要去的团队是否能够提供成长的环境。寻找能够成长的环境，也是优化学习的必备一环。
总体而言，我们可以将成长环境划分为六个维度。分别是增长维度、人员素质、培训角度、坦诚维度、节奏维度以及自主维度。增长维度主要看产品的商业指标增长状况。团队能否提供显著、有效的业务支持。同时，也关注团队能否将优秀人才提拔到管理岗位的能力。人的维度，则主要看面试你的人看起来比你聪明吗？能从他那里学到东西吗？面试内容严密符合逻辑吗？培训维度则关注，进入公司后，能否提供清晰明确的全职划分，新人指引是否到位。会配备指导关系吗？人员是否有持续成长的机会。
另外三个维度，坦诚、节奏以及自主，是我之前有体会但是很难抽象出来的概念。原作者作为团队leader，将其很好地总结了出来。坦诚维度，关注团队内部信息流通、关注团队自我学习和纠偏的能力。例如团队成员知道团队的优先级吗？在新功能上线后，有复盘活动进行回顾吗？知识和技巧有文档可循吗？团队从过去学到了什么？节奏维度，关注团队的迭代速度与活力。团队从想法到交付需要多少时间？团队使用何种工具加快迭代？自主维度，关注团队的灵活性，这会影响工程师自主性的发挥。团队成员有选择项目和选择怎么做项目的权力吗？工程师会参与产品特性评估会吗？
问完上述六个问题，能够很自然地判断，当下的环境是否是真的能够提供成长。
在工作场景改善技术
当我们确定当下团队能够提供成长环境，接下来要做的便是利用这个场景去提升自己。首先做到熟练掌握编程语言，尽可能多写代码。不要一开始很飘，写代码不多的技术管理，对于团队将是一场灾难。掌握好基础技能十分重要。深入那些难以理解的代码范式，去吸收和学习别人优秀的编码风格。如果可以，将你的代码提交code review。
确保团队内有比你厉害的工程师，向团队内最好最厉害的工程师学习。除了自己在做的项目，团队内一定还有其他进行的项目。没关系，去参加你感兴趣的项目研讨，去拓宽自己在做的项目类型。
工作之外精进
除了工作，我们还会有别的个人发展的需求。在业余时间去学习新的语言、新的框架。也去多了解时下最热门的职业技能。多阅读、多去参加研讨会。在各类活动与会议中，去构建并维系属于自己的社交网络。关注学习类的博主（例如我），也去尝试做一些学习分享。思考并实践side project，去追逐你所爱。
常更新优先级
作为工程师，我们手上的需求可能会有很多，常常让我们抓不住重点。这里优先级就将发挥它的作用。写下并审视你的优先级。
在能产生直接价值的地方下功夫。在职业生涯，数据挖掘这类工作，会有很多分析报告与画像标签的活。当时的背景下，犯过一些错误。在当时的组织背景下，会很关注交付的量。其实这是完全没必要的。我们更应该聚焦交付用户的价值。例如我们交付了多少产品，商业指标改善了多少，支持了多少高优先级项目。这些有一个共性，能够直接带来结果。而与之对立的，则是我今天又工作了多少个小时，完成了多少上级交代的任务，写下了多少代码，参加了多少会议。这些常常被一些管理无能者作为考核指标，但其实完全没有必要，软件开发不是流水线生产，关注交付价值才是核心。
为了我们能够更好聚焦高价值项目，还应保护我们的执行过程。保护我们的排期不被其他事项切割，保持专注减少同时进行的项目。利用“如果，就”来绑定习惯，对抗拖延。最后将更新优先级作为习惯。
小结
树立正确的工程师思维，是我觉得读下来收获最大的。其核心观点在于杠杆，利用杠杆聚焦产生直接价值的事，最大可能放大工程师的影响力。选择提供成长的环境以及终身学习的观点，也令人印象深刻，对我们择业和打造高绩效团队，有很好的参考意义。关注并订阅这个系列，将有用的内容转发给朋友，喜欢的话点个赞，高效工程师咱们明天接着讲。