談到外包管理，不知別的CIO認為最困難的是什么?對我來說，在外包管理環(huán)節(jié)當中，有一個我一直沒有做得非常有體系的環(huán)節(jié)——人天的計算。我曾與一位業(yè)界前輩交流這個困擾，他說：“做了10多年 IT ，怎么可能連人天計算這種小事情都搞不定呢?”不可否認，他說的有些道理，人天計算的確看起來像是“小事情”，但是在項目展開過程中，它也是一個必要且重要的環(huán)節(jié)。
根據(jù)我的觀察，很多軟件項目在這個環(huán)節(jié)上問題非常多，充斥著所謂“四拍工程”——拍拍腦袋，估計大概多久能完成;拍拍胸脯，保證一定沒問題;拍拍大腿，說聲“可惜了”，沒完成;拍拍屁股走人，攤子交給下一位。
我在實際運作中，曾經(jīng)碰到過外包商與我們的人天計算差異達到100%的情況。造成人天計算差異的具體原因有很多，包括雙方方法論有差距、流程文件規(guī)范不同等。不管原因是什么，一旦發(fā)生這種情況，雙方必定要展開一些協(xié)商工作，以最后達成共識。
在確認每個項目的人天數(shù)上，我心目中的理想狀況是，合作伙伴能提供一個幾乎準確的計算方式，然后在每次合作時，只需要把這個公式拿出來，大家運算一下，就可以決定這個項目需要的人天了。當然，在人天評估上，100%的準確是不可能的，所以需要與外包合作伙伴保持長期合作關系。只有當時間拉長后，計算中出現(xiàn)的問題平攤到每個項目上，才會幾乎消失不見。
不過，可惜的是到目前為止，我還沒看過哪家外包服務商能夠提供這樣的計算公式。因此，我在每次將項目外包之前，會先在內(nèi)部進行人天的評估，然后將這個數(shù)字與外包商的報價進行對比，如果兩者的差異在一定百分比之內(nèi)，項目就直接進入開發(fā)階段，不再做后續(xù)的議價動作。
除了人天的評估之外，仍有幾個“小事情”，是我與長期外包伙伴合作中的重要考量點。
外包商的互補性。幾乎可以確定的是，外包商接觸的客戶一定比我們IT部門接觸的要多。我有一位老師曾說過：“創(chuàng)新的來源之一是將不同領域的一些做法復制到自己所在的領域?！边@句話可以理解為“創(chuàng)意的來源其實不重要，關鍵是你是第一個發(fā)現(xiàn)事情可以有新做法的人?！盋IO一天到晚去參觀別人如何做，顯然不現(xiàn)實，此時，外包合作伙伴就可以成為CIO的“耳目”，他們在不違反法律的前提下，能很好地補充CIO的不足之處。當然，從另一面來說，CIO 也要做好自己的思路被復制到別處去的準備。
在制度上，與合作伙伴更好地融合。通常而言，能夠在外包行業(yè)具有一定規(guī)模的技術廠商，幾乎都有自己一套完整的方法論，而企業(yè)的IT 部門畢竟不是專業(yè)軟件公司，在這方面能夠投入的心力不可能太多。因此，與其自己發(fā)展一套東西，不如讓自己融入對方的體系。好在那些外包商為了與甲方保持長期合作關系，都非常樂意把它的體系移植到項目中來，而且CIO基本不需要為這個服務花什么錢。不過，這個看起來有些一勞永逸的方法，有時也會給CIO帶來挑戰(zhàn)，當CIO有幾個不同的外包合作伙伴時，挑戰(zhàn)便來了——你的員工是否需要適應幾套不同的方法論?
我在這個問題上的做法是，先花費比較多的精力研究前期合作伙伴的方法論，且會找?guī)讉€不同的合作伙伴嘗試。一旦確認比較好的運作模式之后，我會按這個模式要求后期加入的合作伙伴。畢竟預算掌握在甲方手上，所以甲方會有比較強的主動性。
借助外包伙伴，調(diào)和內(nèi)部資源矛盾。IT部門在企業(yè)中的基本定位應該是一個技術性部門，可是我作為部門主管，實在不想讓“技術、工具”這些字眼跟自己的關聯(lián)太緊密，我的團隊成員也希望他們能更多考慮商業(yè)運作上的事。這個看起來與技術定位有些相反的方向，在實際運作中造成了一個矛盾。我覺得，借助外包伙伴的資源化解這個矛盾，其實是個不錯的選擇。目前，在我們IT部門內(nèi)部有一個管理所有程序員的主管，他同時還要負責整體技術方案的方向性規(guī)劃。在規(guī)劃過程中，我并不介意他“借用”外包伙伴的資源。
上述這些考量點，其實都是基于一個假設前提——CIO想和外包合作伙伴保持長期合作關系。如果這個前提不成立，那么所有的一切便是不同的故事了。
