廳長批示後的兩週，日子像繃緊的弦。
林凡每天上班第一件事，就是開啟內網系統，檢視方案流轉到了哪個環節。從辦公室發出，到秘書處登記，再到各相關處室會籤——流程的每一個節點，都像一道需要翻越的山。
第一週，建設處和規劃處籤回了意見。意見寫得很有技巧：“原則同意，但建議充分考慮實際操作中的困難。”——同意是姿態，困難是實質。
財務處趙處長簽得最痛快：“同意按會議討論意見推進。”他兌現了承諾，但也把球踢了回來——會議討論時大家提的那些困難，現在成了方案的一部分。
第二週，資訊中心和法規處的意見回來了。資訊中心的意見最具體，列了七條技術實現上的難點，每條都需要投入資源和時間。法規處的意見最嚴謹，指出方案中三處可能存在的合規風險。
林凡把這些意見整理成表格，逐條研究對策。每天下班後，他辦公室的燈都亮到九點以後。
週三晚上八點，劉建軍推門進來，手裡提著兩個盒飯。
“還沒吃吧？”
林凡抬起頭，這才感到胃裡空得發慌：“劉處，您怎麼……”
“我也加班。”劉建軍把盒飯放在桌上，“順便看看你。進展如何？”
林凡把意見彙總表推過去，苦笑道：“每個處室都同意，但每個處室都提了條件。把這些條件都滿足，方案就得推倒重來。”
劉建軍翻看著表格，看得很仔細。看完後，他說：“你知道這意味著甚麼嗎？”
“意味著阻力很大。”
“不。”劉建軍搖頭，“這意味著大家都在按規則出牌。提意見是他們的權利，也是他們的自我保護。如果哪個處室不提意見就同意，那才不正常。”
“那我該怎麼辦？逐條修改？”
“分三類處理。”劉建軍用筆在表格上畫線，“第一類，技術性意見，比如資訊中心提的資料介面問題——接受，寫進方案，但註明‘後續由技術小組專項研究’。第二類，原則性意見，比如法規處的合規風險——必須修改，不能留隱患。第三類……”
他頓了頓：“推諉性意見。比如建設處說的‘實際操作困難’——不修改，但寫個說明，解釋為甚麼這些困難可以克服。”
林凡記下了。這就是劉建軍說的“策略”：不是全盤接受，也不是全盤拒絕，而是區分對待。
“還有，”劉建軍說，“你要開始主動溝通。不要等意見來，要帶著方案去。”
“主動去找他們？”
“對。尤其是資訊中心和法規處。技術問題和法律問題，越早溝通越好。讓他們覺得你是去請教，不是去施壓。”
接下來的三天，林凡開始了他的“拜訪之旅”。
第一站是資訊中心。中心主任姓吳，四十出頭，技術出身，說話直接。
“林科，不是我不支援。”吳主任指著方案裡的技術架構圖，“你說的實時共享，理想很豐滿，現實很骨感。我們現在的系統，十年前建的，各部門資料標準都不一樣。要打通，得重新開發介面，這不是小工程。”
林凡沒有爭辯，而是拿出筆記本：“吳主任，您看這樣行不行？我們不追求一步到位，分階段實現。第一階段，先用最笨的辦法——每日定時匯出資料，人工核對後上傳到共享平臺。雖然不實時，但至少能做到每日更新。”
吳主任想了想：“這倒是可行。但人工操作，容易出錯。”
“所以我們設計嚴格的核對流程，雙人複核。”林凡說，“等試點成熟了，再考慮系統對接。這樣既推進了工作，也給技術升級留出了時間。”
這個折中方案打動了吳主任。他最終同意，在方案里加上“分階段實施”的表述。
第二站是法規處。法規處長是位女同志，姓孫，五十多歲，戴著金絲眼鏡，說話一板一眼。
“小林，你方案裡這個‘資料使用授權’條款，表述不夠嚴謹。”孫處長指著條文，“甚麼叫‘在必要範圍內使用’？必要範圍怎麼界定？誰來界定？這些都必須寫清楚，否則將來會有法律風險。”
林凡虛心請教：“孫處長，您覺得該怎麼寫？”
孫處長從抽屜裡拿出一本《政府資訊公開條例》，翻到某一頁：“你看，這裡對政府資訊的使用有明確規定。你可以參考這個表述，把‘必要範圍’具體化為‘履行法定職責所需’，並且加上‘不得用於與職責無關的用途’。”
“那如果某個處室認為他們需要某個資料來履行職責，但資料提供方不同意，怎麼解決？”
“設立爭議解決機制。”孫處長說得很清晰，“由辦公室牽頭，法規處、資訊中心參與，組成資料共享爭議協調小組。有爭議，上會討論，集體決策。”
這個建議很專業。林凡全部記下，承諾修改。
走出法規處，林凡感到一種奇特的成就感。這種一磚一瓦的溝通、修改、妥協，雖然緩慢，但每一步都紮實。他想起張懷民說過的話：“在機關裡，最快的速度往往不是奔跑，而是一步一個腳印。”
週五下午，林凡正在修改方案，手機響了。是青江大橋專案組的老王。
“林科，出事了。”老王的語氣很急，“大橋三號墩的施工方案，規劃和建設兩邊又槓上了。規劃說建設擅自改方案，建設說規劃審批太死板。現在工地停工了，每天損失十幾萬。”
林凡心裡一緊：“試點專案的協調機制沒用嗎？”
“用了，開過兩次協調會。但兩邊都堅持己見，誰也不讓誰。”老王說，“劉處讓我直接跟你彙報，說這個事……可能是個機會。”
機會？
林凡瞬間明白了劉建軍的意思。如果資料共享機制已經建立，如果規劃處的審批意見和建設處的施工進度能實時同步，這種誤會根本不會發生——規劃能看到建設每一步的調整，建設能提前知道規劃的要求。
但現在，機制還沒真正執行，問題已經發生了。
“我馬上過來。”林凡說。
半小時後，林凡趕到專案指揮部。會議室裡煙霧繚繞，規劃處的陳工和建設處的王工各坐一邊，臉色都不好看。
看見林凡進來，陳工先開口：“林科，你來得正好。建設處這次太過分了，三號墩的地質情況有變化，他們調整施工方案，不報批就直接幹。這是嚴重違規。”
王工立刻反駁：“我怎麼沒報批？一週前就打了報告，你們規劃處壓著不批。工地等不起，地下水都快湧出來了，我再等下去要出安全事故！”
“那你也不能先斬後奏！”
“我不先斬後奏，現在墩子已經塌了！”
兩人越說越激動。林凡聽明白了，問題的核心是資訊流轉太慢——建設處打了報告，規劃處審批需要走流程，但工地情況緊急，等不起。
如果……如果施工方案調整的申請、審批意見、執行情況，都能在共享平臺上實時更新呢？
如果建設處一提交申請，規劃處就能看到，就能啟動加急審批呢？
如果規劃處的每一次審查意見，建設處都能實時收到，就不會有“壓著不批”的誤解呢？
林凡沒有馬上調解具體矛盾，而是問了一個問題：“陳工，王工，你們兩位的意見，都願意為了解決這個問題，嘗試新的工作方式嗎？”
兩人都愣了一下。
“甚麼新方式？”
“資料實時共享。”林凡說，“如果建設處的方案調整申請，能實時同步到規劃處的待辦事項；如果規劃處的審批意見，能實時推送到建設處的手機端；如果整個流程的每一個環節，都能在共享平臺上看得一清二楚——今天這種誤會，以後還會發生嗎？”
陳工皺起眉頭：“技術上能做到嗎？”
“技術上可以分步實現。”林凡說，“最簡單的，建立一個微信群，專門用於這個專案的緊急溝通。所有申請、批覆、執行情況，都在群裡同步，@相關人。這不算高科技，但至少資訊不會丟失，責任不會推諉。”
王工先表態：“我同意。只要能把事辦成，甚麼方式我都配合。”
陳工猶豫了幾秒，也點了頭：“可以試試。但要有記錄，不能光在群裡說。”
“當然。”林凡說，“群裡的所有溝通，都會匯出歸檔，作為正式檔案的補充。”
接下來的一個小時，林凡建了群，把專案相關人都拉進來。他在群裡發了第一條訊息：
【青江大橋專案緊急協調群建立。從即日起，所有緊急事項均在本群同步。建設處提交三號墩方案調整申請，請規劃處接辦。@陳工】
王工立刻拍了申請檔案照片發上來。
陳工回覆：【收到。啟動加急審查，兩小時內給出初步意見。】
會議室裡的緊張氣氛，肉眼可見地緩和了。雖然問題還沒解決，但溝通的渠道通了。
兩小時後，規劃處的初步審查意見發到群裡：【原則同意調整，但需補充兩項安全驗算報告。請建設處今日下班前提交。】
王工回覆：【收到，立即安排。】
一場可能升級為責任事故的衝突，就這樣被一個簡單的微信群緩解了。雖然不是林凡設想的那種高大上的資料共享平臺，但原理是一樣的——資訊透明，流程可視，責任可溯。
晚上七點，補充報告提交了，規劃處也給出了最終批覆。工地恢復施工。
林凡坐在回廳裡的車上，看著窗外流動的燈火。他忽然意識到，劉建軍說的“等待時機”，可能已經來了——不是驚天動地的大事，就是這樣一個具體的、緊迫的、需要用新方法解決問題的時刻。
他拿出手機，給劉建軍發了條資訊：“劉處，今天青江大橋的事，用臨時群聊機制解決了。我有個想法，能否以這次事件為契機，向廳長彙報試點機制在解決實際問題中的價值？”
十分鐘後，劉建軍回覆：“明天上午，帶著完整材料來我辦公室。時機到了。”
林凡握緊手機，看向窗外。
東風來了。
不是狂風暴雨，而是一縷恰好能鼓動帆船的風。
而他，已經張滿了帆。
接下來的航行，不會平靜。但至少，船已經動了。
回到辦公室，林凡沒有下班。他開啟電腦，開始整理今天的全部材料：衝突起因、協調過程、群聊記錄、問題解決的時間線。他要寫一份簡明扼要的案例報告，用事實說明，資訊共享機制不是理論設想，而是現實需求。
鍵盤敲擊聲中，夜色漸深。
這座城市有無數盞燈亮著，每一盞燈下，都有人在為各種事情忙碌。而林凡的這盞燈，今晚格外明亮。
他知道，明天將是另一個開始。
一個用實踐證明理論，用案例推動變革的開始。
而他，已經準備好了。