1.3 怎么启动项目

我们将通过项目的形式推动技术团队的代码质量提升。

一个完整的项目管理一般会有立项、启动、过程跟进、结项以及复盘等环节，这里不着重描述。本节重点看一下启动项目的一些关键环节。

项目启动是项目管理的核心环节，关系着项目价值能否得到团队认可以及项目能否在团队内顺利开展。虽然它一般有固定的模式和方法，但也会因环境、管理者、参与人不同而不同。

我们的项目启动策略是通过有趣的手段，让一线人员积极地参与进来，赋能他们解决方法，持续小批量地解决增量和存量问题。下面通过一些关键活动给大家解释清楚。

1.3.1 快开始，慢启动

项目启动的重点就是让核心成员（项目干系人）了解项目背景、认同项目要解决的问题、了解项目的推进策略、掌握项目实行过程中解决问题的方法、配合项目负责人达成阶段性目标。

其实，项目启动还有另外一个目的，就是让项目负责人能够得到授权，这就需要请来有“权力”的人。另外，若想让核心成员积极参与，可能需要让参与者尝到一些“甜头”，包括精神和物质方面。一个项目的失败，往往是开头没有做好这些，导致管理过程中项目负责人被动妥协，目标倾斜而失败。

综上所述，项目启动前要邀请有“权力”的人，整理好项目的背景和现状，告诉他们最终要达成的目标，一起商议好阶段性里程碑目标和实施策略，愉快而不失礼貌地将整个过程节奏掌控好。这样项目的启动就算成功了。

那就启动呗！

会前，我们准备了PPT，邀请了CTO和各团队核心成员，整理了问题和初步的里程碑目标，申请了项目经费，买了水果拼盘、小零食和矿泉水，通过会议邀请把大家约到了一个会议室，约定1h内结束。会议分4个环节，各环节已分配好时间。

1.3.2 站个台，明目标

此过程10min以内，最好5min。主持人的节奏把控很重要。

邀请CTO的目的很明确，就是让他强调为什么技术团队要做代码质量提升。会前，我们已经给他发邮件介绍过我们的方案以及要提升的指标。会上，他将加工后的想法介绍给大家，重点强调了项目的阶段性目标，并隐晦地点了几个代码质量比较差的团队，以及明确后续所有团队需积极配合效能团队做好代码质量提升。

看形势差不多了，主持人说道：CTO说得很重要，代码质量是我们程序员的底线，突破底线，岂不是很难堪。非常感谢CTO……（6min拿捏得刚刚好。）编写代码虽然是我们最拿手的，但也是我们最容易出错的，接下来我们详细讨论一下如何提升代码质量，大家可以先吃点水果，都是绿色产品。

顺利进入下一个环节。

1.3.3 观现状，探预期

此过程约20min，我们主要是观察现场反应，试探性地提出技术中心整体的代码质量问题。

此过程中，我们主要给大家展示技术团队代码质量现状。项目启动时，我们效能团队还没有任何管理平台，如下指标数据是通过Sonar平台汇总得到的。当时，技术团队的重点项目中大约有3000个固定的项目分支。

主持人：大家吃好喝好了吧？让我们一起通过如下3个核心指标，分析技术中心所有Git项目分支的代码质量现状。

1）项目分支代码安全性。技术中心3%的项目分支有严重的安全漏洞问题，而修复每个漏洞平均需要4天左右（Sonar平台评估计算得出）。

2）项目分支代码可靠性。技术中心52%的项目分支存在一般代码缺陷，11%的项目分支存在严重代码缺陷，而修复每一个缺陷平均耗费40min左右，随着时间的推移，发现和修复这些缺陷的时间会更长。

3）项目分支单元测试覆盖率。技术中心86%的Java项目分支代码单元测试覆盖率小于30%，并且有8%的项目分支没有任何有效的单元测试用例。（单元测试简称为“单测”。）

随后，我们又按照部门维度进行了相关指标的分析。

……

大家现场看到这些数据还挺震惊的，很多技术负责人都不敢相信这是自己部门的代码质量情况，有些人比较质疑指标计算精准性，有些人不理解指标含义，有些人甚至对指标的计算公式提出了挑战。这些都是我们预料到的，会前特别准备了如上指标的计算方法、含义和使用方法。这些声音很快都被压下去了。

若有些场景和问题一时不能应对，这句话可以帮你解围——就算指标的计算不精准或者指标维度不够丰富，但大家使用的都是同一套指标；至少从这方面来说，大家都是公平的；更何况大家不是为了计算的精准性，而是为了发现问题，不是吗？

