注：本文僅為**，原文被牆，向作者李建盛致謝！原文傳送門：
軟體開發的相關從業者可能經常會遇到這樣的情況，老闆總是靈感閃現或以客戶的需求的名義，告知三個月必須完成某個專案。然後大家開始加班加點的幹。當然最後的結果是三個月之後天沒有塌，老闆又開始要求其它的事情了。如此反覆。直到老闆將錢燒完。企業倒閉。
「大躍進」是乙個歷史名詞，是指2023年到2023年中國的政治運動的乙個總稱，具體表現就是完成了社會主義初級階段，要向共產主義進軍，鋼鐵產量要趕超英美，人民公社成立，天天放衛星，各種奇葩事件層出不窮。詳情請fqgoogle「大躍進」。
這裡意指專案干係人不是根據實際情況出發，不作科學的分析，而重點強調目標，以密集的勞動表現為考察人的一切標準，以意志力可以戰勝一切為信條，不切實際的提出在某個時間段內完成某件重要的軟體工程專案。
事實上我們在實際的工作當中，這樣的事情是經常遇到的。筆者對於去年經歷過的事情到現在想起來仍然心有餘悸。過程是這樣的，大約在去年十月初的長假結束後，公司就像大多數國內的openstack廠商一樣要從原來的解決方案提供商轉型作公有雲平台，而我作為開發的負責人只是在這之前的三個月領到乙個任務：建立基於openstack的研發團隊，團隊裡也就6個人不到，當時老闆拍桌子要求，11月中旬完成上線，必須使用基於openstack作為平台。嗯，然後我就懵了，這怎麼可能完成？我當時想的是整個的開發到實施的流程，選型、測試、開發、發布、實施、除錯的一系列過程，人員的招聘、團隊的建設、架構的設計、團隊成員學習／適應的曲線等等，而這一系列的評估本身也要花一些時間的，然後，決策在當時不到半小時的會議就決定了－放棄目前團隊的開發，直接購買紅帽的現成產品。故事就講到這裡，後面的結果閱讀筆者的部落格的都明白，這樣的決策是戲弄人也罷侮辱人也罷都成為我個人的經歷一部分，感謝這樣的機會讓我成長！
當然，類似的事情經歷的不止一次兩次了，尤其是遇到實際專案的時候。那麼我就我個人的經歷，以及對於周邊的觀察，同時通過讀書和網路學習到的，對於遇到類似的事情如何防範，這也是本文的目的。
但是，話說回來，作為工程師或者專案主管、架構師、技術總監的身份，或者是常見的企業架構的樹狀結構的非根的部分，能夠做到有效防治是非常困難的事情，多數時候最終的決策不是你，但是，事情往往並非那麼的絕對，前提是老闆能夠做到就事論事，不是過於的武斷專行，下面的內容還可以繼續。如果事實的情況就是「老子天下第一」，那麼對不起，你有兩個選擇，0、乖乖聽話，做乙個聽從指令的機械人。1、換個老闆，或者自己做老闆。
請做到以下幾點：
下面是上述三點的細節討論：
絕大多數的現代企業，老闆都是受過高等教育，有理想、有才華的人，即使不是，也會找乙個職業經理人作為企業的決策者，所以，即使深受壓力，一般也能理性的接受有理有據的原因。而我們要做的就是提供科學的證據，不妨學習亞馬遜的貝佐斯的**方式。要提供下面的內容：
達成共識的目標（或者是老闆一廂情願的）；
目標的細節描述，諸如使用者群體、產品功能列表、sla級別等等；
目前的資源，包括工程師、機房、網路；
就目前的狀況，要做到1的目標，工作強度x1.5，需要多長的時間；
工程師數量翻2番的情況，要做到1中的目標，工作強度x1.5，需要多長的時間；
工程師之間的溝通、協調、適應，會延長專案的週期；
就目前的技術力量／儲備，要完成1中的目標需要那些挑戰／學習；
招聘的難度。
如果非的從上述8條中選擇乙個最為重要的題目的話，1是最為重要的了。這可能是中和了決策者的願景、市場分析、直覺、對於團隊的信心等各方面所提出來的。如果是頭腦發熱、拍腦袋臨時起意的話，不在討論範圍之內。
溝通，這是最難的事情，人類如果沒有溝通的問題，那就真的能夠造出巴比塔，世界再無爭端。童年背景、學歷、文化觀念、知識、脾氣、情緒的控制、心腸、頭腦等等都是溝通的障礙。但是難不等於不可能，首先自己要做到：
國內的一些公司在管理上還停留在工業時代，畢竟中國改革開放才30多年，多數是從自上而下、流程化的「豐田模式」「彼得德魯克語錄」等等出發的，再加上「大集體」「文革」「工人階級」「國有企業」等餘毒，當然，還有」儒家傳統「」家族管理「等中國傳統的意識形態。管理基本是一片狼籍，文化上甚至羨慕華為等」狼文化「軍事體制，所以如果你自己已經進入了當代，即知識經濟時代的話，仰慕矽谷文化，期盼扁平化，尋找授權，接受自己願意的挑戰，那麼就得試圖去影響它、改造它，因為你要的結果是成就自我。
請嘗試去做到下面幾點：
當然，本文的內容，是過去筆者自己對於工作中的乙個回顧和反思，我自己也沒有做的很好，最後以失敗告終，告別自己親手打造的團隊；告別自己熱愛的所開發的產品。一切正如年初寫的部落格：我為什麼停下來，在此寄希望於後來者。也希望自己在以後的事業中能遇到能夠做到上述幾點的優秀而卓越的人！
軟體專案中的風險管理
http www.csai.cn 2005年07月27日 1.引言 軟體專案風險是指在軟體開發過程中遇到的預算和進度等方面的問題以及這些問題對軟體專案的影響。軟體專案風險會影響專案計畫的實現，如果專案風險變成現實，就有可能影響專案的進度，增加專案的成本，甚至使軟體專案不能實現。如果對專案進行風險管理...
軟體專案中的基礎測試
軟體專案中的基礎測試 單元測試 ut 什麼是單元測試 單元測試 又稱為模組測試 是針對程式模組 軟體設計的最小單位 來進行正確性檢驗的測試工作。序單元是應用的最小可測試部件。在過程化程式設計中，乙個單元就是單個程式 函式 過程等。單元測試流程 在傳統軟體開發過程中，單元測試是在編寫完模組 後開始進行...
軟體專案中存在的問題
在學習 軟體工程 前，我個人倒是著實作了點專案，個人做的和團隊合作的都有。但無論是個人做或是團隊合作，給我印象最深的就是分工不明，雖然這種組織專案開發的方式快速，但與此對應所帶來的惡果常常是混亂和持續不斷的錯誤，並使得開發熱情迅速消耗殆盡，最後變成了磨洋工。學了 軟體工程 之後，覺得自己的思路開闊了...