畅销书《深入浅出Vue.js》作者，在阿里淘系1年的收获成长

作者：玖五

时间好快，眨眼间，加入阿里已经一年了。这一年发生了很多事，整体上非常地充实且精彩，在一件又一件事情中，我不停地犯错，一路走来，步履蹒跚，也收获到了很多成长。每次结束一件事后，经过短暂宁静的生活便再次踏上新的征程。

之前写过一篇《畅销书深入浅出Vue.js作者，在阿里淘系6个月的收获成长》，因此文本主要讲述“后半年”收获的成长。

1. 关于“思考”

以上对话来自一次我向导师询问的一个问题：“我应该如何再进一步，7和8的区别是什么”（大致是这个问题，原问题记不清了?）。

7和8之间就级别本身的区别优势是 “可以调动更多资源”。之所以需要调动更多资源是因为需要做更复杂的事。复杂的事哪来？“思考得来”，当然也可以靠主管分配，但谁又能保证主管一定会把那个机遇分配给自己。

完全靠主管分配机遇，这也违背我内心一直以来所坚定的信念：“让事情因为自己而与众不同”。今天能通过面试进入到阿里巴巴的同学，能力都不差，主管把机遇分配给另一个人绝大概率拿到的结果不会比我差多少，一件事情究竟是因为我去做才拿到好结果，还是大家去做都能拿到好结果，不太好说，这达不到**“让事情因为自己而与众不同”**的标准。

只有自己凭空创造出的机遇并最终拿到了结果，才符合**“让事情因为自己而与众不同”**，也更能展现出自己的水平。

所以一个更可靠的发展路径是：

1. 多思考项目未来的发展方向和现有技术体系的问题

2. 做判断并按照正确的方向执行

3. 事情足够大就会衍生出调动更多资源的需求

4. 时机成熟后，可能会晋升到下一个级别以方便调动更多资源

这会衍生出一个新问题，“如果自己思考的项目未来发展方向和大团队方向不一致怎么办？”

其实不用担心，可以和主管多沟通对焦，如果自己思考得来的方向客观事实上是正确的方向（各方面受益都更高）或者是绝大多数人都信任是一个正确的方向，那么正确的方向一定会替换掉错误的方向。

2. 技术与业务两条腿走路

一定要 “技术与业务两条腿走路”。这是我主管和我导师对我的忠告，当两个经验丰厚的大佬不约而同地给了相同的建议，足以证明这句话的分量，这也引起我深思。

自从我开始工作，我都是只搞技术，我对业务其实不太感兴趣，我很崇拜那些知名的技术很强的世界顶级工程师，一直以来我的梦想都是想成为他们中的一员，想成为前端行业技术吊炸天的世界顶级工程师。

但现在我渐渐意识到，不能只搞技术，也要多思考思考自己的业务，这对自己是有好处的，对业务多思考的好处是：

1. 提前对技术体系做布局，引领技术与项目，避免业务突然变化时陷入被动

2. 对现有支撑业务“较为成熟”的“有瓶颈”的技术体系做出改革与突破

3. 避免让自己成为“工具人”

让“技术”和“业务”互相成就彼此，共同成长。业务发展倒逼技术改进，技术改进成就业务，相佐相成。身为技术同学，可以基于对业务的预判用技术落地项目辅佐业务，业务的成功再反过来成就技术。

千万不要陷入到一个巨大的误区：技术的自嗨，其实并没有多大贡献。

所有伟大的技术创新，都是那些对社会有巨大贡献的技术，伟大技术的诞生，都是基于一个不被满足的“需求”，基本上伟大的技术都是这样被创造出来的（Git、React、Vue又或是支撑公司业务背后的技术体系）。

只有对业务足够了解，思考的足够深，才能知道用户需要什么，才有可能引领未来支撑业务的技术体系，才有可能创造出改变世界的伟大的技术。

一门心思只搞技术，很难做到“引领”和“创新”。大概率只能做到学习现有已被其他人创造出来的技术，学到精通，成为某领域专家，但很难引领某个技术领域。

3. 稳定发挥

发挥稳定型（线性增长）选手比阶段性发挥波峰波谷选手更有优势，稳定（可预测性）本身就是一种优点。发挥不稳定的选手，缺点是不可预测，换位思考如果自己是主管，有一件很重要的事，你敢交给发挥不稳定的选手么，万一碰上发挥较弱的时间段，就悲剧了。

这个道理，在电子竞技、体育竞技等领域都相通，发挥不稳定是不可能拿到冠军的。

刚进入一家公司，在一个新环境都会有点着急，急于拿到成绩得到认可，这本身其实是件好事，但不要把劲使大了，把自己变成了那个波峰波谷型选手。放轻松一点，少使点劲，让自己线性成长稳定发挥。毕竟，职业生涯本就是一场“没有终点的长跑”，大家比拼的并不是短期内谁跑的更快，而是“坚持”，在这条赛道上能跑赢的，不是那些跑得快的人，而是为数不多坚持跑的人，他们能跑赢，只是因为还在跑。

4. 求同尊异

某一刻，我终于理解了这四个字，这要从一件事说起。

我对自己进行了深度的反思，“贝利体系”打被我凭空创造出来之后，无论是面向用户，还是面向合作方，都不是很受欢迎。面向客户，团队成员觉得这是一种压力和负担。面向合作方，团队横向负责人没有与贝利体系合作的动力和需求。这件事本身不是大事，但做这件事却非常难，贝利诞生到现在一直被大家抵触，被大家无视，还有人觉得这是几个人之间的小众游戏。

