教你优雅解决项目Delay和交付质量差的问题

本文做者：AIOps智能运维

做者简介

凌薇    百度云智能运维业务研发负责人

 

负责百度云Noah自动化运维平台和智能运维解决方案的探索，在服务管理、资源管理、变动管理和故障管理的业务分析和设计方面经验丰富，致力于推动AIOps在百度业务、公有云以及私有云客户的运维场景落地。

 

为何要写这篇文章

作了这么多年项目，参加过无数次团队内外的项目复盘，发现很多项目延期和客户交付质量的问题。这些问题给产品和技术负责人带来了很多应急“救火”的困扰。分析这些Case后，发现问题集中在如下几个方面：

• 需求界定不清晰、系统设计有缺陷、研发质量无保障、无效沟通耗时长，致使项目反复而且严重延期；

• 跨团队协做推进成本高，多团队交付进度出现Delay，项目总体目标不可控；

• 概要设计文档、API手册、产品使用手册和运维手册质量差，客户学习成本高；

咱们团队一般会使用项目复盘（Case Study）的方法来应对这些状况。复盘主要为了解决如下两个问题：其一，为项目延期和客户交付风险找到可行的解决方法；其二，给团队成员一些指导，避免同一个问题重复出现。固然，这些复盘工做通常在某个项目组内部开展，须要一种方式可以在多个项目组之间共享，这即是我写此文章的缘由。

项目管理和研发质量控制是一个比较复杂的系统工程，本文不会系统的讲解一些理论和原则，而是以实际案例为索引分享一下项目管理中常见的问题以及必需要采起的方法。前车之覆，后车之鉴，但愿能对新晋的项目管理同窗有些帮助。

案例一：多角色人员协做的业务项目

场景描述

某监控产品须要对多个Region的多个云服务（例如虚机、数据库组件、缓存组件、消息队列组件）提供多个指标趋势图对比查看功能。产品研发须要PM设计产品形态和逻辑，UE设计产品视觉交互，若干FE研发前端页面，若干RD研发后端业务逻辑，QA测试业务功能，测试经过后FE和RD联合上线。项目研发从预期的1个半月拖延至实际3个月。研发中经历至少5轮测试，发现2个产品缺陷，5个技术方案缺陷，低级Bug预估20+，Bug收敛速度极慢。这是一个极其典型的项目管理和研发质量失控案例，参与项目的多数是新同窗，研发流程规范上认知度严重欠缺。

为了便于你们对项目过程的理解，附注一下相关的产品设计、接口设计和低级Bug例子：

• 产品设计缺陷：PM产品设计时遗漏在趋势图上标注不一样Region的云服务名字，致使用户没法定位指标所归属的云服务实例。

• 接口设计缺陷：产品要求一个趋势图最多支持30个云服务实例的指标对比，前端FE接口参数检验限定为20个，后端RD接口参数校验限定为10个；趋势图指标数据查询不管用户选择的时间段多长，指标查询的粒度都是60s，致使在时间跨度很大的状况下，返回数据点过多页面渲染性能差。

• 低级Bug：选择实例和监控项以后能够查看趋势图，可是取消监控项选择以后趋势图未消失；时间选择框对趋势图展现的指标数据的时间段控制做用失效。

关键问题

• 产品设计和接口设计缺陷应该是在什么阶段发现？

• 低级Bug为何那么多？Bug收敛速度为何那么慢？

• 项目出现延期风险时，项目负责人应该在什么阶段管控风险？

解决方案

这个项目的关键是没有严格遵循常规的软件研发流程规范。

• PRD没有通过评审，PM简单画了几个原型图开始安排前端FE和业务RD开发，致使产品缺陷没有在PRD评审阶段发现；

• 前端FE和后端RD的接口设计没有完备的文档，没有通过充分的沟通；RD提测代码时没有通过总体场景的联调和Demo Review，致使低级Bug在测试阶段才暴露出来；

• QA的测试准入没有严格执行，低级Bug多的状况下，QA未实施测试打回；

• 技术负责人没有在项目即将延期时进行问题复盘，而是在延期两周后才跟进问题，错过了关键的项目修复时间，增长了不少没必要要的多人协做成本。

