题记

首先要声明一下，这不是标题党，我真没有吹牛。

谨以此文，分享一些我加入阿里云后，我和我所在团队的成长经历。这里既有我个人如何从程序员成长为一个技术经理，也有我的团队如何把事情越做越大的过程和思考，希望能够帮到有需要的人。

0到1，从一个程序员，到一个技术经理

2020年11月，我加入了阿里云，走上了交付岗位，投身于一些项目交付，从程序员转型成为交付技术经理。都说加入阿里有一个把自己碾碎再重组的过程，很快这件事情就发生在了我的身上。

在我的第一个承担总控技术经理的项目上，作为一个技术人员，我在尝试以我认为正确的方式，来做项目的技术经理：过需求，评方案，给ISV管代码，搭流水线，做code review，搞部署，做配置……事无巨细，身先士卒，和快30个ISV人员共同搞项目。然后发现自己身上的事情越来越多，我经常成为了项目的卡点，只得加班加点使劲处理。在这个项目上，我觉得我已经尽我所能地努力了。然而效果却不理想。甚至ISV的研发人员也对项目的掌控度不高，大小问题都需要我来参与决策，有时还要手把手教怎么写码。我能怎么做？只能更加努力。记得项目最忙的时候，压力山大，我一个礼拜睡了不到20个小时，真是把自己碾的碎成渣了。然后呢？然后，下一个并行项目要开始了……

初入项目的我，活像图中挖坑的人

我不禁陷入深深的困惑——我做错了什么？别人又是怎么做的呢？

这时，团队的老技术经理们给了我很多建议。我一一记下，总结归纳成如下几点：

1.  一名合格的技术经理，并不是一个大头兵，而是技术方案上的制定者和决策者，以及方案落地结果的验证者。

我之前花了太多的时间做了“我想做的事情”，而不是“我必须做的事情”。技术经理要做最重要的是对交付过程中的技术性问题提供可以落地的解决方案，并指导相关研发人员落地。其他的执行性工作，是不是我亲手下场做的，真的重要吗？

2.  合格的技术经理面对问题解答问题，优秀的技术经理预测问题、规避问题。

交付过程中，解问题，大多是被动的，也容易出现拆了东墙补西墙的情况。到项目后期容易形成“房间里的大象”式（显而易见，但容易被忽略）的问题。好的技术经理要在一开始就要尽可能的选择不给后来挖坑的方案，这非常考验技术经理的技术判断水平。

3.  管理风格：尽可能保持师长心，非必要不必父母心。

起初，我在项目上习惯性地把方案的粒度落到代码级，然后再手把手地教研发同事写下来。时间长了，我发现他们有点问题就会等着我来处理，完全被我“惯”坏了。这样一来，我也没有精力处理更多应该处理的问题。好的技术经理应该像一个师长一样，讲方案和方法，放研发人员去执行，自己检查结果。这样随着研发人员技能的成长，自己身上的担子会越来越轻。当然，这不是说自己就可以完全不干，必要时候还是要撸起袖子自己上的，也就是所谓的“兜底”。好的将领要坐镇帐中指挥三军，但危机时刻也要亲手上阵杀敌。

4.  用好资源，做好协同。

自己的注意力要放在那些只有自己能做的事情上。有些确定的、标准的、技术含量相对低的、重复性高的、必须要做的工作，可以尽可能交给项目组执行人员完成。这样一方面培养了团队力量，一方面节省了自己的时间和精力，可以投入到更能体现自己价值的事情中去。同时，也要与商务侧和交付铁三角（项目经理、业务分析师、技术经理）的战友保持良好合作关系，内心明确各自职责范围以及合作阵型，确保正确的人做擅长的事，让项目整体保持高效。

5.  背靠产研，用好产研，服务好产研。

在遇到了一些交付标准产品的问题时，别自己闷头看，该是产品侧的问题还是要产研方协助调查的。但这也不意味着有问题直接透传，而是要发挥自己在一线的作用——缩小问题，锁定问题，协助产研快速分析解决问题。同时也要意识到，交付技术经理是可以将客户的需求结合技术分析反馈到产研，让产品变得更好的，这种产研协同也是交付技术经理在产品上的最大价值。

6.  交付有硬核技术，也有温情温度。

好的服务一定是充满人情温暖的，为对方着想的。甲之蜜糖，乙之砒霜。有时候技术上的最佳实践，却未必是最适合客户的。甚至有时客户会因此承担一些非必须的工作量，或本不该承担的风险等。在这时，技术经理就不能仅考虑技术了，要考虑客户的额外风险，把复杂留给自己，把简单留给客户。

7.  技术！技术！还是技术！

上面的几条，其实说的是技术经理“做什么，什么不做”。但必须做的事情，到底都是技术相关。自己技术能力不够，就得去学。你永远不知道客户和ISV会从怎样的刁钻角度向你提出怎样的问题。一个项目下来往往会发现自己很多要学，咋办？打铁还需自身硬，学起来！

我的工作手记

