一起工作，分開就座
![]()
，譯者
鄭柯
發佈於
2014年10月22日
|
討論
要想判斷你的離岸外包冒險之旅是否成功，有兩個最根本因素：人和過程。有人會說：過程是最重要的；另外有些人將人放在第一位。8年前，我開始實施近地外包，當時認爲流程最重要。我相信，必須要搭建某種像工廠一樣的流程，這樣離岸外包才能成功。現在，我相信：雖然流程至關重要，但人是最基礎的根本。出色的流程加上不怎麼樣的人，結果必將讓你失望。僱傭最好的人，卻沒有任何流程，結果會讓你吃幾個。如果你僱的人有問題，他們可能根本不注意流程，而是直接“開步走”。這常常導致各種溝通和項目管理方面的問題。
本文的早期版本曾刊登於《如何組織離岸外包和近岸協作》這本書中，它屬於一系列管理遠程團隊的書籍。
本文是管理遠程團隊系列文章的第一篇。我將分享的經驗，談談如何構建適用於遠程協作的穩固流程。當人們身處多個遠程地點時，必須付出更多精力，闡明團隊如何協同工作。在Bridge公司，我們研究出一種工作坊，一直將其提供給新客戶。我們還創作了工作手冊，其中有些章節提到達成遠程高效協作的幾個關鍵因素：
- 流程：我們如何工作？
- 責任：誰負責做什麼？
- 項目管理工具：我們如何跟蹤項目？
- 溝通：我們如何溝通？頻度如何？
- 績效：我們用什麼來度量績效和進度？具體如何度量？
- 編碼規範：我們的標準是什麼？
- 時間記錄：我們如何記錄時間？
- 形成“同事”：我們如何一起工作，發揮潛力，成爲朋友？
我會討論其中三個因素：流程（“我們的工作方式”，包括規劃、需求和測試）、責任和績效。大家可以在我們的網站下載免費的工作手冊。
1. 流程
軟件項目中，很多人會自然地“馬上開工”。他們會在東歐或是印度選擇一個合作伙伴（後者要在招投標上用很多時間），然後就“開始工作”、“啓動項目”。尤其是針對固定價格的外包項目關係，他們會期望合作伙伴知道如何着手項目。需求寫完了，也發給供應商了，我們現在可以坐享其成，等着成果在指定日期交付就好。但是，這可能嗎？
當然，作爲外包的“買方”，你有權期望外包合作伙伴知道外包的工作方式。遠程團隊必須瞭解如何滿足你的要求，讓你的項目成功。而且很可能他們也是如此。但是你呢？
他們瞭解你的具體情況嗎？知道如何讓外包過程符合你的具體項目嗎？當然，很多外包廠商都是技術公司。他們開發能力很強，但這不意味着他們可以保證複雜的協作過程順暢無阻，這個過程要跨越文化、時區、不同語言的差異。最近，我跟荷蘭一家大銀行的 CIO 聊天。他告訴我：只要是把徵求計劃書（RFP）發到離岸廠商那邊，得到的迴應一定是深入技術細節的解決方案。而他一直在尋找的公司，要能告訴他自己如何交付他需要的解決方案：他們會用什麼樣的人，建議使用什麼樣的流程，建議如何與在岸的產品負責人協作。
在離岸團隊開始執行項目之前，在他們開始分析你的需求、撰寫代碼之前，你必須召開一次會議，離岸和在岸團隊都要參加，大家一起討論具體工作方式。不妨從你們各自當下的工作方式開始。因此，兩種方式可以在這裏碰撞——你們的工作方式、廠商的工作方式——這意味着其中某一方（或者雙方）要調整、適應彼此的行爲。
軟件開發是創造性過程。指望往一個標準化過程中灌入需求，然後得到完成的產品，這對任何客戶來說都是一個美夢。但這不是任何創造性過程的工作方式。過去，軟件開發遵循建築行業的構建過程，人們制定出了瀑布模型。這個模型主導了20來年的工作方式。今天，一切都要“敏捷”。創造性過程自然就是敏捷的。本文中，爲了簡化起見，我將會使用瀑布和 Scrum 作爲流程因素的兩個極端加以討論。
你現在如何工作？
你遵循的過程接近瀑布模型嗎？還是你們已經完全敏捷了？你們是不是像很多公司一樣開始使用 Scrum？也許你們已經應用了極限編程或是看板？在 Bridge 公司，我們構建的遠程團隊專爲某家公司的內部 IT 部門服務。我已經體會到：最具挑戰性的客戶，是提供服務的公司（相對於構建產品的公司而言）。尤其是小型服務提供公司，比如互聯網公司，要想讓離岸發揮效果，非常具有挑戰性。而且，在大多數情況下，客戶強制要求使用固定價格。也許得使用瀑布式模型才能按固定價格報價。如果你是規模比較大的服務提供商，那就完全不同了。基本上，大型服務提供商要爲客戶的長期項目構建“產品”。因此，在打造流程的時間和靈活性更強，可以得到期望的產出。這種情況下，合作雙方都有更多時間制定聯合協作流程，即便價格或時間有限制，項目還是更易於成功。
現在，請用一些時間，梳理一下你自己真正的工作方法。我自己的經驗是：Scrum 基於某些原則，而不是定死了的流程。因爲人們會遵循“原則”，所以就有很多種方式可以產生工作方法。很多公司因此認爲自己在實施 Scrum，實際上他們用的是瀑布或是看板，或是其他類似的過程。如果你希望與遠程團隊建立順暢、完整的寫作方式，你必須告訴他們（在你自己眼中）自己的工作方式，以及你希望的工作方式（你希望在自己流程中看到的改進）。很多時候，工作方式都沒那麼正式（也就是沒有文檔或流程圖）。自己團隊中的人們在潛意識中已經形成一套工作方法。然而，新加入的遠程團隊必須從意識上認識、適應新的工作方法，這個方法也是你們彼此同意的。所以，不僅要討論工作方法，還要用筆寫下來，畫下來，讓人人都能看到，從而產生責任感。如果僅僅以口頭方式說明工作方法，開工之後，可能會發現大家對其理解彼此不同。
你如何估算工作？
瀑布模型有一個十分嚴重的問題，就是對項目的估算。不妨看看你個人的規劃。你個人如何規劃自己一週的工作？如果你看看這周的事務優先級，是否能準確估算出每一項要佔用多少時間？要是估算接下來這個月呢？要是接下來這一年呢？要想知道估算的準確程度，比較你的預計時間和完成任務的真實使用時間。可能你會發現：真實使用時間是估算時間的2-3倍，每個季度是5-10倍。
我們希望軟件開發者能給出比較好的估算，還發明瞭各種方法讓其更準確。但是，我們是否的確更接近真實情況了呢？一般來說，爲客戶完成的項目需要提前估算。因此，常常使用簡化的計算過程，以加快投標進度。既便如此，你也不能無視：即便贏得了投標，到了某個時間點，離岸團隊還是要估算工作量。而且很有可能他們已經偏離了估算，那時你已經偏離預期進度了！
如果你以這種方式工作，而且無法改變瀑布模型。那我建議你尋找使用相同流程的離岸合作伙伴，他們已經習慣使用固定價格方式，他們的流程也能符合你的估算。不過我還是推薦儘可能改變這種流程。你可以先向當前流程中引入某些 Scrum 的元素，然後一步步改變流程，也許可以跟你的離岸合作伙伴同步進行。引入敏捷的原則和 Scrum 需要花時間，要培訓團隊如何實施 Scrum 時間，讓你的某些僱員認證成爲產品負責人或是 Scrum Master。這個變化會需要幾個月，並且可以在與遠程團隊開始項目之前，讓離岸合作伙伴幫你一起建立流程。
如果你正在使用敏捷或是 Scrum，那就最好不過。你可能使用規劃撲克（或是其他方法）來估算每個用戶故事，整個團隊都要認可這些用戶故事。如果你需要估算整個項目，可以大概估計一下項目範圍，然後利用 Scrum 的靈活，在每個 Sprint 中調整工作量，最終完成項目範圍內的工作。理想情況，當然是整個團隊，包括離岸團隊，都能加入Sprint 規劃，同時認可項目範圍。
我們如何定義需求？
知道需要構建什麼，而且能用清晰的需求文檔加以表達，這是軟件開發最具挑戰性的方面之一。再加上遙遠的距離，以及不同時區、不同語言、不同文化的差異，難度大大增加。
瀑布模型假設我們可以事前想清楚要做什麼。我相信，如果時間足夠多，我們可以做到，但也只能完成75%-80%，所以，風險在於：當你完成某些功能時，它可能已經過時了。如果我們在遠程協作中選擇這種方式，那就必須要提前規定清晰的指南，說明如何制定需求規範。要回答類似下面的問題：
- 需求規範中哪些細節最爲重要？
- 我們是否要創建單獨的技術需求規範？如果是，哪些規範最重要？
- 離岸團隊如何參與到需求規範的制定或擴展？
- 針對需求規範的附加條件、優先級變化、刪除，如何討論、達成一致、保存？
這些問題的答案必須有明確的紙質（或電子）記錄，這樣每個團隊成員對於需求的設定方式纔能有清晰理解。要是能附上一份“理想需求”的範例作爲補充，那會很有幫助。
最根本的問題是：誰負責創建需求？一般都是在岸團隊負責，因爲他們更接近客戶。但是要想清楚。如果在紙面做出某些承諾，那一定是經過了深入思考，這些思考來自於此前與客戶的多次討論。然而，遠程團隊卻沒有參與到這個互動中。所以，這些需求文檔對你很清晰，對遠程團隊卻如迷霧一般。要讓遠程團隊儘量早加入解決方案和需求的制定，這樣他們就更易於理解這個過程，知道要構建的東西。
如果你在使用敏捷開發過程，討論和會議就是你的起點，而不是需求。至於需求，整個團隊都參與到制定過程中，而不僅僅是某一個人。
首先，產品負責人會與客戶或用戶對話，將需求轉換成用戶故事，然後 Scrum Master 和開發團隊（設計人員、開發者、測試人員、架構師）會進一步探究每個用戶故事。要明確理解這種流程在你公司內部的機制，這很重要。
我觀察到：有些公司稱之爲“Scrum”，即便他們沒有真正遵循這個方法。這麼一來，舉個例子，產品負責人（或是既當產品負責人又當 Scrum Master 的人）就會跟客戶討論，詳細描述用戶故事，預先描述解決方案，有時會深入到技術實現細節，然後會將“用戶故事”發送給開發團隊。如果你這麼做，就等於創建了“迷你瀑布”模型。雖然這種方式能出成果，但你和遠程團隊一定要明白：使用這種模型，會影響團隊的參與程度，以及團隊對需求的理解深入程度。
如何做計劃？
電子書《如何組織離岸和近岸協作》中，有整整一章講到規劃，本文只提出一些要點。
如果使用瀑布模型，你可能要制定出使用工具（比如 Microsoft Project）創建項目計劃的標準化方式。要思考制定計劃的方法，這有助於爲遠程團隊提供明確的書面理念。你是否要讓離岸團隊參與到規劃活動中？他們是否會創建設計，還要經過你批准？你是否創建供他們執行的規劃？
在 Scrum 中，你是否認真進行了 Sprint 規劃？整個團隊都參與到規劃活動中了嗎？如何計算Sprint 中有多少個小時可用？團隊成員能夠將80%的精力用在用戶故事的高效開發上嗎？或者至少能保證50%？誰爲 Sprint 中的工作負責？
誰負責測試什麼？
測試是軟件開發中的灰色區域，各個公司的實施方式完全不同。很多公司希望他們的開發人員能測試自己的工作（但這麼做如何做到“驗收”？），然後項目經理會完成某些最終測試，再發給終端客戶或用戶。大型團隊有專職測試或測試部門，他們評估開發完成的功能或是用戶故事。此外，有些人使用小組測試，在 Sprint 最後一天，整個 Scrum 團會聚在一臺電腦前共同測試。
這裏的重要之處在於：記錄組織當前的測試流程。你希望每個人都做什麼？面對與遠程團隊成員的合作，你在測試上要做出哪些調整？驗收條件，或者“完成”的定義是什麼？把一切都寫下來，與遠程團隊討論，對於如何完成測試，要得到清晰的共同理解。
2. 責任
如果把團隊放在一起，讓他們“馬上開工”，他們能否成功完成項目，很難說。在我看來，在團隊開始工作前，一定要討論清楚各自負責什麼，然後寫下來。
公司層面是最佳的起始點。兩邊的責任是什麼？與項目有關的首要問題，是項目或產品的相關責任。誰負責規劃、設定截止日期？誰負責項目管理？要想回答這些問題，必須劃分明確的界線，而且要以契約形式確立。其他因素包括：誰負責管理人？誰確保每隔3-6個月團隊成員就可以跟管理者討論自己的個人發展？誰負責培訓的決策和組織？
在 Scrum 中，產品負責人和 Scrum Master 是最重要的角色。在瀑布模型中，這些問題都差不多，雖然角色命名有所差異。
在離岸語境中，分配職責最有效的方式，就是讓產品負責人在岸，儘量接近客戶。離岸團隊可以有第二個項目負責人，不過要是項目不大，這麼做有可能更復雜。Scrum Master 離岸或在岸都可以。常用的方案有：
A. 在岸產品負責人與離岸 Scrum Master（加上團隊）對話。
B. 在岸產品負責人與離岸產品負責人對話。
C. 在岸Scrum Master與離岸 Scrum Master對話。
D. 在岸Scrum Master與離岸開發團隊對話。
理想狀態下，客戶或最終用戶會在 Sprint 規劃會議中與整個團隊對話，要是能與（虛擬）Scrum團隊（無論是離岸、在岸還是混合的）坐在一個辦公室中，就更好。可是，很多時候，產品負責人會跟客戶對話，然後將所有的用戶故事告訴團隊。無論選擇何種方式，整個團隊（包括產品負責人和 Scrum Master）都要在 Sprint 規劃中使用視頻會議。
爲了保證責任界定清晰，要回答以下問題：
- 誰負責描述用戶故事的實現（從功能以及技術角度）？是離岸還是在岸 Scrum Master？
- 產品負責人能描述多少內容？
- 在 Sprint 中，誰負責決定開發什麼、何時開發？如果那個人因爲時區差異找不到該怎麼辦？
- 誰負責做演示？
- 演示的目標人羣是誰？
- 誰主導功能測試？
爲了完成每個人或者每個角色的責任列表，我會繼續闡述如下問題：
離岸協作中有一個關鍵角色——“流程經理”，也稱爲“交付經理”、“質量經理”或類似名詞。此人的責任在項目之外，其核心工作是確保在岸和離岸團隊順暢溝通。比如，在比較大的環境中，在岸和離岸團隊中都有這樣的角色會更好。這些流程經理每週開會，評估當前的整體表現。他們不會深入到每天的項目進展細節中，而是有相對外部的視角，爲團隊溝通的方式提供有益的建議，他們會覈查流程，看看是否偏離正常方向；他們還可以保證項目符合合同中的相關條款，以及諸如此類的事情。
我們有一個開發在線約會平臺的客戶，當時我們使用了上述協作方法。產品負責人位於客戶在蘇黎世的辦公室，Scrum Master 也是。在岸流程經理位於荷蘭，離岸流程經理位於烏克蘭的基輔，跟團隊在一起。CEO 一開始擔任產品負責人。在每週定期的會議中，我們發現一個問題：CEO 有時候找不到。團隊常有用戶故事的問題，但他總是沒法直接聯繫上，這會導致進度延遲。我們決定，蘇黎世辦公室中需要一個新的產品負責人。這個新產品負責人加入之後，障礙數目迅速下降，開發速度得以提升。很多時候，如果流程經理不能每週見面，這樣的問題可能要幾周乃至幾個月才能發現，拖慢項目進度，影響團隊之間的關係。
3. 績效表現
在公司層面，基本上只有一個問題：這種寫作能否交付我們需要的價值？在 Bridge 公司，我們每週都會來回問這樣的問題。這不是一次就能回答的問題。在岸和離岸團隊必須適應寫作。目標是構建合作伙伴關係，要一起寫作，要創建協同效應，達成1+1=3的結果。畢竟，這纔是最重要的。當然，你也可以度量響應時間、工作效率，或者其他與你的 SLA 聯繫在一起的變量。
如果有多個團隊參加多個項目，項目主管也不一樣，同樣問題也可以在團隊層面提出。
需要評估的最重要的績效，就是個人層面的績效。團隊由人構成，所以我們需要有人評估每個個人的技能。如果（離岸或在岸的）Scrum Master 可以每個月或者每季度完成類似評估，那就最好不過。在 Bridge 公司，我們讓客戶每個月評估單個團隊成員。我們使用1-10的評分，以確保清晰明白。一般來說，我們使用下列問題（根據項目某個方面的重要性不同，我們會修改問題）：
這個開發人員能否：
- 滿足你的期望？
- 及時響應你分配的任務？
- 自己做出有效決策？
- 理解產品或項目的商業模式？
- 以開放心態接受反饋？
- 在答應的時間進度內完成工作任務？
- 適合你未來的項目？
除了這些“正式”的績效評估外，還必須建立有節奏的會議。如果你遵循 Scrum，每天的站立會議中、在演示時、在回顧會議中，都可以爲團隊提供反饋。我們也有與流程經理每週的會議（見前述內容），其中每個離岸地點都會像前文一樣，給協作打分。每個季度，我們會與每個成員、我們的 HR 經理、流程經理等，單獨開會。某些時候，我們的客戶會加入或者接手這個季度個人發展會議。
對於更大規模的企業，《如何組織離岸外包和近岸協作》這本電子書有一章很有價值，講到 Erwin de Bont，其中提供了一個度量績效和 KPI 的框架。
結論
要想爲遠程協作奠定堅實基礎，在真正“開工”之前，必須留出“思考時間”。項目啓動之前，想想你每天的工作方式，以及如何調整這些工作方式，才能與離岸團隊一起工作（流程）。你可以思考如下話題：
- 我們遵循哪些步驟？
- 我們如何達成估算？
- 我們如何列出需求？
- 我們如何規劃？
- 誰來測試什麼?
你可以跟離岸和在岸團隊成員一起討論。會議中或者會議後，要把流程記錄在紙面上。描述每個參與者的職責，說清每個細節。最後，要形成一個穩定的框架，可以爲每個人、團隊、公司提供反饋，互相評價。
現在，你也許在想：“太棒了！我們已經搞定了這些東西，討論了很久，也都寫下來了，最後就把它們放在（虛擬的）抽屜裏。沒人會再去看它們，我們還是會馬上動手幹活。”沒錯，也許你會這麼做，因爲這是自然而然的趨勢。
然而，動腦子的團隊就會想：“如何在真正開始開發之間展開協作”。這會建立起人們之間的聯繫，而且可以創建更有效的工作方式。現在，你要負責不讓這些文檔躺在抽屜裏，在你的定期會議中使用它們，隨進度更新它們，讓它們成爲有生命的計劃和實踐！
關於作者
Hugo Messer從2005年開始，就在世界各地建立和管理團隊。推動位於不同文化、地域、時區的人們一起協作，是他的激情所在。無論是離岸還是近岸，他知道如何達成全球化的協作。如果希望更多瞭解
Hugo，請訪問他的網站，也可以閱讀他的博客，或是觀看 Youtube 上有關他的視頻。