專 案 管 理 輕 鬆 學

具有看待和管理高難度談話的正確心態愈發成爲商業成功的關鍵因素。很多領導者僅注重决策的理性和數據驅動面，而忽視决策中蘊含的情緒。然而，情緒是行動的最大推動力之一，在瞬息萬變的時代尤其如此。成功的領導者談話會釋放積極情緒，並將高難度談話轉變爲成功的談話。

 

一、使用敏捷開發

敏捷開發，這是現在非常時興的一個詞，聽起來挺牛的，敏捷，讓我們感覺用了它就會“快”。在被這種開發模式折磨了一年多的我想說，其實它跟其他所有的事情都一樣，它有自己適用的領域，假如錯誤的以爲任何專案用敏捷開發都能敏捷，那就是自找苦吃。

爲什麽？敏捷開發的特點就是根據用戶的需求迭代，一個迭代解决一個迭代的問題，對於一個對於架構清晰的專案來說，這樣每一個迭代都會有一些成果。而對於有些專案而言，比如說殺毒軟體，磁盤分析器等等，對於這種産品類的專案，很多時候它的需求都是一開始需要定義清楚的，客戶名義上是廣大的PC用戶，實際上是PM或是PGM，PM說這個專案裏面我們要做3個功能，那我們就需要做3個功能，多一個不行，少一個也不行，如果PGM在你做了3個功能後告訴你，要加一個功能，而且這個功能在舊的架構上是很難實現的，那麽這個PGM就是不合格的，爲什麽？因爲他加大了專案的成本。

所以，我想說的是，如果需求是由我們自己定義，而且我們很清楚要做一個什麽東西的時候了，采用敏捷開發的風險可能會加大，因爲它過多的依賴於“迭代”，認爲迭代可以解决大多數的問題，可是實際情况遠不如此樂觀!當你的PM對你我們要加這個新功能，之前的定義的功能不行這個迭代要改的時候，作爲一個程序員，我們能做什麽呢?去跟PM說，對不起，我們之前的底層架構不支持這種變態的需求，PM會告訴你，我就是代表客戶，這個功能就得這麽做，我說了算，爲什麽不支持，我們不是採用的敏捷開發嗎，敏捷開發的特點不是迭代來解决問題嗎?

老實說，瀑布模型的好處之一，就是你的PM可以少幾個變需求的理由，PM一個星期變一次需求，我們程序員就沒有幸福可言了，所以，我想勸有些專案經理，別拿需求的變更當做理所應當的，你不是一個嬌生慣養的小孩，沒有必要變的需求就不要變，如果你把敏捷開發的需求變更當做是你隔三差五變需求的理由，那下個專案，當你的程序員聽說你要用敏捷開發，肯定想抱頭痛哭。你是産品的設計師，這個産品的外觀功能，應該一開始就定義好，不要前一個月說要做個電飯煲，這個月又說要在電飯煲加個微波爐的功能，如果你手下的程序員任勞任怨，把微波爐的功能真的加進了電飯煲，那只能說PM幸運，碰到了技術牛人，並且技術確實是可行的，但是如果功能實現不了，那麽PM可能就怪開發者，覺得他們技術不行，心想我用的是敏捷開發，爲什麽我給了你們時間缺不能解决問題呢？

時間確實是可以解决問題，但是作爲開發者更希望把時間多花在需求分析階段，而不是修改舊的代碼上。開發模型只是一種工具，依賴敏捷開發這個工具，並不是解决所有問題的萬金油。

作爲專案經理，你不光要對客戶負責，更需要對産品負責，對你手下的程序員負責。其實，假如做不到後面兩點第一點也不好做到，因爲專案很可能經常delay，到最後客戶不滿意，或者産品上綫的時候早已經落於市場上其他的産品。

二、角色分配

