項目管理的五大過程-在線瀏覽
2025-06-06 01:18本頁面
【正文】 是拿下單子，我聽到的銷售們說的最多的就是沒問題或者NO銷售是非常辛苦的，為了建立客戶關(guān)系，尤其是空白的市場是很不容易的，往往為了一個單子會犧牲非常多。在銷售和客戶做承諾之前，PM要主動的跟銷售交流，提供粗略的總體設(shè)計框架和技術(shù)難關(guān)以及能考慮出的工作量，而不是等出了問題再被動和銷售在老板面前互相推委責(zé)任。優(yōu)秀的售前團隊合作是接單的重要保障。在商務(wù)談判的實際操作中，存在著各式各樣的問題，PM的職責(zé)和要求絕非以上幾點所能描述詳盡。但是有一點可以肯定，這是PM成為PM的第一道關(guān)，也是最重要的一關(guān)。與銷售有所不同，PM在該階段的任務(wù)除了接單，還要盡可能的搜集客戶關(guān)鍵人物的資料并與對方各個階層的負責(zé)人建立良好的客戶關(guān)系，以便在項目實施時充分調(diào)動資源。實際操作中多分為范圍，成本與進度，其中最重要的莫過于范圍。談判的時候一定要確立遞交件的標準和要求，也就是范圍。但是這個標準對每個公司來說都有一個底線，一旦超過了這個底線，那項目就肯定是虧的。建立范圍需要的就是PM的多年的實戰(zhàn)經(jīng)驗，在大大小小的項目中用血淚換來的一些體會。成本就是客戶答應(yīng)付的款項，與我們的投入成本并不是一回事情。項目如何成功？也有一些關(guān)鍵的因素。這里要注意的就是資源和高層的支持。這時候各個團隊或者部門之間不可避免的會發(fā)生資源爭奪戰(zhàn)，摩擦再所難免。除了高層對PM項目的重視程度，如果PM平時在公司與同事相處的好往往能使很多別人看起來很棘手的問題迎刃而解。有時候，這種內(nèi)耗對項目和PM來說是毀滅性的。一般來說PM已經(jīng)被項目里大大小小的事情搞的筋疲力盡，要PM去主動要求客戶配合是很吃力的事情?？蛻敉膊皇翘貏e的積極，主動與客戶聯(lián)系溝通和測試能及早發(fā)現(xiàn)問題。積極的態(tài)度可以帶動客戶的積極性，在項目完工的時候，客戶對你的感激往往是難以用語言描述的，這對以后接單或者做二期三期會打下良好的基礎(chǔ)。項目具有商業(yè)行為的幾個重要特征，有消費源，有參與者，有成功關(guān)鍵因素，有財務(wù)目標，有風(fēng)險。啟動階段PM的主要任務(wù)是率領(lǐng)總體架構(gòu)設(shè)計師和系統(tǒng)分析員收集盡可能詳細的數(shù)據(jù)，確立盡可能詳細的需求，進一步確立詳細的項目范圍，預(yù)估資源，確立其他方案并獲得進入下一階段的批準。項目即將進入計劃階段。接下來就是需求分析。PM統(tǒng)領(lǐng)的團隊這時候還不是真正的開發(fā)團隊，我們叫做前期團隊。對一個已經(jīng)啟動的項目來說，需求分析直接決定了項目的成功與失敗。這種需求一般比較含糊，無法體現(xiàn)客戶真正的需求。有時候客戶會很不講道理或者思路僵化，就要求按照他的思維去定一些明顯錯誤的需求。所以說，爭論再所難免，客戶有時候會吹胡子瞪眼睛拍桌子甚至?xí)f這個東西不要你們做了之類的話。只要PM盡力約束團隊中的成員，這個度還是很容易控制的。對有相同或類似模式的小項目來說采用快速開發(fā)或疊代開發(fā)是很合算的做法，時下流行的極限編程就是針對這方面建立的思維模式。如果不是因為項目有差異，那么市場上就只有產(chǎn)品而沒有項目了。我們要討論一個問題，究竟應(yīng)該在需求分析和總體設(shè)計上花費多少時間？我們熟悉的瀑布開發(fā)模式基本上分需求分析，總體設(shè)計，軟件開發(fā)，測試等幾個階段，然而究竟應(yīng)該在前兩個階段上花多少時間卻沒有定論。而需求分析和總體設(shè)計沒有做好就急忙上馬進行開發(fā)的項目在項目初期進展順利的時候問題不大，到了項目后期和測試階段一些潛伏期比較長但是破壞作用比較大的問題就會凸顯出來，造成返工，延長測試時間。基礎(chǔ)夯實了，金字塔就容易造了。在日本公司打工的程序員們可能都知道，小日本的軟件規(guī)范非常厲害，他們花在需求分析和總體設(shè)計上的時間通常在40%到50%左右，遠遠超過國內(nèi)軟件項目的實施，效果也要強的多。在這樣的軟件規(guī)范下，程序員更象是裝配流水線上的工人，對一個模塊或技術(shù)熟悉到一定程序就變成了完全的重復(fù)性勞動。在國內(nèi)，只會照抄別人代碼，一點都不懂創(chuàng)新，凡事依靠別人，快下班就盯著表看的程序員是不少，這種人一般很難有什么前途。由于國內(nèi)沒有象CMM這樣的軟件規(guī)范或者很少，所以這類優(yōu)秀的程序員不少都是干著系統(tǒng)分析員甚至PM的活，拿著程序員的工資。當(dāng)上進的程序員們作為PM進行商務(wù)談判的時候，前者還在各個公司里頻繁跳槽，跳來跳去都不滿意。日本的軟件規(guī)范與CMM有驚人的相似，其中至少有35%以上都是幾乎一模一樣的。這些公司紛紛搶灘上海，招收技術(shù)人員。往往一個程序員進去干了好幾年，對自己的那一塊熟的不得了，而對隔壁同事所做的東西一竅不通。當(dāng)然，已經(jīng)作到PM或QA或者熱愛CODING的朋友例外。需求分析本身也存在著時間分配的問題。所有的文檔將會提交給PM進行復(fù)審并簽字，不合格的打回重做。當(dāng)PM最終合并了所有文檔并確立需求之后，最終生成的需求文檔將提交給客戶的各部門負責(zé)人簽字。需要說明的是，客戶并非都是蠻不講理，但是說實話，頗有無奈，國內(nèi)目前的項目大多數(shù)客戶為了不讓自己的錢白花，經(jīng)常變著法子提需求。有時候，這種大項目在簽單時雙方都沒有絕對把握保證可以出成果，一旦在需求分析階段發(fā)現(xiàn)難以逾越的技術(shù)難關(guān)，就會放棄項目。上世紀八十年代初美國搞星球大戰(zhàn)計劃，拖跨了蘇聯(lián)。其實并不完全如此，蘇聯(lián)人的情報機構(gòu)無孔不入，并非那么容易上當(dāng)受騙。項目啟動要確定項目計劃，與客戶一起實施第一次項目審核，確認并對一些產(chǎn)品和服務(wù)向下包廠商下訂單。這些會議有與客戶的會議，與下包廠商的，有團隊的，有公司高層的。與客戶的一個主要會議將是項目啟動會議。還有一些零零碎碎的東西甚至包括辦公場地的大小，電話多少部，所有人的聯(lián)系方式等等都要在會議上確立，并做會議記錄。大概就是所謂三軍未動，糧草先行吧。這時候，作為公司高層，應(yīng)該向全公司發(fā)表申明，正式給PM發(fā)布項目經(jīng)理任命書和項目授權(quán)書。 （WBS）這里概念可能有些不太對頭，其實是翻譯的緣故，反正大家明白意思就行，不用拘泥于字面?？梢哉f，WBS是計劃階段的核心。WBS有縮進式和樹狀式，我這里也沒辦法畫圖，大家參考一些項目管理的書籍，里面有詳細介紹。WBS的細目并不需要分解到同一水平，最下面的細目叫做工作包，分包的依據(jù)是個人的責(zé)任和可信度，也就是說到每個人頭上的任務(wù)是否能落實，是否有把握完成；還有就是準備對項目進行控制的程度，程度越深，WBS樹也就越深。PM要召開團隊進行討論，向成員提供與項目相關(guān)的所有詳細
公司管理相關(guān)推薦
鄂ICP備17016276號-1