Part 03｜当客户真的要交付时，我最先考虑的不是技术

当事情真正进入“要交付”的阶段时，我才发现，自己关注的重点并不是技术。

那时候，我并没有第一时间去想用什么框架、什么架构，
也没有急着画系统图、列模块清单。

我最先反复确认的，其实不是用什么技术方案，而是一些更现实的问题。

一、交付一旦成立，很多事情就不能再“慢慢看”

在项目还停留在想法阶段时，很多问题是可以被搁置的。

但一旦确认“这是要交付给客户的东西”，很多模糊空间就会突然消失。

我会下意识地去想：

• 这个系统交出去之后，我还能不能接得住
• 如果线上出了问题，我是不是知道从哪里查
• 客户要改需求的时候，我还有没有余地可以调整

这些问题如果现在不想清楚，
后面再想，成本只会更高。

二、我最先确认的，是“这个系统我能不能完全掌控”

在真正要交付的时候，“可控”这件事会变得异常重要。

这里说的掌控，并不是指控制客户，
而是一些很具体、很工程的问题：

• 这个系统里每一块核心逻辑，我是不是都清楚
• 哪些地方是关键路径，哪些地方可以慢慢调整
• 出问题的时候，我是不是只能靠猜，还是有明确的判断路径

如果一个系统让我在交付前就感到不安，
那它后面大概率也不会让我轻松。

三、比“能不能做”更重要的，是“后面好不好改”

在和客户讨论需求的时候，我发现自己会刻意多问几句：

• 这个功能以后大概率还会不会变
• 这个规则是不是可能被推翻
• 如果半年后要改，代价会不会很大

这些问题，和“现在能不能实现”关系不大，
但和“这个系统会不会变成负担”关系很大。

我越来越在意的，不是“现在写得快不快”，
而是“我有没有给以后留空间”。

四、我会刻意避开那些“现在省事、以后麻烦”的方案

在交付压力下，其实很容易做出一些选择：

• 先写死，反正现在需求就这样
• 先绕一下，等真要改再说
• 先把功能做出来，后面再优化

这些做法我以前不是没用过，
但也正是这些选择，往往会在后面反过来消耗你。

一旦系统开始跑起来，
很多“后面再说”的事情，其实就很难再有机会认真处理了。

五、在这个阶段，技术方案反而不是最着急的

这也是为什么我会说：
当客户真的要交付时，我最先考虑的不是技术。

不是技术不重要，
而是技术方案通常是有解的。

真正难的是先想清楚：

• 哪些问题现在必须面对
• 哪些复杂度现在就要承担
• 哪些事情一旦写进去，就很难再回头

如果这些判断没想清楚，
后面选什么技术，反而都只是被动应对。

六、我更愿意慢一点，把边界想清楚

在交付节点前，我宁愿放慢一点节奏，也要想清楚几件事：

• 这次交付的边界到底在哪里
• 哪些需求我可以明确拒绝
• 哪些扩展我可以提前考虑，但暂时不实现

因为一旦交付完成，
这个系统就不再只是“我自己的项目”，
而是进入了一段长期关系。

写在最后

当事情真正走到“要交付”的那一步时，我才意识到：

技术选型从来不是第一步。
第一步，是先想清楚你愿意为哪些结果负责。

也正是从这个阶段开始，
我才慢慢把注意力从“怎么把功能做出来”，
转向了系统该怎么设计。

后面很多看起来像“技术选择”的决定，
其实都是在这个判断之下，自然做出来的。