当我在做技术管理时我在做什么

阅读Tips: 本文是我根据这么多年来的实际开发、技术管理经验的一些总结，完整阅读需要30分钟，已经整理成简书专题《当我在做技术管理时我在做什么》，可分章节挑选感兴趣的部分阅读。

序言

个人介绍：

联合创始人 & CTO，目前管理20多人的技术团队，从事Web开发12年，使用过Perl、ASP、PHP，从2007年开始使用Ruby开发，主持开发过音乐上传下载网站、网页游戏API、症状疾病检索网站、CRM系统、数据可视化、在线GTD项目、任务管理系统、在线教育、在线呼叫中心、在线商城、商品采集和点评、地方门户类网站、定制微信公众平台、iOS多媒体终端、国外多种社交网站API数据分析等，目前专注敏捷团队管理。

企业背景

公司创立于2013至今，主要从事Web、移动应用、微信公众号的定制、外包开发，主要使用ruby/rails/git/linux等编程技术，推行敏捷风格的开发管理，使用自动化部署、各种共有云服务，使用Redmine、Trello、Slack等流行的项目管理、沟通工具，客户分布中国、美国、德国、澳洲等地，涉及领域广泛（见「图2-2」）

∆「图2-2」2016年项目领域统计

工作范畴：

“大内总管” - 公司的内部管理者，负责技术管理、团队管理、项目管理

管理的目标：

我所做的一切都是为了提高开发效率，让项目成功交付

目标意义：

• 提高开发效率 -> 我们开心！
• 项目成功交付 -> 客户开心 -> 爽快结款 -> 大家开心！

管理什么：

众所周知，一个企业中CEO主要管四方面：人事物财

那么对于CTO呢，我认为也是管四个方面：人事物文

分别对应为：

• 人 - 团队管理
• 事 - 项目管理
• 物 - 技术管理
• 文 - 文化建设

下面分别讲一下四个方面的管理。

人 - 团队管理

核心思想: 以人为本

团队是由一群追求一个或多个共同目标的人组成，通过一些规则约束在一起工作。人多不一定是力量大，也可能是人多手脚乱。要让一个团队高效协作，核心原则必然是以人为本，让每个成员在自己的位置得到最有效发挥，让个体与整体相互触进成长。

我把团队管理分为6个方面：

1. 定组织架构 - 要招什么人
2. 招聘 - 怎么招人
3. 培养 - 招到的人怎么培养
4. 考核 - 要不要继续培养
5. 效率管理 - 要培养成高效人材
6. 情绪管理 - 是人就有情绪

1. 定组织架构

所谓“成大事须合乎天时地利人和”，其中天时不如地利，地利不如人和。所有事情归根都是由人来推动执行，因此一个团队首先要有适合的人。

那是不是马上要讲讲怎么招人吗？不急，首先看公司的业务方向，根据公司发展的需要来选则所需要的人材组建团队。
所以成熟团队的管理方案中第一件事应该先定好组织架构，定下企业需要的岗位、职责、需要的人数。

这点其实跟做产品开发流程很像，得先有原型、设计图，然后才做实际的开发实现，实施成本才可控。

组织架构的科普：

企业组织结构是进行企业流程运转、部门设置及职能规划等最基本的结构依据，常见组织结构形式包括中央集权、分权、直线以及矩阵式等。
企业的组织架构就是一种决策权的划分体系以及各部门的分工协作体系。组织架构需要根据企业总目标，把企业管理要素配置在一定的方位上，确定其活动条件，规定其活动范围，形成相对稳定的科学的管理体系。

组织架构的作用简单来说就是公司的骨架，自上而下明确各个岗位的职责、管理范围、责任链，因此不宜经常大动大改。

公司成立了3年多，目前做了2次调整，「图3-1」是公司 2016年底定下的组织架构中CTO负责管理的开发部分

∆「图3-1」组织架构

2. 招聘 - 招人其实也是个技术活

有了组织架构（设计图纸）后可以招人了，然而招人这件事本身就是个技术活！

从哪里招？同行那么多要发什么样的招聘文案才吸引人？面试时要问什么？怎么知道对方是不是有料？什么样的人适合留下来？要给多少钱？

一大波的问题迎面而来！

有效过的招聘渠道大概有3种：内部推荐，专业招聘网站，社区论坛。

从实践结果来看，其中内推的结果最为靠谱。为了鼓励更多的内推，我在公司内提出推行了内推奖励机制：通过内部推荐应聘成功的，在试用期转正后，推荐人可获取一定现金奖励，奖励力度跟被推荐人被评定的职位等级挂钩，也就意味着引荐越有实力的人，引荐人则有高的回报，企业也能收获更有实力的人材，对企业而言是小投入高回报的策略。

另外为了让招聘文案“新鲜刺激有内涵”，在众多的招聘帖子中能吸引到小伙伴的眼球，我曾煞费苦心收集了大堆团队的日常照片，从中挑选一些有代表性，给每一张配上适合的解说词，合并成了一张457x8419 像素的巨长图（「图3-2」），得到一波好评的同时也给公司了一次PR。

「图3-2」 公司的日常（@2015.4）

不同的技术岗位需要掌握的技术技能自然不同，因此刷选时也需要面试官对面试岗位技能都有所掌握，然而每一门技术的技能树各不相同，如「图3-3」。

∆「图3-3」前端工程师技能树

技术岗位都需要定一些面试题目来提高候选人筛选效率和标准化结果评估，因此我根据需要的引进的岗位制定一些面试题文档：

• [公司前端面试题v2015-08-27]
• ruby开发面试@2016-10-09.md
• react-native开发 面试.md
• 开发运维面试.md

内容涉及对应岗位的编程知识、项目开发的流程及协作方式、解决问题的方法等，考察候选人当前的编程水平、项目经验、学习能力和工作态度，用以判断加入公司后的培养成本和周期。当然大家都知道，只是通过交谈是无法百分比准确的判定一个候选人是否完全符合预期，只有真正在一起工作时才能了解彼此。

目前所有进入公司的技术人员都是由我亲自面试过，因此引进的人员在技能方面是比较有把握的。

面试的过程其实很占用人的时间、精力的，对于每位上门的应聘者，我都会耐心的引导，避免由于面试的紧张导致应聘者没有发挥好从而给出错误的结论。因此即使没有面试通过的，也得到比较正向的反馈，见「图3-4」

∆ [图3-4] 面试反馈

