[上篇]
其實，大家都這樣做並不代表這就是一個好的方法流程！既然這個客戶的教育訓練承辦單位企圖使用敏捷式專案管理與團隊合作的藥方來醫治組織的這個病灶（IT 部門做出來的系統，經常遠遠不符需求單位的期望），我們就來看看，敏捷方法可以如何來給予協助。
其實，大家都這樣做並不代表這就是一個好的方法流程！既然這個客戶的教育訓練承辦單位企圖使用敏捷式專案管理與團隊合作的藥方來醫治組織的這個病灶（IT 部門做出來的系統，經常遠遠不符需求單位的期望），我們就來看看，敏捷方法可以如何來給予協助。
在敏捷式方法當中，最受歡迎的一個體系叫做 Scrum（讀音：史逛），此方法使用所謂的用戶故事（User Story）這種非常簡單又結構化的格式來蒐集、紀錄、描述一個需求。以下就是一個用戶對一個購物網站專案，以用戶故事格式所提出的需求之範例：
1.
身為一個購物網站的用戶，
2.
我希望這個網站能夠在我輸入郵遞區號時就自動幫我填寫好相關省市街道資訊，
3.
這樣就能節省我很多打字的時間！
上述三點可以分別歸納為以下的三項結構化元素：
1.
角色（Who）
2.
功能/服務（What）
3.
理由/好處/效益/價值（Why）
只要能用上述這樣白話又結構化的用戶故事來溝通需求，需求單位和開發單位之間的障礙就能夠被消除掉一大半。需求單位將會更樂意，也更有能力來提出系統改善的需求，並且聚焦在此需求對他們的「價值」之上，而不是讓需求單位陷在非其專業的細部規格開立泥沼之中。
開發單位也因此更能夠發揮其專業與專長，去發想和設計能夠滿足這個需求的各種細節（包含畫面、流程、看不見的技術限制等），而不是按著不專業、不成熟的規格去照做，結果造成「客戶（需求單位）不滿意，自己（開發團隊）也失意」的雙輸的局面。
如此一來，上述的問題一應該就可以被迎刃而解。
由產品負責人全權負責產品成敗
下一個你會想問的問題應該是，在眾多的用戶故事（需求）當中，到底哪一個用戶故事應該被優先開發實做出來呢？Scrum 敏捷式方法提出應以高價值的用戶故事優先。可是問題又來了，每個用戶故事對其提出者來說都是最重要的，那麼，到底該由誰來仲裁用戶故事彼此之間的價值高低呢？
面對上述的問題二，我們得先來思考一下，組織成立 IT 部門的初衷是什麼？組織之所以會成立一個專責的
IT 部門，不就是要達成「支援/助攻所有其他單位，提升其工作績效」的目標嗎？無論是開發新系統、修改舊系統，或是防止系統掛點（當機、中毒、硬體毀損等）等，IT 部門這一切的作為不都是為了要達到這樣的目標嗎？
既然如此，用戶故事價值排序的仲裁者就不會、也不該是 IT 部門，而應由「監管整個組織績效」的那個人或單位來擔任，而就我看來，這個人似乎最好是由組織中的 COO 或 CEO，或是由各單位高階主管所組成的委員會來擔任，IT 部門則只是達成目標的「實做開發團隊」。如此的設計也才算是符合所謂的顧客導向，不是嗎？
在 Scrum
敏捷式方法當中，這個仲裁者就叫做產品負責人（Product Owner），全權負責產品的成敗。在此客戶的案例當中，產品就是「IT 部門開發出來的各種系統功能」，而成敗的判斷依據則是「用戶故事們被滿足的程度」，也就是因為用戶故事價值被滿足而令「組織整體績效被提升的程度」。因此，IT 部門也就不再擁有一個需求的直接否決權，而只有建議權。
充分透明化的敏捷團隊開發狀態
有了較為公正客觀、客戶導向的產品負責人（或委員會）仲裁用戶故事的價值高低之後，IT 部門只要把人力都聚焦在開發最高價值的用戶故事就行了，而這也因此間接地達成了 IT
部門自己效能最大化的目標，更有利於 IT 部門在組織中價值的提升。
Scrum
敏捷式方法還有許多的設計，都是為了讓敏捷團隊能夠在合理情況下將其效能最大化。例如，5-9人的小團隊組成和團隊一起在共同辦公室內辦公的做法均有利於高效率溝通與相互備援；團隊共同決策所有開發事務和著重團隊共同績效而非個人績效的做法則有利於團隊凝聚力的提升與相互備援；公開透明所有開發過程狀態資訊和定期展示與審查開發成果則有利於團隊紀律的形塑以及對團隊的信任提升。
如果能落實這些敏捷方法的設計，則
IT 部門再也不需「因人力不足而無法實現某個需求」的說詞，需求單位自己即可心知肚明，前方尚餘有多少待辦的高價值需求了。
此外，IT 部門更再也不需承受被關說的壓力而去更動需求的開發順序（因為這已經由產品負責人來決定），還可以用這些透明資訊為證，向組織的高層要求擴充合理人力，相信說服力必能大增！
至此，上述的問題三，也應該已經得到了相當程度的解決了！
無疑地，此客戶選擇敏捷式專案管理與團隊合作的藥方來醫治組織的這個病灶是個對的決策！只不過，專案管理是個跨部門、跨專業的團隊合作，所有參與專案的成員都應該瞭解和配合整個流程才行。如果無法說服 IT 部門的人員來積極參與這個課程，只有需求單位的人員一頭熱地參加，那麼，想要有具體的成效，恐怕也只是緣木求魚罷了！
[上篇]