Posts

前言 “任何人都可以过得快乐而舒适，可如此世界就不会有所进步，没有人过着快乐而舒适的生活还能取得伟大的成就。” 看完纪录片，我就在想，有时我们做不好一件事情，是不是因为没有破釜沉舟，给自己留了太多后路的缘故，总觉得这次不行，那就下一次。 可是，如果面对的是生死，并且只有一次选择的机会，你会怎么做？ 《徒手攀岩》于 2019 年 9 月在中国上映，是第 91 届奥斯卡最佳纪录片。 该片讲述的是美国攀岩大师亚历克斯于 2017 年 6 月 3 日无保护徒手攀上美国约塞米蒂国家公园 916 米的酋长岩的全过程，共用时 3 小时 56 分钟。 2021 年 6 月底，我在 B 站上看的时候，是别人上传的资源，这一次看发现 B 站已经上架，当然这对于我而言，并没有什么不同，这些年也有重温，这次是第三次。 想到，现在开始整理电影观后感，就写一写这个纪录片带给我的一些感受。 专注的力量 亚历克斯决定挑战徒手攀岩酋长岩，不是拍着脑袋就决定的。 他认准这个目标之后，用了 8 年的时间做准备，四十多次有安全绳的攀岩，一直都在练习。 一次又一次的练习，每一个细节都要做到无可挑剔，每一个指头触摸到的地方，每一个脚尖所碰到的岩石勾缝，都记得一清二楚。 每次爬完，都要做笔记，哪里做对了，哪里没做对。 努力不能是盲目的，不是说我练习跑步，那就去跑步，每天都不懂脑子，跑完就完了。 努力是全方面的努力，而且要用对方法，练习跑步，不仅仅只是在跑道上奔驰就行，穿什么鞋，每天跑多远，怎么摆动手臂，每日三餐吃什么，晚上几点睡觉这些都要学习。 而且，亚历克斯的生活真的太简单了，吃喝住行全在房车上，土豆、菠菜什么的大乱炖就是晚饭了，对他来说，只有攀岩是最重要的。其他的，可有可无。 这让我想到科比说的一段话： “我知道没什么能阻止我，对于 18 岁的我来说，篮球就是生命，你不可能强过我，因为你没我那么花时间在篮球上，即便你想，你也做不到，因为你还有其他牵绊，其他分散你精力的责任，所以我已经赢了。” 不是一开始就成功的 亚历克斯不是一次就成功的，他也放弃过，那一次为了到达抱石绳段，刚好太阳光线不影响到自己，他早上 4 点出发，可才爬了一小段距离，就因为左脚状态不好，对要用自己的右脚来决定一切失去信心，加上被众人注视之下，心理压力很大，外加女友和他说 “能不能为了我放弃这次挑战”，心理压力变得过大，就放弃了。 一个人没有可以在乎的人，也就没有任何弱点，但是，从另一个角度来说，正是因为有保护的人，才会变得异常强大，这个在很多作品中诠释过这一观点，但对于此时的亚历克斯，显然是前者，他的心态发生了变化。 按理说，他应该沮丧的，但是他没有，三个月之后，他重新出发了。 我赢是理所当然的 这些年，我看到运动员在奥运会上获得了金牌，有的热泪盈眶，有的开心至极，有的人则面无表情。 我就在想，为什么会出现这种面无表情的情况？你都已经是世界第一了。 面无表情，难道是觉得我夺得金牌是理所当然的事情吗？ 在我看来，真的很有可能是这种心理，我付出了全部的努力，吃过了那么多的苦，就是为了这一刻，这些都是我应得的，甚至与我所吃过的苦相比，不值一提。 亚历克斯也是这种人，虽然他攀岩登顶之后，大笑不止很是开心，甚至有点想哭，但是上午刚完成这个伟大的创举，下午就开始继续训练了，换做其他人，不得放纵几天，但是他没有。 可能对于他而言，他只是完成了一个想要的目标而已，他是很高兴，但是他付出的也足够多，当然运气也是不能完全忽视的因素，只是在这个降临之前，你是真的倾尽了全力。 要不要破釜沉舟 回到文章开头那个问题，我们在做选择的时候，要不要抱着破釜沉舟的心态？ 我只能说，这个很容易陷入正反两说的境地，有的人适用，有的人不适用，反正在我们中国的文化里，面对任何事情，都是可以灵活应对，而不是固执。 比如古人说 “己所不欲，勿施于人”，反手又说 “顺我者昌，逆我者亡”，这些话对错都要看当下的情况，不是绝对的，合理就好。 ...

在多项目管理过程中，会遇到这样一个问题：有的项目人比较多，有的项目人比较少。 比如 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 年的几场培训，培训老师说过的一句话让我印象深刻： “如果你不想吃亏的话，要以最坏的情况去判断你的员工。” 即便李四为人厚道、兢兢业业，不会偷奸耍滑，那你能保证王五、赵六也不会这样吗？ 你真的有时间和精力去仔细分析每个人，或者持续观察他们的一言一行吗？ 那样的话，你自己就不用干活了。 所以，还是要回归到流程规范上来，不回避任何问题，把它暴露在阳光下，通过望闻问切，仔细分析原因和我们的诉求。 接着就是大家沟通达成共识，用规定来约束，用流程从源头解决问题。 那接下来，如何从流程规范入手解决这个问题呢？ 这要从我们的目的出发，我们的目的是对任务进行有效制定、跟进和验收，而不是流于形式。 既然要 “有效”，就要实事求是，杜绝虚假。而规避虚假的办法，就是专业的事情交给专业的人。 现实情况是，项目负责人并非全能全知，所以可以把这部分工作交给对应的同事来执行，引入技术端负责人的角色。 各项目可根据实际情况，设立前端负责人、后端负责人和终端负责人。他们的职责是协助项目负责人明确对应技术端任务的开发所需时间，跟进任务进展，并负责验收。 整个项目的人员架构就变成：项目成员 - 技术端负责人 - 项目负责人。 那么，项目成员的任务申请时间变更，由谁来审核呢？ 本来我觉得，项目的全部任务本应由项目负责人审核，而技术端负责人已经对开发周期（即天数）进行了把关，项目负责人依据这一点判断即可。 但技术端负责人需要覆盖三个关键环节：制定、跟进和验收。变更属于跟进部分，如果这一环节改由项目负责人执行，整个任务的生命周期就无法形成闭环了。 在项目管理系统中，曾经的设计思路是：项目成员的任务时间变更，审核人都是项目负责人。 如果现在引入端负责人的角色，那么技术端成员的任务时间变更就应由对应的技术端负责人审核，而技术端负责人的任务变更则由项目负责人审核。 至此，我认为可以解决项目负责人如何制定、跟进和验收不同技术栈成员任务的问题。