項目管理-項目管理的幾大過程-免費閱讀
【正文】 其實真正體現(xiàn)客戶滿意度的地方有很多。一般跟客戶要開一個，主要是確定所有的提交件都已經(jīng)被接收，對突出的個體進行表揚，對外宣傳成功案例，標志并記錄項目的正式結(jié)束。 PM 辛苦了那么多，終于可以高興一下了，收到最后一筆款項，意味著遞交件的移交和團隊的解散，項目也轉(zhuǎn)入維護階段。得到 A 的 PM 是很逍遙的，基本上不會有人來過問。其實人心都是肉長的，如果可能的話，我還是不贊同使用一些手段的，但是有時候客戶非常難以在短時間打動而工期又將接近，這種情況下就要靠 PM 耍一些手段了 。有時候爭論會很厲害，到非常白熱化的地步， PM 與客戶代表幾乎溝通不了。 對任何項目，變更無可避免，無從逃避，只能去積極應對，這個應對應該是從需求分析就開始了。別人的公司都是團隊，兩人智慧勝一人，這頭還在靠一個天才支撐門面，實際上市場可就別人搶了去，那時候再天才也沒用了。他們這樣培養(yǎng)人的目的或許就是為了壓縮吧？！ 四 .控制和執(zhí)行階段 實在沒什么好說的，也是大家最不愿意談的，平時在公司里談的已經(jīng)夠多的了，還要在這里受我嘮叨。如何壓榨，還是個技巧。 網(wǎng)絡邏輯圖是表示任務和邏輯關(guān)系的示意圖，可以用先后次序表示，也 可以用關(guān)鍵路徑表示。我每天早晨六點多出門，經(jīng)過將近兩小時顛簸，八點多點已經(jīng)坐在位子上，中午吃 15 分鐘的飯，干到晚上八點下班，到家吃完飯往往已經(jīng) 11 點了。進度計劃是從 WBS 提取過來的。到目前為止也沒有一個定論說有絕對好的方式，只能盡其所能的避免。 識別之后要進行分析。有些風險很容易解決，有些風險則大大損害利益。由于 WBS 是實用性的東西，根據(jù)個人理解也不一樣，所以一個項目可能會有幾個正確的 WBS，看 PM 的需要和最適合當前團隊狀態(tài)的進行選擇。 三 .計劃階段 （ WBS） 啟動階段結(jié)束后，項目進入計劃階段，也就正式進入實施。團隊的會議主要是建立正式的團隊，提供團隊成員的角色和職責，提供績效管理方法，向成員提供項目范圍和目標。典型的例子就是 NMD 洲際導彈防御系統(tǒng)。所有的文檔將會提交給 PM 進行復審并簽字，不合格的打回重做。最近經(jīng)濟不景氣，東京倒閉了 160 家軟件公司，這個數(shù)字是今年 6 月份的，還在不斷增加。所以在日本和歐美經(jīng)常會有程序員是低級工作一說，很多人不明就里，對國內(nèi)程序員也照搬，對國內(nèi)的程序員來說是很不公平的。我們要討論一個問題，究竟應該在需求分析和總體設計上花費多少時間？我們熟悉的瀑布開發(fā)模式基本上分需求分析，總體設計，軟件開發(fā)，測試等幾個階段，然而究竟應 該在前兩個階段上花多少時間卻沒有定論。所以說，爭論再所難免，客戶有時候會吹胡子瞪眼睛拍桌子甚至會說 這個東西不要你們做了 之類的話。 PM 統(tǒng)領(lǐng)的團隊這時候還不是真正的開發(fā)團隊，我們叫做前期團隊。 根據(jù) PMI 的解釋，接單之后項目自然轉(zhuǎn)入啟動階段。對客戶的積極反應也比較關(guān)鍵。個人的理解也不盡相同，通常包括以下幾個方面：界定工作目標及工作任務；老板或高層的支持；優(yōu)秀的 PM 和開發(fā)團隊；充足的資源；良好的溝通；對客戶的積極反應以及適當?shù)谋O(jiān)控和反饋。盡管商戰(zhàn)的時候不可避免的客戶會不斷提高標準和要求，而承諾的款項卻不會有一分錢的增加。根據(jù)環(huán)境，政策，人文，關(guān)系等各方面的不同情況， PM 的不同成長經(jīng)歷，每個 PM 最終都會建立自己對商務談判的看法和經(jīng)驗。一般公司在接下一個單子進行到一定程度的時候， PM 往往會尷尬的發(fā)現(xiàn)協(xié)議上銷售代表們對客戶的一些承諾是幾乎做不到或者根 本做不到的事情。從今天開始，這類人就必須重新學習如何說話，如何大聲的爭論。對方點頭如搗蒜泥，態(tài)度和熱情都來個一百八十度轉(zhuǎn)彎，隔天他就拿到了單子。 PM 一般用不著陪客戶喝酒吃飯，那是銷售們的事情，但是 PM 和客戶討論問題可能是最多的。因為到他們所處的社會地位，已經(jīng)不 需要任何華麗的外表來襯托自己的身份，他們有的是底氣。隨著 PM 在中國的悄悄興起，越來越多的 PM 開始在老總的授意下參與商務談判，和銷售們一起打單子，這就比較實在的需要 PM 們?nèi)ゴ蛻舻男睦?。然而，老板多半是沒有約束的。只有作到謙虛謹慎，不擺架子，尊重別人，才會得到別人的尊重，才有機會贏得項目。他花了好多天和對方交談，以自己的博學逐漸取得了對方的信任。 胸中有萬千墨水卻不知如何表達其實是比較少見的，但并非絕對沒有。這種人，碰到不懂，不太認真或者好奇心強的客戶是有一定市場的；而有水平，負責任的客戶往往會覺得這種人不可靠， 一般不會把單子交給他。在組建團隊的時候， PM 要根據(jù)團隊里每個人的素質(zhì)和任務進行因人置宜的信息傳遞。實際操作中多分為范圍，成本與進度，其中最重要的莫過于范圍。成本就是客戶答應付的款項，與我們的投入成本并不是一回事情。除了高層對 PM 項目的重視程度，如果 PM 平時在公司與同事相處的好往往能使很多別人看起來很棘手的問題迎刃而解。積極的態(tài)度可以帶動客戶的積極性，在項目完工的時候，客戶對你的感激往往是難以用語言描述的，這對以后接單或者做二期三期會打下良好的基礎(chǔ)。接下來就是需求分析。前期團隊要根據(jù)自己的經(jīng)驗和客戶溝通并引導客戶進入正軌。然而，大中型項目中有太多不一樣的需求和模塊。 在日本公司打工的程序員們可能都知道，小日本的軟件規(guī)范 非常厲害，他們花在需求分析和總體設計上的時間通常在 40%到 50%左右，遠遠超過國內(nèi)軟件項目的實施，效果也要強的多。當上進的程序員們作為 PM 進行商務談判的時候，前者還在各個公司里頻繁跳槽，跳來跳去都不滿意。當然，已經(jīng)作到 PM 或 QA 或者熱愛 CODING 的朋友例外。在啟動階段明確需求并簽字，無論最終情況如何，一份詳盡的書面文檔可以解決很多口頭承諾或概念模糊的文檔帶來的許多問題。 項目啟動要確定項目計劃，與客戶一起實施第一次項目審核，確認并對一些產(chǎn)品和服務向下包廠商下訂單。大概就是所謂三軍未動，糧草先行吧。 WBS 有縮進式和樹狀式，我這里也沒辦法畫圖，大家參考一些項目管理的書籍，里面有詳細介紹。盡管很麻煩，制訂 WBS 仍然是非常值得的。 PM 要先召開風險識別會議，這個會議面向公司，高層，跨部門的有經(jīng)驗的人都將參加。碰到這種風險只好讓客戶修改需求或者增加風險預留成本，否則一旦虧起來不是虧一點 點，有可能賠的很厲害。預估似乎沒什么特別需要提的地方，每個 PM 接到項目的 時候自然會有預估，在項目發(fā)生變更或進入下一階段時也會預估。我的 頭倒是用的很溜了，近一個月來他就用這個 PROJECT 畫了一
公司管理相關(guān)推薦
鄂ICP備17016276號-1