一、业务支撑

快速发展已经成为互联网公司的一种共识，那么在快的情况下，怎么面对业务支撑？尤其是当业务多，团队人手不够，大家又想做技术驱动、平台升级的时候。

我们的做法是跟大家做了一个共创，把业务分成日常项目和重点项目。在互联网领域，所谓重点项目就是能影响市场抢占度，甚至影响公司成败的项目。因此，对于重点项目，我们有一个明确的要求，即0排期，让重点项目能够随时启动、快速上线，以雷霆之势赢得战略优势。

以运满满为例，我们是一家强运营公司，前线销售人员面对的情况多变，因此他们的KPI、运营方式、所需的数据支撑也一直在变，这就需要CRM系统也能跟上这种变化速度，给他们最大的支撑。

面对这种情况，我们就把CRM建设作为重点项目，高速迭代，在3个月内完成了58次发布，支持14个业务扩展了109个需求。

这是我们最根本的态度，重点业务一定要好好支撑掉，然后才会去做技术驱动。

如何保证业务支撑

那在具体执行层面，如何保证业务支撑呢？毫无疑问，架构和技术是基础，但你会发现架构永远跟不上新业务的发展。这时，在平台化还没有实现、工具化还没有完善的情况下，我们就需要先靠项目管理和人员素质来解决这个问题。

首先，要理顺整个项目管理流程和节奏，我们有几个原则，包括早进入、并行化、反向推动、Deadline、公告等。

以并行化为例，在开始聊想法、MRD、运营计划的时候，核心产品经理、核心架构师、核心设计师要同步参与；在出商业计划的时候，基本的整体架构设计就应该已经完成了；在出产品PRD的时候，基本的概念设计就应该已经完成了；真正到开发的时候，测试用例和自动化测试脚本等就应该已经同步的完成了。尽量分解并行，以此来提高效率。

其次，要打造项目机动组织。举个例子，大家排期的时候经常会提到人员不够，我们的做法是对整个团队做一次大的封闭培训，要求大多数成员特别是高T的同学要非常熟悉每个系统，尤其是核心系统。这样，当某个系统模块比较紧急需要人手的时候，我就可以随时把其他系统的人调过去，尤其是高T的同学，他再带上两个研发的话，可以快速的把这个模块做起来。

对于一家较大规模的公司来说，人员肯定是不缺的，关键在于组织是否足够机动，能否做到员工兵力的机动调配，去支撑重点项目，尤其是脉冲型重点项目。

除了这两点，还需要其他项目管理原则、项目公约、项目同步机制等，通过共享的方式，让大家都能看到项目进度，都能参与进来，真正做好项目管理。

业务支撑遇到的问题

在保证业务支撑的过程中，我们会遇到各种问题，最典型的有以下3种：

过来的所有需求都说非常重要、非常紧急，但是拼完上线了，业务那边却不做数据反馈或者根本不用，团队这边也不知道效果到底怎么样。
因为都是机动支撑，做完这个版本，也不知道下个版本做啥。
团队也想给业务打枪造炮，但看不到业务蓝图、路线图和运营思路，感觉就像高级外包一样，完全没法和业务一起思考，一起做系统架构，导致没有成就感。

为了解决这些问题，我们和团队又完成一次共创，提出了一个概念，即由单纯只关心“技术指标”的“需求翻译机器”、“架构优化机器”，转变为从技术视角去推动平台业务发展的业务架构师。不断锻炼“寻找技术和业务完美结合点的敏锐嗅觉”，保持“跨界”的核心竞争力。这个概念最初是天猫架构负责人大少提出来的，当我们再次用在满满团队，发现也非常适用。

具体到执行层面，可以从以下几个方面出发。

了解你的用户，我们会让研发团队到前线去跟真正的用户接触，做前线业务同学、运营同学做的事情，听他们的声音。同时要重视用户的反馈，我们的做法是每两周会把所有在线用户的问题拿出来分享给整个团队，让他们去了解用户的需求。
体验你的产品，我们会强行要求每个同学都得用自己的产品，频率可以不高，比方说一两周一次，但一定要亲自去使用，同时要注意在使用的过程中提出问题。
关注线上数据，同样也是要求每个同学都关注线上数据，还会不定期抽查，比方说上线了一个新模块，那这个模块最近数据怎么样了？涨和跌的原因是什么？数据的变动又跟哪个项目有关系等。
懂你的行业，这方面我们也做了很多举措，比如汇集行业资讯，开展行业分享，引入行业专家等。通过这些方式，让大家了解这个行业究竟是怎么运转的，也真正了解业内司机的痛点。当我们足够了解对方的时候，大家才会带有情感和思考的做事。
心中有一张大图，即做每一个功能都要思考整个架构，思考业务的运营，而不是只做单点思考。同时，还要思考要实现这个功能，底层需要有哪些支撑等。