角色分配的問題在整個軟件開發過程也是很重要的，說簡單點就是分工要明確，按照博弈論的觀點，假如我們每個人的目標都是合理的，那麽我們通過相互的制約很好的推進專案的周期，但是如果角色分配的不合理，比如說職責重複，缺少角色等等，那麽開發的過程中就會遇到很多利益衝突，解决不好，就容易導致團隊不和諧，沒有凝聚力等等，最嚴重的情况就是大家各自爲政，都聽不進別人的意見，大家都是會爲別人著想的人，但是有時候想得太多，總是會覺得不合理，不公平，難免影響工作情緒。

在我現在這個專案就有類似的問題，首先，就是沒有一個架構設計人員，經驗豐富的開發和經驗較淺的開發做的事情是差不多的，整體架構的設計名義上是大家一起來做，但是在開發過程中就發現了問題，對於一個架構變動，沒有人有决策能力，TM只會說，有問題跟我說，然後你發現了問題告訴他，他却不知道和誰來商量，經過和一個個的開發者進行了討論，認爲這個架構的變更確實是必須並且可行的時候又要開一次會，來討論怎麽來做這個變更，由誰來負責這個變更，所以說，SD是必須的。而在一次會議上我聽別人說做SD必須要有10年的經驗，我覺得有點可笑，有很多優秀的開發在很早就做上了架構師，我認識的人裡面就有一個，其實我覺得邏輯思維能力較强，有整體架構思想，並且對專案中使用技術有一定研究就可以做SD了，倒是我不明白現在爲什麽很多軟件公司都特別在乎工作年限，認爲做了10年IT就是萬金油了，什麽事情都可以解决，真是大錯特錯。

ˋ

我認爲，做什麽事情都有一個精與不精的區別，假如那句什麽語言不重要，重要的是思想，一通百通的話我覺得真是沒什麽意義。我們都知道C和JAVA.NET的側重點不一樣，一個偏向底層，一個偏向應用，讓一個做C做了10的人去做一個網站可能都做不好，爲什麽?因爲他沒有對網站應用根本就不瞭解，用戶需要什麽他都不知道，他腦袋想的只是如何使用戶體驗更加的絢，但是卻不知道網頁上能不能實現這個效果，網頁上上傳做個進度條能不能實現，實現的難度大不大，他都不知道，這樣的架構師能做好網站嗎。同樣讓NET程序員去做JAVA的事情也不一定做的好。聞道有先後，術業有專攻，這句話是有道理滴。

角色分配的問題還體現在我們不能越庖代厨，如果你是RD，你就不要過多的去擺弄需求，覺得需求不該這麽做，因爲這個問題不該你想，想這個問題只是浪費時間，如果你是PM，你就不要過問架構和技術細節，因爲你始終不如開發瞭解實際的問題，如果你是一個做了十幾年開發的PM，自己手下的技術不如自己，硬要按照自己的想法去做事，那麽不要做PM，你可以做個SD。我以前就碰到過這樣一個PM，讓我去做一個圖片處理的程序，他想讓我把一張圖變清晰，我覺得一張從100K壓縮成了10K的圖你還想讓他變清晰仿佛是不可能的事情，用脚趾頭想問題也知道那丟的90K是幹什麽的，PM要我多測試幾次，經過測試確實是不可行的，但是PM不相信，因爲他做了一年多的開發，於是中午不吃飯跑到我的機器上寫代碼，口中還念念有詞的，等我吃完飯睡好午覺，他終於認輸了，雖然如此，但是從這件事上我就覺得有點不痛快，多的就不想說了。

 

文章截錄：中國項目管理者聯盟

圖片來源：1 2 3

 

ProjectClub 專案俱樂部為一群專案經理人組成的平台，網站分享專案運作的各種專案管理手法與實用專案工具，並分享如何提昇職場人的軟技巧與硬實力。

