在咱们公司最近做的那个“云端数据中台”项目里，实际上没那么光是堆砌技术和整规整齐的流程。 说实话，刚启动踩坑的时候，我就认定原型设计忒理想化了，根本没法落地。我们团队花了两周工夫对着文档和思维导图改了一堆原型，结局到了开发阶段，业务方突然说“这个交互要像咱们老客户的微信那样”，“这个搜索得赞成离线检索”。

这玩意儿直接就把原本能做的范围给缩成了能做的范围，最终项目延期了两个月，还出于需求频繁变更，害得研发经理的 KPI 被拉得特别难看。 刚启动的时候，我们确实当作只要把需求文档写得细一点，流程走一遍，难题就能迎刃而解。

那时候总认定写一坨长长的文字文档，就能把脑子里的创意全都装进纸面上了。结局呢，到了评审会上，整个团队都在这上面磨叽。业务人员说那个数据模型得重新画，测试人员说接口定义不清，运维说部署脚本忒烂。大家一个个对着 PPT 改，改到晚上十点，第二天又是“那个字段再调整一下”，改成了再调整。

那时候我就想，是不是自己忒天真了？

是不是项目本身就是个坑？ 后来我意识到，这种“文件大于功能”的怪圈，根源不在流程，而在沟通。我们当作只要把流程画好、文档写全，就能把散落在各处的需求都聚拢起来，统一处理。可现实是，业务人员根本不在乎那些画出来的流程图，他们只在乎做出来的东西能不能用。他们就连懒得读一页文档，直接拉着老板去拍板。

这时候，研发经理的权限变得挺尴尬，既要有推动业务的热情，又要有把控技术的底线。 有一次，我们搞了一个“用户画像”功能，本来想着能解决大量业务场景。结局做完才发现，业务方根本不用，就连认定忒复杂了，要改回好办的“标签”。更离谱的是，业务人员把需求调到了修改代码级别，说“这个逻辑得改一下，不然影响稳定性”。

这时候，要是沟通得好一点，要么业务方理解错了，要么我们就得把事做精。可碍于面子，我们只能硬着头皮在代码里硬改，最终害得系统上线后，性能直接掉线，用户反馈一堆 Bug，业务方也怪我们技术没跟上，还怪业务方需求不够清楚。

那一刻我才明白，大量“需求不明确”的难题，压根儿不是文档的难题，而是人心不定的难题。 那会儿我们总埋头写代码，总认定只要代码跑通了，需求就明确了。目前回头看，代码只是最终的交付物，真正的交付物是业务价值。

要是业务方想要的东西跟开发的技术选型彻底对不上，那就算代码写得再完美，那也是空中楼阁。 故此，我认定项目研发经理这个角色，真不是好办的“甩手柜”。你既要懂技术，得知道代码能跑通、性能够好，还得懂业务，得知道用户到底想要啥，就连有时候得去跟业务方吵架，去说服他们接纳你的技术方案。 最近复盘，我认定咱们项目最大的难题不是技术没跟上，而是“共识”没建立好。大量原本共性的难题，靠反复开会和开会聊聊，最终变成了一堆“版本 3 还是版本 4"的扯皮。

要是我们能早点意识到，需求文档里的每一条文字都不是绝对真理，而是假设和约定，情况可能会好大量。

要是业务方认定某个功能“忒复杂”如何办？我们能够现场演示，把复杂拆解成模块，展示每个模块的价值。

要是业务方认定数据模型“忒僵化”如何办？我们能够重新定义数据字典，让模型更灵活。 在这个过程中，我也发现了一件事：有些时候，业务人员就连不需求懂技术细节，他们只需求知道“这个能做啥”和“如何让它不那么难用”。

要是研发经理能多花点工夫去听他们讲业务逻辑，少花点工夫去解释技术难点，可能会好大量。 自然，我也不能吹嘘说，只要经理细心，难题就全解决了。项目总体的延期和 Bug 数量，还是受限于团队本事、技术债务还有外部环境的复杂。只是，我们起码把那些原本可能让项目彻底夭折的“需求冲突”，给化整为零，让大家都能清楚自己的职责边界。 最终想说，做项目研发经理，确实挺难。你每天被各种版本、各种 Bug、各种业务变更包围着，要随时预备着去跟不同性格的人打交道，去平衡技术和业务之间的张力。

这活儿，干得久了，你会发现自己没有黑眼圈，没有加班到凌晨，反而认定心里特别踏实。出于你知道，你是在帮业务把东西落地，而不是在为了写代码而写代码。 你看咱们公司这两年，别看也有不少“从 0 到 1"的艰难时刻，但也有不少“从 1 到 10"的突破。

那些成功的案例，背后实际上就是那种“不推诿、不甩锅、只讲结局”的氛围。

要是每个项目都能像咱们这个项目那样，坦诚地把“需求不明确”变成“沟通优化”，那可能就不会有那么多的延期了。 故此，别再指望画出一张完美的流程图就能搞定一切了。真正的打法，是要在不断的摩擦中找共识，在不断的妥协中求平衡。

只要大家不为了“流程对”而牺牲“业务结局”，那这个项目，大约就不会如此难做了。