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

1. 前言 项目当前版本（假设为1.0）开发完成之后，会提交给测试组进行测试，然后，开始进行下一个版本（假设为2.0）的研发工作。 但是，测试组测试周期可能要一两个月，期间会不断的反馈 Bug 到系统里，等项目当前版本（1.0） Bug 修复完成之后，再进行下一轮的测试。 这时，项目新的版本（2.0）功能开发进行中，每个人都已经有自己的开发任务了，时间也排好了，应该怎么安排？ 还有，在 A 功能模块上修复 Bug，而同时又在 A 功能模块上开发新的功能，代码合并可能会冲突等等问题怎么处理？ 2. 权衡任务调整的利弊 因为测试反馈 Bug 数量不是一个可控的事情，有时第一轮测试完成，都没几个 Bug，有时第一轮测试就反馈好几十个 Bug，完全可以衍生新的任务，评估个两三天去处理。 所以，如果你打算，暂停或推迟当前版本（2.0）的开发任务，而去执行修复上个版本（1.0）的 Bug 的任务，很有可能收益不大，因为可能都没有几个 Bug 让你修复。 但是，如果你完全对第一轮反馈的 Bug 不管不顾，又会影响到测试组的测试进度。 3. 基于测试周期的任务调整 上面说的，虽然测试反馈 Bug 的个数是不可控的，但庆幸的是，测试周期是明确的，比如第一轮具体是什么时间段，第二轮又是什么时间段，这些都是前期沟通好的，虽然偶有变数，但是大体上问题不大。 在这个基础之下，项目负责人就要根据测试轮次结束的时间，对当前反馈的 Bug 情况，进行任务上面的调整，比如第一轮测试反馈了 50 个 Bug，然后按功能模块划分清楚，以及哪些功能模块对应的负责人是谁，修复这些 Bug 需要多少工作量，新增一条修复 Bug 的任务在项目当前版本（2.0）计划中。 4. 测试环节的漏洞 但是，如果 Bug 特别多，花费了大量的时间，甚至影响到了当前版本（2.0）的开发进度怎么办？ 这个时候，是否需要延长修复 Bug 的任务呢？ 缩短开发的任务时间呢？ 加加班？ 这些方式可以解决这个问题，但是，治标不治本。 因为在这个功能到测试组介入参与测试时，其实，已经有过三个环节，对功能进行测试了。 一个是功能开发人员自测，编写测试用例，然后对开发的功能点一一测试。 另一个是功能开发任务验收，这个验收的工作就是根据功能开发人员提供的测试用例，验收人自行跑一下这个测试用例，看下有没有什么问题。 最后一个是项目负责人内测，就是项目当前版本（1.0）结束，要给测试组提测之前，把全部功能都测试一遍。 上面这三个环节，为什么不能发现和解决掉一些很明显的 Bug，而一定要测试组测试时才发现？ 5. 优化测试流程 理想状态下，每一轮测试都不应反馈那么多 Bug 的，然后需要排两三天的时间去处理的，通过一两天差不多了，甚至在开发当前功能时抽个一天的时间解决掉就行。 所以，回答项目开发中应什么时候去修复测试反馈的 Bug 这个问题，那就是做好下面的流程： ...

