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

1. 前言 项目发起测试时，首先要在 OA 填写软件测试申请单。填好之后，由项目负责人准备当前版本的测试用例，交给测试部门，同时沟通确定测试周期，之后才正式开始项目功能测试。 2. 线上版本出现明显的问题 最近有个线上平台，客户反馈说平台里有个列表的按钮怎么点都没反应，而且弹窗的样式也错乱了。可这个版本明明是测试通过才上线的，这就说明测试环节肯定出问题了。 3. 问题产生的原因分析 为什么会出现这种情况呢？ 主要还是测试流程有漏洞。因为项目负责人提供给测试部门的测试用例，只包含了当前迭代的需求。所以测试的时候，测试人员就只测了新增加的功能，而出问题的那个功能是旧功能，因为不在迭代的需求范围内，所以压根就没测。 按理说，这个旧功能没做任何改动，怎么会出问题呢？ 后来发现，在开发当前迭代需求的时候，有可能开发人员不小心动到了这个功能的代码，或者是在修复其他小问题的时候影响到了它。 还有可能是当前迭代需求其实和这个功能是有关联的，但我们只关注了迭代功能有没有完成，根本没管那些关联功能，这才导致问题在实际使用的时候暴露出来。 4. 测试流程改进办法 为了解决测试覆盖不全，又不想每一轮都全部测一遍浪费时间的问题，我们优化了测试流程： 项目负责人这边要提供完整的测试用例，还要标注清楚当前版本里哪些功能必须测试，哪些不用测试。 测试人员分三轮进行测试： 第一轮，不管标注的是不是必须测试，把平台所有功能的测试用例都过一遍； 第二轮，专门验证已经修复的 Bug，同时再把那些必须测的功能测一遍； 第三轮，等所有 Bug 都修好了，确定没什么大问题了，再把平台全部功能的测试用例再过一遍。 这样一来，既能保证测试全面，又不会做太多无用功。

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、鸿蒙、微信小程序这些跨平台要怎么解决等等。 完全没完没了，这些讨论当然有意义，但是，在项目进度例会上进行讨论，真的太不划算了。 ...