「
聖經種子」團隊當初在組成的時候,成員本就是散落在各地,因著我的邀請而聚集在一起。因為大家都在不同的城市,平日也有自己的工作,所以對於我們來說,該如何讓團隊中溝通討論順暢、設計協作合作順利、凝聚出向心力,就成了最大的課題。
如果你還沒看過「
APP誕生全紀錄」,建議先去瀏覽一下唷!本篇內容主要會以我們開發的APP專案「
聖經種子」來做案例介紹,告訴你關於我們的經驗。
專案空間
首先我們需要一個共同的空間來存放專案內容,以及工作項目進度紀錄規劃,額外訴求是免費,因為我們是沒有收入的小型Side Project團隊 (笑)。
網路上常見的
Trello、
Slack一開始都有嘗試用過,但並不是非常貼近我們的需求。原因在於Trello主要用於工作項目規劃、分配和進度控制,但畢竟我們是小型團隊,每個人的任務量其實都蠻大的,而且有互相偶合,這時候如果使用任務型分配追蹤,如果切很細會累死,花太多時間在處理項目進度,項目過大又看不出進度,而且我們還有一個主要的需求是存放專案內容,這點在Trello上就不太吃香;而Slack比較注重在團隊溝通上,也不是我們主要的訴求,畢竟不是主要工作,每個人上線處理的時間都不一樣,所以也被排除在我們的考量之外。
最後我們使用
BaseCamp來作為我們的專案空間,一來可以存放我們專案需要的檔案和文件,也可以簡易的條列和分類出我們的待處理事項,而且它的免費方案是20個使用者、3個專案、1G的儲存空間,已經可以滿足我們的需求。
協作方式
我們UI / UX的成員主要是用
AI和
Sketch來做設計,如果今天是只有一位設計師,我建議可以使用Sketch +
Zeplin,但如果有兩位以上的設計師,可以使用
Figma來做協作設計。不管是Zeplin或是Figma都是可以讓UI和程式設計師之間溝通的媒介,能夠很清楚的讓程式設計師了解UI設計師的設計內容。
程式設計的部分當然就是使用
Git +
Github來做版本管理啦,定期找時間Merge一下,但第三方套件版本最好統一由一個人來掌管控制,不然可能會天下大亂。
Flutter要控管pubspec.yaml和pubspec.lock
iOS要控管Podfile和Podfile.lock
Android要控管project和app的兩個build.gradle,以及AndroidManifest.xml
通訊軟體
我覺得對於技術型的會議有兩個功能是必需的:桌面分享 和 繪製 (注釋) ,如果更進階點的就是有遠端操控功能,額外訴求一樣是免費 (笑)。
首先桌面分享顧名思義就是會議報告者可以分享個人桌面 (有些程式可以到指定視窗),邊說明個人進度時可以邊操作畫面,讓其他聽眾都可以“看”到報告者要表達和展示的內容,視覺化的說明是不可少的,畢竟我們有UI/UX/程式設計各方人員要互相溝通呢!大部分的軟體都有支援。
再來是繪製 (注釋)這項功能就不是大眾的功能了,但對於技術型的團隊會議是重中之重,這個功能著重在聽眾可以“回應”,用畫面繪製來標註說明目標或是簡易流程架構說明。例如當UI設計者展示了一個畫面,當我想要調整其中一個按鈕的擺放位置時,我可以直接標示出期望位置;或是當流程不夠順暢,可以直接標示流程。更進階的方式就是可以直接操作報告者的電腦了,這在一些要對方輸入指令、程式碼或是特殊操作的時候可以派上用場。
比較了下列許多的會議軟體,最後我們選擇使用
POP這套軟體。
Winner:POP
優點:免費(目前)、介面簡潔、我們需要的功能都有
缺點:偶爾完全連不上(需重開機)
1. Zoom
優點:功能最完整、操作直覺
缺點:需付費、資安疑慮
2. Google Meet
優點:快速簡單
缺點:功能少、白板整合性不佳、缺少繪製功能
3. Microsoft Terms
缺點:功能介面複雜、沒有我們需要的功能
4. Webex
優點:介面乾淨直覺
缺點:需付費、缺少繪製功能
5. Free Conference Call
優點:有繪製註解功能、免費
缺點:網路連線不穩、操作不直覺(整合了VoIP)
〔補充〕近期也有個新的專注於協作會議的軟體SwitchBoard,也是個不在意視訊,更強調協作討論的會議軟體,有試用過的人可以分享看看唷!
定期會議
一個團隊一定要有定期的會議,一來是掌握和同步進度,二來可以避免設計走歪設置停損點,再來可以讓大家習慣這個步調,還可以增加凝聚向心力,最後可以將目標訂小點,讓每次會議都有個可以完成的目標,增加每一次的完成度和成就感。
我們的團隊是定每週五晚上作為開會時間,因為我們團隊的成員都還有正職的工作,定在週末前比較不會有心理壓力,也可以在會後確認好設計方向,方便週末空閒時間去實作。
在等人到齊前就是閒聊,放鬆大家的心情,進入會議後開始輪流報告一週進度和討論,再來看看是否有臨時動議要討論的,最後就是定下週的進度。這樣每一週大家都可以往前跨進一小步並獲得成就感,在管理上也可以確保大家的進度和設計方向的一致性。
當然平常也還是用Line群組來解決即時的訊息傳達或簡短討論,但群組內還是盡量讓閒聊多過於正式討論吧。
主導型 vs 多頭馬車
一個團隊中到底該一人主導整個專案還是彼此均權呢?這是個很複雜的問題,並沒有一個標準答案,但團隊的目標必須一致。一個人能力很強的話,主導專案會效率很快,但一個人容易疲累,如果做錯決策或是造成成員的不愉快,也很容易讓團隊蒙上層陰影或解散;假使所有人均權,又容易造成效率低落,或是造成沒有辦法決定方向的情形發生,且如果大家意見不合,也還是會鬧得不愉快。所以我個人認為最好的方式是要有一個頭,但這個頭也要能夠察言觀色,廣納建言,該決斷的時候要做出決策;而且最好要有個副手,在第一個人有事或出問題的時候,第二個人能夠很好的補上並繼續帶領團隊前進,直到原負責人回歸。至於這些角色訂為該如何產生,可以看團隊一路執行下來的默契和個人特質能力,有領導力的人很容易看得出來,自然也會在適當的時機點站出來。
在「聖經種子」這個團隊中,因為我是主召集人,所以很自然的就扮演了頭的角色,在一路的過程中,每個人的角色定位就慢慢的成型。遇到意見分歧的時候,會先看大家討論的意見,大部分會採多數決,有時候我的立場比較堅定時,會請大家先回去思考看看,下一週末再來商量。通常過了一週之後,結果就明朗了,雖然也是有我強制決斷的時候,但基本上屈指可數。
總結一下
心法 - 每週固定開會
- 主導者
- 目標一致
工具 - POP
- Figma
- GitHub
- Basecamp
以上是一個遠距團隊的經驗分享,一個優秀團隊的誕生、成長和磨合是相當不容易的,如果真的遇到了好的夥伴,記得好好珍惜!!