1、为什么"用户说的"和"用户要的"不一样一个经典故事：客户说"我要一匹更快的马"，而真正的需求是"更快地到目的地"。如果团队照着字面做，交出去的就是一匹养不起的马。需求获取（Requirements Elicitation）之所以难，是因为：用户说不清：他们描述的是"解决方案"，不是"问题"。用户不说全：日常习惯性的东西，他们觉得"这还用问？"用户之间会打架：销售要灵活，财务要管控，运维要稳 …

1、为什么"排期"总是崩几乎每个项目都有同一个场景：计划表上写着"4 月上线"，到了 4 月，进度条停在 60%。原因通常不是团队不努力，而是估算是拍脑袋的、排期是理想化的、风险是没算的。本课解决三个问题：单个任务的时间，怎么估才不离谱？一堆任务，怎么排出一条真正可行的路？风险和缓冲，怎么留才不是自欺欺人？2、估算的三种常见错误错误一：只报"最好情况"。"这个接口两天能写完。"——对，如果在没 …

1、范围是项目的"承诺书"，也是最容易失控的地方项目章程里那句"范围"，其实是一份承诺：我保证做完这些，别的先不承诺。范围失控有个形象的名字——范围蔓延（Scope Creep）：今天加个按钮，明天加个报表，后天"顺便"再改个流程……每一项单看都"不大"，合起来却能把项目拖垮。它的可怕之处在于每一次都打着"顺便"的旗号，而"顺便"永远不会出现在排期里。所以本课的核心，就是学会三件事：把模糊的" …

1、立项的结论，要"落纸"第 2 课我们算清楚了"值不值得做"。但结论停在脑子里，等于没有结论——半年后没人记得当初为什么做、答应过什么、边界在哪，于是争议、返工、扯皮全来了。所以立项之后第一件事，是把结论固化成两份东西：项目章程（Project Charter）：项目的"出生证明"，写下被授权的目标、范围、边界和负责人。干系人地图（Stakeholder Map）：找出所有会被项目影响、或能 …

1、立项不是"走流程"，是"先花小钱省大钱"上一课说，项目最贵的失败是"做了没人要的东西"。立项阶段的唯一使命，就是在花大钱之前，先用小钱判断这件事该不该做。打个比方：立项就像造房子前的看地和勘探。勘察花几万块，能避免你把楼盖在滑坡上、白扔几千万。软件开发里，立项花的是几天到几周，能避免的是几个月到几年的浪费。所以立项的核心不是"写一份好看的 PPT"，而是回答四个问题：为什么要做？（问题/机 …

1、先讲三个"翻车"的故事故事一：三个月的"小需求"。老板说："就加个导出 Excel 的功能，很简单吧？"开发说："简单，一周搞定。"结果三周后，发现导出要权限、要大数据量分页、要兼容三种旧模板、还要审计日志……最后做了两个月，还漏了"导出后不能重复下载"这条，被业务方投诉。问题不在技术，在于没人先把"想要什么"问清楚。故事二：最勤奋的团队做出了没人用的东西。一个五人团队闷头写了四个月，代码 …

这是全书的最后一课。前面三十课，你学了 fork/exec、管道、重定向、信号……现在，我们把它们合流，亲手用 C 写一个能跑的真 shell。你会发现：你天天敲的 ls、cd、sleep 10 &，背后其实都是同一套机制。 写完它，你就真正"驾驭"了操作系统。从"你敲的那条命令"说起你敲下 ls -l | grep txt > out.txt，回车，结果出来了。这一瞬间，she …

前面二十九课，我们把操作系统从"进程"一路学到了"容器"，理论齐了。但真正的高手，不只是"懂原理"，更要会动手排障——系统卡了、内存满了、程序挂了，你能定位问题在哪吗？这一课，我们学一套"用命令解剖操作系统"的硬功夫。这是第九阶段（实战收束）的第一课，也是最"实用"的一课。从"体检"说起人身体不舒服，医生会做体检：量血压、验血、拍片，一步步定位病灶。系统也一样。它"不舒服"时（变慢、卡死、内存 …

现代系统几乎都跑在云上、容器里。你可能天天用 Docker，却未必想过：Docker 凭什么能做到"秒级启动、互相隔离"？ 它和虚拟机有什么本质区别？这一课，我们把 Docker 的"黑魔法"拆开看——你会发现，它调用的全是 Linux 内核早就有的能力。这是第八阶段（虚拟化与容器）的唯一一课，也是全书倒数第三课。从"一栋楼 vs 一套房"说起要把"一台机器当多台用"，有两条路：虚拟机（VM） …

前几课，你学了一整套 shell 武器：变量、判断、循环、函数、管道、三剑客。但光会写还不够——一个能上生产的脚本，还得健壮（出错能处理）、能定时自动跑（cron）、好排错。这一课，我们把知识合起来，写一个真正能用的自动化运维脚本，并让它按时自动执行。这是第七阶段（Shell 与脚本编程）的收官课。从"人工运维"到"自动运维"想象你每天要做这些事：备份文件、检查磁盘和内存、清理旧备份、记日志。 …