软件项目盘算里，那些看起来零零散散的子盘算，实际上往往像是一架精密的机器，各个齿轮之间互相咬合，松一点都会卡死。它们根本不是啥平行的平行线，而是有着明确层级和先后顺序的咬合关系。最典型的情况是，一个大型项目被拆分成“需求分析”、“系统设计”、“编码实现”、“测试”这些大块，但这几个大块之间也是层层嵌套的。
比如“编码实现”这个大子盘算，它里面又包含了“前端开发”和“后端开发”两个具体任务。前端开发要依赖后端供给的接口文档，后端开发又要在前端代码里埋点。
要是前端和后端的工作没对上，代码就像半吊子，后期得重新啃回来，成本更高。 再看“设计”这个大板块，它和“需求分析”的关系就像地基和盖房子的关系。需求分析得先把房子的户型图、承重墙位置画出来，设计才能画上帝之物。
要是需求分析阶段漏掉了一个关键接口，设计阶段画出来的架构再完美，落地起来也是空中楼阁，随时可能翻车。
这种依赖关系是硬性的，画错了需求，设计就没法做；画错了设计，需求就没法过审。 还有一个好办被漠视但贼关键的关系是“并行”与“串行”的博弈。
有时候子盘算之间能够与此同时进行，比如“逻辑设计”和“数据库设计”，两者能够一起忙，互不干扰。但像“UI 原型设计”和“UI 开发”就不中，原型一旦画定，开发就得照着干，这时候务必串行。
要是设计阶段改了，开发务必停工重画，这中间的工夫差就是成本增添的地方。项目经理得时刻盯着这些关系，确保不会让并行任务拖成串行，要么让串行任务干等忒久。 数据上的例子确实能直观说明难题。假设一个电商项目，总盘算是三个月。其中“支付接口开发”这个子盘算，要是先做了前端界面，后端排队等着，那这个后端任务就得串行化，耽误整个上线工夫。但要是“订单系统”和“库存系统”是独立打通的，它们就能够并行推进，各自对接数据库，最终集成时再合并。
要是项目节点赶在月底前，这种并行空间就丧失了意义。 在写盘算表的时候，你得看清这些依赖线。
比如“单元测试”往往要等到“编码”做完后，才能启动，它和编码是严格的串行。而“回归测试”就要等所有代码做完才能启动，它和整体编码是串行的，但和单个编码师是平行的。有些关系是跨组的，比如“保险评审”，产品经理、开发、测试三个人都得参加，缺一不可。
这种多阶段参与的关系，要是搞混了顺序，评审就无从下手。 口语来说，这些关系就是项目标骨架。骨架拉直了，肉（业务逻辑）才能正常生长；骨架歪了，整个项目就塌了。
有时候“子盘算”不是好办的 A 加 B，而是 A 是 B 的容器。
比如“核心模块”包含了“登录”、“订单”、“支付”这些子盘算。核心模块做得不好，里面的子盘算再完美也救不了整体。
这时候就要在核心模块里进行权衡，砍掉一些非核心的子盘算，要么优化它们的优先级。 最终还要寻思风险。出于盘算里各子盘算的关系紧密，一旦某个环节出了难题，牵一发而动全身。
比如前端开发进度滞后，可能害得需求修改，进而害得后端接口设计变更，就连引发测试用例覆盖率的下降。
这时候单纯说“子盘算要同步”就忒轻描淡写了，得明确指出：前端晚一天，后端就得倒推三天，测试就得多花两天查错。
这种连锁反应就是依赖关系带来的真威力。 故此，制定任何项目盘算，都不能把子盘算当成独立的条目堆砌。要把它们当成一张网，看清楚每一根线连着哪位，哪根线断了整个网都晃。
只有这样，项目推进时才不会遇到那种“明明看着在干，实际上卡在瓶颈上”的尴尬局面。