檔案所帶來的痛苦

前一篇講到了我們希望軟體開發專案中，所有的利害關係人所提出的看法都應該要完整的被紀錄下來，然後以Issue的形式被保留在平台中。

我們把畫面往回轉一下，如果在還沒有平台可以被保留的狀況下，我們會如何紀錄一場會議？然後如何把會議紀錄發送給所有的利害關係人？如何處理回饋，然後通知給所有利害關係人？

傳統的作法大多都是email，流程大概如下：

• 做好會議記錄word檔案，擬好一份email
• 發送給所有利害關係人，告知如有問題請回覆
• 利害關係人提出需修改之需求，告知需修改

以上三個步驟就不斷迴圈，直到大家都滿意為止。

其實在過去，我們常常遇到email滿天飛的狀況，如果是像Gmail那樣的Saas服務，搜尋功能強大還可以靠著標題歸類或是Tag分類，去找到過去可能的溝通過程。但我待過兩間企業都使用地端的outlook，搜尋功能就沒有那麼強大，而且最大的問題不在信件內容，而是附加檔案。

會議記錄用word檔案寫成，這對知識的檢索造成非常大的困擾。因為word檔案並不是txt文本，他有他自己的格式，要直接透過windows做word檔案內容檢索，幾乎不可行。

公司有提供sharepoint讓大家把檔案往上放，作為分享與檔案版本控管的一個集中處。但根據資安的理由沒有開放share folder的形式，只能一個個檔案透過網站介面往上丟....十分痛苦。

身處於一個巨大的組織中，會議根本就多到天上去，筆者並不是一個很好的檔案管理者，所以每次找東西都會花費上很多的時間，到後面就會逐漸沒有耐心。

而且，會議記錄有時候所寫的內容，並沒有辦法直接與軟體專案當時所下的決定是根據哪些討論內容、確認的設計方式，開發指派、進度追蹤、過版的記錄等都沒有辦法一目瞭然，所以過去其實是處於一個混沌的時代，找的到是實力，找不到是天意。

Wiki的原則

回到現在，雖然我們推行wiki還不到三個月，但我們會有一些原則在上面：

• 跟專案有關係，而且會讓你卡關20分鐘以上的事情，就應該放上去，不論是技術類或是非技術類。
• 除非跟現實世界的表單有關係，不然盡可能不要放檔案上去，因為搜尋會有問題。
• 請不要放機敏資料上去，如資料庫連線字串以及帳號密碼，如果不小心放上去，除了刪除以外，請去真實世界把那組密碼變更。

Wiki常用場景

• 會議記錄，我們目前在專案會議中，將相關的會議記錄作為知識保留，且藉由下面的comment 來進行該篇會議記錄的討論。
• 專案管理討論頁，我們會把所有的Issue製作成一個Query，然後專門成立一QA頁面，在每次專案進行一開始，就進行各Issue的狀態追蹤。
• 系統架構與資訊，我們會將使用者可以驗證的測試環境連結，主機IP以及相關節點如AD或資料庫等資訊登載在上面，以便主要經辦休假時，代理人可較容易找到相關資訊。
• 更板或佈署資訊，我們會將該系統需要更板的步驟做成文件，以供Pipeline人員參考後，建立相關自動化Pipeline。
• 新的架構或流程設計，筆者常常需要去思考可能要做的新的流程，那通常會透過wiki先做出一頁完整資訊來，再來進行討論。
• 各式專案或系統文件，這是目前已經在進行中的部分，我們期望未來相關專案皆不產出word檔案，都以wiki的形式進行交付。

講點Wiki 我認為很棒的地方

首先是可搜尋，相較email+word檔案的方式，只要你是專案成員，就可以對workitem、code以及wiki進行全面性的搜尋，這是一般檔案系統無法比擬的。況且，wiki是以markdown語法進行撰寫，支援mermaid語法，所以可以針對一些基礎的圖，例如流程圖，就可以在上面直接編寫。未來下一個維護者不會只拿到一份jpg或是png，但卻需要修改時而傷透腦筋了。

再來就是高度關聯性，由於知識本身的建立，與工作是互相關聯的，因此可以輕而易舉在wiki中建立工作項目或是issue。如同前日所述，Issue代表著是有任何問題都可以提出，因此如果wiki的資訊有難以理解的，除了可以在下方留言詢問外，品質把關者更可以提出質疑請作者重新敘明，甚至指派工作要求更新文件。

最後就是可追溯性，由於Azure DevOps 中的Wiki，是採取markdown的形式，然後用git repo的方式儲存在平台中，所有被改過的內容，都可以找到修改的軌跡，凡走過必留下痕跡這件事情有優缺點，當時內部引起廣泛的討論，分成了是否該高度管制的兩個論點：

• 應高度管制：嚴格限制單位內僅被授權的人可查詢相關資訊，理由是萬一不小心有人放了機敏資訊進去，可以確保損失程度最低。
• 應自由開放：秉持著不分享知識會造成組織內嚴重的穀倉效應，這樣就以資訊單位來說就好，會有多少知識都無法共享，造成效率低落。

上述兩個論點其實至今沒有明確的結論，但筆者認為，一個工具不該限制最基本的自由創作權利，資訊單位應該是一個藉由共同進步謀取最高組織商業價值為目標，不能因可能存在的風險而全面禁止。

軟體開發畢竟是工程學，知識的分享與管理是進步的必然，不該因噎廢食，這是我們這些第一線開發人員的心聲。