專 案 管 理 輕 鬆 學

日益激烈的競爭迫使企業不得不改變原來的管理模式以適應動態變化的內外環境。企業專案化管理(EPM)作為一種新型的組織管理模式在聯系戰略與專案、管理眾多專案上越來越顯示出其強大的生命力。那麽企業專案化管理原則是什麽？

要有效地進行進度控制，必須對影響進度的因素進行分析，事先或及時採取必要的措施，盡量縮小計劃進度與實際進度的偏差，實現對專案的主動控制。軟體開發專案中影響進度的因素很多，如人為因素、技術因素、資金因素、環境因素等等。在軟體開專案的實施中，人為因素是最重要的因素，技術的因素歸根到底也是人為因素。軟體開發專案進度控制常見問題主要是體現在對一些因素的考慮上。

常見的問題有以下幾種情況：

對於專案經理來說，專案管理過程中的溝通是非常重要的。其實溝通並不像想像中的那麽困難，真誠的微笑，熱烈的握手，專注的神態，尊敬的寒暄，都能給對方帶來好感，活躍溝通氣氛，讓專案團隊保持輕鬆和活力。

在溝通中應注意幾個要點：

這種情況很常見，而發生這樣的事情，雙方都有責任，不僅僅是溝通問題，有時是故意為之。發展到這種狀況，想按早先的預期完成專案已是不可能，得重新規劃一下，保障之後的二期三期順利進行。

此時欠缺的還是評估，關鍵在於確認“誤差”有多大。就面向企業的IT服務專案為例，作為專案負責人需要同時做以下十方面的工作：

技術創新專案，需要良好的專案管理作為實施保障。企業要想求得生存與發展，就必須在現有的基礎上不斷創新，並運用戰略管理將各種資源變成社會所需要的產品和服務。

技術創新專案管理常見問題

1. 技術創新活動缺乏有效的戰略指導

許多企業的技術戰略模糊不清，或者實際上根本不存在。公司的技術戰略往往是基於當前外部客戶的需求，傾向於依賴外圍的技術支援，而對企業核心技術能力和技術組合缺乏綜合平衡的考慮。在R&D的資源分配上，缺乏戰略考慮表現在過於注重現有產品和工藝的維持及一些短期發展計劃，很少強調長期發展計劃和新產品、新技術的基礎研究活動。

技術戰略與企業發展總體戰略相脫節的現象也比較突出。從專案管理角度看，企業內的科技創新專案管理一直停留在一種孤立的、隔離的傳統管理方式上，既無法保證在專案水準上彼此間有機聯結，更無法保證與公司的戰略相關。即使有些企業採用了系統化的管理思想，其範圍很有限，也只是停留在專案的水準上，即以分散的專案為基礎的單一專案管理，而不是將所有專案視為一個整體進行管理，忽視了企業是一個系統的戰略整體，它不利於公司在整體水準上優化資源，不能有效地處理與現有業務直接有關的、而且在公司水準上與未來發展密切相關的重要活動。

長此以往，企業的技術創新活動處於較低水準，核心技術發展緩慢，不利於形成持久的競爭優勢。

軟體專案的管理是人事的管理，是企業明確核心業務梳理流程的過程，也是企業內部積極溝通的過程。在專案管理中衝突的解決是關鍵，下面列出幾個重要的衝突管理。

1. 1.     人員管理—信任和授權，是解決衝突的基本點

企業高層對專案經理要充分的信任和授權，充分發揮專案經理的個人能力。如果在對待專案經理的問題有牽制和太極現象，一定要及早的處理解決。專案的成敗就在管理體制和專案經理，對人的管理是專案管理的核心。

對專案經理的能力要求：熟悉企業現在的工作流程和將來的改革方向，熟悉軟體工程，熟悉專案管理，熟悉企業的管理現狀，能夠預見本行業將來的發展趨勢，有責任心，有創造力，主動溝通，主動挑戰，能夠抓住企業的核心基本點。

有以上的保證，加上專案經理能夠自我否定、堅持不懈、積極溝通，一般專案就會很好的完成。否則軟體專案是完成了，但不是您所要的，更危險的是專案根本不能完成。要防止可怕的事：專案經理換人，高層領導變動，專案需求中間變化，專案小組人員大量流失。針對這些事件的發生，要設立個性化的獎勵制度，提供高效的諮詢途徑，對專案組人力資源的特殊管理，要嚴格按照專案管理的要求進行人力資源培訓。

建築精品工程是建築企業抓品質的必然結果。一個企業的精品工程的多少，體現出這個企業品質管理水準的高低；產品品質是建築企業拓展市場的基礎；企業精品工程是企業的品牌，為企業發展提供競爭優勢。

創精品工程不僅要求建築企業從業人員提高思想認識，更要求企業尋找切實有效途徑和措施。企業創精品工程需從以下幾個方面著手。

第一，設計要優

一個優秀的設計不僅要滿足社會的需求，功能合理，造型美觀，符合客戶要求，還要保證社會資源的充分合理利用，以求建築作品的最佳經濟價值、品質價值和社會環境價值。工程設計只有從多個方案中，優中選優，才能讓工程設計經得起歷史的考驗。

一般來說，應該從以下幾個方面入手進行專案管理的創新。

專案管理的觀念創新

專案管理是一門年輕而又充滿活力的科學，即工程專案管理學，它的應用性特別強，並在不斷發展。但是，在專案的管理活動中，發現許多專案管理的從業人員並沒有意識到這一點，這樣，就帶來了隨意性管理，出現了“大幹苦幹拼命幹”口號型管理、嚴管嚴懲的整頓型管理、聽之任之的自由式管理等。

專案管理的制度創新

為了防止分包工程的用工、材料、設備管理不到位，可實行專案承包管理制度，加強對專案責任制的考評，將責任指標細化為進度、安全、文明施工、材料管理、勞動力管理、技術、質量、成本、結算管理等多項內容，並且詳細制定考評標準，以此來規範專案部門的責任範圍和行為，然後進行考核量化評分，可以收到很好的效果。

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

一、使用敏捷開發

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

爲什麽？敏捷開發的特點就是根據用戶的需求迭代，一個迭代解决一個迭代的問題，對於一個對於架構清晰的專案來說，這樣每一個迭代都會有一些成果。而對於有些專案而言，比如說殺毒軟體，磁盤分析器等等，對於這種産品類的專案，很多時候它的需求都是一開始需要定義清楚的，客戶名義上是廣大的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、成本控制　　　

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