这个案例在不少新项目新团队成员中比较常见。对于多角色协做的项目须要执行严格的研发流程规范，需求相关的MRD，产品设计PRD，UE设计稿、整体设计和详细设计文档都需按照规范撰写而且通过团队评审，只有前一个环节经过才能进入下一个环节。尽早交流和持续沟通使开发人员得到对产品和业务的信息，始终遵照“及早发现，及早解决”的准则，如此咱们便能在软件研发过程当中价值最低的阶段修正问题。RD在交付QA以前须要进行系统联调和Demo Review，确保研发和产品设计保持一致。研发质量须要符合编码规范，而且有单测指标，单测的行覆盖率和分支覆盖率不达标QA能够拒绝测试。QA须要严格执行测试准入，对于低级Bug多的同窗不只拒绝测试，而且团队内公示项目中每一个同窗的代码质量。

项目管理者须要执行严格的研发流程规范，须要合理的安排项目的进度。一般的经验是为 1/3计划、1/6编码、1/4构件测试以及1/4系统测试，因此必定不要在前期的设计评审阶段和后期的联调单测阶段节省时间，否则会使得项目风险频发，脱离控制。任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外。你们一般指望项目在接近结束时，软件项目能收敛的快一些，然而，状况倒是越接近完成，收敛的越慢。一个风险问题的暴露，一个里程碑的进度偏离，最终会累积使得总体进度偏离很远。慢性进度偏离是士气杀手，及早的问题复盘，持续的信息同步有助于将脱轨的项目拉回到正常的轨道。

案例二：多团队联合解决方案实施

场景描述

部门成立一个近20个团队的联合项目，实施核心业务线的SCAR（项目代号）。该项目的主要目标是结合多个平台系统提供的能力，组合成一个复杂解决方案，帮助业务提高能力。项目的周期是一年，多个平台研发团队和十几个业务团队须要完成该解决方案的研发和业务落地。项目实施中的初期发现平台研发符合预期，若干个业务团队没有承诺明确的落地时间，或者承诺的时间由于团队的其余项目影响落后于项目预期。联合团队采起了紧急沟通，实施了一些双重汇报机制和指标管控方法，保障了项目如期交付。这个项目成功落地业务线取得了很是好的效果，做为成功案例在多个团队作项目管理分享。

关键问题

• 如何确保多团队目标的一致性？

• 如何跟进项目及时发现进度风险？

解决方案

多团队协做的一个重要问题是每一个团队都有各自的重点项目指标，SCAR项目只是其中的一个，也可能不是其重点项目，各个团队投入的关注度和资源不必定充分。在这种状况下，须要成立横向联合的虚拟团队，在多个团队的经理层面明确项目目标，使得该目标变成经理自身考核KPI中的一项，而且每一个团队还须要抽取出一名成员做为接口人参与联合项目。虚拟团队实施双重汇报机制，团队成员除了向各自的经理汇报之外，还须要向横向联合团队的负责人汇报，团队成员的年末绩效考核时，横向联合团队的负责人也会给出一份评价。这种机制能够确保各个团队的项目经理对项目的支持度，以及跨团队的成员在项目中有足够的投入和友好的协做。

由于涉及的团队比较多，多个业务团队的落地进展对横向团队负责人来讲是一个黑箱。横向联合团队负责人须要设定相应的指标监督项目进度和识别项目风险。关键的指标包括如下三类：

• 先行指标（Leading Indicator）：项目启动之初创建该项指标，明确到项目结束时SCAR系统具有的能力以及在业务线实施的覆盖度，经过这些指标能够引导项目负责人关注黑箱中该注意的事情。

• 线性指标（Linearity Indicator）：为了达到目标设定的理想进度指标，能够理解为项目分季度分月的KPI指标，好比系统研发的进度，好比业务线实施覆盖度。以业务线实施覆盖度为例，可能14个业务线，第一个季度实施4个业务线，后面的两个季度每一个季度实施5个业务线。设置线性目标是为了指导项目分阶段的进度，避免由于项目时间跨度过长项目风险总体不可控。

• 趋势指标（Trend Indicator）：以时间标准为基础，根据对过去的观察，从趋势中预测将来。例如，项目的初期系统易用性较差，业务落地的成本高，前期的业务实施覆盖度指标有可能落后于一开始设置的线性指标。通过一段时间的系统优化，业务落地的成本变低了，后期的业务实施覆盖度指标有可能快于一开始设置的线性指标。项目负责人须要周期性Review项目的趋势指标，及时协调资源，调整项目的进度和把控风险。

