2019 年在项目中的 commit 记录,一共有 2589 次提交,涉及到 28 个代码库,23 个应用的 344 个需求。

如何和老板沟通

和老板沟通其实是种向上管理的能力。有前辈云,在阿里最重要的两件事:跟对人,做对事。做对事指的是做到好的项目,跟对人就是跟一个好的老板。很多人离开阿里的时候感叹,被 NB 的公司吸引来,被 SB 老板气走。老板不仅决定你的晋升、绩效和奖金,还是决定你工作是否开心、职业道路上是否有成长的重要因素。

  • 及时和老板表达想法

    在阿里老板这么重要,颇有官大一级压死人的感觉。作为“下级”容易有一种思维:老板交代的事情只能执行,即使不太想做,咱也不敢说,咱也不敢问。这样的事如果是小任务可能问题不大,但长期如此,对自己是拖累,对任务是风险。比如刚入职的一段时间我被安排到一个数据运营的项目里面,这个任务技术上只是在前端加一些埋点,剩下的大部分时间是和产品、数据的同事讨论如何调整埋点。这个需求不属于我的 KPI,stackholder 主要是产品,但又有许多没什么技术含量的工作要做,主要是操作阿里的各种内部系统做一些配置,这些系统往往缺少文档或者面临更新换代,易用性、稳定性和容错性都不理想,有较高的上手成本,最重要的是在这项工作中我认为自己得不到想要的成长,这个时候就会表现出来任务进展缓慢,对任务缺少 ownership,在晨会上更新状态的时候只能说到埋了一些点的表面,而不能站在任务视角更新整体进度。老板观察到这种状况,只能做两种猜测:一种是这个人能力不行,交给他的事 handle 不了,另一种是他能力是没问题的,只是不喜欢做这个项目。当你和老板之间有足够的信任的时候,老板的猜测可能会倾向于后者,但如果老板多次尝试你都不 say no 又做不好,老板自然会对你失去信心,这是我们不希望得到的结果。而且老板那么忙,为什么要老板去猜呢?自己说出来不是更好吗,老板分配任务的时候并不是定死了你做 A,给他做 B,也是站在一个统筹的角度,尽可能把任务分配给适合的人做,让老板听到你的声音,其实是帮助老板做出最优选择。所以与其含含糊糊地把任务接下来不好好做,不如主动说,提前说,既有利于自己,又规避了项目风险。老板对你的兴趣了解得越多,你也越容易得到适合自己的任务。

  • 让老板知道你在忙什么

    一个开发团队的杂事是很多的,老板不可能时时刻刻知道每个人在忙什么,这个时候就需要个人对上级有一个主动的工作内容汇报,包括你在做什么事情,进度如何,风险点在哪。千万不要一个人瞎忙,例如帮助其他团队的同事做联调、或者协助设计的工作,这些职责之外的事情,也要透明出来,老板才不不会觉得你上班是在摸鱼。千万不要等到老板质疑你开发效率低的时候再提,尽早避免误会。阿里内部有个写周报的要求,我觉得是一种有用的方式。

  • 主动帮老板做一些脏活累活

    前面两点都是让老板了解你,你也得了解你的老板,站在老板的角度考虑问题永远是利大于弊的。尤其当你的老板是一个技术角色,他的位置很有可能就是你的下一个职业目标。知道你的老板在想什么,解决老板头疼的问题,既有利于提升自己的能力,又有利于提升在老板心中的地位,说的现实些,一个团队的开发大家平时都在写业务,拿什么体现你比别人的工作更有价值?不就是看你为团队多操了哪些心嘛,什么集成测试挂了没人修,代码合并老是冲突是不是该换分支策略了,测试环境部署的时候怎么有宕机时间了,对这些这些看似项目以外的事情关心,恰巧是体现出差距的地方,更不用说老板操心的事情,一定是会让团队发展受阻的,也就是更有价值的事情。

做好并行任务管理

