又一次情緒激動、氣氛高度緊張的會議，這一次是商議如何讓目前這個重要專案「重回正軌」——計畫的完工日期早已超了幾個星期。所有的這些場景聽起來都很耳熟嗎？我想說的是，專案超期在任何行業裡都是常見的事情。
然而，軟體行業裡看起來更容易出現這種情況。
我們怎麼會走到這種地步的？這還要從我們夢開始的地方說起。所有的開始都是精神抖擻、幹勁十足。
乙個漂亮的創意，這次我們發誓絕不會重蹈上次的覆轍，不會犯上次的錯誤。這次我們告訴自己，這次的計畫將會「正確」的執行，不會圖省事，也不會中途變更。經常有時候我們會感覺夢想正朝正確的方向前進，設計很成功，每個人都很樂觀，外界評論也很好。
然後，噩夢開始降臨，因為各種打擊開始出現。
系統中最容易的部分卻耗用了大家全部的時間。乙個微小的疏忽就可能意味著當初一系列簡單的假設都不再成立。錯誤的假設產生連鎖效應，導致系統設計陷入死局。
需要對設計進行修改來糾正這些問題。希望仍然存在，只要付出足夠不眠之夜和週末加班，我們仍然能讓專案「重回正軌」。
具有里程碑意義的原型終於誕生了，所有人都充滿信心，因為原型表現的非常好。外人不知道這是多少個通宵達旦的努力換來的。很快，「小需求」開始出現。
通常的說辭都是從「這有什麼難的？」或「這真的很簡單！」開始，更經典的話是「如果我們能夠…那將會太神奇了」。
通過交換意見發現，這些新增的小的功能特徵不僅看起來「簡單」，而且實際可做。當然，你是不會說不的，然而，歷史的悲劇即將重演。
現在，你和你的團隊終於回到了現實世界，再次檢視這些新增需求。在經過了近距離的觀察這些看起來「非常簡單的功能特徵」後，突然意識到它們並不像起初聽起來的那樣簡單。但為時已晚，你已經答應了這些新修改。
「呯！」你的郵箱通知你有了一封新郵件，真是火上澆油，銷售已經向客戶許諾。銷售向客戶談到了這些「簡單」的新功能，而客戶提出來更多他們想要的「更簡單」的新功能。
銷售照單全收，因為這些新需求聽起來比起初那些更簡單。
程式設計師們，請勇於說不
停，不能這麼幹
在80年代和90年代期間有乙個非常流行的運動口號：「just say no」，是用來宣傳讓孩子們遠離毒品。不管你是否還記得這場運動，它表達的資訊是非常有力的。
相似的，我們應該使用同樣的語氣來面對我們遇到的問題。
當然，我並不是在慫恿抵制任何的需求變更。從我的角度，任何需要編碼開發的新增內容我都會用紅線劃分開。但諸如介面或前端內容的修改不包括在內。
任何新增需求在接受前一定要確定相應的充裕的追加時間。內心裡對新需求的預設反應應該是「just say no」。當然，並不需要從表面上暴露這種反應，可以用適當的外交手段達到這種效果。
在專案開始之日，任何乙個最初沒有規劃的「需求變更」都要謹慎斟酌。任何後來新增的功能特徵都要堅持這個原則。有了這個原則你很容易說出「不」。
因為這是乙個標尺，所有人都明白，後加的新功能會耗費額外的時間。把這種壓力放在客戶和老闆的身上，要麼延緩完工日期，要麼放棄另外乙個功能做替換。
結論有各種各樣的原因會導致乙個軟體專案不能按時完工。專案進展緩慢，程式設計師持續在高強度壓力下工作，這使專案開發時間的預估變得更加困難。程式設計師應該有心理準備，新增需求的情況肯定會出現。
把「just say no」記在心裡，多少能預防你張嘴就說「行」的習慣。玩槍很危險，給槍加上保險裝置，至少能防止傷了自己的腳。
科學發展中要勇於自我批評
俗話說，金無足赤，人無完人。只要幹工作，總會有不足，就有可能犯錯誤。乙個人的工作有缺點毛病並不可怕，可怕的是諱疾忌醫，以致 小疾 拖成 大病 良藥苦口利於病，忠言逆耳利於行 只有能夠虛心接受批評的人，才能不斷地改造自我 提高自我 完善自我。而在虛心接受批評的同時，自我批評則顯得更加重要。自己的問題自...
職場工作中要勇於承擔責任
有個故事很受啟發。約翰和戴維是新到速遞公司的兩名員工。他們倆是工作搭檔，工作一直都很認真，也很賣力。上司對這兩名新員工也都很滿意，然而一件事卻改變了兩個人的命運。一次，約翰和戴維負責把一件大宗郵件送到碼頭。這個郵件很貴重，是乙個古董，上司反覆叮囑他們要小心。沒想到，送貨車開到半路卻壞了。戴維說 怎麼...
單位口頭說要辭退你
如果用人單位口頭說要辭退你，你在沒有接到正式書面通知 蓋有公章 前，按時上班，或要求用人單位給你乙個書面通知。如果僅憑用人單位口頭說你明天不用來上班了，你就不來的話，到時用人單位會說是沒有人說過不讓你上班，是你自己曠工數日，按你自動離職處理了。被用人單位辭退或解除勞動合同，分三種情況，一是勞動者有 ...