昨天說我是公司裡唯一一個負責數位轉型的PM，今天想先聊聊我平常都在做什麼～

需求從哪裡來

大致有四個管道，而它們給我的壓力不一樣。

需求方直接來找我： 這種需求真的是極少數，收到的時候我都覺得很珍貴，這類型需求通常最具體，因為對方已經知道自己卡在哪，但它也最容易變成插隊，因為來的時候往往是「這個應該很簡單，很快就能做出來吧」。

主管轉過來的： 從主管那裡轉過來的需求通常會是跨部門的需求，也是最花時間的需求，整個流程要釐清會需要找很多部門討論決定，而且有些流程本身也正在調整中，所以大家可能也都還沒有一個比較明確的流程出來，這類型的需求是最複雜但也蠻有趣的。

會議上被提出的： 這種會比較模糊，說的人可能只是隨口一提，但全場都聽到了，於是它就自動變成一件「應該有人要處理」的事，通常會後還會需要另外去確認是不是真的有這個需求。

第四種比較特別，是我在上課的時候發現的： 由於我同時負責公司內部的 AI 教育訓練，我都會趁上課或是他們來問問題的時候多了解大家工作的內容的細節，常常會聽到一些描述，比如說資料都是從 BI 匯出整理的、或是比對不同表中的數據等等，但說的人都不會把它當成需求，因為他們已經習慣自己做了。

我深刻感受到 很多流程之所以沒有被優化，很多時候是因為當事人根本不覺得那裡有問題。 所謂痛久了就不痛了，甚至學AI對他們來說也是一個不確定能獲得多少回報的事情，所以與其花時間嘗試用AI自動化結果失敗，不如就自己做一做還比較快，所以「發現需求」這件事對我來說有時候比解決需求更難。

要先做哪個？

畢竟只有我一個人，所以可想而知我收到的需求很多也很雜，而主管對我的管理也採放任制，也不太會管我要先做哪個需求。好是好在我可以自行規劃工作進度，壞就壞在我需要自行判斷哪個專案應該要先執行(當然我判斷完還是會跟主管回報一下)

而我一個人的時間有限，所以我也不是所有需求都會接受，在決定之前，我會先把 scope 切出來，問自己這四件事：

這是個人的需求，還是部門的？ 有些事情只有某一個人在做、用他自己的方式做，那自動化的價值就比較有限，假如他離職或換方法，做出的東西就沒用了，所以如果是個人需求的話，我通常會利用教學時間請他們自行嘗試看看。

流程上有沒有跨部門？ 單一部門的事情相對單純。一旦跨部門，就牽涉到誰對什麼負責，這種問題不是技術能解決的。

會不會牽連到其他流程？ 有些需求看起來是一個小點，但改下去之後，前後的流程也得跟著動。如果不先看到這一層，做完會發現只解決了中間那一段，兩頭還是卡的。

最後還有一個最重要的就是這個需求 是否有Deadline ，有些需求沒有明確期限，就可以有比較多充裕的時間去規劃，有些則是有時效性，像人資的年中績效考核，日期就在那裡，不會因為我還沒做好而延後。

一個專案大概怎麼走

理想上是這樣：

先訪談。 大致先了解需求，也了解目前的流程實際上是怎麼跑的，這一步的重點不是聽對方要什麼，而是弄清楚現在到底發生什麼事，因為有時候對方要的東西只是表面的需求，實際他可能是想達成另一個目的，才是我們真的要解決的事情。

流程複雜的話，畫一張流程圖給對方確認。 這一步我一開始不覺得是必要的，後來發現在畫的過程常常會抓出雙方認知不一樣的地方，我原本以為是1 -> 2 -> 3，通常畫出來之後會發現應該要改成 1 -> 1.1 -> 1.2 -> 2 -> 3，有時候也不是彼此溝通的問題，純粹是對方不覺得1.1、1.2也是一個步驟，所以流程圖意外的很重要。

做出 demo。 身在AI時代的我很幸運的可以使用AI工具先做出一個原型，直接有畫面呈現給需求方確認真的很方便，在這階段我主要focus在功能和流程上是否符合需求，而不會細雕UI的部分。

串真實資料，讓需求方協助驗證。 有時候用假資料看不出問題，真資料才會暴露那些「原來這個欄位是空的」、「原來這個數據要再另外處理」。

再強調一下，以上還是理想的情況。

實際上...

真實情況是：確認需求、確認流程圖、做出 demo，然後在 demo 之後又收到新的需求，更新 demo，再收到新的需求，一直循環往復...

這不是對方在刁難，只是多數時候大家要看到成果後，才知道他們自己要什麼，他們得先看到自動化實際長什麼樣，才有辦法想像它還能做什麼。流程圖上看起來合理的東西，變成可以點的網站之後，才會有畫面讓他們想像「啊對，這裡我們是不是可以讓他直接自動通知業務」。

所以來回是必然的，我現在的做法是把 demo 做得快一點、醜一點也沒關係，讓它早一點被看到，而不是花時間做到完美再拿出去。早一點被否定，比晚一點被否定便宜很多。

當然在這個階段，當夥伴發現一些自動化的好處時，也開始會有一些「天馬行空」的許願，所以還是需要適時的踩點煞車，不是什麼需求都要幫他們做出來，或至少分階段上線。

現在這條線上只有我一個人

把上面那些寫下來之後，有一件事變得很明顯：

收需求的是我，判斷 scope 的是我，訪談的是我，畫流程圖的是我，寫程式的是我，串真實資料的是我，跟需求方來回的是我，上線之後出問題的也是我。

這裡面沒有任何一個環節有第二個人。

好處是快，不用開會對齊，我想到什麼就可以直接做。
但除了我，沒有第二個人知道這些自動化的流程，也不是所有判斷都會被別人檢查過。
所以「之後要怎麼維護」這件事也一直是我的困擾。