当每个研发人员脑袋里都有一张完整的大图，同时又很懂行业、懂用户，他的参与感就会很高，这些是我们经历过共创、碰撞后提出的硬性要求和做法，目前执行下来效果非常不错。

二、技术驱动

前面提到，我们通过种种措施很好的支撑了业务，但技术同学不仅仅想要得到业务上的成就感，还希望得到技术上的成长。那怎么帮他们寻求成长，并且与真正的商业结合，让公司认可呢？

1.架构升级，包括服务化、中心化、中间件、平台化等

架构升级对于整个研发的拉动作用是非常明显的，以大家都在做的服务化为例，拆分完之后，模块直接松耦合，可以独立发展和演变，团队也能快速扩张。像运满满一开始也是一个All In One的App，后来服务化拆分之后，团队就可以迅速打起来。

服务化做起来之后，一定要跟上中心化、平台化，底层一定要有一个很强大的中台做支撑，这样才能支持新业务的快速扩张，也能支持已有业务的快速变化。之后还可以去思考怎么在平台里去做业务监控、做数据分析等，慢慢会沉淀出很多中间件。

所以，整个架构是在不断演进、不断升级的，这对于技术同学来说就是一个很好的Topic，激发大家的激情，让他们自驱动的去思考还可以做什么，来让效率更高、稳定性更强。

2.工程效率，包括动态化、配置化、工具化、自动化等

工程效率对业务会有比较直接的支撑，而我们做技术驱动的整体思路，就是把工程效率中的每条线、每个子模块，都去做动态化、配置化、工具化、自动化。

从发布到运维，从测试到自动化，我们大概做了六七十个系统来打造我们的工具体系。这样一个工具体系的打造，首先大家会有成就感，自己做出的工具有效的帮助自己提高了工作效率；其次这些事情都有一定的技术挑战和技术深度，让整体团队的技术氛围得以增强。

3、稳定性，通过系统保障系统

稳定性是研发不变的一个主题，当公司体量越来越大的时候，稳定性就越来越重要，可能一个功能宕机5分钟，就有几万通电话打进来。在稳定性上，除了形成很多固定的流程机制外，我们还通过系统来保证系统，包括测试/灰度、降级/容灾/回滚、监控告警等。

4、用户体验，包括性能／交互、可用性、新IO、安全特性等

稳定性和工程效率是研发中两个基础的部分，能够在早期和中期很好的带动研发技术氛围，但最性感的还是用户体验。

用户体验是非常大的一个课题，需要长期的去监控、去治理。除了已有性能的不断优化外，我们还可以采用一些新技术来提升用户体验，比如当前很火的自然语言处理、人脸识别等。

以自然语言处理为例，它的知识图谱跟所处的行业有着密切的关系，比如我们就用它来做智能助手、智能客服，帮助司机解决使用问题，甚至帮助他们语音发货等。

这就是新技术跟行业、跟产品的结合点，而对技术团队来说，每一个结合点都是一个很好的技术驱动的方向。

5、运营效率，包括系统化、智能化等

每家公司不一样，运满满的运营基因很强大，大概有3000多名运营人员，所以怎么提高运营效率，怎么让他们更高效的获取用户、服务用户、拓展业务，也是我们的工作重点。

从这个维度出发，也能衍生出很多Topic，比如各个系统怎么去做自己的优化，通过系统化、智能化的手段大幅度提升运营效率。

值得注意的是，我提的这几个方向并不一定适用于每个公司，只是提供了一个思路，沿着这些方向去思考，总能找到适合自己的做技术驱动的方式。

最后，我们期待的团队必然是充满活力创新，每个人都在贡献idea，尝试优化产品和系统，参与到业务创造以及技术改变商业的过程中来。今天主要聊了如何从业务支撑和技术驱动这两个方面出发打造这样的理想团队，希望我们的一些做法能给大家带去参考。

作者简介

王东，运满满CTO，资深技术专家与管理者，曾先后负责过10多条亿级用户的产品研发管理工作，历任天猫高级技术专家、360高级总监、百度主任架构师，有过两次创业经验。