專 案 管 理 輕 鬆 學

研發專案管理，實際上是專案管理在研發管理領域的應用。由於研發工作的獨特性，使得研發專案管理的具體方法與其他領域的專案管理工作存在著較為明顯的區別，因此在眾多公司經過多年實踐後，研發專案管理成為了一個獨立的研究領域。研發專案管理是研發專案組織根據研發專案目標，對研發專案實施工作所進行的各項活動做出周密安排。研發專案計劃圍繞研發專案目標，系統地確定研發專案的任務、安排任務進度、編制完成任務所需的資源預算等，體現了准備做什麼，什麽時候做，由誰去做以及如何做的未來行動方案，從而保證研發專案能夠在合理的時間內，用盡可能低的成本，完成盡可能高的質量。

作為一個專案經理，很多人都面臨著如何帶好自己團隊的問題，小編總結了一些經驗和想法，給大家分享一下。

1、熟悉團隊中的每個成員

人員熟悉的過程是一個互相認識的過程，作為專案經理要瞭解每個人的脾氣稟性、特長和工作方式，並且還要注意大家之間有無個性衝突的問題，防患於未然。人員確定並且熟悉之後，要讓大家能夠同心協力，精誠合作，保持一個團結的心態，要讓每一個人明白，專案成敗和每一個人都有關係，責任是大家的，榮譽也是大家的。

有一個專案經理這樣說：“業務方面，我對產品懂得太少，是不是存在的價值不大？如果說有價值，價值在哪裡？”專案經理是開發團隊中最有權力的角色，沒有之一。專案經理這個職位，在很多小公司裡，或者某些大公司裡，直接就是“老闆”，也有叫“製作人”、“總經理助理”、“產品總監”；在更多的一些中型公司裡面，他們就叫“專案經理”；在某些大公司裡面，也有叫“專案助理”的。

“權力源於選擇性”——專案經理工作本身就是由各種選擇組成。主程(美、策)決定如何做，客戶和老闆決定做什麽，專案經理決定什麽時候做、用什麽資源做、做到什麽程度、由誰去做……。如何完成做出最合理的選擇，以推動專案成功，是專案經理的最大功用，也是最大的挑戰。

專案經理的主要工作內容——溝通、資源、進度。通過溝通，掌握最切實細致的內部和外部的資訊；通過資源工作，讓選擇的餘地更大；通過進度工作，讓選擇得以實現，並且提供真實的反饋，改進掌握的資訊。

水準很高的顧問未必能做好專案經理，因為從某種意義上，你可能太相信自己了，你不放心、不相信你的專案成員和你一樣能把工作做得很出色，所以所有的事情你都想自己幹，但專案內容實在太多，你忙不過來，你累得半死，你的專案成員在旁邊卻無事可做，乾著急，幫不上忙，偶爾幫上了，還被你臭罵一頓。只有無限同情地看著你，看著這個可憐的所謂專案經理。

如大家所熟知，大多數專案經理都出生於土建專業，土木建築是大專業，水暖電通是小專業。

專案經理的位置及其重要，如果說，一個專案是一艘船的話，毫無疑問，專案經理扮演著舵手的角色。

是一個專案的最高領導，也是專案的靈魂。

做諮詢十年的時間裡，發現中國大多數老闆都是靠機會驅動成功的，他們善於抓住國家的政策機會，行業的發展機會，産業化的形成機會，行業的轉型機會，區域的開發機會等等。總之，我覺得大部分老闆都是善於從細微中發現機會、善於抓住機會的人。

他們是一群聰明的人，有志氣的人，有眼光的人，有膽識的人，有野心的人。也是一群幸運的人，有很多人是靠歪打正著的，無意中進了某個行業中然後一直堅持下來，結果因爲堅持就“糊裏糊塗地”成功了，爲什麽這麽說？當你問及他是怎麽樣成功的，靠什麽取得成功的時候，他們可能無言以答，也許他們沒有總結或者不會總結。但是，成功過後，老闆們因爲沒有認真的總結，最後導致失誤而業績下滑，甚至一闕不振，兵敗麥城。其實，成功需要借鑒，失敗也要總結。筆者總結了企業老闆們在30多年打拼中的三大失誤，誠望新創業的老闆在“大衆創業、萬衆創新”的大勢下引以爲戒。

中國的管理諮詢專案成功率不到30%，管理諮詢專案失敗率之高，但也擋不住企業聘請諮詢師進行企業變革，一方面反應了企業需求大量存在，另一方面也反映了管理諮詢成功難度之高。有個諮詢師同行曾對我說：“諮詢不是人做的。”我也是感同身受。作爲一名該領域的新兵，談談應如何做好管理諮詢專案，以此抛磚引玉，希同行補充完善。

我們以購買一件重要設備為例，說明對專案成本的三種認知—資金承諾、費用和現金流。

假設購置了一台價值180000元的設備，六個月後交貨。那麽在下訂單的時後即產生了180000元的資金承諾，六個月後供貨商交貨同時寄來發票，收到發票會立即得到會計人員的處理，產生180000元的費用，但是付款(現金流出)通常會依照公司付款政策拖延一段時間(假設下訂單8個月之後才開具支票給供貨商)。

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

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

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

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

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

各位讀者，是否依然記得上一回，我們跟各位介紹如何利用Trello，巧妙地與日常生活中的旅遊規劃作結合？在這一次的文章中，我們一樣打算不談公事，就讓我們跳脫辦公室會遭遇到的專案範例，來看看還有哪些有趣又有用範例吧！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第一，設計要優

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

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

專案管理的觀念創新

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

專案管理的制度創新

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

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

許多讀者絕大部分都聽過專案管理工具、看板管理等工具，但相信無論針對有無使用經驗的讀者而言，其中有好些人都會直覺認為，這是工作上才會接觸到的東西，所以第一印象往往不甚想要多認識它，亦或保有一定的距離感。可是其實我們也都知道，專案的概念是充斥在生活中、無所不在的，既然如此，這一回筆者就打算，用比較貼近日常生活的案例，套用到我們的Trello看板軟體，讓大家重新用過往熟悉愉快的經驗，輕鬆地重新認識專案管理工具。

一、使用敏捷開發

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

爲什麽？敏捷開發的特點就是根據用戶的需求迭代，一個迭代解决一個迭代的問題，對於一個對於架構清晰的專案來說，這樣每一個迭代都會有一些成果。而對於有些專案而言，比如說殺毒軟體，磁盤分析器等等，對於這種産品類的專案，很多時候它的需求都是一開始需要定義清楚的，客戶名義上是廣大的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；産品經理介入的會更早，前期用戶調研，需求確認等等就已經參與了，到專案執行的過程和最終上線運營，都需要參與進去，中間如果不是敏捷開發，沒有嚴格的迭代控制，那麽需求變更不可避免，自然就會影響到專案的進度，這裏就不以敏捷開發爲例了，就以常見的瀑布式爲例。

先前筆者為各位讀者針對Trello介紹一系列的擴充支援軟體，讓我們在Trello上的操作應用，能更加廣泛多元而得心應手。這一回筆者一樣要介紹可以幫Trello加分的小工具，但是卻非額外的擴充系統，而是平時隱藏在Trello中的小地方。今天要幫助大家把它們找出來，不知道細心的您，在使用時曾否發現過它們的蹤跡呢？

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