畢業入職一年拿下軟考高項並申請E類人才攻略

阿里妹導讀

本文記錄了作者考取軟考的複習過程、備考時間線和一些經驗總結。

為什麼考軟考

杭州人才認定：在杭州的打工人應該都瞭解，杭州市的人才評定福利待遇是很豐厚的。從A類到F類，每個級別的人才都會有相應的福利。其中，E類人才是我們大多數人稍加努力就可以夠到的人才類別。

E類人才：E類人才目前有多種評定方法，其中我們能夠接觸到的副高職稱評定資格+相關成果（論文或專利）或者年薪50w+。評定上E類人才後，在杭州每個月可以發2500的租房補貼，總共可以領5年，即最多可以領取15w。

軟考的定位：軟考是國家認證的可以以考代評的水平考試。換句話說，通過了考試就不再進行職稱資格的評審工作，相當於拿到了軟考證書就具備了評副高職稱的資格，進而就滿足了上述E類人才評定方法的必要條件之一。

時間線

整體時間線

自己備考的整體時間線如下：

隨緣複習（2023.8.19~2023.11.25）

準確地講，自己在2023年的7月（剛畢業入職）就已經瞭解到有軟考這個東西，也知道軟考可以用來評定E類人才，由於花32買了本教材，想憑藉自己讀書期間養成的考試習慣把它拿下。但教材拿到手的那一刻我傻眼了，發現教材比我預想的要厚很多（跟板磚一樣）。

這裡我選擇考試科目是資訊系統專案管理師，選擇該科目的原因是在2023年，該科目一年可以考兩次，上半年考掛了下半年可以接著考，而系分、系架一年只有一次，如果沒考過時間成本很高。（注意：2024年新的檔案中規定高項一年只能考一次，系分、系架一年有兩次）。大家在備考時需要考慮到這個因素。

由於剛畢業自己也沒有什麼專案經驗，書本中的知識點自己學習起來非常吃力。於是就到B站上找了公開課聽一聽。B站上也確實有一些不錯的公開課，自己進入的是大匠老師的課程。聽了幾節課覺得講得蠻細緻的，於是就開始跟了（這裡建議大家多找幾個老師的課聽一下，橫向對比一下看看自己更適合哪個老師的風格）。

https://www.bilibili.com/video/BV16Y4y1S7Eh/

當然，天下沒有免費的午餐，這些課程也進階的內容也基本都要收費。於是我斥“巨資”，買了大匠老師的課程。開啟了自己的複習之路。

之後自己每個週末沒事的時候在家刷B站看影片輔導課（每週跟著聽一兩章的內容）。

其實在23年11月有一次考試機會，但當時覺得自己複習得非常淺，肯定考不過，於是也就沒去考試。

（再次為這300元報名費感到心疼💔）

11月那次考試結束後，由於離次年考試還有整整6個月的時間，再加上工作也開始忙起來了，自己也就開擺了。

正式複習（2024.2.18~2024.5.26）

自己正式開始軟考備考的時間點應該是在24年過年回來開始上班。當時自己的管理知識儲備是：對專案管理的十大過程組有個初步的認識（大概知道下表中各個過程是幹啥的），對於一些計算機基礎知識（人工智慧，大資料，計算機組成原理）有一定的瞭解，但也都是停留在知道是什麼上。對於有計算機知識背景的考生而言，這個時間點開始完全夠了。如果是非相關專業同學，建議提前一個月左右過一遍基礎知識。

不過那個時候，自己已經有了半年的工作經歷：和產品battle過產品方案，向pm、老闆彙報開發進度等。其實這些都是專案管理知識點對應的實踐經歷。有了這些經歷，自己在學習相關知識點的時候立刻產生畫面感，從而對書本中的知識點有更深刻的理解。

一輪複習（2.18~3.18）

一輪複習給自己定的計劃是：花一個月時間（當然也只有每個週末的7-8個小時）跟著網課把軟考的所有知識點都全部認真的過一遍。

