在多项目管理过程中，会遇到这样一个问题：有的项目人比较多，有的项目人比较少。 比如 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 来承担这项工作。 ...

继续《To B 市场品牌实战课》课程第 5 个场景练习： 选择一个你熟悉的 To B 产品，按照我们的模版，做一个商机分析，并请你周围的一个朋友（作为销售）看看能不能通过你的模版，挖掘到关键的销售信息？ “To B 的商机工作，是市场工作最艰巨的事，也是最有价值的事。” 本节内容中，这句话我是深度认同的。 因为对于公司而言，能够有好的业绩，就是因为有需求的客户购买了你的产品或者服务。 那怎么知道哪些客户有这个需求呢？这个过程就是商机。 说得通俗易懂一点，商机就是你能找到客户，或者让客户能找到你，不管是哪个途径吧，只要能让你们碰头就行。 为了让你们能碰头，就要使出浑身解数，从 “你找客户”、“让客户找你” 这两个方面入手。 你找客户，就涉及到网上信息收集、各个企业进行深入分析、整理行业大会相关信息等等。 让客户找你，就涉及到营销，最基本的就是官网 SEO 优化要做好，让官网在各大搜索引擎中排名靠前，客户搜索相关关键词，能出现在搜索结果页面最前面的位置。至于什么短视频、打广告这些都是后话了。 这一段时间，我深入参与了整理企业分析报告和官网 SEO 优化，有一些心得体会。 我对于企业分析报告的看法是，要知己知彼，才能百战百胜。 不应只是关注客户与我们相关的部分，比如我是云服务解决方案商，那么，就不应只是关注企业对于上云这块的需求，而是整个企业都要进行分析，从基本信息、企业规模、发家历程、业绩情况等方面进行全面分析。 这一点在之前的文章《和 ToB 目标客户接触前，要做哪些准备工作？我的一点看法》中，已经以永辉超市为例，做了一份简易的企业分析报告，并加以说明，所以，本次场景练习要求的商机分析模板，实际上已经完成了，这里就不再赘述了。 在做了好几个企业的分析报告之后，结合产品会议上多人沟通和讨论的结果，发现有些企业的实际情况，与分析报告中的结论有出入。 有一些客户在自己官网的产品介绍页，或者一些新闻稿件上，把产品夸得天花乱坠，但是，实际情况却并非如此。 有些大公司，某一款产品可能就一两人在开发和维护，与预想中几十几百个人的团队规模，相差很大。 在这里给我的启发是，通过企业分析报告，分析出来的商机，具有一定的欺骗性。 所以，是否有机会，不应该完全从对方是否已经有方案满足自己需求了入手，而是从对方的业绩上入手，只要对方业绩不错，发展有很大的潜力，都应该深入去了解。 因为企业发展好，才更有机会，如果企业都半死不活了，你拿下这笔生意，也不能赚多少钱。 至于官网 SEO 优化，一开始我是不太上心的，因为我觉得 To B 产品在官网进行宣传，流量太少了，收益可能不大。通过百度统计，查看官网每日浏览量那么少，都没有多少动力去搞 SEO 优化了。 但是，后来我想了一下，发现我的思路有问题，因为官网 SEO 优化，你如果做好了，它一天 24 小时都挂在那里宣传你的产品，就有可能有客户会看到，不需要你实时跟进，甚至可能是一劳永逸的，所以，官网 SEO 优化这个事情的优先级反而应该是最高的。 总之，怎么做好商机这个工作，就是做好你去找客户，或者让客户找到你，这两个方面，至于后面你们碰头之后，是否达成交易，那是下一步的工作了。

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

继续《To B 市场品牌实战课》课程第 4 个场景练习： 在今天的场景练习环节，我想请找出你身边或者你公司一个即将发布的产品，按照咱们上面的流程，写出、提炼核心发布要点，并形成一个虚拟的发布会工作笔记。 产品发布会流程的核心要点记录，本来我是打算以 “极客云” 或者储能系统为例，把这些内容一一补充的。 但是，我发现直接用 AI 生成不是更快？但是这样子做，又违背了我的初衷。 如果都是这样 AI 生成了，那我还写这个场景练习有个什么意义，没有任何收获。 思来想去，还是做一个折中，就是把产品发布会的流程核心要点，以大白话的解释来代替，这样，很方便记忆。 等后面真的有机会参与到产品发布会，再以这些流程进行实践，并输出更为真实的体会。 产品立项（做什么） 产品的卖点（三个卖点） 预热、关注、好奇（刷存在感） 产品发布会（在哪摆摊） 邀请嘉宾（可信度） 产品发布（卖东西） 典型客户案例分析（可信度） 现场产品互动（问题解惑） 媒体专访（宣传资料） 影响力持续（到处贴宣传单） 查缺补漏（检查任务清单） 把上面的流程，整理成一段话就是： 做什么，并提炼三个卖点，然后去各大网站或论坛狂刷存在感，然后定好在哪里摆摊，并请专业人士过来试用，接着吆喝起来开始卖东西，并找一个已购用户分享使用感受，接着就是回答在场围观群众的问题，然后，安排一个媒体进行访谈，最后，就是把访谈的内容形成广告，到处张贴，最后，把上面的流程捋一遍，看下有没有什么出入的问题，结束。 除此之外，对于自身产品，要有一个深刻以及到位的理解。要对以下的问题，都能够回答得上来： 客户遇到了什么？（有问题） 客户需要什么帮助？（要什么） 我们可以提供什么？（有什么） 我们又要以什么成本提供？（多少钱） 能够解决客户的问题吗？（能行不） 还有同类方案吗？（其他呢） 为什么是我们来解决？（为啥找我） 我们解决的优势是什么？（我好在哪） 我觉得，如果对上面产品流程清单、产品问题清单，都能回答得上来，那么这个产品发布会，应该是没有问题的了。