评论
点赞
收藏项目管理十律：从解决核心问题到商业可行性
Lucas Fernandes da Costa 提出软件项目管理的十条原则。核心观点包括：项目目标是解决问题而非满足初始规格；范围随工作推进才逐渐清晰，需保持灵活；固定日期对应可变范围，反之亦然；应构建每日可工作的最小版本，而非并行开发后集成；工程决策需兼顾销售、运营等商业维度；假设的重要性取决于其错误的成本，而非验证难度；保持看板状态同步以避免信息孤岛；尽早交付核心解决方案以预留改进时间。这些原则强调适应性与商业可行性，适合技术管理者参考。
反向压力（Backpressure）才是你真正需要的
本文提出使用编码 AI agent 的第三种方式——在人与 agent 之间建立"反向压力"机制，让 agent 自己先完成更多验证再交给人类审查。作者类比系统工程中的反向压力概念：当下游组件无法继续处理时，向上游发信号要求减速。在编码场景中，自动化测试、类型系统、CI 流水线都是反向压力。但当前用 LLM 写代码时，人类自己成了默认的反向压力——手动审查每行代码。文章分享了 7 种实际可用的反向压力机制：lint/测试验证、cURL 及浏览器手动测试、基准测试、审查 agent（功能/测试/类型/简洁度）、规划阶段审查、视觉设计审查、PR 监控。作者给出了可在 Claude 中直接运行的 npx 命令和具体 prompt 模板，以及如何通过迭代循环让 agent 每次修改后自动运行这些检查，从而大幅减少人类低级别审查负担，让人专注于架构与设计决策。
设计文档不过是披着连帽衫的瀑布式开发
设计文档不过是披着连帽衫的瀑布式开发。作者 Lucas F. Costa 以犀利个人观察指出：大多数 design doc 的真实功能不是指导实现，而是让组织感到安全——提供一个可审批、可追责的工件。你在信息最少的阶段被迫做最多决定，文档写完即弃无人更新。文章不空谈批判，给出具体替代方案：写问题而非解决方案、识别单向门/双向门决策、先原型再写文档、用代码审查代替文档审查。引用了 Rich Hickey、John Ousterhout、Jeff Bezos 等思想，论证扎实、文风幽默，是一篇让人想点开、读完并参与讨论的优质技术随笔。
I'm still not using GUIs: A guide to the terminal (2019)
> *TL;DR: [Here are my dotfiles]. Use them and have fun.* GUIs are bloatware. [I've said it before](/2018/08/05/In-Praise-of-Plaintext.html). However, rather than just complaining about IDEs I'd like ...
回顾会议：从记录问题走向真正解决问题
许多团队的回顾会议变成了形式主义——记录问题却从不解决，分配调查任务却无果而终。作者以亲身经历批判这种低效循环，并通过丰田生产方式（TPS）的"安灯拉绳"机制引出四个改进方向：1）赋予团队"拉停产线"的权力，如Resend公司的"The Fixer"轮值制度，每周指定专人全权负责修复问题；2）立即行动与尽早复盘，而非把问题推向下次回顾；3）将模糊的"调查""改进"等动词替换为具体可执行的任务并设定责任人和截止日；4）从临时修复走向永久修复，确保同类问题不再发生。文章还讨论了一个反直觉的观点：过于频繁的回顾反而会制造"改善已有专属时间"的错觉，阻碍日常持续改进。适合困惑于回顾会议价值的团队和技术管理者阅读。
你的回顾为什么没用，以及如何改进
每个团队都必须相信改进，即使它已经不再发生了。回顾会议正是为此而设的。 大多数团队也会利用回顾会议来记录那些没人有时间去解决的问题。T...
如何在 Hacker News 上成功发布项目
作者自己的项目多次登上 HN 首页，这篇文章分享了具体可复用的经验和策略。内容包括：标题怎么写才不被改、什么时间点发布曝光最高、如何回复评论区的质疑来制造热度而非防御、以及为什么第一波 upvote 的节奏比内容本身更关键。全是第一手踩坑经验，不是泛泛而谈的"做好内容自然有人看"。对于想在海内外技术社区做冷启动的技术创作者来说，这篇有很高的实操参考价值。
为什么产品待办列表有害、永远减不下来，以及该怎么做
核心看点：待办列表（backlog）永远不会减少，因为它本质是"我们想做的事"而非"我们能做的事"。作者指出待办列表导致焦虑、错误优先级和低质量交付，并提出替代方案：限制在制品数量、只保留即将做的少数事项、用"问题跟踪"代替"功能列表"。文中有个人经验和具体方法，观点鲜明，对每一个在排期泥潭中挣扎的工程师和产品经理都有直接参考价值。讨论入口强——任何经历过 backlog 膨胀的人都会想反驳或补充。
如何把 Scrum 搞到再也跑不动
一篇讽刺味十足的反向指南。作者用幽默口吻列举团队如何"成功"扭曲 Scrum：把每日站会变成状态汇报、把 sprint review 变成演示表演、把 retrospective 变成互相甩锅。核心观点是 Scrum 的问题是它通常确实有效，这让很多爱发明轮子的技术人不爽。文章通过反例让读者对照反思自己的团队是否也在犯这些经典错误，语言生动有个人风格，适合技术管理者阅读讨论。
你根本不需要 Scrum，把看板用对就够了
一个直白到有点挑衅的论点：大多数团队选 Scrum 是因为别人替他们选了，而不是因为 Scrum 适合他们。作者对比了 Scrum 的固定节奏和看板的流动模型，认为很多团队的真正需求是限制 WIP、可视化瓶颈、持续交付——这些看板天然支持，而 Scrum 的 sprint 反而制造了不必要的紧迫感和任务堆积。文章有个人实践经历支撑，不是理论空谈，适合正处于敏捷流程反思期的工程团队阅读和辩论。
为什么截止日期毫无意义，以及该怎么做
作者认为截止日期毫无意义，反而导致加班、低质量交付和倦怠。建议用基于风险的交付、小批量迭代和持续价值交付替代固定截止日期，适合团队管理者反思进度管理。
在MMORPG里经营机器人农场如何让我踏入编程世界
作者14岁时为了在《仙境传说》中挂机打怪，自学编写外挂机器人，从而开启了编程之路。文章充满个人回忆和情感，描绘了从用户到创造者的转变，对游戏怀旧和编程新手有强烈吸引力。
有用的工程度量指标——以及为什么速度不是其中之一
开篇用星座运势类比 velocity（速度/速率）的无用性：听起来像那么回事，但实际无法指导任何决策。作者结合亲身经历，指出 velocity 最大的问题在于它被当作"产出量"来考核，导致团队自然会注水、拆分任务凑点数。文章提出了几种真正有用的工程指标：cycle time、deploy frequency、revert rate、MTTR 等，并有简要解释为什么它们更能反映工程健康度。有个人经验支撑，观点明确，适合工程团队讨论。
最小可行性空无一物：不构建产品来验证想法
验证产品想法最快的方式是销售，而非开发。作者强调「如果用户说好但不付钱，说明他们并不想要」，并列举用落地页、原型演示、预购等方式快速验证，对创业者和产品经理价值极高。
如何不建造一个自行车棚
作者以讽刺文学手法虚构一家「超级自行车棚公司」，极端化展示团队如何沉迷流程而非成果。全文幽默犀利，指出「自行车棚效应」的危害，对项目管理有启发性。
为什么高耸的层级会拖慢组织，以及如何解决
大型企业效率低下的根源在于决策信息需要层层传递。作者建议通过减少管理层级、授权一线决策、建立清晰的决策权限来加速组织反应，论据扎实，适合管理者阅读。
为什么你的每日站会没用，以及如何改进
每日站会已沦为形式主义，作者提出改进方案：聚焦工作流而非个人汇报，用看板可视化瓶颈，将站会变为协调工具而非状态更新。实用性强，适合团队迭代。
如何以及为何利用不确定性让产品更盈利
不确定性并非坏事，而是影响产品经济学的客观存在。作者提出通过实物期权思维、分阶段投资、灵活架构来利用不确定性获利，适合有一定产品背景的读者深入思考。
跟客户聊天：一个"颠覆性"的敏捷框架
用反讽口吻提出一个"颠覆性敏捷框架"——TTYC（Talk To Your Customers），讽刺业界把简单道理包装成复杂方法论的现象。作者一本正经地说自己即将出书卖500页图表来阐释"跟客户聊天"这个道理，幽默感极强。核心观点是：与其套用各种花哨框架，不如直接去跟用户聊。文章短小精悍，观点鲜明，读起来轻松有共鸣，很容易引起开发者转发讨论。
把手头的事做完，团队才能更高效、更可预测
讨论"做完一件事再开新任务"这个看似显而易见却很少有人真正做到的工程管理原则。作者指出团队最大的问题不是做得慢，而是在做的东西太多，导致上下文切换成本吞噬了产能。文章从个人经验出发，给出了减少WIP（在制品）的具体建议和团队协作上的落地方法。有真实场景描述，观点直接，对技术管理者有实际参考价值。