在每一章的開頭把本章在考試中的定位記錄下來（課程中一般都會介紹本章考試分值）。

前1~6章的內容都是選擇題，根據自己的知識儲備情況選擇性複習。由於我本身就是計算機專業的，對諸如區塊鏈、人工智慧、大資料的知識點就很熟悉，這裡我就直接當聽故事一樣快速略過。如果是不熟悉的小夥伴建議把這些內容當作日常聽力訓練內容，沒事就聽聽，增加一下熟悉程度。

對於重點的章節（7~19章）自己則會跟著老師上課的PPT在書本上勾勾畫畫，並且經可能得去帶入自己實際的工作經歷（從事軟體開發行業的同學應該比較容易get到）。例如進度管理章節，就聯想一下自己如何向老闆彙報進度，過程中有哪些注意要點。對於一下抽象的知識點，自己可以把經歷過的一些工作場景寫在旁邊加深理解（後來你會發現，這其實也是論文素材）。

此時，可能會出現聽起來雲裡霧裡的情況，別擔心，知識的沉澱是需要時間的，按部就班推進就好。

二輪複習（3.18~4.15）

經過第一輪的複習，對專案管理在整體上應該能更清晰的認識。

這個時候，需要把學習的重心放在重點章節上（7~19章），週末每天花幾個小時，自行把控節奏。

這裡，筆者採用的複習方法就是再次通讀課本，感悟各個章節之間的邏輯性，按照自上而下的思路去學習每個章節，然後嘗試去回答課後習題。有了一輪複習自己寫下的一些實踐樣例以及對前後章節的學習，這裡就已經能夠明顯感受在學習這些知識點的時候不再那麼吃力，並且每次閱讀教材都會有不一樣的收穫（在這個時間點下，筆者複習每個章節大概只需要1個小時左右）。有條件的同學可以配合這一些輔導資料，在自己購買網課的群一般都會有輔導資料。

強化複習（4.16~5.5）

基礎知識複習（工作日）

二輪複習後，自己對各個章節的重難點也基本有了認識。並且給你一個習題，基本上能夠做到快速定位這個知識點是歸屬於那個章節。

滾動強化複習的目的在於強化這些知識點，提高做題的正確率。在這個階段，自己開始在工作日的晚上也會投入複習。做的內容是：針對每一個章節，拿出一張A4紙自己把該章節的重難點梳理出來。並且自己去想一些口訣、用例去強化記憶知識點。用A4紙記口訣或例子有兩個原因：一個是自己寫一遍記憶更加深刻，另一個是可以把A4紙帶去公司，然後在第二天也做到在午休前回顧這些口訣用例。

這個階段把7-19章過完大概花兩週左右，每天晚上花40分鐘快速過一遍書本，然後花20分鐘左右整理口訣。

案例分析+計算題（週末）

此外，在這個階段，也應該開始著手準備案例分析和計算題。

案例分析基本都集中在過程管理，計算題都集中在成本、進度管理。這兩種題目通常是有解題套路的，如果自己去琢磨的話時間成本較高，不建議。這裡建議大家直接報個網課，花100左右買個計算題+案例分析+論文的輔導課。二輪複習順利的同學，能很輕鬆跟上網課的節奏。當聽完一遍網課後，直接開始寫題。（有時候研究一道題不知不覺就天黑了，彷彿回到了中學時代哈哈哈）。案例分析和計算題的題目種類不多，大約兩個週末就可以把所有題型都給刷一遍。刷完案例分析和計算題基本都能過了。

所以強化訓練的節奏就是週一到週五滾動複習7-19章書本知識點，主要是背誦十大過程管理的主要內容、作用和輸入輸出。週末就跟著老師過案例分析和計算，並自己刷題。

衝刺複習（5.5~考前）

如果一輪、二輪、強化複習都有條不紊地完成，到這個階段，十大過程組、案例、計算題基本上都不是難點了。

衝刺複習就可以針對選擇題+論文進行了。

選擇題（工作日）

