职业与管理

从 2023 年 10 月 22 日开始，我对自己说：如果能坚持每周更新一篇 ARTS 文章，就继续运营这个公众号并群发。 所以前面 10 篇都没有群发记录，基本是偷偷在写 —— 主要想验证自己能否坚持下来，万一失败了，反正也不会有人知道。 但当时心里一直想着：要做就做好，要么就不做。没有不清不楚、不黑不白、不上不下的中间地带。 这个打卡活动，我从 2020 年 4 月底购买陈皓《左耳听风》课程时就知道了，起初打算试试看，后来不知怎么就不了了之。这次重拾起来主要有三个目的： 平时上班敲代码的机会变少，想通过刷算法题保持对代码的感觉。 我有一份问题清单，记录着工作中遇到的问题、技术点和小技巧，但一直没整理，打算通过 Tip 模块倒逼自己梳理。 老生常谈的英语学习。 前期坚持的效果还不错，印象中没补几次卡，应该就是过年放假时间长了点，其他时候都还好。 起初计划每周阅读 Medium 上的文章，说实话，上面的文章质量真不错，而且这个网站没有广告，阅读体验特别好。 我做 Review 这件事的流程基本是：自己先看一遍，看不懂的用欧路翻译插件一键自动记录到生词本，了解大概内容后自己翻译，再用有道翻译原文，对比两者的差异。 这个模式坚持了一段时间后，我觉得 Medium 上的文章有时太长，自行翻译太费时间，加上需要翻墙，在公司看文章很不方便，于是换成在 Breaking News English 网站翻译新闻短文，一方面文章篇幅短，另一方面不用翻墙，还能了解新闻资讯。 在这个网站坚持一段时间后，有一天我突然觉得自己看英文文章不发怵了，不管多长都能硬着头皮看下去，总觉得自己马上就能看懂了。但这种感觉没持续多久，就又回归正常状态了。 说真的，我很讨厌英语，为什么要学这个东西呢？但后来我想明白了，“师夷长技以制夷” 的前提是你得懂对方在说什么。当然也可以用翻译软件，但学习一门语言就是在学习一种文化，只有了解了文化和风俗习惯，应对问题，才能游刃有余。这是翻译软件无法替代的。 坚持这个打卡活动到某个时间点时，我突然觉得差不多了，就是已经不需要证明什么了。当时计划在 2024 年 10 月 22 日结束这个打卡活动。 但刚好《黑神话：悟空》8 月底开售，我想自己都等了 4 年了，Windows 电脑和游戏手柄都有，装备齐全，没理由不去玩，一玩才发现，这质量也太高了吧，远远超出预期。 9 月初通关《黑神话：悟空》后，我真正对魂类游戏产生了兴趣，想起 2017 年买的《黑暗之魂 3》，每次玩都因为不知道怎么玩，也不看攻略，再加上都是骷髅有点吓人，玩了几次，实在玩不下去，就作罢了。 这次趁热打铁，我把老贼的《黑暗之魂 3》通关了，通关后才感叹这真是艺术品啊。它在我 Steam 游戏库里吃灰快 8 年，直到现在，我才真正体验到这部作品为什么是史诗级别的。接着我又通关了老贼的《艾尔登法环》，这部年度游戏也是神作，就不多说了。 前前后后花了很多时间在游戏上，ARTS 打卡活动就经常断掉，只能攒起来恶补，每周一次的打卡规定也形同虚设。 但我一点都不慌，也不觉得心虚，因为我已经不需要这些来证明自己能坚持这个打卡活动了。 我坚信，即使是现在，我依然可以按严格的每周一更频率坚持打卡，只是已经没有这个必要了。 从 2023 年 5 月 13 日陈皓过世到现在已经 2 年了，时间过得真快。 ...

