許願清單不能直接變成開發清單

一份收集了各部門期待的「許願清單」，和一份能直接交給開發團隊的「需求清單」之間，到底差了多遠？

很多時候，大家以為中間只差一個能把文字轉成系統規格的負責人。會議開完，表單也收齊了，接下來只要按表操課，好像就是最合理的下一步。

但麻煩通常就從這裡開始。

員工交上來的東西往往混雜了期待、抱怨，還有對現狀的各種想像。裡面少數幾條可能很精準，但大部分都非常模糊，更多時候他們其實是在抱怨舊流程有多卡，甚至順便暗示別的部門沒把事情做完。這份清單如果沒有經過梳理就直接往下發，那位負責人接到的，就會是一團充滿未知的組織情緒與期待。

說真的，被交辦這種任務，很容易讓人想深呼吸三次。

許願是原料，還沒有人清洗過

許願本身當然有價值。它能讓平常藏在流程縫隙裡的聲音被聽見。

你可能會看到第一線同仁寫下「希望報表自動產生」。再往下問兩句才會發現，原來他每週要花半個工作天，從五個不同系統把數字複製出來貼上。也可能有人只寫了「希望簽核可以快一點」，但實際的狀況是，一份文件常常擱在某個不常登入系統的主管信箱裡，一卡就是好幾天。

這些狀況都值得被看見。但它們還不能直接進入開發。

光是「希望報表自動產生」這一句話裡面，就藏著資料是誰要維護、欄位怎麼定義，還有萬一數字錯了到底算誰的。如果這層沒先釐清，直接開發下去通常就是無止境的返工。

PMI 的研究就提醒過，需求沒抓準往往會牽連到專案範圍無限膨脹，或者各方根本不在同一個頻道上溝通。¹ 這跟導入新工具的會議情境很像：每個人都覺得自己已經講得很清楚了，負責人卻發現大家腦袋裡裝的根本是不同版本的期待。

原料有味道、有現場感。可是它還需要清洗、分類，才知道到底能不能煮成一道菜。（這個比喻有點家常，但會議室裡常常就是這麼回事。）

被交辦的人，需要一張問問題的通行證

當老闆說「請你負責把大家的許願做出來」時，最容易被省略的動作，其實是授權那位負責人回頭重問一輪。

這到底是誰提的？問題多久發生一次？資料平常是誰在管？做出來後誰來驗收？

這些問題問起來有點煩。尤其在一個很想快點看到成果的組織裡，停下來問問題還常常被誤以為是在拖進度。

但沒有這些答案，負責人就只能硬著頭皮猜。猜業務單位想要的報表長怎樣，或者猜 IT 到底有沒有辦法把資料接出來。等到東西真的做出來，大家再補上一句「這跟我想的不太一樣」，整個案子又得重來。

IIBA 也在標準裡強調過，要把各方的資訊轉成可理解、可驗證的需求。² 換成白話來說，需求要先被確認過，還要能接回當初遇到的業務挑戰。跳過這一步，負責人背上的就是一個看起來很清楚、實際上卻毫無邊界的炸彈。

自動通知、跟催，有時候只是讓同一個混亂跑得更快

很多寫在紙上的願望，背後其實都是流程問題。

「希望系統可以自動跟催」聽起來像是一個簡單的通知功能。但實際往下看常常會發現，原來是表單送出後根本不知道卡在哪一關，不然就是主管出差時沒設定代理人。有時候，承辦人甚至連查詢進度的權限都沒有。

這時候如果只做自動跟催，系統就會很努力地提醒大家去跑同一個混亂的流程。

報表也一樣。在自動化之前，我們得先搞清楚數字從哪裡來、萬一對不上時要聽誰的。否則系統上線後，大家只是更快拿到一份還是得靠人工核對的報表。

先把現在怎麼做畫出來，再討論要改哪裡。³ 畫完流程後大家有時會尷尬地發現，系統功能其實只在流程的最末端。前面擱著的其實是誰有權限看、例外狀況誰來拍板，或者某個「大家一直以為有人在管」的三不管地帶。

如果那個空白沒被看見，開發清單會做得很冤枉。

把許願丟給一個人，通常扛不起來

Gartner 最近的 CIO 調查指出，平均只有不到一半的數位倡議能達到商業目標。他們特別提到，這需要 CIO 與業務高階主管共同扛起交付責任。⁴

這剛好打到了「把清單丟給單一負責人」的盲點。

如果把這件事丟給 IT，他們懂技術，卻未必推得動業務單位的流程調整。如果交給業務單位自己主導，他們雖然最清楚現場哪裡不順，但往往不知道背後資料庫跟資安的限制在哪裡。找一個人把所有期待扛下來，最後常常是責任很重，但實際能調動的資源卻很少。

