项目管理：问题探讨与解决方案

这几年项目进度例会的模式，都是按照上篇《18-过进度方式一：项目负责人进行全部功能演示》的方式进行的，其目的也在上篇说明清楚了，都是从项目负责人的能力提升方面考虑的，其会议流程是这样的： 第一步，项目负责人把当前项目情况进行汇报，然后重点问题说一下。 第二步，每个项目成员在自己的座位上，说一下上周做的事情，下周计划做什么，遇到什么问题。 第三步，散会。 但是，不同的阶段关注的重点不一样。 在项目进度例会中，对当前所做的工作进行验收，是很重要的一环，这些也在《16-项目的任务质量如何保证》中，把前因后果也说明清楚了。 本篇主要是探讨让项目负责人把全部功能进行演示和让项目成员依次汇报任务进度和演示，这两种方式不同之处在哪里？ 首先，我们要知道，参加会议的人，什么样的心态都有。有的人现在遇到了很多问题，亟需在会议上反馈出来，然后帮助他解决这些问题；有的人觉得我现在忙得很，又天天开会，真烦，能不能少开一点、少说一点，让我赶紧忙完，要不然就得加班了；有的人觉得真好啊，最好开一整天，又可以摸鱼了，等等。在这些心态之下，各人的反应也会不一样。但更深层的一点是，多一事不如少一事，你要让他主动去说，那太难了，你问了才会说，不问就不说，甚至你问了，也可能因为性格等各方面的原因，都不太愿意说太多。加上大部分人都在会上刷手机，不会有心思听那么多的。 在这样的情况之下，让项目负责人把全部任务进度进行汇报并演示可验收的功能，很难覆盖到其他项目成员。他们本身不会觉得和这个会议有什么太大的关系，反正就是听一听，看一看手机，到了时间散会就完事儿。也许有些人可能有问题要反馈，但是他不会主动去提。 所以，项目进度例会的整体流程就要进行调整： 第一步，项目负责人要对项目当前的情况进行汇报，比如延期风险高不高？有什么重点问题？说一下，同步下信息，以及后续要注意哪些方面，等等。 第二步，就是要项目成员依次到前面来，而不是在自己座位上。把自己上周完成了哪些任务说一下，哪些任务进度怎么样也说一下，然后是演示一下自己开发的功能或者一些技术文档，最后就是遇到了哪些问题？需要现在就讨论和解决，然后就是下周计划做什么？把这些信息都记录在会议记录文档上面。 一方面可以减少项目负责人需要全面深入细节的工作；另一方面，可以侧面给项目成员一点压力。因为每次项目进度例会都要说一下工作内容，你如果上周完全都不用心，那么工作自然没什么产出，这样你总不能胡编乱造吧。 冥冥之中，不需要谁整天盯着你工作，你自己清楚，无形之中，就会有约束力，也减少了项目负责人的管理工作。 第三步，项目负责人把项目成员过进度中反馈的待解决问题，都记录到会议记录文档里面。下次项目进度例会，会看下待解决的问题是否已经解决。 第四步，项目负责人要根据当前项目进度情况，再次强调要重点关注的点，然后评估下是否需要加班。如有需要，进行加班安排。 第五步，散会。 相信按上面这个流程，可以有效解决项目成员在会议上没有深入参与的问题，并且能起到日常工作的一些约束，加强自我管理的意识，达成期望的工作目标。

在项目进度会议中，由开发人员自行演示近期完成的项目功能似乎无可厚非。毕竟，他们是最熟悉这些功能的操作流程的，部分功能甚至需要连接特定设备或模拟数据才能顺利演示。若非使用开发人员事先准备好的账号，整个演示流程可能会耗费大量时间，从而降低会议效率。 然而，深入分析后不难发现，这种做法存在一些潜在问题。首先，项目负责人可能对其他同事开发的功能并不熟悉；其次，项目负责人作为整个项目的负责人，在进行项目整体汇报时，若将主要演示职责交给开发人员，会导致职责划分不清晰，这不仅不利于项目负责人的个人成长，也不利于项目的顺利开展。 因此，项目功能演示环节最好由项目负责人全程主导，开发人员可适时进行补充。这样做的好处有三点：一是避免职责不清；二是增强项目负责人的责任感；三是促使项目负责人更深入地了解项目需求，因为只有真正理解项目需求，才能顺利进行演示，这也有助于后续的功能验收环节，其影响是多方面的。 归根结底，问题的根源在于项目需求与方案环节。项目负责人需要确保对项目需求有清晰、透彻的理解，虽然不一定亲自编写代码，但可以在脑海中模拟开发过程，至少要清楚功能的具体形态和使用方式。基于此，项目负责人可以在每周一提前浏览本周的任务，鉴于项目进度会议每周举行一次，本周需要实现的功能数量相对有限，亲自操作演示也不会花费过多时间，从而确保在周二的项目进度会议上能够清晰、准确地进行汇报。

