刚接这件事的时候，我以为自己做的是一个业务模块。

真做进去才发现，它没那么简单。
页面和流程当然要做，但那不是最难的部分。真正麻烦的是，很多线下早就在跑的规则，其实没有被真正说清楚；很多人嘴上说的是需求，背后卡住的却是流程、口径和习惯。系统一旦要把这些东西接住，那些原来能靠经验、靠默认、靠“先这么办”混过去的问题，就都会冒出来。

这个项目后来对我影响很大。

因为它让我第一次很具体地意识到，产品经理很多时候并不是在“接需求做功能”，而是在把那些还没被讲清楚的问题，一点点理出来。

一开始看上去，它只是个平台里的一个模块

最开始大家对这件事的理解其实都很直接：

把计量支付这套流程搬到线上，让它能跑起来，效率更高一点，用户少做一点重复劳动。

听上去很顺。

一个模块，一套流程，几个页面，再加上一些业务规则，好像就是一件挺标准的产品设计题。
但这类事情最容易让人误会的地方也在这里。

表面上看着越清楚，真做进去以后，越容易发现很多关键问题其实根本不在表面。
计量支付不是单纯把几个节点连起来就完了。它背后连着合同清单、计量逻辑、审批流转，还有很多已经在线下跑了很久的工作方式。你不碰还好，一碰就会发现，很多东西并没有想象中那么清楚。

真正难的，不是把页面画出来

这个项目真正难的地方，不在页面怎么画，也不在流程图怎么排。
难的是，很多关键规则原本就是模糊的。

有些是靠经验在撑，有些是靠默认共识在撑，还有一些，说到底只是“以前一直这么做”。在线下，这些模糊地带还能被人用经验补上；一旦搬到线上，系统就会逼着你把话说清楚。

系统不像人，它不懂什么叫“差不多”。

它要的是明确规则，是边界，是口径统一，或者至少是口径可被兼容。
问题也正是在这个过程中一点点露出来的。

原来看上去像“做一个模块”，后来越做越像是在翻一套旧账：哪些流程本身就有漏洞，哪些规则其实并不统一，哪些做法只是沿用了很多年，但没有人认真想过为什么。

后来我花了很多力气，不是在定方案，而是在补理解

这件事真正开始往前走，是从我不再急着定方案开始的。
我先去补业务逻辑。

去学和计量支付相关的知识，去对流程，去看线下到底是怎么跑的，去听不同的人怎么讲同一件事。这个过程其实不漂亮，也没有什么特别“方法论化”的瞬间，更多时候就是反复问、反复对、反复确认。

做久了会发现，很多需求如果只停留在表面，根本看不出问题。

用户提的是一个点，背后连着的却可能是一整段流程，甚至是一套默认运转很多年的习惯。你不往后多追几层，最后做出来的东西，很可能只是“看起来像那么回事”，但真正落到业务里，还是接不住。

我印象很深的一件事，是预付款扣回的计算方式并不统一。

如果只站在系统设计的角度看，统一一种方式当然最省事；但事情一旦回到真实业务里，就没那么简单。不同做法背后都有自己的来路，也都还在被使用。如果一刀切，产品是好做了，业务反而会断。
后来我做的，不是强行替换掉原来的所有做法，而是先把线下流程理顺，再通过产品设计去兼容不同的计算方式。这样做不算“最干净”，但它能接住现实，也能让线上真正跑起来。

这个模块真正上线以后，变化不只是效率

模块上线之后，最直观的变化当然是效率。
原来在线下要跑很久的一套流程，到了线上以后，明显快了很多，重复劳动也少了不少。这个变化是看得见的，也是用户最容易感受到的部分。

但如果只说效率，我觉得还不够。
这个项目更重要的一点，是它不只是把流程搬到了线上。

它是在这个过程中，把原来那些一直含混着、但确实会影响执行的问题也一起拎了出来。有些漏洞被补上了，有些口径被讲清楚了，有些以前默认糊过去的地方，也因为系统要落地，被迫做了明确判断。

所以后来我再回头看，不太会把它简单理解成“做了一个计量支付模块”。

