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

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

這個系列的文章太多，除了用於總結性篇章外，請訪問「問題總目錄」查找感興趣的具體問題。

初始問題

對於不斷更新的需求，致使需求優先級的判斷出現了錯誤，知道項目週期後期才發現，怎麼辦？

答案

1. （臨時方案）確保全部排序均是由PO完成的

經常出現所謂現場客戶、由客戶出PO、由一個銷售當PO的狀況，都是應該避免的。

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

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

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

通常的產品經理和項目經理排列優先級的依據通常有兩個：一個是客戶價值方面，一個是開發因素方面（好比對架構的影響、需求間的依賴）。但這些都相對淺薄的理解。

真正決定什麼優先的因素，是產品或項目的商業目標，並所以制定版本計劃，在版本中體現優先級。

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

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

做爲項目，看似是爲了完成需求規格上面的描述，實際上是爲了支撐客戶的某個業務。這個客戶業務，乙方要有人明確是什麼，並最好能預見將來的業務。這樣除非這個業務的優先級發生變化，項目任務不會發生重大變化。

另一個要作好的事情則是項目切忌不能客戶說什麼作什麼，或者什麼項目都作，而是要想好本身企業的主營業務是什麼，有什麼能夠平臺化以進行積累的東西，才能在作大的同時作強，成爲某個領域不可替代的供應商。

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

項目要想被乙方控制，初期很難作到，甚至說若是這樣是找死；可是若是作了好久還處於什麼項目都作，客戶說什麼作什麼的狀態，則是在等死。

案例

1. 一個軍工項目

這個項目發生在某年的10.1閱兵儀式上，但可別就此認爲全部需求都與此有關，裏邊仍是摻雜了甲方不少人的想象，面對強勢的甲方，這些需求很難拒絕。

不過項目負責人仍是很清楚那天這個軟件到底會被用來作什麼的，因此核心功能被提早4個月完成並常用（所以也不多有缺陷）；而其餘功能被扔在最後零星且「湊合」地實現。在最後期限逼近的時候，全部純粹的想象都煙消雲散，最重要的功能順利運行。

2. 一個產品

這個數字電視產品研發時，國外已經有兩家企業運營一段時間了，所以主要工做就是「抄襲」他們的功能。在抄襲了一段時間後，終於成爲國內的佼佼者，可是如今反觀走過來的幾年，反而冒出一身冷汗，爲何呢？

原來直到10年後的今天，有不少功能仍然沒有「被使用」，緣由就是國內電視臺有本身的業務規矩，好比年齡分級、賽事區域禁播這些功能，在國外是很熱門的，但在國內至今也沒有運營。這些功能的優先級在國內和國外排，會大相徑庭，這不是一個開發問題，而是一個客戶的業務問題。

若是不是由於當年這個領域的競爭不像如今的互聯網行業這麼強，加之團隊的工做能力極強，結局極可能不是如今的樣子。

補充

不少問題的發生，並不侷限於要在開發組的範圍內找答案，而必定要追究最終的緣由（無我）。

不少時候人們只如今在本身範圍內找答案的緣由，是由於本身能夠控制，能夠解決。但實際上如鞥這些答案解決問題不完全，問題就會永遠存在。

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