经过虚拟团队的双重汇报机制，经过设定项目的先行指标和线性指标，周期性Review趋势指标，能够帮助项目负责人在多团队协做项目中可以比较好识别项目风险和调度资源解决问题。

案例三：ToB客户验收项目

场景描述

团队承接了某个客户的平台研发，须要交付时提供完备的系统概要设计文档、用户手册和标准运维流程手册给客户。项目交付前期团队内部抽查了部分文档，发现一些文档内容的完备性、可读性和可操做性欠缺，急需规范和优化。为了保障对客户高质量的输出，团队陷入紧急的文档优化过程，不少RD和PM进入了加班“救火”状态。在ToB项目中，每一份文档都表明着对客户的承诺和服务意识，表明着一个团队的技术素养，须要认真对待。

关键问题

• 什么阶段该写文档？一个好的文档应该具有什么样的特征？

• 团队经理和项目负责人如何保障文档质量？

解决方案

概要设计文档须要在项目设计阶段产出而且评审经过，而不是在项目交付阶段进行补充；接口设计须要在研发以前完备而且通过评审；用户手册须要在实施客户培训前完备，具有良好的易读性，客户学习成本低；运维巡检和故障处理SOP手册须要在交付客户运维以前完备，而且通过演练执行。

一个团队应该有肯定的可执行文档规范，而不是每一个项目每一个团队成员想固然的自行发挥才华，交付质量良莠不齐。对每一个文档的维护也提供了项目的状态监督和预警机制，文档使各项计划和决策在整个团队范围内获得交流，也便于及时发现项目的问题。

概要设计文档须要明确项目的背景、名字解释、功能概述、性能指标、依赖的软硬件环境、系统的整体架构、系统核心业务模型、系统各模块交互的数据关系、各模块的功能概述、各模块依赖第三方服务的接口说明。

HTTP Restful风格的接口设计文档须要明确面向资源的HTTP URL设计方法、HTTP Method使用说明、HTTP Status Code使用说明、接口鉴权方法，接口输入和返回的各类参数说明、接口返回系统错误码的明确含义等。

用户使用手册须要场景化，有截图，须要明确给用户标识出错误使用的风险。运维巡检和故障处理手册须要步骤清晰可执行。

文档规范的执行效果须要有质量控制方法，否则文档规范就成了摆设。项目负责人经常使用的方法能够称之为“海关与监视器”，团队经理经常使用的质量控制方法是随机检验。

• “海关”是指咱们先设下重重关卡，文档惟有经过检验以后才能进入下一步的研发流程，若是文档没法经过评审，便被打回重作或者是废弃。概要设计文档和接口设计文档应该使用此方法。

• “监视器”是指咱们能够将不知足质量检测的文档内容标识上记号，这个文档将不会在流程中的各个关卡被截住，整个流程将会变得顺畅，在这种检测中，有问题的地方超过必定的量，则须要当即修订。对于用户手册和运维巡检手册中场景的覆盖度问题能够视状况采用“监视器”的方法进行多轮迭代。

• 随机检验就是随机抽查。由于项目不少，不一样项目负责人对文档把控的严格程度也会有误差，因此对于团队经理来讲，逐个文档检查的成本很是高，改变检验的频率也就理所固然。若是一个经理对他的下属事必躬亲，就可能形成干预，并且将会浪费更多的时间在不会出错的下属上。更糟糕的是，他的下属可能所以会造成依赖性——反正什么事情老板最后都会检查。随机检验应用在管理上，既能够增长项目负责人的责任感，又能够节省经理时间。

无论使用上述哪一种文档质量检查方法都是在培养团队的文档质量意识，由于交付给客户每一项质量差的文档均可能会致使客户的流失，也会影响团队口碑和产品品牌。

寄  语

以上是对几个典型项目场景下遇到问题的复盘思考，这些案例给咱们的启示以下：

• 多角色人员协做的业务项目：严格遵照软件研发流程&及早发现问题及早解决；

• 多团队联合解决方案实施：创建双重汇报机制&设定而且盯好业务指标；

• ToB客户验收项目：珍惜客户&重视团队文档交付质量；

但愿这些分享能够给新晋的项目管理负责人一些参考，避免一些没必要要的弯路。后续依然会持续关注团队的项目实施和分析，欢迎更多有兴趣的同窗一块儿讨论和分享。

原文连接地址：https://developer.baidu.com/topic/show/290334