【原创】公司各个阶段 CTO 需要做什么?(下篇)

假设一个公司发展有以下几个阶段:

  • 0 :创始阶段;

  • 0.5 :有产品但无管理阶段;

  • 1 :经过 1年的发展初步稳定的阶段;

  • 1+ :稳步发展阶段。

上一篇文章中,我们聊了公司在初创阶段,CTO 需要做的事情,本篇将承接上篇,分析 0.5 到 1 的阶段、1+ 的高速发展阶段,CTO 需要做的事情。

 

0.5到1的阶段

公司经过了初创阶段,产品也已经上线运行。接下来产品需要高速、高质量迭代,作为技术管理者需要把各方面都规范起来。

 

管理需要标准化

 

建立项目管理流程:

  • 是否要使用一些项目任务管理工具,比如 Jira 或 Tower 等;

  • 是否要使用一些文档知识管理工具,比如 Confluence 等;

  • 选择什么样的开发模式,是敏捷开发还是传统瀑布开发;

  • 制定各种会议制度,比如固定的晨会、周会、总结会等;

  • 规划分支使用的流程,代码审核的流程;

  • 测试如何进行,选用什么样的 Bug 管理平台,Bug 的分级等;

  • 和公司其他部门定期同步并讨论项目总体计划流程。

 

建立沟通汇报流程:

  • 规划日常对内、对外 IM 沟通工具和邮件使用的规则;

  • 确定日常工作流程(评审、提测、发布、上线);

  • 制定每一个团队成员的日报或周报的模板。

 

绩效管理:

绩效管理如何来做,选择 OKR 还是 KPI ?大家有太多讨论和不同意见。在 TGO 鲲鹏会的小组活动中,我们组员也经常会针对这个话题讨论,每一个公司都有不同的做法,这和公司层面的文化、背景、项目属性、甚至是管理层的性格都有关系,无法完全照搬别人的做法。

我认为一个相对成熟的公司,适合公司的绩效管理方式必不可少,需要不断探索。一般而言,考核是用来激励那些不太优秀的人,特别优秀的人才无论如何考核,他们永远都是是冲在最前面的一批人。但是,任何公司都不可能做到 100% 的员工都有合伙人的心态和冲劲,也不可能 100% 的员工都是世界一流人才。所以,帮助所有员工建立清晰的目标并且进行回顾和考核非常重要,要让所有人的目标都是清晰、具体且正确的。

 

技术需要标准化

 各个环境标准化:

  • 定义明确 Dev 、QA 、Staging 、Live 环境的作用、每个人的权限,以及每一个环境的使用方式;

  • 建立一套统一的发布系统来处理日常发布。比如,可以封装 Shell 脚本或 Jenkins ,并且明确在线上发布事中事后,包括:运维、开发、测试、产品等每一个应该负责的点。

 建立技术标准规范:

  • PRD 产品需求文档和 UI 标注的标准;

  • 开发标准,比如,可以在阿里的 Java 开发规范基础上和大家一起讨论,总结出符合自己公司需求的开发标准,并且通过代码规范插件来约束;

  • 概要设计文档的标准,文档必须包含哪些点,什么时候提交评审;

  • 概要设计时表结构和服务定义的标准,各种中间件使用方式的标准和最佳实践;

  • 自测标准,单元测试的要求,自测不完善测试打回的惩罚等;

  • CMDB 的建立、服务器配置,操作系统基础配置,程序安装方式的运维标准化。随着时间的推移可以总结出适合自己团队标准或最佳实践,所有的标准应该是所有团队成员共同认可和遵循的,可以定期就这些标准进行回顾和讨论。

 建立监控管理制度:

  • 搭建日志、监控报警基础设施。比如,可以使用 ELK 、Grafana 、InfluxDb 等来搭建;

  • 统一公司的日志、打点框架,规范明确项目的日志和打点标准;

  • 为各个业务建立监控面板和报警规则,明确报警处理标准;

  • 定义事故分级流程,复盘方法以及追责方式;

  • 定义运维日常监控容量巡检方式以及应急响应预案。

 

1+ 的高速发展阶段

 

随着业务规模的扩大,很可能有了多条产品线;随着团队规模的扩大,彻底扁平化的组织架构可能无法满足需要;随着访问量的增大,对技术和架构的要求也越来越多。这种情况,不管是对技术的要求还是对管理的要求都更上一层楼,这个时候需要在标准的基础上再做一些管理和组织结构的演进,站在更高的角度管理去思考。(这个时候做一些细枝末节的工作对于整体的意义就不大了)。

 

技术方面的升华