最后面试的人多起来了，我们需要安排一面、二面流程提高面试效率，这时也需要制定一些流程规范来标准化从而提高招聘效率，因此我也将这个流程指定成规范文档，见「图3-5」：

∆ 「图3-5」公司招聘流程

除了专业技能，我认为优秀员工的重要的品质有2点：

• 责任心
• 主动性

但这些是从短短一个小时的面试过程中是看不出来的，因此还要涉及到对新入职员工的考察，后面一节会讲到我是怎么做。

面试通过后、谈妥了offer后，就是入职安排。
入职过程不是到公司报个道就完事了，有相应的入职的流程、需要不同的人协作，如要安排Mentor、分配帐号、满试用期后考核等等，因此我提出并制定了一个[公司新员工入职流程]，如「图3-6」

∆ 「图3-6」[公司新员工入职流程]

企业都想找到适合的员工，所谓适合，其实就是有能力、企业能给得起钱。企业主不应总是对应聘者挑剔，懂得要马跑就要喂马吃饱的道理，这点是每个企业主自身要做好的准备，双方各取所需、共同成长，企业赚钱、员工涨薪才是最大的共赢。

3. 培养

经过了面试双方谈妥，人员入职到岗了，不能丢在一边“放养”。要想让新人尽快通过磨合，熟悉开发流程，掌握专业技能，尽早能独立完成开发任务，我采用以下几种方案：

• 引入Mentor制度
• [公司 新人提点注意事项]
• code review：[Code Review Tips]
• pair programming
• 内部培训、分享
• 官方blog
• 外部技术交流会

引入Mentor制度

Mentor制，是指定了一名同类岗位、高一级别的同事作为“导师”，来带领入职的同事熟悉开发环境、开发流程、代码规范等，让新人尽快通过磨合，熟悉团队、有归宿感。我不认可那种一来就直接指派个任务卡片，丢下一句“自己看代码学习，这周内搞掂”的放养式管理风格。将心比心，人到一个陌生的环境，都是期待能得到一些简单的指引，有时只有简单几句话，也会有种安全感。

[公司 新人提点注意事项]

这是我整理给Mentor的指导文档，一般的开发人员平时都只是做日常开发，一开始也不懂得如何指导新人，为了解决这种窘况，我整理了这么一份文档（「图3-7」），内容实际就是公司知识库WIKI中的一些内容的链接索引，另外特别强调了注意不要分享整个文档给新人，要锻炼他们自己的学习能力。

∆ 「图3-7」公司 新人提点注意事项

code review：[Code Review Tips]

我们在日常开发中鼓励并推行code review（代码审查）。

在每个项目立项进入开发阶段时，我会根据开发组成员的级别设定审查链，按照 “中级审初级，高级审中级，高级互审”，没有合适的人时我来审查，开发任务完成后，任务开发者需要发Pull/Merge Request给指定好的审查者进行审查和合并，确保每次代码合并前都有2个人能看到过，一般只有在做演示出现exception，需要紧急合并做部署时才会跳过code reivew流程。

推行code reivew需要有2个人以上的协作，自然是有代价的，那有什么好处？
见「图3-8」中我在公司WIKI [code review tips]中给的回答：

∆ 「图3-8」code review tips

相当于另一种pair programing，大家的编程水平都能提高（无论是提出问题的，还是被指出问题的）

让一个新人融入团队没有比在一起讨论代码更快的方式了，特别是对于新人而言，对代码规范不熟悉，通过code reivew能有效减少低质量代码的check in，对个人、对团队、对项目都是很有益的一项安排。

至于要怎么做好code reivew这件事，需要另开新篇来阐述，「图3-8」中有review代码的要点摘要，在这里就不展开了。

「图3-9」是我日常进行code reivew 发现问题的一些总结，在团队内也做过一次专题的培训

∆ 「图3-9」 code review examples

∆「图3-10」code reuse - DRY your codes

特别提一下，设定固定的审查链的好处是减少审查者的负担，每个人只需负责1~2个的代码审查；阶级式的安排，可以让高级的不用反复的去提点低级人的一些低级错误，反复指出一些低级问题对高级人员是负担也是干扰，容易累积高级人员缺乏成就感的情绪（程序员的一个特质是喜欢有挑战性的任务）。

pair programming

结对编程的好处不用多说，我鼓励结对编程，但不会强制安排，不会要求像教科书般要求在某个时间规规矩矩的一个看一个写，实际上一般的情景是某个同事有问题时，需要找我或作指导的其他同事，拿上电脑大家坐在一起讨论、直接敲代码（「图3-11」）：

内部培训、分享

团队的强大不能依赖个体，新知识只有一个人掌握时，不等于团队掌握了，分享出来团队技术才能成长。
在每周五下午，我会不定期的安排一些内部的培训，技术的、设计的、产品的，不限制领域，既是对个人的一次锻炼，又同时是给大家一个休息、坐在一起讨论的时间（「图3-12」）

∆ 「图3-12」内部培训

官方blog

知识的累积和巩固途径由浅到深可分为“听读写说”，但听别人说不如自己读书，读书不如动手练习写写，写不如说出来给别人听。能亲口说出来的知识掌握得最牢固，不过不是人人都有勇气在别人面前开口，因此我们设立了团队Blog，把掌握到知识“写”出来。

我会不定期给技术人员安排“功课”，给定一个主题和大纲，将一些开发的心得总结整理成博客文章，经我审查修订后发布到公司的博客上，这样即可以让当事人的知识更加巩固，又可以给其他同事作参考指引，另外还可以对外展示公司的技术能力和形象，可谓一举多得。

外部技术交流会

只是内部交流是不足够的，还要看看别人是怎么做的，做法很简单要么走出去要么请人来。
我们会不定期安排一些优秀的员工，参加的一些技术沙龙活动开拓眼界和学习。

我们会邀请其他企业的、行业的技术专家过来，给团队分享技术上的、产品上的、团队管理上的经验。

交流应该是双向的，我个人也会被邀请到其他技术团队、交流活动分享我的技术经验、心得，让外界了解公司技术实力。

我自己曾作为2015年的Rubyconf China活动讲师，跟现场300多ruby开发者们交流（「图3-13」）

∆ 「图3-13」Rubyconf China 2015

4. 考核

前面提到，除了专业技能，我认为优秀员工的重要的品质有2点：

• 责任心
• 主动性

但这些是从短短一个小时的面试过程中是看不出来的，因此还要涉及到对新入职员工的考察和审核，试用期就是很好的一个让双方了解磨合的阶段。

