就軟體開發專案而言，傳統的生命週期基本重點是從需求分析開始，這當中會有個不大不小的問題，即“知識斷層”。大部分軟體專案中，專案經理接觸專案通常是在合同簽署後，這個時候就有一個很明顯的斷檔，我相信有些專案經理沒有過專案售前的經驗（我不是指和銷售人員跑跑客戶講講方案演示下demo什麼的），真正的專案售前其實是一個諮詢的過程，這個過程要抓住客戶，唯有四個字“提供價值”，這裡的價值，表現為通過方案的描述，通俗易懂的描述能幫助客戶解決什麼問題，達到什麼樣的成果等等。這個階段收集到的需求和目標才是客戶最原始的專案需求。
全生命週期
和傳統軟體生命週期不同，一般軟體工程理論只重視專案實施這一環。在真實專案場景中，我經常會聽到專案經理抱怨“銷售當初怎麼和客戶說的，畫這麼大個餅，也不提前支會我一聲”。其實，這種情況不能完全怪銷售或售前，專案經理在進入專案實施前，應主動找銷售和售前人員瞭解當初拿下這個專案中所有的過程細節，瞭解從哪些地方打動了客戶，哪些是客戶真正關心的，即時在售前環節不是從技術上征服了客戶的，你也有個心理預期，知道這專案客戶想要的到底是什麼。
舉個不那麼恰當的例子：談戀愛中最具影響力的過程不是戀愛環節，而是你和對方確認戀愛關係前所做的一切努力，沒前面的鋪墊，一下子進入戀愛實施環節，肯定不是一個完整的過程，對吧，各位。
下面總結一下專案全生命週期的各個環節
因為篇幅所限，所以重點介紹一下專案售前和專案運維。關於專案實施，各類理論和學說在網路上汗牛充棟，就簡單帶過了。
專案售前
這個階段的重要性如前文所述，經常被專案經理所忽視。導致的後果就是：專案視野狹窄、專案目標誤判、專案理解週期長、專案磨合期長、客戶意圖理解週期長而導致的信任感低等問題。這些問題基本沒人會提醒你，在哪個風險庫中你也找不到，但是在實際專案中確實存在。下面就售前階段的各個步驟簡要說明。
可行性分析
通常這個階段的目標是協助客戶對專案的經濟性、合規性、實施可行性、安全性等做個分析。簡單說就是從業務角度幫客戶做一個量化的投入產出分析，讓IT部門能依據這份報告來說服老闆答應立項（就是投錢）。
基本上這個階段，銷售接觸的是客戶的IT部門，即使是業務部門有熟人透露專案資訊，最終也會轉到IT部門過一道。相對於業務部門來說，IT部門更難搞定一些，畢竟對方既是IT專業出身，又對自身運營業務和特點熟悉。因此，可行性分析首先要打動他們。而打動他們其實就是他們認為能打動老闆。因此不要小看這份報告，通常分管IT的CIO並沒有什麼決算權力，碰到審批許可權之上的（軟體專案我看大部分CIO都不是最終拍板的），基本上還是得由總經理（國企）或CEO（合資/外企）來拍板，但他們熟悉自己的文化和老闆的風格，通常能到CIO位置的，揣摩上級心思還是很有一套的。因此在拿這份報告時，首先是得獲取客戶方上至IT老闆下至分管專案的主管的認同，當然還有業務部門的認同。
通常這個階段客戶的優勢是有一些IT應用的專業知識，熟悉內部業務和行業知識。但他們的缺點也剛好是我們的優勢，就是在IT領域上，基本上乙方的專業知識會強出不少，更具有優勢的是，部分乙方在行業經驗上比甲方更具深度。因此，運用自己的專業知識和行業背景知識，理解客戶業務部門的痛點，適當放大，再美化產出效果，是打動最終老闆的唯一正途（歪途就不說了）。
這個階段中，如果需求是由業務部門發起的，那麼與業務部門的溝通尤其重要。有些企業IT部門與業務部門互相看不順眼，這個時候你也沒辦法，必須硬著頭皮去找業務部門溝通需求，聆聽（注意這個詞）他們的想法，理解他們的無奈，方案上與他們達成一致，
這個階段的產出物，很多是PPT，重形式的國企或政府機構會要求出具文件形式的報告。PPT和文件都是一個累積的過程，等有空的時候我再來專門講解如何製作PPT和文件。
有意思的是，這個階段對專案型公司最難的是不具備行業背景知識。因此我給出一個文章《跟專業人學習一週摸清一個行業》的連結供大家參考，實際應用中，我也確實認同這種方式，可以在短期內寫出一份比較精彩的報告來打動客戶。
專案立項
這個階段基本上就要看甲方老闆的反應了，一般的銷售就會傻等，稍微厲害的會慫恿IT部門的老闆找老闆一起開會彙報（當然事先要多次排練，一旦演砸基本上就沒戲了），更厲害的除了彙報之外還會動用自身的人脈，適時的約上甲方老闆時間彙報了。不過我看一般也就第二層了，第三層沒點皇親國戚的關係沒人會鳥你。
這個階段呢，銷售還有一些輔助手段。譬如找業務部門的人，讓他們適時的吹吹風。提供一些案例參觀和考察的機會給甲方等等。
一旦老闆點頭同意立項了，基本上就成功有望了。這個階段多少有點只能側面迂迴的感覺，除非是老闆親自抓的IT專案，那就另當別論了。
專案方案建議
這個階段有些公司直接省略了，其實是不太合適的。最直接的後果是，銷售感覺能做的，在沒有專業技術人員支撐的前提下（售前很多是二把刀），無限畫餅，承諾客戶。導致期望和專案範圍無限放大。最終結果就是專案經理接了個隱患重重的專案。
方案建議其實是一個專案中關鍵技術論證的報告，閱讀物件是客戶的IT和業務部門，其目的是告訴對方：1、你放心，從專案目標、實施範圍、典型場景、關鍵技術、實施計劃的方方面面我都考慮到了，讓客戶的IT部門對你的信任感無限上升；2、告訴客戶，這個專案的邊界在哪兒，專案中的實施範圍的優先順序、順序、技術實現方式是什麼；3、給客戶吃一顆定心丸，知道專案接下來的實施模式是什麼樣的；
因此，這個報告的形式以文件為優，而且這個報告最好是由公司內專業的技術骨幹、專案經理、銷售、售前來一起寫。花這點力氣是值得的，一、此時專案經理和技術骨幹的介入，會直接給技術實現以最可行的方式；二、此時專案經理的介入，會了解專案的背景、風險和由來，因此在這個階段由專案經理和銷售一起引導客戶的技術思路是最有效的；三、最重要的，防止銷售畫大餅；
那麼這個方案如何寫呢。寫一個好的方案建議書，要知道是給IT和業務部門看。因此開篇的時候要從業務角度去寫，即“鳳頭”，通常的章節如“前言、專案目標、專案範圍、實施內容、技術原則”這些。開篇就是要讓人有眼前一亮的感覺，覺得你是懂我的，你是懂我這個行業的，你說的是我聽得懂的話，你說的把我想的都總結了。
接下來的中間章節，一般稱之為“豬肚”，通常有“系統開發平臺、系統邏輯架構、系統物理架構、系統執行環境、關鍵技術實現”等內容，通常這部分業務部門會一眼帶過，但IT部門會認真看，特別是架構部分的圖，千萬別馬虎畫，要經得起推敲。另外就是關鍵技術實現，實際上就是解答IT部門內心關於技術難點如何解決的疑問，同時給後來的專案組成員一個指導和參考。
最後的章節，就是怎麼落地了，因此叫“豹尾”，意思是有力乾脆。一般有“專案進度規劃、專案管理保障、專案費用概算”這些，當然概算你事先要和客戶達成一致。這個階段可以稍稍高點。
招標與投標
這個階段麼，只要你方案建議做的好，基本上招標書的內容，客戶都會照抄你方案建議書的內容，或是讓你幫忙代勞。甚至評分規則上也會諮詢你意見，向你傾斜。其實到這個份上，如果你還拿不下專案，基本上我只能說你們公司肯定有問題了。我就碰過這麼一次，不過那是因為人員更替造成的，客戶前期很信任那個寫方案的專案經理，打了三次電話邀請他們公司來投標（因為乙方不想投，嫌金額小不夠成本），後來甲方說可以縮減部分需求，甚至底價都說了，結果那個專案經理離職了，沒人可以寫投標方案，也沒人可以講標，這專案就黃了。所以軟體公司麼，最重要的真的是人。
至於標書的製作，沒有什麼竅門，就是兩個字“仔細”，當然還需要深厚的方案寫作功力。不過此時有前期的方案建議書可用，寫起來也應該得心應手。總之，前面幾個階段做好了，只要不是天災人禍，拿下專案是十拿九穩的事。
專案實施
這個過程沒啥還多說的，敏捷、RUP、MSF各種東東，我想說的是，無論哪種方法，要重點注意的是，一定要在合同簽署中或後有一個專案工作範圍的確認，這個工作範圍說白了，就是要完成哪些模組、功能，功能的具體描述，哪些是甲方要提供的條件，哪些不歸乙方負責的，一定要仔仔細細想清楚了寫，千萬在裡面不要在功能描述的時候來個“等等”之類的字眼，這個東東最好和作為合同附件，在和客戶談需求的時候將是你的最後一道防線。
專案運維
其實很多人忽視了這個階段。我的實踐經驗中，我手上大部分專案都是在運維過程中冒出的新需求而產生的。而且，實際過程中，運維因為週期長，人員要求素質高（別以為放兩個畢業生就可以），實際成本並不低。特別是現場運維，要有熟悉客戶現場環境和專案開發過程的（別以為靠文件就可以兩三天整明白的）人，最不濟也要有人帶上個把月，告訴你程式碼結構、功能特點、專案隱患、注意事項、客戶脾氣這些細節。才能放心把人放在現場運維。
運維制度/流程
專案運維之前，首先要和客戶確認的運維制度和流程。而且必須把業務部門培訓好，讓他們可以進行一些簡單的運維工作（前提是你們完成的系統不能太爛）。有了這個雙方認可的運維制度/流程，基本上大家都知道如何處理日常問題，不會再出現扯皮拉筋的事了。
運維/持續改進
專案運維也是個很細緻的活，日常檢查、月/季巡檢、災備演練、運維記錄、客戶回訪、bug修訂、新需求收集。基本上專案經理把活做好了的，運維的時候還是得時不時讓他們回訪一下客戶，很多新專案機會就是從這些回訪中冒出來的。
小結
綜合上面所說，我所認為的軟體生命週期，並非只包含了專案實施這一個環節，而是應當包括專案售前和專案運維兩個階段的，這才是一個完整的軟體生命週期，好比一個生命，最初的起點是懷胎，最終的結點是你死後再沒有人緬懷你。而作為專案經理，特別重要的是要能參與到售前中來，特別是方案建議的環節，對後期的專案實施有著清晰專案範圍、理解專案背景、瞭解客戶期望、縮短專案磨合期的巨大好處。當然現實是殘酷的，公司的高層是否有這樣的覺悟，有了這樣的覺悟是否能組織好技術型人才和銷售型人才的工作配合問題，那就得看各位的造化和努力了。