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

寫崗位職責(zé)的時候，得結(jié)合具體的崗位需求，不能一概而論。對于一個net軟件工程師來說，主要的工作就是處理各種系統(tǒng)開發(fā)的事，從設(shè)計到編碼再到測試，每個環(huán)節(jié)都得盯緊了。比如，參與系統(tǒng)的架構(gòu)設(shè)計，這很重要，要是架構(gòu)不合理，后續(xù)開發(fā)會很麻煩。還有，代碼編寫這部分也得認(rèn)真對待，不能馬虎，不然出了問題不好排查。

平時還得跟團(tuán)隊成員保持溝通，確保大家都清楚項目的進(jìn)展和目標(biāo)。有時候接到客戶的需求反饋，要快速響應(yīng)，調(diào)整相應(yīng)的功能模塊。當(dāng)然，維護(hù)現(xiàn)有系統(tǒng)的穩(wěn)定性也是份內(nèi)工作，遇到bug就得趕緊修復(fù)，不能拖著不管。要是系統(tǒng)升級什么的，也要提前做好計劃，一步步實施。

不過有時候在寫職責(zé)描述的時候，可能會忽略一些細(xì)節(jié)。比如，有些人可能只強(qiáng)調(diào)技術(shù)層面的東西，卻忘了提到需要負(fù)責(zé)協(xié)調(diào)資源，這就有點欠妥。畢竟項目推進(jìn)過程中，資源調(diào)配也是個關(guān)鍵點，少了這一塊，工作開展起來就費(fèi)勁了。

書寫注意事項：

文檔編寫這部分也不能落下，很多工程師覺得寫文檔太麻煩，但其實這是很重要的，它能幫助團(tuán)隊成員更快理解代碼邏輯。有些時候，為了趕進(jìn)度，草草寫了份文檔交差，結(jié)果后來發(fā)現(xiàn)問題一大堆，這事就鬧大了。所以，該花時間的地方還是得花，不能偷懶。

再說到時間管理這塊，得合理安排每天的任務(wù)，不能眉毛胡子一把抓。要是把所有的任務(wù)堆在一起做，最后肯定亂套。而且，有些緊急任務(wù)來了，得優(yōu)先處理，不然影響整個項目進(jìn)度就麻煩了。但有時候也會出現(xiàn)狀況，比如因為某個環(huán)節(jié)耽擱了，導(dǎo)致整個項目延期，這就挺糟心的。

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

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

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

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

書寫注意事項：

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

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

小編友情提醒：

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

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

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

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

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

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

書寫注意事項：

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

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

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

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

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

書寫注意事項：

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

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

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

小編友情提醒：

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

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

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

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

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

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

書寫注意事項：

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

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

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

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

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

書寫注意事項：

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

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

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

小編友情提醒：

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

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

寫崗位職責(zé)的時候，得根據(jù)自己了解的情況來寫，不能瞎編。比如對于一個net軟件開發(fā)工程師來說，他的主要工作肯定包括日常的代碼編寫，這算是基本任務(wù)之一。另外，還需要參與系統(tǒng)的設(shè)計與優(yōu)化，這部分內(nèi)容不能漏掉，因為這是體現(xiàn)專業(yè)能力的地方。

在描述具體職責(zé)時，可以提到一些細(xì)節(jié)，像是負(fù)責(zé)項目的技術(shù)方案制定，這很重要，畢竟方案的好壞直接影響后續(xù)進(jìn)展。還有，維護(hù)現(xiàn)有的系統(tǒng)也是必不可少的，尤其是那些已經(jīng)上線運(yùn)行了一段時間的程序，總會出現(xiàn)這樣那樣的問題，需要及時處理。

至于職位要求，除了專業(yè)的技術(shù)背景，比如熟悉c#、asp.net之類的技術(shù)棧外，還應(yīng)該強(qiáng)調(diào)溝通能力。為什么？因為工作中難免會跟其他部門打交道，良好的溝通能提高效率。不過有時候?qū)懙臅r候可能會忘記補(bǔ)充這一點，只顧著列技術(shù)點去了，這就不太好了。

