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

在多项目管理过程中，会遇到这样一个问题：有的项目人比较多，有的项目人比较少。 比如 A 项目有张三、李四、王五等 4 个人，B 项目则只有赵六、王七 2 个人。 这种情况下，通常会考虑从 A 项目调一个人去支持 B 项目。 不过在做这个事情之前，得先想明白几个问题：我们为什么要调一个人去支持 B 项目？调谁合适？为什么是他？做这个事情的根本目的又是什么？ 如果不加深究，很容易得出答案：因为 A 项目人多，B 项目人少，适当匀一下，显得更为合理。 但实际上，人员调配的真正目的是优化资源结构，把钱花在刀刃上，实现利益最大化。 从这个角度出发，你会发现事实可能和之前预想的不一样： A 项目有 4 个人，B 项目有 2 个人，虽然 B 项目的事情好像更多更杂，表面看更应该加人。 但结合项目对部门业绩发展的重要性来评估资源投入就会清楚，A 项目是行业项目，B 项目只是对内的、满足公司自身需求的项目。 显然，这两个项目对部门发展的重要性是不一样的，A 项目很明显更重要。 所以，即便 A 项目人多，B 项目人少又事情多，也不应该从 A 项目调离人员。 正确的做法是加快 A 项目的功能迭代，同时对 B 项目的功能进行筛选，先做高优先级的，低优先级的就推迟开发。 除此之外，是否调离人员，还需要评估人员的重要性。 结合实际情况，核心成员就该投入到重要性高的项目，再结合对他的发展期望，调整到利于他发展的项目中。这样一来，他的能力能得到提升，也容易做出更好的业绩，从而激励到自身。 还有一点，要尽量不过多变动当前人员负责的业务，不让他们掺杂过多业务，一来精力太分散，容易变得低效；二来人员掺杂过多业务，会加大管理难度，影响多项目推进。 所以在我看来，多项目管理中的人员调配，可以通过这几个来判断： 根据项目对部门业务发展的重要性，评估投入资源。重要性高的项目人多，重要性低的项目人少。重要性低的项目事情多，就适当慢下来，按优先级处理。 依据成员的重要性进行调配，核心成员投入到重要性高的项目，利于其发展、做出业绩，实现自我激励。 避免人员参与过多业务，以最小力度调整人员，保持业务的稳定性。

