乙方變甲方了，怎么做好甲方項目經(jīng)理？

Q

原來做乙方項目軟件經(jīng)理 8 年，去年跳槽到一家大公司的信息化部，今年開始要當(dāng)甲方項目經(jīng)理，缺少當(dāng)甲方的經(jīng)驗，怎么才能做好甲方項目經(jīng)理？

A

你現(xiàn)在甲方公司的信息化部，主要工作應(yīng)該就是負(fù)責(zé)信息化方面的項目，找乙方來做。

在這個過程中，要做好甲方項目經(jīng)理，可以從內(nèi)、外兩方面來看。

一、對內(nèi)

對內(nèi)指的是作為項目經(jīng)理，怎么做好與公司內(nèi)部相關(guān)的事情。主要有兩方面，一是明確需求，二是申請授權(quán)。

先說明確需求。

你負(fù)責(zé)的項目，最終交付的系統(tǒng)，是給內(nèi)部業(yè)務(wù)部門使用的，所以業(yè)務(wù)部門是你的用戶，要從他們那里了解基本的需求，搞明白他們到底想解決什么問題，想在哪方面獲得效能提升。

同時，信息化之類的項目，往往牽涉到不同級別領(lǐng)導(dǎo)之間的博弈，每個領(lǐng)導(dǎo)都有自己的想法和需求，也要注意了解把握。而且這個往往非常重要。

這塊有一個比較常見的問題——領(lǐng)導(dǎo)對信息化項目的要求與業(yè)務(wù)部門用戶想要的不一致。甚至有時候，業(yè)務(wù)部門就想用已經(jīng)習(xí)慣的老系統(tǒng)，并不想上什么新系統(tǒng)，因為要換系統(tǒng)，就牽涉到流程、數(shù)據(jù)等方方面面的改變，很麻煩。

這個時候，你就要和各級領(lǐng)導(dǎo)整合目標(biāo)，達(dá)成一致意見，然后請各個業(yè)務(wù)部門的領(lǐng)導(dǎo)配合摸排本部門的需求。

接著說申請授權(quán)。

公司要上新系統(tǒng)，很多時候大家會覺得這個跟他們關(guān)系不大，主要是信息化部負(fù)責(zé)，只要由你們負(fù)責(zé)搞定就行了。但實際上，項目交付的系統(tǒng)是給業(yè)務(wù)部門用的，你只是“做項目管理”，你不決定需求等等東西，所以你得拉業(yè)務(wù)部門參與進(jìn)來。而有時候，業(yè)務(wù)部門會以“工作繁忙”、“某某需求根本不重要”等等理由，拒絕參與。這個時候，你就需要申請授權(quán)，以便整合不同部門的人員參與到項目中來，共同推進(jìn)項目。

有時候大領(lǐng)導(dǎo)雖然在會議上明確指出某個項目由你負(fù)責(zé)其他業(yè)務(wù)部門要好好配合，但到實際執(zhí)行時，業(yè)務(wù)部門并不一定會積極配合，這種情況就會導(dǎo)致某些事情難以推動，卡在那里。

怎么辦呢？

一個可行的辦法是，你在項目會議或里程碑節(jié)點把控時，把大領(lǐng)導(dǎo)拉進(jìn)來話事，這樣可能會更順利。

二、對外

對外的“外”，指乙方，對外就是你作為項目經(jīng)理，怎么管控乙方做好項目。

對外的基本原則是“卡兩頭，抓大放小”。具體展開說的話，分四方面：

1）定需求

2）審設(shè)計

3）卡節(jié)點

4）盯結(jié)果

一個一個簡要說下。

先說“定需求”。

定需求，就是把用戶需求整理明白，這個其實和對內(nèi)的“明確需求”是一致的，不同的是，你要把從公司內(nèi)整理出來的需求，盡可能無損的傳遞給乙方。

有了用戶需求還不夠，還要再進(jìn)一步，將用戶需求拆解成軟件需求，以 SRS （軟件需求規(guī)格說明書）的形式明確下來。

