 |
| 感謝 OCF 讓我 cosplay 網站產品經理，解決了沒有頭銜給別人帶來的困擾 |
上禮拜收到莫名的邀請信，雖然不知道在幹嘛，但網兇就叫我去。結果各種陰錯陽差之下，這系列活動的三場座談，我都全數參加完了，而且也都打了野生的逐字稿... 因為逐字稿錯誤百出也沒有取得與會者同意，所以想看的朋友可以私下跟我要連結，如果是我不認識的人，據說官方有錄影錄音完整記錄，感覺應該之後會釋出，可以過陣子再追蹤看看。
因為關於會議的各種安排，好像蠻臨時的，會前提供的資訊也頗雲霧，加上耳聞各種民間人士去參加這類會議的慘劇，導致我一直以為會議的本質是找吉祥物來替既定政策背書，所以這十分鐘的發言到底要講什麼，才不會背書得太過份、又不會得罪到人、最好還可以真的有些建設性，著實讓我苦惱了一番。直到昨天從資策會的夥伴那邊得知原來座談會之後還會有工作坊，才發現這會議好像是認真的（驚）於是大幅修改了講稿，放了比較多真心話進去 XD
今天因為借用 OCF 的頭銜，不好意思穿星際大戰的 T shirt，就素 T 外面披一片黑色窗簾布過去，結果一去遇到國發會某友，她就該該叫說天啊 ETBlue 妳怎麼穿這麼正式超 OL 的氣質完全不一樣耶 blahblah ... = ="
幹嘛這樣，偶爾 cosplay 人類臭了ㄇ
會議資訊
主題：數位政府-社福一站式便民服務專家座談會
時間：2017/10/27 (五) 14:00-16:00
地點：應用力學研究所 R400 會議室，國立臺灣大學
主辦：insight 台大智活（臺大智慧生活科技整合與創新研究中心）
簡介：詳 活動邀請函
與會：衛福部苦主、彰化縣苦主、新竹市苦主、嘉義市苦主、新北市第一線社工苦主、國發會苦主、台大智活歡樂正能量主持人賴老師、各領域傑出專家七位、以及莫名亂入的阿宅我
幾位專家裡面除了李維斌局長原本就知道以外，最難忘記的是黃朝盟老師的名字，因為主持人介紹他的時候說：
「昨天我們想了很久，到底要唸成黃ㄓㄠ盟還是黃ㄔㄠˊ盟，後來決定唸成黃ㄔㄠˊ盟，因為我們覺得黃老師～又潮～又萌～～～♥」
眾人：「......」
話說這是我第一次聽說台大智活這單位，三場座談觀察下來，覺得他們真的是充滿誠意與正能量的團體，工作人員也很溫暖可愛，喜翻～<3 然後一開始在選場次的時候，原本我想去的週五場額滿了，他們還特別幫忙橋過去，感動 QAQ
如果說有什麼可以調整的地方，大概就是會議的前置作業吧？雖然許多人都說公家機關的會議就是那樣，臨時抓人來，不明就裡地開完會，大家換名片順便互捧一下 social 完然後解散，是標準的常態。但身為很少參加政府會議的草民，實在覺得很不習慣。畢竟我參與過的民間辦的座談會，議程都處理得非常細緻，邀約通常會在至少一個月前提出，經費來源、上游業主、整體計畫的架構、座談會的定位等關於計畫案本身的資訊，通常會在邀約時主動揭露，讓與會者可以判斷會議背後的政治脈絡。會前主持人會把同場次的與談人拉到同一個 email 群組彼此協調發言的角度和內容，共筆通常會早早開好，讓大家隨時想到什麼可以丟上去。
這些會議的前置作業，真的非常耗費心力，但為什麼要做？就是為了確保會議當天大家都在狀況內，彼此的資訊落差不會太大，可以在同樣的知識基礎上對話。畢竟這麼多人齊聚一堂的時間非常寶貴，應該用來互相激盪，而不是重複提出一些已知的事情，這樣會議所產出的內容也更有機會把事情往前推進一步。先前家華在 Blulu 提出審議的表與裏，其實不只是審議會議，其他類型的會議也是，會議活動本身是表面，容易被看見，但重要的卻是裏面，也就是前置作業跟後續回應。如果可以每場會都開得更有效、更深入，那是不是大家就可以少開一點會，多做一點其他事情...
額，不過依照政府單位的出席費計算方式來看，可能與會專家們也不想花太多時間在會議前後的溝通吧？畢竟多做這些裏面的事情，也不會多出顧問費，自我剝削之外還增加主辦單位的麻煩，可說是害人害己。
想到這邊，決定還是把原本考慮寄給主辦單位的意見吞回肚子裡，畢竟，這種公家機關主計制度下的困境，主辦單位應該比我更清楚，也更無奈，能像現在這樣撐出跨界座談會的空間，已經很難能可貴了。身為袖手旁觀的草民，也只能幫 QQ 惹。
發言稿全文
為了這個發言稿，這幾天騷擾了很多大大，特別感謝各路高人指點，包括 Whisky、KNY、Tz、MH、Bobby、以及素昧平生卻拔刀相助的 Max 老師，各位請受我一拜 m(_ _)m
以下發言稿全文，連同本文以 CC BY-ND 4.0 授權釋出：
開場
大家好，我昨天才知道原來今天座談的內容，還會帶去後面的工作坊，不是開完畫押完就沒了。其實前幾天跟一些常參加類似會議的朋友討論，一直以為開這個會是為了趕驗收，我可能只是被找來當橡皮圖章的，但看起來是我想法太負面了，在這邊先跟主辦單位道歉 XD
座談會專家與計畫承辦人的共同困境
昨天資策會的夥伴有特別交代說希望針對社福的計畫內容提意見，但因為這個計畫從 2015 年開始規劃兩年，從今年開始執行了十個月，我接觸才一兩天，其實很狀況外，所以我提的意見可能不會比路人好到哪裡去。另一方面是，一般政府計畫書的撰寫方式比較不是業界習慣的溝通語言，我拿到計畫書會先找業務跟對應的使用者族群的清單，然後 user journey map，但公部門的計畫書通常不是用這樣的方式來表達，所以除非找到懂的人來問，不然比較難從計畫書裡面瞭解到我需要的資訊。
前面兩場週一跟週四的座談會，我有去旁聽，發現很多專家提出的意見其實都已經有確定的答案，像是什麼卡在法規，卡在流程，卡在跨部會，或者事情已經在進行了只是不在這份計畫書，有些意見好像就變成無效的意見。這些無效意見不是說提出的人有什麼問題，而是資訊落差下必然的結果。昨天聽起來最犀利的是李局長，可能因為他原本就在公家機關所以比較瞭解。
今天我被賦予的任務是提供有價值的意見，但我無法達成這個任務，不是說我特別怠惰，也不是主辦單位的要求特別機車，而是時間跟知識上的資源不允許，這個資源的限制，其實跟會議本身的程序有關。我比今天衛福部的朋友幸運的地方是我不是公務員，任務沒達成不會被專家電，但我們面對的困境可能很相似，就是我等一下想分享的關於程序的問題。
自我介紹
我今天的 title 是開放文化基金會的網站產品經理，這是我參與的其中一個專案，我的發言不代表基金會。我過去在設計、企管、程式這幾種領域工作，所以目前在網站開發的專案裡面通常扮演跨領域協調的角色，以今天的主題來說，我思考的角度會跟系統開發外包案的甲乙雙方的窗口比較接近，接下來就提供這方面的看法。
網站企畫常見問題：內容與設計的斷裂
過去經驗裡面，不管是政府的或者是私人企業的網站，如果是需要傳遞很複雜的資訊的網站，很容易發生的現象是網站內容跟網站設計的斷裂。
這個斷裂的意思是說，業務單位提供的內容，從網站設計的角度來看不能用，可能是文案的寫法讓一般人看不懂，可能是內容分類的方式是以分工為主、不是以功能為主，或者不同業務提供的資料很不一致，也可能是 metadata 因為填寫的人不知道它們的用途，所以每個欄位都貼一樣的東西。
當內容與設計的斷裂遇上網站外包
這個斷裂其實是正常的現象，因為第一線經手業務的人不懂網站設計，做網站設計的人不懂第一線業務。從業務導向的內容變成設計導向的內容，中間需要轉譯，這個內容轉譯，就是他們 UX 說的資訊架構，我們政府網站最主要的功能就是整理資訊，而資訊架構就是這方面重要的專業，但是據我所知，國內的產業生態裡面，資訊架構師比較不是獨立的專業職位，通常是企畫或者 PM 順便兼著做，所以實務上可能變成要有跨領域的企畫或 PM。
但跨領域的企畫或 PM 很少見，這時候，如果網站開發的團隊是組織內的自己人，那內容跟設計的斷裂，就可以透過頻繁的組織內部的溝通來彌補。如果是發包出去，那業務單位跟網站開發團隊變成甲方跟乙方的關係，雙方的利益就不一致了，這時候內容跟設計的斷裂，就會反映在最後上線的網站上，可能有些就會變成民間專業社群會截圖討論的素材。
可能的解法：改良網站開發的程序
所以今天想提出一個作法，是稍微調整網站開發的程序，在真正實做之前，先撐出一個空間，把內容跟設計的斷裂銜接起來。也就是說，第一期的發包案不是網站開發，而是網站企畫，以業務單位為主體，請相關領域的顧問進來跟網站的 PM 也就是承辦窗口 cowork，用網站設計的視角來盤點業務內容，也用網站開發的視角來分析利害關係人的需求。
網站前期企畫案的工作內容
這邊講的利害關係人，除了網站的使用者以外，還有資訊部門的同仁，還有各級長官，他們可能為了某些壓力需要在某個時間點之前優先完成某些目標。還有其他業務上有往來的單位，他們可能會有分工跟流程銜接上的意見。
另一種類型的利害關係人，是各領域的專家。比方說，開放資料的專家可能會要求資料欄位命名之前建立跨部會通用的語彙庫，將來才能做 linked open data，或者 db schema 的欄位設計要符合某些國際通用的標準。資料經濟領域的專家則可能會要求提供 api 時對政府內外的 api 必須公平。其他使用者經驗啊，服務設計啊，系統開發啊，資訊安全啊，公共行政啊，就是今天在座的各位專家，應該也都有各自專業領域的要求。
以往專家們可能比較多是以評審委員的身份參與，在期中期末驗收會議前才看到執行狀況，廠商可能就在會議上被電，才知道做錯了，被電完以後趕快想辦法應付，用 workaround 的方式趕結案。但這很多時候不是廠商怠惰，而是跨領域整合跟企畫的空缺所造成的專業知識的落差。如果企畫階段可以先把各領域的需求梳理清楚，尤其是跟業務內容和使用者端緊密相關的 user journey 或資訊架構之類的文件可以先確定，那設計跟程式發包的時候，招標規格書就不用寫得那麼模糊，廠商也比較不用憑空猜測很多事情，最後就比較不用臨時改來改去，相信甲乙雙方的痛苦指數都會下降，最後做出來的東西也會比較符合使用上的需求。
結語
社福一站式的計畫已經在執行中，應該大部分都已經第一包出去開始實做了，如果有將來才要發包的，或者是做完一版，要進入下一輪週期的，也許可以在程序上做一些微調，撐出企畫的空間。
昨天工商場次有聽到一個初步的共識，是一站式的系統要讓公務員 deload 減輕負擔。現在網站跟資訊系統的世界很複雜，需要各種跨界整合，不是任何單一領域的人可以應付，所以在開發出讓公務員 deload 的一站式系統之前，是不是可以先有個讓公務員 deload 的開發一站式系統的程序？就像是政策規劃前會做前期研究，網站開發前是不是也可以做設計面向的前期研究？
這禮拜的幾場座談會有很多跨領域的火花，接下來的工作坊可能會更深入，但我想會議跟工作坊都是比較短時間的，個人的經驗是跨領域的整合需要長時間的溝通跟協作，各位在座的專家都有自己的專業，業務單位也有他們第一線人員的專業，這些不同領域的專業人士如果可以有足夠的時間跟資源，在同一個團隊裡面協作，有一致的利益和目標，一起完成網站企畫，一起撰寫發包的規格書，這樣可能比較有機會規劃出讓各界滿意的系統，去打破各種評審會議上父子騎驢的輪迴。以上是我從網站開發的執行面跟跨領域協調的角度的想法。
Call In 時間
最後代替朋友請教三個問題：
1. 社福一站式服務跟 1957 福利諮詢專線之間的關係
2. 一站式的網站會取代原本的官網嗎？如果會，那關於組織執掌、各單位主管局長處長這些不屬於服務本身的資訊，會放在哪
3. 各種整合查詢平台、或者小幫手 app 等等面對末端使用者的系統，是不是有公開的 api 讓民間開發者也能平等地取得，如果有的話可以在哪裡找到
後記
上面這些講完後，因為跟計畫內容無關，所以並沒有在會議中產生什麼迴響，但總算是把我一直以來在不同專案中重複看到的、因為基礎程序問題導致的各種悲劇，以及目前想得到的解法，都整理出來了。
總而言之，當你覺得窮盡力氣，卻仍然做不到期望的水準，在自責之前，可以先檢查程序本身。個人觀察，大部分沒做好的事情都不是來自不為，而是來自不能。而這個不能，有時候是人格特質或者專業水平的問題，但更多時候，其實是程序上少了應有的前置或者中繼的步驟所導致的必然結果。
這些程序的問題，通常都跟第一線的基層無關，而是跟做議程設定的決策者有關。而決策者之所以制訂出不合宜的程序，通常也不是來自不為，而是來自不能，決策者的不能，多半來自管理專業知識的缺乏。可以想像的是，世界上的專業何其多，多數的決策者並沒有足夠的時間跟精力去鑽研管理學，因此決策者缺乏管理專業知識，是很正常的，於是，各種不合身的程序所導致的痛苦，也就成為一種普遍存在的現象。這些都不是誰的錯，而是在人類文明發展的過程中，自然會遭遇的瓶頸。
不管怎麼說，意識到問題的存在就是解決問題的第一步。當越來越多人注意到程序的問題，對應的管理手段就會漸漸地被討論、漸漸地成為顯學，最後廣為人知，變成一種常識。到時候，就又可以開始探索下一個瓶頸了。
今天提出這樣的思考角度，希望可以幫助到一些自責而迷惘的靈魂... XD
場邊花絮
今天發生一件令人毛骨悚然的事情，李局長臨走前匆匆塞了一張名片說「之後有機會可以一起玩～喔呼呼♥」然後一臉奸笑地離開了。我坑被推得夠多，知道接下來會發生什麼事，看來這段時間務必日夜顛倒，深居簡出，宜打電動不宜出門，以免所經之處地層下陷，遭受無妄之災（南太）
會後窩在走廊邊查 google map 的時候，可能看起來太路痴了，隔壁深擊設計的大大看不下去，就很好心地幫我人肉導航到馬路口，一邊疑惑問我不是台北人嗎，我解釋說我很少出門。最後發現我沒有用 ubike，大大就震驚了，問我到底是多不常出門！我想大大這麼年輕有為，以前一定是沒認識過整天家裡蹲打電動的廢柴吧...
阿宅臭了ㄇ
沒有留言:
張貼留言