互联网公司的成功很大一部分归结为人才储备，如何打造有活力、持续创新的研发团队，相信很多管理者都比较关心。
下面我们从业务支撑、技术架构、团队建设这几个方面做简单剖析
业务支撑
快速发展已经成为互联网公司的一种常态，那么在这么快的节奏下，如何快速支撑业务？尤其是在资源紧缺的情况下，既要做业务，也要做系统优化升级。确实很难做取舍。
我的观点是看公司的规模，如果是创业早期，活下来才是第一要素，我们会将业务分为日常项目和重点项目。所谓重点项目就是能影响市场抢占度，甚至影响公司生死的项目。因此，对于重点项目，我们有一个明确的要求，即 P0 排期，让重点项目能够随时启动、快速上线，以雷霆之势赢得战略优势。
理想是美好的，但与业务对接时，可能会遇到一些问题：
1、每次业务都说需求很急，火急火燎，确很少关注数据指标，项目一旦上线，就没有了下文。
2、研发完全是被动角色，像驴脑袋前挂根胡萝卜，永远被牵着鼻子走
3、产品缺乏清晰的业务规划、业务架构，很多时候都是走一步看一步。而研发作为合作伙伴，感觉像个外包，没法跟业务一起思考，共进退，缺乏成就感。
如何提高研发的参与感，快速支撑业务？首先要关心业务，不打无准备仗。
正如拿破仑说的“不想当元帅的士兵不是好士兵”，做为研发工程师，如果不关心业务，也很难有高性价的技术方案产出。不管是前期的需求分析、市场调研、竞品分析，技术同学如果有精力，最好都参与下。你不仅会了解到这个需求是怎么来的，还能预想到未来业务可能的迭代方向。提前做规划，这样在做设计技术方案时才会充分考虑系统的扩展性，而不是“将提升扩展性只是当成喊口号”。
研发的价值不仅是满足当下的业务需求，还要为为后续业务迭代预留好扩展。千万不要把自己定位成“需求翻译机器”、“架构优化机器”，相反我们要做从技术视角去推动平台业务发展的业务架构师。
技术架构
业务方面要发扬主人翁精神，技术方面同样要有成就感。关注市场主流的技术架构，选择合适的技术框架应用到项目中。具体我们要关注哪些方面？
1、架构设计
借助DDD思想指导我们落地一系列的微服务，通过注册中心完成各服务间的路由和发现。通过"拆' 降低系统复杂度，提升扩展能力。如果公司的业务较多，结合当下流行的中台战略，按业务模块拆分，水平支持上层一系列业务。将一些通用的逻辑沉淀到中台，统一规划支持，减少重复造轮子成本。
另外，做技术的同学都知道，架构是演化来的，很难一步到位。所以在做技术方案时，要充分考虑上线时间、人工成本、系统复杂度等因素，挑选性价比最高的技术方案，先满足当下业务诉求，后面再慢慢技术改造，迭代升级
2、工程效率，包括动态化、配置化、工具化、自动化等
工程效率对业务会有比较直接的支撑，而我们做技术驱动的整体思路，就是把工程效率中的每条线、每个子模块，都去做动态化、配置化、工具化、自动化。
从发布到运维，从测试到自动化。通过一系列的工具化，首先大家有成就感，借助工具提高工作效率；其次这些事情都有一定的技术挑战和技术深度，让整体团队的技术氛围得以增强。
画外音：复杂的事情简单化，简单的事情标准化，标准的事情流程化，流程的事情自动化。
3、系统稳定性
系统稳定性是一家公司的底线，如果一个线上系统经常宕机，相信不会做大做强。在稳定性上，除了形成很多固定的流程机制外，我们还通过一些优化策略，紧急预案来保证，包括测试 / 灰度、降级 /限流/ 容灾 / 回滚、监控告警等。
团队建设
1、团队项目管理透明化
通过白板或者jira需求列表，将团队中所有事务全部罗列出来，包括需求列表、迭代列表、问题风险列表等，把所有的信息透明化。
比如在白板左侧列出需求列表，中间写上迭代表，团队这一个迭代内需要完成的任务，之后列出团队目前遇到的问题及风险。另外，还有需求燃起图、迭代燃尽图等，便于查看每一个迭代图完成了多少个需求。还可以加上一份团队日历，标注出在迭代过程中的重要事项和重要时间节点，帮助我们能够看到团队中所有人的任务和进度。
2、个人激励
团队中每位成员都有自己负责的业务及系统，责任田机制，每人在自己负责的地盘有较大的自由度，精耕细作，待来年拿个好的“年终奖”。放权更容易激发团队成员的主观能动性，激发个人潜能。这样也能给团队负责人更多的时间精力统筹思考规划团队的未来方向，业务越做越大，脚步越走越稳。
了解团队成员的职业生涯或成长通道，按照这个方向帮助他提升个人能力。关注团队中的个人，给他尊重与认可。当然，这方面也需要团队的透明制度作为支撑。
3、考核机制
考核虽然比较敏感，也比较让人讨厌。但确是激发个人产出最有效的手段。想阿里巴巴实行的271考核，如果考核评到前20%，年底年终奖可能会拿到至少5个月的奖励，是不是很诱人。
考核是一把双刃剑，用不好很容易挫败人的积极性，甚至会导致员工离职。所以在设置合理绩效目标很重要，既要有一定难度，但也不能是镜中月水中花，难已实现。同时也要关注实现比例，如果年底，团队成员都超出期望实现自己的目标，那可就难办了。
考核一定要透明，切记不要搞暗箱操作，诚信规则很重要，否则很容易丧失公允力。
4、文档建设
工作中沉淀较完善的技术文档，这样后面有新同学入职后，可以自己熟悉业务，快速投入到工作中。
带团队要注意的问题
1、方向要明确。业务方向、团队目标，大家要达成一致，千万不要项目排的很多，让大家疲于奔命却又没有成就感。这样很容易导致人员流失
2、目标清晰。如果团队负责人都感到模糊的事情最好不要分配给下属，否则会让对方无所适从，要么不当一回事，不会引起重视。如果是调研型工作，要跟下属明确需要完成的目标，这样才能保证效率和产出。
3、优先级一致。作为团队负责人，任何时候面前只要超过一件事，心中肯定有优先级之分。这个优先级需要清晰明确的告知团队，并且就此与团队达成一致，避免因信息不一致或者大家的认识不同，引起不必要的扯皮，耽误事儿。
4、多跟业务沟通，时刻关注业务动向，提前做好技术储备，避免一些让人措手不及的复杂任务从天而降，尽量减少搞突击。
5、留出弹性空间，项目适当留些buffer。避免一些突击项目搞的你很被动。
6、技术就是生产力。鼓励团队多开发一些提高效率的小工具，例如自动化测试脚本、部署工具和一些解放人力重复性工作的小程序。
往期推荐
关注【微观技术】
我们热衷于收集&分享高并发、系统架构、微服务、消息中间件、 RPC框架、高性能缓存、搜索、分布式数据框架、分布式协同服务、分布式配置中心、中台架构、领域驱动设计、系统监控、系统稳定性等技术知识。
关注公众号，后台回复“中台”，下载PDF学习资料
