跟蹤進度

對于外包工作，組織還常常擔心無法了解工作進展情況。因此，很多客戶常常對基于敏捷的方法很熱衷，他們強迫廠商定期提供中間交付物。然而，這種做法不是總可以發揮作用，總會存在一些情況，除非工作完成，否則不會有可交付物，特別是要交付的與業務而不是技術相關的時候。舉個例子，我曾與一個銷售團隊共事，他們外包了制定全新銷售薪酬模型的工作，后來看到這樣的情況：因為不同元素之間存在依賴關系，只有模型完全定義結束，他們才能看到成果。這不是說工作因此無法跟蹤。然而，一句俄國老話用在這里很合適：“doveryai, no proveryai”，翻成中文大概的意思是：“相信，但還是要驗證”。

步驟2：確保進度跟蹤合適而且客觀

完成工作的小組，無論是內部的遠程部門，還是外部廠商，都應該得到信任。如果雙方的關系沒有信任作為基礎，就會在人和人際關系上耗費太多精力，工作上的精力就不夠了。然而，信任不應該導致無視真相，應該試圖驗證一切進展順利，需要做的，就是將這方面的工作放到項目規劃中。

規劃應該包括定期檢查點，要雙方明確同意期望得到什么：這些檢查點的成果要能表現出項目的進展。成果可能不是實實在在的可交付物，但它們仍然可以是“真實的”。在銷售的例子中，我們讓廠商展示不同的元素，這些元素是他們打算放到薪酬模型之中的，還有正在制定的不同角色和職級、影響提成的變量等等。分開來看，這些東西毫無意義，但是它們表明一切正在向最終目標行進，更重要的是：它們是客觀的度量方法，而不是主觀判斷。

存在某種傾向認為：比起驗證外部廠商的工作，驗證同一組織內部遠程團隊的工作更容易；事實并非常常如此。如果是內部部門，參與工作的人可能更清楚如何“逃避責任”，如果他們想這么做的話；所以在我看來，不管遠程團隊來自內部還是外部資源，我的驗證總是一視同仁。

除了在周會上提供定期的進度更新外，在協作工具中分享，項目主管之間的“必要”談話，這些都有必要。對于項目經理不太能夠了解的工作，我總是要確保他們安排更多時間，以進行正式的工作任務評審。形式上，可能是在某些項目關鍵點的某種結構化討論，對于項目通過某個關卡、達成中間階段里程碑的相關工作任務，所有利益干系人都要評審與其相關的“檢查列表”。其中可能包括中間階段交付物交接，但也可能僅僅是展示已經完成的數據模型、設計確認等。這些檢查點應該視為確認廠商的工作在按進度進行，如果可能，還要跟付款日程綁在一起。如果有必要，它們也可以用來發現和批準糾正不當行為的機會。此時，就要考慮“相信，但還是要驗證”：如果多方之間沒有信任關系，那么可能會隱藏問題(或者假定已經隱藏了問題)，將來也就不在有機會就某種實際的糾正計劃達成一致意見，即便這樣的計劃能夠幫助確保項目成功。

即便存在信任關系，大家仍然有可能對當前情況有不同理解。廠商可能覺得延遲兩天沒問題，但客戶卻有可能覺得這會導致嚴重問題。因此，我總是要確保：這些規劃好的評審中，要記錄成功條件，同時大家要達成一致。成功條件可能包括任何東西，從簽署一份文檔，到完成某些模塊的工作。我甚至見過這樣的成功條件：雇人完成工作和文檔交付相關的度量數據。關鍵在于：大家在項目開始時就認可各個里程碑上成功的意義，這樣在評審中就不會參雜主觀的談判。這樣一來，大家都可以同意延遲的時間長短、超出成本高低等等。這些就會在每個里程碑評審觸發相應糾正措施。因此，評審本身就會成為一種對比，對比規劃中應創造的價值和相應的真實情況。

安排這些評審時，項目經理應該確保評審頻度，避免問題失去控制，但也要留出足夠時間，確保工作能夠推進。而且，評審不能開始得太早，要在工作真正有可以評審的實際產出時再進行，但也不能太晚，要能有余地提供時間來恢復正常和糾正問題。

總結

以上是生活随笔為你收集整理的软件测试项目交付,成功交付离岸项目的三个步骤的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。