一定要记住，启动会不是为了即刻说服大家，目的是让大家了解我们要干什么，大致如何去做。相信我，一切都会随着时势而变化，并且一定会变。这种代码质量提升方面的项目很容易被叫停，因为代码质量问题在一段时间内不会严重影响到业务。若技术团队出现人员调整、业务变动等，第一时间要暂停的项目可能就是不直接产生业务价值的项目。所以，项目工作要集中进行，并且要在一定程度上影响到技术团队。

技术团队若出现开始关注代码质量的信号，可能在一定程度上说明业务的发展速度已经允许技术存在短暂的缓歇，进一步说明业务在一段时间内得到了验证，相对稳定。

1.3.4 扣本质，强烙印

此过程约20min，如上隐晦地说明了技术团队研发人员代码编写能力不足的问题，下面强调一下引起这些问题的根本原因——技术负责人的代码设计能力和评审能力不足。

主持人：刚才的提问引发了大家深入的思考，我相信大家对这些指标反馈出来的问题应该有目共睹了。接下来让我们看看代码设计方面的问题。（这里不再赘述问题的细节，下文会逐步展开。）

主持人：我们随机抽查了技术中心的10个项目，涉及所有团队。通过这些项目发现了代码设计、代码框架方面普遍存在一些问题。

1）代码架构扩展性差。只要有新需求，开发人员基本是在原来代码的基础上进行修改，后续若需要重构此部分业务逻辑代码，就需要回归整个流程，比如项目A、B。

2）面向过程编程。很多项目表现出臃肿的Service层，比如项目C、D。

3）代码命名无规范。应该禁止使用拼音，尽可能体现业务含义，比如项目E、D。

4）代码注释无规范。类、方法、变量都要写注释，比如项目F、H。

5）代码日志规范没有统一规范。日志级别乱用，比如项目J、K。

……

随着主持人的现场展示，现场气氛渐渐凝重起来。

主持人故意暂停1min，缓解一下大家紧张的心情，随后又笑着说：这些问题想必各团队多多少少都会有，还是那句话，重要的是我们要想办法分阶段去解决这些问题。

此时，大部分技术负责人频频点头（意识到了问题严重性），他们是我们的帮手，要重点“协助”和“扶持”。但还有些技术负责人不在乎，认为团队的核心职责是面向业务交付，面向老板“编程”，配合大家就行。我们后续要拉拢这些人，要花时间帮助他们树立信心。还有些技术负责人看到CTO已经走了，开始高谈阔论，比如会讲一些之前他所在的公司怎么做的，领头羊互联网公司怎么做的。对于这些人，我们后续尽量争取，尽量协助，若确实搞不定，就交给CTO去解决。

当遇到第二类和第三类负责人时，我们首先不要回避甚至逃避，更不要放弃他们；其次要去争取他们团队下的小组负责人和一线研发人员，通过对一线员工的赋能，一样可以达成目标。

所以，代码质量提升的手段需要下沉，培养一线研发人员良好的研发习惯才是重点。

主持人：想必大家对代码质量都有了深入的认识，接下来我们看一下如何分阶段改进和提升吧！

此时，主持人将PPT翻向最后一页，也就是我们整理好的比较粗略的项目里程碑目标。

1.3.5 重过程，有效果

此过程约10min，重点要强调我们启动项目不只是随便说说，效能团队是认真的，不只是跟进度、做汇报，会告诉大家发现问题、分析问题以及解决问题的方法，并定期通过度量来帮助大家分析和改进，同时会深入具体团队，跟进问题的解决情况。

主持人：大家再整体回顾一下这些代码质量问题，我们整理了能反映这些问题的指标。

……

主持人：我们根据技术团队的现状和工作安排，初步梳理了这个季度的项目里程碑目标。

……

主持人：长远的项目目标和计划现在整理出来肯定不太现实，甚至我们觉得上面的里程碑计划也会随着大家的工作调整而发生变动。所以，我们先看一下下周大家要一起做的事。

……

这样，主持人带着项目核心干系人认识到了问题的严重性，初步制定了项目里程碑目标，详细说明了眼前要干的事情。最后，我们制定了沟通机制（比如，每周一下午2点开周会），并建了一个信息同步群，后续演变为了代码质量提升委员会的问题协调群。代码质量提升项目也算成功启动了。