在各位前辈的指导和帮助下，我终于找到了自己的定位，真正成为了一个合格的技术经理。并行的搞上两三个项目，终于不是问题了。这一路碾碎自己再重组的过程，我想，可能就是通往架构师之路吧。

1到10，从交付好一个项目，到怎么并行高质量交付多个项目

之前项目交付过程中，我就在思考，什么是高质量低风险的项目交付？思前想后觉得有如下几个要素：

1. 范围需求明确。如果交付过程中持续需求变更，增加迭代，持续定制开发，这其中的风险肯定会越来越大，这种需求持续变更在展会类项目中特别常见；

2. 解决方案由标准产品构成。好的交付项目应该是由尽可能多的、标准的、经过诸多项目验证的产品，通过简单的配置和集成工作来完成的；

3. 尽可能少的代码级定制开发改动。交付过程中加入的代码越多，产生风险的可能性就越大。最好能用基于标准产品的能力，如配置、低代码、脚本等方式来完成定制需求，越少的定制开发带来越少的交付风险；

4. 项目周期短平快，交付内容小而精，这样就没什么创造风险的空间了。

带着这种思考，拥抱业务变化，我又投入到了专属钉钉的项目中。进场伊始，我发现专属钉钉的项目交付真是具备了高质量低风险交付的所有要素：

1. 交付需求确定：就是让客户用上和用好专属钉钉，差异只在一些标准特性的组合，以及和客户环境的集成上；

2. 解决方案构成均为标品：专属钉钉中的若干特性、宜搭、Teambition、邮箱，基本上围绕这企业办公效能提升的几个组件，构成整个交付解决方案；

3. 近乎0代码交付：交付过程主要由如下动作完成：SaaS开通，中间件部署，配置和低代码搭建。在这样的近乎0代码交付中，技术经理更多的是关注交付方案中的网络打通，安全合规配置，架构互联关系，以及客户侧的应用上钉系统的技术方案咨询；

4. 短则十几天，长则半年内搞定项目交付，参与人员不多。

这可真是个好活儿啊，时间短规模小标准度高，感觉自己可以过上轻松日子了。事实证明我又错了。两三个项目同时开始，没问题。五个十个项目并行执行，忙的过来吗？

于是，我又忙傻了。我很快就要面对从1到10的能力提升和角色转身——如何做海量标准项目的同时交付。团队的老技术经理们又给我出主意了：

1. 抓大，放小，看细。还是一个工作粒度的问题，随着项目并发度更高，更需要区分清楚什么是自己做，什么是生态做。更多的执行层面的动作需要借助生态的力量完成，技术经理应该关注更加大方面的问题，比如交付方案、交付流程、当前卡点等，将项目拆解为可执行落地的一个个步骤，然后交给生态执行，解放自己。当然，也不是放手不管了。后面还得有结果检验的过程，需要持续关注交付过程中的信息沟通，确保落地无误。

2. 生态化和标准化。1到10，是一个从skill in，到skill out的过程。五个人的精力总是有限的，要覆盖更多的项目，自然就需要更多的人。生态化交付是不可避免的。为了支撑更多的专属钉钉交付项目数量和并发度，我们引入了更多的生态交付人员。但生态交付人员的技术能力深浅不一，怎么样能够保证交付质量和效果呢？新手来了怎么带？老手要是走了怎么办？这就是做标准化交付的价值所在了。我们在自己交付过程中，将标准交付的过程写成一个个可执行的标准交付手册，涵盖规范交付过程的输入，操作，输出。保证来一个新人，无需培训，对着手册就可以开始交付。在这样的努力下，很多小型的项目的交付基本上可以完全由一方生态人员独立交付，节省了我们大量的时间。

3. 交付方案与交付知识的持续沉淀。标准化的交付方案，是需要随着交付过程持续打磨的，过时了也无法达到对交付持续助力的作用。所以我们工作的另一个重点，就是将标准交付执行手册持续更新，确保每位交付人员都有一手的交付指导。另外我们也建立和丰富交付知识库，将不同的人遇到的问题和解决方案都记录下来，这样在以后的项目中，确保过去已经解决的问题，可以立即查到答案，省去了很多再次寻求答案的过程。这也让我们的职责发生了进一步的转变：由执行者、管理者，变为交付方案的沉淀者、交付知识架构的搭建者和推广者。脑子里时刻考虑的是，如何将一项能力让交付人员都快速掌握，所以持续积淀交付知识就非常重要了。

4. 工具化，将非标准问题转化为标准问题。项目多了以后，会发现总有一些通用性的问题，但需要结合客户的实际场景来做局部的差异化处理。这样的工作每个项目可能不多，可加起来就会觉得费时费力。最终我们发现团队还是需要孵化一些工具，将这种非标问题，通过工具上的配置来转化为标准解决方案。最终，我们孵化了了一些真正有用的工具，高效的解决了诸多通用性问题，这些工具也真正成为了助力项目交付的有用弹药。

