前言：專案管理工具的抉擇

其實 Jira、Notion 是更好的專案管理工具(個人使用後的觀感)，但因為許多公司都有購買 Office 365 來使用 office、excel… 等工具，所以如果專案管理也能用 Office 365 來解決不但能節省一筆經費，更可以讓團隊把注意力集中操作同一個軟體，而不是做一件事都需要更換一個軟體。

Office 365 裡比較適合拿來做專案管理的有 Microsoft Planner 、 Microsoft Lists 這兩個，如果有興趣了解兩者的不同可以參考這篇文章，但經過考量後 Microsoft Lists 更為適合多個單位之間的合作，下面會詳細介紹我是如何使用的。

一、建立符合專案管理需求的 Lists

SETP 1: 建立空白清單

SETP 2 : 依照需求新增欄位

➤ 下面說明每個欄位的作用，可依自己的需求再做調整：

1. 任務名稱：簡單明瞭讓被指派的人員初步了解任務
2. 描述：詳細說明任務內容，如果有子任務建議使用條列式呈現
3. 進度：顯示該任務完成進度，此欄位會因為任務類型的不同而有不同的文字呈現
4. 優先度：分成 緊急>普通>不重要 3 種
5. 負責人員：PM 指派的任務對象，此欄位可選擇群組或是由多個人負責
6. 相關人員：除了負責人員外，需要追蹤該任務的人員，就像是信件的副本概念
7. 負責 PM：通常就是建立該任務的 PM 本人
8. 任務類型：分成 文件、設計、程式、測試 4種，方便透過此欄過濾出想要的資訊
9. 相關連結：可能是要測試的網址、給設計的參考範本、完成的文件連結…
10. 開始日期：被指派的人員開始作業時的時間
11. 到期日：完成該任務的時間

二、模擬專案實際情境

需求：今天有一個網站需要新增一個商品清單頁面，並且在這個頁面可以對商品進行新增、修改、刪除、查詢的動作

前期

指派設計完成 wireframe，同時 PM 分析這個頁面的細部需求規格

中期

在設計的 wireframe 與 PM 的需求規格完成後，後端工程師可以依據需求規格開始撰寫 api ，前端工程師也能依照 wireframe 先完成畫面等 api 完成後串接

後期

在前端工程師依照 wireframe 完成 UI 並串接好後端 api 後就可以請測試部門做功能上的確認，測試的功能項會建議由工程師做簡易的文件撰寫。

測試後依據測試結果將進度轉為 測試成功、測試失敗 ，如果測試失敗要說明原因並重新指派給當初負責的人員處理。

三、操作上的小訣竅

善用篩選功能找出需要的資訊

因為列表上的資訊非常多，所以我們可以依據實際的情境來做調整：

1. 將 優先度度為緊急 的篩選出來確認進度
2. 測試人員只需要瀏覽 任務類型為測試 的就好
3. 可以 用關鍵字搜尋任務名稱

使用交談功能討論任務進度

使用過本產品的人我想最大的詬病之一就是文字圖片無法複製貼上，目前看到可以複製貼上的區域只有 任務裡面的交談，如果你們有很多詳細的內容是寫在交談裡面的請記得在描述中說一下，不然大家都不知道交談裡面有更多內容。

結語：讓工具連結發揮更大功用

如果只操作 Lists 你會感覺到有些部分綁手綁腳的，但 Office 365 的工具我想當初設計的想法就是要使用者把裡面的工具互相串聯吧？所以每項工具只做出基礎的功能，如果要更深入的功能需要再與其他工具結合：

1. 如果你要 subtask 的功能要與 Microsoft Planner 結合
2. 想要撰寫更詳細的文件內容就直接超連結到 Microsoft Office

他不是一款完美的工具，但使用者可以透過其他方法讓他更好用。

Microsoft Planner

任務呈現方式：

• 清單

• 面板

• 圖表

• 排程

新增任務：

使用特點：

• UI非常直覺，基本上不用讀說明書都能輕易上手
• 可以依據不同的情境讓使用者決定任務的呈現方式
• 發布及指派任務速度快
• 因較著重於工作事項，適合在小型專案、短期計畫中使用
• 篩選的功能很方便，但是用關鍵字搜尋只能找到標題那層

缺點：

• 子任務 只能用 檢查清單 的方式來呈現，缺乏subtask的概念，這樣有關聯的事件無法一起呈現
• 因為是以任務為導向，這樣在日後發生爭議時很難找到過去討論的歷史

Microsoft Lists

建立清單

項目列表

新增項目

使用特點：

• 偏向主管對於專案的全局掌控，因為每個項目中無法填寫太多資訊
• 適合多個 Team 共同合作時使用，每個項目皆有客製化選項
• 建立清單時提供多個範本可以快速對應不同的情境
• 在篩選功能的設計也是偏向管理者的

缺點：

• 通常專案管理系統會依據使用者想要顯示的內容（狀態/優先度/被指派人員/sprint等），去變化他的介面形式，但 Lists 的顯示方式只能是很陽春的表格，只能照使用者想要的內容排序。
• 單一項目裡面，可能會夾雜更多的待辦事項，但 Lists 的設計是一件事件裡面不能再塞其他 To-do 事項。
• 單一項目裡面，可能會跟多方討論，Lists 有個對話框(conversation) 功能可以解決此問題，但該對話框功能在項目中並不會顯示，所以查看該事件時可能會完全忽略對話框的資訊（Jira留言板功能比較好）。

結論

從使用角度而言

兩個工具可以各自應用在不同的情境中，Lists 勝在有 Microsoft 365 的整合，否則功能過於陽春，可能不比市面上 Jira、 Notion 等專案管理系統。但若公司的專案管理的不是那麼的複雜，Lists 完全是可以勝任的。

考慮到 Lists 偏向大方向的項目，而 Planner 是細節任務的規劃，也許我們可以將兩者做一個結合，比如 Lists 裡面建立一個項目是 網頁UI設計 ，而這個 網頁UI設計 會關聯到自己的 planner ，這樣在 planner 裡面就能做細節工作的劃分

兩個工具的共同缺點

• 當事件數量一多，使用者通常會想搜尋、或依據自動編號方便溝通，但這兩者都沒有內建。（ jira 在新增任務時會自動產生該計畫的編號）
• 管理人員、權限問題。任何人都可以刪除整個工具或任何事件，而且也看不出來是 誰 或 何時 建立該工具或該事件。
• 如果要附上圖片、文件都需要單獨上傳，如果是用來 bug 追蹤會是極其不便的(無法圖文並茂)，除非每個 bug 追蹤都要額外附上一個 word 連結來詳細描述

工具綜合比較：