1.2.2 時間、成本、質(zhì)量、范圍之間的平衡
識別出項目干系人后，項目經(jīng)理(甚至項目團隊)應(yīng)了解項目干系人在范圍(Scope)、時間(Time)、成本(Cost)、質(zhì)量(Quality)等方面的期望。這就是通常所說的項目約束三角形(如下圖)。這四個方面代表著項目管理的核心內(nèi)容。
項目管理是目標(biāo)管理方法。一般，項目目標(biāo)是通過明確項目的起止時間、項目成本和要達到的質(zhì)量要求來界定。因此，QCT構(gòu)成了項目的約束邊界，S則構(gòu)成了項目需要滿足的功能要求，也就是產(chǎn)品與服務(wù)的需求。如果產(chǎn)品實現(xiàn)的功能點越多(三角形面積越大)，所耗費的時間則越長，投入成本也越高。而質(zhì)量會如何變化呢?俗話說“做得越多錯的越多”。一般而言，質(zhì)量會隨著產(chǎn)品功能的增強而下降。
假設(shè)客戶的功能性需求S保持一定，QCT會如何變化呢?如下圖所示，為了達到較高質(zhì)量目標(biāo)，勢必進行更多的測試與評審等質(zhì)量控制活動，耗費更長的時間和更多的開發(fā)成本(投入市場后的維護支持成本會降低，客戶總體擁有成本TCO——Total Cost of Ownership會降低);反之亦然。
因此，QCTS在成為項目經(jīng)理開展工作的約束的同時，也成為其在面對問題時，需要考慮的四個方面，甚至成為與相關(guān)干系人談判并取得平衡的手段。
筆者曾親身參與過這樣一個項目：某移動運營商為了在5月17日國際電信日推出一種移動增值服務(wù)，向A、B兩家公司發(fā)出招標(biāo)邀請。招標(biāo)邀請發(fā)出時已經(jīng)是3月中旬左右。這對于AB公司來說，幾乎又是一個Mission Impossible。AB兩家公司毫無例外都想到了增加人手和加班加點的方式來確保按時完成。但人手問題對于哪一家研發(fā)企業(yè)來說不是捉襟見肘，即便即可啟動招聘工作，也“遠水不解近渴”?？磥硪揽咳撕?zhàn)術(shù)縮短開發(fā)時間行不通;加班加點也同樣，試問有幾個研發(fā)企業(yè)的技術(shù)人員不經(jīng)常加班的?
經(jīng)過三天招投標(biāo)雙方的溝通，運營商選擇了A公司。且來看看A公司給出的方案：
A公司首先分析運營商在該項目上最關(guān)注什么?時間，毫無疑問是時間。運營商無論如何無法承受在5月17日推不出新服務(wù)的結(jié)果，因此才會用時間來“壓”投標(biāo)方。既然如此，A公司認(rèn)為在QCS三個方面應(yīng)該有談判的余地。
于是，A公司向運營商提出了兩個要求：
首先，減少產(chǎn)品的需求。通過對產(chǎn)品進行分析，發(fā)現(xiàn)該產(chǎn)品的最終使用者包括兩部分人員：運營商內(nèi)部人員——內(nèi)部用戶、運營商的客戶——終端用戶。因此A公司提出在5月17日前確保終端用戶的使用功能完全實現(xiàn)，內(nèi)部用戶的需求按照卡諾模型[1]進行優(yōu)先級排序，在5月17日前實現(xiàn)基本功能。
其次，考慮到時間緊迫，要求降低驗收標(biāo)準(zhǔn)。在驗收測試時，軟件缺陷密度由千分之二降低為千分之五;產(chǎn)品上線一次成功率100%降低為90%。A公司給出的方案是：減少部分單元/單板的測試工作，但同時提出，在保持產(chǎn)品級技術(shù)評審的基礎(chǔ)之上，增加部分關(guān)鍵模塊的專項評審，并邀請客戶參加。
以上兩點足以保證A公司在5.17完成運營商的要求。這似乎就OK了?
A公司可不這樣認(rèn)為，還提出了補充方案：在5.17正式投入運營之后，一個月內(nèi)，將為運營商實現(xiàn)前期未完成的功能，并且提高產(chǎn)品質(zhì)量到最初的要求(千分之二，100%)。
面對如此全面的方案，該運營商無法拒絕，欣然與A公司簽訂了合同。順便提一句，運營商還為之后一個月的工作買單了。多好的方案!
筆者現(xiàn)正從事咨詢行業(yè)，也接觸了很多為電信運營商提供產(chǎn)品與服務(wù)的企業(yè)。每每談起雙方的合作，這些企業(yè)都滿肚子怨氣“他們(指電信運營商)太強勢了。我們?yōu)榱松姹黄冉邮芤恍┎缓侠淼囊蟆薄Ｊ沁@樣嗎?
1.2.3 人、過程、技術(shù)與工具之間的