这件事，为什么该由我们来做？

看这份中国政策机会地图，我觉得有一件事需要先想清楚：事情确实需要有人做，为什么就该由我们来做？

金融系统要改造，城市管网要治理，建筑企业要把工程和财务的数据接起来。每个方向都能讲出需求，也都能找到政策依据。顺着这些材料往下看，很容易开始安排团队，估算收入，甚至觉得眼前只剩执行的问题了。

但这里面，其实跳过了很长的一段。谁已经在做，客户还缺什么，我们有什么能力值得他再付一笔钱，这些都还没有回答。一个行业发生变化，当然值得关注；只是关注之后，得把自己能做的事情单独拿出来审视。不能因为方向有道理，就顺便证明了自己的选择有道理。

材料里有个细节，我想先拿出来说。

江门的一个城市生命线项目，要求基于省标准版对接，而且明确禁止另建平台。这个采购期已经过去了，我想借它看清客户的要求。

假如我们带着一套新平台过去，功能更丰富，界面更漂亮，演示也做得很完整，可客户根本没有让你另起一套的空间。这时候，准备得再充分，也可能是在一个错误的方向上越来越熟练。

真正要往下研究的，是已经有的平台还需要怎样接入本地设备，设施编码怎么对应，历史数据怎么清洗，告警怎样进入实际处置。这些要求会把团队的工作限定得很具体。你得进去了解现有系统，理解使用部门的分工，才能知道自己有没有可以补上的那一段。

所以我会先放下“我们能做一个什么产品”的想法，看看客户已经做到了哪里。对方已经投入的钱、已经建好的系统，以及已经确定的责任，都构成了我们做事的条件。绕开这些条件谈创新，很容易谈得痛快，做起来却处处碰壁。

金融里的数据库迁移，也可以沿着这个思路看。

假设一家机构换了数据库，安装顺利，白天跑几张报表也没问题，可到了晚上，批处理迟迟跑不完，第二天业务人员上班，报表还没出来。这时候，产品已经装上了，业务却接不住。

问题可能在查询语句，可能在数据转换，也可能在原来的作业顺序。到底是哪一处，要拿实际的数据和负载去查。查完还得改，改完还得测，上线以后出了问题，又得有办法退回来。这个过程里，工程能力才有机会被具体地看见。

这份材料讲的 FDE，可以理解为进入客户现场、参与实际交付的工程团队。名字可以先放在一边，工作要落到这些事情上。客户明天能不能按时拿到那张报表，比我们把技术路线讲得多漂亮，更接近他眼前的困难。

当然，看到这里也还不能急着算生意。

材料列了成都银行的一份历史采购样本，数据库许可之外，还包含迁移、部署、集成测试和培训。它说明工程服务确实进入了采购范围。但既然已经被放在采购范围里，就得继续查：现有厂商承诺交付哪些工作？哪些由它自己完成，哪些需要合作团队？假如这些事情都已经有人负责，我们打算补在哪里？

不能把客户的工作清单，直接抄成自己的收入清单。

如果要从厂商或总包的合作里进入，我们还得回答一个更实际的问题：我们的加入，能替对方解决什么他原来解决不了，或者投入很大才能解决的问题？如果回答仍然只是“我们也懂技术”“我们可以安排工程师”，这份能力就还没有说具体。一个困难的兼容问题，一段需要反复核对的数据，或者一套确实能在切换失败时执行的回退方案，才有继续谈分工的依据。

对照这份材料，如果先选一个试点方向，我会从数据库迁移里的外围系统找起。先把任务收在一个能够说清范围、单独验收的系统里，拿到数据，列清依赖，把迁移、测试和回退完整地走一遍。外围系统也有复杂性，核心账务系统的风险和责任更要另外判断；这里想争取的，是让第一轮投入和结果能够对应起来。

这么选，就得放下把客户所有需求一次包下来的念头。有些工作不接，合同金额可能也没那么好看。但我想先知道，给定这些条件，我们究竟能不能交付；哪一项能力已经具备，哪一项还欠缺，代价究竟有多大。第一单如果什么都往里装，最后做得艰难，也很难说清究竟是哪一步出了问题。