5. 团队作战，发挥每个人最擅长的点。每个人项目都很多，这意味着分到单个项目上的时间就少了。那么，遇到棘手的问题怎么办？这需要靠团队的支撑了——如果一个客户对应用如何做应用钉钉集成有需求，就去找熟悉企业应用和钉钉开放平台能力的同事；如果一个客户对让企业使用钉钉后如何提效更明显有需求，就去找做咨询方法论完备、擅长企业上钉咨询的同事；如果一个客户对工具有需求，那就去找工具的owner同时；如果一个客户对运营推广有同时，那就去找擅长运营的同事……君子善假于物，技术经理更应该深谙此道。不得不说专属钉钉项目真的特别好，无论你之前干过什么，大家基本都找得到和过去经历深度结合的点，让自己的能力有所发挥。印证了那句鸡汤——所有的经历都是值得的。

就这样，我们团队五个技术经理，上一个带队交付了120多个专属钉钉项目，其中有一个人搞几天的小项目，也有几个人客户现场一扎几个月的大型项目，日常基本上可以做到每个人带领一到两个生态人员，参与七八个项目（两个重点项目+五六个中小型项目）的交付。

一年下来，终于有这种调度三军，处变不惊的感觉了

这一年的项目交付过程中，随着交付标准化和交付工具的建设，交付效率和交付质量越来越高，这使我们可以将更多的时间关注在业务拓展和工具创新上。

10到100，怎么让更多的人快速并行高质量交付多个项目？

都说“既要又要还要”，那么，我们能不能还能支撑更多项目的高质量交付呢？这成为了这个新年的一个挑战性问题，围绕这个话题我们也做了大量的讨论。要再次的提升交付并发度，做到从10到100，其实就是解决从1到10中还存在的问题。那都是什么问题，以及要怎么解呢？

1. 基于标准化的交付在线化。虽然我们可以并行的交付很多项目，但作为兜底的技术经理也就五个人，并行10个以内的项目还能够靠记忆或者表格来维护交付状态，但再进行并发，就一定需要在线工具了。要不然就真不知道每个项目的进度和每个人在忙啥了。我们需要一个工具，来对每个人的正在进行的项目进行在线化的管理。但和一般的项目管理或者GTD工具不同，我们对工具的期望，还包括了交付方案的自动化生成和编排、标准交付动作内容的在线化、交付知识的在线化、标准交付过程中的问题和对产研的需求跟踪。这样，无论是新人加入，有人离职，项目人员更迭交接，我们都可以在在线化的平台上看到项目的执行情况和问题卡点，从而能够变被动为主动，通过在线系统去驱动项目交付。有了平台化的管理会带来很多基于数据的分析，我们就可以在这样的基础上，去寻找进一步可以优化的点。包括项目交付卡点分析，项目交付耗时分布，每个人的项目并发度和能力分析等。我们就在基于这样的需求，孵化适合标准交付的项目在线交付工作台，从而在提升每个人的并发度，也能够降低交付复杂度，提升效率。

2. 孵化更多产品加工具的联合标准解决方案。交付过程中，对专属钉钉产品交付可能只是交付的一部分，围绕着客户的实际需求，还需要结合我们自己的服务产品，做更大更完整的标准交付方案，借助在线化的交付工作台来做广义标准交付过程。

目前，我们也已经将专属钉钉的标准产品，我们自己的一系列工具产品，孵化了企业上钉综合运营推广解决方案。让客户不仅能够上好钉钉，更能用好钉钉。这种综合的一揽子标准交付方案，也会在在线化交付的平台下，支撑更多复杂交付场景。

3. 深度的生态化。从10到100就可能不仅仅是我们自己来做交付了，我们需要引入更多的生态来参与交付。

在这里有两种思路：一种是将一部分服务分包出去，我们以管理更多生态的方式来支撑更大程度的并发交付，管理方式包含且不限于使用在线交付工作台；另一种为将孵化的工具和在线交付工作台开放给生态使用，让更多的生态用上我们的工具，提升每个项目的工具覆盖度和交付效率，我们作为工具的提供方为生态交付兜底。这两种方式其实并不冲突，我们在新的一年都会进行尝试，争取探索出一条合适的生态化之路。

4. 交付技术经理角色的再次转身。在线化工具化很好，但是如果实际交付不使用，那么还是有问题的，对工具的问题不会暴露，对交付的深度挖掘也不会发生。我们在此时，除了做方案，解问题，看进度，还需要做在线化交付的监督者和执行者。需要不止对生态进行交付本身的管理，更需要给参与交付的人员定规则、查执行，使用交付工具完成交付，使用交付工作台完成项目交付记录。定期走查，及时管理，培养交付习惯。

上面的几点也是我们团队新年的重点建设内容之一了，希望能够在人员有限的情况下，交付更多项目，并且将能力输出到生态。让我们拭目以待，看看下一个年我们能交付多少项目。

后记

可能也许在未来的某一天，随着阿里云各种产品的标准化建设，大量的交付也会变得不依赖重型二次开发来完成，那这类的项目的交付团队，很可能就会再重新走一遍我们的老路，去思考如何1到10，以及10到100。我们会在继续努力，锐意进取，将海量并行交付这条路继续走下去。争取在正确道路的尽头，等待着其他的小伙伴。

广阔天地，大有可为！