就需求開發和管理這一領域，業務分析師努力向客戶收集需求後，下一步當然就是把需求記錄在案了。就記錄在案這一個步驟，CMMI也提出了一個我覺得很多初階管理者不重視的實踐，但是這個實踐極為重要，它就是「與需求提供者就需求的含意達成一致」。簡而言之就是我們在收集需求的時候，理解和寫出來的東西，是否就是對方講的內容呢？會不會在溝通的過程中，理解錯誤呢？我覺得要做好這一個部份，需求的編寫實際上起關鍵的作出，即易於理解及用詞一致。我個人比較不推薦以用戶故事的方式來編寫需求，即需求編寫的格式是「我是誰，想怎樣，然後我能得到什麼價值。」除非對方對上述需求編寫方式已經十分了解，不然的話這種格式未必能很普通地引起對方的共鳴。而且於需求收集的過程中，也未必能準確地識別所謂的價值是什麼。隨便地寫下一個自己猜想的價值可能並不洽當。因此以直接的行文來表達對方希望想要什麼比起以指定格式來編寫更加重要。另一方面就是用詞方面，我最近受到很深刻的教訓，就是用詞前後不一致而引起的混亂。例如我有時會寫使用者姓名，也有時會寫使用者名稱。如果我在不同的句字中混合使用上面的詞，則可能會造成混亂。例如：操作記錄中要顯示操作的使用者姓名；登入時要輸入使用者名稱。讀者會疑惑這兩個資料，顯示的會是同一個資料嗎？還是指兩個不同的資料？因此在編寫需求時保存一致的用詞能避免和減低誤會的發生。畢竟需求編寫完成後，看的是別人而不是自己。文字能表達的內容及意義有其限制，如果項目的需求比較複雜的話，則十分建議以會議的方式來對每項寫下的需求進行講解。也能幫助編寫需求的人更容易找出理解錯誤的地方，並且及時更正。

職場

專案管理大小事

閱讀是為了通過書本認識世界、獲取靈感和改善自己或身邊的人的生活。在此主要分享一些我自己從書中獲得的一些靈感、啟發、見解等內容

Seng Wong的沙龍

沒達成一致意義的需求就是沒有需求

為需求排定優先級對於項目來說異常重要，也是控制項目要實現多少功能的一個手段。如果每一個需求都是同樣重要的話，換句話說就是團隊需要完成所有由用戶提出的需求或功能。那麼在需求管理這一領域來說，我覺得可以說是失敗的。我在這麼多年當項目經理的生涯中，有感這方面管理的困難。當我作為乙方項目經理，要求客戶檢視所有收集回來的需求然後要求他們排定優先級的話，很多時候的結果不會好到那裡去。在他們的眼中，降低優先級某程度就是代表放棄。沒有那個客戶會認為支付了一筆金額後，還要自己降低要求，這是可以接受的。

現在的我是通過工作量透明化的方法來強制打開排定優先級的話題。

- 明確項目目標：乙方項目經理很多時是難以明確知道甲方的項目目標的，因此在執行上往往會出現被甲方拖著鼻子走的情況，只要甲方說這個重要，就需要迫著實現。要打破這個局面，多了解對方項目目標能更利於決定需求的優先程度。以人力資源管理系統（ＨＲ系統）為例，如果對方的目標是改善人員的管理，能更快速地查找個人資料。那麼用戶提出的需求如：修改員工薪金計算公式、員工自助申請假期等；這類合理的需求其優先級能因為跟大目標不太有直接關系而降低；

- 說明總工時：過往的項目，團隊通常會說明項目交付的軟體包含什麼功能。但這樣並不利於項目實現。這是由於需求能於單一功能中無限延伸。再以ＨＲ系統中的「員工管理」此一功能為例，用戶能先提加某某資料欄位的需求，再提欄位和欄位間相互協同相互影響的需求。此類圍繞單一功能無限擴展的情況可謂見怪不怪。因此我們更改做法，於項目的最初，除了跟客戶說明項目將會交付什麼之外，也說明項目包含多少總工時。這能給予項目團隊及客戶一個清晰且可測量的標準。

- 說明實施每項需求所需的時間：每一個人都明白要實施某一個需求，是需要資源的。但是對於不是行內人或是對系統設計了解不深的用戶來說，他們往往會認為所需要的資源幾乎可以忽略不計。換句話說即他們所提出的需求很簡單就能完成，不必為此決定優先級。或者他們會認為每一個需求所需要的資源相差並不大，因此難以作出取捨。為了解決用戶對不確定需要多少資源這一問題，提供明確的參考往往能幫助他們作優先級排序的決定。當客戶得知實施每一個需求大概需要的資源，他們的心中自會盤算是否值得，即實現需求對他工作的幫助是否值得要他支付相對應的金額。

幫助客戶排定優先級的方法

於CMMI的需求開發和管理實踐域中，除了基本如「記錄需求」這種像 “脫褲放屁” 一般的實踐外，有一個實踐我覺得是每一位項目經理都必定聽過，但不一定有做過的實踐。它就是「將需求轉化優先的客戶需求。」言下之意就是在收集客戶各種不同類型的需求後，為需求排定優先順序。排定需求優先順序雖聽起來很理所當然，但是當過項目經理的人就知道，特別是作為乙方的項目經理，很多時收集回來的需求都只有一個優先級，它就是 “最高”。客戶不願意降低需求的優先順序。為何所有需求的優先級都是最高呢？我覺得有幾個不同的原因。- 現在就有：其中一個很重要的原因必定是現在用戶使用中的系統已經有某個功能，即使這個功能使用率有多低，只要現在已經存在的功能，用戶是不希望於新系統中失去任何功能的。- 有所期望：用戶必定希望新系統能比舊系統好，因此所有提出的需求他們都希望能於新系統中實現。而且他們會認為他們提出的需求是必需且不可或缺的，如果缺失的話，感覺會影響更換系統的動機。- 理想主義：新系統應該要能處理各種問題，即使問題的發生機率有多低，只要在需求發掘時有記下，客戶就會認為新系統應能解決該問題，因為客戶會認為此問題必然會於未來再次出現。- 不願失去：於客戶心中，降低需求的優先級於心裡代表的是什麼？必然是失去。最少我認為在他們心中，把優先級降低，即代表新系統將 “有可能” 缺乏解決某一個問題的能力。客戶通常並不會希望失去任何可能的功能，即使他們並未實際擁有它。