【正文】 延長測試時間。但是，優(yōu)秀的不斷進(jìn)取的程序員也很多。如果去這樣的公司應(yīng)聘就要 考慮清楚了，進(jìn)去可以學(xué)到他們的規(guī)范和質(zhì)量控制，可是要想從程序員成為系統(tǒng)分析員或 PM，比登天還難。當(dāng) PM 最終合并了所有文檔并確立需求之后，最終生成的需求文檔將提交給客戶的各部門負(fù)責(zé)人簽字。大家對那段歷史有些含糊，很多人認(rèn)為蘇聯(lián)人上了美國的當(dāng)。在這個會議上 PM 會與客戶確立正式的交流渠道，項目綜合描述，讓項目參與人員相互了解，建立以 PM 為核心的管理制度。 WBS 是一組要提交的項目元素，用來組織定義項目的總體范圍，具體包括從工作內(nèi)容，資源，成本角度考慮項目范圍；建立一套系統(tǒng)所需要的分層工作結(jié)構(gòu)；把項目分解成易于 管理的幾個細(xì)目，這概念有些模糊，其實跟資源管理器里分目錄是一回事情。 PM 要召開團(tuán)隊進(jìn)行討論，向成員提供與項目相關(guān)的所有詳細(xì)資料，并把 WBS 樹分解到二層三層。由于風(fēng)險的不可預(yù)知性，風(fēng)險管理難度很大，概念也很難講清楚，只能從一些可行的角度去分析，進(jìn)行管理。有經(jīng)驗的人可以一起參加討論，把提交出來的風(fēng)險進(jìn)行分類。 風(fēng)險預(yù)留通常是成本的 8%。對程序員來說，進(jìn)度計劃毫無疑問是噩夢。雖然強大的壓力使我們能在短時間內(nèi) 掌握盡可能多的技能，開發(fā)更多的模塊，但是對我們的情緒也是有很大的影響。從前向后的概念就是某項活動必須相同或晚于直接指向這項活動的的所有活動的最早結(jié)束時間的最晚時間。說來殘酷，最能壓的還是 CODING，編碼階段往往是壓縮重點，總之大家埋頭苦干就是了，大項目壓縮的時候程序員吃喝拉撒都在公司是很正常的事情，相信不少人都有很深的體會，這里傷心事情也就不提了。 SOURCESAFE 這些工具有時候還是有必要使用的。 有個問題需要單獨對還沒有 PM 覺悟的程序員說，其實是在調(diào)研的時候就定了的，就是使用什么樣的開發(fā)工具。而需求沒做好，基準(zhǔn)文件里的范圍含糊 不清，被客戶抓住空子搞你一下是非常頭疼的事情，往往要付出無謂的犧牲，有時候甚至非?；鸫?。這種情況非常難辦。 PM 在變更管理中需要做的是分析變更請求，評估變更可能帶來的風(fēng)險和修改基準(zhǔn)文件。 質(zhì)量管理貫穿整個項目周期，詳細(xì)的可以參見 CMM。一般來說，提前完工的項目很少，但是能賺大錢；按時完工的賺小錢；延期的要賠錢。 團(tuán)隊要解散，內(nèi)部會議肯定是 要開的。這中間的感覺，只有經(jīng)歷過的人才明白。說出來獎金發(fā)出去似乎你損失了，其實你賺大了。只有在項目中和生活中不斷磨練，培養(yǎng)自身素質(zhì)和作人的基本準(zhǔn)則，才能成為賺大錢的 PM。 五 .結(jié)束階段 項目結(jié)束時， PM 要將最終系統(tǒng)方案提交給用戶，完成項目所有的提交件，收集項目全部信息并結(jié)束項目，完成或終止合約，簽署項目結(jié)束的相關(guān)文件。 QA 對 PM 的工作最終是有評定的： A 級表示總體在控制下；B 級表示當(dāng)前在控制下； C 級表示有顯著問題； D 級表示有重大問題。相對需求來說，什么 WBS，風(fēng)險管理，計劃進(jìn)度都是扯淡，需求做好了，一帆風(fēng)順。當(dāng)然，有時候一些不是非常關(guān)鍵的模塊 PM 也不至于一點不講情面，該賣面子的時候還是要賣，尤其是當(dāng)著對方領(lǐng)導(dǎo)的面，千萬要賣面子，但是也別賣的太干脆 ，不要讓他們得到的太容易。我舉這個例子并非說不看中工具 ，而是提醒想轉(zhuǎn)型為 PM 的程序員，第一要把工具當(dāng)作工具，而不要被工具套進(jìn)去，鉆研一些一輩子都用不上的技術(shù)；第二要掌握的并非是單獨的一個工具，而是流行的程序設(shè)計的思想，以及在最短時間內(nèi)掌握一門 陌生工具的能力。但是他的代碼似乎也要有點注釋的，沒有注釋過段時間再天才的程序員也不能保證他是最有記憶力的。其實質(zhì)量保證和測試人員的人數(shù)和素質(zhì)都應(yīng)該要高于程序員。在不改變項目范圍的情況下，調(diào)整進(jìn)度有幾種方法：利用快速跟蹤手段來改變?nèi)蝿?wù)間的關(guān)系；將串行的任務(wù)改成并行；改變工作方法（可能改變 WBS）；改變?nèi)掌谙拗?，使關(guān)鍵路徑上的任務(wù)開始或結(jié)束的更早。 里程碑圖表的特征是任務(wù)，成員和時間，任務(wù)和成員用文字標(biāo)志，時間用數(shù)字描述并輔助以圖線跨度，象階梯一樣非常形象，一目了然。我們一般都是一邊開發(fā)一邊做 UNIT TEST，效果上來看，因為有強大的時間壓力，效率上比之前確實要提高不少，可是我們也只能結(jié)結(jié)巴巴的趕完進(jìn)度。預(yù)估的作用主要還是讓 PM 作到心中有個底，安排計劃時不至于毫無頭緒。高和中，中和中的搭配都是屬于高風(fēng)險，中和低，低和低搭配屬于低，高和低搭配屬于中。然后審核由項目小組生成的風(fēng)險清單并與重要成員進(jìn)行風(fēng)險溝通，檢查一些重要的風(fēng)險源如 WBS，成本（時間）預(yù)估，人員計劃，采購管理等等。如同需求分析一樣， WBS 準(zhǔn)備的越充分，編碼的進(jìn)度越快。我整個文章只挑我覺得需要注意的地方，如非必要，對技術(shù)細(xì)節(jié)或者工具使用不做詳細(xì)介紹。 這 時候，作為公司高層，應(yīng)該向全公司發(fā)表申明，正式給 PM 發(fā)布項目經(jīng)理任命書和項目授權(quán)書。這個時候的 PM 會忽然發(fā)現(xiàn)有開不完的會，一天開三到四個會議是很正常的事情。 詳盡的需求分析有一個額外的好處就是對一些雙方都很陌生或者從來無人嘗試的領(lǐng)域?qū)⑹且粋€決定是否進(jìn)行項目的判斷標(biāo)準(zhǔn)。 需求分析 本身也存在著時間分配的問題。有些扯開了，回到我們的話題。他們總體設(shè)計的規(guī)范甚至詳盡到某個過程該如何判斷，確立什么樣的條件，換言之就是把什么時候該如何寫 (if...else)語句都幫程序員定好了。如果不是因為項目有差異，那么市場上就只有產(chǎn)品而沒有項目了。有時候客戶會很不講道理或者思路僵化，就要求按照他的思維去定一些明顯錯誤的需求。由于專業(yè)的原因，我們這里僅討論軟件工程項目的需求分析（以下簡稱需求分析）。因為在和別的新客戶談判的時候，新客戶自然會找你的老客戶了解情況，這時老客戶隨意的一句話頂?shù)纳夏愫苜M心的十句。相反，一個不會作人的 PM 由于人緣差，即使高層強壓別的部門或團(tuán)隊配合，別人也會能拖就拖，延緩項目的進(jìn)度和質(zhì)量。進(jìn)度就不用多描述了。我們把項目最終生成并提交給用戶的產(chǎn)品和文檔統(tǒng)稱為遞 交件。優(yōu)秀的售前團(tuán)隊合作是接單的重要保障。 PM 需要把握好這個度，吹是肯定要吹的，只是吹牛的時候一定要有基礎(chǔ)的去吹，對從來沒涉及過的領(lǐng)域或者根本不懂的東西輕易不要發(fā)表意見，挑選自己熟悉的方向合理的進(jìn)行發(fā)揮，適當(dāng)?shù)牧羯弦粌墒?，給對方高深莫測的感覺，效果最好。每個人的人生軌跡都有所不同，思維受環(huán)境的影響也各有差異。后來他隱約發(fā)現(xiàn)對方對數(shù)學(xué)和天文學(xué)的發(fā)展史有所涉獵，如獲至寶，回家花一個通宵的時間在網(wǎng)絡(luò)上搜索相關(guān)資料。鼻子比眼睛高的人只會把 自己的鼻子撞扁。中國改革開放才二十年，很多有錢的老板實業(yè)家文化層次都不高