對人員不夠關心和重視；過度的進度壓力；缺乏激勵；過分誇張的激勵等。
人員能力欠佳，工作效率低，甚至做多錯多。
不對有問題的人員採取措施是專案組成員對領導最常見的抱怨。
強調個人英雄主義會導致發生額外的風險，也會削弱在軟體開發過程中多個角色的合作。
盲目地在專案後期加入人手等於火上澆油。
擁有安靜、隱蔽辦公環境的人員比工作在嘈雜、擁擠環境中的人員往往會有更好的工作業績表現。
主要原因是缺乏溝通。這種摩擦耗費時間，它會轉移客戶和開發人員雙方對專案工作的注意力。
過高的期望值和主觀的不切實際的設想。是導致開發人員和客戶或專案經理之間的摩擦常見原因之一。
軟體開發專案的許都方面都需要高層的支援，包括實際的計畫、變更控制以及新型開發方法的採用等。缺乏有效的高層支援事實上注定了專案的失敗。
軟體開發中所有主要人員必須齊心協力專注於專案，包括高層支持者、專案領導、專案成員、市場人員、終端使用者、客戶和任何專案介入者。
沒有使用者早期介入的專案充滿需求誤解的風險，易受專案後期功能蔓延的威脅。
「政治家」型專案強調「管理至上」，主要精力集中在他們與經理的關係上。將政治凌駕於結果之上對軟體專案會造成極大傷害。
閉上眼睛毫無理由地希望某事將像想象那樣運作。很多軟體開發問題都是由於充滿想象造成的。
想象示例：
過 程定製過於樂觀的專案計畫相當於自己為專案失敗畫出了底線，導致縮短分析、設計等關鍵性前期開發活動；同時也向開發人員施加了額外壓力，會長期對開發人員的自信心和生產率造成巨大傷害。
如果你不主動管理風險，風險隨時會來找你，打亂你的開發計畫。
如果不對承包商加以認真管理，交付可能延期，並且質量難以保證。
沒有計畫的專案就像飄盪在海洋中的小船，沒人知道會飄到**。
很多專案組定製了計畫，但遇到了麻煩時就放棄計畫。專案失敗的原因不是在於放棄計畫本身，而是不能及時修訂計畫制定替代計畫，並一頭栽進編碼和問題處理中。
由於花在審批、預算等前期工作的時間過長，或需求無限迴圈等原因，導致壓縮開發計畫。專案前期節省幾周或幾個月時間比將開發計畫壓縮同樣時間來得更容易、更廉價，風險也更少。
研究資料：
前期被跳過的活動或工作通常在後期會以10倍到100倍的代價來完成。如果一項工作在專案初期需要5小時完成，那麼在專案後期你至少需要50小時才能完成它。 （fagan 1976，boehm and papaccio 1988）
前期活動不符合要求的乙個特殊情況就是設計低劣。高壓環境導致設計缺乏周密思考往往導致設計低劣。
研究資料：
專案前期砍掉1天的質量保證活動，到專案後期就需要3到10天的處理代價。（jones 1994）
缺少管理控制點就難以對專案的階段和狀態進行跟蹤，因此不能知道專案是否按正常軌道前進。
在構建未完全鎖定時，進行過早的整合或額外的整合不利於產品，它僅僅是在浪費時間，延長進度。
訓、公司和部門會議，技術評審會議等活動在專案估算時通常被遺漏。
當進度落後時不重新檢查任務和調整計畫，而是簡單地決定把進度趕上來。
另一種情況是，當產品出現變更卻沒有做相應的計畫調整。
沒有足夠的需求基礎和清晰的架構設計而進行「邊編碼邊修改」造成太多重複工作和返工，這樣的做法使專案大多以失敗告終。
產 品專案的產品要求要求比實際需求多得多的產品特性或複雜功能，卻又不給進度計畫分配足夠的時間。
在整個開發過程中，專案平均會有25%的需求變更，對軟體計畫至少有25%的影響。如果任由客戶不斷提出新需求，專案就會一直都做不完。
開發人員著迷於新技術，有時渴望在自己的產品中使用這些技術，而不管那些技術是否適合或是否會對系統整體造成破壞。
管理者批准進度落後的專案順延，但同時又給這個專案加入新任務。
軟體開發進度是完全有理由可以**的，而軟體研究進度甚至理論上都是不可預知的，不能採用像軟體研究一樣的工作方式引導專案開發。
技 術過於相信某些技術宣傳（某種開發過程、某種程式設計方法、某種開發語言），缺少在特定環境下使用這些工具的必要資訊。當團隊寄望利用他們來解決進度問題時，不可避免會失敗的。
無論採用多少新工具或方法，以及這些工具或方法有多好，他們很少能夠大幅度提高生產率。軟體開發由多個任務組成，特定的工具或方法只會可能提高特定任務的生產效率。同時，它們所帶來的效率常常被學習它們所花費的時間抵消了。
在專案中間更換工具時，伴隨使用新工具而帶來的人員學習和掌握的過程、重複的工作、不可避免的錯誤等會徹底抵消它所帶來的益處。
缺乏自動的源**控制容易造成版本衝突、歷時版本丟失、更新丟失等一系列問題，並浪費大量的時間處理這些問題。
軟體開發人員的基本原則
1.紮實的基礎。資料結構 離散數學 編譯原理，這些是所有電腦科學的基礎，如果不掌握他們，很難寫出高水平的程式。據我的觀察，學計算機專業的人比學其他專業的人更能寫出高質量的軟體。程式人人都會寫，但當你發現寫到一定程度很難再提高的時候，就應該想想是不是要回過頭來學學這些最基本的理論。不要一開始就去學oo...
做軟體的基本原則
不知不覺做軟體已經做了十年，有成功的喜悅，也有失敗的痛苦，但總不敢稱自己是高手，因為和我心目中真正的高手們比起來，還差的太遠。世界上並沒有成為高手的捷徑，但一些基本原則是可以遵循的。1.紮實的基礎。資料結構 離散數學 編譯原理，這些是所有電腦科學的基礎，如果不掌握他們，很難寫出高水平的程式。據我的觀...
軟體測試的基本原則
在軟體測試過程中，應注意和遵循的具體原則，具體可以概括為以下幾項，接下來我們就來了解一下。1.所有測試標準都是建立在使用者需求之上。軟體測試的目標就是驗證產品的一致性和確認產品是否滿足客戶的需求，所以測試人員要始終站在使用者的角度去看問題 去判斷軟體缺陷的影響，系統中嚴重的錯誤是那些導致程式無法滿足...