很是道-中小軟件公司項目管理(第四節 如何看待生命週期)

     就軟件開發項目而言,傳統的生命週期基本重點是從需求分析開始,這當中會有個不大不小的問題,即「知識斷層」。大部分軟件項目中,項目經理接觸項目一般是在合同簽署後,這個時候就有一個很明顯的斷檔,我相信有些項目經理沒有過項目售前的經驗(我不是指和銷售人員跑跑客戶講講方案演示下demo什麼的),真正的項目售前實際上是一個諮詢的過程,這個過程要抓住客戶,惟有四個字「提供價值」,這裏的價值,表現爲經過方案的描述,通俗易懂的描述能幫助客戶解決什麼問題,達到什麼樣的成果等等。這個階段收集到的需求和目標纔是客戶最原始的項目需求。安全

全生命週期

      和傳統軟件生命週期不一樣,通常軟件工程理論只重視項目實施這一環。在真實項目場景中,我常常會聽到項目經理抱怨「銷售當初怎麼和客戶說的,畫這麼大個餅,也不提早支會我一聲」。其實,這種狀況不能徹底怪銷售或售前,項目經理在進入項目實施前,應主動找銷售和售前人員瞭解當初拿下這個項目中全部的過程細節,瞭解從哪些地方打動了客戶,哪些是客戶真正關心的,即時在售前環節不是從技術上征服了客戶的,你也有個心理預期,知道這項目客戶想要的究竟是什麼。網絡

      舉個不那麼恰當的例子:談戀愛中最具影響力的過程不是戀愛環節,而是你和對方確認戀愛關係前所作的一切努力,沒前面的鋪墊,一會兒進入戀愛實施環節,確定不是一個完整的過程,對吧,各位。架構

      下面總結一下項目全生命週期的各個環節運維

   

      由於篇幅所限,因此重點介紹一下項目售前和項目運維。關於項目實施,各種理論和學說在網絡上汗牛充棟,就簡單帶過了。學習

項目售前

      這個階段的重要性如前文所述,常常被項目經理所忽視。致使的後果就是:項目視野狹窄、項目目標誤判、項目理解週期長、項目磨合期長、客戶意圖理解週期長而致使的信任感低等問題。這些問題基本沒人會提醒你,在哪一個風險庫中你也找不到,可是在實際項目中確實存在。下面就售前階段的各個步驟簡要說明。對象

可行性分析

     一般這個階段的目標是協助客戶對項目的經濟性、合規性、實施可行性、安全性等作個分析。簡單說就是從業務角度幫客戶作一個量化的投入產出分析,讓IT部門能依據這份報告來講服老闆答應立項(就是投錢)。blog

     基本上這個階段,銷售接觸的是客戶的IT部門,即便是業務部門有熟人透露項目信息,最終也會轉到IT部門過一道。相對於業務部門來講,IT部門更難搞定一些,畢竟對方既是IT專業出身,又對自身運營業務和特色熟悉。所以,可行性分析首先要打動他們。而打動他們其實就是他們認爲能打動老闆。所以不要小看這份報告,一般分管IT的CIO並無什麼決算權力,碰到審批權限之上的(軟件項目我看大部分CIO都不是最終拍板的),基本上仍是得由總經理(國企)或CEO(合資/外企)來拍板,但他們熟悉本身的文化和老闆的風格,一般能到CIO位置的,揣摩上級心思仍是頗有一套的。所以在拿這份報告時,首先是得獲取客戶方上至IT老闆下至分管項目的主管的認同,固然還有業務部門的認同。生命週期

     一般這個階段客戶的優點是有一些IT應用的專業知識,熟悉內部業務和行業知識。但他們的缺點也恰好是咱們的優點,就是在IT領域上,基本上乙方的專業知識會強出很多,更具備優點的是,部分乙方在行業經驗上比甲方更具深度。所以,運用本身的專業知識和行業背景知識,理解客戶業務部門的痛點,適當放大,再美化產出效果,是打動最終老闆的惟一正途(歪途就不說了)。項目管理

     這個階段中,若是需求是由業務部門發起的,那麼與業務部門的溝通尤爲重要。有些企業IT部門與業務部門互相看不順眼,這個時候你也沒辦法,必須硬着頭皮去找業務部門溝通需求,聆聽(注意這個詞)他們的想法,理解他們的無奈,方案上與他們達成一致,開發

     這個階段的產出物,不少是PPT,重形式的國企或政府機構會要求出具文檔形式的報告。PPT和文檔都是一個累積的過程,等有空的時候我再來專門講解如何製做PPT和文檔。

     有意思的是,這個階段對項目型公司最難的是不具有行業背景知識。所以我給出一個文章《跟專業人學習一週摸清一個行業》的連接供你們參考,實際應用中,我也確實認同這種方式,能夠在短時間內寫出一份比較精彩的報告來打動客戶。

