|
CTO 是企业内技术最高负责人，对企业的发展起到至关重要的作用。但随着公司的不断发展，CTO 的工作重心也会不断变化。只有在正确的阶段做正确的事，才能更好地为公司做出贡献。朱晔是空中金融 CTO ，TGO 鲲鹏会上海分会会员。加入空中金融之前，朱晔曾在饿了么、空中网、5173 等互联网公司担任中层技术管理者，有过三次从 0（ 或 0.5 ）开始的创业公司工作经历。 假设一个公司发展有以下几个阶段：
上一篇文章中，我们聊了公司在初创阶段，CTO 需要做的事情《空中金融 CTO 朱晔：公司初创阶段 CTO 需要做什么？（上篇）》，本篇将承接上篇，分析 0.5 到 1 的阶段、1+ 的高速发展阶段，CTO 需要做的事情。 公司经过了初创阶段，产品也已经上线运行。接下来产品需要高速、高质量迭代，作为技术管理者需要把各方面都规范起来。 建立项目管理流程：
建立沟通汇报流程：
绩效管理如何来做，选择 OKR 还是 KPI ？大家有太多讨论和不同意见。在 TGO 鲲鹏会的小组活动中，我们组员也经常会针对这个话题讨论，每一个公司都有不同的做法，这和公司层面的文化、背景、项目属性、甚至是管理层的性格都有关系，无法完全照搬别人的做法。 我认为一个相对成熟的公司，适合公司的绩效管理方式必不可少，需要不断探索。一般而言，考核是用来激励那些不太优秀的人，特别优秀的人才无论如何考核，他们永远都是是冲在最前面的一批人。但是，任何公司都不可能做到 100% 的员工都有合伙人的心态和冲劲，也不可能 100% 的员工都是世界一流人才。所以，帮助所有员工建立清晰的目标并且进行回顾和考核非常重要，要让所有人的目标都是清晰、具体且正确的。 各个环境标准化：
建立技术标准规范：
建立监控管理制度：
随着业务规模的扩大，很可能有了多条产品线；随着团队规模的扩大，彻底扁平化的组织架构可能无法满足需要；随着访问量的增大，对技术和架构的要求也越来越多。这种情况，不管是对技术的要求还是对管理的要求都更上一层楼，这个时候需要在标准的基础上再做一些管理和组织结构的演进，站在更高的角度管理去思考。（这个时候做一些细枝末节的工作对于整体的意义就不大了）。 随着公司的发展，产品要么形态丰富，各种产品和业务衍生出来，要么产品形态不变，访问量急剧增大。对于前者，管理方面很容易犯的一个错误就是简单的进行业务线的拆分和招人、招人、招人，形成 N*20 个这样的团队，每一个团队之间相对独立，技术没有沉淀。对于后者，很容易犯的错误是通过堆服务器和堆运维来抵挡压力的上升，导致技术架构老旧问题增多。这种粗旷风格的团队扩张是不太健康的，更好的方法还是多折腾：
随着业务规模的扩大，团队规模也在扩大，仅仅对业务线的技术团队进行横向拆分（ X 维度拆分 ）还不够，还需要有专门的垂直团队服务于横向的业务团队。通过建立架构、中间件、运维等垂直团队服务于所有业务团队，确保技术和架构的统一（ Y 维度拆分 ）。 如果团队人数超过 20 不足 50 ，我们需要增加经理层来管理一线员工，变为三层架构，如果人数超过 50 不足 100 ，我们需要增加高级经理来管理经理，变为四层架构（ Z 维度拆分 ）。当然，可能还会形成一些虚拟的或实际的技术或项目管理委员会，对技术人员的发展、技术的标准化、公司层面的技术大任务进行定义和协调。 补充以下几点：
人毕竟是社会动物，是有感情的，如果公司所有的管理手段都是硬手段，员工很难从内心认可。我们可以和 HRBP 配合，打造有团队特色的技术文化。比如，分享文化、开源文化、学习文化、鼓励自动化的文化等。 我们可以建立技术团队的微信公众号，让所有人一起来发文和运营。可以把自研的项目开源出去贡献给社区，让社区一起来完善，可以组织定期的公司内部或公司与公司之间的技术培训或交流，组织一年一度的技术之星、产品之星评选等等。初期可以通过使用一定的奖励激励手段来传播固定技术文化，形成文化后，每一位团队成员会觉得工作不仅仅是完成个人的任务，而是在一个集体中成长，在团队中生活，有归属感价值感。 一般而言公司层面会提炼出 3 - 5 项重要的价值观，技术团队也可以在此基础上细化、提炼技术方面的价值观，并纳入考核。 个人认为价值观一方面可以给我们定一个大方向，比如，我们需要怎么样的人；另一方面又类似于心理暗示，潜移默化的影响每一位员工。慢慢地，员工会演变为符合公司价值观的人（变得和公司有“夫妻相”），或者意识到无法适应价值观而主动离职。比如，如果可以定义一专多能、主动承担、勇于创新、言出必行作为技术团队的价值观，并且展开列出一些子项纳入考核。即使员工的业务能力没问题，但日常的表现不符合价值观，那么他只能是一个过客，无法和公司一起发展，这也是为什么很多大公司如此强调价值观的原因。 团队规模小的时候，我们只要自己冲在前线就可以很好的管理团队，在规模中等的时候我们可以利用一些标准和制度进行管理，在规模更大了以后，我们需要更高维度的文化价值观等手段来感染到每一个员工，让员工认同公司，这比约束命令式管理更有效。 处于这个阶段的公司，CTO 不仅要做好对内的管理工作，还要抽出时间做一些对外的工作，来帮助公司做品牌宣传，并且用技术争取更好的资源，比如，定期和同行以及投资人交流，组织参与一些技术讨论，跟进行业趋势等。 就我个人而言，我觉得两点很重要，一是坚持，二是应变，三是要思考。围绕这几点，我列了一些技术服务公司战略的要点。 作为产品技术团队，最本职的工作还是持续高效输出高质量、高可靠的产品，满足公司的业务需要。并且在不断提高可用性的同时，通过自动化、标准化提高效率，节省人力成本。在组织规模变大了以后，还能通过管理手段来保持团队的高效。随着业务和团队规模扩大，做到这几点并不容易，但这只是技术服务于公司战略的基本要求。 举个例子，有一次，业务给我提了一个需求，因为受到底层外部接口的限制，这个需求无法实现。但是业务表示，为什么别的公司可以实现，我们就不行。这时候，我才花时间去认真思考是否有一些突破的办法，尝试找到别人的实现方式，最后想到了可以绕开限制的方式，把这个项目实现了。我没想到的是，项目上线后业务告知当时问错了，其实别人也无法实现这个东西，因为只有我们实现了这个技术，所以很多人都愿意来找我们合作。 很多时候，我会认为自己有十几年的技术研发经验，我对公司既有技术足够理解，我以为我可以对一件事情是否可以实现很快下结论。其实这是不对的，在收到外部需求的时候，应该反过来思考，先假设这个需求是必须实现的，或者竞品已经实现了的，在拒绝别人之前，给自己几天时间，给团队几天时间来想一下怎么去实现，如果你做到了别人做不到的，那么你的技术就是核心竞争力。 随着公司技术的标准化和成熟，团队应该 具有打快战的能力，但是稳定的业务往往会让老兵们进入温水煮青蛙的状态。作为技术管理者，应该用各种手段来激励大家的斗志（比如搞阶段性的重构、黑客马拉松比赛），保持团队的活力。这样，如果有新开辟的项目，可以在公司内部轻松找到并形成一支敢死队来参与战斗，超高的执行力使得新业务可以尽快进行低成本试错或抢占市场，这也是技术产品团队成熟于否的体现。 不管是团队架构还是技术架构应该有一定时间的先行，一般而言对于线性发展的项目，公司目前如果处于 A 量级的 PV ，就应该开始储备十倍 A 量级 PV 的架构。根据业务的发展估算技术架构的挑战，提前半年或者一年进行新一代架构方案的确立，确保技术不拖业务后腿。团队架构也是同样需要先定义骨架，再在每一个可能的职位上进行填坑招聘。技术管理者需要对公司的战略敏感，根据公司的发展和战略，提前做好这两个架构调整的准备，并在需要的时候及时应用调整。 提炼核心技术，产品化产品，探索进行产品输出的可能 如果做的是 2C 的产品，在一个领域做了多年或许就有能力把核心技术或产品提炼出一套 2B 或 SaaS 的产品来卖，如果成功，这就不仅仅是一个 2C 的产品，很可能又多出一套 2B 的产品甚至是一套 2C 的平台。如果做的是 2B 的产品，或许就要思考一下，现在的产品是复制粘贴的定制化产品还是完全配置的产品化产品，如果不是，怎么让他更通用地进行产品化，减少人力成本。产品化平台化的过程是一个痛苦的抽象过程，对技术的要求更高，不过一旦实现就可以让公司的用户和规模得到爆发式发展，真正的技术改变战略。 关注前沿技术，思考前沿技术和公司业务的结合 目前正处在技术变革的一个关键阶段，在未来 5 年内，垂直细分的 AI 将会变得成熟，区块链也可能会出现大量的实际应用，技术管理者应该时刻关注这些技术，不断思考可能的结合场景。这个世上不缺爱思考的人，但很多懂业务的人不懂技术，懂技术的人又不能理解业务痛点，只要积极关注前沿技术并和业务专家保持讨论沟通，说不定哪天就会碰撞出具有革命性的产品。 |
|
|
