書寫經(jīng)驗85人覺得有用

寫崗位職責的時候，得先搞清楚這個崗位到底要做哪些事。比如.net軟件工程師，這可不是個簡單活兒，涉及到編程、調(diào)試、維護什么的。一開始就得把工作范圍圈定好，不然領導找你問事的時候，你可能就有點蒙。像什么開發(fā)新功能、修復漏洞之類的，這些都是基本的工作內(nèi)容。

具體到.net軟件工程師，他得負責項目里的代碼編寫，還有就是配合團隊一起解決問題。有時候客戶那邊提出需求變更，那也得及時跟進，調(diào)整相應的程序部分。說起來簡單，做起來可不輕松，畢竟代碼，一個小小的改動都可能牽一發(fā)而動全身。

在寫職責的時候，最好能帶上一些專業(yè)術(shù)語，這樣顯得專業(yè)。比如，需要熟悉.net framework、c#、asp.net這些東西。要是沒有這些基礎，做起事情來難免會有些吃力。而且，還得強調(diào)一下，工作態(tài)度很重要，遇到問題不能推諉，要積極想辦法解決。

除了技術(shù)能力，溝通能力也不能忽視。因為軟件開發(fā)不是一個人的事，團隊合作特別關(guān)鍵。有時候需求文檔理解不到位，就需要跟產(chǎn)品經(jīng)理或者其他同事多交流，確保大家都朝著同一個目標努力。如果在這方面出了岔子，最后出來的成果可能就會偏離預期。

書寫注意事項：

寫職責的時候，還可以提到一些軟技能的要求。比如責任心強、抗壓能力強之類的。畢竟項目進度緊的時候，加班加點也是常有的事。要是有人扛不住壓力，工作質(zhì)量下降，那整個團隊都會受影響。

不過，有時候?qū)懼鴮懼?，可能會不小心漏掉一些重要的點。比如忘了提測試環(huán)節(jié)的重要性，其實每個模塊開發(fā)完之后，都需要經(jīng)過嚴格的測試才能上線。要是這里沒說清楚，別人看了職責描述還以為只要寫代碼就行，其實遠不止這些。

書寫經(jīng)驗72人覺得有用

寫崗位職責的時候，得結(jié)合具體的工作場景和需求，不能太籠統(tǒng)。比如高級.net軟件工程師這個崗位，你得先把技術(shù)上的核心任務寫清楚，像負責系統(tǒng)架構(gòu)設計，性能優(yōu)化這些。不過有時候會因為時間緊任務重，可能會漏掉一些細節(jié)，像是數(shù)據(jù)庫調(diào)優(yōu)這部分，有時候就容易被忽略掉。

書寫注意事項：

職責里最好提到一些具體的產(chǎn)出物，像需要編寫高質(zhì)量的技術(shù)文檔，確保代碼符合團隊的編碼規(guī)范。有時候領導可能覺得這些不重要，但實際上長期來看，文檔對后續(xù)維護特別關(guān)鍵，要是文檔不到位，后期改代碼的時候可能會踩坑。

要強調(diào)跨部門協(xié)作的能力，畢竟軟件開發(fā)不是一個人的事。跟產(chǎn)品經(jīng)理溝通需求，跟測試團隊確認bug修復情況，這些都是日常工作的一部分。不過有時候跟不同部門的人交流，可能會因為專業(yè)術(shù)語的不同產(chǎn)生誤解，這就需要多花點心思去解釋清楚。

至于職位要求，除了必備的技術(shù)技能，像精通c#、熟悉.net框架這類，也得提一下軟技能，比如說解決問題的能力，遇到難題時能冷靜分析，找到解決辦法。有時候面試官可能會過分關(guān)注技術(shù)深度，卻忽視了候選人的溝通能力，這其實挺影響工作的。

小編友情提醒：

