驾驶舱这个项目，我一直很想放进网站里。
不是因为它看起来更“像成果”，也不是因为页面会更容易被看见。恰恰相反，它最有意思的地方不在页面上，而在页面前面。看上去是在做展示，真做进去以后才发现，真正难的是：客户脑子里有一个很大的设想，需求一直在动，交付时间却在那里不动，你既要把事情往前推，又不能把整个东西做得越来越散。
它不是一个那种可以坐下来慢慢想、慢慢磨的项目。
很多时候，边界是在推进里一点点长出来的，很多判断也不是等条件都成熟了才做，而是你得先做一个决定，让事情有机会继续往前走。
一开始，客户想要的是一个很大的东西
我刚驻场进去的时候，客户对接的领导提了一个很宏大的设想。
质量、安全、造价、智慧工地、BIM，几乎能想到的工程领域方向都想往里放。问题是，这里面有不少内容并不在我们原来的平台能力里，有些没有现成功能，有些连稳定的数据来源都没有。如果只是听这个设想本身，其实很容易被带着跑，越听越大，越做越像一个什么都想装进去的容器。
但这类项目最怕的也正是这个。
想法太大，边界就会变得很虚；边界一虚，后面所有事情都会被拖住。
我当时基本是驻在客户那边，需求随时来，我就得随时接。
一边安排研发计划，一边和 UI 讨论界面样式，一边把手下几个产品经理各自分到不同版块，由我先定一层大的基调，再带着他们和用户把内容先聊出一个轮廓，之后再由他们细化，我最后统一把关。整个过程其实一直是在边设计、边协调、边推进。
真正卡住的，不是做不做得出来，而是很多需求根本定不下来
这件事最难受的地方，其实不是做，而是很多时候你连“到底做什么”都没法彻底定下来。
有不少内容，客户那边的领导自己也希望先和交通局的领导确认之后再拍板。问题是时间一直约不上，需求就一直悬在那里。你能感觉到事情在那里卡着，但交付时间不会因为这个往后让。更现实的是，这个问题公司领导也帮不上太多，最后还是落回到项目现场。
这种时候其实很考验人。
因为你会发现，很多项目并不是缺执行力，而是缺那个“现在先定一版往前走”的时点。这个时点没人拍，事情就会一直挂着；一直挂着，看起来好像很稳，实际是在慢慢失控。
后来有一次，我就是直接定了一版需求，让研发先进入。
不是因为那是最完美的答案，而是因为项目已经不能再等了。对这种项目来说，有时候最重要的不是等所有人意见完全一致，而是先给它一个能继续长下去的版本。
我后来做的，不只是设计页面，而是在给它压缩复杂度
这个项目如果只是照着客户脑子里的设想平铺下去，最后一定会很臃肿。
所以后面我花了不少心思在“怎么让它别越长越重”这件事上。
有些平台里原本没有、而且后面也未必固定的数据，我没有强行往系统能力里塞，而是做成了模板导入的形式。这样一来，整体架构不会被拖得太重，二来也给后面调整留了空间，客户要改，产品还能跟得上，不会每次都动大手术。
还有些时候，客户急着汇报，页面又还没完全开发好，我们就会先把 UI 图直接挂到页面上，用一个很临时、但足够有效的方式先把汇报撑过去。
这当然不是理想状态，但项目现场很多时候就是这样。你得分得清什么是长期方案，什么是眼前先要过的坎。先把坎过了，事情才能继续往前走。
这一整段做下来，我慢慢有个很深的感觉：
驾驶舱这种东西，表面上看是在做展示，实际上你一直在处理的是“怎么给复杂度做减法”。不是把内容做少，而是让它不要一开始就把自己压死。
后来真正把事情推起来的，是那次周末的 PK
项目做到后面，突然来了一个很强的外部刺激。
客户那边来了另一家前海的公司，也是做驾驶舱的竞品，而且已经和客户领导有了初步意向。那时候我们其实和各项目还只是做了初步接触，这件事一下子就把节奏拉得很紧。公司领导知道以后，和客户高层做了沟通。周五晚上，研发副总经理把整个产品线各部门负责人召集起来，决定周末两天快速迭代一版，周一直接去和竞品 PK。
这件事后来回头看，其实很像一次临时拉起的战时状态。
周末两天，几乎所有产品部都各自负责一个业务板块同时开始优化。我们一边改，一边联系关系比较好的项目，反复确认真实的汇报逻辑和展示重点，尽量让做出来的东西不是停在“演示感”上，而是真的贴着项目实际在走。
最后一直干到周一早上 7 点，版本才上线。
那天去交通局领导那边 PK，是我主讲。对方还停留在 demo 阶段，我们虽然也很赶，但因为前面和项目沟通得更深，做出来的内容更贴近真实汇报场景，也更能体现项目以 BIM 管理为亮点的那部分东西，最后把这场 PK 赢下来了。
真正让我记很久的，反而是那次正式汇报
PK 完还没结束，下午客户领导就要带着这套东西去市里开会，给市领导演示。
那次是我操作，客户领导主讲。我们之前其实没有正式配合过，只来得及一起顺一遍流程。那一中午我基本都在一边跟领导过稿，一边用笔记时间点：讲到哪一页，几分几秒切什么页面，哪个地方停一下，哪个地方提前准备。下午正式演示的时候，我就照着那个节奏一路跟。
现在回头看，那次经历留给我的东西，已经不只是“完成了一次汇报”。
它更像是在提醒我，产品经理做的很多事情，最后都会落到一个特别具体的场景里：
有没有人真正在用它，关键时刻能不能撑住，它能不能跟上别人的表达节奏，它在那个现场里到底是加分，还是掉链子。
这个项目后来留给我的，是另一种对产品的理解
计量支付那个项目，让我第一次很具体地意识到，产品经理很多时候是在补规则、补理解。
驾驶舱这个项目留给我的，则是另一层东西：很多项目表面上是在做功能、做展示，真正决定它后面会不会越做越乱的，其实是前面那些判断。
边界怎么划，哪些内容现在就做，哪些先留接口，哪些地方先用临时方案顶住，什么时候该等，什么时候不能再等了，什么时候该自己先拍一个版本出来——这些东西听起来不像“产品设计”，但它们又确实在决定这个产品最后长成什么样。
它也让我更能接受“合适”这两个字。
不是所有东西都能一开始就按最完整、最漂亮的方式长出来。很多时候，真正有价值的是先抓住最关键的矛盾，把它做成一个能成立、能推进、也能继续往下长的东西。
如果现在再用一句话来概括这个项目，我大概会这样说：
我表面上是在做一个驾驶舱，实际上是在学着怎么让一堆还没定型的东西，先长出一个能继续往前走的框架。