随着公司的发展,产品要么形态丰富,各种产品和业务衍生出来,要么产品形态不变,访问量急剧增大。对于前者,管理方面很容易犯的一个错误就是简单的进行业务线的拆分和招人、招人、招人,形成 N*20 个这样的团队,每一个团队之间相对独立,技术没有沉淀。对于后者,很容易犯的错误是通过堆服务器和堆运维来抵挡压力的上升,导致技术架构老旧问题增多。这种粗旷风格的团队扩张是不太健康的,更好的方法还是多折腾:

  1. 我的建议是通过进行技术和组织架构的调整,形成专才,形成纵向技术线,把通用技术提炼出来,让整个公司都可以积累统一的、能够向前发展的技术平台;

  2. 强制通过自动化手段把人解放出来,人应该去做创造性的工作;

  3. 消除团队安逸的状态,让团队或业务线之间形成竞争,保持冲劲。

 

组织架构调整

随着业务规模的扩大,团队规模也在扩大,仅仅对业务线的技术团队进行横向拆分( X 维度拆分 )还不够,还需要有专门的垂直团队服务于横向的业务团队。通过建立架构、中间件、运维等垂直团队服务于所有业务团队,确保技术和架构的统一( Y 维度拆分 )。

如果团队人数超过 20 不足 50 ,我们需要增加经理层来管理一线员工,变为三层架构,如果人数超过 50 不足 100 ,我们需要增加高级经理来管理经理,变为四层架构( Z 维度拆分 )。当然,可能还会形成一些虚拟的或实际的技术或项目管理委员会,对技术人员的发展、技术的标准化、公司层面的技术大任务进行定义和协调。

补充以下几点:

  1. 随着层级的增多,管理者对于一线员工的触达会越来越难,可能导致执行效率降低。这个时候,对下属主管的任用和管理非常重要。与管理一线员工相同的是,主管也需要绩效考核和标准,不同的是,主管们承担了管理职务,一线员工是由他们直接管理和影响的,此时对于主管的培养非常重要。不仅仅要让他们使用 CTO 原先定的标准和套路来管理,更多的是让主管明确意识到自己的管理职责,激发出他们自己的管理风格;

  2. 在确保主管被充分授权,并且有团队管理自治性的同时,最好提供一个通道,让一线员工有机会表现和表达自己的想法,让高层管理者可以了解到任何一名员工的想法,保持公正透明;

  3. 在公司这个阶段,可以和人事一起把人员的职级要求和薪资标准进行统一定义,要和绩效考核结合起来,形成固定周期的职级调整方案,形成明确的上升通道。让每一位成员意识到只要通过自己的努力,在公司内部同样可以走的很远;

  4. 业务团队和平台架构团队的目标使命不同,会存在一些矛盾存在。作为 CTO 要做好引导,让业务团队认识到架构统一的重要性,让架构团队认识到业务团队的压力。也可以鼓励团队之间的人员换岗以及做一些技术团队的培训,让架构团队理解业务,让业务团队深挖技术。

 

建立文化

人毕竟是社会动物,是有感情的,如果公司所有的管理手段都是硬手段,员工很难从内心认可。我们可以和 HRBP 配合,打造有团队特色的技术文化。比如,分享文化、开源文化、学习文化、鼓励自动化的文化等。

我们可以建立技术团队的微信公众号,让所有人一起来发文和运营。可以把自研的项目开源出去贡献给社区,让社区一起来完善,可以组织定期的公司内部或公司与公司之间的技术培训或交流,组织一年一度的技术之星、产品之星评选等等。初期可以通过使用一定的奖励激励手段来传播固定技术文化,形成文化后,每一位团队成员会觉得工作不仅仅是完成个人的任务,而是在一个集体中成长,在团队中生活,有归属感价值感。

 

建立价值观

一般而言公司层面会提炼出 3 - 5 项重要的价值观,技术团队也可以在此基础上细化、提炼技术方面的价值观,并纳入考核。

个人认为价值观一方面可以给我们定一个大方向,比如,我们需要怎么样的人;另一方面又类似于心理暗示,潜移默化的影响每一位员工。慢慢地,员工会演变为符合公司价值观的人(变得和公司有“夫妻相”),或者意识到无法适应价值观而主动离职。比如,如果可以定义一专多能、主动承担、勇于创新、言出必行作为技术团队的价值观,并且展开列出一些子项纳入考核。即使员工的业务能力没问题,但日常的表现不符合价值观,那么他只能是一个过客,无法和公司一起发展,这也是为什么很多大公司如此强调价值观的原因。

