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

寫崗位職責(zé)的時候，得根據(jù)自己對工作的理解來，不能太籠統(tǒng)。比如軟件開發(fā)工程師這個崗位，你得先想想日常工作都有什么。比如日常就是寫代碼、調(diào)試程序、解決bug之類的，那職責(zé)就得具體到這些點上。像寫代碼這部分，不能只說負責(zé)編碼，得詳細點，像負責(zé)設(shè)計系統(tǒng)架構(gòu)、編寫高質(zhì)量代碼之類。

職責(zé)里最好能體現(xiàn)一些專業(yè)術(shù)語，這樣顯得比較專業(yè)。比如說負責(zé)數(shù)據(jù)庫的設(shè)計與優(yōu)化，這比單純說管理數(shù)據(jù)庫要好。不過有時候?qū)懙臅r候可能會有點亂，像我剛才提到的“管理數(shù)據(jù)庫”就有點口語化，不如“負責(zé)數(shù)據(jù)庫的運維與性能調(diào)優(yōu)”聽起來正式。

任職資格這塊也得細寫，不能光說要求本科及以上學(xué)歷，還得具體到專業(yè)背景。像計算機科學(xué)與技術(shù)相關(guān)專業(yè)畢業(yè)的優(yōu)先，這樣更有針對性。還有工作經(jīng)驗，不能只寫多少年經(jīng)驗，得結(jié)合具體的工作內(nèi)容，比如有大型項目開發(fā)經(jīng)驗的優(yōu)先錄用。

有時候?qū)懙臅r候會不小心漏掉一些重要的東西，像是對編程語言的要求，像java、python之類的，這很重要，要是忘了寫進去，后面招人的時候就會很麻煩。再比如團隊協(xié)作能力，這是軟件開發(fā)里特別重要的一塊，要是沒寫進去，可能就會錯過一些優(yōu)秀的候選人。

寫職責(zé)的時候，最好能結(jié)合公司的實際情況，像有些公司可能特別注重代碼質(zhì)量，那職責(zé)里就可以強調(diào)代碼審查這一塊。另外，有時候?qū)懙臅r候會忘記提到對新技術(shù)的學(xué)習(xí)要求，其實這一點也很關(guān)鍵，畢竟軟件開發(fā)變化挺快的。

小編友情提醒：

寫的時候要注意格式，職責(zé)和資格分開寫，這樣看起來會比較清晰。不過有時候?qū)懼鴮懼?，順序可能會搞混，像把資格條件寫到職責(zé)里去了，這樣的情況得注意避免。

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

寫崗位職責(zé)的時候，得先弄清楚這個崗位到底干什么的。比如說android軟件開發(fā)工程師，這可不是敲敲鍵盤那么簡單的事。這個崗位的職責(zé)肯定跟軟件開發(fā)流程掛鉤，從需求分析到設(shè)計、編碼、測試，再到上線后的維護，每一步都得有明確的任務(wù)描述。

需求這塊，得知道客戶想要什么，然后把需求轉(zhuǎn)化成技術(shù)方案，這中間可能需要跟產(chǎn)品經(jīng)理反復(fù)溝通。比如，客戶說想做一個能實時定位的應(yīng)用，那你就得搞清楚定位精度的要求，是用gps還是網(wǎng)絡(luò)定位，這些都得提前想好。不過有時候?qū)懙臅r候可能會漏掉細節(jié)，像沒提到需要對接第三方地圖api，這就有點不夠周全了。

設(shè)計階段，要規(guī)劃好整個應(yīng)用的架構(gòu)。像模塊劃分、接口定義之類的，得確保各部分能協(xié)同工作。這里頭容易出問題是，可能會忽略掉一些邊界條件，比如數(shù)據(jù)傳輸失敗時的處理邏輯。這部分職責(zé)要是寫得不清不楚，后續(xù)開發(fā)起來就會麻煩。

編碼這一塊就不用多說了，得嚴格按照設(shè)計文檔來寫代碼。注意代碼規(guī)范很重要，不然后期維護起來費勁。記得有一次我寫代碼的時候，忘記給一個變量加上初始化值，結(jié)果調(diào)試了好幾天才找到問題，這也算一個小教訓(xùn)吧。

測試也很關(guān)鍵，得保證軟件質(zhì)量。不僅要自己測，還得讓其他同事幫忙測，看看有沒有什么潛在的問題。有時候?qū)懧氊?zé)的時候，可能會只強調(diào)單元測試而忽略了集成測試，這樣其實不太全面。