在前面提到的[公司新员工入职流程]中，我要求Mentor在试用期结束后，需要对新人进行评价审查，而评价审查的大纲很简单：

1. 基础
2. 学习能力
3. 态度
4. 交流

1是考察当前能力水平，这点在面试时已经大概了解，相当于验证一下是否有水分，短短的试用期内也不大可能突飞猛进；

2考察个人潜质，对个人发展很重要；

3是看责任心和态度，遇到问题会不会主动找人反馈或协助？交代的任务超出预期时间不能完成有没有主动反馈给项目组长？

4是考察团队协作，对团队重要，有些程序员动手能力强但比较内向，沟通能力略有欠缺的，那就可以安排不需要很多沟通需要的任务。

一般初级安排1到2个月的实习，但基本上1、2周都能看出一些问题了，这时我是愿意给机会调整，看重后续的成长，但如果到了实习结束期都还是不行的，那就只能劝退了。

审查内容只有4点，因为写评价报告这件事对Mentor是开发工作之外的一种负担，我尽量简化文档/报告的复杂度，减少干扰，接下来效率管理就会提到具体怎么做。

5. 效率管理

核心思想：减少干扰

程序员最烦什么？最烦的不是任务有多难多重，而是在写代码时被干扰打断。为此我需要从沟通方式、工作流程、协作方式各种方面来解决干扰的问题，我大概归纳为“四化”：

• 沟通明朗化
• 工作流程化
• 开发自动化
• 协作清晰化

沟通明朗化 - 限定沟通工具、使用好工具

为了减少对开发人员的打断，可以把需要沟通讨论的内容根据“轻重缓急”，粗略分为“紧急且重要”，“紧急不重要”，“重要不紧急”。

• 紧急且重要的，就当面沟通。面对面沟通是效率最高的，然而这种情况也是最干扰的，因此应该判断好沟通内容是否确实那么紧急且重要；
• 紧急不重要的，但期待对方尽快有反馈的，我们鼓励在企业IM上进行对话，这样对话内容以后还有历史记录。至于企业IM，我们团队目前是使用Slack，支持@提醒、公私分组、代码片段高亮、各种服务跟chatbot集成，强烈推荐技术团队使用（见「图3-14」）；
• 重要不紧急、需要存档或者不期待对方马上给反馈的，就建议使用Email，常见如一些重要公告、会议记录通知。
• 其他的如任务反馈、code review的留言等，不需要马上有答复的，只需要在任务管理工具上留言，这样有源可塑。

∆ 「图3-14」Slack example

另外还有一点要提的是，作为管理者应该有意识的界定IM工具的使用场景，我们工作时间使用Slack，这样只要是通过Slack发过来的消息，我们能第一时间意识到是有工作相关的问题需要讨论了，以便能及时作出反馈。Slack中按项目建立分组，所以往往只是看到消息是来自哪个分组，不用看消息内容，就以及知道大概是要讨论什么内容，自然在脑中切换上下文，提高沟通效率。

不建议使用微信/QQ作为企业内部的沟通工具，由于微信/QQ混合了非工作消息的通知，开发人员不能很好的区分开这是有工作消息、还是普通社交聊天消息，很容易错过重要的工作信息。但有人会说跟外部的人沟通时是避免不了使用微信/QQ，注意，这里说的是“企业内部的沟通工具的选择”，对外该使用什么的还是用什么，两者并不冲突。

工作流程化 - 不要每次都让我告诉你什么时候该做什么

在团队中，特别是进行软件开发项目时，需要有一定的流程指引，那么大家在一起进行工作时可以分工、分步协作，清楚知道自己、别人下一步会做什么，自己会不会被干扰，从而提高协作的效率。
为此我根据我们公司实际的需要，制定了一些规范文档，从接到项目需求，到项目评估、立项、开发、具体到代码提交、部署、验收都做了流程规范，例如：

• [公司开发流程规范] - 规范了从需求确定、项目评估、项目确立、开发、验收交付到项目结束总结各个阶段的各角色的工作内容范围和输入输出的文档，见「图3-15」
• [公司招聘流程] - 前面提到过了，见「图3-5」
• 开发流程图 - 创建feature分支 -> 提交PR/MR -> code review -> 部署staging -> QA -> 部署production
• 提倡git flow - 使用Github/Gitlab flow，代码提交使用Pull/Merge Request来进行code review

∆ 「图3-15」公司开发流程规范

定好工作流程，大家都能从中找到自己的位置和角色，知道在什么阶段要做什么、下一步做什么、要跟谁协作，不能有“一头雾水”的感觉。

开发自动化 - 把重复丢给机器

我提倡善用工具最大程度做到自动化，这种思维是贯穿整个开发流程各个环节的。

如最普通的Terminal（终端shell），推荐使用带交互的shell（如zsh/Fishshell）来辅助cli的操作，鼓励善用alias来简化重复的使用命令；

代码开发时鼓励使用支持自动完成的IDE、编辑器（如Sublime Text），鼓励善用代码snippet来减少重复编码的操作；

代码测试使用自动化测试（可配合guard或者livereload达到保存时自动跑相关测试）；

代码提交使用自动化命令（gitlab-send-merge-request of git-cmd-helpers），一步完成代码提交并发Merge request；

项目部署使用自动化部署工具（如Chef、Capistrano），做到一键部署；

使用CI（GitlabCI）进行自动化测试、自动构建、构建结果通知、自动部署、自动打包上传app package，达到DevOps的自动化；

服务使用健康监控（如Monit，God），自动监测服务健康并自动重启服务；

一句话就是尽量把重复的工作丢给机器去做，人力应该专注在机器解决不了的地方。

协作清晰化 - 让你知道什么时候要去找谁做什么

为了解决协作清晰问题，我们使用3种管理方法：

• [公司 Agenda] - 团队共享日程表
• [公司 collaboration] - 团队协作（非特定项目）任务管理
• project board - 具体的项目管理布告板，在后面的项目管理章节中会具体提及