書寫注意事項：

工作經(jīng)驗?zāi)晗捱@一塊兒也要寫清楚，比如說要求至少三年以上的相關(guān)經(jīng)驗。但有時候?qū)懙娜丝赡軟]注意到，這樣的表述可能會讓一些剛畢業(yè)的優(yōu)秀人才被忽視，雖然初衷不是如此，但確實是潛在的問題。

再說到開發(fā)流程這塊兒，應(yīng)該涵蓋從需求分析到測試驗收的全過程，這些都是日常工作的一部分。不過有時寫著寫著就容易漏掉測試這一步，覺得只要代碼寫得好就行，殊不知測試環(huán)節(jié)同樣關(guān)鍵，甚至可以說是保障產(chǎn)品質(zhì)量的最后一道防線。

小編友情提醒：

關(guān)于薪資待遇之類的敏感話題，如果是在內(nèi)部文檔中提及，倒是可以適當(dāng)帶過一下，但如果是對外發(fā)布的招聘啟事，最好還是省略掉比較好，免得引發(fā)不必要的爭議。當(dāng)然，要是寫的時候不小心把不該寫的寫進(jìn)去了，那也只能重新修改了。

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

寫崗位職責(zé)的時候，得結(jié)合實際的工作內(nèi)容來寫，不能太籠統(tǒng)。像net軟件開發(fā)這個崗位，一開始就得提到需要熟悉.net框架相關(guān)的技術(shù)，這很重要，因為這是工作的基礎(chǔ)嘛。平時工作中要負(fù)責(zé)項目的編碼實現(xiàn)，這部分得強(qiáng)調(diào)一下具體的任務(wù)，比如說完成某個模塊的功能開發(fā)，還有就是解決項目中的關(guān)鍵問題和技術(shù)難題。

在日常的工作里頭，可能還會涉及到跟其他部門溝通協(xié)作，這就需要能清楚地表達(dá)自己的想法，不然容易產(chǎn)生誤會。對于一些比較復(fù)雜的系統(tǒng)設(shè)計，需要提前做好規(guī)劃，確保后續(xù)開發(fā)順利進(jìn)行。有時候接到需求后，得快速評估可行性，這個環(huán)節(jié)很關(guān)鍵，因為如果評估不準(zhǔn)，后面可能會出大問題。

書寫注意事項：

代碼質(zhì)量這塊兒也不能忽視，得定期檢查自己的代碼，看看有沒有潛在的問題，像是內(nèi)存泄漏什么的，這些問題如果不及時處理，積累多了就麻煩了。而且，隨著項目推進(jìn)，可能會遇到各種意想不到的情況，這時候就需要靈活應(yīng)對，不能死板地照著原來的計劃走。

其實，寫崗位職責(zé)的時候，最好能把具體的工作場景融入進(jìn)去，這樣別人看了才知道你是干什么的。比如，當(dāng)用戶反饋某個功能有問題的時候，就得第一時間響應(yīng)，分析原因，盡快修復(fù)。還有，團(tuán)隊里的技術(shù)分享會也是少不了的，通過這樣的方式可以互相學(xué)習(xí)，提升整個團(tuán)隊的技術(shù)水平。

不過有時候?qū)懼鴮懼腿菀茁┑粢恍┘?xì)節(jié)，比如忘記提測試的重要性了。做軟件開發(fā)，測試環(huán)節(jié)必不可少，無論是單元測試還是集成測試，都得認(rèn)真對待。要是某個功能上線后發(fā)現(xiàn)bug，那前期的努力就白費(fèi)了。所以呀，在寫崗位職責(zé)的時候，這些細(xì)節(jié)能不能都涵蓋到，還得仔細(xì)琢磨一下。