一款好的項目管理工具，是產品研發進度把控、團隊協作的賢內助。用好了，將達到事半功倍的效果；用不好，不但無法提高效率、帶來幫助，反而成為工作中的負擔。當我們使用項目管理工具時，應該注意的點有哪些？文章為你解讀。

1.找到合適的工具

項目管理的作用對象是團隊，因此，好的項目管理工具應該達到團隊成員人人受益、提高每個成員工作效率的效果：

• 對領導，可掌控項目的整體情況：可查看匯總信息，包括但不限于項目進度匯總；每個成員的任務情況、項目任務清單匯總；項目迭代路線（版本路線）；項目文檔備案匯總等。
• 對員工，可掌控自己的具體工作：可查看自己的工作清單；可直觀地查看自己當前的任務量；可將任務流轉到下一位負責人。
• 對團隊，可掌控項目的迭代進度：可查看項目的迭代進度；遇到問題時，可通過追溯發現根源；可查看任務的流轉情況、項目文檔的歷史版本、項目的迭代情況等。

2.清晰的任務流轉流程

清晰的任務管理流程幫助團隊成員掌握自己工作的步伐，保證大家理解一致。也確保 迭代過程的監控和后期的追溯。

不同的任務類型，流轉的流程不盡相同：

以開發任務為例，經歷的流程路徑詳解如下：

有了標準的任務新建、流轉流程，項目工作被分解為具體的任務，且指向到特定的人。每個人完成手上的任務后，很明確地指派給下一位負責人，提高大家對自己工作的管控力。也確保了每個任務有始有終，有清晰的軌跡，方便了項目的整體監管。

3.粗細適宜的任務粒度

開發、測試、運維、文檔、設計5類型任務幾乎涵蓋了一個項目中所有的細節工作，此時，很容易出現因任務粒度過細導致的龐大任務量。當每個人手上的任務量達到一定的臨界值時，不僅無法幫助大家管控工作，反而因信息過載造成極大的困擾，人們不得不花費大量的時間精力查看處理這些任務，而無法將注意力集中在完成任務本身上。

因此，粗細適宜的粒度是建任務的關鍵。一般應遵循的規則如下：

• 以一次迭代為單位新建開發任務：在任務的描述中敘述此次迭代的story point；以附件的形式補充PRD等需求文件

• 一個迭代任務下有若干個子開發任務、運維任務：新建的迭代任務，以功能為單位被拆解成多個開發子任務，方便分配給具體的研發人員；針對某此迭代的運維任務掛在對應的迭代任務下：

• 某個功能的bug掛在對應的開發任務下：測試bug作為開發任務的子任務，方便看到某個人負責的某個功能出bug的情況，也方便迅速定位bug集中的功能所在：

• 以類型為單位新建測試bug：若每個小問題被簡稱一個測試bug，則會出現bug泛濫成災的場面，為此，應將bug按類型歸類，同一類的提一個匯總bug即可。如文字錯誤類、樣式不符類。

4.定期的項目例會評審

明晰的規則不能成為空頭條例，重在執行過程中的堅守。因每個人工作的習慣根深蒂固，常常忘記按照規則實施，為此，定期（一般兩周一次）召開項目例會，在例會上對著任務單進行評審顯得非常必要。例會的主要議程有：

• 項目進度情況評審：對照當前版本的進度計劃表，評審每項任務完成的情況。這個過程很容易發現項目進度存在的風險，有利于提前采取措施預防風險。
• 團隊每個成員的任務清單評審：通過評審每個人手上的任務清單，可以發現工作分配是否均衡；其次在評審的過程中，找出沒有按規則新建和流轉的冗余任務單子，并進行合并、關閉等處理。通過清理冗余的任務，防止因工具而影響團隊效率。通過會上討論的方式，對大家遵守規則做到了很好的提醒（應注意，評審時發現不符合規則，應只需指出哪里不符合并改正，而不是怪罪于當事人）。

5.隨時監控任務清單

項目管理者應隨時關注工具的使用情況，發現問題及時指出。主要應關注的點或許有：

• 一周內沒有更新的任務：一個任務若一周內都沒有更新，有兩種情況：當事人忘記處理；任務粒度太大。此時應及時提出，查找問題所在并解決，防止某個問題被遺漏出來，或工作分配不合理。
• 測試bug清單數量：項目管理工具中，占比最大的任務單當屬測試bug。為防止任務粒度太細給大家造成困擾，應及時關注測試bug清單，及時合并極細小的bug。

短期的實時監控和項目例會結合，有效地掌控項目狀態的同時，促使團隊更好地使用工具。

誠然，市面上有花樣繁多的項目管理工具可供選擇，每個工具各有其優勢。不論使用何種工具，合理地使用，并使其提高團隊的工作效率，是第一要義，而不應為了使用工具而使用工具，反而使其成為團隊工作的負擔。

本文由 @小麻雀 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議