一个项目开发时必定会定下一些关键的时间节点，如什么时候开会讨论、什么时候开发结束、什么时候做演示、什么时候正式上线；公司内必会有人员活动的变化，如公共节假日怎么安排、团建、什么时候有面试安排、团队成员中必然会有事生病请个假什么的等等。
为了让这些跟时间节点、会影响到人员在线情况的事件在团队中清晰透明、避免冲突，我在公司里发起推行了“团队日历共享计划 - [公司 Agenda]”（见「图3-16」），这样大家都能有个清晰的预期，知道最近有什么短期目标、有什么事需要准备、什么时候有会议要开、哪个小伙伴会没有空。具体做法很简单，使用Google Calendar服务进行日历共享，客户端使用Mac Calendar查看，约定好事件的标题格式“[公司名-项目名] 事件类别: 事件标题”。
另外注意一点，在推行新制度时，使用流行的服务和系统自带的工具，可以降低推行阻力。

∆ 「图3-16」公司 agenda

但日历只能也只应该记录事件标题和日期时间，更具体的内容，我们在Trello上建了一个board来进行管理，如我们的团队分享安排、团建安排、假期的安排等。

至于更具体的项目开发任务，我们是使用独立的项目管理工具，在后面的项目管理章节中会提及。

6. 情绪管理

是人就会有情绪，了解员工的情绪问题也是管理工作的日常之一。在公司还没有强大到有专职的“程序员鼓励师”时，也只有亲身上阵，我推行了3种方式：

• 员工一对一谈话 - 聊天是舒缓情绪很简单有效的一种方式，无论工作问题、生活问题，都可以坐下来面对面聊一聊，讨论下解决方法
• 员工年度调查 - 有些话不适合、不方便当面说的，那么可以写下来，为此我发布过[2015年 公司员工年度调查]，收集对工作流程、工作环境、薪资待遇、公司发展建议等
• 户外团建活动 - 离开工作环境人的情绪会得到放松，为此我拟订过[公司2016团队建设活动计划]

我自认为在这方面做得还不够好，InfoQ上有篇文章《技术团队的情绪与效率》 值得参考借鉴。

事 - 项目管理

前面团队管理中说“团队是由一群追求一个或多个共同目标的人组成，通过一些规则约束在一起工作”，而项目管理则是为了让团队能在资源、人员限定的情况下，能按预期达成目标的手段和方法。

核心思想：有的放矢

项目管理的注意3点：

1. 目标清晰 - 要做什么、什么时候完成
2. 控制节奏 - 有了目标，就要管理好节奏，是一步到位还是小步快跑
3. 制定规范 - 无规矩不成方圆，现代化团队作战讲究统一、标准、量化

1. 目标清晰

在项目开发中，有3点需要清晰：

• 需求清晰 - 要做什么，做给谁用，做成什么样
• 任务清晰 - 安排什么人，在什么时候，具体做什么
• 节点清晰 - 要在什么时候做完

针对以上这3点我制定了以下文档、规范：

• 明确需求 - [公司 PRD文档规范]
• 明确任务 - [公司 Trello使用规范]
• 明确节点 - [公司 Agenda]

下面分别说下具体的做法。

[公司 PRD文档规范]

PRD（产品需求文档），相当于是产品的工程设计图纸，是给开发人员使用的，它的主要目的是陈述产品是什么，有什么功能，给什么人用，是什么样子。因此我认为一份PRD中应包含以下7部分：产品说明文档、产品信息结构图、产品功能结构图、逻辑流程图、原型图、功能点列表、设计文档，如「图4-1」，主要是说明每份文档是什么、有什么用、大概长什么样。

∆ 「图4-1」公司 PRD 文档规范

开发人员常说我不怕需求复杂也不怕需求太多，最怕的是我费心费力使用了优雅的设计模式、重构了代码、加了单元测试后PM对我说句“xx需求不要了”。所以如果作为产品PM，当整理过一份完整的PRD后，其实已经对产品的逻辑性、合理性做了一次梳理，再传达到开发团队手里时，能有效减少返工、无效需求的“折腾”。在这里要认清的一个事实就是：没有不变的需求！所以我们要做的只是尽量减少无效需求传导到开发手中，让开发的输出更有价值。

[公司 Trello使用规范]

Trello是个看板风格的协作工具，上手十分简单，但由于Trello本身十分松散灵活，100个团队有100种用法，因此为了方便统筹管理，我制定了一些使用流程并整理成规范文档[公司 Trello使用规范]（见「图4-2」），包含对list、label使用以及card生命周期的流转，让每个任务从需求转化为任务，到分配、评估、开发、部署、测试、上线，意图让每一步都清晰可预期，参与员之间协作配合清晰可见。
我们的项目管理布告版也会对客户开放，我们希望让客户从一开始就可以参与到日常开发流程中，可以了解项目的开发具体进度，也方便收集对需求任务的讨论、BUG反馈，以及给客户分配一些他们所要配合的工作（如一些基础服务帐号注册），让协作由内而外都可以贯通。为此我特意把这个文档写了英文版，以发放给国外合作的客户参阅以便了解我们是怎么使用Trello的。帮助客户培养成合理的协作习惯，这其实对我们进行高效项目管理也会更有利。

∆ 「图4-2」公司 Trello使用规范

[公司 Agenda]

一个项目开发，需要定一些时间节点，如什么时候正式立项，以便项目经理可以召集开发团队、召开立项会议；什么时候做交付演示，以便让QA工程师可以准备用户故事；什么时候正式上线，以便项目组技术组长可以准备交付文档；时候做营销推广以便运维人员可以做好服务器压力测试调整服务器配置……

前面在说如何解决团队协作清晰化中，提到了使用“团队日历共享计划 - [公司 Agenda]”（见「图3-16」），因此我要求项目经理给每个项目添加2种事件类型，一个是CHECKPOINT（检查点），一个是DEADLINE（最后期限）。CHECKPOINT是阶段性的时间节点，DEADLINE是当前版本最终的交付限期；一个开发版本内可以有多个CHECKPOINT，但只有一个DEADLINE。

做事应有始有终，我要求每个项目的每个大版本开发，都要定一个DEADLINE（最后期限），期限是构成目标的要素，没有期限则没有目标，没有目标何从谈管理。

CHECKPOINT则是一些阶段性的目标，到达一个DEADLINE之前，可以有多个CHECKPOINT；一个CHECKPOINT可以是任何关键事件，如阶段演示、交付演示，可安排阶段小结会议来讨论技术问题调整开发计划。

个人todo管理tips

在日常工作中，往往又有一些个人的代办事项，如某项技术调研、培训文档准备等不适合放入协作的任务列表的，也要管理起来，我现在的做法如下：

• 不需要协作的，放入 Wunderlist（可跨多终端）;
• 需要team范围知晓的、有明确日程安排的，放Agenda;
• 跟具体项目相关的，放在对应的项目trello board

