大家好，我是若川。今天推荐一篇95年的博文的文章。他的故事应该挺多人知道。如果不知道可以看他的博客 https://github.com/berwin/blog

点击下方卡片关注我、加个星标

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

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

1. 关于“思考”

• Mentor：你平时周末都做些什么？

• 我：没事的时候通常会看看书，写写代码，研究一些自己感兴趣的东西

• Mentor：可以把一些平时做事的时间换成什么都不做，坐在那“思考”，想一些东西

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 稳定发挥

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

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

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

4. 求同尊异

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

最开始，为了帮助团队成员“提升个人写作”、“提升表达能力”、“提升个人技术成长”，我提出了文章计划，团队成员每个人大概每5个月写一篇文章，同时发明了 “贝利体系” 作为奖惩机制，每人每月按照一定的数量自动掉贝利，贝利掉多了需要接受惩罚，发表了文章后奖励贝利，只要保证每5个月写一篇文章贝利就不会达到惩罚线，具体数值都是我计算好的，并写了段程序自动执行，拿到手里的贝利可以用来兑换一些礼物，有HHKB、AirPods等可以兑换。

后来“文章计划”受到了大家的集体挑战，觉得给大家造成了非常大的压力和负担，“文章计划”就宣告结束，不过 “贝利体系” 被我保留了下来，虽然不强制大家写文章了，但依然鼓励自愿写文章的同学，并给予贝利奖励。

这时我对贝利体系进行了一些思考，并重新定位：“衡量体系”，衡量团队成员对“团队建设”、“组织文化”、“横向贡献”的贡献值，助力团队和文化的横向建设。简单来说，就是所有对团队横向有付出的同学，我都会按照贡献的大小付出的多少来奖励贝利，且有一个排名，排名高代表横向贡献多，我会给予贡献多的一些同学发一些礼品，贝利本身也可以自行兑换礼物：HHKB、AirPods等。

我希望贝利体系和团队横向的事情，例如：团建、招聘、安全生产、写文章、技术分享、对现有产品提改进建议、组织大家健身、组织大家玩桌游等有更深度的结合。

因此，有一天，我提出一个想法：让贝利少的人举办团队的团建，并给予举办团建的人奖励贝利，主要考虑给团队横向贡献少的同学多些机会做些贡献。且在团建过程中结合贝利有一些有趣的玩法，例如可以按照贝利的多少设定初始装备（贝利高，团建玩游戏时略有优势，但又不失平衡）。

但这个提议被团队负责团建的同事拒绝（因为他认为贝利不客观公正，无法客观衡量谁贡献少）。当时我觉得这是一个对团队有帮助的好事，可能它暂时不完美，但我会持续优化，我是在“坚持做正确的事”。而且当场我问同事觉得哪里有缺陷需要改进也说不上来，再加上我觉得自己在做正确的事，在让这个团队变得更好，所以我就和同事大吵了一架，对，我又双叒叕和人吵架了，而且这次格外激烈。

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

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

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

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

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

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

后续：

这件事之后，现有的“规则”我都通过匿名调查问卷的方式投票决定，调查大家认为哪些应该奖励，应该奖励多少，哪些不应该奖励，并根据调查问卷的结果进行了修改。

所有的规则，完全由匿名投票大家共同决定，规则制度“公开透明”，由全体成员“共同参与”。并且提供了日常的“实名”和“匿名”双通道接收意见反馈，并给反馈意见的同学奖励贝利。获取贝利和消耗贝利的方式也变得更加的多样化。且这些新的多元化的获取和消耗贝利的方式都是由团队成员大家共同贡献出来的。经过一系列的调整，整体认可度相比之前有了很大的改善，贝利体系在向着更好的方向迈进。

年前也按照大家的贝利数量给大家发放了同等价值的礼品，并启动新一轮周期，大家都很开心。

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

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. 总结

不知不觉，来阿里已经一年了。这一年是我近几年来成长最快的一年，自己的思维和想法，都有了质的提升。非常感谢舒文把我带到这个团队，以我的学历正常很难进到这个团队，经常感叹自己真的是凭运气遇到贵人。还非常感谢墨冥（我的主管），这一年来不断地言传身教并给予机会试错，这一年来的成长（可参考这两篇文章《畅销书《深入浅出Vue.js》作者，在阿里淘系6个月的收获成长》，《畅销书《深入浅出Vue.js》作者，在阿里淘系1年的收获成长》）绝大部分来自墨冥的教导，再次感叹自己的好运气。

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

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

学会坚持，“长时间的积累”永远比“为了短期高收益频繁切换”收益高，无论是“日常做事”、“投资”还是“职业规划”、“人生规划”等。

舒文经常说：“做成一件事情”有很多因素，“坚持”是成本最低的一种。

最近组建了一个江西人的前端交流群，如果你也是江西人可以加我微信 ruochuan12 拉你进群。

今日话题

略。欢迎分享、收藏、点赞、在看我的公众号文章~

一个愿景是帮助5年内前端人走向前列的公众号

可加我个人微信 ruochuan12，长期交流学习

推荐阅读

我在阿里招前端，我该怎么帮你（可进模拟面试群）

2年前端经验，做的项目没技术含量，怎么办？

点击上方卡片关注我、加个星标

················· 若川简介 ·················

你好，我是若川，毕业于江西高校。现在是一名前端开发“工程师”。写有《学习源码整体架构系列》多篇，在知乎、掘金收获超百万阅读。

从2014年起，每年都会写一篇年度总结，已经写了7篇，点击查看年度总结。

同时，活跃在知乎@若川，掘金@若川。致力于分享前端开发经验，愿景：帮助5年内前端人走向前列。