這是敏捷開發一千零一問系列的第十一篇。（之一，之二，之三，問題總目錄）
原來問題是這麼寫的：「每個人對美的認識不一樣，在產品開發過程中，該怎樣有效控制介面設計用時？」
大致是說有些人覺得這樣就得了，另外一些人覺得還不夠漂亮，不知道評審的時候該聽誰的。
這個問題有點另類，所以泛化成「需求誰做主」。
方案1：聽產品經理po的
這個是簡化的方案。
一般而言，我們總會挑選出正確的人，或至少是最正確的人——他對市場清楚，客戶明白，至少在業務方面比程式設計師經多見廣——來形成對需求的雛形，日後驗收的，也是他。
這個人就是po，product owner，產品的主人，產品經理。
不過，常常不存在乙個人這麼厲害，能超越和覆蓋其他人的眼光和見識，怎麼辦呢？
方案2：聽po團隊的
po團隊在產品管理系列中講過，是乙個高低、內外、業務與技術搭配起來的團隊，從各個角度，保證對產品的把握。
這個團隊不是乙個「投票團隊」玩少數服從多數的遊戲，而是各自貢獻特長互補的團隊，人們通過共享知識+集體思考來判斷哪個需求才是真正的需求。
方案3：做servant，不做owner
這個也是產品管理系列中提到過的，就是要真正為客戶服務，而不要太在意「自己的審美觀」。
對客戶而言，不同的操作，會有不同的價值觀，他們需要這些價值觀服務於自己的工作。作為程式設計師，有時候會持有不太一樣的價值觀，比如技術先進性，效能，美觀，而客戶卻對此不感冒。
假設乙個系統有一些自動的通知機制，應該在「我的通知裡邊」如何展示這些通知呢？
下面這個圖平淡無奇，開始的時候就想到了，大致如此：
一些看不太出來的細節從左到右包括：
1. 鬧鐘是「限期完成」，滑鼠懸浮時，上面出現限時的日期。
2. 三角是重要，圖示是通知型別。
4. 小人是單發的還是**的
5. 最右邊的倒數第二個圖示是「未讀」，點一下變成已讀。
6. 最右邊乙個是小旗子，點一下出現乙個下拉列表，選顏色。
這些，都是開發者（產品經理、程式設計師）的第一感。在開發到這裡的時候，我們問自己：當乙個使用者看到自己的通知時，有哪些核心價值需要滿足？
大致思考的結果及後續修改是：
1. 未讀的是型別中最重要的----這導致預設tab頁面從原來的「所有」改為「未讀」（圖中為方便顯示的是「所有」）
2.1 仔細看鬧鐘的左上角，每個事件距離現在還有幾天，用乙個極小的數字標識出來了，所以無需再「懸停」了
2.2 旗幟的顏色直接反映到通知內容中（比如「資料編輯」四個字是藍色的，和旗幟相同），這樣直接看文字比看旗幟再目光移動回來快很多。
2.3 旗幟上的下拉列表操作太慢，改為直接點選就按乙個順序自動切換（只能用乙個「爽」字形容啊）
3. 資訊不要太凌亂
……額，應該說這個我們還有點做得不好，原來的介面比這個還複雜，已經簡化過了，等下一步自己使用一段時間（我們「碰巧」自己用自己的產品），移除一些不太需要的資訊，或者放到不顯眼的位置上。
注意在這個案例中，沒有所謂「領導決定」「投票」這些內容，而是問「使用者在這裡有哪些核心價值需要滿足？」
就是不要把「我」放到產品中的過於重要的位置上，而是讓使用者做主角。
「使用者"常常無法參加開發決策怎麼辦？其實當把握了使用者核心價值的時候，不只是產品經理或po團隊，一般的程式設計師也能為這個價值貢獻想法。如果沒有把握這個價值，就會變成幾個人無謂的爭執，無論po還是領導還是投票解決，結果都不會是最好的。
敏捷開發一千零一問系列之十一 需求誰做主？
這是敏捷開發一千零一問系列的第十一篇。之一，之二，之三，問題總目錄 原來問題是這麼寫的 每個人對美的認識不一樣，在產品開發過程中，該怎樣有效控制介面設計用時？大致是說有些人覺得這樣就得了，另外一些人覺得還不夠漂亮，不知道評審的時候該聽誰的。這個問題有點另類，所以泛化成 需求誰做主 方案1 聽產品經理...
敏捷開發一千零一問系列之十四 敏捷開發加班嗎？
這是敏捷開發一千零一問系列的第十四篇。之一，之二，之三，問題總目錄 正逢週末，又是愚人節，群中有人正在加班，想起上次培訓中間休息的時候，討論起這個 敏捷開發加班嗎 的問題，雖然後來沒有作為課後投票入選，但這裡也完整回答一下。敏捷開發加班嗎？樓下有人問到 敏捷和加班有什麼關係 補充這兩句。有些程式設計...
敏捷開發一千零一問系列之十四 敏捷開發加班嗎？
這是敏捷開發一千零一問系列的第十四篇。在這裡提問，之一，之二，之三，問題總目錄 正逢週末，又是愚人節，群中有人正在加班，想起上次培訓中間休息的時候，討論起這個 敏捷開發加班嗎 的問題，雖然後來沒有作為課後投票入選，但這裡也完整回答一下。敏捷開發加班嗎？樓下有人問到 敏捷和加班有什麼關係 補充這兩句。...