上線之后也不是萬事大吉了，還得持續(xù)關(guān)注用戶體驗。收集用戶反饋，及時修復(fù)bug。這方面要是寫得太籠統(tǒng)，比如只是說“負責(zé)后期維護”，就顯得太模糊了。最好具體點，比如提到定期檢查日志文件，查看是否有異常情況發(fā)生。

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

軟件開發(fā)工程師在電信行業(yè)的崗位職責(zé)其實挺復(fù)雜的，得從幾個方面去考慮。比如，日常的工作里頭，要負責(zé)一些系統(tǒng)的維護，這包括了檢查系統(tǒng)運行狀態(tài)，發(fā)現(xiàn)問題及時處理。有時候會遇到一些緊急情況，比如某個功能突然失效，這時候就得迅速定位問題所在，可能是代碼哪里出了問題，也可能跟硬件有關(guān)。

還有就是新項目的開發(fā)工作，需要參與需求分析，跟其他同事討論設(shè)計方案。在這個過程中，可能會遇到各種各樣的技術(shù)難題，比如接口對接不順暢，數(shù)據(jù)庫查詢效率低這些問題。解決這些問題的時候，往往需要查閱大量的資料，甚至要向同行請教，畢竟每個人的經(jīng)驗都不一樣。

書寫注意事項：

代碼編寫這部分也是很重要的，得確保代碼質(zhì)量，符合公司的編碼規(guī)范。寫代碼的時候要注意細節(jié)，一個小小的疏忽都可能導(dǎo)致整個程序崩潰。有時候?qū)懼鴮懼?，可能會發(fā)現(xiàn)自己寫的某段代碼邏輯有點混亂，這就需要停下來重新梳理一下思路。

文檔編寫也不能忽視，項目相關(guān)的技術(shù)文檔、用戶手冊這些都是必不可少的。文檔得寫得清晰明了，不然以后別人接手項目會很麻煩。不過有時候?qū)懳臋n的時候，可能會因為趕時間而忽略了一些細節(jié)，導(dǎo)致后來出現(xiàn)問題。

團隊協(xié)作也很關(guān)鍵，開發(fā)過程中少不了和其他部門溝通協(xié)調(diào)。有時候可能會遇到意見不合的情況，這個時候就需要耐心地交流，找到大家都認可的解決方案。要是溝通不到位，可能會影響項目的進度。

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

寫崗位職責(zé)的時候，得結(jié)合具體的工作場景和需求。比如對于一個c語言軟件開發(fā)工程師來說，主要就是負責(zé)代碼編寫、調(diào)試和優(yōu)化這部分工作。日常得參與項目的討論，確定技術(shù)方案，這很重要。還有就是跟團隊成員交流溝通，確保大家都明白任務(wù)目標(biāo)，這個環(huán)節(jié)也不能忽視。

平時，要能快速定位程序里的問題點，找到原因后及時修復(fù)。遇到復(fù)雜的問題，可能需要查閱相關(guān)資料，甚至找供應(yīng)商的技術(shù)支持幫忙。有時候項目時間緊，加班加點趕進度也是常有的事。當(dāng)然，除了完成自己的本職工作，還應(yīng)該主動學(xué)習(xí)新技術(shù)，保持對行業(yè)動態(tài)的關(guān)注。

文檔這塊兒也挺關(guān)鍵的，要記錄好每次修改的內(nèi)容，包括為什么改、怎么改的，這樣方便后續(xù)維護。要是公司有代碼審查流程，就得認真對待，仔細檢查別人的代碼，同時也接受別人對自己代碼的反饋。偶爾也會碰到一些棘手的情況，像是兼容性問題，這時候就需要耐心分析，一步步排查。

再說了，跟客戶對接的需求也不容小覷，有時候他們提出的想法未必可行，這時就要用專業(yè)角度去解釋為什么，能不能實現(xiàn)。另外，測試階段也要全程參與，協(xié)助測試人員理解功能邏輯，確保最終交付的產(chǎn)品質(zhì)量過關(guān)。

有時候，為了提升效率，會用到一些自動化工具，像構(gòu)建腳本之類的，這就要求熟悉相關(guān)的命令行操作。偶爾還會有一些突發(fā)狀況，比如服務(wù)器宕機什么的，這時候就得迅速反應(yīng)，盡快解決問題。

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

寫崗位職責(zé)的時候，得結(jié)合實際工作情況去描述，不能太籠統(tǒng)。比如說高級c 軟件開發(fā)工程師這個崗位，就得具體到技術(shù)層面。平時工作中，主要負責(zé)的就是一些核心模塊的設(shè)計與編碼，這部分內(nèi)容肯定要寫進去，不然就顯得很空洞。另外，還要涉及跟團隊成員的溝通協(xié)作，這點也很關(guān)鍵，畢竟項目推進不是一個人的事。