在日常工作中,迭代任务主要是业务需求,除了处理这些需求之外每天往往还会有一些紧急的 bug fix,领导立马要的、客户新提的、产品认为要赶紧上、运营突然想要调整的的需求,诸如此类的临时任务。这些任务我在排优先级的时候有两个原则:紧急的事情优先于迭代的需求,有外部依赖的事情优先于自己能搞定的事情。

  • 异步工作模式,沟通先行

    作为开发日常工作中很多任务是有第三方依赖的,涉及到其他产品,或者团队,这些依赖方的反馈周期和 push 难易程度肯定要大于团队内协作的情况,因此把他们放在首位,优先解决项目中不确定性大的部分,主要是为了规避项目不能按时交付的风险,同时给其他团队留够时间也是一种 push 的技巧。一个需求我问你要了两天没给我跟两周没给我是不一样的。

  • 利用好项目管理工具

    异步任务最难的是任务挂起后一段时间,唤醒的时候还能拿到所有的上下文,这个时候就要有好的项目管理工具支持,看板是一种,可以在任务卡的评论里留下足够详细的进展记录,方便在多任务同步进行的情况下追溯具体任务的细节。

  • 做好任务可视化,即时同步相关责任人

    做好可视化,除了让你的老板知道你在忙什么,还能为你争取到一些资源,比如站会时更新状态的时候可能会有团队成员提出之前做过类似的事情,或者给你发篇文档,或者给你个靠谱的接口人,都能极大地提升你的办事效率,扫除项目中的不确定因素。

至于自己能搞定的事情,如果真是有那么着急,即使其他团队的人都走了,正好也没人会打扰到你,这个时候再做,其实是更有效率的。

凡事有交代,件件有着落,事事有回应。

——判断一个人是不是靠谱的三个标准

高效会议

在阿里的会议主要有周会和项目对齐需求的会议,团队内部的沟通一般吼一声就可以,所以会议大多是面向老板的或是面向其他部门。其实在 ThoughtWorks 的离职总结我有提到过如何做一个好的会议组织者,在这一年的工作中我更多的时候是作为一个参与者。会议的组织者主要是关心会议的目的,会议的议程是什么,哪些是会议主题之外应该私下讨论的,会议到达达成的共识是什么,诸如此类;作为一个参与者,更多的是要关注自己的目的,要和谁确认清楚什么事情,要某位领导点头做某个决定或者不做,带着目的去开会是高效会议最重要的核心。

  • 开会要准备,会议的背景、有哪些内容是“你”一定要在会上和别人沟通清楚的,有哪些是可以线下再说的。
  • 一切讨论、想法都要有记录。

  • 邮件比聊天工具更适合工作。

及早发现问题,快速获得反馈

返工是最耽误进度的,曾经有过一段不愉快的项目经历,是因为一个产品需求上的一个小变动导致整个技术方案推倒重来,而且因为一开始没有预估好变动的范围采取了基于第一版的实现改造的方式,导致工期比重做一版还长,最终影响到项目交付时间比预期延长了一倍。这些损失和风险其实是可以通过及时、频繁的沟通降低的,协作的核心就是在沟通,宁愿在开始前先花时间沟通清楚业务需求和技术实现,也不要造成返工这种极大的浪费。

直面客户

阿里巴巴一以贯之的价值观是“客户第一”。在一个云产品团队,我们的客户主要是用户企业的开发者。以前在 ThoughtWorks 很苦恼的是总是要通过客户企业才能接触到真正的用户,在阿里的苦恼是每天都要接触真正的用户。刚开始答疑的时候,内心是很排斥的,一方面由于用户的技术能力参差不齐,提的问题大多涉及到非产品的问题而是一些通用开发工具如 npm, maven 的使用上的问题,让人很想甩用户一脸“自己 Google”。然而价值观告诉我们这样是不对的,耐着性子跟客户聊下来发现,很多问题源自于用户和我们不在同一个上下文,产品背后的实现对用户而言是一个黑盒,所以提出来的问题很多会让我们觉得很无语,而且随着沟通的深入我还发现,其实用户反馈的问题中,有相当一部分确实是我们的问题,要么是易用性,比如错误提示做得不够好,要么是产品真的有 bug。认真对待客户的问题是一个做产品的团队应有的心态,阿里云作为一个庞大的系统有自己的用户反馈体系,用户的声音经过层层传递到达开发团队是很不容易的,是用户的信任让他的问题走到了我们面前,不要辜负这份信任。

小结

最后,Ownership 真的是太重要,可能是职场中最重要的东西。有责任感,交给你一件事做成了,又交给你一件事也做成了,你做的事情会越来越多,越来越有挑战,这个过程就叫成长。