团队规模小的时候,我们只要自己冲在前线就可以很好的管理团队,在规模中等的时候我们可以利用一些标准和制度进行管理,在规模更大了以后,我们需要更高维度的文化价值观等手段来感染到每一个员工,让员工认同公司,这比约束命令式管理更有效。

 

处于这个阶段的公司,CTO 不仅要做好对内的管理工作,还要抽出时间做一些对外的工作,来帮助公司做品牌宣传,并且用技术争取更好的资源,比如,定期和同行以及投资人交流,组织参与一些技术讨论,跟进行业趋势等。

 

最后,想聊聊技术如何服务于公司战略?

就我个人而言,我觉得两点很重要,一是坚持,二是应变,三是要思考。围绕这几点,我列了一些技术服务公司战略的要点。

 产品技术部门最基础的职责

作为产品技术团队,最本职的工作还是持续高效输出高质量、高可靠的产品,满足公司的业务需要。并且在不断提高可用性的同时,通过自动化、标准化提高效率,节省人力成本。在组织规模变大了以后,还能通过管理手段来保持团队的高效。随着业务和团队规模扩大,做到这几点并不容易,但这只是技术服务于公司战略的基本要求。

 以技术创新把不可能变为可能

举个例子,有一次,业务给我提了一个需求,因为受到底层外部接口的限制,这个需求无法实现。但是业务表示,为什么别的公司可以实现,我们就不行。这时候,我才花时间去认真思考是否有一些突破的办法,尝试找到别人的实现方式,最后想到了可以绕开限制的方式,把这个项目实现了。我没想到的是,项目上线后业务告知当时问错了,其实别人也无法实现这个东西,因为只有我们实现了这个技术,所以很多人都愿意来找我们合作。

很多时候,我会认为自己有十几年的技术研发经验,我对公司既有技术足够理解,我以为我可以对一件事情是否可以实现很快下结论。其实这是不对的,在收到外部需求的时候,应该反过来思考,先假设这个需求是必须实现的,或者竞品已经实现了的,在拒绝别人之前,给自己几天时间,给团队几天时间来想一下怎么去实现,如果你做到了别人做不到的,那么你的技术就是核心竞争力。

 建立一支可以打快战的铁军技术团队

随着公司技术的标准化和成熟,团队应该 具有打快战的能力,但是稳定的业务往往会让老兵们进入温水煮青蛙的状态。作为技术管理者,应该用各种手段来激励大家的斗志(比如搞阶段性的重构、黑客马拉松比赛),保持团队的活力。这样,如果有新开辟的项目,可以在公司内部轻松找到并形成一支敢死队来参与战斗,超高的执行力使得新业务可以尽快进行低成本试错或抢占市场,这也是技术产品团队成熟于否的体现。

 根据战略及时调整团队架构和技术架构

不管是团队架构还是技术架构应该有一定时间的先行,一般而言对于线性发展的项目,公司目前如果处于 A 量级的 PV ,就应该开始储备十倍 A 量级 PV 的架构。根据业务的发展估算技术架构的挑战,提前半年或者一年进行新一代架构方案的确立,确保技术不拖业务后腿。团队架构也是同样需要先定义骨架,再在每一个可能的职位上进行填坑招聘。技术管理者需要对公司的战略敏感,根据公司的发展和战略,提前做好这两个架构调整的准备,并在需要的时候及时应用调整。

 提炼核心技术,产品化产品,探索进行产品输出的可能

如果做的是 2C 的产品,在一个领域做了多年或许就有能力把核心技术或产品提炼出一套 2B 或 SaaS 的产品来卖,如果成功,这就不仅仅是一个 2C 的产品,很可能又多出一套 2B 的产品甚至是一套 2C 的平台。如果做的是 2B 的产品,或许就要思考一下,现在的产品是复制粘贴的定制化产品还是完全配置的产品化产品,如果不是,怎么让他更通用地进行产品化,减少人力成本。产品化平台化的过程是一个痛苦的抽象过程,对技术的要求更高,不过一旦实现就可以让公司的用户和规模得到爆发式发展,真正的技术改变战略。

 关注前沿技术,思考前沿技术和公司业务的结合

目前正处在技术变革的一个关键阶段,在未来 5 年内,垂直细分的 AI 将会变得成熟,区块链也可能会出现大量的实际应用,技术管理者应该时刻关注这些技术,不断思考可能的结合场景。这个世上不缺爱思考的人,但很多懂业务的人不懂技术,懂技术的人又不能理解业务痛点,只要积极关注前沿技术并和业务专家保持讨论沟通,说不定哪天就会碰撞出具有革命性的产品。

- End -

 

posted @ 2018-04-13 17:05 lovecindywang 阅读(...) 评论(...) 编辑 收藏