比較合理的做法，是讓不同的人各自帶一塊拼圖進來。業務單位要把工作場景跟驗收條件講清楚，IT 負責踩住資料與權限的紅線。至於優先順序或是跨部門吵架，這只能讓主管層來拍板。那溝通和角色調整呢？這塊最常沒人認領，最後多半就落到 HR 或負責推動變革的人身上。

沒有人想要開更多的會。只是改變工作順序、資訊流向與責任歸屬這件事，一位負責人頂多只能從中協調，他不可能獨自擁有所有的答案。

填完表之後，然後呢？

收集意見看起來很像是一種員工參與。但如果表填完之後，沒有人回頭去訪談或澄清，這種參與就只會停留在「我講完了，接下來等你做」。

於是大家對這份清單的認知完全錯開。填表的人以為寫上去就一定會做，負責人可能只把它當成參考，而主管卻以為這張表就等同於最終的需求規格。三方都沒有惡意，但落差就這樣產生了。

這裡的「諮詢」絕對不只是發發問卷而已。我們得告訴大家，哪些期待這次會先處理，哪些因為某些限制得暫緩，而背後的理由又是什麼。

沒有這個回饋，這套機制很快就會失去信任。第一次填表大家可能很熱情，下一次大概就開始觀望了。等到第三次，團隊裡一定會出現這種聲音：「反正寫了也沒用。」

把願望先翻成問題

如果清單已經收好了，我會建議先不要叫它需求清單。我們可以先把每一項願望翻成要追問的問題。

graph TD

    A[原始許願：希望報表自動產生] --> B{第一層：場景與決策}

    B -->|釐清| C[支援哪個業務決策？]

    B -->|釐清| D[現在是誰在做？]

    C --> E{第二層：權責與風險}

    D --> E

    E -->|釐清| F[數字錯了誰負責扛？]

    F --> G[可驗證的開發需求]
    style A fill:#F9F9F9,stroke:#2C3E50,stroke-width:2px,color:#2C3E50

    style G fill:#F1C40F,stroke:#2C3E50,stroke-width:2px,color:#2C3E50,font-weight:bold

例如，當有人說「希望報表自動產生」時，要問的是這份報表到底支援哪個決策？現在是誰在做？如果系統撈出來的數字錯了，誰要負責扛？

又或者「希望簽核更快」，那目前到底是卡在哪一關？是沒人代理，還是權限設定有問題？如果大家「希望系統自動通知」，那要通知誰？收到通知後對方要做什麼？沒處理的話怎麼辦？

把願望翻成問題，是為了弄清楚組織到底要先面對什麼現況。

翻完之後你會發現，有些期待的確能靠新功能解決。但很大一部分其實是流程需要重新調整，或者是部門間的權責得先講清楚。甚至有時候，辦一場教育訓練就解決了。當然，也會有幾項因為現階段資料還沒準備好，或是風險太高而被暫緩。

那些被暫緩的理由，一定要說出來。這決定了大家下次還願不願意陪你玩這個遊戲。

把「做出來」改成「先翻譯」

如果我是那位被交辦的人，我會希望老闆先收回「把大家許願做出來」這句話。

換成：「請先把這些清單轉成需求判斷，釐清背後的流程與優先順序，再回來說哪些值得進入開發。」

這兩句話差很多。前者把人直接推進了交付的死胡同裡，後者給了他探索的空間，也讓其他部門知道：這件事不是把需求丟出來就好，你們自己也要幫忙確認流程、承擔取捨的責任。

導入新工具走到深處，處理的多半是組織怎麼做決定的問題。到底要先處理哪裡的摩擦？哪些舊流程必須被改掉？或者有什麼風險是不能拿速度去換的？光靠一張功能清單是回答不了這些問題的。

一份許願清單可以是個很好的起點。但只有經過實際的需求訪談、把流程盤點清楚，然後排出輕重緩急之後，它才適合變成一張開發清單。少了這一段，負責人做得越努力，越容易把自己推向一個大家都不滿意的結果。

每個組織能承受的前期盤點深度當然不一樣。小型內部專案可以輕一點；但如果牽涉到高合規性、資料風險，或者是跨部門權責很複雜的流程，就需要更嚴謹的把關。條件不同，做法自然要跟著調整。

只是有一個判斷可以先放在桌上：如果一份清單連現在的流程長怎樣、誰負責驗收都說不清楚，那它真的還不能直接當作開發規格。

引用

延伸閱讀

• [[企業 AI 轉型的真實卡點：當 KPI 走在應用場景前面]]
• [[HR AI 的下一步：從工具展示，走向工作流重構]]