許多項目經(jīng)理在使用項目管理工具的時候都有一個誤區(qū)，那就是把工具僅僅當(dāng)成了匯報工作的一種途徑。他們要求程序員在工具平臺上面記錄任務(wù)以及花費的時間，至于任務(wù)的具體內(nèi)容或是任務(wù)途中的各種障礙，他們并不關(guān)心。如果你的項目管理工具是這樣被使用的，那就大錯特錯了。而這樣被要求的程序員，通常也只會按照既定的要求或者朝著績效更好的方向，去填寫工作耗時。這樣的記錄，又有多大的意義？
項目管理工具，現(xiàn)在更多地被稱作團隊協(xié)作工具?，F(xiàn)在的工具的設(shè)計不僅僅是為了高層的管理，更多的是注重在提高團隊合作的效率上面。
諸如Jira, Teambition, Trello， Worktile之類的工具，都提供了是十分豐富的功能，但怎樣去利用它們達到高效呢？
自我管理
既然是團隊協(xié)作工具，意思即是工具是針對團隊里的任何人的，而不是僅僅是管理者使用的工具。如果僅僅用于匯報工作，任何人都會覺得枯燥，甚至成為每天的一項負(fù)擔(dān)，不小心忘了匯報的時候，還會被催或是懲罰，聽起來就可怕。
很多優(yōu)秀的程序員會有自己的筆記本、待辦事項管理工具，他們的自我管理能力非常強。而團隊協(xié)作工具其實可以達到一樣的效果，也可以幫助那些自我管理經(jīng)驗相對較弱的程序員，提高這方面的能力。
方法其實很簡單，把之前屬于個人的知識管理和時間管理轉(zhuǎn)變成團隊的知識管理和時間管理，鼓勵程序員之間互相交換所學(xué)、分享新奇的想法、透明化工作進度都有益于相互激勵。這里說的“自我”，其實是團隊本身，而不是個人。
透明化優(yōu)先級
程序員和項目經(jīng)理其實對優(yōu)先級有著不同的理解，程序員可能偏向于先做一些很快就能完成的工作，而項目經(jīng)理當(dāng)然更希望客戶的緊急需求能夠得到更高的優(yōu)先級。
各種工具其實都能夠?qū)θ蝿?wù)標(biāo)注優(yōu)先級，如果項目經(jīng)理能夠把優(yōu)先級透明化到工具層面，那程序員當(dāng)然能更加直接了解客戶的需求，也可以更好的安排工作。相信沒有程序員會愿意一直做沒有什么商業(yè)價值的功能吧。
建議項目經(jīng)理不要在一個Sprint(沖刺)之中修改優(yōu)先級，即便客戶突然改了主意，也要把這樣的改動留到下個Sprint。與客戶提前商定不可臨時修改的規(guī)則是非常必要的。
避免使用過多的工具
很多公司的程序員不得不用一個很大的收藏夾去放下所有日常要用到的工具，一個工具用于匯報工時，一個工具用于修改Bug，一個工具用于查看需求，一個工具用于溝通需求，一個工具用于查看原型圖。每天要用到那么多工具，項目經(jīng)理需考慮一下這到底要浪費程序員多少寶貴的開發(fā)時間，是不是有些本末倒置了。
其實大部分的團隊協(xié)作工具已經(jīng)集成了知識管理、時間管理、缺陷管理、需求管理甚至是溝通的工作，換個工具給程序員(以及服務(wù)器)減減負(fù)吧。如果實在無法找到對應(yīng)的功能，也可以將某個任務(wù)對應(yīng)其他項目的鏈接集中在一處。
現(xiàn)在很流行的DevOps，把開發(fā)、測試、運維人員的工具需求全部集中至一個平臺，全透明化更有利于多團隊之間的協(xié)作。
分享項目的前景
許多項目經(jīng)理讓程序員埋頭苦干而不知曉項目的未來發(fā)展，實際上會間接影響產(chǎn)品的質(zhì)量。因為只有當(dāng)程序員了解項目未來的業(yè)務(wù)需求時，他們才能更好地提前做好技術(shù)上的選擇，而不是做到最后發(fā)現(xiàn)需要大改。
把當(dāng)前項目未來的戰(zhàn)略、前景、業(yè)務(wù)需求都持續(xù)地更新在工具平臺上，讓這些信息隨時對程序員透明。別讓他們蒙在鼓里，那會使團隊喪失動力。
別讓程序員背鍋
團隊的氣氛總是很壓抑，很多時候，也許是項目經(jīng)理造成的。項目經(jīng)理的壓力確實很大，他們需要去和客戶溝通、集中匯報團隊工作、協(xié)調(diào)各個團隊，還有一些來自內(nèi)部競爭的壓力?？墒菬o論這些壓力來源如何，程度多大，都不應(yīng)該是程序員需要關(guān)心的，程序員需要關(guān)心的是如何攻克技術(shù)難關(guān)、實現(xiàn)業(yè)務(wù)需求。
利用工具減輕程序員的溝通壓力、理解壓力，別讓工具成為程序員的又一種負(fù)擔(dān)。不讓程序員幫你背鍋，才能讓程序員和你一起做一桌好菜。