有時候在寫職責(zé)的時候，可能會忘記提到一些細節(jié)，像參與需求分析這類事情，其實也是日常工作的一部分。還有就是代碼審查，這能保證代碼質(zhì)量，但不少人在寫職責(zé)時容易漏掉。另外，對于新技術(shù)的研究也不能忽視，這有助于提升整個團隊的技術(shù)水平，只是有時候會因為覺得理所當(dāng)然而沒寫清楚。

除了技術(shù)相關(guān)的工作，還有一些管理性質(zhì)的任務(wù)也得涵蓋，比如指導(dǎo)初級工程師解決問題。不過有時候會把這部分內(nèi)容寫得過于簡略，像是“協(xié)助團隊成長”這樣一句話帶過，實際上應(yīng)該詳細描述具體怎么做。還有培訓(xùn)新員工的部分，這也是職責(zé)之一，但往往會被一筆帶過，沒有突出重要性。

在寫這些職責(zé)的時候，最好能融入一些具體的例子，這樣能讓職責(zé)看起來更有說服力。比如可以提到曾經(jīng)主導(dǎo)過某個大型項目的開發(fā)流程，或者成功優(yōu)化了某項性能瓶頸。不過有些時候可能會忽略這一點，只列出一堆看似高大上的職責(zé)，卻沒有實際案例支撐。

書寫注意事項：

職責(zé)里還可以加上對外部客戶的溝通內(nèi)容，尤其是在涉及到產(chǎn)品交付的情況下。但有時會遺漏這部分，認為這是銷售部門的事情，其實不然，開發(fā)人員也需要參與其中。還有就是版本控制這塊，確保代碼庫的整潔和安全，這也是一份重要的責(zé)任，偶爾會被忽略。

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

寫java軟件開發(fā)工程師初級崗位職責(zé)的時候，得先搞清楚這個職位到底要干什么。一般來說，這個崗位主要負責(zé)一些基礎(chǔ)性的代碼編寫工作，像是參與項目需求分析，然后根據(jù)設(shè)計文檔去實現(xiàn)功能模塊。當(dāng)然，剛?cè)胄械男“卓赡芨鄷r候是在前輩指導(dǎo)下干活，像跟著做些單元測試，確保代碼質(zhì)量。還有就是日常維護現(xiàn)有的系統(tǒng)，遇到問題及時排查修復(fù)。

其實，崗位職責(zé)不是一成不變的，每個公司可能側(cè)重點不一樣。比如說有的公司會要求新員工熟悉公司的技術(shù)棧，盡快融入團隊；有的則可能更看重學(xué)習(xí)能力，希望新人能快速掌握新技術(shù)。所以寫的時候得結(jié)合實際情況，不能太死板。像我們之前有個同事剛?cè)肼殨r，就被安排了不少文檔整理的工作，說是為了讓他更好地理解業(yè)務(wù)流程，雖然聽起來有點浪費時間，但確實挺有用的。

書寫注意事項：

寫職責(zé)描述的時候，最好能把具體任務(wù)細化一下。比如“參與代碼編寫”就太籠統(tǒng)了，可以改成“負責(zé)后端接口開發(fā)，包括用戶登錄認證模塊的設(shè)計與實現(xiàn)”。這樣不僅顯得專業(yè)，還能讓應(yīng)聘者對自己即將承擔(dān)的工作有個清晰認識。不過有時候?qū)懧氊?zé)描述的人可能會漏掉一些關(guān)鍵點，比如忘記提到需要定期參加團隊的技術(shù)分享會，這對新人的成長可是相當(dāng)重要。

再來說說注意事項，千萬別把職責(zé)寫得太模糊。像“協(xié)助完成相關(guān)工作”這樣的表述就很空泛，沒人知道具體要幫什么忙。最好是能明確到具體的任務(wù)范圍，比如“協(xié)助開發(fā)人員完成支付功能的集成測試”。還有就是要注意措辭，別讓人覺得這個崗位只是打雜的，得體現(xiàn)出一定的技術(shù)含量。像“配合完成項目部署”這種說法就不太好，不如改成“負責(zé)生產(chǎn)環(huán)境下的應(yīng)用部署及監(jiān)控”。

有時候?qū)懧氊?zé)描述的人可能會因為疏忽，把某些重要的職責(zé)遺漏掉。比如忘了提數(shù)據(jù)庫表的設(shè)計審核，或者沒寫明需要定期提交開發(fā)進度報告。這些都是比較容易忽略的地方，但其實都挺關(guān)鍵的。尤其是對于初級崗位來說，很多細節(jié)都需要通過這些職責(zé)來體現(xiàn)出來，畢竟新人的經(jīng)驗有限，得有人帶著一步步成長才行。

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