更像是借着做这个模块，把一段原本没被真正讲透的业务重新理了一遍。

这个项目后来留下来的，不只是结果

它后来对我影响很深，不是因为它有多复杂，也不是因为它做完之后看上去多完整。
而是它让我第一次很具体地意识到，产品经理真正难的地方，很多时候不是把方案写出来，而是先把问题想明白。

你面对的未必是一个已经被整理好的需求。

更多时候，是一团被流程、规则、角色分工和历史做法裹在一起的东西。不同的人会从自己的位置说出诉求，系统会从自己的位置提出限制，业务会从自己的位置强调重点，但这些东西放在一起，并不会自动变清楚。

产品经理如果只停在“接收需求”这一步，事情很容易越做越窄。

但如果愿意多往后追一点，把流程、规则、动机、约束、替代方案这些东西都放进来，很多判断就会不一样。
这个项目也让我慢慢接受了一件事：

产品不是所有地方都要做到最满、最极致。很多时候，更重要的是找到一个能成立、能推进、也相对合适的解决方案。它未必是最漂亮的答案，但它得先是一个真正能接住现实问题的答案。

如果现在再用一句话来概括这个项目，我会更愿意这样说：

我表面上是在做一个计量支付模块，实际上是在学着怎么把一个没被讲清楚的问题，慢慢想清楚。

驾驶舱这个项目，我一直很想放进网站里。
不是因为它看起来更“像成果”，也不是因为页面会更容易被看见。恰恰相反，它最有意思的地方不在页面上，而在页面前面。看上去是在做展示，真做进去以后才发现，真正难的是：客户脑子里有一个很大的设想，需求一直在动，交付时间却在那里不动，你既要把事情往前推，又不能把整个东西做得越来越散。

它不是一个那种可以坐下来慢慢想、慢慢磨的项目。

很多时候，边界是在推进里一点点长出来的，很多判断也不是等条件都成熟了才做，而是你得先做一个决定，让事情有机会继续往前走。

一开始，客户想要的是一个很大的东西

我刚驻场进去的时候，客户对接的领导提了一个很宏大的设想。
质量、安全、造价、智慧工地、BIM，几乎能想到的工程领域方向都想往里放。问题是，这里面有不少内容并不在我们原来的平台能力里，有些没有现成功能，有些连稳定的数据来源都没有。如果只是听这个设想本身，其实很容易被带着跑，越听越大，越做越像一个什么都想装进去的容器。

但这类项目最怕的也正是这个。

想法太大，边界就会变得很虚；边界一虚，后面所有事情都会被拖住。

我当时基本是驻在客户那边，需求随时来，我就得随时接。
一边安排研发计划，一边和 UI 讨论界面样式，一边把手下几个产品经理各自分到不同版块，由我先定一层大的基调，再带着他们和用户把内容先聊出一个轮廓，之后再由他们细化，我最后统一把关。整个过程其实一直是在边设计、边协调、边推进。

真正卡住的，不是做不做得出来，而是很多需求根本定不下来

这件事最难受的地方，其实不是做，而是很多时候你连“到底做什么”都没法彻底定下来。
有不少内容，客户那边的领导自己也希望先和交通局的领导确认之后再拍板。问题是时间一直约不上，需求就一直悬在那里。你能感觉到事情在那里卡着，但交付时间不会因为这个往后让。更现实的是，这个问题公司领导也帮不上太多，最后还是落回到项目现场。

这种时候其实很考验人。

因为你会发现，很多项目并不是缺执行力，而是缺那个“现在先定一版往前走”的时点。这个时点没人拍，事情就会一直挂着；一直挂着，看起来好像很稳，实际是在慢慢失控。

后来有一次，我就是直接定了一版需求，让研发先进入。
不是因为那是最完美的答案，而是因为项目已经不能再等了。对这种项目来说，有时候最重要的不是等所有人意见完全一致，而是先给它一个能继续长下去的版本。

我后来做的，不只是设计页面，而是在给它压缩复杂度

