轉自：http://www.cnblogs.com/ILove/archive/2009/02/26/1398920.html
編碼人員的誤區
誤區一：因爲任務緊迫，所以沒有時間想
有些人認爲只有在領導規定的時間內完成任務纔是最重要和最緊急的。至於方向是否正確，功能是否完整則沒有時間去考慮。
這些人陷入了多寫些代碼和程序就會安全了的假象當中。殊不知方向錯了，跑得越快，損失越大。
抱有這種想法的根本原因在於他們的不自信，不知道如何分析問題，找出最佳解決途徑和細緻的評估影響面，因而無法向上級提出一個更加合理的時間。
例如： Bulk Address feature 的設計者也是說時間緊，沒時間細想。後來的結果就是這個 feature 的 design 和代碼被一次又一次的推翻和重做。而我們的 leader 也因爲反覆的向 Jerry Lu 解釋上次做錯了能否接受我們新的 Solution 而招致了 Jerry Lu 的反感。
誤區二：在最後一刻告訴 Leader 代碼寫完就算開發任務完成了
這種人認爲只要寫完代碼告訴 Team Leader ，自己就可以交差了。
如果做錯了，大不了重做；
如果漏做了，大不了補做；
如果 bug 很多，大不了 fix bug ；
自己沒考慮到，還有 Team Leader
例如：分配給做 Multi Agency admin 端 code owner 的開發時間原本是足夠的。但是他寫完代碼後，只驗證了最基本的增、刪、改、查功能，主要的業務邏輯和其他的邊邊角角的功能都沒有測試，直到上級規定完成時間的最後一刻他纔對 Leader 說任務完成了。
這樣做的嚴重後果有 2 個：
l 由於這個開發人員缺乏責任心，導致我們不得不花了比原計劃多出 30% 以上的時間去補做和補測
l 開發人員沒有意識到之前他的 Leader 對他的能力不太熟悉，所以給他的時間會比正常情況下多一些。只要發揮出正常能力和應有的責任心就可以提前完成任務。結果他不但沒有完成任務，還浪費掉了預留給他的時間。這種情況下他的 Leader 對他能力的評估只會更差，同時也增加了 Leader 對他能力的不信任。
誤區三：領導說得都是對的，我沒意見
例如：一個 Leader 在給組員講解需求和設計時，希望大家都能夠提出自己問題和想法。有個組員就對這個 Leader 說你的分析設計能力比我強，工作經驗比我豐富，你說的都對我能有什麼意見。
發生這種現象時，開發人員和 Team leader 都有需要改進的地方。
開發人員這麼說，有下列幾種可能：
1） 他當時心情不好正在鬧情緒，這時開發人員應當注意控制好自己的情緒
2） 他真的是全聽懂了，只要回答“我全明白了”就好了
3） 絕大多數內容他沒聽懂，這時他可以回答“我暫時還不能完全理解你說的所有內容。我下來再仔細看看文檔，估計 30 分鐘後再來問你好嗎？”
Team Leader 對於那些能力比較弱的人可以採取如下措施：
1） 給組員一些準備時間，在講解前告訴他們着重看那部分內容。
2） 講解完畢後，可以讓組員講出哪些分析點是他之前沒有想到的，怎樣分析才能夠分析的比較全面。
3） 如果組員的分析能力實在太弱什麼也講不出來，我們還可以鼓勵他們說出哪些內容他們沒聽明白。
這樣一來，我們對組要的要求就可以做到因人而異，且比較具體化。同時我們要求的也是組員能夠做得到的。 Team Leader 要學會 Case by Case 的教導組員如何逐步提高。
誤區四：凡事都有 Team Leader 幫忙檢查
例如：有一次 Hikelee 讓一個組員給他寫一封需要回復給客戶的郵件。很快這個組員就告訴 Hikelee 寫完了。
Hikelee 就問他說“我是否可以不做任何修改就可以把這份郵件直接發給 Anderson ？”這個組員回答說不能。 Hikelee 就讓他拿回去參看以往 Hikelee 發出的類似郵件去改，直到達到這個標準後再發給過來。
過了一會這個組員又說寫完了。這次 Hikelee 又問他，是不是 Anderson 也不需要做任何修改就可以把這份郵件直接發給我們的客戶？組員回答說不能。 Hikelee 就對他說在去看看 Anderson 以往是怎麼回覆客戶這類問題的，找到差別修改後再發給我。
誤區五：只提出問題而不負責解決，解決問題是 leader 或 PM 的事
例如：有些組員會問，我們這個 release 的加班好像是比上個 release 少了一點點，但是說實話還是太多太頻繁，我們能不能少加點班？
問話的組員只是提出了問題，卻沒有思考是不是有些必須要加班才能完成的任務自己也有責任 ? 有的話原因在哪裏，你認爲怎樣做才能夠減少或避免類似的加班？
經過我們的分析，導致這類加班我們自身的原因主要有：
1） 用人不當，由能力不足的人作分析設計導致設計失誤太多，必須要花更多的時間檢查和修補
2） 缺乏有效的分析設計技巧導致和業務領域知識，導致 Effort 估計不足
3） 編碼和 UT 素質較差，需要成倍的時間進行修補和返工
4） 工作效率低導致在規定的時間內未能完成任務而加班
5） 工作方法不當，一些無謂的等待導致了加班
根據不同的原因我們可以採取不同的策略來處理。
誤區六：整天寫代碼太單調太沒勁
有的開發人員覺得自己整天都在寫代碼， fix bug 沒勁。對上級佈置的任務也太當回事，抱着應付差事的心態在做事，你佈置一件我應付一件，你說怎麼做我就怎麼做，反正辦好辦壞都一樣。
實際上我們應該認識到無論是誰，無論能力高低都必須做到讓領導對自己所做的每一件工作滿意，纔有可能接受更高難度和更有挑戰的工作，他的職務薪資也會隨他所從事的工作難度的提高而逐步提高。
例如：以我爲例，在轉到 Accela 部門前就已經是 Team Leader 了。但是我還是被安排到從基本的編碼開始，獨自負責一個 Feature 。我把這種安排當作是一次對我的考驗，儘自己最大的努力做好。結果這個 feature 做得很好，並且在做的過程中體現出了優秀的技術能力、學習能力、溝通協調能力和很高責任心和使命感，證明了我做 Team Leader 。因此在這個新的部門做回了 Team Leader 的職務。在做 Team Leader 的過程中，也是因爲我所帶領的 team 戰鬥力強，隊員素質提高快而被提升爲 PM 。
一個開發人員，只有在他的代碼寫的很好的情況下，才能夠獲得需求分析和設計工作；只有在需求分析和設計做得都很好的情況下，才能夠做 feature owner ；只有在 feature owner 做得很好的情況下，才能夠獲做 Team Leader 。
誤區七：工作既然交給我做就應該信任我
要知道“用人不疑，疑人不用”只是個結果而不是過程。我們每個人都必須經過嚴謹的考驗後，才能夠逐步的取得領導的信任。在完成任務的過程中，領導可 以觀察出我們的能力水平。以後安排那些在我們能力範圍內的任務時，他就可以比較放心，投入較少的精力。相反如果他安排了超出我們能力範圍外的工作時，他就 必須要投入比較多的精力來監管。因此，信任不是絕對的。
如果我們想要取得領導的信任，就必須要盡我們最大的努力來做好領導安排的每一項工作，提高領導對我們能力水平的認識，做到事事讓領導放心。
誤區八：因爲一些在 bug 描述中沒有提到過得 issue ， QA reopen 我們 bug 是不對的
例如：有這樣一個 bug ， QA 只描述了在 Create Portlet 裏有問題。後來 QA 在驗證 bug 時發現開發人員只 fix 掉了 Create Portlet 裏的問題， Search Portlet 也有同樣的問題但沒被 fix 掉，因此 reopen 了該 bug 。
開發人員就說“不對， QA 你沒有提到過 Search Portlet 也有問題，這個 bug 不該被 reopen ，你應該提一個新的 Search Portlet bug 。”
這種思想是錯誤的，原因如下：
1） 不要急着先說人家 Reopen 不對，首先自己要先覈實 Search Portlet 裏的 bug 和 Create Portlet 的 bug 是否無關。如果確實無關再耐心的和 QA 解釋爲什麼應該提一個新的 bug
2） 但是無論如何出現這種狀況，我們的開發人員自身也有問題。他們不瞭解， fix bug 不是頭痛醫頭，腳痛醫腳。我們首先要找到 bug 的成因，然後分析這個 bug 成因的潛在影響面，最後徹底的 fix 掉這個 bug 。另外， bug 有個扎堆的原理，當你發現一個地方有 bug 時，往往周圍出現 bug 的機率就會比較高。所以我們一定要在這個 bug 的周圍多做一些測試。
3） 不懂的只有高標準嚴要求，才能激勵自己更快更好的發展。
4） 這種工作人員的工作心態也有問題，錯了就是錯了，不要對自己的錯誤做過多的辯解。知道自己錯誤，錯在哪裏，然後下次能夠改進就好了。因此我們需要及時的調整好自己的心態。
誤區九：上班時瀏覽技術網站學習新的技術沒有問題
我們不反對組員學習新的知識。但是應當是在自己當天的任務已經完成的前提下。如果研究的內容與我們的工作有關，我們還會鼓勵。
例如：爲了提高 fix bug 的效率我們要求在 Fix bug 階段，確認一個不能重現的 bug 最多不能超過 2 個小時。這個規定早上剛剛講完，我們就發現有個組員確認了 2 個不能重新的 bug 後，就去上網學習新技術去了。
Team Leader 的誤區
誤區一：處理客戶問題和處理一般開發任務沒有區別
有些 Team Leader 或 Feature Owner 認爲，處理客戶問題和處理一般開發任務一樣，都是把代碼寫完並完成 UT 就好了。
例如：有個組員在處理 Andrew D 要求增加實現 Filter Service 功能時，代碼做完了就報告給 PM 說任務完成了。他忽略了 Andrew 提出這個要求的目的是爲了在 IST 站點上給他的客戶進行 Demo 。
因此我們不僅需要在 QA 和開發站點上測試，還需要在 IST 站點上更新和部署相關的代碼和配置 (EMSE Script) 以驗證 Andrew 不需要做任何配置就可以看到這個新的功能。最後在 IST 站點上也驗證通過後，還要回復 Andrew 一封郵件，告知他問題已經解決。
誤區二：任務分配出去後 Owner 有問題就來找我，但是我很忙沒時間找他
Leader 要對自己管轄所有 Feature 心裏沒數，在分配給組員去做之前能夠預見到可能出現的風險，提前告知 Owner 預防風險或者密切觀察 Owner 是否能夠自己發現和規避分風險。如果問題出現了，我們要幫助組員認識到導致問題的原因是什麼，哪些方面的能力和技巧他需要學習和改進。
平時也要多和組員溝通，不要誤認爲組員不來問我就代表沒事。
例如： Hikelee 自己在做 Dynamic Web Service feature 的 Expression 部分，就把 Bulk Address 和 Alter ID Mask feature 分給了他的 2 個組員去負責，中間幾乎很少過問和檢查 feature 的狀態。結果兩個 feature 雙雙都出了問題。
誤區三：工作態度好，工作年限多的就可以做 Feature Owner
不是隻要工作態度好，工作年限多或者希望當 Feature Owner 的人就可以做 Feature Owner 。這個問題的本質是用人要當量才而用。例如，有的人做事認真，但是面向對象的分析和設計能力較弱，就不能安排他去做分析設計工作；有的人分析能力較強，但是考慮問題不周做事常做一半，處事和溝通技巧欠佳，就不能安排做 Team Leader 。