查看原文
其他

洋哥做CTO填过的坑!

findyi findyi 2022-05-12

阅读本文大概需要7分钟。

最近有不少读者问过洋哥:CTO到底要不要写代码?CTO究竟要做什么?怎么才能成长为一名CTO?


对于程序员来说,做CTO是最大的追求之一,但洋哥的确也见过程序员、架构师甚至技术总监都能干得很不错的朋友,做了CTO却惨遭翻车甚至被开除,这样的朋友还不在少数。


其实CTO最重要的能力,除了技术之外,是对商业对产品对业务的洞察力,这也是我之所以在去年选择做业务管理者的最重要的原因,只有深入业务、操盘业务才能掌握更本质的洞察。


可以用两句话来界定CTO的职责:

  • 建立对竞争对手的技术优势

  • 用技术驱动业务和商业腾飞


至于写不写代码?真的不重要!你代码写出花了,以上两点没做到,迟早也会滚蛋。


换个角度,就算跟王坚博士一样,一行代码都不写,以上两点做好了,那也是一个优秀的CTO。


前段时间分享过做CTO的方法论:有家创业公司花重金要请我当CTO?


今天分享下去年我在土豆教育做CTO的实操经验,希望对大家有帮助。


在那段时间里我做了这几件事:


首先重组了产品技术设计团队,引入了数名非常优秀的小伙伴。其中有几个产品技术小伙伴,放到上市公司都能到总监级别。


其次,参与公司战略制定,并根据公司战略制定产品的战略和打法,明确了未来3个月,半年,一年的产品目标。


再次,梳理了产研流程,搭建了敏捷研发及发布体系,工具的使用,推动团队数据驱动思维的转变。


最后,我们在C端实现用户量扩大10倍,GMV增长好几倍,公司内部的支撑产品也走向正轨。


我有这几点收获:


1.技术架构要和业务紧密结合


进公司发现团队已经在使用微服务架构,基本属于一个子功能一个微服务,服务端团队没多少人,微服务倒是有几十个。我们砍掉及合并了10来个无用的微服务,并从业务角度重构了我们的服务架构。


服务重构前:

服务重构后:


重构主要解决了以下问题:


  • 服务耦合,通用服务没有抽离

  • 服务分的太多,服务治理及维护成本高

  • 用户服务没有统一的入口,管理混乱

  • 分层混乱,没有面向业务的分层思想


重构后的服务体系应该能支撑公司业务后续2年的发展。并且我们是在优先支撑业务需求的前提下做完整个服务重构。


2.C端产品需要单点突破


做产品,选择干什么比选择不干什么要容易得多。刚来公司,大家还在做新功能,并且有个非常宏大的规划,不过产品存在以下几个问题:


  • 没有数据驱动的习惯

  • 日活月活半年维持不变

  • 功能越做越多,子功能体验都不好

  • 产品战略和公司战略结合不够紧密


和团队小伙伴各种聊天及思考了1周后,我们制定了一个c端产品六个月计划。


这六个月计划,明确了产品后续每个月甚至每周的重点关注模块和数据提升的北极星目标。这使得团队在每一个阶段都在做单点突破,有一个总体的大目标,围绕大目标快速迭代。


我们最初2周,就围绕产品下载率和注册率反复实验,基本上一周4个小版本,在两周内快速将产品下载率提升1.5倍,产品注册率提升2倍。这样在投放不变的情况下,我们的新增注册增加3倍。


随后,我们迅速将注意力转向激活率及留存率的提升,经过几个版本,激活率和留存率都有大幅提升。


做c端产品有足够的专注和聚焦,更容易取得突破性的效果。


3.内部系统产品效率优先


首先说一句:很多创业公司的产研团队是被复杂的内部系统产品拖死的。内部系统产品的研发一定要重视效率和效能,首先解决业务的痛点。


对于创业团队来说,超出业务需求和业务规模的内部系统设计是致命的,但在现实中,有不少这么做规划的团队。


我认识的一个创业团队,做了个后端支撑系统大重构计划,时间预计3个月。结果最后这个项目做了半年,占用了公司80%的产研资源。导致对业务的支撑严重跟不上。


在土豆做CTO期间,我们也面临了大量内部系统的重构及新增需求。这方面的经验总结下:首先需要深入了解业务流程和细节,找出真正的痛点,然后用快且底层健全的方式一步步满足业务方的需求,创业团队一定要控制住完善内部系统的想法,用短平快的方式来满足业务方的需求。


4.学会时间管理


时间管理是个大痛点,相信大家可能都有这种经历:每天忙得跟狗似的,但感觉没什么产出和提升,一段时间过后,发现貌似也没出什么成绩。归根结底,这是时间管理的问题。


我的经验是,不断梳理自己工作的优先级和工作重点。


别看我们每天都忙忙碌碌,忙过一段,你回头看看,可能80%的工作都是无效工作,真正给你带来进展的可能就是一两件事。那些既不能给公司带来较大收益,又不能给用户带来价值改进和“升级”的工作,都可以被看做是「伪工作」。


想清楚哪些事情是最重要的,是项目团队的key point,并花绝大多数精力去思考去解决这些key point。key point解决后,你会发现那些小问题说不定自动消失了。


5.用户群体研究


对一个操盘产品的人来说,最重要的技能是什么?不是什么方法论,产品架构体系,最重要的是要懂你的用户。


当然如果你本身就是你的产品的目标用户,那就会容易得多。不过还有不少产品经理,即便是在自己就是用户的产品领域,一开始设计产品立马变成「官方用户」,用自己产品架构的视角去看待产品,而完全忘记用户视角。


不懂用户带来的后果是毁灭性的,所以我们非常重视用户群体研究,在这个维度做了大量工作。比如定期的用户电话回访,产品体验官群,用户反馈的分析和回访,用户行为的详细数据分析。


通常情况下,我们自己的需求是很容易被发现的,但优秀的产品经理应该能够站在用户的角度思考:我们发现的需求,是真需求还是伪需求,是刚需还是弱需求,是高频需求还是低频需求。


发现产品的这些特性是产品经理的优秀能力,这种能力是在工作和生活中日积月累形成的,同时也可以通过大量的用户群体研究来快速进步。


6.团队文化建设


组建团队不是只需要把合适的人招进来就完事了,更重要的是把人才黏合在一起。把人黏合在一起靠的就是团队文化。


刚来公司发现团队的氛围不太对,技术团队更像一个外包团队。产品团队也对公司业务流程了解有限。


我们首先统一了大的战略方向,然后通过不断的思辨和讨论激活团队,并赋予每个团队成员足够的授权。


每周我们也会组织各种专业分享活动及产品脑爆会,竭尽全力做到信息透明并让每一个小伙伴都参与到建议和建设的氛围中,同时尽可能让每一个团队成员快速成长。


另外,我们让团队的每一个成员形成数据驱动的习惯,每个人衡量工作成果首先想到数据验证。无论是c端的用户数据,还是投放的端到端打通的数据,又或者是技术的各项优化对应的数据。让团队形成用数据说话的习惯和思维方式。


以上六点,是我做CTO的一个小小总结。


今天虽然我在做业务,但内心深处依然把自己当作一名程序员,或许有一天还会回归CTO的岗位,相信到了那个时候,做业务积累的经验会让我更加游刃有余。


·················END·················



你好,我是findyi,毕业于华科、清华,
一位大厂的业务负责人,
做过大厂技术总监,
也做过小厂CTO的产品技术人,
同时,也是一位信奉终身成长的职场人。

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存