記得結(jié)合公司實際情況調(diào)整措辭。像如果是初創(chuàng)公司，可能更看重快速響應市場變化的能力；而大企業(yè)的話，流程合規(guī)性就顯得尤為重要。所以寫的時候得心里有個譜，不然寫出來的職責和要求就容易偏離實際。

書寫經(jīng)驗19人覺得有用

寫崗位職責的時候，得先搞清楚這個崗位具體是干什么的，不然寫出來的東西空洞得很，讓人看了摸不著頭腦。比如asp.net軟件工程師，這可不是那種隨便就能上手的工作，它涉及到一堆專業(yè)的東西，像什么mvc架構(gòu)、web api、linq之類的，所以崗位職責就不能太籠糊。要是我來寫，就大概會說負責網(wǎng)站后端開發(fā)，維護現(xiàn)有系統(tǒng)，還有就是跟前端同事配合調(diào)試接口什么的。這些都是日常工作的一部分。

寫的時候最好能結(jié)合公司實際情況，比如說這家公司的項目主要是做電商系統(tǒng)的，那職責里就可以提到需要對接支付接口、處理訂單邏輯之類的具體任務。不過有時候?qū)懚嗔朔炊菀着芷?，像我曾?jīng)寫過一個職責，寫著寫著就把“協(xié)助解決線上問題”寫成了“定期排查線上問題”，這其實有點多余，因為誰會專門定時排查，都是出了問題才去查的嘛。

職位要求這部分也得實打?qū)崒?，別光喊口號。像asp.net工程師，就得提c#基礎必須扎實，數(shù)據(jù)庫操作熟練，還得懂點性能優(yōu)化。但我記得有一次寫職位要求，不知怎么就寫成了“熟悉常用的設計模式，例如單例模式、工廠模式等”，其實工廠模式算不上特別常用，這話有點畫蛇添足的感覺。

書寫注意事項：

寫這些的時候語氣得誠懇，別給人感覺像是應付差事。比如說寫到“需要配合產(chǎn)品經(jīng)理完成需求分析”這一條時，就應該帶點主動性進去，不能光說“配合”，好像自己只是個跑腿的。當然了，有時候?qū)懚嗔艘矔鰡栴}，像我寫過“具備良好的溝通能力，能夠與團隊成員有效交流”，這句話本身沒問題，但放在一起看，就會覺得啰嗦，因為前面已經(jīng)提過溝通能力了。

寫的時候還要注意行業(yè)術(shù)語的使用，不能亂套。像asp.net工程師，提到的技術(shù)棧就要對，像entity framework這種orm框架，要是寫成直接操作數(shù)據(jù)庫，那就露怯了。不過也有時候會寫錯，比如把“配置nginx反向代理”寫成“配置apache反向代理”，雖然意思差不多，但還是能看出水平高低。

小編友情提醒：

寫這些東西的時候得有耐心，別急匆匆地草草了事。尤其是像asp.net這種技術(shù)崗，細節(jié)很重要，一個小疏忽可能就會影響整個項目的進展。

書寫經(jīng)驗97人覺得有用

.net軟件測試工程師的崗位職責和職位要求寫這類崗位描述的時候，得先搞清楚這個崗位到底要做什么事。比如，這個崗位需要負責軟件的功能測試，那就要具體說說怎么測，是手動測試還是自動化測試，這得看公司用什么工具和技術(shù)棧。

寫職責的時候，可以從日常的工作內(nèi)容入手。像負責編寫測試計劃，這個肯定得提一下，還有執(zhí)行測試任務，確保每個功能點都檢查到位。有時候可能還會涉及到一些性能測試，這部分也別漏掉。另外，發(fā)現(xiàn)bug后怎么跟蹤處理，這也是很重要的環(huán)節(jié)，得寫清楚。

至于職位要求，學歷背景一般得本科起，計算機相關(guān)專業(yè)。技術(shù)能力方面，至少得熟悉常用的測試框架，像nunit、xunit之類的，這些都是.net開發(fā)里比較常見的。當然了，還得會點數(shù)據(jù)庫操作，sql查詢語句什么的基本功要扎實。