在之前的文章《37-AI 时代，代码评审方式究竟怎样优化？关键要点有哪些？》中已经提到，AI 代码评审基于 Code-Review-GPT-Gitlab 进行使用，因为这个开源库包含评分机制、问题反馈、修改建议和修正后的代码等部分，比较符合我的预期。 在使用了一段时间之后，考虑到要基于流程规范来操作，项目成员提交代码后，最好能看到 AI 代码评审报告，然后根据反馈的问题修改后再提交代码。 但怎样才算修改好了呢？这就需要制定一个标准，比如将 90 分作为评分标准，每个分支提交到仓库时，都需要达到 90 分以上，代码才能入库。 然而，以 90 分作为标准执行一段时间后，有同事反馈这个标准可能不太合理。因为通过 AI 代码评审，出现了一些幻觉问题，这会导致评分不准确，使得 90 分的要求难以达成。 幻觉问题一直是当下 AI 面临的较大难题，在我看来，这并非完全是由于私有化部署时使用的模型小、性能不够强大所致，很多市面上很强大的 AI 工具，同样存在这个问题。 加上，其实提交的代码只是变更部分，AI 代码评审时，只会对 diff 部分进行检查，这就会存在对业务认知不完整的问题，因为项目中一个完整的业务功能，并不一定就在一个文件里完整呈现的。 因此，流程调整为采用 “AI 预评审 + 人工复核” 的方式，依旧按照 90 分的评分要求，具体问题具体分析。如果出现幻觉问题，则灵活处理，而非因噎废食。 关于幻觉问题，一方面可以考虑升级配置，比如购买性能更好的显卡；另一方面只能等待行业发展，以有效解决 AI 幻觉问题。 在《当 99% 可靠性是及格线，我们如何为大模型装上工程 “安全带”？》这篇文章中，提到了对幻觉问题的探索和解决，后续发展情况仍需持续关注： 在 2025 世界人工智能大会（WAIC）上，蚂蚁集团旗下蚂蚁密算宣布对外开源高阶程序（High-Order Program）大模型可信应用技术框架，通过外部化控制与核验，为构建可信、可控、可维护的大模型应用提供了务实的参考标准。 除此之外，项目成员在提交代码之前，需要在 VSCode 中使用豆包 AI 插件，对所有改动的文件进行检查。 这样至少能在提交代码、进行分支合并之前，在本地提前暴露问题，无需等到提交代码后再用 AI 进行代码评审，从而简化大量工作。 不过，在本地使用豆包 AI 插件检查改动的代码时，无需过度检查。因为我发现，每次提问都会得到问题反馈，即便复制它建议的代码去询问，仍然会收到很多建议，这会让人感觉没完没了。 毕竟代码的写法、规范并非只有一套，功能的实现细节也千差万别，并非绝对统一。所以，只需检查一次，把特别明显的问题改掉即可，若是吹毛求疵，只会陷入无尽的循环。 至此，我之前认为代码评审完全可以由 AI 来完成并让整个流程顺畅运转的想法，显然有些激进了。 以当前情况来看，无论 AI 代码评审能达到何种程度，即便幻觉问题能得到有效解决，也不应该完全由 AI 来承担这项工作。 ...

一般而言，项目的任务计划都是由项目负责人制定的，其中需要明确每一条任务的优先级、开发周期和开发负责人。 但是，有些项目负责人的技术背景是前端，有的是后端，还有的是终端。 这就会遇到一个问题：他们怎么去制定其他技术栈成员的任务并进行验收？ 在此之前，我们默认都是由项目负责人完成这些工作的。比如，项目负责人张三是前端出身，现在他要给后端的李四制定开发任务。 通常的做法是，张三会和李四沟通要开发的功能，然后由李四给出功能开发所需的时间，接着张三填写任务时间，任务安排便完成了。 这里就存在可操作的空间，因为李四给出的时间没有第二人进行审核。而张三是前端出身，并不具备审核后端任务时间的能力。如此一来，任务安排就完全取决于李四是否厚道了。 我们一直反复强调人性，可依赖人性做事情，迟早会出问题。 今天李四心情好，可能就凭良心给出合理时间；哪天他心情不好，或许就会把任务时间拉长，好趁机摸鱼。 写到这里，我想起 2020 年的几场培训，培训老师说过的一句话让我印象深刻： “如果你不想吃亏的话，要以最坏的情况去判断你的员工。” 即便李四为人厚道、兢兢业业，不会偷奸耍滑，那你能保证王五、赵六也不会这样吗？ 你真的有时间和精力去仔细分析每个人，或者持续观察他们的一言一行吗？ 那样的话，你自己就不用干活了。 所以，还是要回归到流程规范上来，不回避任何问题，把它暴露在阳光下，通过望闻问切，仔细分析原因和我们的诉求。 接着就是大家沟通达成共识，用规定来约束，用流程从源头解决问题。 那接下来，如何从流程规范入手解决这个问题呢？ 这要从我们的目的出发，我们的目的是对任务进行有效制定、跟进和验收，而不是流于形式。 既然要 “有效”，就要实事求是，杜绝虚假。而规避虚假的办法，就是专业的事情交给专业的人。 现实情况是，项目负责人并非全能全知，所以可以把这部分工作交给对应的同事来执行，引入技术端负责人的角色。 各项目可根据实际情况，设立前端负责人、后端负责人和终端负责人。他们的职责是协助项目负责人明确对应技术端任务的开发所需时间，跟进任务进展，并负责验收。 整个项目的人员架构就变成：项目成员 - 技术端负责人 - 项目负责人。 那么，项目成员的任务申请时间变更，由谁来审核呢？ 本来我觉得，项目的全部任务本应由项目负责人审核，而技术端负责人已经对开发周期（即天数）进行了把关，项目负责人依据这一点判断即可。 但技术端负责人需要覆盖三个关键环节：制定、跟进和验收。变更属于跟进部分，如果这一环节改由项目负责人执行，整个任务的生命周期就无法形成闭环了。 在项目管理系统中，曾经的设计思路是：项目成员的任务时间变更，审核人都是项目负责人。 如果现在引入端负责人的角色，那么技术端成员的任务时间变更就应由对应的技术端负责人审核，而技术端负责人的任务变更则由项目负责人审核。 至此，我认为可以解决项目负责人如何制定、跟进和验收不同技术栈成员任务的问题。