这个问题最初出现在技术管理沟通群里，有群友提问：自己负责的项目任务已十分繁重，可领导还要安排新任务，不知如何是好。答应吧，担心自己所在的小组即便累死累活也难以完成；不答应吧，又怕惹领导不高兴。 我想起之前看《铁齿铜牙纪晓岚 4》时，有这样一段剧情：乾隆打算在凌烟阁挂上二十四幅功臣图，众人就谁排第一产生争执。乾隆使计让杜小月说出，若让纪晓岚进入军机部，也能像和珅一样出色，所以不同意和珅比纪晓岚厉害。乾隆顺水推舟，安排了角色互换的游戏，让纪晓岚去军机部，和珅去修四库全书。结果两人在处理不同部门事务时，因为缺乏经验，导致处处受阻，只能私下碰头商讨对策。 剧中，纪晓岚说皇上让自己查张廷玉的几块银两用在何处，觉得这点小事不必斤斤计较。和珅则表示，皇上安排的事情，最怕的不是大事，因为大事有章法可循，按章办理即可；最怕的是小事，没有先例，只能琢磨心思、见招拆招，所以对皇上安排的小事，要特别小心。 还有曾仕强先生在一期节目中说道：“如果老板让我去死，我到底去不去呢？” 他给出的回答是，先应承 “好的，老板”，然后自己不去就行了嘛。 从上述事例中，我们能得到什么启发呢？一方面要明白领导的用意，另一方面是不要直接拒绝领导。关键在于不要直接拒绝，而非完全不能拒绝。 其实核心还是 “先肯定后否决” 的策略，这和我们平时常用的标准反驳句式如出一辙 ——“你说的确实有道理，但是……” 如果是我，我会先一口答应下来，尤其是在多人场合。如果只有自己和领导两人沟通，拒绝的影响相对小一些；然而在多人场合直接拒绝，领导可能会觉得没面子。要是领导心眼小、心胸狭窄，日后难免会给你穿小鞋。所以，先痛快地答应 “好的”，然后过半小时左右去找领导，解释目前手头上的任务太多，若新任务时间紧迫，是否可以将其他任务暂缓？如果不能暂缓，多项任务同时推进实在难以完成，恐怕最后会顾此失彼。 这样做既能表明自己有积极完成任务的态度，又能说明客观条件不允许。领导的回应通常有两种：要么让你先暂缓其他任务，要么让你推迟新任务的完成时间，问题往往就能迎刃而解。当然，如果领导听不进建议，仍然一意孤行，直接干他就是了（哈哈哈，你敢信，我就敢说）。 由此可以延伸思考，领导安排任务时，必然有自己的考量。一般有两种情况：一是从当时的实际情况出发，认为由你负责更为合适；二是借此进行测试。培养一个人并非突然委以重任或提拔，而是通过日常工作中的突然考验，时不时来这么一下，看你瞬间的反应，从多个维度综合评估你是否值得信任、能否为我所用。 可能有人会说，公司的组织架构、管理方式和领导的性格等各方面情况都不一样，但我觉得核心逻辑是一样的 —— 先肯定后否决，只是在执行方式上，需根据实际情况调整。比如公司是扁平化管理，上下级没有明显的严格层级划分，而你对自己负责的项目情况又特别清楚，领导安排新的任务时，你完全可以直接当面解释目前的情况，说明加上新任务可能会导致的问题，而不必非要一口答应，等到半个小时之后才去找领导解释，那样做事就太死板了。 不过话说回来，工作和生活本就是一体的，但又不尽相同，人在上面的行事风格差异很大。工作上的这种测试是可以接受的，毕竟只是工作。但生活中类似的测试，真的不能接受，因为很没意思。