我们每周二都会召开项目进度例会，会议中需要逐一汇报五六个项目的进展情况。为了能够在会议中顺利演示相关功能，必须将已开发完成的功能代码合并至Dev分支，否则将无法进行功能演示。 对于那些能够在会议前完成合并的分支，其代码已成功合并至开发环境平台，此时仅需进行功能验收即可。然而，功能分支的代码需经过项目负责人的评审，但往往功能开发任务在当天刚刚完成，而项目负责人本身还承担着其他功能的开发任务，因此难以及时完成代码评审及合并工作。在这种情况下，该如何妥善处理呢？ 一种可行的方案是Clone功能分支代码至本地，在本地环境中运行并进行验收。但这一流程存在诸多不便：需要Clone分支代码、安装依赖，且可能面临与本地环境不兼容的问题，还需进行微调才能成功运行，整个过程较为繁琐。在会议中花费大量时间进行此类操作显然毫无意义，那么如何简化这一流程呢？ 一方面，可以在会议前与相关人员进行沟通，提前了解哪些任务已完成且已合并至Dev分支，哪些功能的代码尚未完成评审并合并至Dev分支。对于尚未合并的功能分支，可提前将其Clone至本地电脑，安装好依赖并成功运行，待开会时通过远程连接至本地电脑即可进行演示。 另一种方案是直接打开代码仓库GitLab，查看项目分支的代码，让负责功能开发的同事详细介绍该功能的实现方式以及代码的设计思路，这样既能解决上述问题，也能达到功能演示的目的。 此外，还可以考虑在现有的Dev、TEST、Staging、Master 四个环境之外，额外设立一个Preview环境。项目的各个功能分支，无论处于何种状态，均可立即合并至Preview环境。功能开发完成后，项目负责人可直接将该功能分支合并至Preview分支，解决合并冲突后通过CI/CD流水线自动部署至Preview环境，从而方便地进行功能演示。Preview环境主要用于功能演示，最终的代码合并仍需以Dev、TEST、Staging、Master 四个分支为主，项目负责人在完成代码评审后，需将功能分支代码合并至Dev分支。 通过以上提供的三种解决方案，包括项目负责人在会前做好准备工作、通过GitLab查看功能分支代码进行验收、提供Preview环境以便直接合并功能分支进行验收，相信可以解决会议上因代码没有合并，从而无法进行功能演示的问题。