这个项目如果只是照着客户脑子里的设想平铺下去，最后一定会很臃肿。
所以后面我花了不少心思在“怎么让它别越长越重”这件事上。

有些平台里原本没有、而且后面也未必固定的数据，我没有强行往系统能力里塞，而是做成了模板导入的形式。这样一来，整体架构不会被拖得太重，二来也给后面调整留了空间，客户要改，产品还能跟得上，不会每次都动大手术。

还有些时候，客户急着汇报，页面又还没完全开发好，我们就会先把 UI 图直接挂到页面上，用一个很临时、但足够有效的方式先把汇报撑过去。
这当然不是理想状态，但项目现场很多时候就是这样。你得分得清什么是长期方案，什么是眼前先要过的坎。先把坎过了，事情才能继续往前走。

这一整段做下来，我慢慢有个很深的感觉：

驾驶舱这种东西，表面上看是在做展示，实际上你一直在处理的是“怎么给复杂度做减法”。不是把内容做少，而是让它不要一开始就把自己压死。

后来真正把事情推起来的，是那次周末的 PK

项目做到后面，突然来了一个很强的外部刺激。
客户那边来了另一家前海的公司，也是做驾驶舱的竞品，而且已经和客户领导有了初步意向。那时候我们其实和各项目还只是做了初步接触，这件事一下子就把节奏拉得很紧。公司领导知道以后，和客户高层做了沟通。周五晚上，研发副总经理把整个产品线各部门负责人召集起来，决定周末两天快速迭代一版，周一直接去和竞品 PK。

这件事后来回头看，其实很像一次临时拉起的战时状态。

周末两天，几乎所有产品部都各自负责一个业务板块同时开始优化。我们一边改，一边联系关系比较好的项目，反复确认真实的汇报逻辑和展示重点，尽量让做出来的东西不是停在“演示感”上，而是真的贴着项目实际在走。

最后一直干到周一早上 7 点，版本才上线。
那天去交通局领导那边 PK，是我主讲。对方还停留在 demo 阶段，我们虽然也很赶，但因为前面和项目沟通得更深，做出来的内容更贴近真实汇报场景，也更能体现项目以 BIM 管理为亮点的那部分东西，最后把这场 PK 赢下来了。

真正让我记很久的，反而是那次正式汇报

PK 完还没结束，下午客户领导就要带着这套东西去市里开会，给市领导演示。
那次是我操作，客户领导主讲。我们之前其实没有正式配合过，只来得及一起顺一遍流程。那一中午我基本都在一边跟领导过稿，一边用笔记时间点：讲到哪一页，几分几秒切什么页面，哪个地方停一下，哪个地方提前准备。下午正式演示的时候，我就照着那个节奏一路跟。

现在回头看，那次经历留给我的东西，已经不只是“完成了一次汇报”。
它更像是在提醒我，产品经理做的很多事情，最后都会落到一个特别具体的场景里：

有没有人真正在用它，关键时刻能不能撑住，它能不能跟上别人的表达节奏，它在那个现场里到底是加分，还是掉链子。

这个项目后来留给我的，是另一种对产品的理解

计量支付那个项目，让我第一次很具体地意识到，产品经理很多时候是在补规则、补理解。

驾驶舱这个项目留给我的，则是另一层东西：很多项目表面上是在做功能、做展示，真正决定它后面会不会越做越乱的，其实是前面那些判断。
边界怎么划，哪些内容现在就做，哪些先留接口，哪些地方先用临时方案顶住，什么时候该等，什么时候不能再等了，什么时候该自己先拍一个版本出来——这些东西听起来不像“产品设计”，但它们又确实在决定这个产品最后长成什么样。

它也让我更能接受“合适”这两个字。

不是所有东西都能一开始就按最完整、最漂亮的方式长出来。很多时候，真正有价值的是先抓住最关键的矛盾，把它做成一个能成立、能推进、也能继续往下长的东西。

如果现在再用一句话来概括这个项目，我大概会这样说：

我表面上是在做一个驾驶舱，实际上是在学着怎么让一堆还没定型的东西，先长出一个能继续往前走的框架。