一个项目的 Bug 来源是多方面的。有的是线上功能试用反馈，比如客户在使用平台功能时，发现了影响功能使用的 Bug；有的是项目负责人验收任务时反馈的；还有的是测试人员反馈的。 测试人员反馈的 Bug 一般都记录在 Bug 系统里进行管理，所以问题不大。发在沟通群里的，多个人看到了之后，会给功能负责人带来一定的约束力，通常问题也不大。 最大的问题是那种私底下一对一沟通反馈的 Bug。比如，项目负责人张三给项目成员李四发消息，反馈了一个功能上面的 Bug ，李四说记下来了。 如果李四解决了并反馈给张三，那还好；但如果李四不反馈，张三就不知道这个 Bug 的状态了。除非张三主动去问，否则谁也不知道这个 Bug 是否已经解决。 写到这里，我不由得感叹，要做好一件事情，各方面的协作都要到位。**任何一个流程没有有效执行，都会导致后续的环节发生变化，并需及时提供相应的对策，从而使简单的问题复杂化。**所以，制定清晰的流程并传达到位，是多么的重要。 首先，在推动从流程入手解决这个问题之前，要先分析一下： 为什么反馈 Bug 时要私底下一对一沟通呢？ 为什么不直接发到沟通群里呢？ 原因很简单，大家都是同事，低头不见抬头见。发现对方开发的功能出现了 Bug，虽然不是什么大事，毕竟，谁都不能保证自己开发的功能，一个 Bug 都没有。只是，发到项目沟通群里，当众指出别人的问题，不管对方心胸多么宽广，总会不高兴的，自然而然，都会觉得没必要做这种不讨好的事情，反正能解决掉这个 Bug 就行，是否是私底下一对一沟通反馈，没有那么重要。 我觉得换位思考，上面这样的原因是可以接受的，但是完全依赖人，而不是依赖流程，是不能彻底解决掉问题的。 所以，我们可以这样规定： 在 Bug 系统上进行管理，为项目创建一个对应的版本。在这个版本的开发时间段内，遇到的所有问题，以及别人反馈的 Bug，都记录在这个上面，而不是私下沟通。这样虽然是公开的，但是不去看就不会知道，不像在项目沟通群里，当众处刑。 因为 Bug 系统是和邮件关联的。比如你是项目负责人张三，在验收李四开发的一个功能时，发现了问题123，那么就在 Bug 系统记录，并分配给李四。 等李四解决掉 Bug 之后，就修改这个 Bug 的状态为 “已解决”，张三就知道 Bug 已经解决了，然后再去跟进，这样就形成了闭环。 那如果张三还是不把 Bug 记录到 Bug 系统，或者李四解决了 Bug 但没有在 Bug 系统上修改状态呢？ 那就需要及时介入沟通了，不能听之任之。抓而不紧，等于不抓，出现问题要第一时间解决，表明你对这件事情很重视。 否则，大家都觉得可有可无，慢慢就变成做做样子应付了事，那通过流程化解决对 Bug 进行有效管理的初衷就无法达成了。

1. 前言 复盘会议通常是在项目某个版本完成开发并正式上线之后才召开的，但复盘工作其实并不是等到最后才开始的。项目负责人应该在项目前期就开始着手准备，在项目推进的过程中，持续记录各种各样的问题，这样在会议上就能有更充分的内容来进行讨论和总结经验。 当项目负责人要召开项目复盘会议的时候，需要把项目相关人员都通知到位，比如产品、后端、前端和测试等等。然后预订一个会议室，在群里发布会议通知，到时候按计划如期进行。 这个复盘会议对于项目负责人来说，一方面能够吸取项目管理方面的经验，另一方面也有助于提升项目团队的凝聚力。 在会议上，把项目开发过程中哪些是做得好的，哪些是做得不好的，依次都列出来，让大家一起讨论一下，有一个总结与反思的过程，也是一个一起分享成果的过程。 对于做得好的地方，那肯定是要表扬的；对于做得不好的地方，大家就再接再厉。 复盘会议上讨论的内容，基本上涵盖了项目版本周期的方方面面，目前主要总结了以下几点。 2. 任务完成情况 这个版本的项目任务计划制定得是否合理？哪些任务有多次变更的？已过期的任务具体原因又是什么？ 3. 测试反馈BUG问题 把这个版本测试提出的 Bug 整理和归纳一下，分析一下具体的情况。哪些 Bug 是完全可以通过提前规划来避免的呢？比如输入框的校验，基本都没有，功能开发的时候，只是保证能用就行了，功能的边界完全没有自测。类似这种问题，就可以在会上进行讨论，然后达成共识，加入到开发规范里，后续就可以规避类似的问题了。 4. 会议记录 我们每次开会都有会议记录文档，然后会把反馈的问题都记录下来。这些文档在复盘的时候就会起到作用，可以从中吸取经验。看看有哪些问题是第一次出现的，那有没有对策可以避免再次出现呢？这些都是可以在复盘阶段解决的。 5. 技术笔记 技术笔记是开发过程中对功能难点进行总结的文档。遇到哪些功能解决不了的？后来又是怎么解决的？都可以在复盘会议上进行分享。 6. 群内反馈的问题 群里反馈的问题可不止是项目讨论群里的，还有其他客户群里的。客户反馈了哪些问题，又提出了哪些需求？后续我们的工作要怎么规划？ 7. 总结 复盘的目的不是对过去的问责，而是对过去的反思和总结，并着眼于未来如何改善。 项目这个版本的功能已经完成了，事已至此，没必要深究谁没做好，然后让对方有心理负担。我们的目的一向是解决问题，这次没做好，下次做好不就行了，谁都有没做好的时候。 更重要的是，今天比昨天做好一点。更重要的是，着眼于未来，这个项目下一个版本能不能比上个版本做得更好一点？

