晚上十点，项目群又多了十几条“顺手加一下”

前几天晚上，娃终于睡着，我轻手轻脚把卧室门带上，打开电脑准备收个尾。结果项目群里已经刷了十几条消息：这个字段顺手加一下，那个按钮能不能提前露出来，某个客户明天要看，最好今晚能确认方案。

以前遇到这种场景，我的第一反应很产品经理：开文档，拉表格，按模块整理需求，再标优先级。看起来很专业，甚至有一种“我在控场”的错觉。后来项目做多了才发现，有些表格只是把混乱排版得更整齐，像给一个漏水的桶贴创可贴。

复杂项目里，最怕的不是需求多，而是大家都在说功能，却没人说清楚这个系统到底要解决什么。产品经理如果一上来就被功能清单拖着走，很容易变成一个高级需求收集器，谁催得急，谁就先进入版本。

先问清楚：这件事到底要让谁变顺

我现在会先忍住不画页面，先问一句：这个系统到底要让谁的什么事情变顺？是让一线门店少录一次单，还是让总部财务更快对账？是提高转化，还是降低误操作和合规风险？这些听起来都叫“优化系统”，但落到功能上完全不是一回事。

比如以前做互联网医疗相关项目时，业务方说想加一个审核功能，表面看就是多一个审核按钮、多一个状态流转。但往深一层问，真正担心的是医生误操作、资料不完整、后续追责说不清。那这个需求的重点就不是“按钮放哪”，而是风险怎么被拦住。

目标一旦不同，优先级就会变。为了提效，可能要减少人工判断；为了控风险，反而要增加关键节点确认。产品经理的价值，不是把所有诉求平均塞进版本里，而是把模糊的话翻译成团队能判断的目标。

系统感不是大词，是把边界画清楚

很多项目吵起来，不是因为大家不配合，而是边界没说清。这个字段谁维护？状态是谁改？异常订单谁处理？客户退回后是回到上一步，还是重新发起？这些问题如果一开始不问，后面就会在群里反复出现。

所以我会先把流程拆一遍：谁发起，谁处理，谁审核，谁兜底；哪一步系统自动完成，哪一步必须人工判断；什么情况算正常，什么情况算异常。画到这里，经常会发现，原来大家脑子里的“同一个流程”，根本不是同一个版本。

边界清楚以后，功能反而会自己浮出来。需要哪些入口、哪些状态、哪些提醒、哪些权限，不再是凭感觉凑出来的，而是从流程里长出来的。这个时候再画原型，心里会踏实很多，不会只把某个页面做漂亮，却让整体跑不通。

功能上线不是结束，能不能复盘才关键

以前我也犯过一个毛病：功能上线那天很兴奋，发版邮件写得像小作文，第二天就投入下一个需求。直到某天业务反馈“这个功能好像没什么用”，才发现我们根本没有留下足够的信息去判断它到底有没有发挥作用。

现在搭系统时，我会提前想数据闭环。这里说的数据，不只是埋点报表，也包括操作日志、业务单据、状态流转、异常原因。关键动作有没有记录？状态变化能不能追踪？出了问题能不能知道卡在哪一步？这些都决定了后面能不能复盘。

一个功能有没有价值，不该只靠上线时大家的掌声。产品经理至少要能回答：它有没有让事情变好？如果没有，是流程没跑通，使用成本太高，还是一开始目标就错了？能被验证的功能，才不是一次性的交付。

别为了一次上线，给未来挖坑

项目紧的时候，临时方案特别有诱惑力。先写死，先手工，先绕一下，先上线再说。每一句都很合理，尤其在客户催、老板问、研发排期爆炸的时候，听起来简直像成熟职场人的妥协艺术。

但复杂业务系统最现实的地方在于，今天的临时方案，很可能会变成后面每个版本都绕不开的债。字段含义没定义清楚，后面报表口径会吵；权限没想清楚，后面每加一个角色都要返工；异常处理没留口，线上一出问题就只能人工救火。

这几年我越来越觉得，做系统有点像带娃。不是今天哄睡成功就万事大吉，还要想她半夜会不会醒、明天会不会因为没睡够而崩。产品设计也是一样，要有一点面向明天的耐心。AI 可以帮我整理会议纪要、润色方案，但系统边界和长期取舍，还是得自己一层层想清楚。

我的顺序：目标、流程、数据、维护，最后才是功能

如果项目已经很乱，我现在会给自己一个小顺序：先确认业务目标，弄明白这件事为什么值得做；再画流程边界，看它在系统里到底怎么跑；接着补数据闭环，想清楚怎么知道它跑得好不好；然后考虑长期维护，判断以后变复杂时能不能接得住。

最后才是功能清单、排期和原型。这个时候，功能不再是一堆孤岛，而是系统里的零件。哪些必须先做，哪些可以后置，哪些看起来很急但其实不影响主链路，判断会清楚很多。

混乱不会因为我们画了一张图就消失，客户还是会催，业务还是会变，资源也不一定突然变多。但当系统搭起来，团队至少有了共同地图：知道哪里能改，哪里不能随便动，出了问题该回到哪里看。对我来说，这就是产品经理在复杂项目里的一点点安全感。

功能是会长出来的，前提是你先给它一片能站住的土地。