2. 控制节奏

项目开发有如组织团队赛跑，需要控制好节奏，什么时候要留力调整速度，什么时候要加速冲刺，都应该有规划。

我根据这些年来的项目开发经验，整理了一份开发流程规范 [公司开发流程规范]（见「图 17」），划分出几个阶段，每个阶段有主要参与的角色及其主要任务、有输入输出的结果，以便项目参与者明确自己角色的任务。

项目开发流程大纲：

- 选定项目管理框架/风格：Kanban + Scrum
- 选定项目管理工具： 
    - 默认：Trello + Scrum Extension
    - 其他：Redmine，Teambition，Worktile，Tower
- 角色安排：项目经理，产品经理，项目组长，开发，测试，运维
- 流程安排：
    1. 需求确定 - 确立需求可行性
    2. 项目评估 - 根据PRD评估开发量，确定项目周期
    3. 项目确立 - 项目组角色安排，项目周期、确定技术栈
    4. 开发    - 日常开发迭代
    5. 验收交付 - 交付项目，收集客户反馈
    6. 项目结束 - 进行项目汇总，总结开发收获、工作流程改进意见
- 会议安排：
    * 项目启动会议 - 成立开发组、通告项目背景、周期、技术栈
    * 项目阶段会议 - 阶段性小结，了解当前实现进度及出现的问题，调整下阶段的目标和做法
    * 项目总结会议 - 进行项目汇总

∆「图3-15」公司开发流程规范

3. 制订规范

所谓无规矩不成方圆，在一个完整的开发流程中，每个环境牵扯到不少细节，团队会不时增补新人员，要形成统一的团队风格，少不了要制定一些规范文档，让团队每个成员可以达到一致的行事风格和输出，其他对接同事协作时则有规可循。特别的，一些输出文档我都给出了样例，这样负责输出文档的同事只需做“填空题”，关注输出内容本身即可。

以下是我制定的跟项目开发流程相关的系列文档例子：

• [公司开发流程规范]（见「图 3-15」）
• [公司 PRD文档规范]（见「图 4-1」）
• [公司 Trello使用规范]（见「图 4-2」）
• [公司 Trello board template]
• [公司项目周报规范文档]
• [公司阶段小结会议规范]
• [公司项目总结会议规范]（见「图 4-3」）
• [公司项目总结报告规范]
• [公司会议记录书写规范]

∆ 「图4-3」公司项目总结会议规范

小结

如果有一些成熟完整的项目管理工具，可以辅助解决一些流程的规范、自动化，自然会省事不少，但工具很重要也只是辅助，我接触了解过一些开发团队，使用了一些复杂、强大的项目管理工具，然而管理层不去推行、监督，执行层不落实执行，工具再多再强大也是没有意义。因此在工具的使用上，适合自己团队的才是最好的，不用过于纠结在工具选择上。例如，我们使用Scrum管理框架，但也不是完全照搬Scrum全家桶，我们有每日站会、有Sprint 评审/回顾会议（我合并为“阶段小结会议”）、使用Backlog列表、任务评估使用Story Point、使用User Story做验收交付文档，没有Scrum Master（但有项目组长），根据团队的实际情况做了简化调整，可以落实执行的方案才是好方案。

总的来说，即使团队只有一个人时，做事也应该有章法，才能做到事多不乱，团队壮大了再由己及人，保持团队一致的调性。只有做到以上这些，我们才能从复杂多变的环境中做到“有的放矢”，从容应对变化。

关于项目管理有几本书推荐阅读：

• 《最后期限》 —— 被称为“中国第一本项目管理小说”，以一个虚构小说告知项目最重要的4个要素：找对人，分配正确的任务，激励，团队建设。
• 《人月神话》 —— 本书自第一版以来，畅销20余年不衰，是软件领域绝无仅有的必读经典
• 《Scrum权威指南》 —— 不到20页的文档里简明阐述了Scrum是什么、怎么进行Scrum，特别是在2016年版引入了“Scrum价值观”的概念，鼓励团队成员相互敬重，彼此成为更有能力和独立的人。
• 《技术管理之巅 : 如何从零打造高质效互联网技术团队？》 ——　1号店技术总监出品，推行扁平话、OKR目标管理、Scrum和Kanban的实践、自动化测试等，从技术团队组织架构、产品开发流程、制度规范建立、企业文化、大数据与技术管理创新、移动技术开发、实用应用架构设计等方面。

物 - 技术管理

核心思想: 喜新厌旧

• 喜新（Upgrade）：升级技术栈
• 厌旧（Migrate）：偿还技术债务

喜新（Upgrade）：升级技术栈

从事信息技术的都知道摩尔定律，然而这个定律不止作用在芯片更新换代上，在编程领域也是可适用的，几乎每年都有一些新编程语言、技术框架、系统架构的出现，其中一些有重大突破性的还能引起热潮。对于技术团队，其能掌握的技术栈就是其战斗力，而今年掌握的很有可能第二年就变为过时，因此一个有活力的技术团队是需要不断吸收外界新鲜有活力的技术点，吸纳融合入团队技术栈，转化为团队的战斗力。

然而新技术会不断提出、旧技术会迅速过时，我们既不能被新技术牵着鼻子走又不能过于落伍。因此在选定技术栈时需要具备有前瞻性，不能被新热的技术吸引分散精力，也又不能把团队绑定到一些没有生命力的技术上，这不是简单的选择题，需要经过探索、调研、实践到最后掌握化为生产力。

厌旧（Migrate）：偿还技术债务

在项目开发过程中，有时会根据当时的人、财、物及知识经验限制等，对技术框架、架构选型做一些当时认为“最适合”的设计或选择，但随着时间推移，需求变更、经验提升、新技术提出等，回过头来会发现当时的“最佳实践”已经不适合了，有的严重更会成为推进项目的负担，这种情况我们称之为“技术债务（technical debt）”。

欠债要还，没有反思不会进步，因此要给团队“还债”的时间，团队才有进步。但这点在外包开发团队中其实是很难彻底实践，因为需要跟客户解释什么是“重构”，为什么要花时间去做一些没有明显输出的工作；又得在尽量不影响工期的情况下，定下更“正确”的架构，这也很考验架构能力。

