APP誕生全紀錄 - 遠距團隊的溝通

2022/08/09閱讀時間約 6 分鐘

「聖經種子」團隊當初在組成的時候，成員本就是散落在各地，因著我的邀請而聚集在一起。因為大家都在不同的城市，平日也有自己的工作，所以對於我們來說，該如何讓團隊中溝通討論順暢、設計協作合作順利、凝聚出向心力，就成了最大的課題。

Duy Pham on Unsplash

如果你還沒看過「APP誕生全紀錄」，建議先去瀏覽一下唷！本篇內容主要會以我們開發的APP專案「聖經種子」來做案例介紹，告訴你關於我們的經驗。

專案空間

首先我們需要一個共同的空間來存放專案內容，以及工作項目進度紀錄規劃，額外訴求是免費，因為我們是沒有收入的小型Side Project團隊 (笑)。

網路上常見的Trello、Slack一開始都有嘗試用過，但並不是非常貼近我們的需求。原因在於Trello主要用於工作項目規劃、分配和進度控制，但畢竟我們是小型團隊，每個人的任務量其實都蠻大的，而且有互相偶合，這時候如果使用任務型分配追蹤，如果切很細會累死，花太多時間在處理項目進度，項目過大又看不出進度，而且我們還有一個主要的需求是存放專案內容，這點在Trello上就不太吃香；而Slack比較注重在團隊溝通上，也不是我們主要的訴求，畢竟不是主要工作，每個人上線處理的時間都不一樣，所以也被排除在我們的考量之外。

最後我們使用BaseCamp來作為我們的專案空間，一來可以存放我們專案需要的檔案和文件，也可以簡易的條列和分類出我們的待處理事項，而且它的免費方案是20個使用者、3個專案、1G的儲存空間，已經可以滿足我們的需求。

協作方式

我們UI / UX的成員主要是用AI和Sketch來做設計，如果今天是只有一位設計師，我建議可以使用Sketch + Zeplin，但如果有兩位以上的設計師，可以使用Figma來做協作設計。不管是Zeplin或是Figma都是可以讓UI和程式設計師之間溝通的媒介，能夠很清楚的讓程式設計師了解UI設計師的設計內容。

Zeplin介面

程式設計的部分當然就是使用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 多頭馬車

一個團隊中到底該一人主導整個專案還是彼此均權呢？這是個很複雜的問題，並沒有一個標準答案，但團隊的目標必須一致。一個人能力很強的話，主導專案會效率很快，但一個人容易疲累，如果做錯決策或是造成成員的不愉快，也很容易讓團隊蒙上層陰影或解散；假使所有人均權，又容易造成效率低落，或是造成沒有辦法決定方向的情形發生，且如果大家意見不合，也還是會鬧得不愉快。所以我個人認為最好的方式是要有一個頭，但這個頭也要能夠察言觀色，廣納建言，該決斷的時候要做出決策；而且最好要有個副手，在第一個人有事或出問題的時候，第二個人能夠很好的補上並繼續帶領團隊前進，直到原負責人回歸。至於這些角色訂為該如何產生，可以看團隊一路執行下來的默契和個人特質能力，有領導力的人很容易看得出來，自然也會在適當的時機點站出來。

在「聖經種子」這個團隊中，因為我是主召集人，所以很自然的就扮演了頭的角色，在一路的過程中，每個人的角色定位就慢慢的成型。遇到意見分歧的時候，會先看大家討論的意見，大部分會採多數決，有時候我的立場比較堅定時，會請大家先回去思考看看，下一週末再來商量。通常過了一週之後，結果就明朗了，雖然也是有我強制決斷的時候，但基本上屈指可數。

團隊的目標必須一致