在这篇文章《19 - 过进度方式二：项目成员依次说明和演示任务完成情况》中，已经讲明了当前项目过进度的方式：要求各项目成员到前面的座位来，把上两周以及下两周要做的工作情况汇报一下。 但是，在执行大半年的时间里，发现有的项目成员在会议上汇报自己任务情况时，只是简单说明内容，两三句话就说完了。 怎么引导项目成员更多地反馈工作中的情况，而不是让会议变成形式化、流水账式的无意义会议呢？ 我反复思考了一下，项目成员为什么不想说那么多呢？这个点其实在《19 - 过进度方式二：项目成员依次说明和演示任务完成情况》中也有过分析，这里就不再过多赘述了，无外乎就是多一事不如少一事 —— 只要我说得越少，问题也就越少。 不过，我也能想到其他的可能，比如 “就是线上修复了几个 Bug，没有什么可说的”“就是正常的功能开发，没什么可说的”“我做的是其他项目的，跟其他人关系不大，没什么可说的”。 关键点就在于 “没有什么可说的”。 为什么没有什么可说的呢？ 难道每个人在开发的过程中，真的一点问题都没有吗？ 每一条任务的制定，都包含需求、方案、研发、技术笔记和验收等多个环节。 这几个环节中，总该有可以说的点吧？ 但是，为什么没有什么可说的呢？原因就是没有做好相关的工作。 很多需求只是一句话，或者口头说一下；很多方案也只是当面沟通一下，沟通好就完事了，没有整理成方案文档记录下来。 至于研发过程中遇到的问题，有些 Bug 在没解决之前是 Bug，解决之后恍然大悟，就会觉得问题不值一提 “原来如此，我居然会犯这个低级错误？” 所以，也就觉得没有什么值得总结和记录的了。 还有技术笔记，写这个是要花时间的，完全看每个人是否自觉去做，那真的太难了，大多数人的想法是，还不如省下这些时间去做下一条任务。 甚至，有些人会觉得，这种知识点还要写技术笔记，会不会让人觉得自己技术很菜、水平很低，还不如不写。 任何问题都要透过表象抓住本质，一般这种问题，只是从人身上入手，效果不会很理想的，你可以口头要求对方一次两次，过段时间，只要你稍微疏忽了，对方也就松懈了，所以，还是要从源头去解决，也就是要从流程入手、从规章制度入手，经过沟通讨论，定下一些规定，让大家一起遵守就好。 比如，项目负责人在制定任务的时候，需要把任务要求写清楚，任务要先整理详细的需求文档、解决方案和技术笔记。 之前可能只是 1 条 “支持 10 万台设备接入”的开发任务，里面涵盖着想让成员写各种文档的期望，现在这个事情直接挑明了，拆分成 3 条任务： 支持 10 万台设备接入需求文档 支持 10 万台设备接入解决方案 XXX 框架基本使用、疑难问题解决等技术笔记 这样，就把之前依赖项目成员自觉的工作，变成硬性要求，以任务形式下达，让工作从无序变成有序，从无条理变为有章法。 在这个基础上，项目进度会议中项目成员汇报进度时，就可以把这些资料都过一遍，然后再进行验收，应该能有效解决会议流水账的问题。