這個問題是肯定會遇到的，大一點的專案都會再指定一個專案經理來協助産品經理，以確保專案能最終上線，這種情况在大公司很常見，小公司就不說了，否則怎麽叫苦逼的産品經理呢。在接觸了幾個這樣的專案之後，感覺這種配合模式比較難達到非常和諧的地步，專案經理從專案立項開始跟進，到專案上綫，其要保證專案不被delay；産品經理介入的會更早，前期用戶調研，需求確認等等就已經參與了，到專案執行的過程和最終上線運營，都需要參與進去，中間如果不是敏捷開發，沒有嚴格的迭代控制，那麽需求變更不可避免，自然就會影響到專案的進度，這裏就不以敏捷開發爲例了，就以常見的瀑布式爲例。

 

經歷了新專案的落幕之後，單純從結果來講我們體現的比較渺小，針對自己收穫的板塊來講，有很大的經歷值得我去總結和沉澱，在這個過程中，我確實也體會了創業過程中的艱辛和欣喜，唯獨一點就是在成本把控上還是比較不足的。在這邊把這個總結寫出來，希望對那些馬上要啟航新專案的同仁有所幫助。

 

很多時候，人們都在強調執行力，專案的成敗，很多人都將最後的結果歸結為執行人的執行力不夠！怎樣的執行力才算夠？ 

伴隨著中國市場經濟的不斷發展，大量企業在發展的過程中遇到了瓶頸和天花板，在從個人家族治理公司轉型到團隊平臺建立完善制度的過程中，因為企業成立發展所遺留的諸多問題，很多企業仍然缺乏完善的經營管理理念和發展規劃，極大的制約了企業進一步發展壯大的空間。　　

於是，很多企業針對自身內部問題主動尋求關於發展戰略、基礎管理、管理體系、企業文化、團隊建設、行銷模式等方面的管理諮詢服務，希望通過專業化的服務來進一步拓寬企業的發展道路。於是，針對於不同行業領域的管理諮詢機構應運而生，這些管理諮詢機構的使命就是為這些需要專業指導的企業，提供有效的智力服務，扭轉企業內部管理不當和經營不良的局面，以提高企業的經濟效益和市場競爭力。

 

5、成本控制　　　

無論怎麼樣都需要控制成本，盈利和正向現金流對於創業公司來說活下來比什麼都重要，生存是擺在第一位的。燒錢的發展模式不可取，賺不賺錢是衡量公司好壞的第一標準，很多創業專案並不是死在商業模式或者市場開發或者客群培育上，而是死在資金流的斷裂。在資本巨頭還未進入到打車軟體領域時，在打車軟體們還處於群雄割據的局面下滴滴和快的能夠從幾十家打車軟體中脫穎而出的根本原因並不是因為資金雄厚，而是把資金最大化的有效利用，對客戶的體驗這一重要環節做的非常好，積累了一批忠實的客戶，通過客戶滿意度贏得回頭率、贏得客戶繼續轉介紹，比同行活的更久，撐到資本春天的到來，這是綜合開發成本最低、成單率最高的業務來源，是可持續發展的業務來源。

新專案的成功率往往連一成都不到，成功的專案都有各自成功的原因，但失敗的專案大多都會跌倒在相同的坑裡，在新專案的運作過程中，很多被忽視的問題，都是會影響成功的關鍵點，對於這些關鍵點的認知和把握顯得尤為的重要。　　

 

 

只要流程界定清晰，專案經理就能保證專案的發展方向與最終目標相契合。廣義而言，要掌控各種類型專案的發展，首先要關注十個關鍵的流程。

一、生命周期與方法論

專案的生命周期與方法論，是專案的紀律，為專案開展劃出了清晰的界限，以保證專案進程。生命周期主要是協調相關專案，而方法論為專案進程提供了持續穩定的方式方法。

