❶ 軟考高級-信息系統項目管理師怎麼備考
1、對知識點進行梳理：對於一些硬性記憶的內容沒什麼好說的，但除此之外，所有的知識點強烈建議應該進行梳理，盡可能將知識點貫穿起來，同時需要與曾經做過的項目進行結合，甚至可以用新的知識點來分析曾經的項目，將知識可以活用起來這是最終目標，而且一定要掌握分析方法。
2、多看試題分析，理解為什麼會是這樣的答案。注重分析過程，不要太過注重結果，當然，那些死記硬背的題目無需這樣考慮，希賽的在線真題測試不錯。如果具備相關的工作經驗，在此會對你有莫大的幫助，但也會帶來一定負面作用，因為你的經驗未必正確。
3、軟體行業中有很多內容是很難衡量對錯的，在工作中有時候經驗比知識更重要，但考試的時候知識就比經驗重要了，綜合知識中會出現一類題型，介於經驗和知識之間模稜兩可的，此時肯定是以考試為主，這類題型一定要注意，甚至有可能出現各個不同版本的答案。對於此類題目沒有什麼好的建議，只能說多看以前的試題吧，會有所幫助的。但有時候真的不明白，為什麼這種模稜兩可或者說沒有唯一答案的題總是出個不停，難道是為了卡過線人數?
4、多看看網上的實際案例分析，多從不同角度或角色來分析一個項目，如果已經具備了多年的項目管理經驗，那就和項目管理知識點結合起來重新對案例進行分析，如果缺少項目管理經驗，那就多思考一下為什麼別人會給出這樣的建議，基點是什麼?重點在哪裡?依據是什麼?解決的問題在哪裡?多問問為什麼。
❷ 如何快速處理大量信息，你需要做好這5件事！
我們來看一個場景：
項目需要，需要臨時快速選擇成員組成一個團隊，針對客戶需求，1天時間內給出一個方案建議。部門中有這么3個人供選擇。第一個人，工作經驗豐富，做過很多項目；第二個人，擅長文案編輯工作，能夠拿出漂亮的文檔或PPT；第三個人，梳理和掌握信息能力強，能快速吸收大量信息並能現學現用。如果從這三個人中選擇成員，哪個人的機會最大？
毫無疑問，能夠快速掌握和處理各種信息的人，即第三個人能夠獲得這個機會。因為這類人對信息的消化吸收能力強，他可以快速掌握客戶所在行業情況、客戶企業本身情況以及需求和目標。只有掌握了這些前提信息，才能夠「對症下葯」，提出滿足客戶需求的方案或建議。
由此可見，有高水平的信息處理能力多麼重要，它可以為我們爭取更多的機會。如今我們面對怎樣的信息環境？哪些因素會影響我們處理信息效率？我們又該怎樣提高我們的信息處理能力？
信息超載現象
不管是企業還是個人，現如今都面臨信息超載問題，即需要處理的信息超過我們的信息加工能力。如何高效快速處理大量的信息，從中找出對自己有效的信息是一個挑戰。企業為了解決這個問題，使用大數據分析，使用人工智慧，搭建數據中台。其出發點就在於存儲、收集和分析數據，並提取有效的信息供業務決策。那麼，我們個人該如何應對信息超載現象呢？
你是否經歷過這些情況？早上到辦公室打開郵箱，一堆未讀郵件需要處理？工作上有一堆資料需要閱讀？微信群有幾百條未讀信息？想入手一瓶防曬或精華，在考慮選哪個牌子時，網路搜索出來大量信息？不管你在電梯、樓道還是商場，也被各種信息所包圍？
「當信息量過多以至於個體無法對全部信息進行處理分類和利用時，會發生什麼情況？他們會篩選、忽略、跳過或忘記信息。或者他們會暫停更深入的處理，直到信息超載情況結束」。
在信息泛濫的時代，我們該如何快速處理、有效利用各種信息？首先，我們需要了解一下在信息超載的情況下，有哪些因素會影響我們如何處理信息。
影響因素
興趣 。大量的信息中，唯一能讓個體產生積極、興奮的情緒恐怕就是與個體興趣相符合的信息了。這類信息再多，對信息處理者來說都不是難題。
先驗知識 ，是指個體對某一主題或領域有經驗或了解。與個體先驗知識相關的信息，對處理者而言，會比較簡單輕松，他可以套用或改進以往的處理方法，不需要過多的思考。
信息的特點 。信息以什麼渠道、什麼樣的方式呈現在個體的面前會有影響。單渠道還是多渠道、是文字、圖片、視頻還是聲音的形式展現，對信息處理者來說，意味著不同的處理難度和不同的精力投入。
情緒 。人們處於積極的情緒下，對信息的解讀會更自信，速度也更高；而在消極的情緒下，信息處理效率低。
語言 。「即便以同一種語言進行溝通，同樣的詞彙對不同的人來說意義也會不同。年齡和情境是導致這種差異的兩個最顯著的因素」。呈現在個體面前的信息，不表示都是個體所能理解的，比如一個英語背景的人，他很難看懂和理解一篇病毒學分析的文章，以及一個初入社會的年輕人，他很難懂得年長者的老生常談。
在眾多的信息中，我們不能只處理自己感興趣、自己看得懂或者處理起來容易的信息。而是過濾無效的信息，利用有效的信息。那麼我們該如何做呢？
快速處理信息秘訣
1、逐步建立「信息處理系統」。 這類處理方法主要針對復雜的問題。想像你購買房子或是選擇一份工作。當你開始處理這類問題時，大量的信息朝你涌來。在做決策之前，我們肯定要明確自己的需求，然後收集和分析外界信息，看自己的需求是否得到匹配。這時候可能會有多個備選方案，然後我們需要制定評分標准，並對不同的候選方案進行評價，最後選擇一個對自己來說綜合效益最大的那個方案。
這里涉及到明確需求→外界信息分析→需求匹配→制定方案→方案分析→方案選擇，到最後實施這幾個步驟。
我們在應用信息解決問題的過程中，應該有意識地建立這樣完善的系統。以後凡是復雜的問題，能夠自動啟發系統運行，按照該步驟執行。
建立「信息處理系統」，需要做到以下幾點：
1）更好地認識自己。認識清楚自己，你可以更快地著手處理信息，而不是通過搜索大量的信息，來發現和啟發自己。
2）積累可靠的信息處理渠道，比如可靠的房源發布渠道是哪裡，可靠的招聘渠道是哪裡，這有助於你找到高質量的信息，過濾掉虛假和低質量的信息。
3）培養做決策以及提高執行力。
2、儲備經驗知識庫 。每個人都有不同的經歷和認知，過去的經歷會造就未來的我們。有些事情會重復發生多次，有些事情的處理方法在其他地方同樣適用。因此，生活工作中，學會總結經驗和反思教訓，積累自己的經驗知識。當以後遇到同類的信息時，我們就可以自動處理一些信息，而不用投入太多時間和精力。
3、減少和科技產品的聯系 。過於依賴手機，ipad和電腦等科技產品，會讓我們總是被雜、散和亂的數字信息所打擾。減少與科技產品的聯系，可以讓我們過濾掉很多沒有意義的信息。
4、避免在情緒不高的時候處理信息。 人在情緒低落的的時候，對信息的理解可能出現偏差、遺漏和過濾 。
5、給自己休息時間 。提高信息處理速度和效率不是埋頭整理，也需要給自己休息的時間。我們需要從信息的海洋里抽出來，讓自己休息。這樣有利於從大局上對信息進行認識，分清主次。
總結
信息超載的情況在所難免。理解影響我們處理信息的因素，然後找到相應的解決辦法才是正確的應對方法。逐步建立自己的「信息系統」，幫助我們處理復雜問題；建立自己的經驗知識庫，提高「自動處理」信息的能力；減少與科技的聯系，避免不斷被數字信息叨擾；在情緒好的時候處理信息，以及不要埋頭在信息的海洋里，要給自己休息的時間。
❸ 在高級產品經理眼裡，產品架構是怎樣的
一般來說，搭建產品架構這件事情，只有少數的高級PM才能勝任，絕大多數剛入門的產品經理或產品專員，還涉及不到任務這么艱巨的工作（簡單的產品功能結構不算）。
經歷過需求的採集、分析和篩選，我們對產品的定位和用戶的需求有了越來越深刻的認識，對整個產品方向的把控和版本迭代節奏也會更有感覺。這種感覺你也可以稱之為「產品感」，雖然講得有點懸乎，可又的確存在。以我個人的經驗來看，不斷地了解用戶需求和場景，也是積累產品感的一種良好的方式。有了不錯的產品感，我們要繼續往前走，才能將產品推向一個更高的高度。
產品經理之前已經將產品第一個版本的功能需求都整理好了，也輸出了一份詳細的功能需求列表，這個時候要做的工作就是為產品搭建一個好的架構，也就是產品設計的第三個環節——搭框架了。任何一款互聯網產品都應該有一個產品架構，有了這個強大而堅實的架構作為產品的基礎，我們才能將產品需求給一個一個填充進去，讓產品變的豐富立體，更有血有肉起來。
那究竟什麼是產品架構，產品經理又該如何態純塌來搭建一套好的產品架構，我們來接著往下看。
什麼是產品架構
任何一個產品都有自己的產品架構（也有很多人把它稱為信息架構），就好比每一個人都有自己的骨骼系統一樣，你的骨架大小決定了你大致的身材會是如何，每個人的身材都不一樣，高、矮、胖、褲旦瘦各有不同。
有些產品的產品架構比較繁雜，例如大部分to b 的產品，如客戶關系管理系統、ERP軟體、電商網站的管理後台、物流管理後台、SaaS軟體等；有些架構則比較輕便、簡單，比如絕大多數的to c 的產品，像我最近在玩的圖友、摩拜單車、直播APP映客、花椒等，當然還包括微信（雖說現在功能越來越多了，但大體架構依然是簡單、清晰明了的）。
我們直接看幾個例子：
天貓商家工作後台
這是天貓商家的工作後台，看到左側這一排滿滿的導航菜單了嗎，是不是感覺超級復雜，光店鋪管理就有超過10個二級菜單，要梳理好淘寶、天貓這種量級的電商平台產品架構可真不是一件簡單的事。不過我也常常好奇一點，這么復雜的後台，賣家們都能清楚地知道每一個功能在哪裡么。
復雜架構的產品，對產品經理的能力要求較高，需要產品經理能提供功能完備、結構嚴謹的架構系統，讓用戶能通過操作流程來使用各個功能。所以這樣一個架構的特點是，它會帶來一定的學習成本，有些甚至需要對產品的用戶進行培訓（像淘寶開設了淘寶大學以及淘寶社區）。這種架構產品的用戶群體一般比較聚焦，只針對某一類人群，需要對海量功能進行合理整合、靈活布局來聚焦核心用戶場景。
臉萌官網
再來看一個例子，這是曾經爆紅一時的臉萌app的產品官網，仔細分析一下這個官網的產品架構，是不是超級簡單，簡單到只剩下2個菜單——首頁、關於我們。這里要注意一點，即使是簡單的2個菜單（有些官網只有一個菜單），也依帆圓然構成了完整的用戶體驗，因為通過這個架構，網站的目標和用戶的需求都已經得到了充分的滿足。當然，如果你想要重新定義網站的目標，或是用戶的需求發生了變化，那你就該去准備重新調整產品架構了。
輕架構的產品，它的目標就是提供給用戶一個簡單明了的信息架構，讓用戶使用方便、體驗流暢。對於產品經理來說，設計輕架構的產品，難點在於體驗和創新。我們可以通過給產品做減法來不斷聚焦用戶的核心使用場景，讓用戶簡單易上手，等產品的用戶體量上升到一個新的台階的時候，再去拓展產品的使用場景，延展產品架構。
典型的幾個產品架構模型
Jesse James Garrett在《用戶體驗要素》這本書中，為我們系統闡述了互聯網產品的幾個典型的產品信息架構模型。第一種信息架構模型比較符合我們產品經理對產品架構的理解和定位，後面三種信息架構模型，你可以當作是第一種模型的補充，或者你也可以把它當作頁面級別的信息架構梳理。
第一種，層級結構（hierarchical structure）
層級結構模型
書中原文是這么來描述這種產品架構的——「在層級結構中，節點與其他相關節點之間存在父級/子級的關系。子節點代表著更狹義的概念，從屬於代表著更廣義類別的父節點。不是每個節點都有子節點，但是每個節點都有一個父節點，一直往上直到整個結構的父節點。層級關系的概念對於用戶來說非常容易理解，同時軟體也是傾向於層級的工作方式，因此這種類型的結構是最常見的。」
這種傘狀式的產品架構，恐怕是互聯網、移動互聯網產品中使用最多的一種信息結構，比如我們使用頻度最高的微信、手q，以及各類to c 的移動APP，甚至是復雜的to b 類產品，都是使用這種產品架構進行產品設計。這種架構的特點是符合人類的認知習慣，因為人類天生就有分類的習慣，比如書桌，我們會習慣把書籍放在一起，把錄音卡帶等放到一邊；又比如我們的衣櫃，我們一半會將不同季節的衣服放在不同的位置。在生活中，整理物品是為了更容易地找到自己需要的東西。
下圖是蜻蜓fm早期版本的一個層級信息架構：
蜻蜓fm的產品信息架構
在使用層級結構的時候，需要注意層級的深淺和寬窄這個問題。
大家都有過逛商場的經驗，其實有時候做產品和逛商場很相似，有的商場設計的比較合理，很容易地能夠讓逛商場的用戶找到想要的商品品類，有的商場設計卻經常讓你迷路，來來回回折騰好幾次。在確定產品架構的時候，考慮產品架構的深度和廣度成為了產品經理的一道必選題，就拿淘寶APP和唯品會APP來說，淘寶屬於廣而深的架構，唯品會則屬於淺而窄的架構（相對）。在偏深度的架構中，用戶操作起來效率不高，用戶獲取信息、完成目標任務的路徑增多，但是相對而言，減少了用戶選擇的入口。在偏廣度的架構中，用戶面對的入口增多，在選擇入口的時候比較費時，但是減少了用戶的操作路徑。
廣度和深度的架構模式
寬而淺的產品架構和窄而深的產品架構，各有優勢和劣勢，具體使用哪一種產品架構，關鍵是要結合自身產品的定位、業務特性、發展階段和用戶特徵及使用場景來進行取捨和判斷。
第二種，自然結構（organic structures）
自然結構模型
原文描述如下——「自然結構不會遵循任何一致的模式。節點是逐一被連接起來的，同時這種結構沒有太強烈的分類概念。自然結構對於探索一系列關系不明確或一直在演變的主題是很合適的。但是自然結構沒有給用戶提供一個清晰的指示，從而讓用戶能感覺他們在結構中的哪個部分。如果你想要鼓勵自由探險的感覺，比如某些娛樂或教育網站，那自然結構可能會是個好的選擇；但是，如果你的用戶下次還需要依靠同樣的路徑，去找到同樣的內容，那麼這種結構就可能會把用戶的經歷變成一次挑戰。」
事實上，這種形態的產品架構一般在to c 的游戲、娛樂、資訊產品裡面運用的比較廣泛，例如優酷視頻、好奇心日報等。當然，很多時候自然結構是應該結合層級結構來進行思考的，比如用戶進入好奇心日報這個網站，可能的一種使用方式是，用戶心裡已經有一個明確的資訊目標，想看一下最近商業有發什麼大故事，所以用戶會點擊上方的「全部分類」，選擇電影，選擇商業板塊然後進行瀏覽。也有另一種使用方式，就是毫無目標，直接就是這么從上到下瀏覽下去，看到自己感興趣的文章標題便點擊進去。
好奇心日報官網
自然結構很適合輕架構產品的瀏覽式形式，尤其比較適合to c 類的娛樂休閑類產品，因為這類產品的目標用戶，絕大多數時候的使用場景都是無聊式地瀏覽，並沒有明確的用戶目標，也不需要解決什麼特定的任務。
第三種，線性結構（sequential structures）
依舊來看下原文描述——「線性結構來自於你最熟悉的線下媒體。連貫的語言流程是最基本的信息結構類型，而且處理它的裝置早已被深深地植入我們的大腦中了。書、文章、音像和錄像全部都被設計成一種線性的體驗。在互聯網中線性結構經常被用於小規模的結構，例如單篇的文章或單個專題；大規模的線性結構則被用於限制那些需要呈現的內容順序對於符合用戶需求非常關鍵的應用程序，比如教學資料。」
說的直白一點，所謂線性結構，就是你用一個講述故事的方式去給用戶介紹你的產品，多見於產品專題頁、幫助文檔的設計。其實這部分也沒什麼可講的，關鍵是講述故事或者問題的時候，你的思路是否清晰，很多時候這部分工作也會由運營的同事替我們代勞。
金山快盤專題頁
上圖就是金山快盤做的一個活動專題頁，通過線性結構講故事的方式來將自己「100G空間永久免費」的活動宣傳出去。
第四種，矩陣結構（matrix structure）
矩陣結構模型
書中是這么描述矩陣結構的：「矩陣結構允許用戶在節點與節點之間沿著兩個或更多的「維度」移動。由於每一個用戶的需求都可以和矩陣中的一個「軸」聯系在一起，因此矩陣結構通常能幫助那些「帶著不同需求而來」的用戶，使他們能在相同內容中尋找各自想要的東西。
舉個例子來說，如果你的某些用戶確實很想通過顏色來瀏覽產品，而其他人偏偏希望能通過產品的尺寸來瀏覽，那麼矩陣結構就可以同時容納這兩種不同的用戶。然而，如果你期望用戶把這個當成主要的導航工具，那麼超過三個維度的矩陣可能就會出現問題。在四個或更多維度的空間下，人腦基本上不可能很好地可視化這些移動。」
看了上面這段話，你的第一反應是不是想到了下面這個產品設計界面：
淘寶的寶貝詳情頁
矩陣式的信息結構，需要將多種信息內容放置在一個頁面里，所以它的重點和難點是在於如何做好信息分層，讓信息更加有效率地傳達給自己的目標用戶，這個問題我們放在後面來講。
總體來說，產品經理了解這幾個典型的產品信息架構模型，對於後期自己設計產品架構的時候，會更加明確應該朝哪個方向進行努力。這就好比一個建築師在設計房屋之前，都需要先有足夠的建築設計知識，其中搭建建築物的框架便是其中少不了的重要一課。
在具體的工作場景中，大多數產品經理從事的工作基本會分為兩個大類，一類是C端產品經理，負責和普通用戶打交道，更考驗對用戶痛點和興奮點的把握和拿捏；另一類則是B端產品經理，負責和企業用戶打交道，更考驗對業務本質和行業戰略的思考。那麼，具體這兩種類型的產品該如何來搭建產品架構呢？
To C 類的產品如何搭建產品架構
先簡單介紹下業務背景：
2014年開始變熱的O2O行業，已經迅速從表層變革進入深水區，很多O2O相關商業模式被驗證錯誤或者迅速發展壯大，這個過程無數創業公司創立和倒下。除了商場、吃喝玩樂商戶、線下服務商戶等成為O2O熱點之外，到家模式也成為一個新熱點，美甲的、按摩的、泡腳的手藝人很多都變成了流動作業（典型如河狸家），如果說吃喝玩樂等希望輻射的是商圈流量，那到家服務無非希望搞定社區這塊「富礦」。
15年初，當時我所在的公司正好也看中社區O2O這個行業（當然是老闆有相關資源，又覺得市場前景廣闊），而做社區O2O，有個繞不開的門檻——物業，如果有誰願意費力氣去啃物業這塊兒硬骨頭，就能有機會贏得未來。
於是我們就組建了一個小團隊，先去做了一番市場調研，看一下市面上的這些社區O2O產品都做了哪些連接社區居民的服務，得出了這么一份競品分析報告：
競品分析報告
把玩了幾十款APP後，我們發現只有少數幾家公司的產品做了向業主提供在線支付物業費、停車費的服務，更別談業主可以在線報修，呼叫安保等服務。
總的來說，當時的社區O2O還不算是一片紅海，仍然有市場空間和機會進行切入。以產品的開發背景來說無非是兩類APP，一類是「叮咚小區」「小區無憂」為代表的第三方創業公司，一類便是開發商自有的「住這兒」「彩之雲」等移動端應用。
第一類像「叮咚小區」這種平台模式，沒有用戶基礎，只靠燒投資人的錢來鋪地面工作，當時來看是圈了不少小區，但是由於沒有根基，用戶隨時會被搶走，想要做到成規模的應用不知道要燒多少年。目前傳聞好像已經倒閉了，估計資本的錢也燒的差不多了吧。
第二類應用大都停留在試水階段，扮演配合物業的角色，還沒找到完整的盈利模式。「彩之雲」可以算得上其中的優秀代表了，其垂直電商模式或許可以成為一個突破口，同阿里爭奪「最後一公里」。
而當時的BAT等巨頭還都持觀望態度，沒有太大動作，又或者是等待哪一家創業公司做起來之後再進行投資收購。很明顯，大家都把這塊難啃的骨頭放在了一邊。
由於當時公司在房地產物業這塊有相關資源，所以，我們團隊將產品的切入點定位在了物業公司，物業服務站和物業從業人員這里。而後，通過相關小區的試點，驗證產品可行性後，再將產品的使用場景拓展到進行車位信息化管理、社區商戶平台——商戶通過物業平台入駐小區並投放廣告、為成熟的業委會提供在線管理平台、社區教育等等。當時，產品的名字暫時就命名為「樂業安居」，正有讓社區的老百姓擁有了我們的產品，就能安居樂業的意思。
經過一系列的產品設計准備工作，就要開始搭建APP的產品架構了。結合之前的市場調研及產品路徑規劃，以及團隊對O2O的理解，梳理了一下我對社區O2O產品架構的規劃思考，主要由4個tab組成：
社區：負責連接人與人，這個部分可以滿足鄰里之間人與人的交流溝通，你既可以在這里發布相關信息尋求幫助或需求交換，也可以在這里找到志趣相投的鄰居一起去做一件事情。包括後期的業委會、居委會等等，都可以在這里展示相關信息。
物業：負責連接人與物業，這個部分就是通過移動互聯網來改善業主和物業的連接效率，讓物業的服務成本降低，效率提高，也提升業主的用戶滿意度。
周邊：負責連接人與O2O服務，這個部分就是第三方O2O（如家政服務、維修服務、養老服務、社區教育等）、電商團購的綜合展示舞台，通過整合資源可實現有自己特色的O2O社區服務。
我的：負責管理與」業主「有關的所有信息，如」我的報修「、」我的繳費「、若後面產品拓展做了社區教育，則還可能有」我的課程「等等。
社區o2o的產品架構
當然，第一個產品版本的開發，打算就先做2個部分——」物業「和」我的「，既然是從物業作為切入點，就先把這個點做好，後期在相關小區試點可行後，立即迭代產品，再引入其他功能讓產品的使用場景變得更加豐富起來。
如果你仔細分析，應該可以看出這裡面的框架邏輯——連接。
這里就涉及到對O2O最本質的理解，它的本質是什麼？O2O本質其實就是用互聯網去改善消費者和服務提供者的連接，讓他們之間的連接變得效率更高、成本更低。所以整個產品架構都是圍繞著連接去做的功課，連接人與人，人與物業服務、人與其他服務，這樣對於用戶來說，他們對你產品的認知邏輯就會非常清晰，每一次打開產品的時候，都能夠輕松地找到自己想要的東西。
就這個案例，我們嘗試著來做一點總結：
1. 做好分類
前面我們就已經說過一點，人類天生就有分類整理的習慣，有這個習慣也是為了更方便地找到自己所需要的東西。超市裡的商品擺放也是如此，所有的商品需要按照不同的分類，擺放在不同的貨架上，並且上面還要貼上相應的指示牌，告訴用戶這是什麼商品區域。
我們常用的Windows 資源管理器也是一個極佳的例子，試想一下：如果我們將自己電腦上的所有文檔都歸存在一個盤里，而且這個盤並沒有文件夾的形式讓你分類管理你的文件，word文檔、excle文檔、ppt文檔、pdf文檔、視頻文件、圖片格式文件等都混雜在一起，那你想要找到自己需要的文檔也則太難了。幸好在Windows 資源管理器模式下，我們可以創建文件夾，並且可以按照文件的名稱、修改日期、類型、大小等進行排序和分組，這樣才方便了我們更加快捷地找到自己所需的信息和文檔。
同理，網站或者移動APP應用也是如此，信息越多，就越需要組織和整理。我們可以根據邏輯習慣來對信息進行分類整理，如上面所舉的例子，就是根據社區O2O「連接」的邏輯進行分類的；當然，也可以直接去探究用戶的想法，了解用戶的使用習慣。一個好的產品經理，往往也是這個行業的資深人士，或者稱為行業專家。因為只有產品經理自己本身對所處行業有極深的理解，他才能更准確地命中產品架構的脈門，有時候甚至是一擊而中。
2. 平衡用戶與商業
對產品架構的設計，一方面是要了解用戶的信息需求，另一方面也要了解整個產品的商業目的和訴求。一般情況下，用戶目標和商業目標之間肯定存在著矛盾，比如用戶都不想看廣告，但企業又希望能夠把自己的業務和廣告推薦給用戶（典型如微信的朋友圈廣告）。如果一個產品只滿足用戶的目標，產品體驗當然會不錯，但這個產品也很難走的長遠，畢竟企業的終極目標是要盈利的。
這個時候，如何平衡用戶與商業，就成為考量產品經理的功底的重要一環了。在這方面，我們向微信團隊進行學習，微信在平衡用戶體驗和商業目標這一塊做的非常好。還記得2015年1月份的朋友圈廣告么，當時一經推出，便立刻成為了朋友圈的熱門話題，大家都爭相在廣告底部進行點贊和評論，彷彿品牌一下子就成為了我們身邊的朋友一樣，在朋友圈直接與我們分享故事和內容。而在社區O2O這個案例中，我們也將周邊這種帶有業務、廣告性質的功能，放在了後面的版本進行迭代開發，並沒有立即嘗試進行產品的商業化，這也是一種平衡的體現。
微信廣告
3. 重要的功能設置快捷入口
產品架構應該是結構清晰、合乎邏輯的，讓有明確目標的用戶能夠快速找到所需信息；有不確定目標的用戶，通過瀏覽和尋找，一點點地明確自己需要的信息；沒有目標的用戶，則可以在探索中激發需求。所以，對於後兩者用戶來說，如果重要功能和常用功能隱藏地太深，則很有可能會讓他們對產品喪失興趣。
為重要功能和常用功能設置快捷入口，就好比在原有的產品架構上搭了一個「快捷通道」，典型如微信將「購物」放在了「發現」這個菜單里，手Q的「購物」入口改成了「京東購物」，京東和騰訊的「聯姻」，由微信和手機QQ社交應用入口、朋友圈、朋友群、公眾號、廣點通，以及線下推廣共同組成了多場景的京東社交購物生態，匯聚了龐大的社群流量，為京東帶來了不少的新用戶和成交增長。
當然，快捷入口的設置也是一個需要權衡的過程。必要的快捷入口可以提高用戶的使用效率，也能滿足產品一定的商業目標，但是如果快捷入口過多（尤其是參雜太多商業目標的快捷入口），產品也會變得混亂和復雜，這個時候就會讓用戶的使用效率下降，有點得不償失了。所以你會看到，微信這款產品，並沒有把所有的業務都通過快捷入口的方式展現出來，而是通過在「我－－錢包」裡面，展示其他的第三方服務。這么一來，這些功能隱藏地如此之深，產品的用戶就不會覺得微信是一款復雜而混亂的產品了。
京東微信手機QQ購物兩周年慶典
當然，在業余時間我們自己把玩產品的時候，也可以試著去解構一下其他公司的APP產品，看下他們的產品架構是如何搭建的，又有什麼地方是值得學習和借鑒的，這也是一個非常重要的學習手段。
說一下我常用的方法，分三步來走：
拆解產品骨架，將所有模塊和功能點畫成思維導圖
分析重點功能的使用場景與流程
分析次要功能的使用場景與流程
當然，分析產品的時候需要考慮很多因素，不僅是從產品設計出發，還要從行業背景、公司戰略、運營、實際資源等情況出發，才能得出更接近真相的答案。
To B 類產品如何搭建產品架構
To B類產品（通常都是後台產品）的設計非常具有挑戰性，因為To C類的前台產品，大家都已經培養起了使用習慣，對功能有一定程度的理解，見過的模式足夠多，能夠建立起一定的產品模型，也容易找到參照物去模仿。但是To B類的後台產品，你幾乎沒有什麼競品可以參照和模仿，所以在搭建產品架構的時候則要求產品經理非常懂業務，非常考驗PM的核心競爭力——業務知識儲備、結構化思維和系統性抽象能力。不同行業的產品可能做整體架構的思路也不一樣。
稍微簡單類比一下，產品架構復雜程度的感覺由弱到強是這樣的——
設計或者操控以下交通工具：
自行車
汽車
飛機
火箭
宇宙飛船
……
是不是感覺到難度越來越大了，不過我們也算是了解了復雜產品的架構是怎麼樣的了，其實依然還是有對應的方法去進行設計的。在對後台產品搭建產品架構的時候，往往有兩種思路可供參考：
1.按功能模塊來進行劃分
什麼叫按功能模塊來進行劃分？如下圖：
按功能模塊來劃分
如果一個後台產品的目標用戶比較單一，且用戶需求也比較統一，並沒有出現說某個用戶只需要使用其中某一個功能模塊的時候，且功能和功能之間並沒有太多的邏輯關系，往往可以嘗試使用按功能模塊來進行劃分的方式。比如網路移動統計，它的目標用戶就是互聯網公司內部的運營人員、產品人員，且運營和產品關注的數據絕大部分是可以通用的，也就是說用戶需求還是比較統一的。
2.按業務邏輯來進行劃分
另一個劃分邏輯，是按業務邏輯來進行劃分。很多公司內部的信息管理系統，都是採用這種產品架構來進行設計的，因為這個產品的目標用戶往往涉及到多方角色，既有公司的業務人員，如市場、銷售、客服、前台等，又有公司的職能部門人員，如人事、財務、行政等。這個時候再採用功能模塊來進行後台的產品架構梳理，則顯得不是那麼適用了。
按業務邏輯來進行劃分，則要求產品經理在規劃系統時要思考這個系統的作用到底是解決了什麼問題，再具體一點就是——解決了哪些用戶的哪些問題。在這個大的環境下確定了之後，在需求的收集和分析的階段，就應該按照業務角色來進行相關的工作，而後到了梳理產品架構這一步才能更得心應手一些。如下圖所示，一個研發管理的子系統，就對應了這么多不同角色人員的不同需求。
按業務邏輯來劃分
那麼，產品經理在做to b產品的時候，進行業務規劃和產品架構之前需要儲備哪些方面的能力呢？
需要有一定的技術理解能力，幫助自己理解清楚信息在不同的系統之間是怎樣交換、存儲、耦合和解耦的。
要有基本的商業邏輯思維，比如節省成本、提高營收、提升效率等。
業務的整合需要對所在行業及業務本身有深刻的理解，同時對公司整體的運行邏輯也要有一定的認識，如銷售、市場、財務、運營、產品、技術等。
需要有更強的抽象能力。不僅是把一個工作流程抽象成一個功能，而是要把一個業務抽象成一個系統，並且知道這個系統在產品中所處的位置；不是理清任務與任務之間的關系，而是要清楚業務與業務之間的關系，這樣的關系最後是如何交織和演化在一起，共同促進產品繁榮的。
最後，這里提供幾個優秀的後台產品供大家參考和研習：
淘寶的商家後台
有贊微商城的後台
微信公眾平台後台
總結來說，產品架構這件事情涉及的面非常廣，上至產品的宏觀計劃，下至產品的功能模塊，囊括產品的目標及願景、用戶需求、商業需求、數據業務流程和設計框架，還涉及到產品的生態結構，所以要搭建好一套產品框架並不是件易事。產品經理在這條道路的學習上，也要做好一個漫長的認知迭代准備。
好的產品架構具有怎樣的特性
好的產品架構對於一個產品來說是非常重要的一件事情，就如同人的骨架之於人，房屋的框架之於房屋，是起到支撐、引導、承重的作用。說回到互聯網產品，好的產品架構要具備的幾個特徵，總結起來大致是這么幾個點：易用性、穩定性、可擴展性。
什麼是易用性呢？人的天性是懶惰的，試想如果用戶在一次簡單的使用產品後能記住每一個操作，而且能重復使用，不用刻意學習具體的操作，使用起來一定是很「爽」的。對於產品經理來說，我們必須竭力讓用戶能夠方便地使用產品，這就需要產品架構上能夠提供一個清晰的路徑導航，讓用戶不會產生迷路等不爽的用戶行為了。
什麼是穩定性呢？這部分又通常和後台的技術架構有所關聯，當產品不斷演進和迭代的時候，系統的架構是否能夠承受那麼多用戶的同時訪問，在性能和響應速度方面有沒有什麼影響。所謂的穩定性原則，就是說你提供的服務一定是穩定可靠的，是能及時響應需求的，盡量避免類似APP上突然有提示失敗、伺服器異常、空等情況。
易用性和穩定性，就不再多用文字解釋了，我們來看看產品架構的可擴展性。
可擴展性其實是在傳達一個信息，就是要求產品經理在設計產品架構的時候，就要去多思考未來這個產品是否會新增加功能或者內容，也就要求產品經理要有產品規劃的意識。如果一個新做的產品剛上線沒多久，因為要新增功能，導致頁面的信息架構重新調整，相關人員怨聲載道，產品的使用用戶也會增加對產品的認知成本。可見，產品架構的可擴展性是有多重要，產品經理需要根據實際情況及未來可預見的規劃進行構思，爭取將產品的維護成本降到最低。
❹ 如何梳理復雜系統的用戶需求
1.概念 需求的定義包括從用戶角度(系統的外部行為),以及從開發者角度(一些內部特性)來闡述需求. 關鍵的問題是一定要編寫需求文檔.我曾經目睹過一個項目中途更換了所有的開發者,客戶被迫與新的需求分析者坐到一起.系統的分析人員說:"我們想與你談談你的需求."客戶的第一反應便是:"我已經將我的要求都告訴你們前任了,現在我要的就是給我編一個系統". 百事通 而實際上,UGGs,需求並未編寫成文檔,因此新的分析人員不得不從頭做起.所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話,你就確信你已明白用戶的需求,那完全是自欺欺人. 需求的另外一種定義認為需求是"用戶所需要的並能觸發一個程序或系統開發工作的說明".有些需求分析專家拓展了這個概念:"從系統外部能發現系統所具有的滿足於用戶的特點、功能及屬性等".這些定義強調的是產品是什麼樣的,而並非產品是怎樣設計、構造的.而下面的定義則從用戶需要進一步轉移到了系統特性: 需求是指明必須實現什麼的規格說明.它描述了系統的行為、特性或屬性,是在開發過程中對系統的約束. 從上面這些不同形式的定義不難發現:並沒有一個清晰、毫無二義性的"需求"術語存在,真正的"需求"實際上在人們的腦海中,這個人們主要是指客戶,但一般情況下,用戶並不能描述自己的需要,只就需要系統分析人員根據用戶的自己語言的描述整理出相關的需要再進一步和客戶核對.系統分析員和客戶需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務必達成共識. 任何文檔形式的需求(例如如下將要描述的需求規格說明書)僅是一個模型,一種描述. 2.需求分析的任務 開發軟體系統最為困難的部分就是准確說明開發什麼.最為困難的概念性工作便是編寫出詳細技術需求,這包括所有面向用戶、面向機器和其它軟體系統的介面.同時這也是一旦做錯,將最終會給系統帶來極大損害的部分,並且以後再對它進行修改也極為困難. 目前,國內產品的龐雜,一家企業可能有幾個系統並立運行,它們之間介面是系統開發人員最頭痛的問題. 對於商業最終用戶應用程序,企業信息系統和軟體作為一個大系統的一部分的產品是顯而易見的.但是對於我們開發人員來說,並沒有編寫出客戶認可的需求文檔,我們如何知道項目於何時結束?而如果我們不知道什麼對客戶來說是重要的,那我們又如何能使客戶感到滿意呢? 然而,即便並非出於商業目的的軟體需求也是必須的.例如庫、組件和工具這些供開發小組內部使用的軟體.當然你可能偶爾勿需文檔說明就能與其他人意見較為一致,但更常見的是出現重復返工這種不可避免的後果,而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價,這些血的教訓正在國內的軟體開發者身上發生. 近來,我遇到一個開發小組開發包括代碼編輯器在內的一套內部使用的計算機輔助軟體.不幸的是,當他們開發完這個工具後,發現這個工具不能列印出源代碼文件,使用者當然希望有這個功能.結果這個小組只好手工抄寫源代碼文檔以供代碼檢查.這說明那怕需求明確無誤並構思准確,如果我們沒有編寫文檔,軟體達不到期望目標也只能是咎由自取了. 相反的情況,我曾見一個要集成到"錯誤跟蹤系統"中的簡單界面寫了一頁需求說明.而操作系統系統管理員在為處理腳本時發現簡單的一張需求清單竟是如此有用.他們依據需求對系統進行測試時,此系統不僅非常清晰地實現了所有必需功能,而且未發現任何錯誤. 事實上,需求文檔在開發過程中一直起指導作用. 3.需求分析過程 可把整個軟體需求工程研究領域劃分為需求開發和需求管理兩部分更合適,如圖4-1所示: 圖4-1 需求工程域的層次分解示意圖 需求開發可進一步分為:問題獲取、分析、編寫規格說明和驗證四個階段.這些子項包括軟體類產品中需求收集、評價、編寫文檔等所有活動.需求開發活動包括以下幾個方面: 確定產品所期望的用戶類別. 獲取每個用戶類的需求. 了解實際用戶任務和目標以及這些任務所支持的業務需求. 分析源於用戶的信息以區別用戶任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息. 將系統級的需求分為幾個子系統,並將需求中的一部份分配給軟體組件. 了解相關質量屬性的重要性. 商討實施優先順序的劃分. 將所收集的用戶需求編寫成文檔和模型. 評審需求規格說明,確保對用戶需求達到共同的理解與認識,並在整個開發小組接受說明之前將問題都弄清楚. 需求管理需要"建立並維護在軟體工程中同客戶達成的合同" .這種合同都包含在編寫的需求文檔與模型中.客戶的接受僅是需求成功的一半,開發人員也必須能夠接受他們,並真正把需求應用到產品中.通常的需求管理活動包括: 定義需求基線(迅速制定需求文檔的主體). 評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它. 以一種可控制的方式將需求變更融入到項目中. 使當前的項目計劃與需求一致. 估計變更需求所產生影響並在此基礎上協商新的承諾,這種承諾具體體現在項目解決方案上. 讓每項需求都能與其對應的設計、源代碼和測試用例聯系起來以實現跟蹤. 在整個項目過程中跟蹤需求狀態及其變更情況. 以上幾點說明是我總結了成功實施項目後系統分析人員的經驗,同時也根據國內外的其他系統實施的相關成功經驗,進行了總結. 4.需求的類型 下面這些定義是需求工程領域中常見術語的定義. 軟體需求包括三個不同的層次:業務需求、用戶需求和功能需求(也包括非功能需求). 1.業務需求(business requirement)反映了組織機構或客戶對系統、產品高層次的目標要求,它們在項目視圖與范圍文檔中予以說明. 2.用戶需求(user requirement) 文檔描述了用戶使用產品必須要完成的任務,這在使用實例(use case)文檔或方案腳本說明中予以說明. 3.功能需求(functional requirement)定義了開發人員必須實現的軟體功能,使得用戶能完成他們的任務,從而滿足了業務需求. 在軟體需求規格說明書 (SRS)中說明的功能需求充分描述了軟體系統所應具有的外部行為.軟體需求規格說明在開發、測試、質量保證、項目管理以及相關項目功能中都起了重要的作用.對一個大型系統來說,軟體功能需求也許只是系統需求的一個子集,因為另外一些可能屬於子系統(或軟體部件). 作為功能需求的補充,軟體需求規格說明還應包括非功能需求,它描述了系統展現給用戶的行為和執行的操作等.它包括產品必須遵從的標准、規范和合約;外部界面的具體細節;性能要求;設計或實現的約束條件及質量屬性.所謂約束是指對開發人員在軟體產品設計和構造上的限制.質量屬性是通過多種角度對產品的特點進行描述,從而反映產品功能.多角度描述產品對用戶和開發人員都極為重要. 下面以一個字處理程序為例來說明需求的不同種類.業務需求可能是:"用戶能有效地糾正文檔中的拼寫錯誤",該產品的包裝盒封面上可能會標明這是個滿足業務需求的拼寫檢查器.而對應的用戶需求可能是"找出文檔中的拼寫錯誤並通過一個提供的替換項列表來供選擇替換拼錯的詞".同時,該拼寫檢查器還有許多功能需求,如找到並高亮度提示錯詞的操作;顯示提供替換詞的對話框以及實現整個文檔范圍的替換. 從以上定義可以發現,需求並未包括設計細節、實現細節、項目計劃信息或測試信息.需求與這些沒有關系,它關注的是充分說明你究竟想開發什麼.項目也有其它方面的需求,如開發環境需求或發布產品及移植到支撐環境的需求.盡管這些需求對項目成功也至關重要,但它們並非本書所要討論的. 5.需求分析的原則 不重視需求過程的項目隊伍將自食其果.需求工程中的缺陷將給項目成功帶來極大風險,這里的"成功"是指推出的產品能以合理的價格、及時地在功能、質量上完全滿足用戶的期望.下面將討論一些需求風險. 不適當的需求過程所引起的一些風險: 1. 無足夠用戶參與 客戶經常不明白為什麼收集需求和確保需求質量需花費那麼多功夫,開發人員可能也不重視用戶的參與.究其原因:一是因為開發人員感覺與用戶合作不如編寫代碼有意思;二是因為開發人員覺得已經明白用戶的需求了.在某些情況下,與實際使用產品的用戶直接接觸很困難,而客戶也不太明白自己的真正需求.但還是應讓具有代表性的用戶在項目早期直接參與到開發隊伍中,並一同經歷整個開發過程. 系統人員在實踐過程中,也有些感覺,在實施一家公司的項目時,若無足夠的用戶參與,系統人員獲得的需求是片面的,不完整的,這樣系統在需求之初就埋下風險. 2. 用戶需求的不斷增加 在開發中若不斷地補充需求,項目就越變越龐大以致超過其計劃及預算范圍.計劃並不總是與項目需求規模與復雜性、風險、開發生產率及需求變更實際情況相一致,這使得問題更難解決.實際上,問題根源在於用戶需求的改變和開發者對新需求所作的修改. 要想把需求變更范圍控制到最小,必須一開始就對項目視圖、范圍、目標、約束限制和成功標准給予明確說明,並將此說明作為評價需求變更和新特性的參照框架.說明中包括了對每種變更進行變更影響因素分析的變更控制過程,有助於所有風險承擔者明白業務決策的合理性,即為何進行某些變更,相應消耗的時間、資源或特性上的折中. 產品開發中不斷延續的變更會使其整體結構日漸紊亂,補丁代碼也使得整個程序難以理解和維護.插入補丁代碼使模塊違背強內聚、松耦合的設計原則,特別是如果項目配置管理工作不完善的話,收回變更和刪除特性會帶來問題.如果你盡早地區別這些可能帶來變更的特性,你就能開發一個更為健壯的結構,並能更好地適應它.這樣設計階段需求變更不會直接導致補丁代碼,同時也有利於減少因變更導致質量的下降. 3. 模稜兩可的需求 模稜兩可是需求規格說明中最為可怕的問題.它的一層含義是指諸多讀者對需求說明產生了不同的理解;另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明. 模稜兩可的需求會使不同的風險承擔者產生不同的期望,它會使開發人員為錯誤問題而浪費時間,並且使測試者與開發者所期望的不一致.一位系統測試人員曾告訴我,她所在的測試組經常對需求理解有誤,以致不得不重寫許多測試用例並重做許多測試. 處理模稜兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍.僅僅簡單瀏覽一下需求文檔是不能解決模稜兩可問題的.如果不同的評審者從不同的角度對需求說明給予解釋,但每個評審人員都真正了解需求文檔,這樣二義性就不會直到項目後期才被發現,那時再發現的話會使得更正代價很大. 4. 不必要的特性 "畫蛇添足"是指開發人員力圖增加一些"用戶欣賞"但需求規格說明中並未涉及的新功能.經常發生的情況是用戶並不認為這些功能性很有用,以致在其上耗費的努力"白搭"了.開發人員應當為客戶構思方案並為他們提供一些具有創新意識的思路,具體提供哪些功能要在客戶所需與開發人員在允許時限內的技術可行性之間求得平衡,開發人員應努力使功能簡單易用,而不要未經客戶同意,擅自脫離客戶要求,自作主張. 同樣,客戶有時也可能要求一些看上去很"酷",但缺乏實用價值的功能,而實現這些功能只能徒耗時間和成本.為了將"畫蛇添足"的危害盡量減小,應確信:你明白為什麼要包括這些功能,以及這些功能的"來龍去脈",這樣使得需求分析過程始終是注重那些能使用戶完成他們業務任務的核心功能. 5. 過於精簡的規格說明 有時,客戶並不明白需求分析有如此重要,於是只作一份簡略之至的規格說明,僅涉及了產品概念上的內容,然後讓開發人員在項目進展中去完善,結果很可能出現的是開發人員先建立產品的結構之後再完成需求說明.這種方法可能適合於尖端研究性的產品或需求本身就十分靈活的情況.但在大多數情況下,這會給開發人員帶來挫折(使他們在不正確的假設前提和極其有限的指導下工作),也會給客戶帶來煩惱(他們無法得到他們所設想的產品). 6. 忽略了用戶分類 大多數產品是由不同的人使用其不同的特性,使用頻繁程度也有所差異,使用者受教育程度和經驗水平也不盡相同.如果你不能在項目早期就針對所有這些主要用戶進行分類的話,必然導致有的用戶對產品感到失望.例如,菜單驅動操作對高級用戶太低效了,但含義不清的命令和快捷鍵又會使不熟練的用戶感到困難. 7. 不準確的計劃 據統計,導致需求過程中軟體成本估計極不準確的原因主要有以下五點:頻繁的需求變更、遺漏的需求、與用戶交流不夠、質量低下的需求規格說明和不完善的需求分析. 對不準確的要求所提問題的正確響應是"等我真正明白你的需求時,我就會來告訴你".基於不充分信息和未經深思的對需求不成熟的估計很容易為一些因素左右.要作出估計時,最好還是給出一個范圍.未經准備的估計通常是作為一種猜測給出的,聽者卻認為是一種承諾.因此我們要盡力給出可達到的目標並堅持完成它. 6.需求分析人員和用戶的合作關系 優秀的軟體產品是建立在優秀的需求基礎之上的.而高質量的需求來源於客戶與開發人員之間有效的交流與合作.通常,開發人員與客戶或客戶代理人,如市場人員間的關系反而會成為一種對立關系.雙方的管理者都只想自己的利益而擱置用戶提供的需求從而產生摩擦,在這種情況下,不會給雙方帶來一點益處. 只有當雙方參與者都明白要成功自己需要什麼,同時也應知道要成功合作方需要什麼時,才能建立起一種合作關系.由於項目壓力與日漸增,所有風險承擔者有著一個共同的目標這一點容易被遺忘.其實大家都想開發出一個既能實現商業價值,又能滿足用戶需要,還能使開發者感到滿足的優秀軟體產品. 軟體客戶需求權利書列出了十條關於客戶在項目需求工程實施中與分析人員、開發人員交流時的合法要求.每一項權利都對應著軟體開發人員、分析人員的義務.而軟體客戶需求義務書也列出了十條關於客戶在需求過程中應承擔的義務.如果願意,可以將其作為開發人員的權利書. 客戶有如下權利: 1:要求分析人員使用符合客戶語言習慣的表達 需求討論應集中於業務需要和任務,故要使用業務術語,你應將其教給分析人員,而你 不一定要懂得計算機的行業術語. 2:要求分析人員了解客戶的業務及目標 通過與用戶交流來獲取用戶需求、分析人員才能更好地了解你的業務任務和怎樣才能使產品更好地滿足你的需要.這將有助於開發人員設計出真正滿足你的需要並達到你期望的優秀軟體.為幫助開發人員和分析人員,可以考慮邀請他們觀察你或你的同事是怎樣工作的.如果新開發系統是用來替代已有的系統,那麼開發人員應使用一下目前的系統,這將有利於他們明白目前系統是怎樣工作的,其工作流程的情況,以及可供改進之處. 3:要求分析人員編寫軟體需求規格說明 分析人員要把從你和其他客戶那裡獲得的所有信息進行整理,以區分開業務需求及規范、功能需求、質量目標、解決方法和其它信息.通過這些分析就能得到一份軟體需求規格說明.而這份軟體需求規格說明便在開發人員和客戶之間針對要開發的產品內容達成了協議.軟體需求規格說明書可以用一種你認為易於翻閱和理解的方式組織編寫.要評審編寫出的規格說明以確保它們准確而完整地表達了你的需求.一份高質量的軟體需求規格說明能有助於開發人員開發出真正需要的產品. 4:要求得到需求工作結果的解釋說明 分析人員可能採用了多種圖表作為文字性軟體需求規格說明的補充.因為如工作流程圖那樣的圖表能很清楚地描述出系統行為的某些方面.所以需求說明中的各種圖表有著極高的價值.雖然它們不太難於理解,但是你很可能對此並不熟悉.因此可以要求分析人員解釋說明每張圖表的作用或其它的需求開發工作結果和符號的意義,及怎樣檢查圖表有無錯誤及不一致等. 5:要求開發人員尊重你的意見 如果用戶與開發人員之間不能相互理解,那關於需求的討論將會有障礙,共同合作能使大家"兼聽則明".參與需求開發過程的客戶有權要求開發人員尊重他們並珍惜他們為項目成功所付出的時間.同樣,客戶也應對開發人員為項目成功這一共同目標所作出的努力表示尊重與感激. 6:要求開發人員對需求及產品實施提供建議,拿出主意 通常,客戶所說的"需求"已是一種實際可能的實施解決方案,分析人員將盡力從這些解決方法中了解真正的業務及其需求,同時還應找出已有系統不適合當前業務之處,以確保產品不會無效或低效.在徹底弄清業務領域內的事情後,分析人員有時就能提出相當好的改進方法.有經驗且富有創造力的分析人員還能提出增加一些用戶並未發現的很有價值的系統特性. 7:描述產品易使用的特性 你可以要求分析人員在實現功能需求的同時還要注重軟體的易用性.因為這些易用特性或質量屬性能使你更准確、高效地完成任務.例如,客戶有時要求產品要"用戶友好"或"健壯"或"高效率",但這對於開發人員來說,太主觀了並無實用價值.正確的應是:分析人員通過詢問和調查了解客戶所要的友好、健壯、高效所包含的具體特性. 8:調整需求,允許重用已有的軟體組件 需求通常要有一定的靈活性.分析人員可能發現已有的某個軟體組件與你描述的需求很相符.在這種情況下,分析人員應提供一些修改需求的選擇以便開發人員能夠在新系統開發中重用一些已有的軟體.如果有可重用的機會出現,同時你又能調整你的需求說明,那就能降低成本和節省時間,而不必嚴格按原有的需求說明開發.所以說,如果想在產品中使用一些已有的商業常用組件,而它們並不完全適合你所需的特性,這時一定程度上的需求靈活性就顯得極為重要了. 9:獲得滿足客戶功能和質量要求的系統 每個人都希望項目獲得成功.但這不僅要求你要清晰地告知開發人員關於系統"做什麼"所需的所有信息,而且還要求開發人員能通過交流了解清楚取捨與限制.一定要明確說明你的假設和潛在的期望.否則,開發人員開發出的產品很可能無法讓你滿意. 客戶有下列義務: 1:給分析人員講解你的業務 分析人員要依靠你給他們講解的業務概念及術語.但你不能指望分析人員會成為該領域的專家,而只能讓他們真正明白你的問題和目標.不要期望分析人員能把握你們業務的細微與潛在之處,他們很可能並不知道那些對於你和你的同事來說理所當然的"常識". 2:抽出時間清楚地說明並完善需求 客戶很忙,經常在最忙的時候還得參與需求開發.但無論如何,你有義務抽出時間參與"頭腦風暴"會議的討論,接受采訪或其它獲取需求的活動.有時分析人員可能先以為明白了你的觀點,而過後發現還需要你的講解.這時,請耐心一些對待需求和需求的精化工作過程中的反復,因為它是人們交流中的很自然的現象,何況這對軟體產品的成功極為重要. 3:准確而詳細地說明需求 編寫一份清晰、准確的需求文檔是很困難的.由於處理細節問題不但煩人而且又耗時,故很容易留下模糊不清的需求.但是,在開發過程中,必須得解決這種模糊性和不準確性.而你恰是為解決這些問題作出決定的最佳人選.不然的話,你就只好靠開發人員去正確猜測了.在需求規格說明中暫時加上待定(to be determined, TBD也可採用漢語拼音略寫"DQD:待確定")的標志是個不錯的辦法.用該標志可指明了哪些需要進一步探討、分析或增加信息的地方.不過,有時也可能因為某個特殊需求難以解決或沒有人願意處理它而註上TBD標志.盡量將每項需求的內容都闡述清楚,以便分析人員能准確的將其寫進軟體需求規格說明中.如果你一時不能准確表述,那就得允許獲取必要的准確信息這樣一個過程.通常使用所謂的原型技術.通過開發的原型,你可以同開發人員一起反復修改,不斷完善需求定義. 4:及時地作出決定 正如一位建築師為你修建房屋,分析人員將要求你做出一些選擇和決定.這些決定包括來自多個用戶提出的處理方法或在質量特性沖突和信息准確度中選擇折衷方案等.有權做出決定的客戶必須積極地對待這一切,盡快做處理、做決定.因為開發人員通常只有等你做出了決定才能行動,而這種等待會延誤項目的進展. 5:尊重開發人員的需求可行性及成本評估 所有的軟體功能都有其成本價格,開發人員最適合預算這些成本(盡管許多開發人員並不擅長評估預測).你所希望的某些產品特性可能在技術上行不通,或者實現它要付出極為高昂的代價.而某些需求試圖在操作環境中要求不可能達到的性能或試圖得到一些根本得不到的數據,開發人員會對此作出負面的評價意見,你應該尊重他們的意見.有時,你可以重新給出一個在技術上可行、實現上便宜的需求,例如,要求某個行為在"瞬間"發生是不可行的,但換種更具體的時間需求說法("在50ms以內",但若沒有準確的技術分析不能輕易下結論),這就可以實現了. 6: 劃分需求優先順序別 大多數項目沒有足夠的時間或資源來實現功能性的每個細節.決定哪些特性是必要的,哪些是重要的,哪些是好的,是需求開發的主要部分.只能由你來負責設定需求優先順序,因為開發者並不可能按你的觀點決定需求優先順序.開發者將為你確定優先順序提供有關每個需求的花費和風險的信息.當你設定優先順序時,你幫助開發者確保在適當的時間內用最小的開支取得最好的效果.在時間和資源限制下,關於所需特性能否完成或完成多少應該尊重開發人員的意見.盡管沒有人願意看到自己所希望的需求在項目中未被實現,但畢竟是要面對這種現實的.業務決策有時不得不依據優先順序來縮小項目范圍或延長工期,或增加資源,或在質量上尋找折衷. 7:評審需求文檔和原型 正如我們將在第1 4章討論的,無論是正式的還是非正式的方式,對需求文檔進行評審都會對軟體質量提高有所幫助.讓客戶參與評審才能真正鑒別需求文檔是否的確完整、正確說明了期望的必要特性.評審也給客戶代表提供一個機會,給需求分析人員帶來反饋信息以改進他們的工作.如果你認為編寫的需求文檔不夠准確,就有義務盡早告訴分析人員並為改進提供建議.通過閱讀需求規格說明,很難想像實際的軟體是什麼樣子的.更好的方法是先為產品開發一個原型.這樣你就能提供更有價值的反饋信息給開發人員,幫助他們更好地理解你的需求.必須認識到:原型並非是一個實際產品,但開發人員能將其轉變、擴充成功能齊全的系統. 8:需求出現變更要馬上聯系 不斷的需求變更會給在預定計劃內完成高質量產品帶來嚴重的負面影響.變更是不可避免的,但在開發周期中變更越在晚期出現,其影響越大.變更不僅會導致代價極高的返工,而且工期也會被迫延誤,特別是在大體結構已完成後又需要增加新特性時.所以一旦你發現需要變更需求時,請一定立即通知分析人員. 9:應遵照開發組織處理需求變更的過程 為了將變更帶來的負面影響減少到最低限度,所有的參與者必須遵照項目的變更控制過程.這要求不放棄所有提出的變更,對每項要求的變更進行分析、綜合考慮,最後作出合適的決策以確定將某些變更引入項目中. 10:尊重開發人員採用的需求工程過程 軟體開發中最具挑戰性的莫過於收集需求並確定其正確性.分析人員採用的方法有其合理性.也許你認為需求過程不太劃算,但請相信花在需求開發上的時間是"很有價值"的.如果你理解並支持分析人員為收集、編寫需求文檔和確保其質量所採用的技術,那麼整個過程將會更為順利.盡管去詢問分析人員為什麼他們要收集某些信息,或參與與需求有關的活動. 系統分析人員在開發過程中可能會遇到以下問題,一些很忙的客戶可能不願意積極參與需求過程,而缺少客戶參與將很可能導致不理想的產品.故一定要確保需求開發中的主要參與者都了解並接受他們的義務.如果遇到分歧,通過協商以達成對各自義務的相互理解,這樣能減少今後的摩擦. 7.需求文檔 需求開發的最終成果是:客戶和開發小組對將要開發的產品達成一致協議.協議綜合了業務需求、用戶需求和軟體功能需求.就像我們早先所看到的,項目視圖和范圍文檔包含了業務需求,而使用實例文檔則包含了用戶需求.你必須編寫從使用實例派生出的功能需求文檔,還要編寫產品的非功能需求文檔,包括質量屬性和外部介面需求.只有以結構化和可讀性方式編寫這些文檔,並由項目的風險承擔者評審通過後,各方面人員才能確信他們所贊同的需求是可靠的. 你可以使用以下三種方法編寫軟體需求規格說明: 用好的結構化和自然語言編寫文本型文檔. 建立圖形化模型,這些模型可以描繪轉換過程、系統狀態和它們之間的變化、數據關系、邏輯流或對象類和它們的關系. 編寫形式化規格說明,這可以通過使用數學上精確的形式化邏輯語言來定義需求. 由於形式化規格說明具有很強的嚴密性和精確度,因此,所使用的形式化語言只有極少數軟體開發人員才熟悉,更不用說客戶了.雖然結構化的自然語言具有許多缺點,但在大多數軟體工程中,它仍是編寫需求文檔最現實的方法.包含了功能和非功能需求的基於文本的軟體需求規格說明已經為大多數項目所接受.圖形化分析模型通過提供另一種需求視圖,增強了軟體需求規格說明. 如果解決了您的問題請採納！ 如果未解決請繼續追問