而且做完以后，应该有些东西能留下来。哪些兼容问题反复出现，哪种测试能提前暴露风险，客户的哪一项准备工作当初漏算了，把这些整理清楚，下次判断工期和报价就有了自己的依据。要是每接一单都得从头摸索，全靠几个人临时救火，团队很忙，能力却未必在积累。成功的项目也得回头分析，不能只在做砸以后才想起复盘。

建筑企业的数据贯通，也可以采用这样的试点思路：先选一个单位，把工程、合同和财务里的项目编码对应起来，让数据可以追溯，再判断是否扩大。客户需要的最终结果可以很大，我们第一次承担的范围，要和当下的能力相称。

算账这件事，尤其容易让人提前乐观。

材料有一个内部测算：四个月，平均投入三个人，就是十二个人月；按每人月五万元的假设，得到六十万元的含税服务合同额。数字很整齐，但五万元只是这份材料采用的估算口径，并非市场已经接受的报价，也不是工程师的月薪。

拿着这六十万元，我们还得继续往下算。人员、差旅、测试、合作分账，后续要承担多久维护，客户分几次付款。每一项都可能改变这个项目的结果。合同还没签，利润也没算出来，心里倒先觉得这门生意能做了，这一步要小心。

还有一个很不起眼的前提。材料里的实施周期，从资料和环境就绪以后开始计算。

假如三个人准备进场了，测试环境却还没给，数据授权也没完成，这段等待由谁承担？人员能不能调去做别的项目，还是得留在这里随时响应？一个原本按四个月估算的项目，拖下去以后，收入未必跟着增加，投入却不会自己停下来。

所以试点方案里，我会把客户需要准备的条件、双方的责任和付款阶段一起列出来。有些事靠加人可以快一点，有些事要等客户做决定，加多少人也没有用。得尽早约定，这些条件没有具备时，如何调整进场和实施安排。否则外部条件造成的延误，就可能被我们全变成团队内部的加班。

图上的机会不会替团队付工资。客户的预算也要经过合同和付款，才真正成为我们能够使用的钱。

这样往下想，第一阶段的工作就可以收窄了。围绕这个外围系统的试点，去找有具体任务的客户，或者需要补充交付能力的厂商。数据安全整改、城市生命线接入和其他方向继续留在地图上，不必同时变成团队要承担的项目。

先看手里真正有什么。熟悉哪一类系统，有没有对应的交付经验，能不能通过合作伙伴接触实际负责的人，对方是否愿意开放必要的资料和环境。这些条件要具体到人、具体到项目。“认识一些人”和“能够开始工作”，中间也还有距离。

地域也按这个顺序选。材料关注广东、海南、四川和重庆，具体先去哪，我会优先考虑能够接触到实际负责人的项目。地方财政支持可以帮助我们找线索，但落实到采购和付款，还需要具体的预算与合同。能见到人，拿到必要资料，并讨论明确任务的那条线索，值得先花时间。

如果用九十天做第一轮验证，我希望把这个试点推进到双方可以判断是否开工的程度。

先见实际使用系统的人，弄清他反复遇到的困难；再和负责预算、采购与技术的人一起，把问题和可进入的范围核对清楚。如果任务明确、资料和环境能够安排，也有可行的采购路径，就投入诊断，把人力、验收和付款摆到桌上。调查应该帮我们决定在哪里多花一分力气，避免不断扩大待办清单。

也可能查到最后，发现原厂已经覆盖了这些工作；或者客户需要改，但近期没有预算；又或者，我们暂时没有能力承担。那就该把这条线索放下。如果一轮调查只能替最初的想法补充理由，却不能让我们排除一个不合适的项目，这个调查做得恐怕还不够。

到这里，我想先做的事情就比较清楚了：找一个范围明确的外围系统，在预算、环境和责任都能落实的前提下，把第一次迁移和验收走完整。让客户的实际使用来检验我们的判断。

把一单做成，再看看究竟是怎么做成的。到了那时候，对机会的判断才算多了一份自己的依据。