但我又不想放弃，我想让我们团队因为我的存在变得不一样，而我又坚信这是正确的事，是一件好事。为此我和主管聊了两三次，学到了一些知识和做事的方法，总结提炼出精华：

• 不要以自己为中心去思考问题，要换位到“团队视角”，“合作视角”全方位立体多维度思考问题

• 推进事情要考虑：“共赢”，“利他”

贝利体系诞生以来，所有的“规则”（包括哪些贡献应该奖励，奖励多少）都是我一个人定，大家内心是“不认可”的，因此外在表现就是“你自己玩你自己的，我不参与”。换位思考，每个人都会抵触自己“不认可”的事情。

这一刻我终于体会到，也理解了什么叫**“求同尊异”**，每个人都不一样，也不是所有人都和自己想法一样，要尊重不同的建议和声音。一件事，只有大家认可了才能赢得尊重和成功，要赢得客户的认可，赢得合作伙伴的认可。

后续：

这件事虽然不大，但是它教会了我 “如何推进事情”，未来我大概率会打破现有已经“成熟”甚至“固化”的技术体系，为现有技术体系做一些改进，让它变的更好，那么推进并赢得大家的“认可”和“尊重”与这件事是相同的，通过这件事，我提前得到了锻炼，这是无价的宝藏。

5. 身为PM如何做事

感谢主管的培养和信任，不止给我很多试错空间，还在我犯错后教我如何做才是正确的做法。

5.1 “风险”和“进展”及时同步

关于风险同步在《我在阿里半年收获的成长》有提到过，最近又有了新的感悟：不要担心“做的不好”或“不完美”而不敢同步进展和风险，因为“差的信息”比“没有信息”要好很多！

及时同步“风险”和“进展”的好处是：如果真的做错了，会得到及时的纠正和帮助，可以保证项目是安全的，项目安全永远是第一位。不要担心大家会觉得自己菜，自己菜不菜根本没人关心，大家关心是：

1. 项目能不能“按期”、“高质”交付

2. 你是否在成长

哪怕中途做一步错一步，也比中途“毫无音讯”强无数倍。 即便是中途做一步错一步，但由于及时同步了风险和进度，在不停地犯错中一点点把项目做好，最终大家也会看到自己的成长。会对自己很放心，下次类似的事情交给自己会让人安心，因为再差再差，自己也不会把事情搞砸。

5.2 线上问题如何应对

线上出了事故后，立刻向上汇报，不要自己先闷着头去修复！避免业务方找过来时主管完全不知情，这种情况整体都会很被动！

反馈问题的方式：

1. 站在用户视角描述发生的问题

2. 影响面预估（面向用户的影响面，不是判断技术哪里报错，判断不清楚默认当做重大影响处理）

3. 处理策略

4. 如果有原因，提供原因

5.3 不要把自己当做唯一的资源

当接到一个任务后，首先考虑的是 “怎样把这件事做的更好”，“谁来做更合适”，不要把自己当做唯一的资源。

合适的事让合适的人来负责，接到任务后第一个想的是如何把事做好，谁来做更合适，如果自己擅长某一块可以自己去做，如果某一块有更合适的人选，那就应该找到合适的人来做，而不是自己去做。

5.4 “悲观”态度给答复

如果评估不准某个功能是否可以按期上线，一律按 “悲观” 态度给反馈（本质其实是：提升专业性，预判风险，做好预期管理）。新手PM都会犯一个错，那就是，虽然心里感觉大概率在Deadline前开发不完，但还是会和产品说：“我试试”。

我见过的，除了我还有新手PM也犯了这个错，那就是一句：“我试试”（觉得大概率来不及，但还是和产品说感觉来不及，但我努努力试试）。最终没有按期上线时产品就会找过来问为什么没有上线，“不认可”这个结果。

所以，如果评估不准，或感觉有风险，一律给悲观答复。如果一开始有来不及的可能，在一开始就给来不及的**“明确反馈”**。

5.5 做技术判断

技术PM最重要的核心竞争力和职责叫做：技术判断。像双11这种级别的大促，每个功能所涉及的上下游链路都会非常复杂，横跨N多个团队，这就意味着，同一件事，可以有N种解决方案，而不同团队看待问题的视角不同，因此大家给出的方案和倾向性很多时候会有冲突，这时候技术PM要做的就是给一个技术判断，方案1、2、3、优缺点是什么，让高年级同学拍板。而不是把一个问题抛上去让高年级同学们想方案。因为信息是越底层知道的越多，越上层对细节的信息越少。

6. 总结

不知不觉，来阿里已经一年了。这一年是我近几年来成长最快的一年，自己的思维和想法，都有了质的提升。非常感谢舒文把我带到这个团队，以我的学历正常很难进到这个团队，经常感叹自己真的是凭运气遇到贵人。还非常感谢墨冥（我的主管），这一年来不断地言传身教并给予机会试错，这一年来的成长绝大部分来自墨冥的教导，再次感叹自己的好运气。

相信未来，我会在实战中承担更大的职责，相信未来，我会让我们团队因为我的存在变得不一样。

最后，在舒文身上学到了一个原则，特别认同：