生命周期通常由專案的階段組成(包括：開始、規劃、執行/控制、完成)，或由工作的重複周期構成。專案生命周期的細節一般都會隨具體業務、專案、客戶要求而改變。因此即使在同一個專案中，周期也會有多種可能的變化。對工作細致度、文件管理、專案交付、專案溝通的要求體現在生命周期標準和考核的方方面面。大專案的階段一般更多更長，而小專案的階段少，考核點也少。 與生命周期類似，專案方法也因專案而易，細節關注程度高。產品開發專案的方法經常涉及使用何種工具或系統，以及如何使用。

 

ERP(Enterprise Resource Planning：企業資源計劃)的普及化是件好事情，但普及化帶來的客觀結果與主觀美好的願望有可能嚴重不符。如何使ERP與企業的資源相匹配？如何加強軟體廠家與企業的精細密切的合作？如何實現ERP與企業的成功嫁接？別無它法，惟有精細化。

企業應用ERP必須從大處規劃，從細處著手。ERP的精細化，不像普及化那樣是站在廠商的角度侃侃而談，而是站在客戶的角度來考慮怎樣才能應用ERP取得具體實效，以及ERP如何與企業的個性化管理實踐等細節層面相結合。

 

施工管理工作是保證施工管理按質、按時完成，取得較好經濟效益的關鍵性工作，管理的好壞，直接影響施工管理各項指標的落實。本人曾多次參加工程施工，現就施工管理管理技術進行粗淺的探討。

 

專案的定義是為創造獨特的產品、服務或成果而進行的臨時性工作。請注意定義中的兩點，一是獨特的產品、服務或成果，即專案要有一個成果，這個成果是可控的，不能無限放大;二是臨時性工作，即專案是有時效性的，與專案成果是匹配的，這也印證了專案成果必須是可控的，不能無限放大而失控。專案範疇、時間、成本是專案約束三角形，當一個發生變化時，其他兩個中至少一個會跟隨變化。我認為困擾我們最大的就是範疇管理，客戶對需求本身的不確定性和經常變更，對我們的範疇管理帶來了很大的困擾，從而又引起了進度控制(時間管理)困難，進而增加專案成本。因此，在此我想主要談一談範疇管理。

 

在很多實踐專案中，專案的第一責任人—專案經理往往沒有非常充足的權力，即使在專案化水平比較高的組織中，專案經理缺乏權力也是常見的情況。這與專案經理的崗位特點分不開：那些有經驗、有能力的骨幹員工，往往是專案經理的優先人選。

專案工作要想順利的執行，最關鍵的環節就是各項工作職責的分配。如果WBS中的每一個工作包都能有明確的責任人，並得到相關責任人的認可和承諾，那麼專案工作的執行就會順利的多。通常，責任分配矩陣是實現這一功能的有效工具。在分配職責的時候，最理想的情況是團隊成員自己主動“認領”工作職責。自己認領，相當於做出承諾，這些工作的執行將得到最大程度的保證。但是一定有些工作活動沒有人主動承攬，這時專案經理就必須搞清楚原因，為什麼沒人對這些工作感興趣。

 

IT公司有時就像一個妙齡少女，特追求物質的那種，甲方就像貌似“闊少”的帥哥。當少女看到闊少後，急於把自己嫁出去，就以色相勾引。那闊少也是來者不拒，因此很快就兩情相悅，“非法”同居。過些歲月，感情順利，明媒正娶也是一件美事。可天有不測風雲，那貌似闊少的也許一朝露出馬腳，是個窮光蛋;也許移情別戀，與他人圓滿。那少女豈不鬱悶，因此在同居階段少女也很苦啊，不知道怎麼樣才能成全美事。

 

範疇管理是為了確保專案包含了所有要做的工作而且只包含要求的工作，它主要涉及定義並控制哪些是專案範疇內的，哪些不是。範疇管理的基本內容包括：專案啟動、範疇計畫編制、範疇定義、範疇確認、範疇變更控制這五個要素。

由於專案啟動比較獨立，因此在本文中將不予討論，以下所討論的是在確定專案啟動後的工作，這些工作包括：範疇計畫編制、範疇定義、範疇確認和範疇變更這四個的部分。