我在阿里半年收获的成长 #50
Assignees
Labels
Comments
|
虽然不在大厂，但自己也在做一些改变，正在尝试从开发的思维惯性中跳脱出来，多换位思考，从主人翁的角度来思考问题、解决问题，而不是做一个只会被动接受需求的 虽然说觉醒的比较晚，但是现在开始行动，总比不行动好😊 |
|
很受启发。我决定每隔一段时间来看一遍博文大佬的博客。 |
|
“虽然通过了试用期，但得到的反馈是对我的表现没有超出预期，我的执行力虽然很强，但我 “没有对现有技术体系带来变化”。”这，我觉得，好吧，大公司要求就是高 |
|
其实作为Project Manager, 与技术架构差异最大的一点，其实就是情商高，博主的方方面面无不佐证着这句话，但是话又说回来，Project Manager如何带动下面的团队，让下面的人信服这是件难事 |
之前一直以为努力码好代码，沉浸在 01 世界，做好自己就可以了。可是做到后来发现，无论什么时候都是需要和其它人打交道，不可能一个人hold住所有🙌 |
Open
|
思路清晰的表述, 读起来就是舒服, 这篇文章是我一直寻找和喜欢的风格 |
Open
|
厉害 |
|
想问问大神的成功是否可以复制，不怕吃苦哈 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
我在阿里半年收获的成长
回想起年初刚来杭州那会，是疫情正严重的时候，那时候刚来杭州要住半个月的酒店，然后才能进入阿里巴巴溪西园区（后续简称”园区”），时间过得飞快，一晃已经来杭州半年了，这半年经历了很多，也学到了很多，写一篇文章总结下这半年来自己的成长。
1. 勇于挑战权威
记得当时刚来杭州时，心情是非常忐忑的，对未来非常憧憬，能和那么多很厉害的工程师一起工作是一件特别爽的事，再加上我们团队是做双十一大促会场的，咱们技术人都知道双十一对工程师来说意味着什么。入职后，一大堆技术名词和各种技术体系铺面而来也确实让我感受到了技术的强大，所以就一直以学习的心态在了解和接触现有的技术体系。
进入园区后第二个月就开启了618战役，感谢主管墨冥的信任，当时我承担了一个非常重要的专项PM（Project Manager），它在整个618战役里都算是风险和挑战都非常高的专项，也是因为这件事干的还不错，上线后非常稳定，因此我获得了618战役奖励优秀PM的一个“厉害了Work哥 - 此时此刻非我莫属”奖，奖状在淘宝楼里挂了三四个月，“入职不到3个月就获奖” 应该算是比较值得自豪的事了。
说这个当然不只是为了显摆，就在我以为自己表现非常好的时候到了转正面试的时间，虽然通过了试用期，但得到的反馈是对我的表现没有超出预期，我的执行力虽然很强，但我 “没有对现有技术体系带来变化”。
换句话说，招我来的目的不是来当资源的，618战役虽然打的不错，但说实话换个人上去又能差到哪里去？大家对我的期望是对现有比较成熟的体系带来变革。
那怎么对现有体系带来变革？经过大家的引导和我自己的思考，答案是：”发现现有体系的问题“。我刚来觉得这里技术体系特别牛，加上沉淀了这么多年的双十一，已经是比较成熟的技术，觉得这是一个权威，不可能有问题，所以一直抱着膜拜的想法在了解和学习现有体系，所以这就是问题所在。
这时候我学会的最深刻的一个成长是：“要勇于挑战权威，发现现有技术体系的问题，并解决它。”
2. 身为PM如何推进事情
感谢主管的培养和信任，给了我很多试错空间，入职到现在这半年时间从第一次当PM到现在，犯了很多错误，在一次次犯错后也学习到了很多当Project Manager的知识，本小节将这些成长总结起来分享给大家。
2.1 解决合作阻碍
在推进项目时，有时会遇到一些阻碍，例如：不配合，难合作，主动性差等问题。绝大部分能来到阿里工作的同学不会是“能力”或“态度”问题，所以大部分阻碍可以归结于：
解决障碍，就是在解决以上这三点，信息不一致可以靠“沟通”和“换位思考”解决，而“目标不一致”和“优先级不一致”可以靠“上升”解决，只要事情足够重要，给出几种解决方案，上升到某个级别问题一定会被按照最合理的方案解决。
2.2 建立自己的权威
入职大概三个月左右的时候，我发现PD（产品经理，在阿里巴巴我们称为 Product Design，即：“产品设计”）在与我合作的过程中对我是有点不信任的，例如：相同的答案PD会相信我师兄和主管、我给了方案后PD会再去找我主管询问是否有更好的方案等。这也让我有了很多成长，当时我还特地去向二级主管请教一些方法。
2.2.1 拉人佐证自己的判断
案例一：在没有建立起自己的权威前，很多时候PD并不相信我给出的方案。那么这种情况解决方案是：假设有3种方案，将各自的利弊信息同步给PD后，如果都不满意，可以拉其他人，例如拉自己的主管进来，佐证自己的判断。（但前提是自己要做好功课，先和主管沟通好达成一致，再将信息同步给PD）。
案例二：假设现有两种方案各有利弊，完美的方案需要团队A配合，那么可以拉着自己的PD去和团队A的PD谈（前提是要先和自己的PD达成一致，并且以自己为主导拉PD只是来佐证自己的判断），一方面向团队A的PD佐证自己提的需求是重要的，另一方面也可以向自己的PD佐证这个需求确实没那么简单。如果事情推进遇到阻塞，回到2.1小节，最终问题一定会被解决。
2.2.2 资源不足而PD说我都要怎么办？
先和主管达成一致，客观评估需求是否真的重要到需要拉其他同学来帮忙开发，在一个更宏观的角度评估哪个需求优先级更高，然后再给PD同步结论，如果不接受拉主管进来还是相同的结论，再不接受再拉主管的主管也是相同的结论。权威就是在日常这样一点点建立起来的。
2.2.3 与PD合作的艺术
回到最初的问题，PD为什么要找我主管寻求帮助？
本质上是我还没有建立起自己的权威，另外PD是信息弱势方，所以如果我给出的方案她不满意时，她会去找她更信任的人寻求帮助看是否有更好的方案，那么如果这时真得到了一个更满意的方案，那么她会觉得这招管用下回还会再去，这时候我的权威就会崩塌。
解决方案是：提前做功课给到PD的信息永远是权威的判断，在不信任自己时拉人佐证自己的判断是对的，或者和PD一起去找其他人继续推进&解决问题，逐渐让PD意识到即便是找了其他更信任的人也会得到相同的结论，我的结论就是正确且权威的。
2.2.4 积累自己的信用
作为新同学，可能会发现同一件事，同一个解法，PD经常会不信任新同学。
这里日常工作本质上是累积信用和消费信用的过程，解决方案是：在日常工作中一点点累积自己的信用，当机会来临要勇于消费信用去推动事情，这也是体现“此时此刻，非我莫属”的阿里巴巴价值观。
当然，打了败仗，信用也会消耗，经常打败仗即便不是新同学也很难让人信任，所以还是要靠自己的本事来积累信用并建立权威。
2.3 项目风险同步
这半年时间，关于风险同步我犯过两次错误，这两次错误也分别让我学到了两种关于项目风险的经验。
2.3.1 风险同步：Case 1
事情发生在今年的88大促，当时我为会场底层渲染架构全新升级了一版，在一个极短的时间用新开发的2.0追上了正在运行的1.0的大部分功能，然后在88大促切换到2.0，可以类比在天上给飞机换引擎。切换2.0后如预料中的一样，出了一些小问题。
问题在于，给飞机换引擎这个动作和行为，我没有通知给业务方，导致出了问题的时候，业务方很惊讶，为什么之前一直好好的这次突然出了这么多问题？业务方对这个事没有任何预期。
在这件事上，我学到的是：在做一件事时，要通知到所有可能会因为这件事而受到影响的人，把自己的计划，方案，风险等信息完全同步给可能会受到影响的人，好处是：
2.3.2 风险同步：Case 2
事情的背景是，有一次我负责一件事，这件事在过程中我发现进度有延迟的风险，但当时我选择了自己抗下来，加加班，赶赶进度。后面我低估了这件事的严重性，导致最后实在扛不住了才暴露风险，紧急加人解决了这件事，虽然这件事没引起问题，但是这个最后临门一脚才暴露风险这个行为是不对的。
通过这件事，我也学会了如何做事是对的（感谢主管孜孜不倦的教导），暴露风险不是懦弱和能力不行的体现，暴露风险是一个PM的专业素质，不要自己硬扛风险和压力，过程中有风险需要帮助应及时提，避免到最后扛不住才将风险暴露出来。
2.4 误区：不敢上升和暴露风险
新人入职都会进入一个误区：
现在我可以很明确的告诉大家，不是，完全不是！
推进项目受阻有很多原因，绝大部分都不是自己这个位置能解决的，上升是非常高效的解决方案。
项目遇到风险也是同样的道理，除了确实是自己能力导致的风险以外，绝大部分风险都是客观存在的事实，和自己能力没关系，即时且充分暴露风险寻求资源解决风险才是王道，这反而是一名专业的PM应该具备的基本素质。
3. PM的职业素养
PM的目标只有一个：“确保项目按时保质上线”，但过程也同样重要，阿里巴巴有句土话我很喜欢：没有过程的结果是“垃圾”，没有结果的过程是“放屁”。
在推进项目的过程中，一名合格的PM需要具备的基本素养是：
内心时刻铭记一句团队内广为流传的名言：所有关于事的困难可以靠坚持解决，所有关于人的困难可以靠换位思考解决。
3.1 关于情绪控制
项目复杂且生产关系也复杂的时候，会遇到各种困难和阻塞。沟通工作时很容易情绪失控，但身为一名合格的PM，任何时候，不应该被情绪控制自己的判断。
任何时候，都应该基于客观事实理性分析问题，不应该带有主观的执念。
这也是未来我要加强训练的一点，过去这半年，我经常情绪失控，未来我会克服这一点，做一名专业的Project Manager。
3.2 关于方案评估
评估某个方案是否可行，不应该只是评估技术上是否可行，还要考虑按照这个方案推进后，会带来怎样的影响。
关于这点我曾犯过一次错，在技术方案的评审上，我只判断了技术的可行性就同意了某个方案，但是我没有考虑按照这个解决方案推进后会带来很大的其他影响。后面我师兄及时制止了这件事的发生，但是已经答应了PD按照某个方案推进结果又反悔，对于我这种新人甚至是我们团队在PD心中，都是非常消耗信用的一件事，“积累信用可能需要好久，但消耗信用，仅仅只是一次无意间的失误”，要珍惜自己的信用，“信用”，才是PM推进事情时的通行证。
3.3 避免无意中踢皮球的情况
客户（运营、产品、其他人）有疑问来向自己咨询的时候，即便不是自己负责的域，也不要直接和客户说你去找谁谁谁。正确的做法是先把问题揽下来，然后团队内部找对应的同学拉个群解决。
我就曾遇到过这种被踢皮球的情况，我有疑问找了A，A说让我找B，B让我找C，C说他不负责这事，然后我直接找了他们共同的主管，问题解决。
我知道他们不是故意踢皮球，但在我找不到他们1号位是谁的时候，用这种方式对我来说是最快速解决问题的方案。这首先对于客户的体感不好，另一个是我向他们共同的主管寻求帮助后，他们的体感也不好。所以，要有owner心态，“让业务方幸福，让主管信任”。
4. 前端工程师的职业素养
前面说了很多关于PM我犯的错和收获到的成长，那么作为一名前端工程师，这半年也收获了一些成长。
4.1 做一名有“标签”的人
要做一名有标签，有特色，有影响力的人，在公司工作了一段时间后，在人们心中不应该只是一名“前端工程师”，应该是一名XXX的前端工程师。
标签应该自己去努力获取，有两个标签是我现在在努力获取的： “双十一前端PM” 和 “不到30岁的P8”。
4.2 让事情因为自己而与众不同
一个灵魂拷问：今天我负责的事，我做完和其他人做完有什么不一样？今天我作为Project Manager负责某个项目，如果换做其他人来，会有什么区别？
今天获奖也好，得到一个好绩效也好，真的是因为自己做得好，还是因为主管把自己放在这个位置得到了更多的资源所以做得好？如果把其他人放到这个位置，和自己会有什么区别？这是一个值得思考的问题。
一个特别大的误区是：认为自己技术好，所以比其他人做的好。今天能进阿里的同学技术上都不会差，再加上大部分工作都不是去造火箭，所以 “技术好 !== 拿到好结果”，技术好会增加拿到好结果的概率，但不是一定能拿到好结果。
所以，要让自己负责的项目，因为PM是自己，而变得不一样。要让自己的团队，因为自己的存在，而变得不一样。
4.3 学会换位思考
换位到更高维度思考，很多时候不理解的事就理解了。换位到合作伙伴的维度思考，就理解他为什么会不配合，难合作，主动性差。换位到客户的角度思考，就理解她为什么会不信任自己。
还是那句话：所有关于事的困难可以靠坚持解决，所有关于人的困难可以靠换位思考解决。
4.4 沟通的艺术
这是有一次和主管聊天中学到的，和人沟通，一定要学会聆听，解决冲突或问题时，第一步是“聆听”，先聆听，充分了解信息后，再基于客观事实把事摊开了，并基于客观事实讲述正确的做法是什么，然后再去指点哪些地方可能不足。
如果不聆听就做判断，试想在没有得到足够信息输入时就做判断，判断真的客观么？还是自己主观上有倾向？就算自己对情况完全了解，不需要输入也可以做判断，那信息的输出方会不会认为自己做的判断不够客观？因为自己都没有听他说的是什么就做判断，他一定会质疑自己的判断是否公正。
5. 总结
半年来，成长远不止这些，还是感谢舒文把我带到这个团队，赐予机遇和指导。感谢主管墨冥这半年来不断地言传身教并给予机会试错，相信未来，我会在实战中承担更大的职责，相信未来，我会让我们团队因为我的存在变得不一样。
The text was updated successfully, but these errors were encountered: