進入外包行業(yè)，已經是漫長而又短暫的１１年前的事情了，說其漫長，１１年是人生能夠工作年限的１／４，說其短暫，是這１１年之中發(fā)生的各種項目管理的教訓還歷歷在目。今天借此機會梳理一番，也算是給自己從業(yè)１１年的一個小的總結。 外包是一種合同發(fā)注方式，作為軟件開發(fā)的承包方，我們通常是作為乙方的角色參與案件的，說的好聽一些我們要提供最好的服務給客戶，我們不光賣的是產品，更要賣自己的服務?？墒亲鳛橐曳?，這其中的辛酸只有做過每一個項目的人才能熟知。外包開發(fā)主要參與的工程是設計、制造、單元測試，前期的需求分析和后期的系統(tǒng)上線基本上是由客戶來完成的。項目管理涉及到的知識領域比較多，按照PMBOK２００８版的概念來講，也有９大知識領域，４２個過程組。但單純從外包管理來說，不會完全接觸到這９大知識領域，我從０６年開始接觸PMBOK的管理思想，到今年取得PMP資格為止，經歷了大大小小項目數(shù)十個，其中有失敗的，也有成功的，每一個項目的管理過程都充滿了故事，但是真正給我留下烙印的還是從２００８年的某個項目開始，那是一次例行的中間成果的檢查，按照慣例我們把做好的中間產品交給了客戶，沒想到幾天之后得到的是客戶暴跳如雷，那是我從業(yè)多年以來第一次挨批，而且被批的體無完膚。后來在公司PMO室長的組織下，我們對那次“例外”做了認真的分析，并且認真的總結了問題發(fā)生的起因以及我們采取的對策。多年之后，這些經驗仍然是指導我進行項目管理的方法，今天拿出來跟大家分享。 今天我不再去回顧當時事故發(fā)生的流程，上升一個層面，作為外包管理，當項目遇到了客戶的嚴重質疑，發(fā)生信任危機的時候，作為PM應該采取什么樣的方法，我想同樣在國內的很多項目也適用這些方法?？偟膩碚f，當問題發(fā)生的時候，客戶的態(tài)度是比較著急和嚴肅的，作為承包方的我們，應該站在客戶的角度去考慮問題，先解決問題，再逐漸去完善自己的管理流程和工作方法，避免客戶信任危機的產生。
從大的流程來講，問題發(fā)生時的對應流程應該有以下幾個步驟（按照先后順序） （１） 發(fā)生問題的現(xiàn)狀的確認 （２） 發(fā)生問題的原因的推測 （３） 臨時對應方案的確定 （４） 臨時對應方案實施 （５） 防止再次發(fā)生的方案確定（恒久對應方案的提供） 接下來再具體說明一下每一個步驟中的具體內容。 （１） 發(fā)生問題的現(xiàn)狀的確認 客觀地分析調查發(fā)生的問題是最重要的。我們往往在發(fā)生問題的時候會有些慌亂，在調查問題的時候，難免會有一些主觀的因素加進去，比如“大體上是”、“我覺得可能是”等等類似的文字會出現(xiàn)在我們的調查報告中，這是一個大忌。
如果沒有搜集一些定量的數(shù)據，單純靠經驗或者推測，往往不能得出令人信服的調查報告。 為了能夠比較充分地列舉問題的所在，往往會用到“５W１H”這樣的方法，即：“Ｗｈｅｎ（何時）”、“Where（何地）”、“Who（參與者）”、“What（怎么做的）”、“Why（為什么那么做）”，以及“How（結果如何？）”。
如果我們能夠按照上面的方法去追溯導致問題出現(xiàn)的原因的話，至少在后續(xù)的調查中我們得到的第一手的相對客觀的數(shù)據。 （２） 發(fā)生問題的原因的推測 通常情況下，作為一個軟件產品，在追溯到原因的時候，往往會有以下幾種可 １） 系統(tǒng)或者硬件的故障 ２） 設計階段的錯誤 ３） 開發(fā)或者測試工程的錯誤 ４） 人為的工作失誤造成的 我們在這個階段往往犯的錯誤是找到了問題的淺層現(xiàn)象，而沒有去關注真正的原因所在，從另外一個方面，這個時候時間是最寶貴的，產品往往處于故障狀態(tài)甚至是停止使用的狀態(tài)，迅速找到問題所在是客戶最關心的事情。 （３） 臨時對應方案的確定
找到了第一層的問題原因之后，并且明確了“該怎么做”之后，應該著手制定臨時對應方案，方案的制定要考慮的問題稍微多一些。對應方案往往還會涉及到“品質”、“成本”、“風險”、“時間”這幾個因素的制約，在這種場合“品質”是最重要的，因為解決掉目前的問題是關鍵所在，如果這個時候還在顧慮“成本”，往往會給客戶帶去疲于應對的印象，從而逐漸產生信任危機。
當然，我們往往在實際制定對應方案的時候，會有多種選擇，我們需要根據問題產生的背景去客觀地實施一個切實可行的方案，并且去需求各種要素之間的平衡。 （４） 臨時對應方案實施
拿到方案之后，實施階段往往會涉及到許多之前參與項目的多部門人員。實施的時候需要有一個管理體制，把實施當作是一個項目來對應，協(xié)調各個部門的人員，調整實施周期，制定實施流程，明確實施規(guī)范并制定緊急對策，同時盡可能在實施過程中加入多個監(jiān)測點，實時監(jiān)控方案的實施狀況，避免發(fā)生次生風險。 （５） 防止再次發(fā)生的方案確定（恒久對應方案的提供）
完成了以上四個步驟，可以說在應對客戶方面是暫時告一段落了，但是時候還要對整個項目問題發(fā)生做一次反省，查找其中的根本原因。
從幾個方面可以來關注： １） 規(guī)范 我們在項目開始的初期，是否按照客戶的要求和以往類似的項目經驗，制定了完整的作業(yè)規(guī)范，包括我們的設計方針、開發(fā)方針、代碼規(guī)范、測試用例規(guī)范、成果物規(guī)范等等。以及這些方針是否跟客戶取得了共識。 ２） 流程 往往規(guī)范類的文檔是不會有大的問題的，在執(zhí)行層面也就是流程上，是最容易出現(xiàn)問題的，沒有做到１００％的ｒｅｖｉｅｗ，測試流程不規(guī)范導致漏掉了ｂｕｇ，版本管理流程不規(guī)范導致了發(fā)布的產品版本錯誤等等。 ３） 人的因素 人在軟件開發(fā)過程中是最難管理的角色，軟件開發(fā)以客戶滿意度至上為目標，以人為本，面對代碼和設計資料，加上高強度的工作，即便是有完善的規(guī)范和完備的流程，人的因素往往作為偶發(fā)事件出現(xiàn)，但是往往是偶發(fā)事件會給整個項目或產品帶來隱患。所以，對人的管理不能只停留在制度層面，更多的還是要給予技術人員人文關懷。 ４） 管理層因素 管理層往往會同時管理多個項目，他們往往是項目集管理者的角色，所以一旦項目進入了常規(guī)化階段，管理者往往會忽視項目中的隱含著的不穩(wěn)定因素。所以，設置PMO室是大型IT企業(yè)所必需進行的，定期地對各個項目進行跟蹤并且做出相應的指導，是避免產生問題的一種常態(tài)手段。 由于篇幅制約，只能簡單概括地寫到這里，本人對項目管理的認知程度有限，可能有表達不清楚的地方存在，還希望同行能諒解。僅僅希望這些文字對PMP的管理之路提供一點點借鑒。希望大家都能做一位成功的職業(yè)管理人。
|