系統分析師-軟體水平考試（高階）-開篇

前言

時隔一年，我開始了系統分析師的部落格寫作。回過頭翻看一下，一年前的系統架構設計師系列的第一篇部落格-需求理論，還是比較有感觸的。

其實系統分析師的考試早在上邊年五月份就參與了，也在六月份就知道自己通過了考試。但是一方面系統分析師與系統架構設計師有很多內容上的重複，另一方面自己確實工作也比較忙，所以相關的部落格就擱置下來了。

正好最近有點空閒時間，正好一方面整理所學，一方面輸出一些部落格，幫助大家。

分析師與架構師

首先，就是探討一下，系統分析師與系統架構設計師的關聯與區別。

兩者都是軟體考試的高階考試科目，並且也是相似對最高的兩門高階科目。畢竟早期軟考只有系統分析師的考試，而系統架構設計師是由於系統架構設計內容不斷增多，然後分離出來單獨成為一個科目的。

很多朋友都無法把握住兩門考試科目的區別，倒是學習無法集中注意力，從而導致考試失利。

考試角度

首先從考試角度來說，系統分析師中有關架構的部分，分值比較低，可以說幾乎與企業資訊化等章節一樣，就是個普通公民，不再享受系統架構設計師考試中一等公民的待遇了。其次，系統分析師由於在架構方面的分值大幅下降，所以提高了所有章節的分值。簡單說，就是所有章節的考試內容變多了。雖然深度不再深挖，但是考試範圍的擴大，導致考生覺得系統分析師內容太過繁雜，準備困難，難以把握重點。

那麼，分析師有沒有類似架構師的重點呢？答案是有的。從考試的分值散佈（客觀，案例，論文綜合起來看），以及考試名稱——系統分析師，可以知道重點在分析。就像系統架構師的重心在架構，高項的重心在管理，分析師的重心在分析。當然了，由於系統分析師的特殊性（所有高階科目的源頭），所以它的重心不會如架構師，管理師那樣突出。

那麼落在考試章節中，分析又落實在哪裡呢？那就是系統規劃，需求分析，以及一些零散的涉及分析的內容。當然，如果你是第一次參與高階考試，可千萬別隻看這兩個章節啊。

現實角度

老規矩，從考試的角度分析後，我們來從現實角度分析一下。當公司規模不大的時候，公司技術方面往往就一個技術部。技術部會有一個負責人，他會負責所有技術相關的問題，包括但不限於：

• 技術顧問：負責解答公司高層對技術的疑惑
• 技術評估：參與公司專案，產品的技術評估
• 技術規劃：為公司的戰略目標，提供技術方面的長遠規劃
• 技術管理：為領導的技術部門進行有效管理
• 技術支援：為領導的專案提供技術的直接幫助

公司規模不大的時候（百人以內，技術部門二十人以內），負責人尚且還能支撐得住，能夠在各方，各個工作間週轉開。不要問我怎麼知道的，問就是我在上家公司就是做這些的。

但是隨著公司規模增大，技術部門的人數增長。技術負責就不可能面面俱到了（某些牛人，就算了，咱只說正常情況）。

到了這個時候，原有技術負責的工作必須進行拆分。在中型公司，比較常見的是採用矩陣型的組織結構，原技術負責的職責拆分為：

• 技術總監：負責技術顧問，技術規劃
• 專案經理：負責專案管理工作
• 技術負責：負責單個專案的技術支援，配合專案經理與技術總監，完成技術評估，配合技術總監完成技術規劃的落地。

（這其中的需求，往往是三方的協調，妥協的一個結果。如果不懂得這句話，可以等到我開啟專案管理的分支，再細談。或者私聊我）

不要問我怎麼知道的，問就是因為年中有一個以前的上司來挖我的時候，和我提到了他們公司的情況。

可能你們要說，還是沒有看到系統分析師啊？別急，馬上就到了。

隨著專案規模的擴大，專案內的技術負責壓力就比較大了。一方面需要技術上司，業務方，專案經理打交道，瞭解具體需求，進而進行分析，另一方面還需要進行專案資訊系統的架構設計，搭建，為下屬提供技術支援。所以，部分大型公司就再次將技術負責拆分為業務分析師與技術架構師，也就是大家說的BA和架構師。不要問我怎麼知道的，問就是這個月，打電話挖我的公司就有這麼做。當然，也有人注意到，需求這個東西不是應該交由專案經理處理嘛？怎麼說呢？一方面，有些需求只有技術人員才有那個敏感性，另一方面，專案經理雖然也有獲取需求這一過程，但並不表示只靠專案經理自己去獲取，更多的是需要依靠具體的人落實，後者具體的人配合落實。專案經理本身更多是一個協調整合的人員，而不一定就是具體落實的人。

