那会儿接了个新项目，我们整个团队基本都觉得这是个“送分题”。为啥这么说？当时我心里想，这真是飞龙骑脸，怎么输？
是核心技术栈，我们早就玩儿得门儿清了，团队里这些兄弟，个个都是身经百战的老兵，随便拎一个出来都能独当一面。架构嘛之前好几个类似的成功项目都是用这套，稳如老狗。最让我觉得稳妥的是客户那边，需求文档给得那叫一个细致，图文并茂的，几乎把每个功能点都掰开了揉碎了讲。而且我们还专门开了好几次需求澄清会，把所有潜在的疑问都提前解决了，客户代表每次都说“没问题，理解得很到位”。
有了这些“优势”，我们撸起袖子就开干了。项目经理把任务拆得那叫一个清楚，大伙儿领了活儿就开始噼里啪敲代码。我主要负责的是最核心的用户认证和权限模块，这块儿我写过好几次了，真的就像肌肉记忆一样，手指头自己会动，代码写起来行云流水，每天看着进度条蹭蹭往上涨，心里那叫一个得意。测试团队也早就介入了，什么单元测试、集成测试、UI测试，各种测试方案都准备好了，说是要一条龙服务，把所有隐患都提前挖出来。
项目中期，按照计划，我们第一次给客户做阶段性演示。当时，团队里每个人都信心满满的，觉得肯定能拿到满堂彩，客户看了不得把我们夸上天。结果，客户看完，脸色直接就垮下来了。项目负责人支支吾吾地说了一堆，总结起来就是一句话：这不是他们想要的！
我当时就懵了。脑子里嗡嗡的，不是？我把手里的鼠标都捏紧了。需求文档白纸黑字写着，每次会议的纪要客户也签字确认了的，怎么就不是想要的了？他们开始各种“回忆”，一会儿说当时表达的意思不是这样，一会儿说某个按钮“应该”是那样的，反正就是各种推翻之前确认的东西。整个会议室的气氛一下子就变得特别压抑。
从那天起，噩梦就来了。项目变成了无休止的扯皮和争吵。我们团队把需求文档翻出来，一个字一个字地跟客户对，可他们就是不认，说我们“没有理解他们的深层含义”。白天在会议室里吵得面红耳赤，晚上回去还得加班改需求。而且改起来哪儿那么容易？我负责的权限模块是整个系统的基石，他们要改认证逻辑，那就意味着牵一发而动全身。我这边改一个地方，可能其他好几个模块都要跟着动。改完之后，新的Bug又像潮水一样涌出来，怎么都修都修不完。团队里的抱怨声也越来越多，有的说客户出尔反尔太不靠谱，有的说项目经理之前把控得不严。整个团队之前那种“赢麻了”的精气神儿，全没了，取而代之的是焦躁和疲惫。有天晚上，项目经理找到我，一脸严肃地说：“老王，你那边核心模块要是再稳不住，这项目真就得黄了。” 我听得心里直发毛。
项目是硬着头皮上线了，功能勉强能跑起来，但离我们最初设想的那个“精品”目标，真的是差了十万八千里。客户虽然嘴上没多说什么，但我们都知道，他们心里肯定是不满意的，所以后续给我们的新项目明显就少了。回过头来想，当时我们最大的问题就是太“想当然”了。觉得技术实力强，经验又足，文档又全，就觉得一切尽在掌握。但实际？客户的需求它会变，甚至有时候客户自己都不知道自己到底想要什么，他们的“想要”是在不断变化的。我们团队太强调“按章办事”了，没能及时捕捉到客户在沟通中那些隐晦的变化，也没有去有效引导他们，让他们明确自己的真正需求。那次经历真的给我上了一课，让我明白，技术再厉害，看起来优势再大，也架不住“沟通不到位”和“对变化反应迟钝”这两大杀手。现在我接项目，第一件事就是强调“定期深度沟通”和“灵活调整机制”，绝不能再犯那种“飞龙骑脸都能输”的低级错误了。
