项目失败以后

2024 年秋天，我负责的项目上线，结果很差。用户不买账，数据往下掉，团队也没了劲。技术上有问题，但修完那些问题，项目仍然谈不上成功。

我是技术负责人，那阵子压力很大。现在回头写，可以把事情一件件分开，当时却做不到。项目没做好，和自己是不是根本做不好这份工作，常常混在一起。

我后来反复想的一件事是，自己把太多精力花在了架构上。代码怎么组织、以后怎么扩展，想得很细；用户为什么需要这个功能，却没认真问过几次。仿佛技术方案足够好，用户自然会喜欢。

结果是，功能确实做出来了，也花了不少心思，但没多少人愿意用。现在再开始一个项目，我会先把这个问题问清楚，哪怕讨论的结果是暂时别做。总比做到一半才发现根本没必要强。

沟通上的问题也不少。设计师以为的交互、产品经理想要的效果，和我理解的不是一回事。大家各自忙着往前赶，直到把东西拼起来，才知道前面的讨论并没有说透。

返工时很容易怪对方没讲清楚，可我也没有主动确认。后来才肯多花一点时间，把需求复述一遍，拿具体例子对照一下。听起来琐碎，却比做完以后争论当初谁说过什么省事。

这次失败还暴露了一个我不太愿意承认的习惯：我喜欢待在自己擅长的部分。技术问题有熟悉的排查办法，用户愿不愿意用、团队为什么拧不到一起，却很难靠一个漂亮的解法处理。以前遇到这些，我会下意识把话题拉回代码。

后来躲不开了，只好学着问，学着听，也承认有些事我没把握。写这个博客，也是从那段反思开始的。有些话当面说不清，写下来，才看出自己哪里一直在绕。

我不想把那次失败说成一件好事。项目没做成，浪费过的时间和力气都是真的。只是事情已经发生，回头看清楚，总比一直躲着它好。再做下一个项目时，我还会犯错，至少希望别原样再犯一次。