【正文】 不用多描述了。除非是為了二期有利可圖或者是為了搞好關系，否則范圍超過底線的時候情愿不做 ，再厲害的 PM 在這種情況下也是無能為力。我們把項目最終生成并提交給用戶的產(chǎn)品和文檔統(tǒng)稱為遞 交件。接不到單子， PM 將失去存在的意義。優(yōu)秀的售前團隊合作是接單的重要保障。銷售是非常辛苦的，為了建立客戶關系，尤其是空白的市場是很不容易的，往往為了一個單子會犧牲非常多。 PM 需要把握好這個度，吹是肯定要吹的，只是吹牛的時候一定要有基礎的去吹，對從來沒涉及過的領域或者根本不懂的東西輕易不要發(fā)表意見，挑選自己熟悉的方向合理的進行發(fā)揮，適當?shù)牧羯弦粌墒?，給對方高深莫測的感覺，效果最好。除此之外，溝通的能力與社會經(jīng)驗息息相關，與 PM 的見識聯(lián)系緊密。每個人的人生軌跡都有所不同，思維受環(huán)境的影響也各有差異。客戶感覺他層次也很高，而且和自己有共通之處 ，信任度大大增強，把項目交給他放心。后來他隱約發(fā)現(xiàn)對方對數(shù)學和天文學的發(fā)展史有所涉獵，如獲至寶，回家花一個通宵的時間在網(wǎng)絡上搜索相關資料。金錢與美女依然是常規(guī)的敲門磚，然而這種傻瓜也知道的辦法人人都會去做。鼻子比眼睛高的人只會把 自己的鼻子撞扁。雖然說項目在初期有意向時會對對方的人事和關鍵人物有一定的了解，然而大項目里能說的上話的人太多了。中國改革開放才二十年，很多有錢的老板實業(yè)家文化層次都不高，往往是當大學生們只會把屁股坐在板凳上肆意揮霍父母辛苦積攢的財富時，他們已經(jīng)在各地奔波，積累豐富的商業(yè)經(jīng)驗并對金錢，人生和社會的本質有了充分的認識，形成了自己穩(wěn)定的思維框架。如何放下架子，降低作人的姿態(tài)，對從技術人員轉型的 PM 們來說，是至關重要的。 項目管理的幾大過程 一 .商務談判 作人似乎跟商務談判不太有關系，很多技術人員相信 PM 需要的是本事，是如何做好一個項目，而不是會搞好關系弄的四平八穩(wěn)的人。 降低作人的姿態(tài)需要從多個方面去實施，最主要應該記?。喝?不可貌相，更不可以地位衡量。這些人，很多都是穿著舊舊的衣服，戴著破破的手表，說話的時候經(jīng)常會帶上三字經(jīng)，鉆進上海的人堆里，搞不好你會把他當成民工。上海人最瞧不起的就是土氣，很多人談項目的時候看到民工或很俗氣的表現(xiàn)不免會皺皺眉頭，往往在皺眉頭的時候就失去了項目，也就是失去了市場和金錢。 光尊重別人還不足以贏得項目，準確的說是贏得對方關鍵人物的信賴。老板的關系也只是一個方面，如今的大老板，哪個沒有關系？同等條件下 PM 憑什么去勝過別人一籌？ 我一個朋友（ PM）打一個單子時，發(fā)現(xiàn)對方對什么都不太感興趣，費了很大力氣也找不到突破口。第二天他根本不談項目的事情，只跟對方大談特談哥白尼，布魯諾，伽利略這些人的生平，整整吹了一天。如今這種例子在商務談判中已經(jīng)屢見不鮮了。包括象我們目前這個班級里的一些未來的 MSE 們，一定有比較內(nèi)向或者不太愛表達自己觀點的人，這些人比較被動，往往很難承擔起 談判的重任。在日常生活中， PM 就要多留心，多思考，當別人想到某個層次的時候要爭取比別人考慮的更深。 這個團隊一般是由總經(jīng)理發(fā)起并組建的，通常不指定 PMP，對團隊的成員如 SALES， PM， SA， ENGINEER 們的團隊合作提出了比較高的要求。在這種情況下，和銷售進行協(xié)調自然而然的又落到了 PM 的頭上。 在商務談判的實際操作中，存在著各式各樣的問題， PM 的職責和要求絕非以上幾點所能描述詳盡。與銷售有所不同， PM 在該階段的任務除了接單，還要盡可能的搜集客戶關鍵人物的資料并與對方各個階層的負責人建立良好的客戶 關系，以便在項目實施時充分調動資源。談判的時候一定要確立遞交件的標準和要求，也就是范圍。建立范圍需要的就是 PM 的多年的實戰(zhàn)經(jīng)驗，在大大小小的項目中用血淚換來的一些體會。 項目如何成功？也有一些關鍵的因素。這時候各個團隊或者部門之間不可避免的會發(fā)生資源爭奪戰(zhàn)，摩擦再所難免。有時候，這種內(nèi)耗對項目和 PM 來說是毀滅性的?？蛻敉膊皇翘貏e的積極，主動與客戶聯(lián)系溝通和測試能及早發(fā)現(xiàn)問題。 項目具有商業(yè)行為的幾個重要特征，有 消費源，有參與者，有成功關鍵因素，有財務目標，有風險。項目即將進入計劃階段。 需求分析的主要參與人員有 PM，總體架構設計師，系統(tǒng)分析員，熟悉業(yè)務流程的客戶。最初的需求體現(xiàn)在客戶的工作說明書或招標文件及附件上。這個時候團隊成員要耐心和客戶舉事實，談經(jīng)驗，講道理，用圖形或模型等直觀的方式將需求描述出來，比如常見的數(shù)據(jù)流圖等。 對快速開發(fā)和疊代開發(fā)來說，需求和實現(xiàn)往往是同步進行，開發(fā)速度快是一大優(yōu)勢。所以，大中型項目的需求要認真仔細的去做。所以與其把問題堆積到緊張的項目后期，不如把時間多花點到需求分析和總體設計上。在這樣的軟件規(guī)范下，程序員更象是裝配流水線上的工人，對一個模塊或技術熟悉到一定程序就變成了完全的重復性勞動。由于國內(nèi)沒有象 CMM 這樣的軟件規(guī)范或者很少，所以這類優(yōu)秀的程序員不少都是干著系統(tǒng)分析員甚至 PM的活，拿著程序員的工資。 日本的軟件規(guī)范與 CMM有驚人的相似，其中至少有 35%以上 都是幾乎一模一樣的。往往一個程序員進去干了好幾年，對自己的那一塊熟的不得了，而對隔壁同事所做的東西一竅不通。第一遍需求分析花的時間會最長，分析員們在客戶的各個部門之間幾乎把腿都跑斷，把口水說干，就是為了確立一個初期的需求模型。這些文檔將作為合同的附件添加，以便在將來項目變更或者碰到重大問題時和客戶扯皮的重要依據(jù)。有時候，這種大項目在簽單時雙方都沒有絕對把握保證可以出成果，一旦在需求分析階段發(fā)現(xiàn)難以逾越的技術難關，就會放棄項目。其實并不完全如此，蘇聯(lián)人的情報機構無孔不入，并非那么容易上當受騙。這些會議有與客戶 的會議，與下包廠商的，有團隊的，有公司高層的。還有一些零零碎碎的東西甚至包括辦公場地的大小，電話多少部，所有人的聯(lián)系方式等等都要在會議上確立，并做會議記錄。這個動作雖然在別人看來有些形式主義，但是對提高 PM 本人的士氣和責任感是有很大助力的?？梢哉f， WBS 是計劃階段的核心。WBS 的細目并不需要分解到同一水平，最下面的細目叫做工作包，分包的依據(jù)是個人的責任和可信度，也 就是說到每個人頭上的任務是否能落實，是否有把握完成；還有就是準備對項目進行控制的程度，程度越深， WBS 樹也就越深。然后要花上一段時間讓成員進行頭腦風暴式（ BRAINING STORM）思考，制訂工作產(chǎn)出和相應人員的職責，記錄每一個工作包的完成標準。 既然是商業(yè)行為，那么項