7 項目生命週期管理
本章將一個工業物聯網解決方案的生命週期按照大體的時間順序劃分爲：方案企劃、設計論證、實施部署、運行改進和業務退出，並在本章中分別講述。沒有理由相信這種劃分方式是唯一正確的，因爲無論我們將一個工業物聯網解決方案當作項目還是產品來運營，其管理實際上都是一種“最佳實踐”的藝術。也就是說，有很多實際上等價的方式來劃分一個解決方案的生命週期，怎麼劃分無非是不同領域的專業人員從自身經驗和業務特點而產生的不同偏好。
7.1 方案企劃
方案企劃過程的目的是深入理解用戶的需求的實質。該階段包括相互交織的需求獲取和需求分析兩個過程。這個階段不僅僅是後續階段的起點和基礎，也是後續階段的終點。也就是說，在之後的每個階段中，方案的實施團隊都會不斷地在工作中再現和回顧需求分析的結果，甚至是需求分析的基本假設，來驗證當前階段的階段性工作的合理性。之所以會這樣，因爲需求分析過程實際上產生的是整個方案生命週期的行動綱領，以及方案實施團隊和用戶的業務接口。
好的開始是成功的一半，實踐中常見一些方案因爲從一開始就定錯了方向而導致失敗。所以方案企劃的重要性，怎麼說都不爲過。總的來說，我們可以認爲需要先獲取需求，然後加以分析理解，進而編織需求文檔來描述下來以供評審。但就像前面所說的，整個過程是一個多重循環的迭代，任何一個環節都有可能由於新的發現而將你帶回到之前的某個（不見得是最初的步驟）步驟。所以，如果你在某個時刻突然發現自己已經無法分清目前是處於哪一個步驟了，不用驚慌，這隻能說明你對問題的理解正在加深。記得有項目管理領域中的一句老話：你最瞭解項目的時候，是項目驗收交付以後。
7.1.1 需求獲取
首先必須還要囉嗦一句的是，與常見的觀念不同，需求的獲取實際上是一個貫穿整個解決方案週期的活動。不過在本章節，主要還是聚焦於初始的需求獲取，也就是一般概念中的最初的創意的源泉。至於如何在其他階段滲透式地獲取新的需求的修正，將在論述其他階段的章節一併提及。
7.1.1.1 需求獲取的方法
一、（直接）干係人訪談
這裏所謂直接干係人，是指和解決方案的實施有最直接的利益關係的人羣，比如用戶，付款者。訪談的方式可能是被使用得最多的，而且經常是你無意地、自發地就在使用的。但是這種方法的有效性並不容易保證。並不是說作爲一個好的訪談正必須是那種性格外向、和什麼都能打交道的人，實際上，人際交往的技巧主要用在敲開最初的大門以及會談中如何控制會談的進展圍繞向你所需要解決的問題而運轉，而對客戶羣體和目標業務的洞察纔是訪談有效性的關鍵，也是會談的組織者如何確保不偏離主題的立基點。另外還要注意的是，人際交往的能力和業務的洞察力並不見得是由一個人來實現的，而有可能是一個團隊。這個團隊的典型人數是2人：一個負責與客戶的談話，一般由銷售人員扮演；一個負責信息的挖掘和收集，由產品經理、責任工程師來扮演。
和任何會議一樣，訪談之前必須有足夠的準備工作來確保其有效性，這一點就需要相關背景的調研和預先的初步分析。對於公開信息的分析，可以參考下面的段落；而非公開信息的獲取卻是一個長期的貫穿一個方案設計者的職業生涯的過程。這裏面時間是一個關鍵的因素，因爲你必須花上足夠的時間和你的目標用戶羣體的各類角色交往甚至建立個人友誼，纔可能在他們的一次無意的抱怨中獲得靈感。中國的民間智慧中，常說“改行窮三年”和“不熟不做”，其實說的就是這個道理。當然和做任何事情一樣，要做好還需要必要的技能，因爲好的技能可以縮短你瞭解一個領域的時間。這裏要重點說的技能就是對公開信息和專家意見的捕捉和消化。
二、公開信息
在搜索引擎被廣泛使用之前，只有書籍和專業雜誌的綜述性文章纔是你在短時間內系統地瞭解一個領域的方法，但這個方法的問題主要有兩個：第一是系統化的組織的知識看起來很嚇人，因爲那厚厚的一本書讓我們聯想起大學中另一個專業的專業課教材。第二是時效性，也就是說，當這些知識被系統地整理起來的時候，往往已經和產業界中的實際情況已經有數年的差異。
但是請永遠也不要忽視公開的、已經被體系化整理的知識的力量，因爲這些知識往往仍然是形成領域現狀的基礎。即便是關於我們常常認爲是瞬息萬變的消費類市場領域，那些心理學和文化的運作原理實際上在人類的幾千年的歷史中並沒有根本性的改變。讀古人的書是必要的，何況這些專業書籍和文章還沒有那麼古。體系化的知識提供了一個座標原點，以幫助你根據通過其他方式收集的即時信息修正自己的理解。那種“難道我要學習另一門學科嗎”的畏懼感是不必要的，要對自己的大腦有這個自信：大學中各工科專業的專業課時間並不長，更長的時間實際是都是在學習類似的基礎課，不是麼？何況，你只是要爲目標領域打造一個解決方案，這意味着你所需要的更多的只是該目標領域知識的一個側面，而不是全部，所以你在瀏覽該目標領域的體系化知識的時候更多的是跳躍和選擇的，而不是地毯式的搜索或者叫你要拿那個領域的學位。
互聯網是另一個收集公開信息的手段。但是你要了解自己要查什麼。一個缺乏體系性知識的人往往在搜索引擎之前茫然無措，只能反覆將最初的問題拆解成幾個關鍵詞來輸入，而這些關鍵詞也許是膚淺的，或者是因爲該問題在領域中剛剛得到關注而完全搜索不到任何有價值的內容。
三、專家意見
對一個新進該領域的人來說，有機會找到一個領域專家進行一次議題相對開放的會談是一個快速入門的好辦法。行業中有各知名企業的從業人員、各種協會和科研機構人員、大學教授和研究生，還有政府中主管該領域的公務員，這些都是很好的專家羣體。你需要結識他們的方式，比如直接登門拜訪、行業展會和研討會上的茶歇會談等等。專業人士的職業天性一般都會促使他們和你愉快地交談，但是你也必須要注意一些基本的社交禮儀，比如你不能讓對方感到你在刺探對方的商業機密。
在收集專家意見的時候特別要注意，對於獲取的意見要批判接受。不是說大多數專家贊同或反對的就一定對或不對，如果行業裏的共識太普遍，也許這正是問題的根源。比如在企業信息化剛出現的時候，各路專家實際上心裏都有一種對“電腦取代人腦”的恐懼而不肯擁抱計算機所帶來的變革，從而會對你所說的任何以信息化提升工作效率的提議都是否定和牴觸的。這種牴觸並不是簡單的說“否”，而是會給你一大堆的看似有道理的理由，如果你沒有足夠的成體系的該領域知識來形成反問句，此時的你也許已經把自己的創意在心中否定了。
還有就是，多數的專家所能提供的都是一般性的答案，也就是目前普遍而言正確的答案。而你要構建的解決方案可能是要解決某個客戶的非常個性化的問題，或者正式要引入某種來自行業外部的新技術和商業力量來解決當前普遍需要解決的行業性困難。也就是說，一個解決方案要麼解決的是一個本行業的新問題，要麼是引入了原本屬於其他領域的技術而成爲兩個領域的重疊區域。這些時候，一般性的專家觀點對你有多大的幫助就很難說了。總之，無論何時，在徵求專家的意見的時候都要同時運用自己的大腦：要隨時考慮專家的職業立場、個人背景、利益相關性等等所產生的意見的盲區，而切不可盲目接受。實際上，當你爲某個問題提供了客戶普遍認可的解決方案後，可能只有你才配稱爲這個問題的“領域專家”。
還有就是，不要試圖請解決方案要服務的目標領域的專家回答你自己領域的問題。在理解客戶需求的時候，難免會令我們立刻陷入對如何構建技術方案來滿足這個需求的迷惑中，但請將這個迷惑放在心裏或者記在筆記本上日後處理。因爲這些都不是現在就要和客戶或者目標領域專家討論的事項，而是體現我們自己的專業能力的地方。
小案例
記得一次在與客戶討論其能源管理系統該如何構建的時候，當客戶中負責能源管理的工程師說：“我們公司的水、電、熱蒸汽的賬單結算日是不同，分別是每月的20、28和30日。所以，在計算每月的能源消費的時候，要注意統一折算到每個自然月。”這時項目經理問：“對於折算，貴公司是希望採用按每天平攤的方式麼？或者有其他的方法？”客戶顯然對這個問題陷入沉思，但是他們知道這時他們必須回答的。不過有時候客戶也會說：“也許你們比我們更有經驗，或者麻煩你們在方案裏做一個建議吧。”事情到這裏還沒有跑偏，但是突然我方的一位工程師開始大聲抱怨：“如果這樣，我數據庫的複雜性就會增加。或者你們能建議我要怎麼設定我的表結構呢？”客戶方的能源管理工程師此事已經完全不知道要怎麼應對了。
四、問卷調查
調查問卷其實可以視爲直接干係人訪談的一種格式化的模式，但是越來越多的人開始在問卷中採取沒有標準答案的開放式問題。在現實中我們可能不得不做出某種妥協：提供有限可選項的標準化問題用於我們已經自信梳理出來全部（或者絕大多數）潛在答案的問題，而開放性問題留給那些我們還不甚理解的問題。開放性問題在需求採集過程中需要被採訪者花費較多的時間來回答，所以有時不得不付出一些溝通代價，比如一個小禮物；另外後期的需求整理也需要更多的邏輯分析技巧。
對問卷調查的評價可謂譭譽參半，而且可以說這其中的“毀”的成分在近年來有變多的趨勢。但事實上，很多時髦的調研方式中都或多或少包含問卷調查的隱含模式，只不過這些新方式的提出問題的方式更加隱晦和自然，從而更可能獲得有深度的答案。
五、場景觀察
對於企業流程改進類的問題，場景觀察室一種非常有效的方式，尤其當你缺乏背景知識而陷入一片迷茫的時候。另一種特別適合場景觀察的情況，就是客戶感覺其自身某處存在問題，但是卻無法明確提出。這在離散製造業中其實非常常見，也正是爲何一些管理諮詢公司可以在企業管理信息化的領域十分活躍的原因：諮詢公司的典型模式是從企業流程的理解和優化切入，在優化後的生產流程得到客戶的認可後，再給出配套的信息化系統的設計，最後安排軟硬件工程師搭建新的系統或改建既有的系統以實現最終的交付。
場景觀察的第一步仍然是需要做一點基於公開信息的調研，從而能給自己多一點在觀察中發現問題的啓示。但是可能一開始未必深刻。然後作爲一名觀察員記錄和梳理客戶的日常活動流程和特點，關注其信息交流模式，建立既有流程的模型。但是更快的方法是，需求採集者是作爲客戶團隊的見習員工而不是觀察員，直接參與到客戶團隊的日常工作中去。這麼做的一個附加好處就是建立了採集者和客戶團隊成員之間的人際關係紐帶，從而可以爲捕捉更細緻的信息創造條件。這種方式在等級觀念較強的企業或者政府機關中有特別好的效果，因爲在那樣的局部環境下，正式的會談中下屬可能並不敢明確表明自己的觀點——對問題的明確表述可能會被同事和上級主管視作某種不滿的發泄和抱怨，而不是建設性的工作態度。
在現代有各種記錄設備的條件下，場景觀察可以提供非常豐富的原始資料以供後期的分析。但也可能會造成觀察者被淹沒在場景中、被細緻末節的事情誤導而忘記了場景所處的大環境的危險。有時候場景觀察給觀察者的印象太過深刻，以至於觀察者會特別堅持觀察中所獲得的信息所得到的推論，但是忘記了整個企業、整個行業甚至國家經濟與社會面臨的變化。這樣的結果必然是得到一個在最初看起來非常有效的方案設計，在幾個月內就可能瞬間就瓦解了。這種在方案企劃階段的缺乏前瞻性，也是部分解決方案不得不面臨持續改進的原因之一。
7.1.1.2 需求歸檔
建議將獲取的需求整理成文檔，一方面防止自己在未來的工作中遺漏，另一方面也方便傳遞給其他同事進行深入的分析。
首先建議要保留所有的原始材料。需求獲取過程中的原始材料的形式多樣：書籍或書籍摘要、簡報、網頁存檔、手寫的筆記、問卷調查的原件、錄音、錄像、照片等等。一個原則就是，在隨後的整理分類中，儘量將這些原始材料保持原樣而不是銷燬。雖然這些原始資料可能並不值得你花費時間去編目整理，只要找個文件袋放好或者將數字化形式的文件存放在某個文件夾中即可，但是保存原始資料永遠是個值得稱道的好習慣。這麼做的主要原因在於：雖然在接下來的過程中我們需要將這些原始材料進行整理消化，但是要注意，人們的整理工作永遠只是基於當前對問題的理解而進行的；隨着我們進一步的分析和着手開始設計方案，甚至在後期的實現和運行中，隨着我們逐漸成爲方案領域的專家，我們會不斷加深我們對原始材料的理解，從而發現最初的原始材料中在一開始被我們忽略的內涵。
其次開始將原始資料做一定的整理。這種整理有初步分析的意味，但還是沒到方案的詳細設計那麼深刻。在這個階段，實際上筆者建議在整理過程中儘量客觀梳理所收集到的信息，而不要把自己在梳理過程中不自主的對解決方案的靈光乍現摻雜在整理文檔中。你可以將這些靈感記錄在一個筆記本中以備後期在方案設計中使用，但記錄在需求整理的材料中卻很可能是個壞主意：這有可能因爲你對自己的這個靈光乍現的思路的執着而扭曲了客觀事實，甚至將後續加入的其他團隊成員都“帶到陰溝裏去”。
需求文檔的形式靈活多樣，具體的形式其實是要看具體的信息採集過程。爲了方便信息的傳遞和後期的分析，可以儘量將原始文件數字化、量化、甚至做成電子表格的形式。要恪守的兩個原則就是：整理的目的是爲了方便後續的分析和引用，而整理的方法就是儘量將原始資料轉換成方便分析和引用的方式，但同時避免丟失任何有價值的信息。
如果你做了某種問卷調查，對問卷的答案做一個電子表格，甚至提供一點統計是不錯的方式。如果這個問卷的問題是開放性問題，即並不是在有限的選擇中選取，整理的過程則需要特別的小心和技巧。此時建議您仔細閱讀每個開放性問題，然後試圖識別這些開放性問題的答案中所展現的規律，從而進行進一步的分類。如果這些規律相當明顯但是並沒有被所有的被調查者在答案中反映出來，也許你應該儘快組織另一場針對這些新發現的規律的調研（可能是另一場問卷調查）。如果新的調研已經在資源層面不可能，建議在儘量分類整理後，用一個“備註”欄將那些可能值得特別關注的回答摘抄出來。
對於照片、錄音、錄像這些資料，其信息量往往很大，我們需要一種“無損壓縮”甚至“有損壓縮”的方式。將在這些資料中觀察到的現象用文字儘量客觀地記錄下來。
無論是什麼樣的原始資料，在整理彙總過程都儘量分類和量化。分類和量化實際上是一種“有損壓縮”方式，因爲在這個過程中必然會損失一定的個性化信息。這個有損壓縮是否會喪失過多的有效信息，實際上有很大程度上依賴於整理者對領域知識的掌握程度甚至是直覺，甚至有一點“藝術”的成分，需要經常的練習和思考才能增進和保持這樣的能力。
在規模較大的公司，或者某些自以爲已經不會發生任何改變的所謂傳統行業中，一個常見的現象就是企業會制定某種信息收集的表格來發現需求。
7.1.2 需求分析
需求分析的目的是得到對解決方案的功能描述。有時被稱爲市場需求文檔（MRD，Market Requirement Description）或者產品需求文檔（PRD，Product Requirement Description）。實際上，需求分析是整個解決方案的功能設計工作，分析的結果就應該已經決定了方案的交付物形態和存在的邊界。如果沒有這樣的功能設計作爲交付物，需求分析就彷彿只是得到了一堆沒有得到答案的問題。如果是需求的獲取是“什麼問題值得我去解決”，需求分析就相當於先回答“問題的實質是什麼”，然後計劃一下“我該如何去解決”。
7.1.2.1 分析的框架：宏觀與微觀
在需求分析的過程中，針對企業客戶的宏觀和微觀的關係是一個需要方法和經驗來把握的地方。對於企業，在管理學中用的波特五力和PEST方法，是典型的對其所處的生存環境的分析框架。而企業的微觀分析的維度，常用的有QCDML維度，即：
Q-品質（安全性、穩定性、可靠性）
C-成本/價格
D/D-產量/效率/交付能力
D/L-產品研發/技術
M-人才/設備/物/方法/測量
S-銷售/服務
另外一個很重要的常用框架就是SWOT分析。
以上這些分析的框架在常見的管理學書籍中都要，此處不再贅述。需要提醒的是，凡事都有兩面性：任何框架對於頭腦中缺乏思路的人而言可以起到很好的提示作用，但是對於有一定經驗的人而言，卻可能無意中讓你失去了某些特殊的視角。
參考和使用這些框架的好處在於，框架不僅會提醒你在採集需求信息的時候不要忘記有關的維度，防止你犯對某一維度過問重視的錯誤，也可以爲你提供一個檢驗遷移階段需求獲取過程中工作的完整性。你可以把這些框架作爲一個檢查清單，然後對照下看看是否遺漏那一方面信息的收集和思考。利用這種框架的提醒不是說你應該事務鉅細地關注所有的事情，更不是說你要在隨後的文檔中牽強附會地非要把兩件沒那麼大關聯的事情扯在一起。作爲需求的收集者，你永遠有自己判斷的權力。
一個例子在中國特別常見：很多企業家過分迷信政府政策的主導能力。當被問到爲何開始某個業務的時候，或者在向其客戶推薦某個解決方案的時候，會特別強調政府的政策導向。這種多少帶有一定的投機主義的做法，僅適合一些短期的項目型的解決方案，作爲長期的業務和需要較大前期投入的產品，把政府導向作爲市場調研的壓倒性因素是非常危險的。雖然政府是不可忽視的力量，但也永遠只是不可忽視的力量之一。
7.1.2.2 分析的方法
爲什麼要先回答“問題的實質”呢？因爲需求獲取中收集到的信息，本身可能只是一個表象，而不是真正要回答和解決的問題。這就好比你見到一個皮膚髮黑的人，問題不是“皮膚黑（表皮層天生色素較多）”，而可能是日光浴、中毒或者其他別的什麼誘因，不同的誘因首先決定了這個表象是否是值得擔憂而要消除的，然後纔是如何消除。
常見的分析方法有：
一、遞進推演
遞進推演就是以說獲取的需求信息爲基礎，不斷總結、不斷歸納，不斷尋找其中的各種內在邏輯，從而激發自己和團隊的靈感，找出解決方案。這裏我們可以簡單講兩個比較實用的工具，即思維導圖（Mindmap）和頭腦風暴（Brain Strom）。
思維導圖由Tony Buzan發明，最初作爲學習工具，後來逐漸流行於各種企業培訓，尤其是在信息技術和互聯網領域。既然其發明者聲稱其可以表徵和模仿人類大腦思維的過程，那麼出現這樣的情況也就不足爲奇：似乎什麼事情都可以採取思維導圖的方式，從做讀書筆記到整理創意。當Apple公司推出了劃時代的iPhone智能手機之後，思維導圖軟件也第一時間出現在其應用商店中。
在利用思維導圖整理你的思路的時候，一般的主張是採用一張儘可能大的紙張（思維導圖軟件的製作者們聲稱，計算機和手機的屏幕尺寸不是問題，因爲你可以上下左右地移動從而獲得實際上是無限的紙張大小。信不信由你吧。）然後將需要討論的核心議題的關鍵詞寫在當中，並且隨着你的思考，把圍繞這個關鍵詞出現的新的關鍵詞寫在其周圍，並用線連接。這些線就像神經一樣，連接的都是有關聯的關鍵詞。慢慢地你就產生了分類整理的慾望，此時你可能需要重新拿一張紙來重新開始畫。（如果用軟件，就是花一點時間重新編輯一下。）畫面上所有的表達儘量生動、簡潔、充滿色彩、儘量用圖形，以及任何可以刺激你的方式。慢慢地，你開始看出主要邏輯之間的橫向的關聯性，所以還會加入一些虛線來表達各種關聯性。
現在回到需求分析這個我們正在面臨的任務。相信你已經明白了，你現在不缺少關鍵詞，因爲你已經進行了需求的採集工作。現在你可以盡情地利用思維導圖來整理你獲取的資料了。你可以先將已經初步整理的原始資料做進一步的分類整理，然後開始在圖上進行下一步的推理，然後是建立橫向的聯繫，進一步加深自己的洞察力。
還記得剛剛講過的那些分析的框架麼？沒錯，圍繞你的核心問題關鍵詞的第一層關鍵詞也許就是來自那些框架。而類似SWOT之類的綜合考慮企業戰略的框架也正可以建立跨越各由第一層關鍵詞引發的分支的新的關聯。
思維導圖的基本方式並不難，但是要做得好還是要靠不斷的練習來養成勤于思考的習慣。另一個值得推薦的方法是，一個小組而不是一個人來完成關於一個解決方案的思維導圖。與該方案有關的工作小組所有成員在一起，每個參會的人在進入會場之前已經獲得了之前獲得的需求信息的整理文檔，甚至已經經歷一場有負責需求獲取的同事主持的彙報會。然後大家在主持人的帶領下，一邊討論，一邊繪製思維導圖。
頭腦風暴的方式是必須基於一個小組的集體會議的。在主持人的帶領下，大家自由發揮自己的創意給出見解，並將自己的想法寫在若干張紙條上。爲了防止思路的過度發散而偏離重點，每個人的紙條總數可能是有上限的——也就是說，強迫每個人寫出他自己認爲的最重要的幾個見解。然後大家將每個人的紙條拿出來評審，合併同類項，去掉公認爲不可行的。然後進行一輪投票或者就此次發現的新的問題再做一次頭腦風暴迭代。在做頭腦風暴的時候，主管最好是主持人，並且不要發表任何可能壓制同事意見的評判。
同樣地，進行頭腦風暴之前，也應該做好會議準備，即每個人參會者都必須得到一份需求信息彙總文檔，並有充分的時間消化。
二、場景構建
場景構建的方法是在試圖搭建一個構成目標用戶羣體的所有角色所活動的一個完整的場景，以供進行思維試驗，並從中來理解現有場景存在的問題，推演解決方案對這個場景所帶來的全方位的影響從而完成解決方案從構建到評估的全過程。
場景構建的關鍵詞是思維試驗，所以你之前收集到的那些信息其實是搭建最初的思維試驗原型的鋼筋磚瓦泥灰這樣的建築材料。而這個原型在你的思維中搭建成功之後，我們就可以假象我們成爲其中的某個角色，從而體會這個角色感受。如果這是一個涉及多類角色的場景，我們可能還要學會切換不同的角色，身兼數職。或者，利用團隊的力量，由不同的人扮演不同的角色來利用場景所提供的故事腳本扮演這個場景。
在利用對現狀的理解逐漸進入角色之後，作爲畫外音的方案主持人可能說，如果我們加入了這樣一個改變，大家又會怎樣。於是按照新的劇情大家繼續推演。推演的過程最好可以利用錄像設備記錄下來，以備事後集體討論和分析，從而不要讓團隊被不得不停下來的記錄而把自己從剛剛進入的角色中拉出來。
場景構建的技巧掌握起來難度較大，但就其威力而言，是值得花精力去學習和實踐的。
7.1.3 文檔編制
7.1.3.1 文檔的名稱
需求分析的結果就是要編制出市場需求文檔或者產品需求文檔。在實際應用中有的企業將對採集到的需求信息的原始材料的整理文檔（可能有時還要添加一定的分析結果）稱爲市場需求文檔；而將對解決方案的設計，特別是這個解決方案最終是一個產品的時候，稱爲產品需求文檔。有時候索性簡化，只有產品需求文檔最爲這一階段的最終工作成果。也有的理解認爲，如果公司的商業模式以項目爲主，則稱之爲市場需求文檔，如果以產品爲主，則稱之爲產品需求文檔。這個理解的理由是，項目一般是爲其客戶單獨打造的，所以基本上客戶的需求不用經過太多的分析和設計，只要比較直接的記錄和整理即可，所以這一階段的工作結果也就基本上是對需求的原始材料的整理。而產品爲主要商業模式的公司則不盡然，他們需要採集來自多個客戶或個人用戶的需求，然後做較爲深入的消化才能設計出一個滿足大多數目標市場個體的一個解決方案。顯然後者是需要更深入的分析和打磨的，所以後者採用產品描述文檔。
爲客戶定製暗含了一個潛在危險：爲客戶定製打造對任何公司都是一項耗費成本的工作，因爲在產品化的過程中，一些研發和管理費用會因爲產品化的複製而被多個用戶分攤，從而可以大大降低用在每個客戶身上的成本，即所謂產品的規模效應。然而，如果你認爲爲客戶定製就意味着放棄產品化的模塊重用和成本分攤的話，就可能最後陷入營業額高漲但利潤增長很慢的窘境。更不用說，如果放棄了產品化中那種對質量的追求，加上太多個性化的模塊，最後容易導致售後維護陷入極端困難的境地，你講項目成果交付給客戶時讓你興奮不已的毛利潤很快就在費時費力的售後服務中煙消雲散了。這是爲什麼爲了打造持續的業務，即便是在具體客戶定製方案，我們也應該儘量尋找可產品化的局部模塊的原因。
總之，文檔的名稱並不重要，更不要被文檔的名稱所隱含的某種寓意而迷惑。任何時候，編制文檔的最高宗旨永遠是：講得明白。
7.1.3.2 文檔提綱
你就職的公司可能有需求分析的模板，網上有很多類似的免費分享可以利用。如果你仔細比對，就會發現其實這些文檔模板都大同小異。
XXX項目需求分析
業務背景
講述業務需求的來源、目標客戶、需要解決的問題的最初想法等。
行業分析
講述當前行業中對此類問題的解決方案的現狀：都有哪些公司或者團體活躍在這個領域，各自扮演神了角色，他們提供了什麼解決方案，市場對他們所提供的反應如何。更重要地，你的團隊對這些解決方案的優缺點的評價如何。
客戶需求
即將之前獲取的用戶需求的原始材料整理消化後放在這裏。
需求分析
這一段是真正的分析和推理過程。將你和你的團隊對以上所欲有那些信息，按照一定的框架，採用一定的方法，消化後以某種概率相信用戶就是需要怎樣的功能。
功能設計
將上面已經分析得出的功能詳細描述在這裏。
非功能性要求
這一段實際上很容易被忽略。經常看到僅僅是應景一般淡淡寫上幾筆諸如“保障數據和網絡安全、注意實施成本”之類的話。比較好方法是，要重點突出那些對這個解決方案的實現有明確意義的要求。那些行業中的一般規則就沒有必要再寫了，或者簡介明瞭地寫出“數據安全性應符合國家某某標準”即可。
需求文檔的措辭要儘可能地明確可操作，少用“高、底、多、少”之類的形容詞，除非這些詞語在特定的領域已經有了約定俗成的定義。這麼做不僅僅是要在餘下的工作中保證準確傳達其含義，還有一個重要的法律意義。需求文檔很可能成爲合同的一部分，一般成爲技術合同或者合同的技術附件，這樣而言，那些模糊而容易產生歧義的形容詞就成了潛在的風險。
7.1.3.3 常用工具
除了上面的模板提綱，一些具體的表述方式也是常見的工具。
一、 圖表
最常用的是大家都熟悉的流程圖，其中分部門的流程圖對於連接多個角色的應用更加清晰明瞭。雖然UML體系的一些列圖表被設計來爲複雜的應用建模，但是並不是其中每種圖表都在需求分析中被同等地重視。用例圖是最常用的一種，然後是活動圖和交互圖。一些特別技術性的解決方案可能會用到狀態圖。UML的最大的詬病就是，太過理論化以至於很多時候會讓你的客戶感到難以理解，從而影響你的團隊和客戶的交流。更糟糕的是，偶爾極端的情況下，有些客戶會認爲這種他看不太懂的圖表本應該是你自己需要處理的東西，從而因爲你要拿這個圖表來和他討論而低估你的技術能力。
二、 產品原型
包括產品效果圖，操作界面的框線草圖，描述交互模式的文檔等。我們可能已經越來越習慣於原型了：建築師給客戶的效果圖和按比例的模型，甚至連我們購買尚未完工交付的公寓的時候也能看到這樣的模型；飯店前臺的每道菜的蠟質模型。軟件行業最初喜歡給客戶預先設計幾個典型的界面，現在已經發展處利用一個很複雜的原型工具來幾乎模仿出整個軟件的操作過程——有些工具在勤奮的產品經理的手中會把軟件模仿得如此逼真，即所謂“全尺寸模型”，已經會讓某些粗心的客戶認爲軟件已經瀕於完成了。而且，一些原型工具的功能如此複雜，簡直將自身變成了圖形化編程工具。常用的工具包括Microsoft的Visio，主要是做界面框線圖，而FLASH、Auxure和一些基於HTML5的工具主要用於搭建逼真的原型。中國國產的軟件也有一些。
三、 場景描述
一個場景的描述包括時間、地點、人物、事件和各角色之間的連接方式。和構建場景和推演的方法類似，描述一個場景也可以借鑑劇本的創作。先要流出這個元素，然後再分幕描述在這個場景下可能的不同“劇情”——也就是各類角色利用方案的功能而形成的新的動作，尤其是角色之間的互動，這一點對於連接多種角色的流程類和多邊平臺（存在不同用戶羣體的平臺）中尤其重要。
7.1.4 需求評審
需求評審總地來說可以分爲內部評審和外部評審。這裏的內部和外部的界限在哪裏，可能會讓人迷惑。筆者主張的定義是，凡是在最終用戶的評審之前的任何評審都稱爲內部評審。而外部評審就僅指最終用戶的評審。所以，對於同一個公司內部需求的解決方案，方案最終使用的部門的評審其實應該視爲外部評審。
常用的評審方法有：
一、文檔回顧
這是內部評審主要採用的模式，但是常見的客戶回訪會議中也是以文檔回顧爲主。團隊，包括團隊的外部主管一起回到最初的需求整理文檔，然後逐條對照是否被功能設計中的某一條或某幾條滿足了、滿足得好不好、是否有更好的改進。文檔回顧可以採用審批流程，但是大家坐在一起的評審會效果會更好。
內部的文檔回顧可以不做特別的準備，但是在客戶回訪會議中最好再編制一套幻燈片，併爲每個與會者準備一份需求整理文檔和需求分析文檔。你應注意對內對外的文件在措辭上的不同。
小案例
一家建築智能化系統集成商正在爲某個學校的新教學樓的弱電工程準備方案。這個方案除了正常的需求，還有一個資金層面的意圖：當地政府對可爲學生提供現場試驗的設施可以給予一定的補助，而這個學校由於資金的緊張很希望能夠拿到這筆補貼。學者們的表述是隱晦的，但實際上卻是壓倒性的。這家集成商的項目團隊敏感地捕捉到了這一點，所以在內部的文件中特別突出地描述了爲這一意圖的設計。但是在客戶（學校）面前彙報方案的時候，這個需求不會被說成“順利獲得政府的補貼”，而是“充分考慮學生實習的需要”。
二、原型檢測
無論對內部和外部的檢驗都很有效，但是對於內部評審似乎成本有些過高，也未必及時。即利用搭建的原型來回顧和檢驗是否符合目標用戶的需求。有時我們可以將原型直接展示給目標用戶，然後聽取他們的反饋。因爲是原型，很多時候還不能直接體驗，所以在展示的過程中講解員的表達能力很重要。也可以使用視頻錄像的方式，利用一名同事扮演客戶，大家將該同事使用原型工作的過程錄製剪輯成一個短片。這名扮演客戶的同事，最理想的人選是對該項目有一定了解但是在設計過程中並未深度介入的人，比如該項目的銷售、項目組的直接主管，或者合適的該領域外部專家。如果不甚方便，也可以將典型使用情節拍成照片或者配合場景描述中的腳本來展示。
原型檢驗可以幫助人們檢驗一些不那麼好想象的細節，但是對於不適合形象化表述的技術標準類需求是不適合的。所以，原型檢驗最好是配合文檔審查使用。
7.1.5 其他話題
7.1.5.1 誰是用戶
我們一般認爲，那些爲客戶定製的項目很容易識別用戶是誰，但真的是這樣麼？對於一個企業客戶，實際上你要面對的不是一個人，或者一個虛擬的企業法人，而是一羣有不同利益訴求的人。一套旨在增進企業運轉效率的製造執行系統（MES）或者企業資源系統（ERP），被管理者和管理者之間就可能存在不同的理解。在這樣的系統中，普通員工往往是每天最頻繁的使用者，但是主導系統需求提出和認可的卻往往是主管們。如果不能平衡地處理各自的訴求，就可能出現系統功能過度圍繞管理者的需求設計，而需要輸入數據和通過系統互相協作的基層員工的體驗是被忽略了。這很可能導致員工們花費太多的時間“服務”於這個新上線的系統，而不是感到被系統所服務。最後也就導致基層員工對系統的上線怨聲載道，甚至或明或暗地拒絕配合。最後當回顧和評價這個系統的作用時，能夠得到什麼樣的評價就可想而知了。這也是爲什麼在某些企業中每次更換主管經理時就容易重新改造系統，因爲每一任新上任的主管在聆聽員工的意見時一定會得到很多關於系統的抱怨，於是便開始以針對系統的整改來取悅大家或表明自己的工作成就——而這些整改可能原本就不該發生。
另一類被忽視的用戶是二次開發者。每個系統或者產品都免不了被改建或擴建，此時它就面臨者新的開發人員這類特殊的用戶。我們可以看到，最近出現的各種物聯網平臺服務商，實際上他們百般強調的賣點正式面向二次開發者的友好。項目型的解決方案實際上存在同樣的問題。清晰的架構和文檔給未來的維護者帶來工作的便利，而這種便利就意味着更低的維護成本和更快的反應速度。
7.1.5.2 需求分析者的素養
雖然有很多講解需求分析的教科書，但是不能否認這項工作中存在很大的藝術的成分。作爲半個藝術家，爲了做好這項工作你需要在平時就培養自己的工作素養。
首先，你必須在客觀中保持自我。既要在信息採集的過程中保持客觀的精神，也不能放棄自身對現實的思考。即便是對一個問題有着同樣的見解，不同的人給出的解決方案也會不同。那麼哪一個是最優，必須要秉承客觀的角度去判斷，同時對自己的創意又足夠的自信——這種自信至少要支撐到的確被各種後期的論證證明不適用爲止，而不是稍一遇到質疑就放棄。
其次，要磨練自己抓住重點的能力。在這個過程中你會遇到很多信息，有些也特別有趣，但有趣不等於是關鍵問題。你必須在工作中建立起一套篩選重要問題的標準和思考框架，或者能快速識別關鍵客戶的平角標準和思考框架。
最後，要學會有效地溝通。學會在溝通中掌握移情作用是最好的手段，這一點在理解客戶的關鍵訴求非常重要。在各種文檔和演講中要緊扣主題、反覆強調和再現它。溝通的表達要精煉在精煉，可以參照很多諮詢公司採取的所謂“電梯檢驗”，即：假設你和客戶的主管只有乘電梯下樓的30秒時間，你要怎麼有效利用這麼短的時間將重點傳遞給他？當然，完整的功能實際是不可能用30秒瀏覽並理解透徹的，但是關鍵信息的獲取過程可以，分析後的關鍵結論和功能設計的終點可以。可視化手段一般來說比文字更容易給人以直觀的感受，而當今多媒體科技和各種圖標軟件的確也提供了這方面的便利，要充分利用。還有一點就是溝通的時機問題。對於吹毛求疵的客戶，也許結論性的溝通放得晚一點，待你基本落實了每個細節再進行可能會更有效，而有的客戶卻喜歡隨時瞭解您的進展而隨時可以決定是否跳進來和你一起工作。你對客戶對溝通的偏好越早識別出來是越好的。
7.1.5.3 對方案企劃過程的管理
首先的建議是，不過度流程化，反對模板主義。這兩點是相互關聯的，因爲流程化的過程中往往引入標準化模板，以便讓批准流程也標準起來。標準化的模板可能將批准者在審批過程中下意識地關注模板本身被填寫的完整性，而非模板中的內容。而填寫者在填寫模板的時候，也容易下意識地關注模板本身的完成情況而不是問題被揭示的程度。
讓評審者成爲責任人。評審者對方案的成敗負有一定的職業風險，有助於評審者建立對評審工作的責任心和榮譽感，從而積極參與到對文檔內容的主動理解中來。
上一篇：工業物聯網：6 商業模式