不過，寫的時候要注意細節(jié)，有時候一個小小的疏忽就可能導致歧義。比如有一次我寫職責描述，本來想說“參與項目需求分析”，結(jié)果一不留神寫成了“參于”，后來被領導指出來才改過來。還有一次寫職位要求，本來想強調(diào)經(jīng)驗年限，寫了“3年以上工作經(jīng)驗”，結(jié)果忘了加上括號注明是“年”，雖然沒太大影響，但總覺得差點意思。

其實，寫這些東西的時候，最好能結(jié)合公司的實際情況來調(diào)整措辭。如果公司特別看重團隊協(xié)作能力，那就得在職責里突出這一點，比如強調(diào)需要和開發(fā)人員緊密配合解決問題。要是公司對文檔編寫有較高要求，那職位要求里也得明確提到文檔撰寫能力，包括測試報告之類的。

書寫經(jīng)驗26人覺得有用

寫崗位職責的時候，得先搞清楚這個崗位到底干什么。像c# asp.net軟件開發(fā)工程師這活兒，主要就是跟代碼打交道，負責系統(tǒng)的設計、編碼、測試什么的。說白了，就是要把需求變成能跑起來的應用程序。具體咋寫？先想想日常工作有哪些，比如參與需求分析，這很重要，因為需求不對勁，后面改起來麻煩。還有就是編寫代碼，這部分得保證質(zhì)量，不然上線后一堆bug，那可就尷尬了。

書寫注意事項：

還得做些維護工作，老系統(tǒng)要是有問題，就得去排查、修復。再有就是團隊協(xié)作，和其他部門配合好，確保項目按時完成。當然，技術(shù)這塊也不能落下，得不斷學習新技術(shù)，提升自己的能力。不過有時候?qū)懧氊熋枋龅臅r候，容易漏掉一些細節(jié)，像是忘記提到優(yōu)化數(shù)據(jù)庫性能這部分，其實這也是挺關(guān)鍵的一塊。

寫的時候要注意，別光顧著堆砌專業(yè)術(shù)語，得讓人一看就明白是干什么的。比如說到代碼質(zhì)量，可以寫成“確保代碼整潔高效，減少后期維護成本”，這樣既專業(yè)又通俗易懂。再比如，有時候會寫成“負責系統(tǒng)的構(gòu)建和發(fā)布”，這就有點模糊了，最好改成“負責從系統(tǒng)設計到最終發(fā)布的全流程工作”。

有些地方可能會寫得不夠細致，比如只寫了“參與項目開發(fā)”，但沒具體說明是哪個階段的參與。像這樣“參與項目的需求分析、架構(gòu)設計、編碼實現(xiàn)及測試部署全過程”，就顯得更具體了。不過有時候?qū)懼鴮懼瑫恍⌒陌选皵?shù)據(jù)庫表結(jié)構(gòu)設計”寫成“數(shù)據(jù)庫結(jié)構(gòu)設計”，雖然差別不大，但還是得仔細檢查一下。

書寫經(jīng)驗40人覺得有用

寫崗位職責的時候，得結(jié)合具體的工作場景去描述。比如對于c#和asp.net的開發(fā)工程師來說，他們的工作主要是跟代碼打交道，所以職責里頭就得提到日常需要維護現(xiàn)有的系統(tǒng)，還要負責新功能的設計和實現(xiàn)。這部分內(nèi)容要具體到細節(jié)，像是說對現(xiàn)有代碼進行優(yōu)化調(diào)整，確保它們能正常運行，這個就挺重要的。

作為開發(fā)人員，肯定得參與需求分析這類事情，這是基礎工作之一。在這個過程中，可能要跟產(chǎn)品經(jīng)理或者客戶溝通，了解他們想要的功能點是什么樣的，然后把這些需求轉(zhuǎn)化為技術(shù)方案。這里需要注意的是，寫的時候別忘了提到一些具體的開發(fā)流程，比如版本控制之類的，這樣看起來會顯得更專業(yè)。