關於選擇題，這裡建議大家可以直接基於購買課程的題庫進行。通常你購買網課都會自帶題庫，每天上班吃飯排隊的時候掏出手機刷一章，晚上回家後針對錯題找到教材複習一下。從5月到考前基本上也就夠了（無計算機背景的同學建議提早一些進行）。

論文（週末）

下面重點說下論文，論文對於大多數同學應該都是難點。並且隨著報考人數越來越多，卡論文分數也成了軟考組織方控制透過率最直接的手段。我這次考試分數就正好卡在了45分（感謝閱卷老師不殺之恩）。

所以對於論文的準備是十分重要的。

比較重要的備考要點需要注意：論文寫法

論文的核心寫法就是，理論+實踐。思路其實很簡單，就是按照各個流程先說一下理論知識，然後結合自己的實際經歷講一下自己如何將理論知識應用在實踐中。

下面是我提前準備好的專案整合管理的論文：

規劃範圍管理

（理論）規劃範圍管理是為了記錄如何定義、確認和控制專案範圍及產品範圍而建立範圍管理計劃的過程。專案規劃階段，我們邀請了甲方xx地農業發展部的對接人，農產品供應商代表、採購商代表，國內某地質大學GIS系統領域專家，透過借鑑公司歷史資料，共同制定出了專案的範圍說明書。（實踐）在需求管理方面，我們明確了專案中各個任務的負責人和執行方式。其中需求調研任務由需求分析師王X負責。工作要求王某深入農村基層，同廣大農產品提供商進行進行深度交流以獲取他們在農產品供銷上存在的痛點。基於收集到的訴求，王X透過會議的方式，也對同甲方的介面人和領導進行了討論，進一步補充了需求，並確認了需求的優先順序，在透過相關干係人評審後形成了初版的需求管理計劃。

在確認範圍方面，我們採取了三個階段的評審關鍵節點。透過這種方式，我們可以及時發現並糾偏範圍偏差，確保專案按計劃推進。《範圍管理計劃》為該專案提供了清晰的指導和方向，以確保專案團隊能夠明確目標、有序推進，最終實現xx的成功交付。

收集需求

（理論）收集需求是為了實現目標而確定，記錄並管理干係人的需要和需求的過程。為了需求調研，我們派遣了需求分析師黃X深入農村基層，同農產品供應商和深入交流，並參與瞭解日常農產品交易的實際場景。（實踐）在同某農產品採購商交流的過程中，王X瞭解到由於許多農產品的生長週期不固定，自己經常買到臨近過期的農產品，導致自己銷售時經常會有庫存壓力。因此，希望該平臺能提供農產品的質檢報告，或者對農產品供應商的資質進行評估校驗，平臺應當起到監管作用。對此，王X對該需求進行了收集，並同自己在實地學習過程中瞭解到的交易痛點進行了整理，形成了最終的《需求檔案》和《需求跟蹤矩陣》。在需求跟蹤矩陣中，我們詳細制定了需求跟蹤表。例如，針對農產品供應商的商品管理模組，我們對該功能點進行了拆解，劃分了農產品上傳、農產品營銷、農產品售賣報表等子功能模組。並定義好了各個功能模組具體要實現的功能。透過精準清晰的需求收集，我們為專案後續的開展奠定了良好的基礎，確保專案能夠滿足甲方的期待。

定義範圍

（理論）定義範圍是制定專案和產品詳細描述的過程。

（實踐）我們團隊以範圍管理計劃和軟體規格需求說明書等需求檔案為基礎，召集專案的主要干係人進行討論，並邀請了xx地農業發展部的對接人王X，以及農產品供銷商代表人對系統功能進行評價。透過從使用者的角度出發，改進系統功能，最終制定出了《農資監管及直採管理系統專案範圍說明書》，並由甲方負責人簽字，內容包括

1、產品範圍：

供應商端：提供完整的商品上傳、農產品營銷活動報名、訂單管理等功能。

直採端：提供完整的商品展示、商品價格實施計算（疊加優惠券）、購買下單支付、支付成功的功能鏈路。