項目立項

     這個階段基本上就要看甲方老闆的反應了,通常的銷售就會傻等,稍微厲害的會慫恿IT部門的老闆找老闆一塊兒開會彙報(固然事先要屢次排練,一旦演砸基本上就沒戲了),更厲害的除了彙報以外還會動用自身的人脈,適時的約上甲方老闆時間彙報了。不過我看通常也就第二層了,第三層沒點皇親國戚的關係沒人會鳥你。

     這個階段呢,銷售還有一些輔助手段。譬如找業務部門的人,讓他們適時的吹吹風。提供一些案例參觀和考察的機會給甲方等等。

     一旦老闆點頭贊成立項了,基本上就成功有望了。這個階段多少有點只能側面迂迴的感受,除非是老闆親自抓的IT項目,那就另當別論了。

項目方案建議

      這個階段有些公司直接省略了,實際上是不太合適的。最直接的後果是,銷售感受能作的,在沒有專業技術人員支撐的前提下(售前不少是二把刀),無限畫餅,承諾客戶。致使指望和項目範圍無限放大。最終結果就是項目經理接了個隱患重重的項目。

      方案建議實際上是一個項目中關鍵技術論證的報告,閱讀對象是客戶的IT和業務部門,其目的是告訴對方:一、你放心,從項目目標、實施範圍、典型場景、關鍵技術、實施計劃的方方面面我都考慮到了,讓客戶的IT部門對你的信任感無限上升;二、告訴客戶,這個項目的邊界在哪兒,項目中的實施範圍的優先級、順序、技術實現方式是什麼;三、給客戶吃一顆定心丸,知道項目接下來的實施模式是什麼樣的;

      所以,這個報告的形式以文檔爲優,並且這個報告最好是由公司內專業的技術骨幹、項目經理、銷售、售前來一塊兒寫。花這點力氣是值得的,1、此時項目經理和技術骨幹的介入,會直接給技術實現以最可行的方式;2、此時項目經理的介入,會了解項目的背景、風險和由來,所以在這個階段由項目經理和銷售一塊兒引導客戶的技術思路是最有效的;3、最重要的,防止銷售畫大餅;

     那麼這個方案如何寫呢。寫一個好的方案建議書,要知道是給IT和業務部門看。所以開篇的時候要從業務角度去寫,即「鳳頭」,一般的章節如「前言、項目目標、項目範圍、實施內容、技術原則」這些。開篇就是要讓人有眼前一亮的感受,以爲你是懂個人,你是懂我這個行業的,你說的是我聽得懂的話,你說的把我想的都總結了。

     接下來的中間章節,通常稱之爲「豬肚」,一般有「系統開發平臺、系統邏輯架構、系統物理架構、系統運行環境、關鍵技術實現」等內容,一般這部分業務部門會一眼帶過,但IT部門會認真看,特別是架構部分的圖,千萬別馬虎畫,要經得起推敲。另外就是關鍵技術實現,實際上就是解答IT部門心裏關於技術難點如何解決的疑問,同時給後來的項目組成員一個指導和參考。

     最後的章節,就是怎麼落地了,所以叫「豹尾」,意思是有力乾脆。通常有「項目進度規劃、項目管理保障、項目費用概算」這些,固然概算你事先要和客戶達成一致。這個階段能夠稍稍高點。

