問題: 如何減少跟某個客戶瞭解和確認並實現了的需求卻被他的同事推翻需重新設計和實現
具體的原因有很多，其中一點是一開始沒找對人.
一個項目，客戶那邊的stakeholder通常不止一個人，這些人有自己負責的領域. 他們也通常是某一領域的專家. 這裡專家的意見要參考，但要找負責的人確認. 所以首要的就是識別誰負責啥.
以CWP項目為例, 初始客戶那邊有4個人. 他們輪流到現場和Team Dev一起工作. 隨著客戶的輪換, 經常出現需求反覆的情況. 一段時間之後, 項目組瞭解了他們各自的職責.
- L需要對商務程序負責. 如果產品上線後發現關鍵的商務程序走不通或變通成本很高, 他的前途就危險了. 其它的問題則基本不會影響他.
- R需要對非功能性需求負責，比如效能，資料安全等. 如果上線後效能很差，資料丟失或泄漏，他的日子就不好過了. 其它的哪怕商務程序有問題也基本影響不到他.
- S是Program Manager,需要對項目總體負責，但主要是預算, 進度, 工期等，只要錢沒花超，要的功能都在那裡先不管品質如何, 他基本上就安全了.
- B是大老闆，他對項目的成敗負責. 除此之外， 他還負責把握實現核心價值的那些功能的需求. 然而由於某種原因，B卻參與的很少，項目組也沒認識到他的重要性，認識到了也沒努力去改變，努力了也出於其他方面的考慮放棄了，採取了等待他自己認識到錯誤的策略. 至於他負責的這部分需求，就都去找L確認，L畢竟也是這個領域的專家. 終於在上線前一個月，B出於某個意料之外的變動，不得不親自參與項目，結果發現設計和實現並不是他要的那種，也沒法責備Team Dev，畢竟是他信任的L確認的需求，也回憶起項目組為involve他曾經作出的努力，只好開始想盡一切辦法彌補. 這裡其實項目組承擔了很大的風險. 相當於把項目最核心的功能推到了上線前一個月才去做， 之前做的都是原型...如果可能，需要儘力避免這種路子...
前面說的這些資訊客戶通常都是不會直接告訴Team Dev的, 需要不斷的去觀察. 一個有用的手段就是非工作場合的非正式交流，比如一起吃飯聊天等. 通常都會講一些各自公司的八卦，真相通常在八卦中.