學習必要性

可能有些朋友就要問了，大型公司才用到，那是不是對於很多人來說，這個考試的學習就沒有意義了。

當然不是。

首先，即使是在中小公司，分析師的學習會補全架構師在業務方面，商業層面的不足。在一家中小公司，一個幾乎只會談論技術的（雖然有著非常高超的架構水平，但不是每個公司都有“伯樂”的）與一個可以談論公司業務，可以為公司戰略發展提出一個考慮了商業內涵的技術方案的，相信後者會更得Boss的歡心。

其次，不想當將軍的士兵不是好士兵。不想去大公司露一手的，不是好員工。人嘛，總是要有一顆上進的心。

最後，我們需要提升自己視野，如果只侷限於技術的維度，很容易把自己的職業道路走窄了。舉個例子，馬雲評價行癲，不僅有足夠的技術，更有著敏銳的商業視野。後面的故事，大家也都知道了，行癲上位（甚至現有的公司紛紛提出公司組成要有八成的技術人員，也不知道有沒有這方面的原因。囧）。

學習困難性

分析師學習難不難？

從資料角度。系統架構設計師的考試就比較困難了，其通過率接近8%，而分析師的通過率就只有系統架構設計師的一半不到，其通過率約為3%-4%。

從內容角度。套用一位老師說的話，從內容的深度而言，分析師的內容深度與系統架構設計師差不多。但是內容的量級上，分析師的內容量級比系統架構師要多（大概1.5倍吧，但是如果從架構師轉過來的話，只需要再學習0.7左右的內容）。

從抽象角度。對於有開發經驗的人而言，架構師中提到的技術，以及架構思想，起碼在經手的專案中能夠比較直觀的感受到。而分析師提到的系統規劃，需求分析等內容就不是每個開發人員能經手到的了。當然，對於沒有開發經驗的，那麼兩者幾乎是沒有什麼差別的。

XMIND

給出一個XMIND，讓大家比較直觀地感受到系統分析師的知識體系。

學習方法

那麼有沒有什麼辦法可以提高學習效率呢？

當然是有的。雖然我在架構師考試部落格中推薦了許多書籍，但是分析師的書籍真的幾乎沒有，所以就不推薦了（畢竟也有一些人認為沒有時間看那麼多的書籍）。

說一下我的學習方法：

• 首先，看一下教材的目錄，瞭解往年考試情況與分值分佈情況。然後有目的性地快速看一遍教材，不求甚解，只求留個印象。
• 其次，配合XMIND，寫下各個章節的重點內容，從而建立知識體系（我十分看重建立知識體系，包括面試別人的時候）。
• 然後，配合XMIND，按照重要程度，去細看教材。不大清楚的地方，還會查閱資料，詢問群友什麼的。
• 最後，就是做題啦，每個章節學習完，都會做章節練習，判斷自己對這一章節的認識，並瞭解題型。另外學完所有章節（起碼是自己認為應該學習的章節）後，還會做模擬題（儘量還原出考場的感覺）。最重要的，別忘了錯題集，真的有用的。

總結

如果你想要參加考試，第一件事情就是需要明確自己是為了知識而來，還是為了考試而來，抑或是兩者都有的。

另外，我這邊確實有一個關於系統架構師/分析師的群，但是是邀請制的，也就是說給你群號也沒用。如果有參與考試的想法，可以私信@我。

最後，只想說一下，軟考高階是個好東西，但是也不可能讓你立馬上天的。它只是一個加速器，一個倍增器。就像架構師的考試，給了我一個很好的知識體系，雖然非常空蕩蕩的，但是我可以不斷向其中填充具體的技術。目測架構師考試的紅利，我至少還可以吃個三年。至於後續的分析師與管理師就更不用說了。最重要的是提供了非常好的視野，而視野這個東西，無法直觀地帶來薪水，職位的提升。但是這個東西的好處真的很多，關鍵其它途徑很難如此快速地獲得它。

最後，希望我的部落格可以為大家提供幫助。謝謝。