背景 在项目开发过程中，代码评审还是很重要的，主要是为了解决代码规范、功能开发方式、相互学习等问题，代码是否符合规范，关系到项目成员协作的问题。 如果写出来的代码风格五花八门，那么，在沟通交流上面，就额外增加了难度，而这是完全没有必要的。 除此之外，上面说到的功能开发方式问题，意思就是，每个人都有可能是孤岛，一个人的想法可能会有缺陷，如果多个人沟通以及探讨，相互学习，有可能会从不同视角发现潜在的问题。 人工代码评审 一直以来，我们要做项目代码评审，通常都是有这几种方式，比如项目组成员交叉验收各自的功能代码，然后把问题整理到文档，再一起组织代码评审会议，把问题都过一遍，然后安排任务去调整。一方面解决了代码存在的问题，另一方面通过深入交流，大家相互学习。 还有，就是在 GitLab 代码合并阶段，项目成员发起功能分支合并至主分支，由项目负责人去审查项目成员提交的代码分支。 如果没有问题，则合并到主分支；如果有问题，则反馈给项目成员。待项目成员修复完成再次发起分支代码合并，然后，项目负责人确认之后，合并到主分支。这个应该就是常规的代码评审流程。 但是，随着团队的发展以及对降本增效的要求，开始着手去研究，团队中哪些工作是有可优化的空间？ 项目负责人承担的工作事务越来越多，怎么去有效简化无意义的工作，成为了当前亟需解决的问题。 SonarQube 基于上面降本增效的目的，我之前调研了 SonarQube 代码检测工具。 它基本支持了市面上的 Java、Go、JavaScript、TypeScript 等十多种语言，并提供几千条代码规则，用于代码规范检查、代码优化提示等代码质量问题。 支持结合 GitLab 的 CI/CD 做流水线事件中断，方便代码提交人员，自行去查看反馈的问题。 并且，提供 SonarLint 这个 IDE 插件，在代码编写时，就反馈存在的问题，并给出修改建议。 后来为了减少项目负责人的代码评审工作，整个部门的项目，就都接入了 SonarQube 来实现代码问题检查工作。 在使用 SonarQube 的过程中，给我印象深刻的主要有以下几点： 如果一个历史项目要接入使用 SonarQube 工具去检查代码，这个时候，势必会有很多问题反馈，比如可能 2000 个问题，这个时候，是否要立马安排时间去解决呢？ 立马安排的话，就需要比较多的时间了，如果不立马安排解决的话，这些问题应该什么时候去解决呢？ SonarQube 提出了一个 “新代码” 的概念了，意思就是，可以不立即就把这 2000 个问题修复掉，而是在项目功能迭代的过程中，逐步把有问题的代码修复掉。 因为项目功能有迭代，意味着，这部分代码就需要去改动，趁此机会，刚好同步解决掉遗留的代码问题，慢慢地，遗留的 2000 个问题就会以这种方式解决掉。 至于哪些没有迭代的，说明功能已经很稳定了，或者功能不重要，那优先级也相对更低了。 SonarQube 官网文档的这篇说明 《Clean as You Code》 提出的这个方法论，我觉得理念还是很不错的： SonarQube 旨在通过帮助您（开发人员）确保您提交到项目中的每个代码更改都没有问题，从而确保高代码质量和安全性。通过始终提交干净的代码，您可以逐步提高项目的整体质量。我们称这种方法为“Clean as You Code”。 Clean as You Code 的核心思想是将注意力和精力集中在新代码上。在您进行功能和改进时，SonarQube 会在每次新提交时分析您的代码，并在任何代码质量问题和安全问题上提醒您。然后，您可以立即解决这些问题，并确保添加到项目中的所有新代码始终是干净的。 ...