Remote 團隊如何作業? (Part I) 遠端工作者基本認知

遠端作業,對於許多人來說是一個夢想,也是一種願景,身為軟體開發者,歷經過了許多不同開發專案,不同開發流程之後,除了開會之餘的時間有時候會進入『辦公室煩躁期』,這時不禁自問,如果我手上的這台電腦,加上隨時可以連線的工作環境,自己真的還需要待在同一個開發環境中嗎?

也因為這樣的情境下,身為網路開發者,開始對於工作模式的認知產生的懷疑,從 2013 年開始就啟動了許多不同嘗試,也開始試著與不同團隊,公司,組織一起進行不同開發模式的實驗測試。

遠端開發經驗

遠端開發,對於一個沒有太多經驗的開發者來說,一開始的確是一種夢想,也是一種自我實踐的方式,可以自己決定要在哪裡工作,要在什麼時間開始進行開工,在什麼時候進行事情的處理,更重要的是

每個月都有定期入帳

回到實際面,我們每個月收到雇主的薪資,實際上還是要協助處理雇主的處理項目,還有進行項目的處理,更重要的是讓對方『實際感覺』到我們真的很認真的做事情,並且事情都是在進度上發展。

但是開發者本質,並不是一種這麼熱衷於溝通,回報的職業,在我們的平常訓練中大多是協助解決問題,對於問題本身進行邏輯思考,將概念實做於程式中,將程式產出或進行整合。

這段時期,很容易產生『認知偏誤』 ,不全然是認知問題,但是大部分實際遠端經驗,幾乎以不溝通或者溝通不良所導致的意見歧異。

在『遠端作業』環境中,如何打造一個順暢溝通管道,就是最初遇到的實際課題。

遠端謹守定律

在許多挫敗的遠端開發經驗中,甚至讓人幾乎放棄遠端作業的流程上,我們發現共同最大的問題在於認知不同,認知不同的點,小的部分從 code convention 開始,大範圍到實際產出定義多方定義不清,以表單驗證的實際開發經驗來說,當時對於開發只有半日的條件下,就先以 window.alert 最省事方式進行展現,確認範圍日後再進行修改。

最終需要規範的就是 Scrum 流程中的『DoD (Defination of done)』

清楚定義目標完成的準則

例如,應規範應完成項目,應交付事項,應提供的文件,訊息的及時反饋時間點,如果違反者將會有相對應的處置,或者對於團隊的影響,這並不是我們樂見的事情。

當然這也是對於自己的傷害,也是對於整個團隊的傷害。

成果非戰即敗

因為看不到對方,無法瞭解過程,無法掌握彼此的進度,遠端需要比在室內中善用更多溝通工具,更加多重的溝通流程來完成項目。

最終,所看到的就只有結果,只有成功交付,或者失敗收場,身為遠端開發者必須要是一個願意溝通,並主動溝通的角色,以不同角色思考的角色。

實體的環境中,我們可以很容易的溝通,當場景拉遠到無法隨時碰面,無法隨時接觸的網路遠端工作模式,將會有所不同當中的經驗,這當中的過程經歷許多次的失敗及轉換,這些並不是一蹴可及,需要時間累積,也需要許多產品經驗的累積。

如果你是一位年輕開發者,希望嘗試遠端,需要請對方先提供『交付日期』,『DoD』 定義,項目工作範圍,如果中間有任何問題,或者不清楚之處,盡快釐清。

如果你是一位資深開發者,希望嘗試遠端,除了上述項目之外,還需要多主動詢問程式的相依性,程式架構的前因後果,後續發展計畫,協助更完整定義『DoD』 中缺少的細節,將問題提早釐清,提早將可能性問題先提出討論。

最後感謝這些合作過的公司,團隊以及成員們大家的指點與包容。

希望各位同樣朝著遠端作業夢想的各位,持續努力,實際體驗遠端工作經驗,期待各位經驗分享,這是一個嶄新的工作模式,也是一個嶄新的生活形態。

建立出適合團隊的彈性的工作模式,彈性的開發流程,不變的是一流的品質產出。

CaesarChi

Web developer, focus on website fullstack, special JavaScript, and love sharing developing experience and communicate with developers. http://about.me/clonn