決選簡報逐字稿¶
1¶
大家好，我是XXX。原定的報告人YYY現在在ZZZ參加他的UUU，不克前來。只好我來代打。
2¶
先停頓三秒… 然後講(要微笑喔)，這不是投影機壞了，也不是國防布。這真是我們的簡報， 它代表著各位委員等一下腦中的認知模型。
為什麼? 我接下來要講一個YYY真實體驗的故事。
某次颱風過後，我在住家附近閒逛，居然看到有顆檳榔樹倒了，而且還壓到了一根電線桿， 混凝土製的電線桿肯定是不會被壓壞的， 但該死的是這顆樹的大部份重量是作用在接電線的絕緣礙子上面。 我不知道它是否承受得住這顆檳榔樹，所以我趕緊回家上網查台電的客服電話。 對，當這是好幾年前的事了，當時還不流行3G網路及智慧型手機，那個時候， 我拿的是 Palm Treo 650 ，它也還沒有辦法用 wifi 上網呢。
有了電話號碼，及 palm 拍下的電線桿桿號相片。接下來，我就撥給台電，是位小姐接的， 於是我把剛剛看到的路樹壓電線的情況再描述一遍，然後再把電線桿桿號報給她。 結果客服小姐居然說她不懂什麼是電線桿桿號，這真的比扯鈴還扯，這桿號就像電線桿的身份證， 在台電的資料庫中，它還能對應到電線桿的 GPS 座標、尺寸及什麼廠商立的…bal a.bala.
於是，我只好跟她報地址了，這根電線桿的所在地是在一個沒有農舍、沒有門牌的檳榔園旁， 要描述它，只能利用其他的參考座標。所以我請她紀錄，要先找到埔里鎮水頭路17號， 然後向山而行，過了約 50 公尺後，會先看到一個檳榔園，然後是爻白荀田，再過去的檳榔園， 就是目的地了。到那裡就會看到有樹壓到電線桿了。
我也不曉得那位小姐到底有沒有聽懂我的說明，接下來，她要我留下姓名及聯絡方式， 謝謝我的來電後便掛了。
除了這位小姐有沒有聽懂並忠實紀錄我作的描述，如果台電真當這是個事的話，那也會有個派工單， 可能是台電自己的員工，也可能是外包廠商， 那麼這些人看到派工單上的說明，腦袋裡是不是就像這張簡報一樣。
我不知道。但問問各位委員，一樣是跟客服小姐聽了我大致相同的描述， 那您們心中是不是也像這張簡報呢?
所以要解決這個地方型事務的問題，我們首先會面臨幾個難題:
- 說明它發生在那裡
- 解釋問題的程度
- 知道要找的對象是台灣電力公司
3¶
還好現在是 3G 吃到飽，即將進入 4G 的時代，大部份的人手機都有 GPS 及相機功能。 問題在那發生的，用 GPS 測定。問題的程度大小用圖來說明。
有圖就有真相。對施工單位而言，他們可以預先評估要用什麼設備，吊車、卡車、山貓，甚至是要派幾台、多少人力，可以有簡單的估算。
現在剩下的問題，就只有「要找什麼單位？」敝人是土木系出身的， 也常參與一些工務機關的研究案及工程資訊系統的建置，對於公共工程的權責單位劃分有比一般民眾多點認識， 像是以堤防來說，下游多屬河川局管理、中游由水保局管理、上游由林務局，但這也是該河川是屬於中央管河川才是如此劃分。 有些河川是屬於跨省市河川或是縣市管河川，那就分別歸屬於水利署或各縣市水利局管理。 分那麼細，有那些民眾是出了問題後，能立刻想到找誰負責。
所以現在各縣市多半都有 1999 專線，有問題不管大小、知不知道誰負責，反正就打免費電話過去，有專人為您處理。 只是這樣就又回幾年前的那個風雨過後的對話，講的人覺得清清楚楚，聽的人覺得模模糊糊，腦袋裡沒什麼畫面。
4¶
當時，我遇到了這個問題，是覺得問題不大，畢竟我人長那麼大了，也才遇到一次要通報台電。搞不好，這輩子，也就那麼一次。 所以並沒有太放在心上。
直到看到「花蓮市公所的市民報馬仔 APP 」新聞。才想到，我搞錯對象了，重點不是那些公共設施的使用者，是維護者， 他們本身就有這種需求。
這個市民報馬仔 APP 只是提供民眾利用瀏覽器選擇預定的問題類型，再利用 Google Maps 去標註地點。優點是不用打字，用點的， 而且是單純使用 WEB 平台作出來的，可以在 PC/MAC/Android/iOS 上面使用。
但缺點也是有的。它只有花蓮市公所轄區內的馬路相關問題可以用，外縣市或是河川、水電管路就不行了，這很合理。 這個 APP 是花蓮市公所的替代役作的，沒道理，他們花公所的錢去幫全台灣所有鄉鎮市公所服務，就算程式碼開放免費使用， 那也得有人架站，維護管理。
所以我們才提出這個計畫『解決資訊傳遞問題』、『方便跨單位的協作』。
5¶
(攤在陽光下的事，用陽光的方法解決)
我們要解決的問題一定是攤在陽光下的事，因為這樣才抓得到 GPS 。 陽光的方法指的是，各個相關人員在處理問題時，大家看到的資訊都是一樣的。 而且等待任務解決完畢後，承辦人可以選擇對社會大眾公開。
(把地方上有頭有臉的人拉進來)
原本一般民眾不懂得問題該找誰去解決時，現在多是利用 1999 專線。但其實最適當的人選應該是村里長， 及議員們，這本來就是他們的工作，我們希望這個系統是可以把現實中的關係線拉進平台裡，把我們平台變成政治版臉書。
(幫公務員省事，而不是不作事)
公務員分擔的公務，就跟我們國內受薪階級的貧富差距是一樣的，事情多的人，是非常多的。而沒事情的人也是有的。 希望我們平台可以讓這些事情多的公務員，在作事上，可以省點力氣。
(讓施工廠商有機會也露露臉)
很多公共設施的圍牆都會掛著一塊工程告示牌，上面說明了監造單位、營造廠商是誰，且最重要的是留下全民督工專線，歡迎民眾看到不法、不妥、不合理的事情可以通報。 這是給廠商抽鞭子的作法，那我們平台可以給胡蘿蔔的機會，廠商把他們的解決過程、施工相片拍下來，上傳到相關的任務， 這就是一個展示的機會，不然很多鋪馬路、修人行道、路燈之類的工作，作完了，作得好時，不曉得該去給誰拍拍手。
(不只解決問題，更注重協作的品質及效率)
我們平台不是只幫忙解決問題的，還希望各個利用人在處理問題時，可以用最少的力氣。 所以我們主要是把這個平台功能定位為跨單位的工程事務協作系統。
6¶
我們平台包含兩種程式，一個是 WEB ，架在 Amazon 上，跑在 Linux + Nginx + Django + PostgreSQL ， AP Server 是用 uWSGI 伺服器。
另一個則是 APP 程式，只出 Android 版的，因為我們沒有 ios 的人才。
7¶
不同角色會依權限看到不同的任務。
一般人可以看到的任務有兩種，一種是自己創建的，另一種是承辦人處理完畢後選擇公開的。
而其他村里長、村里幹事、議員除了這兩種外，還可以看到發生在自己轄區的任務。
而承辦人及施工廠商則是可以看到自己負責處理的任務。
那麼在搜尋之後，如果有包含到未公開的任務，則在列表時，在標題部份會以 未公開 顯示， 且無法觀看詳細資訊。
8¶
WEB 平台是用來協作及展示之用的。要創建任務，只能靠手機 APP ， 因為我們需要提報人貢獻兩種資訊一個是 GPS ，另一個是相片。 具備這兩者，我們才允許他能創建地方型的任務。
那麼在未來的系統發展目標中，我們是希望可以加入時間戳記伺服器，這樣一項任務在創建時， 有了 GPS 、絕對時間及它當時拍下的相片， 那麼問題被假造的機率就非常低了。這可以避免無聊人士耗費公共資源。
9¶
這是我們 APP 的螢幕截圖。要創建任務時，就按下「建立事件回報」。
10¶
接下來，就使用手機內建相機軟體來拍照，拍完後，可以選擇放棄，點左邊的Ｘ。點右邊則代表使用這張圖。 確定後，會再問您，要繼續拍照，提供佐證，或是直接儲存相片。
12¶
這張是在 APP 上看 WEB 平台的任務資訊，我們 WEB 使用 bootstrap 函式庫， 所以在不同解析度的螢幕上，會作適當的排版調整。
13¶
這是 WEB 版的介面。可以看到用幾張相片、 Google Maps 地點及簡短一句說明， 就能表達問題。
14¶
這是處理任務時，相關人員所看到的表單。
所在村里是我們系統管理員針對 GPS 計算錯誤時，可以修改用的。
承辦單位、類型是給村里長、村里幹事、議員用的。
任務負責人是給承辦單位的總管，像是文書組或是發言人、主任秘書等等，主要就是負責管理單位的陳情信箱的人。
而狀態部份，系統可依當下是什麼角色發派給其他角色時，自動選擇的，但也允許使用者自己調整。
最下方則是對這個任務的回覆意見。
15¶
1）
一開始任務創建完成後，系統會自動分配它是屬於那個村里，確定後，就會寄通知信給這個村里所相關的村里長、村里幹事及議員。
第一個處理的人是里幹事，他選擇承辦單位是中興大學土木系。我們系統會儘量輸入全國各地機關、單位、國營事業的資料， 如果遇到是還沒輸入的，也允許使用者自己打字填寫，事後再由我們管理員作正規化及聯絡信箱的補充。
所以選好承辦單位後，系統就能把任務寄送至該單位的聯絡信箱，收信的人可直接回覆意見或是點選信中連結來到我們網站回覆意見。 因為我們系統在不同任務上，是使用不同的發信地址去寄到各單位的聯絡信箱，所以他們直接回信的話， 我們是可以從收信地址來判斷他回覆的是屬於那一個任務。
這部份的技術，我們是搭配 Google App Engine 的收信服務，它在收到信，可以把收信地址、內文、附件用 HTTP 協定傳到我們網站。
仙人打鼓有時錯。所以有可能遇到里幹事給錯了承辦單位，這也沒有關係，在現實環境中，是用打電話或是去承辦單位直接反應的， 如果反應錯了單位，那也只是踢個足球而已呀！就換個單位提報就行了。
所以土木系的管理員就回了封信，說這不是他們業務，請另找林管處。
里幹事看到回信，就知道事主要換成林管處，一樣是複製貼上相同的意見，再改了承辦單位即可。系統就會再寄信給林管處。
林管處的管理員收到信後，確認這屬於他們工作，那他就會把信轉給單位內的承辦人，如果他們單位內有自己的一套工務管理系統， 也可以把這封信就貼入工務系統裡面去作管理。
所以有可能到了承辦人手上時，這個任務的在現實中處理的各項資訊就會與我們系統暫時剝離了， 因為承辦人不見得會把處理過程一五一十地鍵入我們系統。但是沒關係，只要他最後有把問題解決了， 他總必須回報當初的陳情者，回報內容不管是精采還是簡略，他就是得回報。只要承辦人一回報， 那就是寄信回我們任務專屬的收信信箱。這樣一來，任務資訊就又接回我們系統了。
如果承辦單位還不夠資訊化，沒有專用的工務管理系統，那他可以利用我們系統來當作他們的工務管理系統。
管理員接到工作後，可以在我們系統上，把任務轉給承辦人。
承辦人也可以把自己的處理過程、什麼時候外包、外包廠商的聯絡資訊，放到我們系統上。
17¶
這張是施工後的相片，對比開立任務時的相片，就可以知道到底施工廠商處理地好不好。
當然這種相片驗收方式，也只是一種簡單的。如果是複雜的工程，那還是需要廠商自行提供壓密試驗、平整度的報告， 這就非我們系統能作的。但我們系統可以協助儲存這些實驗報告，作承辦單位、廠商的雲端硬碟。
我們系統的附件儲存位置用的是 Amazon S3 服務。
18¶
不同的角色，在我們系統上的註冊方式有些許的不一樣。以村里長、村里幹事、議員來說， 只要選對服務區域另外再填上姓名、 email 及密碼，就能開立帳號。
當然這可能會發生有人冒用他人身份，遇到此類糾紛時，我們就會要求該帳號需作實名驗證， 目前來說，就是以銀行帳戶為基準，誰拿得出來，那這帳號就歸誰。
承辦人部份則是要求他提供所屬單位的信箱，我們以信箱為憑據。
施工人員則是以公司統編為準，因為一項任務在分派到施工廠商時，是以統編為準的。
19¶
我們系統會使用到的特殊技術有三
EmailProxy 是方便任務的參與者不需要登入我們網站，可以在信箱中收到信，回覆即可。 事實上，這種工作方式，也正是目前大多數人工作的方式，不停地 CC 來 CC 去。 所以我們讓每一個任務具備自己獨一無二的收信地址後，用那個收信地址去寄信給地方人士、承辦單位、施工廠商， 在他們回信後，我們系統都可以清楚判斷他們處理的究竟是那一個任務。
EmailProxy 技術是利用 GAE 的服務來實作，它除了能把 SMTP 協定轉 HTTP 外，也有很高的負載平衡能力，收信的量再大，也不會倒站。
GPS Mapping 則是利用 PostgreSQL 的 PostGIS 函式庫來計算一個點會落在那些區域之中。 這樣我們才能把任務的 GPS 點位拿來對應至所在村里。這部份的 Open Data 則是匯入了全國村里界圖（台澎金馬）-經緯度資料。
而時間戳記伺服器，則還在研發中，大致上的運作原理，就是 APP 內建一把私錀，在創建任務時，用私錀先簽章，簽完的驗證碼， 先丟到我們的時間戳記伺服器中，由時間戳記伺服器拿自己的私錀對這個驗證碼及自己系統上的時間，再作一次簽章，傳回 APP 後， APP 把時間戳記伺服器的簽章附在創建任務的相片之中，這樣我們就能確定相片產生的時間是與時間戳記伺服器的時間是同步的。
20¶
村里長及各級地方民意代表)
提供現任民意代表及未來參選人在平台上建置個人專頁，內容主要整理自實際任務管理的歷程。
也提供不同等級的付費服務，供消費者與潛在選民互動，例: 某些任務在承辦人員經手處理後， 選擇「不公開」給一般大眾查詢閱覽，而這些「不公開」的任務在系統的權限架構下， 還是可以給任務發生轄區的村里長、各級民意代表閱覽，所以消費者可以決定分享給自己選區的特定民眾閱讀。
這模式就像現實世界中，參選人快到選舉日前，大量印製個人過去的喉舌表現文宣，並發送給選區民眾， 本服務僅是將此行為數位化、社群化。
施工廠商)
每個參與任務施工的廠商，都可能有額外的營業項目，非僅單單面對泛公部門。路面修補、堤防修築、 電線整修…這些業務多是由土木包工業、水電工程行處理，現行的施工模式也是多以開口合約議定， 廠商也是跨業經營，在特定時點，處理泛公部門的業務，在平常時段接私部門訂單。
本系統提供廠商的施工實績頁面宣傳他們的施工技術，也可以在其他已公開且類型相似的任務中， 放置廠商的橫幅廣告增大曝光率。
在其他「不公開」的任務中，施工廠商也可單獨分享給特定用戶閱讀任務，藉此證明自己的施工績效。
所有人(泛公部門、施工廠商、其他…)
本團隊過去的軟體開發工作也多是圍繞在工程事務的資訊管理系統上， 未來一樣會遵行此一客製化開發的營運項目。 本平台在營運地方型事務的協作功能下，可證明本公司對此類技術的實作及維護能力。
21¶
時間戳記服務 在電子簽章可能盛行的未來，時間戳記極其重要，但放眼臺灣，似乎沒什麼便利、 便宜的服務可以使用。本系統有意利用此一機會，趁勢培養自身的時間戳記服務能力。 時間戳記服務可運用的軟性市場(非正式的電子簽章):
- 繳交作業的完成時間證明
- 網路文章發佈時間證明
- 網路拍賣喊價證明
- 網路抽獎證明
這些服務的特性都是嚴格講起來不太重要，真正有糾紛也不會上法院打官司， 先要花真金白銀去建置電子簽章實有大動牛刀之笑。 本平台希望未來能有機會踏入這方面的業務。
22¶
最後這是我們使用的 Open Data 資料集。謝謝各位委員的聆聽，我的簡報到此結束，謝謝。