從2015年1月份我們遠程協作團隊組成到現在,這8個月我們發布了4個web大版本和不計其數的小修改;iOS和Android分別發布了8個版本,從1.0到2.0,其中1.0用了2個月的時間(包含春節);2.0上線用了2個月的時間(包含從業務邏輯探討,到最後web, iOS & Android端全部上線)。中間小版本的迭代,基本是2-3周一次。

所有這些事情的完成,全部基於遠程協作。

經過這麼一段時間的嘗試,不能說多成功,但起碼有了不少經驗,踩過了不少坑,可以分享出來供大家參考。所有經驗適合於需要通過團隊協作來完成產品的各位。

坑一:沒找到正確的人,時間的浪費以月來計算

這也是最重要的問題。是我們一開始遇到的問題。現在看來,找人的時候,以下幾點都需要考慮到:

  • 有經驗是前提條件,對於你要實現的產品,他有過類似開發經驗,80%的開發需求他已經瞭然於心,不僅能夠實現想法,還能夠基於自己的經驗給出更優的建議;另外20%他也知道去向誰求助。
  • 很聰明,善於學習,是第二條。總有他沒有做過的部分,但沒關係,他會輕鬆告訴你,我去看下文檔就會了(目前我的親身體會,我們開發團隊童鞋們簡直就是神筆馬良,能想到,就能做到#_#)
  • 同時,他還要有時間有興趣,願意來做你的項目。

以上三點,缺一不可。

這樣的人肯定不便宜。是的,他們的正常薪水比平均水平高50%-100%。

那麼要不花少一點的錢,找個便宜點的新手?

那意味着你將承受更大的成本:需求往複修改的時間翻倍,開發的時間翻倍,測試之後再修改的時間翻倍,他走了之後別人因為讀不懂代碼而導致產品不得不全部推翻重來……我還是建議你不要做這個嘗試了,因為最後你會發現:成本並沒有降低,也許更高,因為他薪水雖然是高手的一半,但他的用時卻是高手的2倍;你還花了更長的時間讓整個團隊付出了更高的時間成本,得不償失。

從去年11月份開始,這樣的人我們花了3個月,才找到,1月底才組成我們自己的開發團隊,然後開發速度颼颼的就上來了。

在做客棧的遠程項目功能時,我們對所有申請簽約的開發者,都像8個月前為自己找開發團隊一樣仔細篩選,然後再加上匹配算法,確保需求方的項目發布后,我們可以用12個小時,就為你對接到過去我們用了3個月才找到的優秀開發者。

如果去年11月我們就有了客棧的遠程項目這個產品,我們的發展時間,可以再快3個月。

坑二:協作的順序沒安排好,將導致時間以周為單位被浪費

一個產品的簡單順序如下:

原型(一般需求明確的情況下,所有文檔一周左右)->設計(根據頁面而定,一般簡單的產品1-2周)->後端(根據功能需求而定,一般簡單的產品1-2周)->前端開發(2-4周)->測試->上線。

對於我而言,每個版本,從原型到最後上線,都是在一個完整的時間段裏面。作為創業小團隊的產品負責人,同時還是測試負責人,意味着只有當產品上線了,這個版本的活才幹完,然後才有精力開始計劃下一個版本。

但這恰恰是之前效率低下的原因之一!在我們早期某個版本,需求,原型被同時傳達給了設計和所有開發者。導致前端小夥伴足足等了一個多星期,才拿到可以開工的文檔。我們的上線時間也因此延誤了一周多。

實際上,當設計和前端交接完,你就應該請設計師開工準備下個版本的設計了。當然,這意味着你此時已經完成了下個版本的原型,準備好了和設計師探討下個版本他需要做什麼。

詳細來說,一個更高效的流程應該是這樣:

 產品開發協作流程

  • 當你的前端開始開發1.0版本的時候,你已經在準備1.1的需求和原型;
  • 當你的前後端在進行聯調的時候,1.1的設計已經開工;
  • 當1.0版本最終發布的時候,1.1的後端接口已經完成。

這樣,項目才會無縫運行下去,大家都能高效運轉。

坑三:以為日子到了?事情就發生了

遠程協作,意味着大家沒有面對面工作的機會,不會有這樣的瞬間:他抬起頭來,看到你,想起你這邊的任務Deadline快到了,於是快馬加鞭一氣呵成。

  • 設計師會等產品原型確定;
  • 後端會等產品邏輯,流程和文檔確定;
  • 前端會等靜態設計,產品交互,流程文檔,以及後端接口確定。

是的,每個環節都在等,而作為產品負責人的你,是拉動整個機器的引擎,是鏈條,是潤滑劑。你不能等。

人只受眼前事物的影響,這是必然的心理狀況。因此,作為遠程項目的負責人,你可以學習Scrum的方式:

  • 每天和你的遠程團隊開一場虛擬立會。每天主動去提醒他,項目進展如何?要完成項目,還需要什麼支持?什麼到位了,什麼沒有到位?
  • 每周有可交付任務,每周進行回顧總結,上周完成情況,本周計劃如何。

我們的周會總結

我看到過有項目,負責人在項目建組的時候和大家打了個招呼,問了項目執行時間,然後就不再過問。前面一周組內都非常安靜,沒有人主動發言,待到預定的第一個Milestone,不出所料,全面延誤。

坑四:以為對方隨時都等着和你互動?別忘了你們有時差

遠程協作的團隊,一般都有時差。

也許你在中國,他在美國,你睡覺時他正好上班;

也許你是全職,他是兼職,你下班了,他才開始上你的班。

即使你們都是全職,可你喜歡白天,他夜晚最有靈感,白天需要補眠。

這些問題都可能碰到,所以做Milestone的時候就要考慮到,所有需要溝通協作的節點,都要提前協商好時間。

我們的經驗小結

  • 高質量的人才是高效率完成項目的基礎,選對了人,就是節省了時間和金錢。
  • 根據項目流程提前做好人員安排,嚴格遵守原型-設計-後端-前端的順序,是多方協作的基礎。
  • 項目負責人要主動推動每個環節前進,而不是等待。
  • 提前協商好milestone和共同工作時間,能提升協作效率。

我相信遠程協作是未來的趨勢,也是遠程的堅定實踐者。國外已經有非常值得學習的對象,創造了Basecamp,Rails on Ruby的Basecamp公司(前37signal)是一個典範:他們的員工分佈在兩個大洲8個城市,他們同時享受着生活和工作的樂趣,他們不用等到退休以後才去做自己想做的事情。希望有一天,我們也能實現這樣的目標。

 

本文由程序員客棧產品經理 @蔣露 原創發佈於人人都是產品經理 ,未經許可,禁止轉載。