所幸我们团队是以Ruby/Rails框架为核心技术栈，Rails框架本身就是fullstack且推崇最佳实践的框架，每年都有大版本升级，每次升级都会引入对提升开发效率、安全、代码质量的理念和实践。因此我们选择了Rails，就相当于在底层框架中有一支专业的团队不断的在维护升级，这也是为什么国内外很多创业团队喜欢选择Rails作为开发框架的原因，可以让产品开发者更多去关注业务实现，而不用太过操心底层框架的维护。
更重要的是，Ruby/Rails不止提供给我们快乐编程的体验，还指导了我们做事情的方式方法、看问题的角度：The Rails Doctrine - Rails 信条

另外遇到一些本身就是做技术开发的客户时，就会比较好沟通能得到认可，但这种优质客户是随机的、可遇不可求，更多情况是我们开发团队自己要提高自己的迭代能力，在每次阶段会议、项目总结时进行技术积累，把经验知识应用到新的项目上。

上面说了那么多理论，下面说下怎么做。

具体做法

作为公司技术负责人，我进行技术管理主要看以下6个方面：

• 技术调研 - 探索新技术、调研工作上需要用的服务等，以保持技术团队的先进性
• 技术实践 - 有实践过的技术才敢引入团队中，不要做拍脑袋决策
• 技术培训 - 得到认可的技术要推广和普及给其他成员，提升团队整体战斗力
• 技术复用 - 提取出可复用的技术点，进一步提高团队生产力
• 规范化 - 技术团队应保持一致行事风格，以降低沟通、代码维护、工具使用的成本
• 自动化 - 解放生产力，让机器去做重复工作，人力去做突破性工作

具体实践总结

以下是具体实践过的一些调研报告（report）、培训讲稿（ppt）、规范文档（doc）、知识库（wiki）、内部开源项目（project）以及公开博客文章（blog post），涉及的内容其实很多我这里只列出一些比较有代表性的、在团队内实践分享过的内容：

• 技术调研
  • report:[angularjs vs reactjs]
  • report:[2016 Rails popular app servers]
  • report:[chrome extension开发调研]
  • report:[Crash Reporting Service]
  • report:[React-Native Hot Update Services Research Report]
  • report:[流行云主机调研报告]
  • report:[国内外流行字体CDN调研]
  • report:[QingCloud 调研]
  • doc:[公司 技术调研报告规范]
• 技术实践
  • project:[jpush-ionic-demo]
  • project:[pushwoosh-example]
  • project:[公司team/react-components]
• 技术培训
  • ppt:[how to do model design]
  • ppt:[toolbox-for-optimizing-rails-project]
  • ppt:[rails项目中性能调优要注意什么]
  • ppt:[rails-debug-tips 2016]
  • ppt:[如何写一份压力测试报告] （如 「图5-1」）
  • ppt:[如何用rails开发一个任务管理的网站和移动app]
• 技术复用
  • project:[quickstart]
  • project:[rails-composer]
  • project:[react-boilerplate]
• 规范化
  • doc:[公司 styleguide(公司代码规范指南)]（如「图5-2」）
  • wiki:[公司 coding standard]
  • wiki:[Code Review Tips] （如「图3-8」，「图3-9」）
  • wiki:[Rules for committing]
  • wiki:[trello + git开发流程规范]
  • wiki:[how to write a rake task]
  • doc:[Tech Stack Example]
  • doc:[API design example]
• 自动化
  • 自动化测试
    • blog post:[RSpec 使用一周小结（上篇）]
    • blog post:[RSpec 使用一周小结（下篇）——使用 FactoryGirl 准备测试数据]
    • blog post:[rails集成测试学习总结]
    • blog post:[rspec集成测试的总结]
    • blog post:[简介如何测试Rails应用]
    • blog post:[压力测试总结]
  • 自动化部署
    • wiki:[Deploy Project to Staging Using Capistrano on Ubuntu]
  • DevOps - 持续集成
    • wiki:[Setup GitLab CI]
    • wiki:[Setup GitLab CI Runner]
  • ChatOps - Slack+Lita

∆ 「图5-1」如何写一份压力测试报告

∆ 「图5-2」公司代码规范指南

重点说说自动化

自动化技术在技术团中对效率提升很重要，在前面的“团队管理 - 开发自动化” 这节已经提到了：

我提倡善用工具最大程度做到自动化，这种思维是贯穿整个开发流程各个环节的。

如最普通的Terminal（终端shell），推荐使用带交互的shell（如zsh/Fishshell）来辅助cli的操作，鼓励善用alias来简化重复的使用命令；

代码开发时鼓励使用支持自动完成的IDE、编辑器（如Sublime Text），鼓励善用代码snippet来减少重复编码的操作；

代码测试使用自动化测试（可配合guard或者livereload达到保存时自动跑相关测试）；

代码提交使用自动化命令（gitlab-send-merge-request of git-cmd-helpers），一步完成代码提交并发Merge request；

项目部署使用自动化部署工具（如Chef、Capistrano），做到一键部署；

使用CI（GitlabCI）进行自动化测试、自动构建、构建结果通知、自动部署、自动打包上传app package，达到DevOps的自动化；

服务使用健康监控（如Monit，God），自动监测服务健康并自动重启服务；

一句话就是尽量把重复的工作丢给机器去做，人力应该专注在机器解决不了的地方。

如「图5-3」就是我们团队日常开发中，从本地终端使用一行代码发起MR（MergeRequest），code rewivew通过合并MR，触发CI自动进行构建、测试、部署到通知Slack的过程

∆ 「图5-3」auto CI/CD

另外我们开发的Chrome Extension项目，也做到了的DevOps贯通、自动化发布，流程如下：

1. 开发在本地执行执行构建命令：gulp release --bumpversion，自动更新 manifest.json中的版本号、自动做git commit、同时自动以版本号创建git tag
2. 往Gitlab发起MR，合并到develop分支后，CI会自动加上--env staging为参数，应用上针对staging的配置，进行构建生成zip文件
3. 把develop往master合并后，CI会自动加上--env production为参数，应用上针对production的配置，进行构建生成zip文件
4. 在CI上构建生成zip文件时，会自动加上一些stamp（包括extension version，git revision， env，datestamp），如“Trellohub-0.2.2[staging]@2016-12-06^0b89f89”
5. zip文件生成完毕后，CI自动把zip文件上传到Trello board对应环境的card中；发布为staging的，放入packages-for-staging card以便可以给QE进行QA；发布为production的，放入packages-for-production card以便给PM上架发布到Chrome Web Store

整个流程中只有第1、2步是需要人工参与（将来可优化成一步），其他步骤已全部通过CI实现自动化。

