專案流程工具－Asana 導入思路
紀錄在產品經理職位上，曾做過的事情，還有怎麼分階段的達成任務及分享。
前言
踏入職場以來，其實最需要的就是專案管理的思維，因為在職位上如何管理自己的知識庫、常用文件等，是可以大幅提升自己在工作上的效率。而我認為管理方式並沒有好或壞，只有自己順手與否及是否符合公司職場所需。
痛點
- 不同部門使用 Asana 工具流程不一，無法將工具應用最大化。
- 產品需求零散，無法有效管理。
- 導入工具但沒有對應的管理架構，因此造成討論內容、開發規格零散。
- SaaS 服務無整合，需要使用人工方式通知。
主要解決的問題
- 現有資源下，如何把專案管理工具應用最大化？
- 不同部門專案管理工具的使用不一，如何確保產品需求、開發進度能夠同步掌握？
思路
盤點資源，確保應用最大化
確保免費與付費差別，區分功能的優先重要性
雖然有時候課金玩家可以解決很多事，但站在經營者的角度卻會考量的是工具是否可以創造更大的價值，又或者是降低了甚麼成本，須要有具體的成效。
因此，了解使用者的需求痛點就相對重要！
確認經營者的工具認知，需要先了解這個問題重視程度，因為重視程度也會影響到提案的困難度，確保提案能夠順利。
盤點公司現有使用的服務，是否有可以串聯的可能性，主要是要確保不管免費或付費工具時，此工具在工作的整合是否能更加全面，不然會很像貼狗皮膏藥一樣，只為了解決單一需求所研究，更會增加日後若需要變動成本。
需求痛點，挖掘問題本質
- PDM
- 方便管理產品需求
- 可自動通知
- 了解開發進度
- 工程
- 管控開發進度
- 規格確認及討論
- 其他部門
- 完成通知
- 公告
在產品開發及需求管理的流程，先透過免費版觀察了一至兩週同事如何使用 Asana，像是企劃就有提到「像是記事本一樣」，也就是說對他們來講此工具是可有可無，對於產品需求及開發，他們僅須要了解需求確認、終端狀況；而對於工程人員來說 Asana 就像是工單一樣，要在這個 task 上能夠獲得最大的資訊，並且能夠與 PDM、技術主管用最小成本進行溝通；而對我而言，在產品的需求、開發的整合更為重要，講求效率下我認為在自動化、統一管理更為重要。
解決步驟
- 現有資源
- 可多開不同專案，讓不同專案可客製，例如：使用者回饋跟產品功能需求就有不大一樣的 Borad、status、workflow。
- 重度使用的成員為 PDM 及 IT team，因此已經縮減使用者人頭計費成本。
- 零散的功能及需求有部分已經存於 Asana，不管專案開設也便於轉移。
- 已有特定開發模式，可確保付費或免費時具有目標。
- 盤點免費版缺少的功能
自訂義欄位：因為專案不同所需的欄位不動，且預設欄位也能降低查看 task 的成本。
專案表單：這是超級關鍵，因為 Asana 有具備表單的功能，不管是需求或是回饋都可以透過表單直接填答，也不會有權限問題，快速的解決使用者換位需求不同的問題。
但當然，決議使用這個功能前，我有使用 Zapier + google sheet + google form 進行測試，但 Asana 已有多年的紀錄 + 轉換會有非常大的陣痛期及成本，因此棄用此方法。
連接應用程式：因為公司主要使用 slack 在溝通，所以能夠串上 Slack 即時通知會非常方便，還有就是 slack 當時是使用免費版也會有溝通訊息遺失的問題，透過 Asana 訊息溝通可以確保訊息留存也能快速連結到 task，會非常方便！
接著我就開始設計 workflow 還有 Form，並且提案先以「試用 30 天」開始確保接下來的設計是否有方便性並且能解決到上述的問題。
圖片來源：Asana
拆成四種不同的專案，工程開發、產品需求、錯誤追蹤、使用者回饋，基於這四種專案設計不同的表單格式，確保在表單內就能夠有足夠的資訊可以讓我（PDM）快速釐清問題。
在表單設計面有幾大重點：
填答者能夠先第一層判斷輕重緩急，而我針對高優先、中優先，都留下的敘述區塊，就是確保在這一層能夠先思考是否為優先，這樣才有參考價值。
客製化表單，像是錯誤追蹤就必須要盡可能知道載具、瀏覽器等等，所以可以直接能夠選擇的答案，也能確保資訊架構一致。
workflow 吻合評估，主要是設計後的表單是否能夠完整的進入 Asana 並且成立為 task，而 task 是否具備明確的資訊可以查看。
Workflow 重點：
- 確保流程單一，不要為了自動化而疏忽可能存在的例外。
- 連結 slack 多方測試，確保資訊一致。
- 降低人工成本及不必要的溝通成本。
自訂欄位確保可使用性：
像是自訂欄位中依照狀態的不同可以讓人快速了解狀況，可能是進度的處理中、待處理、已完成等等，但這些都必須要慢慢修正及依照使用者需求進行的，沒有通規。
圖片來源：Asana
因為有了試用所以在這期間也能收集不同的使用者回饋，並且分析為甚麼需要付費？大家使用上對於此設計是否升級有感？因此再向上提案，讓提案可以被採納。
方案比價，屆時如果真的需要付費，應該要怎麼付費？要付多少人頭等等。
教育訓練，逐一確保協作共識
有了表單、自訂欄位及 workflow 後，就趕緊利用試用的期間將大家的習慣、回饋迅速蒐集，且每次的討論、改動甚至是決議都要明確的記錄下來，且以此工具利用最大化為目標，為了就是讓經營者可以有「回本」感覺。
而在這樣的過程我還特別做的一件事情就是比價，也延伸前一段所述每個人都期望自己付出的成本可以等價甚至是有賺到的感覺，並且在這短短的 30 天內逐一培養大家使用 Asana 的默契。
例如：
- 先讓大家適應表單，而不是過去那種用口頭敘述就成立的 task。
- 確保表單資訊清楚，也就不會有 task 模板在那，但沒人遵照。
完成以上後，再進行下一步的計畫，培養大家串聯 slack 看通知的習慣，因為之前其他部門有提到，信件一堆通知一堆，工作只看 slack，所以先培養了填寫表單，再來就是耐心提醒要串接 slack ，確保通知不會漏掉，也成功降低了人工成本。
結論
在導入工具或是辦法規章時，最害怕的就是反抗及自己做自己爽，所以事前的觀察及利害關係人評估相當重要，就為了確保自己的研究能有價產出。
而產出的結果也是不斷迭代的過程，能夠與時俱進，也必須要透過先前提到的教育訓練、階段性培養來慢慢達成。