綜合管理：項目經(jīng)理和技術(shù)主管的分工

申請免費試用、咨詢電話：400-8352-114

本文是日經(jīng)BP上的一篇關(guān)于項目管理方法的實踐的文章。對于短期的Web小型項目，無論是開發(fā)周期、成本，還是技術(shù)上都有很大的風險。然而許多人對此認識不足，導(dǎo)致項目失敗，或是產(chǎn)品發(fā)布日期一拖再拖、成本大幅上升，或是匆忙發(fā)布后漏洞百出。本文從項目管理的角度說明，即使在小型項目中，項目經(jīng)理也不能將項目全權(quán)委托給技術(shù)主管，而應(yīng)當建立合適的體制，從幾個方面對項目進行控制，這樣才能保證項目的順利進行。
　　通常的項目體制不適合短期開發(fā)
　　在大型機上花費幾年的時間構(gòu)建大型系統(tǒng)時，項目經(jīng)理通常僅負責一個項目，手下也聚集著許多軟件工程師。在需求定義階段，項目經(jīng)理直接與客戶進行交涉，在需求定義中發(fā)揮著領(lǐng)導(dǎo)的作用。
　　這種體制本來十分理想，但對于開發(fā)期間只有幾周到幾個月的小型Web系統(tǒng)來說，卻不盡人意。團隊的實際情況是，項目經(jīng)理和技術(shù)主管通常會兼任數(shù)個項目，設(shè)計、編碼的工作全部交給年輕的工程師或合作方的工程師們。這時，項目經(jīng)理的一部分職責通常會交給技術(shù)主管分擔。
　　職責、分工不明確
　　開發(fā)Web系統(tǒng)時，客戶企業(yè)經(jīng)常會要求使用EJB、XML、Web Service等較新的技術(shù)。項目經(jīng)理為了滿足客戶企業(yè)在技術(shù)上的要求，不得不依賴于技術(shù)主管。另外，項目經(jīng)理通常要照看多個項目，因此與之相比，技術(shù)主管接觸客戶的機會更多一些。
　　這樣，在Web開發(fā)中技術(shù)主管的職責范圍變得非常廣泛。因此，項目經(jīng)理和技術(shù)主管的職責分工很容易變得模糊不清。絕大多數(shù)情況下，職責分工問題不僅沒能形成書面文檔，甚至連簡單的協(xié)議都做不到。極端的例子就是“除了錢的問題，其他全部委托給技術(shù)主管”。
　　這種現(xiàn)象并不鮮見，但是在大規(guī)模項目中，通常會有足夠多的時間和人力來規(guī)避風險，因此即使發(fā)生問題，也總有辦法解決掉。但是小規(guī)模、短期的Web項目中，由于職責分工不明確而導(dǎo)致項目內(nèi)部的意見不一、決策效率低下等，是項目失敗的直接原因。
　　項目經(jīng)理無法掌握項目的狀況
　　讓我們具體地看一看，在項目最重要的任務(wù)之一——需求定義中，職責分工不明確會造成怎樣的問題。
　　在Web系統(tǒng)開發(fā)中，客戶企業(yè)經(jīng)常會在開發(fā)途中增加、改變需求，因此完整的需求在項目初期很難確定。再加上項目經(jīng)理要兼任多個項目，無暇顧及每個項目的需求定義，只得將其全權(quán)委托給技術(shù)主管。
　　這種條件下，技術(shù)主管僅從技術(shù)的觀點來接受客戶的要求，導(dǎo)致項目超過預(yù)算、超過預(yù)定工期的可能性非常大。另外，項目經(jīng)理無法詳細把握需求定義，因此無法把握項目的狀況，導(dǎo)致項目的范圍失控。最終結(jié)果必然是，當問題的征兆出現(xiàn)時，根本無法采取任何對策，如與客戶交涉“先實現(xiàn)優(yōu)先的功能，其他無關(guān)緊要的功能下次再實現(xiàn)”等。
　　想象一下，技術(shù)主管完全根據(jù)自己的判斷來回答客戶企業(yè)的重要問題時會出現(xiàn)什么后果。項目經(jīng)理和技術(shù)主管的意見一致時尚可，意見不一致時，必然會招致客戶的混亂。此外，項目經(jīng)理對技術(shù)主管過于依賴，會導(dǎo)致不好的結(jié)果。例如，帶著“他會做好的”、 “這件事兒是他的責任”的想法，通過郵件給技術(shù)主管分配任務(wù)，其結(jié)果通常是該做的事情沒人負責。
　　建立職責分工的規(guī)則
　　為避免這樣的問題，項目經(jīng)理和技術(shù)主管必須事先決定職責分工。那么應(yīng)當如何分工呢？不同的項目千差萬別，所以并不存在萬能的靈藥。應(yīng)當綜合各種方法，并結(jié)合項目的實際來決定。以此為前提，首先應(yīng)當制定職責分工的規(guī)則。具體來說，要制定以下的規(guī)則。
　　(1) 在需求定義結(jié)束之前，實現(xiàn)哪些功能、采用什么開發(fā)工具、安全實現(xiàn)到什么程度、如何應(yīng)對繁忙時的業(yè)務(wù)量等，這些關(guān)系到系統(tǒng)需求的重要事項必須由項目經(jīng)理和技術(shù)主管協(xié)商決定。
　　(2) 在設(shè)計階段之后，不影響進度、人員計劃的功能追加、修改等項目范圍內(nèi)的事項，首先由技術(shù)主管做出判斷，交由項目經(jīng)理確認之后再做決定?？赡軙?dǎo)致合同變動的項目范圍外的事項，技術(shù)主管應(yīng)當將判斷權(quán)交給項目經(jīng)理。用這種規(guī)則，就能回避職責不明確導(dǎo)致的混亂。
　　共同制作業(yè)務(wù)場景
　　同時，也應(yīng)當建立項目經(jīng)理和技術(shù)主管共享信息的方法。這里，我們以需求定義階段項目經(jīng)理和技術(shù)主管合作制作“業(yè)務(wù)場景”的方法為例進行介紹。
　　新業(yè)務(wù)的場景，即根據(jù)客戶詢問、頭腦風暴、JAD、原型、現(xiàn)有業(yè)務(wù)資料調(diào)查等方式獲得的信息，來描述新系統(tǒng)的樣子的東西。
　　業(yè)務(wù)場景可以用講故事的方式寫成，附以圖表就更完美了。也可以開發(fā)一套能實際運行的原型系統(tǒng)。制作業(yè)務(wù)場景的過程中要不斷與客戶確認，以此為基礎(chǔ)來確定詳細的系統(tǒng)需求。
　　場景制作的材料可以完全委托給團隊成員，但場景本身必須由項目經(jīng)理和技術(shù)主管協(xié)同客戶方負責人一起制作。項目經(jīng)理和技術(shù)主管經(jīng)過不斷的交涉，提煉材料，從開發(fā)的角度看哪些重要，現(xiàn)行系統(tǒng)的哪一部分在新系統(tǒng)中如何變化等，這些問題項目經(jīng)理和技術(shù)主管都要充分認識。這樣，兩者才能獲得一致的意見。
　　技術(shù)主管通過制作業(yè)務(wù)場景來獲得與項目經(jīng)理一致的意見，在確定需求時才能更容易地獲得客戶的新人。另一方面，項目經(jīng)理也有充分的自信能夠“完美地控制項目”。當然，場景的詳細程度需按照項目來定。