对于ios/android app构建发布，我也准备使用Appium做集成测试，使用Fastlane做自动化构建，配合Gitlab CI打通DevOps自动化。

自动化有助减少人工参与，提高效率的同时减少误操作可能，技术团队应大力推行。

小结

今年最大的变化莫过于前端圈的火热和容器架构的盛行，层出不穷的概念、辅助的工具，新技术还没来得及掌握转眼已经变为淘汰，但这也意味着对技术的细分越来越专业，同时也意味IT项目的工程化越来越专业。这是挑战也是机遇，项目越复杂、质量要求越高，对个人的要求也就越高，也意味着团队作战的作用越重要，这也正是PaaS/SaaS这类以打包服务为卖点的平台也更有机会。

文 - 文化建设

核心思想: “八面”玲珑

团队文化是指团队成员在相互合作的过程中，为实现各自的人生价值，并为完成团队共同目标而形成的一些行事态度、思考方式和行为准则。在技术管理方面，我主要是负责塑造技术文化氛围，并通过这些思想、准则来影响及推行“团队管理”、“项目管理”及“技术管理”等方面。

我眼中的工程师文化

所谓“八面”玲珑，不是指要把人培养成圆滑的人，而是我认为在一个以工程师为伍的技术团队中，应该建立以下八个方面的文化：

• 学习文化
• 创新文化
• 工程文化
• 工具文化
• 自动文化
• 脚本文化
• 开源文化
• 流程文化

学习文化

• 技术调研
• 技术总结

前面“技术管理”中说过要“喜新厌旧”，不断扩宽知识边界、填平知识短板，团队技术水平才能不断提高。对新出现、不熟悉的技术点要进行调研，出调研报告；对已经熟悉用过的，要做技术总结，使得经验可以复用。如何鼓励内部分享，外部交流、互通有无，在前面“团队管理”如何“培养”已经具体说过就不再展开。

创新文化

公司无创新则无独特的竞争力，这点大家都懂不多用解释。但我认为“创新”不止是说创造新的工具、组件，勇于使用新技术、引进新框架、打破陈规做法也是一种创新，能引起“有益的变化”就是创新，应该鼓励。

例如我看到我们有一个项目后端是ruby，前端是coffee语言编写，都有大量的类定义，新加入的开发人员上手会比较困难，为此我编写了一个文档构建脚本，能自动对2种语言的代码分别生成统一的YARD风格的文档，再合并在一份文档中，以方便开发人员查看熟悉程序结构，如「图6-1」

∆ 「图6-1」build app doc

这种有利于提高工作效率的改进在我看来就算是一种微创新。

工程文化

软件工程开发，从来不是写个“Hello World”这么简单的事情。一个完整的软件工程，需要考虑程序语言、数据库、开发工具、系统平台、依赖包管理、代码目录结构、设计模式、日志记录等方面，开发项目交付时，除了代码，还要功能说明文档、代码说明文档、单元测试、压测报告、部署说明文档。所以在我看来，一个开发框架的工程化成熟度，就是看以上这些方面的覆盖程度。

前面“技术管理”中说过了我们的Web 开发框架是用Rails，而Rails是fullstack的、从一开始就走工程化的风格，从初始化一个rails项目的第一步的命令： rails new MyProject --database=postgresql --javascript=jquery 看出它会期待你预先考虑好后端使用什么数据库，前端使用什么js库，当然这些参数都是可选，不选择则使用默认配置，Rails遵从CoC（约定优于配置） 原则。

再看一下rails 5自动生成的项目目录结构：

├── Gemfile          # gem依赖管理(Gem是Ruby领域的apt)
├── README.md        # 说明文档
├── Rakefile         # 构建任务管理入口（Rake是Ruby领域的Make）
├── app/             # 应用代码
│ ├── assets/      # 静态资源文件（js,css,img,font）
│ ├── channels/    # 基于WebSocket 的Pub/Sub实现
│ ├── controllers/ # 控制器，负责处理请求，调取Model，选择View渲染
│ ├── helpers/     # view 的辅助模块
│ ├── jobs/        # 队列任务
│ ├── mailers/     # 邮件内容
│ ├── models/      # 业务模型
│ └── views/       # 视图（HTML模板）
├── bin/             # 一些项目CLI命令、自定义脚本
│ ├── bundle*
│ ├── rails*       # 主要CLI，提供启动app server、控制台、生成器、运行测试
│ ├── rake*
│ ├── setup*       # 项目初始化脚本，一步完成安装依赖、数据库初始化、启动rails server
│ ├── spring*
│ └── update*      # 开发过程更新脚本，一步完成安装依赖、数据库迁移、清理临时文件、重启rails server
├── config/          # 各种配置，如启动方式、数据库配置、路由配置、环境配置、密钥配置、i18n配置
├── config.ru        # Rack架构服务调用接口
├── db/              # 数据库迁移改动、种子数据
├── lib/             # 独立的类、模块、app相关的rake任务
├── log/             # 各种日志文件
├── public/          # 不用预处理、可公开访问资源目录，如404.html,robots.txt
│ ├── 404.html
│ ├── 422.html
│ ├── 500.html
│ ├── favicon.ico
│ └── robots.txt
├── test/            # 单元测试、集成测试
│ ├── controllers/
│ ├── fixtures/
│ ├── helpers/
│ ├── integration/
│ ├── mailers/
│ ├── models/
│ └── test_helper.rb
├── tmp/             # 缓存、临时文件
│ └── cache/
└── vendor/          # 第三库、资源
└── doc/             # 文档存放目录，从rails 4不再默认生成，但可以通过`rake doc:app` 来检查并生成app代码文档

从所生成目录就能看出在 rails 项目里会涉及到依赖包管理、构建任务、静态资源处理、消息订阅处理、消息队列处理、MVC架构、邮件处理、提供CLI、i18n处理、多环境适配、Rack架构、数据库连接、数据库查询（ORM）、数据结构迁移管理、初始化数据管理、日志处理、单元测试、集成测试这些概念，几乎涵盖了一个Web项目需要用到的方方面面，可以大方说句使用rails的开发者相对是比较“幸福”的，因为有很多细枝末节的地方都已经有被考虑到，而且还在不断的补充引入新的feature。

我们使用的技术框架不止rails，在前后端分离的架构中，前端使用过Backbone/Angularjs/React & Redux，在移动开发中使用Ionic/React Native，但这些技术框架中有些没有很统一、符合要求的工程化规范，因此我安排整理了一些目录规范，例如：

