以開源軟體而言 Zentao 是相當優秀的專案管理工具，但如果沒有一些基礎教學導引，裡面的功能真的多到你眼花撩亂不知從何下手，如果你有這種困擾，或是想再導入這個軟體前對他有更深一步的了解；我相信這篇文章能給你帶來很大的幫助，讓你了解重要角色的權限劃分及專案流程。
一、官方的『新手教程』
二、了解每個角色的職權
1.『管理員』的基本功
➤ 調整部門結構
➤ 批量增加用戶
➤ 調整用戶權限
➤ 還原刪除的使用者
➤ 解鎖多次登入失敗的使用者
➤ 發現的系統 Bug
2.『產品經理』的起手式
3.『項目經理』如何分配任務
4.『研發人員』完成收到的任務
5.『測試人員』確認每個環節的穩定性
三、體驗心得一、官方的『新手教程』
這個新手教學並沒有依照角色權限設計，所以每個人看到的版本都是以『管理者』的角度去呈現
官方提供的教學可以讓你快速了解整個系統的作業流程，你在『教學裡面的所有操作並不會儲存』只是給你體驗而已，所以意思意思打一下就好。
教程面板說明：
- A：會有亮起來的地方讓你選擇及輸入資訊，這塊跟著走，資訊亂填即可(不會存進系統)
- B：教學的操作步驟
- C：以管理員導向的八個任務讓你體驗，接下來我的文章會更細節說明每個角色實際能操作的範疇
二、了解每個角色的職權
其實在首頁的地方就已經把每個角色的職權都說得清清楚楚了，如果發現有角色的職權跟你預計的不符合也可以再自行客製化
1. 『管理員』的基本功
管理員需要對所有職位的權限非常熟悉，並要了解每個權限具體對應到哪些功能
➤ 調整部門結構
必須要先設定好部門的結構再去新增用戶，因為用戶跟部門是有相互依賴關係的
➤ 批量增加用戶
建議用『批量』的方式建立用戶，無論在權限、密碼方面的設定都會輕鬆許多
批量新增時技巧：
- 職位高的先放：因為通常他們會是所屬部門的根目錄
- 善用『同上』的功能：相同的部門、相同職位…依照同類型的分類設定可以加快速度
➤ 調整用戶權限
在批量新增使用者的時候一個用戶只能有一個角色權限，但有能力的人在公司裡面身兼多職是常有的情形，就像我在公司是『研發 Dev』人員，但同時也需要負責『系統組織、後台設定 Admin』，所以我會給自己設定多種角色權限
如果公司規模不大，一個團隊的 leader 要身兼 『項目經理 PM』、『產品經理 PO』、『研發主管 Dev Manager』、『產品主管 PD』都是很常見的（ex：我現在的直屬主管）
➤ 還原刪除的使用者
➤ 解鎖多次登入失敗的使用者
為了避免帳號被暴力破解法盜取，禪道有登入錯誤次數的設定
➤ 發現的系統 Bug
這裡特別說明一下，禪道這個專案管理系統在權限管理、用戶管理上面的防呆不是很嚴謹，下面舉兩個範例：
- 『管理者』移除自己『管理者』的身份後還能繼續使用管理者的權限😨，需要再次登入才會生效😱（如果由其他管理者移除對方管理者身份時一樣要重新登入才會讓身份生效）
- 『管理者』可以移除自己的帳號😨，帳號移除後還能繼續操作系統😱
2. 『產品經理』的起手式
產品經理需要專注在每個產品的週期，並確認所有需求都有在進行
STEP 1：創建產品
STEP 2：維護模組
這裡的模組會用來區分『需求』的類別
STEP 3：創建計畫
每個『需求』都會隸屬於某個『計畫』
STEP 4：創建需求
『需求』就會依照剛剛創建的『模組』、『計畫』做設定
STEP 5：需求指派
需求要指派給相關的人員才能夠推動專案的進行，這裡指派讓項目經理做後續處理。
『項目經理』預設權限並不能對產品需求進行操作，即時被指派也不行；所以如果要讓他提供相關的資訊請前往：權限 > 需求> 編輯、變更需求、指派需求(打勾)
3. 『項目經理』如何分配任務
項目經裡是具體分配任務的人，他需要了解團隊中每個人的職位才能有效地指派任務
STEP 1：登入後看被指派的需求
STEP 2：創建項目
創建完項目後系統會有彈窗詢問你要不要進行後續的操作，如果選擇『返回任務列表』也還是可以做這些設定
STEP 3：管理團隊
如果沒有設定好參與項目的團隊成員，創建任務時只能指派給自己喔XD
STEP 4：創建任務
項目經理需要將創建任務並指派給相關研發人員
項目經理可以透過『燃盡圖』來觀察每個項目的實作狀況是否符合預期，這裡要特別注意的是『燃盡圖只能計算今天的數據，歷史紀錄無法修改』，所以要記得提醒組員每天更新自己的工作狀況，否則燃盡圖是無法正確顯示的。
4. 『研發人員』完成收到的任務
研發人員主要會收到來自『項目經理』的任務、『測試人員』的bug，他的工作就是每完成到一個進度做回報，方便管理人員掌握進度
STEP 1：登入後看被指派的任務和Bug
STEP 2：更新任務的資訊
- A：任務開始
- B：任務完成，使用此功能時會將任務重新指派給當時委任的『項目經理』
- C：觀看、撰寫任務工時
- D：編輯任務內容
- E：創建子任務
STEP 3：將收到的 Bug 轉成任務
『Bug』跟『任務』不同，Bug 不會紀錄完成的時間，也不會把它算進去燃盡圖中，所以如果想將 Bug 轉為自己的績效，記得先將他轉型
- 項目 > 任務 > 導入 > 導入Bug
- 勾選欲導入的 bug 並填入預計工時> 導入
此時你就會看到『 Bug 被轉型成任務嚕』～為自己爭取更多績效吧！
如果改變剛剛轉型任務的『狀態』為『已完成』會詢問是否要將關聯的 Bug 一併改為『已完成』
5. 『測試人員』確認每個環節的穩定性
測試人員需要先了解產品具體的操作方式以及每個項目的測試點，不然他是很難撰寫用例的
STEP 1：創建用例
『用例』：測試的流程撰寫
用例建議一個一個創建，因為很多細節需要填寫，以下純為流程解說
STEP 2：了解用例的使用方式
- A：觀察用例過去所有執行的結果
- B：執行用例，確認每個步驟符合預期，如果執行中發現錯誤就可以轉Bug
- C：編輯用例，調整前置條件、執行步驟、備註等等
- D：如果用例測試的結果為『失敗』，也可以在這個地方做轉 Bug 的步驟
- E：複製用例
STEP 3：測試錯誤轉 Bug
這裡我們可以發現如果結果不是『通過』，Bug 的 icon 就會亮起來
點擊『轉Bug』後就去詳細的說明這個 Bug 的內容，撰寫的越詳細越能提升工程師解決的速度
STEP 3：生成測試單檢驗成果
『用例』、『Bug』都是單項的，測試單能把這些資訊做一個彙整
藉由『測試單』還能將過去的用例導出數據
想要生成報表也沒有問題
PS.當時我在報告的這個 Tab 用了好久都不知道怎麼操作，後來發現是測試人員 (QA) 預設的權限沒有打開，創建報告的功能要測試主管(QD) 才有權限
三、體驗心得
➤ 系統操作面
這款專案軟體的操作引導是非常棒的，加上官方的中文社群非常活躍，所以如果操作上遇到問題往往 google 一下就能得到解答。
➤ 一些小缺點
因為使用者權限劃分得非常細，所以有些操作會發現沒辦法下一步；又因為功能實在太過繁雜所以使用起來會有一點學習曲線。
➤ 與其他專案管理系統的比較
- Jira：認真說 Jira 還是稍微好用一點，特別是在系統彈性以及流程規劃上面；當然這可能因為我現在用的是開源版本所造成的。
- Redmine：Redmine 需要自己安裝一大堆 plugins 才能成為一套好用的系統，單純這點禪道真的是大勝，但學習曲線 Redmine 相對比較低。
- Teams 的 Planner & Lists：基本上這兩個是幾乎無法拿來做專案管理，會非常的綁手綁腳，不建議嘗試。
▶︎ 如果這篇文章有幫助到你1. 可以點擊下方「Follow」來追蹤我～
2. 可以對文章拍手讓我知道 👏🏻你們的追蹤與鼓勵是我繼續寫作的動力 🙏🏼▶︎ 如果你對工程師的職涯感到迷茫1. 也許我在iT邦幫忙發表的系列文可以給你不一樣的觀點 💡
2. 也歡迎您到書局選購支持，透過豐富的案例來重新檢視自己的職涯
