被专家质疑三次后，我们终于找到了一条捷径

上周五下午，老王给我打了个电话，语气里带着明显的疲惫。

“又要答辩了。”他说，“第三版方案了，专家上次提了12条意见，我们改了两个星期，不知道这次能不能过。”

老王在一家省级事业单位做信息中心主任。他说的“答辩”，是每年都要经历的项目立项评审。厅里组织专家，对着他们花几个月做出来的信息化建设方案，逐条挑刺。

这场景其实不新鲜。我们接触过太多类似的项目——有的单位连续两次评审没通过，整个项目被推迟一年；有的方案被专家批“脱离实际需求”“技术路线不清晰”“预算测算缺乏依据”；更难受的是，专家意见经常相互矛盾，一个让往左，一个让往右，改都不知道怎么改。

说实话，写信息化方案这件事，本身就挺反人性的。

做业务的人不懂技术表述，技术出身的人又写不出业务痛点。两个部门来回拉扯，最后出来的方案往往是“谁都看不太顺眼”的妥协产物。而评审专家看方案，跟甲方看方案完全是两种视角——专家关注的是逻辑闭合性、技术合理性、投资规范性，而不是“我们想干什么就干什么”。

我们也是从无数次被质疑中学会这些的。

2019年开始，我们陆续帮一些单位写过方案。起初只是救急，后来发现这类需求越来越多，就专门拆解了近三年各省市信息化项目的评审要点，把专家习惯问的问题、习惯扣分的地方、习惯盯住的细节，全部反推到方案撰写里。

比如，专家最常质疑的三个点：

第一，需求不明确。 方案里写“提高工作效率”“加强数据共享”，专家直接打回来——提高多少？共享什么数据？跟谁共享？没有量化指标的需求，等于没有需求。

第二，技术方案“大而全”。 上来就谈大数据、人工智能、区块链，但跟实际业务场景完全对不上。专家一看就知道是套模板写的。

第三，投资估算缺乏依据。 软件多少钱、硬件多少钱、开发工作量怎么算的？说不清楚，专家就认为你虚报预算。

我们现在的做法是，先把业务流程画清楚，再谈技术。每个功能模块对应什么业务痛点，每个技术选型对应什么约束条件，每笔预算对应什么工作量。全部串成一条清晰的证据链。

有客户开玩笑说，我们写的方案“像律师写的”——每一句话都有出处，每一个结论都有支撑。

其实没那么玄乎。只是因为我们太清楚专家会看哪里、会问什么了。

前两天一个客户告诉我们，他们的方案一次性通过评审，专家只提了三条小的修改意见。而去年同一个项目，他们自己写的时候被追问了两轮。

回到老王。这次他的方案我们参与了，改到第三版的时候，专家意见从12条减少到了4条。上周四答辩完他发来消息：“过了。专家说这次逻辑比之前清晰多了。”

如果你也在为信息化建设方案头疼，被专家意见折磨得反复修改，不妨找我们聊聊。

我们不是写稿机器，而是帮你把方案做成“经得起追问”的那一种。