在软件工程上，最麻烦的往往不是技术问题。
是 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 变超高，
产品分工则是产品不够大就会很浪费，两个各有他的问题。
本质上还是要回到对产品跟员工能力的理解。

推这篇~讲的蛮不错的

我理解是最根本的就是资讯不对称要怎么做alignment, 很多团队会花大量时间开会想弥补这一块, 但常常越弄越复杂近期我跟几个leader讨论后觉得可行的方案是, 把给AI阅读的SKILLS文件commit进去, 透过原本就有的review 让这些内容文件化, 也同步团队的认知, 新人更好上手, 但不能解决跟技术团队外的角色沟通问题, 刚跑也不确定是不是一个好方法忘了推感谢分享, 把问题讲得很明确

感谢分享

推推，很赞的分享

三个月后老板要开记者会，你自己看着办

我碰到的情况都是一人团队+详细需求都是边做边开会修改，小公司就是这样吧

推分享

敏捷信徒还有10秒抵达现场帮补血

感谢分享

就是人性化的Sprint很多软件工程最大问题就是把人当零件看 那只能用在非智力集中产业 工厂的生产线那套直接搬上来就是白痴

大谈整篇结果有八成内容是执行不好scrum所导致的==台湾人学会怎么用好那套就直接改掉了

感谢分享

专案管理=写好报告,向上管理,有权无责,只管成不管败.

多的是连自己员工懂什么不懂什么都不知道的主管

很普通的 到底在推什么?

你是不是agents要跑很久所以时间很多-_-

我写这样一篇文章只需要20分钟 XD

我的经验是，有一个不懂技术跟管理的高管，有权强硬决策一切时，任何的专案管理技巧都没用。比如在专案最终阶段，直接要求跳过测试环境，直接在正式环境“测试”。功亏一篑，莫过于此。时间和资源只能消散于职场政治斗争中。“没效率”变成专案的“最优解”( ・ ∀ ・ )

谢分享，很有耐心看完这篇文章

良心分享。

同意Eide. 管理只有适合.所以大多数都是各说各话.真正要成为意识形态就只有像那两间知名公司一样最后就是成为宗教一样的存在