需求是后續(xù)開發(fā)的輸入和基礎(chǔ)，這塊下的功夫越多，整理得越明確，后面項目開發(fā)就越可能順利，越可能少走彎路。

再看“審設(shè)計”。

審設(shè)計，一方面是技術(shù)方案的設(shè)計，比如技術(shù)選型、架構(gòu)等，這個牽涉到交付質(zhì)量和后續(xù)維護(hù)，你們肯定在初期就要關(guān)注。

另一方面是測試方案，比如用例、覆蓋率等，它們對交付質(zhì)量也有很大影響。

這是第二個你需要重點關(guān)注的環(huán)節(jié)。好的設(shè)計會大大提升開發(fā)效率，大大提升軟件質(zhì)量。

你做過軟件項目經(jīng)理，需求和設(shè)計這兩個環(huán)節(jié)的重要性，你肯定很清楚。它們組合起來，就是我說的卡兩頭中的第一頭——開始那一頭。

接下來說“卡節(jié)點”。

卡節(jié)點是指，你不必特別關(guān)注技術(shù)細(xì)節(jié)，要重點把控關(guān)鍵環(huán)節(jié)，比如在里程碑節(jié)點做審核、階段驗收等，比如在項目例會上確認(rèn)進(jìn)度、功能等。

你做過開發(fā)，可能會容易沉入到技術(shù)實現(xiàn)的細(xì)節(jié)中，較多關(guān)注細(xì)節(jié)，這塊需要注意轉(zhuǎn)換角色。之所以要做這種轉(zhuǎn)換，一方面原因是，軟件實現(xiàn)部分是由乙方負(fù)責(zé)的，他們會排斥你對細(xì)節(jié)的關(guān)注，你不大容易也不大方便深入到所有細(xì)節(jié)。另一方面原因是，你將來肯定會同時負(fù)責(zé)多個項目，深入細(xì)節(jié)會占用大量時間和精力，這樣你就很難同時管理多個項目。

當(dāng)然有時候你作為甲方，需要在乙方的代碼基礎(chǔ)上做一些改動，對乙方代碼質(zhì)量也會有很多要求，比如變量命名規(guī)范、注釋等等，但你在代碼層面的細(xì)節(jié)性要求，可能會遇到乙方的抵觸。因為你的要求和他們的程序員的編碼習(xí)慣，往往不大一致，他們需要調(diào)整自己的習(xí)慣，會嫌麻煩，同時他們的目的是盡快交付，也不想在“看不見”或“不值當(dāng)”的地方浪費時間。

這個時候，就要在溝通交互上采取一些策略。比如抓關(guān)鍵人物，從乙方項目經(jīng)理或者更高的負(fù)責(zé)人入手，和他們在共同目標(biāo)共同利益上達(dá)成一致（他們愿意把開發(fā)和維護(hù)當(dāng)作整體來計算成本，也愿意付出點額外成本換取長期合作），然后讓他們?nèi)ネ苿酉旅娴拈_發(fā)來“按要求整改”。再比如可以讓乙方來提改善方案你們來審核，這樣他們會因為方案是他們提出來的而更有可能執(zhí)行。

最后咱們說“盯結(jié)果”。

盯結(jié)果，主要是在驗收、發(fā)布環(huán)節(jié)，做好把關(guān)工作，盡量不把嚴(yán)重的問題帶到生產(chǎn)環(huán)境中去。而要做到這一點，又和前面的“定需求”、“審設(shè)計”關(guān)聯(lián)上了，你準(zhǔn)確把握住了詳盡的需求，你對技術(shù)方案、測試方案有很好的理解，就能做出覆蓋全面又頗具針對性的驗收標(biāo)準(zhǔn)。

定結(jié)果是我們說的卡兩頭中的另外一頭——收尾那一頭。

好啦，以上就是關(guān)于做好甲方項目經(jīng)理所要考慮到的事情，希望對你有所幫助。

（下圖是在職場解憂會議上使用的問題拆解PPT，供參考。）

往

期

回

顧