在軟體專案管理中，經常遇到這樣的情況：進度到百分之九十後開始停滯，要花很長很長時間很大很大代價（甚至超過前百分之九十所花費的工時、工期）才能完成最後的百分之十。我把這種情況叫作：軟體專案的百分之九十效應。
西漢·劉向《戰國策·秦策五》：「詩云：『行百里者半九十。』此言末路之難也。」
通俗地講，做事情越接近成功越難，越要認真對待。很多人、團隊做事情，開始的時候總是雄心壯志、信心十足，認為一切盡在掌握，可是隨著時間的推進，各種問題出現，慢慢的就沒有了動力，毅力也消磨殆盡，決心不經意間一去不回，到最後只盼早點結束，要麼放棄要麼草草收尾要麼延期再延期。
在軟體專案開發中，這種案例比比皆是。我自己也曾經遇到幾次。
我總是在想，為什麼會這樣？為什麼這最後一公里路程如此遙遠以致難以逾越？
有的人說，真不明白系統框架為什麼設計成這樣……
有的人說，壓根兒就不該選擇自己實現 http 協議，根本就是重新造輪子……
有的人說，給我的任務太多了，比任何其他人都多……
有的人說，搞不懂 ui 為什麼這麼醜陋，互動也糟透了，一點都不符合習慣……
有的人說，我卡在那個問題那裡，動不了了……
測試人員說，為什麼到快發布了才讓我們測，根本不給我們測試預留時間……
還有測試人員說，開發太不象話了，自己根本不測……
專案經理咬牙切齒，你們這幫人，為什麼不早說……
領導說，這麼點兒小事兒都那啥啥，執行力忒成問題，效率極端低下……
客戶在搖頭……
其實如果能帶著現在的問題、經驗回到起點來看，我們會發現很多可以規避掉的彎路、陷阱、沼澤。
回過頭來再看所謂的百分之九十效應。我這裡有乙個問題給大家：專案進度真的到了百分之九十（90%）嗎？
其實我們可以換個問題，為什麼越臨近交付期問題越多？再換個說法，專案為什麼老是延期？
讓我們來看看軟體專案進度延期的關鍵因素。
軟體專案延期時，專案經理應當首先自問，專案計畫安排是否合理？而專案進度計畫安排是否合理，需要從以下幾個方面來分析。
估算是否準確是對專案進度計畫安排影響最大的乙個因素。
估算不準確的原因有很多，缺少經驗豐富的估算專家和可參考的歷史資料是最重要的兩個方面，而這只能通過多個專案的積累或者某個專案的多個版本的積累才能得到改善，沒有終南捷徑。除此之外，還要考慮一些特殊因素，比如專案組有新成員得預留上手時間，又比如專案涉及到新技術需要預留學習時間……
在專案進度計畫安排上，我們首先要識別關鍵路徑，對關鍵路徑上的資源進行合理安排並進行保護（儘量減少關鍵資源上非關鍵任務的安排）。
另外我們在進度計畫安排上應該適當安排 10% - 15% 的餘量，這樣在專案遇到突發事件，或專案風險轉變為實際問題時候才能夠有人員和時間進行處理。
在乙個專案開發過程中，有的人一直忙碌不停，哼著小曲「時間都去哪兒啦」；有的人是脈衝性的，一陣子忙一陣子閒；有的人則在唱「我的心在等待，永遠在等待」。這說明專案中的人力資源往往不能充分利用起來，這樣還會帶來專案團隊成員之間的不平衡從而進一步影響生產率。
對乙個軟體專案而言，需要保證專案成員的整體利用程度在 70% 以上，否則就應該考慮採用新的開發模式和生命週期模型。為了充分利用相關資源，專案應該盡可能地採用敏捷模型或迭代模型，規避對瀑布模型的使用。另外如有可能，還應當持續整合，讓測試人員盡早開始工作以便盡早暴露問題。
我始終認為，找到合適的團隊成員，是乙個專案成功的關鍵。看過電影《十一羅漢》、《十二羅漢》吧，每個人都有他的價值，個人價值的最大化加上協同效應才能成事兒。人和團隊的因素是對專案影響最大的因素，一切問題說到底都是人的問題。
軟體專案中的程式猿從事的是創造性的工作或者通過螺旋重複進而產生創造性的工作，而非簡單重複的勞動。我們必須承認專案中每個成員的價值，充分的尊重每個成員，讓他發揮出自己的價值。惟其如此，才能保證專案的生產率。
那麼在乙個專案團隊中，可能有哪些人員相關的因素會影響團隊的生產率呢？
兵熊熊乙個，將熊熊一窩，好的專案經理可能佔到專案成功的一半因素或者更多。好的專案經理應該具備哪些的條件呢？
其實優秀的專案經歷還有很多很多特質，每個人都能說出一籮筐，這裡不再贅述。
幹什麼樣的事兒需要什麼樣的人，很樸素的道理。
可是我們在開始乙個專案的時候，往往並非如此。通常我們沒有機會選擇專案成員（除非為新專案組建新團隊），而是在已有成員基礎上接受新專案。那麼這個時候就存在專案組成員技術能力與待開發專案所需技能不匹配的問題。但我們通常會假設專案組成員的技能都能達到要求，並在此前提下進行工作量估算，所以呢，失之毫釐謬以千里。
在開始乙個新專案之前，應當對團隊成員的技術能力進行一次評估，專案經理必須做到誰能幹什麼事兒能幹到什麼程度心中有數，要以此為基礎來調配資源，張三什麼時候幹這件事，李四什麼時候幹那件事，趙
六、王五，怎麼銜接，都必須有譜才行。
如果專案經理認識到團隊人員技能不足，那就要妥善安排。對於大家都欠缺的技能，統一培訓並跟蹤效果；對於個別技能不足的人員，應當給他預留自我學習時間或者安排師傅幫帶，使其技能盡快達標；而對於新員工和他的人物，應該加強評審和檢驗，以免輸出質量太差導致後期代價昂貴的返工。
假如我們以最大的惡意來揣測，很多時候做專案，多數專案成員是抱著完成任務的心態來工作的，責任心不強、敷衍了事。這樣就會導致產出質量低下，帶來大量返工，或者單獨模組能 run ，繼承後給協作模組帶來莫名問題引發大量扯皮及工作量浪費。
在這種情況下，公司或專案經理應當加強專案規範建設，加強專案的團隊建設和集體榮譽感，讓專案成員感覺到做的系統是他們自己的產品，而不是公司的專案，專案經理的專案，讓專案成員有主人翁意識，採取各種措施，讓專案成員對成就感有一定渴望。
好吧，我得說，有人的地方就有江湖。江湖得有江湖的規矩，專案組必須建立起有效的溝通渠道，使專案組成員能夠快捷順暢地進行溝通。如果專案組成員一周的時間有大半耗費在不必要的人際消耗上（張三和李四有牴觸，王五和趙六互相較勁找茬，錢二麻子誰都不吝……，想想吧），專案經歷必須及時分析和總結原因，必要時還要約談相關成員以藝術的方式和稀泥。總而言之，一定要在最短的時間內，使用各種工具、手段（無所不用其極）地使交流雙方或多方達成一致。
前面說專案進度計畫是否合理時，已經提到了專案開發模式和生命週期模型。好的模式可以提高專案組成員的利用率，提高團隊生產率，為專案計畫順利實施奠定基礎。軟體開發行業這麼多年出現了很多開發模式，各個都有其優點，要結合專案組的特點，妥善選擇，行差踏錯可就追悔莫及了。
技術路線選擇錯了，南轅北轍，跑得越快離題越遠。
前面我們提到專案經理在技術上要一專多能，知識面要足夠寬，原因就在這裡，專案經理要對技術路線有評估能力，要負責任。當然也不能搞**，應當團結所有成員尤其技術骨幹共同選擇，要尊重每個成員，大家都參與了才會有認同感，盡量不要給成員「上面強制推行」這種錯覺（哪怕是強制推行也要做到不著痕跡）。
定了技術路線，還要定系統架構。架構設計非常之重要，不僅僅要根據業務的功能性需求進行子系統、介面、元件等的設計和劃分；同時架構設計還需要考慮系統的健壯性、可擴充套件性、效能、安全性、可維護性等非功能性需求。架構人員應該通過架構設計遮蔽整個系統的複雜性，向模組設計和開發人員提供一套簡單、高效的開發規程和模式，這樣才能夠真正提高後續設計開發的效率和質量。
要設計乙個成熟的架構，架構人員不僅僅要是技術方面的專家，也需要充分理解業務需求，這樣才能夠做出好的架構來。一定要給專案的總體設計和架構設計留足時間，架構不穩定就很難承重很難抗震，很快就會積重難返被迫重構或推倒重來。
專案經理一定要有風險管理意識，對專案行進過程中可能出現的風險有清醒的認識，要提前採取應急措施。舉個例子，如果前期沒有分析出來某個核心成員會離職，那當專案進行到一半時該成員要走，專案組中既沒有合適的替代成員又不能在短期內招募到合適的新成員，這樣對專案的打擊將會是致命的。
專案組最好形成一套應急預案來應對突發事件，使得意外的發生在情理之外預料之中，能夠使用已經積累的各種策略、方法、工具和預備的資源餘量進行跟蹤處理。
太陽底下沒有新鮮事兒。對客戶或需求人員來講，變是唯一不變的真理。可是對於專案團隊，頻繁的、大範圍的需求變更簡直就是噩夢，新增功能不但會線性增加工作量而且往往會破壞已有架構最終導致專案不可避免的擁抱延期。如果到了專案後期，就更是噩夢中的噩夢了，有些開發人員砍人的心都會有。因此在專案管理中，一定要形成一套可行的需求管理機制（比如採取敏捷開發模型，乙個衝刺之內不允許變更）來對需求變更進行有效的控制。
乍看之下，時間和質量是專案中的兩個互相矛盾的因素。我們經常為了趕進度而犧牲質量，或者為了保證質量而延期（當然有時以質量之名延期卻沒***質量）。
多數公司都有一套質量規範，交付出去的產品都要經過測試環節的驗證以便盡可能少的發布有嚴重質量缺陷的產品。可是，可是，現實中經常出現專案後期測試問題太多，bug 修改和回歸測試等花費了大量的時間而導致專案的延遲，有時甚至不是一點點而是幾倍於估算工期的延遲。
那麼，怎樣在時間和質量之間取得平衡呢？有幾點可以參考：
採取合適的開發模型，比如敏捷和快速迭代，每個固定週期（2周或3周）交付可測試版本，測試人員及早介入
加強各階段產出物的評審和 review ，比如需求、ui 設計、架構設計、總體設計、介面設計、模組設計
開發人員引入單元測試，如果認為單元測試粒度過細或要求過高，可以變通，撰寫針對輸入輸出、內在邏輯、介面使用的測試程式，測過才可以整合
持續整合，每週要進行 2 次或者更多次，開發人員要不斷交付可用 build ，相互之間交叉測試
先對外後對內，介面先行，將子系統之間、模組之間的依賴降低，避免開發人員之間的相互等待造成的空耗
簡而言之一句話：盡可能的在專案早期發現問題。只要能達到這個目的，什麼措施都行。
說了這麼多，能否解決軟體專案開發中的百分之九十效應呢？其實每個人都有自己的金剛經，唯有實踐才是檢驗經是否念歪的標準。
聊聊軟體開發過程中的「怪現象」
本文所要分享的是軟體開發過程中，親身經歷過的 怪現象 為什麼說怪呢，人多力量大，似乎才符合常理，但是往往在軟體專案開展的過程中會出現人多 事少 工作量大的情況，這跟我們以往的認知大相徑庭。此處輸入描述 首先，要解釋下標題的意思。人多，指的是同乙個專案團隊 同乙個小組或者同乙個部門的範圍內 事少，指的...
專案團隊中的衝突是專案程序中的必然現象
在現今的專案團隊中，無論怎樣的管理方式都會有衝突的存在，無論是性格方便的還是專案任務方面的，每乙個人都會有不同的理解方式，於是衝突產生了。很多領導者害怕衝突，稍微有衝突的時候變惱羞成怒，便變得失控，然後讓衝突擴大化，從而影響整個團隊的協調性。所以很多專案經理是盡量避免衝突，與客戶的，與成員的等等。可...
軟體專案開發流程
使用者檢視 使用者檢視是使用者所能見到的資料或資訊的表現形式.資料詞典 資料詞典 data dictionary，簡稱dd 就是用來定義資料流圖中的各個成分的具體含義的。對資料流圖中出現的每乙個資料流 檔案 加工給出詳細定義。資料字典主要有四類條目 資料流 資料項 資料儲存 基本加工。資料項是組成資...