系統分析師 軟體水平考試(高級) 開篇 前言 時隔一年,我開始了系統分析師的博客寫作。回過頭翻看一下,一年前的系統架構設計師系列的第一篇博客 需求理論,還是比較有感觸的。 其實系統分析師的考試早在上邊年五月份就參與了,也在六月份就知道自己通過了考試。但是一方面系統分析師與系統架構設計師有很多內容上的 ...
系統分析師-軟體水平考試(高級)-開篇
前言
時隔一年,我開始了系統分析師的博客寫作。回過頭翻看一下,一年前的系統架構設計師系列的第一篇博客-需求理論,還是比較有感觸的。
其實系統分析師的考試早在上邊年五月份就參與了,也在六月份就知道自己通過了考試。但是一方面系統分析師與系統架構設計師有很多內容上的重覆,另一方面自己確實工作也比較忙,所以相關的博客就擱置下來了。
正好最近有點空閑時間,正好一方面整理所學,一方面輸出一些博客,幫助大家。
分析師與架構師
首先,就是探討一下,系統分析師與系統架構設計師的關聯與區別。
兩者都是軟體考試的高級考試科目,並且也是相似對最高的兩門高級科目。畢竟早期軟考只有系統分析師的考試,而系統架構設計師是由於系統架構設計內容不斷增多,然後分離出來單獨成為一個科目的。
很多朋友都無法把握住兩門考試科目的區別,導致學習無法集中註意力,從而造成考試失利。
考試角度
首先從考試角度來說,系統分析師中有關架構的部分,分值比較低,可以說幾乎與企業信息化等章節一樣,就是個普通公民,不再享受系統架構設計師考試中一等公民的待遇了。其次,系統分析師由於在架構方面的分值大幅下降,所以提高了所有章節的分值。簡單說,就是所有章節的考試內容變多了。雖然深度不再深挖,但是考試範圍的擴大,導致考生覺得系統分析師內容太過繁雜,準備困難,難以把握重點。
那麼,分析師有沒有類似架構師的重點呢?答案是有的。從考試的分值散佈(客觀,案例,論文綜合起來看),以及考試名稱——系統分析師,可以知道重點在分析。就像系統架構師的重心在架構,高項的重心在管理,分析師的重心在分析。當然了,由於系統分析師的特殊性(所有高級科目的源頭),所以它的重心不會如架構師,管理師那樣突出。
那麼落在考試章節中,分析又落實在哪裡呢?那就是系統規劃,需求分析,以及一些零散的涉及分析的內容。當然,如果你是第一次參與高級考試,可千萬別隻看這兩個章節啊。
現實角度
老規矩,從考試的角度分析後,我們來從現實角度分析一下。當公司規模不大的時候,公司技術方面往往就一個技術部。技術部會有一個負責人,他會負責所有技術相關的問題,包括但不限於:
- 技術顧問:負責解答公司高層對技術的疑惑
- 技術評估:參與公司項目,產品的技術評估
- 技術規劃:為公司的戰略目標,提供技術方面的長遠規劃
- 技術管理:為領導的技術部門進行有效管理
- 技術支持:為領導的項目提供技術的直接幫助
公司規模不大的時候(百人以內,技術部門二十人以內),負責人尚且還能支撐得住,能夠在各方,各個工作間周轉開。不要問我怎麼知道的,問就是我在上家公司就是做這些的。
但是隨著公司規模增大,技術部門的人數增長。技術負責就不可能面面俱到了(某些牛人,就算了,咱只說正常情況)。
到了這個時候,原有技術負責的工作必須進行拆分。在中型公司,比較常見的是採用矩陣型的組織結構,原技術負責的職責拆分為:
- 技術總監:負責技術顧問,技術規劃
- 項目經理:負責項目管理工作
- 技術負責:負責單個項目的技術支持,配合項目經理與技術總監,完成技術評估,配合技術總監完成技術規劃的落地。
(這其中的需求,往往是三方的協調,妥協的一個結果。如果不懂得這句話,可以等到我開啟項目管理的分支,再細談。或者私聊我)
不要問我怎麼知道的,問就是因為年中有一個以前的上司來挖我的時候,和我提到了他們公司的情況。
可能你們要說,還是沒有看到系統分析師啊?別急,馬上就到了。
隨著項目規模的擴大,項目內的技術負責壓力就比較大了。一方面需要技術上司,業務方,項目經理打交道,瞭解具體需求,進而進行分析,另一方面還需要進行項目信息系統的架構設計,搭建,為下屬提供技術支持。所以,部分大型公司就再次將技術負責拆分為業務分析師與技術架構師,也就是大家說的BA和架構師。不要問我怎麼知道的,問就是這個月,打電話挖我的公司就有這麼做。當然,也有人註意到,需求這個東西不是應該交由項目經理處理嘛?怎麼說呢?一方面,有些需求只有技術人員才有那個敏感性,另一方面,項目經理雖然也有獲取需求這一過程,但並不表示只靠項目經理自己去獲取,更多的是需要依靠具體的人落實,後者具體的人配合落實。項目經理本身更多是一個協調整合的人員,而不一定就是具體落實的人。
學習必要性
可能有些朋友就要問了,大型公司才用到,那是不是對於很多人來說,這個考試的學習就沒有意義了。
當然不是。
首先,即使是在中小公司,分析師的學習會補全架構師在業務方面,商業層面的不足。在一家中小公司,一個幾乎只會談論技術的(雖然有著非常高超的架構水平,但不是每個公司都有“伯樂”的)與一個可以談論公司業務,可以為公司戰略發展提出一個考慮了商業內涵的技術方案的,相信後者會更得Boss的歡心。
其次,不想當將軍計程車兵不是好士兵。不想去大公司露一手的,不是好員工。人嘛,總是要有一顆上進的心。
最後,我們需要提升自己視野,如果只局限於技術的維度,很容易把自己的職業道路走窄了。舉個例子,馬雲評價行癲,不僅有足夠的技術,更有著敏銳的商業視野。後面的故事,大家也都知道了,行癲上位(甚至現有的公司紛紛提出公司組成要有八成的技術人員,也不知道有沒有這方面的原因。囧)。
學習困難性
分析師學習難不難?
從數據角度。系統架構設計師的考試就比較困難了,其通過率接近8%,而分析師的通過率就只有系統架構設計師的一半不到,其通過率約為3%-4%。
從內容角度。套用一位老師說的話,從內容的深度而言,分析師的內容深度與系統架構設計師差不多。但是內容的量級上,分析師的內容量級比系統架構師要多(大概1.5倍吧,但是如果從架構師轉過來的話,只需要再學習0.7左右的內容)。
從抽象角度。對於有開發經驗的人而言,架構師中提到的技術,以及架構思想,起碼在經手的項目中能夠比較直觀的感受到。而分析師提到的系統規劃,需求分析等內容就不是每個開發人員能經手到的了。當然,對於沒有開發經驗的,那麼兩者幾乎是沒有什麼差別的。
XMIND
給出一個XMIND,讓大家比較直觀地感受到系統分析師的知識體系。
學習方法
那麼有沒有什麼辦法可以提高學習效率呢?
當然是有的。雖然我在架構師考試博客中推薦了許多書籍,但是分析師的書籍真的幾乎沒有,所以就不推薦了(畢竟也有一些人認為沒有時間看那麼多的書籍)。
說一下我的學習方法:
- 首先,看一下教材的目錄,瞭解往年考試情況與分值分佈情況。然後有目的性地快速看一遍教材,不求甚解,只求留個印象。
- 其次,配合XMIND,寫下各個章節的重點內容,從而建立知識體系(我十分看重建立知識體系,包括面試別人的時候)。
- 然後,配合XMIND,按照重要程度,去細看教材。不大清楚的地方,還會查閱資料,詢問群友什麼的。
- 最後,就是做題啦,每個章節學習完,都會做章節練習,判斷自己對這一章節的認識,並瞭解題型。另外學完所有章節(起碼是自己認為應該學習的章節)後,還會做模擬題(儘量還原出考場的感覺)。最重要的,別忘了錯題集,真的有用的。
總結
如果你想要參加考試,第一件事情就是需要明確自己是為了知識而來,還是為了考試而來,抑或是兩者都有的。
另外,我這邊確實有一個關於系統架構師/分析師的群,但是是邀請制的,也就是說給你群號也沒用。如果有參與考試的想法,可以私信@我。
最後,只想說一下,軟考高級是個好東西,但是也不可能讓你立馬上天的。它只是一個加速器,一個倍增器。就像架構師的考試,給了我一個很好的知識體系,雖然非常空蕩蕩的,但是我可以不斷向其中填充具體的技術。目測架構師考試的紅利,我至少還可以吃個三年。至於後續的分析師與管理師就更不用說了。最重要的是提供了非常好的視野,而視野這個東西,無法直觀地帶來薪水,職位的提升。但是這個東西的好處真的很多,關鍵其它途徑很難如此快速地獲得它。
最後,希望我的博客可以為大家提供幫助。謝謝。