前言 项目的任务质量如何保证？在我看来，主要取决于以下这几个环节：需求要明确、任务开发时间要合理评估、任务需提供测试用例、在项目进度会议上进行功能演示。产品质量是生产出来的，不是检验出来的，不可能全都依赖于验收环节，毕竟那时已经晚了。验收环节只是为任务的质量加了一层防护，应从源头开始，就要不断地关注和解决存在的问题。 需求要明确 需求要明确，这一点在前面几篇文章中都反复提到过，这里就不再赘述了。简而言之，就是产品的需求要具体到可量化的程度。比如我要买苹果，应该是我要买10斤XXX牌子的苹果。 任务开发时间合理评估 在评估任务开发时间的时候，要根据实际情况，不能过于宽松。比如一个设备列表的功能排个两三天就差不多了，硬是排了一周多，这显然是有问题的。但也不能太严格，比如就给一天的时间，这就存心为难他人了，大可不必，实事求是就好了。 有人觉得开发任务只要时间够长，那么交付的功能质量一定就更好，实际上并非如此。人性本就如此，很少有人会提前完成任务，大部分人都会压到最后一刻才说做完了，不过，这也没什么可指摘的，人之常情。 所以，任务开发所需的时间，通常以一个“跳一跳能够够得到”的要求去评估即可。 **我们不会要求一个只能跑10公里的人去跑马拉松，我们只会要求他不断地跑到10公里、11公里和9公里，而不是他每次都只跑了5公里。**道理是一样的，没有什么是十全十美的，只希望每个人都能在自身能力范围内做到最好，仅此而已。 任务需提供测试用例 我们开发人员在开发完成之后，就匆忙提交任务进度为100%，意味着任务已经完成了。但是在验收人去验收的时候，还是经常发现这样或那样的问题。 为了解决这个问题，就需要把全部的问题都放到明面上，而不是藏着掖着，让大家都能清楚地知道，哪些功能确实是真的验收了。 这就需要开发人员在开发完成这个功能之后，提供一个自测报告，也就是在AgileTC测试用例管理平台编写这个功能的测试用例（在《AgileTC测试用例管理平台的基本使用》这篇文章中有介绍过如何使用），把全部功能要测试的点依次列出。 这样验收人在验收功能时，就可以根据这个测试用例，把全部功能都过一遍，有规范有依据，不会像之前那样混乱，到底哪些功能是没问题的，哪些功能是有问题的，一目了然，沟通效率也会更高。 以微信读书PC端的功能为例，图一为微信读书PC端的页面，图二为根据功能编写的测试用例，如下所示： 什么时候编写测试用例 上面提到的是在任务开发完成之后再编写测试用例，但如果在需求阶段就编写测试用例会不会有什么问题呢？ 在需求阶段就编写测试用例，这种开发模式就是常说的TDD（测试驱动开发）模式。这个方式当然是可行的，但存在一个问题，就是最终交付的功能和最初的需求可能会有出入，导致之前编写的测试用例不能用了，需要重新编写。 首先，开发人员在需求阶段就编写测试用例，相当于在对需求进行分解，同时对需求也会更加了解，能和产品明确，达成共识，避免接下来出现返工的情况。 总体而言，测试用例等同于列出需求点，后续需求有变更，也不是全部测试用例都不能用了，很大概率只是个别测试用例进行微调而已。 所以，不管是在需求阶段还是开发完功能之后再编写，在我看来都可以的。 说到底，测试用例最终还是要围绕需求来编写，从需求中提炼出的测试要点才是真实有效的。所以，**对被测对象业务的熟悉程度，也决定了能否设计出高质量的测试用例。**毕竟，各功能点之间往往都是有关联的，会隐藏很多被我们忽略掉或者是想不到的测试用例。 在项目进度会议上进行功能演示 我们发现只有在项目进度会议上进行功能演示才会发现问题。开发人员通常口头上说“已经做完了”，这很有可能是片面的，并非开发人员存心欺瞒，只是每个人对需求的理解，有可能一开始就有差异，这种差异即便功能已经开发完成，还是可能会存在。 在项目进度会议上进行功能演示，整个项目团队的人员都可以看到，并且可以随时提出问题，虽然这样会增加会议的时间，但我相信这是值得的。 这其实也就是在敏捷开发模式中提到的Sprint Review环节，简单来说，就是解决颗粒度对齐的问题（笑），能让项目团队中的相关人员，包括但不限于产品、研发、测试和需求提出方等参与验收当前开发的功能，确认是否有需求理解偏差或潜在的需求调整，能够及时反馈和沟通，有助于项目下一步的功能优化和工作安排。

之前我们计划由项目负责人每周五进行任务验收，但在开展过程中，验收其他开发同事的任务时，经常出现缺胳膊少腿的情况：比如某个任务完成了，但文档没写，或者写了又没有提交更新；某个任务计划的结束时间都超过了，也没有及时变更，至于过期的原因也没有说明等等，执行起来很困难。现在在项目进度会议上把完成的任务进行验收，就需要周一的时候，项目负责人牵头更新任务的时间、功能和文档情况，否则周二在项目进度会议上，还是会出现各种各样的问题。但是周一的时候，项目负责人已经验收过任务，周二在项目进度会议上又要过一次，对于其他开发同事来说，就觉得被问了两次，显然这个方式可能没有从根本上解决问题。 之前项目负责人去验收，实际上是不知道任务进度情况的，只有问了项目开发的同事才知道负责的任务完成了没有，项目负责人完全不知道有多少任务需要验收，完全是随机的状态，相应的其他事情的计划就又要变更了。那我们何不反过来，使用观察者模式，等开发同事完成任务后，给项目负责人发一下邮件或者企业微信的消息，一来形成闭环，二来强化开发同事任务是需要验收的这个意识。项目负责人这个时候立马去验收也可以，但不推荐，因为挨个去验收，精力就会分散，建议把可验收的任务整理记到下周一当天工作计划里，统一验收。后续等我们在线项目管理系统上线，里面就提供一个功能：如果开发同事任务完成，需提交技术文档（如有需要），然后把任务状态变更为待验收，这个时候，系统就会给项目负责人发一条可验收的邮件，相信可以有效解决这个问题。