在软体工程上，最麻烦的往往不是技术问题。 是 schedule。 我的 schedule 到底该怎麽达标？如何不过度承诺，又能确保团队如预期交付？ 这是一个亘古的问题，牵扯的面向很多。 ─────────────────────────────────── ◆ 需求：50% 以上的问题来源 在工作上，有【50% 以上的问题】是来自於需求追加跟处理。 这里我会建议引入「最小工作时间」的概念。就跟汽车引擎启动需要暖机吃油 一样，团队投入评估也是一个暖机启动的过程，中间变更方向是非常浪费的。 我往往会抓【3-5 天】作为暖机的最基本单位，由 2-3 个主要的 PM 收集需求 ，让暖机动作在他们身上完成，产出需求。 一旦暖机完毕，要再变更？要嘛直接丢弃，要嘛等下一个周期。一旦进入机器 里面，大原则上就不给临时变更了。 说真的，这件事能做到的团队，需要非常有纪律，需要有足够信用，也需要有 一定的能力。但如果做不到这件事？你谈准时，基本上都是不负责任，而且缘 木求鱼。 ────────────────────────────────── ◆ 修改成本的迷思 很多人会担心：一开始做错了，後面修改成本会很高。 但其实要看事情。有些事情修改成本确实很高，但有些事情修改成本低到靠北 。所以每件事情都要 micro control 到极致，是非常浪费成本的。 至於哪些事情可以变更、哪些不能变更，这在需求讨论时必须由 PM 给出【边 界定义】。这个边界写得好不好，直接影响整件事情的关键成败。 但现实世界最大的问题是，很多时候 BD 根本搞不懂客户要啥，我们自己当然 就跟着乱了。 这种时候就只能采取保守策略：一次步伐小一点，但多步伐，客户验证周期留 长一点。用这种方式做小步快跑来因应。如果明知道市场是这种模式，还要用 大型瀑布流，基本上就是自杀了。 不同的条件要使用不同的工作流，但台湾很多时候我们都期待以不变应万变， 那当然就是卡死团队也卡死自己。 ────────────────────────────────── ◆ 团队怎麽动起来 知道要做什麽之後，下一个问题是：怎麽让团队动起来。 这是一个很大的问题。我们都知道一个团队可能有几十个人，但管理者其实就 那几个。 训练良好的团队，当然可以动得很快。但多数团队哪有办法训练得很好？很多 时候大家都是临时这边招一个、那边招一个，这边是小菜鸟、那边是资深工程 师，大家混在一起，光团队磨合可能就要花上一段时间。 况且团队可能又有人离职、有人进来。在中小企业来说，团队其实常常处於一 个有点混乱的状态。就算是已经成熟的团队，工作方法也可能受限於过去累积 下来的模式，很难去做调整或转换。 ────────────────────────────────── ◆ 传统分工的极限 过去的工作方法论，通常是职务分工：前端、後端、UI 各有人带。这种方式 是利用工作分工，让大的指令被分切成小的指令。 可是在多模组的情况下，当你的系统复杂度已经到了每个领域知识都需要用模 组切开来分工的时候，状态就会变得非常复杂。 你会发现这些人已经没有能力掌握所有事情，他们会进入下一个状态： 【当你问他任何问题时，他都必须回去问他的 team member 才有办法回答。】 当你发现一个小主管，哪怕是最基层的小主管，已经进入到这个状态时，表示 你的管理已经开始失灵了。 这种时候，就需要考虑是否把团队缩小。 我个人一向相信：越小的团队，沟通成本越低；越大的团队，沟通成本越高。 ────────────────────────────────── ◆ 齿轮团队 这些事情都已经是老问题了，这麽多年我们也反覆在挑战。那为什麽今天要再 谈一次？ 主要的核心问题在於：我们现在面临的问题是有十几、二十条不同的工作链， 而且具有相依性——可能前面要先做完，後面才能做；或者大家都要一起做完 ，才能上验证、上整合。 这就牵扯到整合的强度，也就是这些「齿轮」的磨合。 我在 2023 年的 Modern Conf 讲过「齿轮团队」磨合这件事： 1. 【齿轮磨得准】：大家浪费的时间最少，速度可以跑得超级快 2. 【齿轮磨得不准】：产生的 Gap 会很大，光是一件事情的往返可能就三个 礼拜不见了 这一来一往是好几倍的差距。 台湾在做这种「齿轮化」、「任务分工化」这件事上，其实有很多值得讨论的 地方，但我们台面上基本上都没在讨论，这蛮可惜的。 ────────────────────────────────── ◆ Scrum 的迷思 很多时候我们在讨论的，其实都是什麽 Scrum，你要写 Story、要写 Point， 让大家一起参与讨论。其实大家迷信的一件事情就是：只要每个人都有讲到话 ，这件事情就是对的。 但这他x的屁啦！ 一件事情能不能被完成，重点在於： 1. 要有知道该怎麽做的人 2. 用对的方法，以及团队能够接受的方式把流程推出去 3. 让团队按部就班地把流程的每个环节都做出来，稳定完成上线 这跟有多少人参与讨论、提供意见或负责，其实没有直接关系。重点是你有没 有适当的 idea 在讨论中冒出来。 很多人会以为人多就一定会有好的意见，并没有。人多更多的时候只是浪费你 无限的会议时间，让大家更没办法专注自己的工作。 本来的执行工作做得不好，连规划工作也要进去插一脚（尬一咖），结果本来 可以做好的执行工作根本做不出来，规划工作也是一团乱局。 这才是台湾多数职场的现况。 ────────────────────────────────── ◆ 找对的意见 今天我们要谈的事情是，我们到底要怎麽去看待一个团队分工的讨论。 首先，团队必须要有能力找到： 1. 谁的意见是重要的 2. 谁的意见是对的 3. 谁的意见是建设性的，是可以让团队前进的 然後，我们要让有建设性的意见一直处在领导团队的位置。同时，让那些没有 建设性、或者对进度有害的意见，可以被抑制、缓和掉，让团队可以减少浪费 时间。 ────────────────────────────────── ◆ 害怕不能阻止决策 很多时候，意见是来自於害怕。我们会担心如果在这个地方太武断，做了一个 太强烈的决策，会不会被人指指点点，或者以後要修改会变得很难。 这时候，我们要回来问自己一个问题：我们知不知道这个东西以後会不会被改 ？ 如果没有资讯，我们可以再问一下客户。如果客户没有想法，我们也没有想法 ，那就关起门来问我们自己：我们觉得客户在接下来这半年到底会怎麽改？ 如果答案都是不确定的，那我们为什麽不做决定？ 【就做啊！】做了决定就往前走。 你要在对的时间点做对的决定，然後让事情 move fast，这才是我觉得团队管 理中最核心的事情。 ────────────────────────────────── ◆ Buffer 的恶性循环 下一个问题是，我们很常会碰到工程团队面临的一个老问题：大型功能怎麽拆 。 在这种情况下，工程师会很害怕，他会觉得：「我要跟那麽多系统整合，这肯 定很难。当别人叫我预估时间的时候，我是不是应该抓得保守一点？」 所以这时候你就会碰到一个情况：大家都在抓 Buffer。 其实抓 Buffer 并不是错的，我觉得这是负责任的行为。但问题是，抓 Buffer 隐含着一个恶性循环： 1. 团队越没有效率，大家抓的 Buffer 就越长 2. Buffer 抓得越长，团队成员就越认为彼此没有效率 3. 这种认知会导致大家把 Buffer 抓得更长 ────────────────────────────────── ◆ 先拆素材，不管时间表 所以理想情况是，我会跟做介面的说：你先不要管对接，把这些栏位全部挖出 来。对接的部分，我们等栏位做完之後，再排一个完整的工作来处理。 大家先把彼此的素材整理好，先不用管时间表。我们有 3 到 4 天的时间处理 前置工作，先把所有素材摊开，到时候我们再看着素材来讨论。 如果介面非常庞大，比如有四五个 step，我通常会建议：我们不要一次做完 全部，先做第一页。一个 Sprint 接着一个 Sprint 地把东西做起来。如果总 共有四页，那就分四个 Sprint，四次之後我们就有完整的东西了。 如果你现在抓不准时间，没关系，我们就拆 Sprint。我可以用最宽松的方式 拆给你，但是你必须事先告诉我你要怎麽分解，每一个 Sprint 你具体要干什 麽。 ────────────────────────────────── ◆ 为什麽团队不愿意估准时间 我跟你讲，很多团队之所以不愿意估准时间，或者会估一个很长的时间，是因 为他们真的没有动脑筋想过 Sprint 到底该怎麽切。 他想的只是先把程式码全部刻完，然後看 QA 能测出什麽屁事，等 QA 把问题 都测出来後再全部修完。 但一个正常的软体工程绝对不该是这样子的。我们应该是： 1. 一个零件一个零件地打造 2. 一个零件一个零件地验证 3. 最後只是把零件拼装起来而已 这样我们在最後整合的时候，就不会突然喷出几百个鸟问题。一个正常的软体 工程团队根本就不应该那样做事。 ────────────────────────────────── ◆ 信任感与责任归属 所以你怎麽去拆解这些工程师的 Bullshit？你怎麽去处理好每个角色彼此之 间对时程的害怕？ 你怎麽让大家相信，反正东西交出来到我手上，我就是个魔术师，我可以把这 些东西都拼装起来？ 你怎麽让大家相信他交出来的东西，即使他看不懂全貌，但他可以相信後面有 个人会 pick up，把逻辑接起来，不会掉球，不会事後过来靠北说是他没做好 ？ 你怎麽让团队有这种信任感？ 【责任的归属、时间的归属、时程的归属，这些就是考验你 Product Owner 的职责、设计与规划。】 ────────────────────────────────── ◆ 台湾很少人在讨论这件事 在台湾，有认真在做这整个结构思考的人其实真的非常少。你看文章有多少人 在谈这件事情？我觉得几乎没有吧。 所以我自己很喜欢写这一段，因为我觉得这才是值得讨论的事情： 1. 【团队整合】：你怎麽让团队里面有大有小、有老有少、各自都很有个性 的人，可以揉成一个团队？ 2. 【流程优化】：如何让他们变成一个生产线，一两个礼拜就可以上一次轨 道？ 3. 【协作默契】：让大家跟流水线一样，各自安分守己地拼装自己的生产线 这不就是管理工作吗？这不就是我们该追求的事情吗？ ────────────────────────────────── ◆ 为什麽我要写这些 我今天写这些内容，是因为大家都在 bullshit 地讲我们要用 A 方法，还说 A 方法要思考 5W1H。去你x的，问题真的是我们不知道那 5W1H 吗？ 不是。 问题是我们没有真的去思考团队与团队之间的隔阂，没有想过这个人可能就是 没有能力的。我们只是觉得老板交代一件事情下来，我这件事情就一定要派一 个人出去；他没有做到是他的事，不关我的事。 当我们每个人都用「是他的事，不关我的事」这种心态在处理团队的事，进度 当然会走得乱七八糟。 ─────────────────────────────────── ◆ 每个人都必须有产值 真正的情况是： 1. 团队既然花了这笔钱，哪怕招募了一个领六七万月薪的人，他实际上只能 做三万的工作，你还是至少要让他发挥出三万的贡献。因为他如果没有发 挥出贡献，价值就是零。 2. 你可以之後再用绩效考核去处理他，让他离开；但是在此之前，你不可以 让他完全没有产值。每一个人只要进了团队都必须要有产值，最起码不能 是负数。 ─────────────────────────────────── ◆ 管理的本质 所以管理的本质应该是： 1. 思考如何把每个人的产值用到最好 2. 让产值没达标的人可以慢慢离开这个团队 3. 让产值达标、做得很好的人，能藉由奖金或奖励，让他们心里觉得自己的 付出是有被看见的 可是在台湾，永远都是你管理得好是应该的，你做得好也是应该的；然後你做 得不好就骂你一顿，痛骂你一顿，把你骂到离职。 每一个团队都在找替死鬼、背黑锅，这有什麽意思？这根本就不是管理的本质 。 【管理的本质是要让大家心甘情愿地为你卖命。】 ────────────────────────────────── ◆ AI 时代的管理 所以我写这些文章，是因为看到很多人在谈方法论，特别是 AI 出来後，大家 还在谈这些。 其实我觉得本质上，AI 就是一个员工。在我眼里，AI 大约就是一个价值 3 万的员工，你最多可以养两个，再多你就指挥不动了，因为目前的 AI 指挥负 担成本比较重。 以我为例，考虑到成本和管理负担，我平常可以一管八（人），但在 AI 时代 ，一管二到一管三就是极限了。对我来说，你可以完全把真人跟 AI 员工放在 同一个平面看待。 如果他们堆叠 AI，把自己变成更强的人，我就会把他们视为「有外骨骼的人 类」，可以做更多事情。但本质上，我们还是一个团队，核心目标是： 1. 把需求池里的东西做得稳定、顺利 2. 准时上线，让客户能准时使用功能 这才是整体核心的战斗，最终还是回归到对需求、分配以及知识交换的妥善设 计。所有的方法论，都是为了协助解决这些事情。 ────────────────────────────────── ◆ 我们真的没有认识自己的员工 可是最奇怪的地方在於，我们真的没有认识自己的员工。我们不了解每个人： 1. 他会什麽，不会什麽 2. 强项在哪里，弱点在哪里 3. 什麽事情他不该碰，什麽事情他做了会搞砸 4. 什麽事情他做起来超强 其实管理团队很单纯：让他做他做起来超强的事情，不要让他碰他做得非常烂 的事情；或者只在安全、可以磨练的时间点，才让他碰那些他不擅长的事。 如果每个人都只做他们擅长的事情，其实真的没那麽多（琐碎的）事情可以做。 ─────────────────────────────────── 早上看了一篇文，觉得应该要来讲一下。 这篇文章全部都是用语音转换，再加上我自己写的一个语气 Skill 让 AI 帮 我整理完成的。试试看这样的写作流程，我觉得蛮有意思的。 方法论可以谈，但真正的管理从来不是方法论。 是认识你的团队，认识你的员工，然後让对的人做对的事。 仅此而已。 ─────────────────────────────────── * 人工补注1 本篇采用语音输入+ ai 润稿，我觉得确实有帮助我， 把本来一些已经讲到懒得讲的东西再讲一次。XD * 人工补注2 发现他漏掉我谈 产品分工的那一段 懒得重补了 XD 总之 职务分工的问题是 事情过了门槛就会 overhead 变超高， 产品分工则是产品不够大就会很浪费，两个各有他的问题。 本质上还是要回到对产品跟员工能力的理解。 -- I have a dream, it's silly but beautiful. --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.34.27.1 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1770177295.A.0BB.html