当事情真正进入“要交付”的阶段时，我才发现，自己关注的重点并不是技术。
那时候，我并没有第一时间去想用什么框架、什么架构，
也没有急着画系统图、列模块清单。
我最先反复确认的，其实不是用什么技术方案，而是一些更现实的问题。
一、交付一旦成立，很多事情就不能再“慢慢看”
在项目还停留在想法阶段时，很多问题是可以被搁置的。
但一旦确认“这是要交付给客户的东西”，很多模糊空间就会突然消失。
我会下意识地去想：
- 这个系统交出去之后，我还能不能接得住
- 如果线上出了问题，我是不是知道从哪里查
- 客户要改需求的时候，我还有没有余地可以调整
这些问题如果现在不想清楚，
后面再想，成本只会更高。
二、我最先确认的，是“这个系统我能不能完全掌控”
在真正要交付的时候，“可控”这件事会变得异常重要。
这里说的掌控，并不是指控制客户，
而是一些很具体、很工程的问题：
- 这个系统里每一块核心逻辑，我是不是都清楚
- 哪些地方是关键路径，哪些地方可以慢慢调整
- 出问题的时候，我是不是只能靠猜，还是有明确的判断路径
如果一个系统让我在交付前就感到不安，
那它后面大概率也不会让我轻松。
三、比“能不能做”更重要的，是“后面好不好改”
在和客户讨论需求的时候，我发现自己会刻意多问几句：
- 这个功能以后大概率还会不会变
- 这个规则是不是可能被推翻
- 如果半年后要改，代价会不会很大
这些问题，和“现在能不能实现”关系不大，
但和“这个系统会不会变成负担”关系很大。
我越来越在意的，不是“现在写得快不快”，
而是“我有没有给以后留空间”。
四、我会刻意避开那些“现在省事、以后麻烦”的方案
在交付压力下，其实很容易做出一些选择：
- 先写死，反正现在需求就这样
- 先绕一下，等真要改再说
- 先把功能做出来，后面再优化
这些做法我以前不是没用过，
但也正是这些选择，往往会在后面反过来消耗你。
一旦系统开始跑起来，
很多“后面再说”的事情，其实就很难再有机会认真处理了。
五、在这个阶段，技术方案反而不是最着急的
这也是为什么我会说：
当客户真的要交付时，我最先考虑的不是技术。
不是技术不重要，
而是技术方案通常是有解的。
真正难的是先想清楚：
- 哪些问题现在必须面对
- 哪些复杂度现在就要承担
- 哪些事情一旦写进去，就很难再回头
如果这些判断没想清楚，
后面选什么技术，反而都只是被动应对。
六、我更愿意慢一点，把边界想清楚
在交付节点前，我宁愿放慢一点节奏，也要想清楚几件事：
- 这次交付的边界到底在哪里
- 哪些需求我可以明确拒绝
- 哪些扩展我可以提前考虑，但暂时不实现
因为一旦交付完成，
这个系统就不再只是“我自己的项目”，
而是进入了一段长期关系。
写在最后
当事情真正走到“要交付”的那一步时，我才意识到：
技术选型从来不是第一步。
第一步，是先想清楚你愿意为哪些结果负责。
也正是从这个阶段开始，
我才慢慢把注意力从“怎么把功能做出来”，
转向了系统该怎么设计。
后面很多看起来像“技术选择”的决定，
其实都是在这个判断之下，自然做出来的。