1. 前言 我们统一每周周二开项目进度会议，每个项目的情况都不一样，有些问题就是需要讨论很久，所以时间是无法评估的。 我们不可能要求什么时间内一定要开完项目进度会议，只能说项目负责人需要知道项目进度会议的流程，并且逐渐按照流程执行。 一般情况下，每周开一次项目进度会议，任务通常不会太多，通常一次会议所需时间应该不会太长，但是我们把项目会议流程梳理之后就会发现，时间是大大超出我们预期的，如下所示： 项目进度情况（20 分钟） 问题反馈讨论（20 分钟） 任务验收 功能演示（20 分钟） 代码抽查（20 分钟） 文档查看（10 分钟） Bug 修复情况（10 分钟） 后续工作安排 任务安排（20 分钟） 加班情况（10 分钟） 项目人较多时，就需要 2 个小时左右；项目人较少时，也需要 1 个小时左右。我觉得项目会议时间在 1 - 2 个小时之内是可以接受的，但是开到 3 个小时以上就有点问题了。 要解决问题，最终还是要回到问题本身。项目进度会议时间过长，你的诉求到底是什么？最要解决的本质问题是什么？难道真的是项目时间过长吗？ 那我直接规定每次开会不能超过某个时长就好了，没必要在这里纠结那么多。 所以说，本质的问题不在项目会议时间过长，而在于这个项目进度会议的时间是否产生了价值，是否有必要。 那我们要清楚，到底是哪些问题，容易导致项目进度会议时间拉长呢？ 我想了一下，可能是这三种情况。 2. 没有在会前准备解决方案 有些问题没有在会前自己捋一遍，然后根据自己研究的结果，给出多个解决方案，并整理到文档中，然后发到项目讨论群里，而是自己闷头在研究，简单在脑里想了下，觉得想明白了，等到项目进度会议上再深入沟通。 在项目进度会议上，没有什么文档，大家就一起参与讨论了，只是口头沟通，然后七嘴八舌的，说什么都有，这样行不行，那样行不行？ 讨论没有任何依据，只是凭感觉，反正你一句我一句，再加上一些闲话，最终浪费了很多时间。 正确的做法应该是，在会前要把自己研究或者想到的解决方案，整理到文档中，要列举至少两三个方案，并把每个方案的优说明缺点清楚，最后在总结一栏，把自己推荐的方案标明清楚，并说明你选择该方案的原因。 当然你可能会说，有些难题是在会上反馈出来的，哪有时间去准备解决方案文档，很多都是靠沟通交流得出的。 如果是这种情况，那么可以简单沟通一下，然后回去整理好解决方案文档，发到项目讨论群里，然后叫上相关人员在座位上过一下，然后把最终结论补上文档即可。 3. 无关话题太多以及范围过大 有时在项目进度例会上，很多时候沟通是没有依据的，也就是没有围绕项目当前的情况进行，总是一连串旁枝末节的话题，一个接一个没完没了。 你说这些话题有必要讨论吗？ 当然有的，但是要看当前项目的情况和时机。比如有些规划是大半年以后的，有些甚至是几年后都不一定要做的，这些话题进行深入沟通可以增长个人的知识面，但是在当前没有什么意义，完全可以在私底下去了解。 如果觉得很有用处，可以在了解之后，叫上几个人在座位上探讨一番，而不是在项目进度会议上。 比如讨论 App 的功能，说着说着，又说到 Flutter 最近好像不太平，Flutter 组又裁员了，然后还在 GitHub 上面搞了一个社区的分支，单独维护，然后说不计划合并到 Google 的主分支上了，然后又讨论 Flutter 是不是要完蛋了？那我们后续开发 App 要换不要技术方案？那老项目要怎么维护？Android、iOS、鸿蒙、微信小程序这些跨平台要怎么解决等等。 完全没完没了，这些讨论当然有意义，但是，在项目进度例会上进行讨论，真的太不划算了。 ...

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