今天讓整個軟硬團隊練習需求切割的過程中，感受到一些有趣的現象，記錄下來與各位分享。這是一個真實存在的需求，但不是實際的時程，藉由這個需求讓團隊練習，也或者說趁此機會同步一下大家的想法。
完整需求大概是這樣的操作情境：
- 使用者可以在軟體上選擇該系列所有產品。
- 選定某個產品後，點擊按鈕可以叫出該產品的所有參數列表，提供使用者選擇。參數約莫數百個，有分群。
- 選擇後進行下載作業，完成產品設定。
而上述幾點實際對應到個工程技術大概是：
- 透過編輯 XML 描述文件即可達成，一台設備需要一份XML，約莫幾個小時就可以全搞定。
- a. 需要設計一個 UI 供顯示參數讓使用者選擇。
b. UI 顯示的參數必須從 SQL 資料庫取得，團隊內無人熟稔此技術。 - 此技術已經完全打通，不需要額外的工程。
我請大家設想的情境為兩週（一個 Sprint）後，可以給使用者什麼產出？大略得到以下幾種答案：
- 一份合約書，讓使用者明白我們已經排入時程，會在期限內交付成品。
- 一份投影片，向使用者描述、介紹我們的設計細節。
- 做一份簡單的 XML，接著先刻 UI，可以讓使用者看到大略的參數選擇介面操作方式。
- 做一份簡單的 XML，接著先做比較難的技術核心 SQL，這之後換機種也都很有用處，不會做白工。
其中也包含與我想法相同的答案：
- 詢問使用者，現在最急、最迫切的需求是哪一台產品、哪幾個參數。就只做該產品的 XML，並且有一個很簡單的 UI 能夠裝載迫切的幾個參數。不串 SQL、不設計複雜的 UI，以能夠快速交付最高的商業價值為優先考量。
在這個 practice 中，發現大家的思考方式不盡相同，但卻往往忽略能夠最快交付最高價值才是首要任務。工程師習慣將工作以技術層面切割，一個技術沒有告個段落，對於下一步感覺不太踏實，然而這個習慣往往成為需求切割的盲點。一個可用的軟體，對使用者才具有真正的價值，這是我在 CSM 課程中紮紮實實感受到的。而可用的軟體，重於詳盡的文件，使用者透過實際的操作才能給予真正的反饋，紙上談兵看起來一切都將很美好。
之前瀑布式的開發模式中，已經逐漸形成一種與 PM 對於時程討價還價的模式。PM 要求時程評估，總得先加個一些 buffer 再來討價還價，把所有心力都放在「估計」時程上。然而在敏捷思維中，我們換個方式與 PM (PO) 溝通，我們拆解需求，知道哪一種情境才是使用者現在最急迫與最在意的，擅長縱向的打通功能、盡速交付才是我們的核心競爭力。這已是一個快的打敗慢的世代。
然而，在這個 practice 中我也發現自己對於需求蒐集、訪談技巧不足，談了兩三個小時候，才發現使用者多數的應用情境根本沒有如此發散，好歹後來有想到趕緊收斂回來。期待接下來 David 老師的課程！