書寫注意事項：

有時候項目會有緊急情況，比如突然發(fā)現(xiàn)某個模塊出了問題，這時候就需要快速定位并解決故障了。這在崗位職責里也得體現(xiàn)出來，畢竟誰也不能保證程序永遠不出差錯嘛。所以可以寫上“能夠迅速響應線上問題，及時修復各種技術(shù)故障”。

至于職位要求，這部分可以強調(diào)一下必須掌握的技術(shù)技能，像c#編程語言、asp.net框架什么的，這些都是基本功。同時也可以提一提對數(shù)據(jù)庫操作的經(jīng)驗，畢竟很多應用都離不開數(shù)據(jù)庫的支持。不過有時候?qū)懙臅r候可能會忘記加上“熟悉sql查詢語句”這樣的關(guān)鍵點，這就有點小遺憾了。

再就是關(guān)于團隊協(xié)作這一點，其實也很重要。開發(fā)不是一個人的事情，很多時候需要和其他部門配合完成任務。所以最好能寫明“善于與團隊成員溝通合作，共同推進項目進度”。不過在這里面可能會不小心漏掉“良好的溝通技巧”這幾個字眼，這會讓整個要求顯得稍微欠缺完整性。

小編友情提醒：

記得把職責和要求分開來寫，不要混在一起。這樣既能讓閱讀者清楚地知道這份工作的具體內(nèi)容，也能讓他們明白公司期望應聘者具備哪些能力。

書寫經(jīng)驗83人覺得有用

.net軟件工程師的崗位職責工作內(nèi)容怎么寫，這事得好好琢磨一下。這類文檔通常需要把日常工作細化到具體任務，但又不能太死板，得讓人看了覺得靠譜。

先說點基礎的，像負責項目開發(fā)這部分，寫的時候別光喊口號，得把日常操作給體現(xiàn)出來。比如，“參與需求分析，跟客戶或者產(chǎn)品經(jīng)理對接清楚他們想實現(xiàn)的功能?！边@樣寫就比直接寫“負責需求分析”顯得具體些。不過有時候?qū)懙娜丝赡軋D省事，直接套話，結(jié)果就成了“負責需求對接工作”，少了點細節(jié)，給人感覺不太扎實。

再比如寫到編碼部分，“按照設計文檔編寫代碼，并進行單元測試?！边@句還行，但要是寫成“依據(jù)設計文檔開展代碼編寫及測試工作”，就有點啰嗦了。其實，有時候?qū)懙娜丝赡苁窍腼@得正式一點，但反而弄巧成拙。

還有關(guān)于維護這部分，也得寫得實在點。“對現(xiàn)有系統(tǒng)進行定期檢查，發(fā)現(xiàn)問題及時修復?！边@比那種“負責系統(tǒng)維護與優(yōu)化”之類的表述好理解多了。但也有時候?qū)懙娜藭浹a充背景，比如說具體的檢查周期或者修復流程，這就容易讓人覺得模糊不清。

書寫注意事項：

溝通這塊也很重要，得強調(diào)團隊協(xié)作?！芭c其他部門配合完成接口對接任務?！边@句話不錯，能讓人明白具體要做什么。不過要是寫成“協(xié)助其他部門完成接口相關(guān)任務”，就稍微弱化了主動性，語氣上也差了點勁兒。

再說到文檔這塊，“編寫技術(shù)文檔，確保后續(xù)人員能夠順利接手?！边@句說得挺好，但有時候?qū)懙娜藭雎晕臋n更新頻率的問題，只籠統(tǒng)地說“保持文檔同步更新”，這就有點不到位了。

最后說說問題解決這部分，“遇到技術(shù)難題時主動查找資料并提出解決方案。”這句很實用，但如果寫成“在遇到技術(shù)問題時積極尋求解決辦法”，雖然大意沒變，但總覺得少了點力度。這可能是寫的人習慣性地追求書面化表達，反而削弱了效果。