敏捷開發一千零一問系列之四優先順序排錯怎麼辦？

這是敏捷開發一千零一問系列的第四篇。（在這裡提問，之一，之二，之三，問題總目錄）

對於不斷更新的需求，導致需求優先順序的判斷出現了錯誤，知道專案週期後期才發現，怎麼辦？

1. （臨時方案）確保所有排序均是由po完成的

常常出現所謂現場客戶、由客戶出po、由乙個銷售當po的情況，都是應該避免的。

po一方面要熟悉具體的需求和原始目的（廣度與細度的要求），另一方面則應該對產品的商業目標、終極目的了然於胸（高度與深度），才能站在企業立場而非簡單的客戶價值立場。

從這一方面看，「有無限時間陪著我們的現場客戶」和「乙個銷售」，其細度有餘，高度不足，很容易帶入歧途；而由「客戶出po」則會被客戶牽著鼻子走，客戶的想法一變，專案就會變化，也不符合企業的利益。

2. （最終方案）優先順序排序應該基於較為穩定的商業計畫，要確保有產品總監或專案總監來把控產品或專案方向

一般的產品經理和專案經理排列優先順序的依據一般有兩個：乙個是客戶價值方面，乙個是開發因素方面（比如對架構的影響、需求間的依賴）。但這些都相對淺薄的理解。

真正決定什麼優先的因素，是產品或專案的商業目標，並因此制定版本計畫，在版本中體現優先順序。

作為產品，每個版本都是為了打敗某個競爭對手，取代某個已有產品，獲取某類客戶的過程。從這個角度看，若商業目標明確了，那麼要做什麼功能才能達到商業目標，應該也是相對明確的（或者說，只有商業目標變化時，才需要發生重大的變化，不會突然有人一拍腦袋又變了）。

這一點要求產品研發需要產品總監來做好產品的商業計畫，並與具體負責的產品經理不斷制定和溝通產品版本計畫，並進而明確版本中應該實現的功能。

作為專案，看似是為了完成需求規格上面的描述，其實是為了支撐客戶的某個業務。這個客戶業務，乙方要有人明確是什麼，並最好能預見未來的業務。這樣除非這個業務的優先順序發生變化，專案任務不會發生重大變化。

另外乙個要做好的事情則是專案切忌不能客戶說什麼做什麼，或者什麼專案都做，而是要想好自己企業的主營業務是什麼，有什麼可以平台化以進行積累的東西，才能在做大的同時做強，成為某個領域不可替代的**商。

這一點要求應該按業務領域設立專案總監，對外不斷審視領域的投資價值、分析客戶群，對內推動核心業務的開發而抑制周邊業務的開發。有了這個主心骨，就只有符合實現想好的業務方向的專案才接，自然也就不會發生重大的變化。

專案要想被乙方控制，初期很難做到，甚至說如果這樣是找死；但是如果做了很久還處於什麼專案都做，客戶說什麼做什麼的狀態，則是在等死。

1. 乙個軍工專案

這個專案發生在某年的10.1閱兵儀式上，但可別就此認為所有需求都與此有關，裡邊還是摻雜了甲方很多人的想象，面對強勢的甲方，這些需求很難拒絕。

不過專案負責人還是很清楚那天這個軟體到底會被用來做什麼的，所以核心功能被提前4個月完成並經常使用（因此也很少有缺陷）；而其他功能被扔在最後零星且「湊合」地實現。在最後期限逼近的時候，所有純粹的想象都煙消雲散，最重要的功能順利執行。

2. 乙個產品

這個數碼電視產品研發時，國外已經有兩家企業運營一段時間了，因此主要工作就是「抄襲」他們的功能。在抄襲了一段時間後，終於成為國內的佼佼者，但是現在反觀走過來的幾年，反而冒出一身冷汗，為什麼呢？

原來直到10年後的今天，有很多功能仍然沒有「被使用」，原因就是國內電視台有自己的業務規矩，比如年齡分級、賽事區域禁播這些功能，在國外是很熱門的，但在國內至今也沒有運營。這些功能的優先順序在國內和國外排，會截然不同，這不是乙個開發問題，而是乙個客戶的業務問題。

如果不是因為當年這個領域的競爭不像現在的網際網路行業這麼強，加之團隊的工作能力極強，結局很可能不是現在的樣子。

很多問題的發生，並不侷限於要在開發組的範圍內找答案，而一定要追究最終的原因（無我）。

很多時候人們只現在在自己範圍內找答案的原因，是因為自己可以控制，可以解決。但實際上如鞥這些答案解決問題不徹底，問題就會永遠存在。

但如果遇到了別人的答案，則應該遵循勸人、幫人、替人解決問題的方法。有時候在這家企業、這個部門、這個專案上有可能失敗，但就像共振一篇中所提到的，如果因此而放棄，則必定失敗；不但如此，還會失去在那家企業、那個部門、那個專案的成功準備。

敏捷開發一千零一問系列之四 優先順序排錯怎麼辦？