• angularjs 项目目录结构规范文档
• react-redux 项目目录结构规范文档
• React Native项目结构规范

以便开发项目时更工程化、结构化，可以在新项目中可以复用架构、组件可以通用

工具文化

“工欲善其事，必先利其器”这句话我非常赞同。如果说任务开发是战场，那么开发者使用的工具就是他们的武器，把“武器”打磨得是否顺手就会成为战场生存的关键之一。我经常在团队中推荐并鼓励每个人都分享、推荐自己使用过、认为高效的工具，例如：

• Shell： zsh/fish - 交互式shell，提高CLI操作效率
• 代码提交： GitX - 我鼓励在代码提交时使用git的GUI工具如GitX而不是命令行，因为GUI工具可以进行代码整理，有利合理的代码提交记录
• 终端操作： TotalTerminal/iTerm - 随时随地可以进行敲命令
• 文档编辑：MacDown - 所写己所得、兼容github GFM格式
• API查看：Dash - 快速离线查看各种技术API文档，开发者必备
• 窗口操作：Spectacle - 多屏幕操作利器
• 应用访问：Alfred - 把Mac变成Google Instant Search 般的体验
• 图片编辑：Skitch - 一图胜千言，快速给截图加上注释
• 数据库操作：Navicat Lite - 支持链接mysql/postgres/oracle/sqlite/sql server，开发者必备
• 代码编辑器：Sublime Text/Vim/Emacs/Atom - 编辑器的选择对程序员而言是场“圣战”，为了找出“哪个才是最好的代码编辑器”，我特意在团队内发起过专题分享活动：“编辑器到底哪家好”——技术分享 @ 2015-01-10

自动文化

优秀程序员三大特质之一是“懒”，能用程序、脚本解决的，就不用手工，更有“以自动化为荣，手工为耻”的说法，常会出现花费几个小时的脚本去解决一次只要十几分钟简单但会重复的问题，作为管理者遇到这种情况不应该一昧的打压，因为这种思想就是以自动化思维去解决重复，前面“技术管理”章节中就提到过了自动化的重要性，从本地开发、到代码提交、测试、集成、部署、发布、监控等各个环节中都有加入自动化的操作，能执行自动化的都尽量推行自动化，提高效率之余减少人为误操作。

以现在的观点来看，一个技术团队中有没推行自动化技术，可以认为这个团队是否达到“高效”的检验特征之一了。

脚本文化

无论是作为Java，C++，.Net 这类静态语言的程序员，还是使用Ruby，PHP，Python，JavaScript 这类脚本语言的程序员，在开发过程中都会接触到Shell脚本（Shell Script），因此掌握一些基本的Shell脚本操作，可以有效提高工作效率。

除了可以使用上面提到的“工具文化”中推荐的一些交互式shell来提高CLI操作效率外，还应掌握一些简单的Shell语法，用以编写辅助开发的脚本。

最简单的做法是可以增加一些alias作为一些常用命令的组合，使用有语义的命名，配合可交互Shell的提示，很简单、很低廉的操作成本，就可以在很大程度上减少重复敲打键盘、错误输入。例如我给不熟git的新人建了个 git-cmd-helpers，就是增加一些常用git 操作的封装，用以提高git的使用效率。

开源文化

作为技术开发者，我们是技术开源社区的收益者（可见我发表的 blog post:公司用到的开源产品），因此也鼓励开源精神。我会经常在团队中鼓励在开发中使用一些开源组件遇到问题修复时，给源作者发PR，我们在github上也有发布一些开源作品。

流程文化

制订流程，是团队多人协作的基础，是“规范化”的细节，是“自动化”的前提。
在前面的“团队管理”提到工作要流程化，我制定了涵盖从招聘到入职、升退评价、招聘和入职流程；“项目管理”中我制定了[公司开发流程规范]、[公司 Trello使用规范]，涵盖从需求对接到项目结束交付；“技术管理”中提到[trello + git开发流程规范]，涵盖了代码提交流程、代码审查流程、部署流程步骤细节。

制订制度、规范的流程

同样的，在企业中制定一种新的制度、规范时，也应该遵从类似以下流程：

1. 调研 - 先看人家怎么做
2. 制订 - 自己要怎么做
3. 发布 - 跟团队说明是什么、怎么做
4. 执行 - 怎么说就要怎么做，最忌光说不练
5. 监督 - 了解执行效果，收集反馈
6. 修正 - 根据反馈意见调整细节，收集到足够多的改动后发布新版
7. 发布新版 -> 执行 -> 监督 -> 修正 ->（重复）

思路：跟写单元测试一样

• 编写测试代码
• 运行测试
• 观察结果
• 修正实现代码 -> 运行测试 -> 观察结果 -> (重复)

推衍：企业内所有的重大决策都应该如此推行

所以一个成熟的技术团队中，为了明确职责、分工清晰、减少冲突，是很有必要制定一些常用流程，并将之作为的规范文档沉淀下来反复推行实践，以下我制定过且形成规范文档的流程：

• [公司招聘流程] （见「图3-5」）
• [公司新员工入职流程] （「图3-6」）
• [公司开发流程规范]（见「图3-15」）
• wiki:[公司任务开发流程]
• wiki:[Trello + git开发流程规范]

小结

以上这八种便是我认为是对技术团队有益的文化总结。

企业文化建设能否建设好同样是门不简单的技术活，但更大程度上是受企业创始人、管理层影响，因此不同技术团队中即便是使用相同的技术栈，但由于创始人不同，所施行的管理理念、思考方式不同，执行结果也就不一样。因此我不认为有“最好”的团队文化，只有“最适合”的团队文化，因地制宜、量身打造的才是适合自己的。

总结

在最后做一下总结，我认为想要打造 高效 高质量 的技术团队，需要解决以下问题：

• 高效人员：
  • 持续深入
  • 专人专职
• 技术复用：
  • 经验复用
  • 代码复用
  • 文档复用
  • 团队复用
  • 产品复用
• 自动化：
  • 开发自动化
  • 测试自动化
  • 部署自动化
  • 运维自动化
• 规范化：
  • 流程规范化：开发流程，会议流程，交付流程
  • 代码规范化：代码编写，代码提交，代码审查
  • 文档规划化：需求文档，调研文档，会议文档
• 目标清晰：
  • 需求清晰，协作清晰，日程清晰，任务清晰，流程清晰 = 为了什么，跟什么人，在什么时候，做什么事，要怎么做