大資料監管端：必須對全市農資經銷機構、農技服務機構、人力服務機構、倉儲服務機構、運輸服務機構、農事服務機構等資訊錄入，包括但不限於如門頭照片，店鋪位置資訊，店鋪基本資訊，支付接入.支援所有結構的精確查詢。

2、專案的可交付物：專案的全部原始碼，開發過程中的技術方案文件，測試標準，使用者手冊等。

3、系統驗收標準：

所有功能模組要按照需求文件重要的要求實現，並透過測試用例的驗證，確保在實際使用中表現良好的效能

效能要求：本專案必須7X24小時可用，，平臺訪問微應用響應時間＜5秒；事務處理查詢平均2秒，複雜分析查詢最長＜6秒。在網路穩定的環境下，操作性介面單一操作的系統響應時間＜3秒，高峰期＜4秒。

4、制約因素：

執行環境必須是在國產平臺

平臺還擁有自身業務的延展性、技術架構的前瞻性、平臺埠的相容與開放性，使得未來系統得以不斷升級、業務持續擴充套件，做到平臺系統始終適配不斷發展的現代農業管理思路與智慧農業應用場景。

建立WBS

（理論）建立工作分解結構是吧專案可交付成果和專案分解為較小，更易於管理的元件的過程。基於專案範圍說明書，我和團隊成員對專案範圍進行了分解。好的WBS分解能夠讓原本模糊、籠統的工作變得清晰，是的管理有理有據。（實踐）具體的，針對本次我負責的專案。我先把供給端農產品管理系統分解出大概得WBS1-2層，分解出“高層級”的工作包和控制賬戶，然後讓各模組負責人都參與了專案工作的分解。這裡，我採用了滾動式分解，逐步達到客戶的要求，並將細節資訊在WBS字典中加以描述。如下圖所示：

確認範圍

（理論）確認範圍是農資監管及直採管理系統專案中正式驗收已完成專案可交付成果的重要過程。為了解決客戶對最終績效的擔憂，我們採取了分階段交付+分階段確認方式。（實踐）在專案的里程碑節點，例如完成了供給端農產品管理後臺系統開發後，我們邀請xx地農業發展部介面人，和供應商代表，參與評審會議。會議上演示如何在後臺管理系統中上傳自己的農產品，並完成相關產品的備案。這樣一來，干係人可以直觀地瞭解系統如何執行，也增加他們對專案成功的信心。演示完成後，我們請他們檢查確認，並形成書面的《xx階段評審意見表》以及甲方領導簽字確認，這種階段性確認的方式有效的清楚了干係人一路，保證專案的順利進行和最終驗收的順利完成。

控制範圍

（理論）控制範圍就是監督專案範圍狀態，管理範圍變更的過程。在專案中，我定期組織召開專案狀態審查會，審查專案的範圍，找出專案偏差，並做分析，嚴格杜絕一切範圍蔓延鍍金的情況。（實踐）例如。在某次審查會議桑，我發現了“供給商後臺開發”模組中增加了“供給商店鋪訪問報表分析”的開發任務。我查閱了《產品範圍說明書》和《需求跟蹤矩陣》，並沒有發現該需求，於是我按照責任分配矩陣找到了模組開發的負責人。詢問原因，原來是因為負責人張工，因為之前開發過類似的需求，覺得這個功能挺有用，就決定順手加一下。針對該情況，我也再次和團隊成員強調：應當嚴格遵守範圍基準，杜絕需求蔓延。如果有變更，必須走審批。此功能我透過初步的論證評估，決定將變更提交給CCB審批。CCB審批初步評估該功能大概需要5人日的工作量，但可能會改動到已有的鏈路。但由於專案已經接近尾聲，為了避免本次改動對已完成的功能造成破壞，CCB駁回了變更請求。但考慮到該功能確實會對使用者體驗有極大的幫助，與會幹系人經過討論，決定將該需求作為補充，經過正規變更流程，在二期開發中實現。