怎么优雅解决项目Delay和交付质量差的问题
这篇文章给大家介绍怎么优雅解决项目Delay和交付质量差的问题，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
为什么要写这篇文章
做了这么多年项目，参加过无数次团队内外的项目复盘，发现不少项目延期和客户交付质量的问题。这些问题给产品和技术负责人带来了不少应急"救火"的困扰。分析这些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客户验收项目：珍惜客户&重视团队文档交付质量；
关于怎么优雅解决项目Delay和交付质量差的问题就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
