軟體公司加班，這應該是個很尋常的事情；其實加班不應該是乙個感到不舒服的事情，任何公司或單位都會加班，只是程度不同而已，程度才決定了算不算舒服。
加班不一定是壞事，看是什麼情形。
為什麼會加班呢
加班一般是沒做完事情的直接結果。
但是可能有兩種可能，一種是應該完成的事情沒有完成導致的；
另一種即是一些特殊情況，這種情況就沒什麼說的，做就做吧。
第一種情況下可能又被分成兩種情況，一種是因為時間順序被其它必須完成的任務推遲導致的，這種情況下就提醒下做之前工作的人們，然後接著做了；
另一種是自身不能在規定的時間裡完成要求質量的事情。
這話情況又被分成兩種情況，一種是因為先前提供的沒有真正達到規定的要求，導致後來做了很多補漏的工作；這種情況下，先做一件事情，將裡面的問題提出來。
另一種就完全是自身的原因了，前提很ok，自身沒有完成該做好的東西。這種情況要小心了，因為這其實意味著自身的技術還有差距，不能按質量要求完成工作。
加班的原因不只因為自己
根據上面的分析，加班的原因不單單是因為自己，可能是前提不太好，先做了很多補漏工作，當然更不爽的可能是，補漏工作花費了，最後得到結論，補漏還不如從新弄；這才是世上最讓人痛苦的，不亞於失戀，如果時間很緊，有可能真想有趕緊到世界末日的期望，一切都結束吧...呵呵，開個玩笑，還是要繼續弄呀...不過，有一點還是很重要的，不能老是出現這種情況，這些問題是需要慎重對待，不是說空話，出現問題總需要當事者或者相關人員做總結，盡可能避免設計乙個讓後來者不得不重新做設計並編寫**的東西；如果一定這樣，那設計的意義在**？開發和**工人有什麼區別？
如果是自身原因導致的，那麼深入分析一下，一般都會得到結論，那就是對於技術上的某些問題理解不夠清晰導致的。一直以來，我一直在思考什麼叫對技術問題理解很清晰？想了一遍又一遍，卻一直不能完全來詮釋這個概念，如果對於任何乙個技術問題，能從設計者的角度來解釋，那麼他基本是很清晰的了嗎？但是很多並不需要這樣，因為技術有很多，乙個人也不可能理解所有的東西。那麼，怎麼才能證明對乙個技術問題理解了呢？研究了很多關於作業系統和編譯器的東西，慢慢地這個問題的答案開始浮出水面了，那就是當能從底層來解釋或剖析乙個上層問題的原理或者過程，那這才叫對於問題很理解了。
但是，很可惜，在中國的這個軟體環境裡，一大部分弄上層，底層的東西似乎並不是很受重視，似乎只有那些搞研究的、搞嵌入式系統、驅動和架構的等這些需要能力很高的人物真正了解這些。我只能說，這犯了乙個大錯，因為不了解底層的使用上層，永遠都可能出錯，因為，上層出錯可能有很多，定位這個問題也許不難，但是理解這個問題也許不是簡單的問題，如果重視它，那麼之後犯錯的機率就降低，否則，bug只會一堆又一堆，終究快沒了，也加班地差不多了。
其實，底層不難，只是沒那麼多人費心去學習和理解，也許只需要乙個人的點拔，乙個難的問題就ok了；差就差在，公司存在這樣的人才嗎？他們在影響著整個團隊嗎？團隊是不是還在低效地改著上層的bug，真沒看到底層在偷笑麼？
xichen
2012-5-2 13:37:01
「改革」失敗的根本原因
現在總算體會到 改革 的艱辛了 而跟以前的大多數 改革 者不同的是 我不會用性命去堅持 因為我知道那樣是沒有意義的 老古董啊老古董 這樣做方便，這樣做省事 已經這樣做了 這些可以稱之為原因麼？始終無法說服我 改革 失敗的原因 除了 改革 者本來的能力和準備外 最最主要的是有兩類人存在 部分人的中立和...
根本原因缺陷分析法
軟體缺陷管理過程不僅包含軟體缺陷記錄和統計，更重要的是對缺陷資料進行細緻 深入的分析。缺陷分析是缺陷管理中的乙個重要環節，有效的缺陷分析不僅可以評價軟體質量，同時可以幫助專案組很好地掌握和評估軟體的研發過程，進而改進研發過程，未對缺陷進行分析就無法對研發流程進行改進。此外，還能為軟體新版本的開發提供...
軟體開發問題的症狀及其根本原因
症狀 對終端使用者的需求理解的不夠精確 對需求的改變束手無策 程式塊不相容 軟體不易維護或不易擴充套件 對專案嚴重缺陷的發現較晚 軟體質量低劣 軟體效能無法令人接受 開發組中的人員按各自的方式進行開發，如果有人改變了部分軟體，將很難再進行重組 乙個不可靠的構造和發布過程 原因 特別的需求管理 模糊和...