招標與投標

      這個階段麼,只要你方案建議作的好,基本上招標書的內容,客戶都會照抄你方案建議書的內容,或是讓你幫忙代勞。甚至評分規則上也會諮詢你意見,向你傾斜。其實到這個份上,若是你還拿不下項目,基本上我只能說大家公司確定有問題了。我就碰過這麼一次,不過那是由於人員更替形成的,客戶前期很信任那個寫方案的項目經理,打了三次電話邀請他們公司來投標(由於乙方不想投,嫌金額小不夠成本),後來甲方說能夠縮減部分需求,甚至底價都說了,結果那個項目經理離職了,沒人能夠寫投標方案,也沒人能夠講標,這項目就黃了。因此軟件公司麼,最重要的真的是人。

     至於標書的製做,沒有什麼竅門,就是兩個字「仔細」,固然還須要深厚的方案寫做功力。不過此時有前期的方案建議書可用,寫起來也應該駕輕就熟。總之,前面幾個階段作好了,只要不是天災人禍,拿下項目是十拿九穩的事。

 

項目實施

      這個過程沒啥還多說的,敏捷、RUP、MSF各類東東,我想說的是,不管哪一種方法,要重點注意的是,必定要在合同簽署中或後有一個項目工做範圍的確認,這個工做範圍說白了,就是要完成哪些模塊、功能,功能的具體描述,哪些是甲方要提供的條件,哪些不歸乙方負責的,必定要仔仔細細想清楚了寫,千萬在裏面不要在功能描述的時候來個「等等」之類的字眼,這個東東最好和做爲合同附件,在和客戶談需求的時候將是你的最後一道防線。

 

項目運維

      其實不少人忽視了這個階段。個人實踐經驗中,我手上大部分項目都是在運維過程當中冒出的新需求而產生的。並且,實際過程當中,運維由於週期長,人員要求素質高(別覺得放兩個畢業生就能夠),實際成本並不低。特別是現場運維,要有熟悉客戶現場環境和項目開發過程的(別覺得靠文檔就能夠兩三天整明白的)人,最不濟也要有人帶上個把月,告訴你代碼結構、功能特色、項目隱患、注意事項、客戶脾氣這些細節。才能放心把人放在現場運維。

運維制度/流程

      項目運維以前,首先要和客戶確認的運維制度和流程。並且必須把業務部門培訓好,讓他們能夠進行一些簡單的運維工做(前提是大家完成的系統不能太爛)。有了這個雙方承認的運維制度/流程,基本上你們都知道如何處理平常問題,不會再出現扯皮拉筋的事了。

運維/持續改進

      項目運維也是個很細緻的活,平常檢查、月/季巡檢、災備演練、運維記錄、客戶回訪、bug修訂、新需求收集。基本上項目經理把活作好了的,運維的時候仍是得時不時讓他們回訪一下客戶,不少新項目機會就是從這些回訪中冒出來的。

 

小結

      綜合上面所說,我所認爲的軟件生命週期,並不是只包含了項目實施這一個環節,而是應當包括項目售前和項目運維兩個階段的,這纔是一個完整的軟件生命週期,比如一個生命,最初的起點是懷胎,最終的結點是你死後再沒有人緬懷你。而做爲項目經理,特別重要的是要能參與到售前中來,特別是方案建議的環節,對後期的項目實施有着清晰項目範圍、理解項目背景、瞭解客戶指望、縮短項目磨合期的巨大好處。固然現實是殘酷的,公司的高層是否有這樣的覺悟,有了這樣的覺悟是否能組織好技術型人才和銷售型人才的工做配合問題,那就得看各位的造化和努力了。

相關文章
相關標籤/搜索