敏捷開發一千零一問系列之六業務人員怎樣參與開發？

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

有一次課程上居然來了乙個非開發人員，他是個**的業務人員，提出了這個問題，並被評為課堂最佳問題之一。

一線業務部門應該怎樣具體參與到敏捷開發中來？

方案1：

敏捷開發中有很多活動是需要業務部門參與的，如果沒有時間，第乙個要參與的事情是「評審會」，就是階段性驗收產品的會議。在會上應該思考產品在實際應用中是否可用，並提出改進意見。

但是要注意改進意見不要急於實現，而是應該詢問下一步原來的計畫，或許原來的計畫更加重要。

如果能在評審會上對產品未來的應用做出一點**，對之後的迭代會有幫助。

方案2：

如果能選出乙個代表，參與到計畫會中，對於產品經理難以解答的問題給出補充解答，是乙個更好的活動。

各種解答應該具有預見性，因為所謂軟體需求，無非是業務需求在軟體中的體現。業務需求很少是沒有計畫就盲目開展的，因此若能提供預見性的解答，對整個產品未來的方向都會有很大的幫助。

方案3：

將業務架構、商業計畫轉達給開發人員。

技術架構實際上是業務架構的體現，比如360，其業務從最開始就沒打算侷限於防毒，所以業務部門就可以提前告訴開發組，當有一天要開發聊天、安全桌面、安全瀏覽器的時候，開發組並不需要把乙個防毒軟體「重構」成乙個聊天軟體，這是不可能的。

對於產品研發，業務部門若能將市場定位、商業計畫、競爭對手等資訊充分與開發人員溝通，可以有效地避免閉門造車、缺乏預見性、變更頻繁等情況。

方案4：

變敏捷開發為敏捷交付。

敏捷交付是最近的乙個熱詞，其核心是真正地次第地交付產品。

在以往的開發中，比如微軟、nokia，都是做敏捷開發、持續整合的高手，但是他們的產品都不是「敏捷交付」的，都有巨大的版本和斷代存在，而銷售模式也是工業時代的模式：一次付款，不退不換。

敏捷交付創造了新型的互動關係，使得「擁抱整個市場的變化」落到實處，而不再是「把可用產品拿給部分使用者評價一番」，這將是未來業務架構的趨勢。

1. 某銀行

在訪談某銀行的開發過程時，開發部門抱怨說業務部門的人只能說出零星的功能，而且還經常在變化，導致變更很多。

後來訪談業務部門的時候，業務部門卻抱怨說開發部門每次開發的產品都不太符合自己的預想，而且每次增加功能都要「重構」，反應時間較長。

後來又訪談乙個「戰略規劃部」，發現原來業務部門的業務發展，遠在一年前就會有詳盡的規劃，業務部門所提出的零星需求，其實都是基於這些計畫產生的。若能與研發部門事先溝通這些計畫，開發部門就能充分理解需求的**、根本目的、未來走向等等客戶價值相關的資訊，開發出更加好的需求。

戰略規劃部接受了乙個建議：將定期與研發部溝通未來的計畫，從而讓研發部能看到整個業務的全貌。

實際上在銀行這類業務預見性較強的領域，「擁抱變化」不是不斷改進核心價值（在網際網路則是），而是在確定業務目標的情況下，不斷改進具體的實現方法而已。

1. 在很多場景中，業務部門都以「客戶」自居（尤其是甲乙方真正的合同關係時），認為摸索、返工這些事情都是開發組的負擔，與自己無關（有我）。

但實際上，如果開發混亂，真正受害的無疑是業務人員這些終端使用者。因此應該以無我的精神，去幫助那些為自己「交付價值」的開發人員，最終自己也將受益。

2. 從案例中可見，「擁抱變化」和低頭走路是兩碼事

在能看到未來的時候，有時候可以延長sprint0中做架構的時間，將變化侷限於具體業務細化、評審會上改進產品等活動，開發出來的產品反而更好。

人們在「敏捷地」尋找最佳方法的時候，找到的未必是「敏捷的」方法，而是一種相對重型的方法，因為其業務本身是重型的。這是「無住」的一種典型體現。

用副詞「敏捷地」來描述敏捷開發的時候，乙個問題就成了偽命題：「什麼專案（不）適合敏捷？」任何專案，都應該敏捷地尋找最佳方法。

敏捷開發一千零一問系列之六 業務人員怎樣參與開發？