Algorithm 本周的算法题为 598. 区间加法 II 给你一个 m x n 的矩阵 M 和一个操作数组 op 。矩阵初始化时所有的单元格都为 0 。ops[i] = [ai, bi] 意味着当所有的 0 <= x < ai 和 0 <= y < bi 时， M[x][y] 应该加 1。 在 执行完所有操作后 ，计算并返回 矩阵中最大整数的个数 。 示例 1: 输入: m = 3, n = 3，ops = [[2,2],[3,3]] 输出: 4 解释: M 中最大的整数是 2, 而且 M 中有4个值为2的元素。因此返回 4。 实现代码如下： const maxCount = function(m, n, ops) { // 如果操作组为空，则表示都是0，直接返回m*n if (ops.length === 0) { return m * n; } // 找到最小的m和n let minM = m; let minN = n; for (let i = 0; i < ops.length; i++) { minM = Math.min(minM,ops[i][0]) minN = Math.min(minN,ops[i][1]) } // 返回最小的m和n的个数相乘 return minM * minN; }; 解题思路： 这道题其实还是很简单的，只是一开始会有点绕，不太清楚要讲什么，但是仔细观察就会发现，突破点就是这个 “矩阵中最大整数的个数”。因为所有的格子都要 + 1，所以，最大的整数只会出现在操作组a1、b1值最小的那个上面。所以，我们要做的工作，就是找出最小值的那个操作组。 Review Carlo Ancelotti leaves Real Madrid to coach Brazil - Breaking News English Lesson ...

现在我们的需求梳理方式，基本上就是一句话。什么意思呢？就是有一个需求文档，项目负责人把要做的事情依次列出，再对其进行评估，如果需要设计原型，就安排产品进行功能原型设计，如果需要提供解决方案，那么就先安排自己或其他开发成员提供解决方案。 好像没有什么问题？其实，真正的产品需求文档，也就是俗称的 PRD 文档，是很规范的，就不说什么形式上的问题，比如文档信息、版本更新历史、名词解释等等。就光内容的要求，就很精细。就拿 APP 的 PRD 文档来说，是需要把原型的图片贴到文档里的，然后要对每个功能和交互进行说明，比如点击这个按钮，会出现什么弹窗，弹窗的布局是什么样子的，内容是什么，文本是什么颜色的，是使用什么字体的等等。比如，XiaoPiu 的官方示例： 这样详细的好处是，在之前的文章《16 - 项目的任务质量如何保证》中已经有过类似的叙述，那就是避免需求边界不清晰，导致后续的返工。 但是，对于我们现阶段而言，项目的需求应该怎么梳理呢？这个怎么说呢？如果是在大公司，分工比较明确，那么这样做无可厚非，精益求精未尝不可，但是，如果是中小型公司，或者只是一个部门，要自负盈亏，考虑到实际工作中的产出，或者说性价比，那么就感觉有点过度精细了，说好听点，是追求极致与差不多这个度怎么把控的问题，说直白点，是怎么利益最大化的问题。 所以，从实际情况出发，虽然 PRD 文档规范化，有诸多好处，但是投入产出比显然很低的，因为没有那么多人手把这个需求做到这么精细的程度，加上平时沟通也很及时，有什么问题及时沟通处理就行，而且，PRD 文档规范化还有一个重要的目的是，为了和其他部门或其他公司进行沟通交流使用的。 可是，只是我们部门内部使用的需求文档，就没必要这么精细了，只要能做好这件事情就行。但是，虽然是一句话需求，但还是有优化空间的，我们做不到整个文档规范化，但对这一句话的需求，可以规范化。 上面说的是 PRD 文档的规范问题，但其实，对于需求的整理，可以遵循需求的 INVEST 原则。需求的 INVEST 原则最早由 极限编程（XP）的倡导者 Bill Wake 提出。这一原则旨在指导敏捷开发中用户故事的拆分与编写，帮助团队更高效地管理需求，确保故事的可交付性和价值性。 INVEST 原则主要用于优化用户故事的描述，使其满足以下特性： 独立性（Independent）：故事之间减少依赖，便于单独开发和测试。 可协商性（Negotiable）：避免过早锁定细节，鼓励通过沟通逐步完善需求。 有价值（Valuable）：每个故事必须为用户或客户提供明确价值，避免资源浪费。 可估算（Estimable）：团队能评估工作量以制定迭代计划。 短小（Small） ：单个故事工作量控制在几天内，以降低风险。 可测试（Testable）：明确验收标准，确保功能可验证。 结合我们部门自身情况，需求来源其实很多的，所以可分为两种，一种是部门外，另一种是部门内，如果是部门外，需要加上角色；如果是部门内，角色可不加。可以简化为，是谁？要做什么？为什么？ 这里就以设备管理功能，写一个示例参考： 深圳客户希望能看到自己有多少台设备，方便统计和日常维护。 是谁：深圳客户 要做什么：看到自己有多少台设备 为什么：方便统计和日常维护 通过这种方式，既能保证需求的清晰性和可操作性，又能在现有资源条件下实现需求梳理的优化，为项目的顺利推进奠定基础。

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