寫崗位職責(zé)的時候，得結(jié)合具體的工作場景，像安卓高級軟件開發(fā)這活兒，它不是單純敲代碼那么簡單。平時負責(zé)項目里的核心模塊開發(fā)，這得對架構(gòu)設(shè)計什么的特別熟悉才行。還有，日常跟團隊成員溝通需求和技術(shù)方案也是少不了的，畢竟一個人單干搞不定大項目。

工作中遇到技術(shù)難題，那得第一時間去解決，不能拖著，不然影響進度。比如說某個功能實現(xiàn)起來比較復(fù)雜，就得帶著團隊一起分析，找出最優(yōu)解。有時候客戶提出的新需求也得快速響應(yīng)，這就需要對現(xiàn)有代碼庫很了解，能迅速評估可行性。

文檔這塊也不能忽視，每次完成一個模塊的開發(fā)，都得寫清楚文檔，方便后續(xù)維護。當(dāng)然，有些時候可能因為趕時間，就草草寫了點東西應(yīng)付過去，這樣其實不太好，長遠來看會增加工作量。

書寫注意事項：

還得時刻關(guān)注最新的技術(shù)動態(tài)，安卓那邊更新迭代快得很，新版本出來得趕緊學(xué)，不然很快就被淘汰了。要是覺得培訓(xùn)機會少，也可以自己找資源看，網(wǎng)上好多優(yōu)質(zhì)的教程。

跟其他部門的合作也很重要，像產(chǎn)品經(jīng)理、ui設(shè)計師什么的，他們提供的需求描述可能有點模糊，這時候就需要多問幾句，確保理解無誤。有時候也可能是因為溝通不到位，導(dǎo)致開發(fā)出來的功能跟預(yù)期差那么一點，但這不是借口，得主動調(diào)整。

測試環(huán)節(jié)也不能光靠別人提bug，自己得提前預(yù)判可能出現(xiàn)的問題，提前做好預(yù)防措施。有時候?qū)懘a的時候太專注于功能實現(xiàn)，就容易忽略邊界條件，結(jié)果測試階段才發(fā)現(xiàn)一堆漏洞，這就顯得有點被動了。

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

寫崗位職責(zé)的時候，得結(jié)合具體的工作內(nèi)容和需求。比如說對于一個bi軟件開發(fā)工程師來說，這人主要負責(zé)的就是業(yè)務(wù)數(shù)據(jù)分析這塊兒的事。他得熟悉各種數(shù)據(jù)庫的操作，像sql之類的，能寫出高效的查詢語句。還要懂一些數(shù)據(jù)倉庫的概念，因為經(jīng)常要用到etl流程，從不同的系統(tǒng)里抽取數(shù)據(jù)，清洗之后加載到數(shù)據(jù)倉庫里。

這個崗位需要跟前端那邊配合好，畢竟最終是要把這些分析結(jié)果展示出來的。所以得會點前端技術(shù)，像javascript、html、css什么的，至少要知道怎么嵌入圖表庫，像是echarts或者highcharts。有時候還會涉及移動端的適配，那就要了解下響應(yīng)式設(shè)計那些東西了。

再說了，開發(fā)過程中肯定會有測試環(huán)節(jié)，這部分也得參與。不僅要保證功能正常運行，還得確保性能達到預(yù)期。要是碰到復(fù)雜查詢效率低下的情況，就得優(yōu)化sql語句，甚至調(diào)整索引什么的。不過有時候可能會忽略掉一些細節(jié)，比如忘記檢查某些特殊情況下的邊界條件，這就容易出問題。

書寫注意事項：

文檔也是不能忽視的部分。每個模塊的功能實現(xiàn)都得有詳細的說明，方便后續(xù)維護。不過有時候?qū)懳臋n的時候可能會太簡略，只寫了大概的思路，具體的參數(shù)配置和調(diào)用方式都沒交代清楚，這就給后來接手的人增加了不少麻煩。

再就是溝通這一塊兒，跟業(yè)務(wù)部門保持良好的交流很重要。他們提出的需求往往比較模糊，需要通過反復(fù)確認才能明確下來。但有時候可能會過于依賴自己的理解，沒有及時反饋給對方，導(dǎo)致最后做出來的東西不符合預(yù)期。

小編友情提醒：

還要關(guān)注新技術(shù)的發(fā)展。bi領(lǐng)域變化挺快的，新的工具和方法層出不窮。如果一直停留在原有的技術(shù)水平上，很容易被甩開。當(dāng)然，學(xué)習(xí)新東西也不是一蹴而就的，可能有時候會因為工作忙而拖延，但這絕對不是個好習(xí)慣。