管理 Side Project 設計團隊，如何讓成員能夠有學習也有產出
這是一篇近期管理 Productlife 團隊的心得。Productlife 的前身是 C-Camp，而 C-Camp 是 UX/UI 新手村希望能夠透過共創工作坊，幫助大家累積實作上線產品的經驗，總共有研究場與設計場各 4~6 週。而 Productlife 正是在設計場之後產出的設計概念，並交由目前固定的產品團隊進行設計與開發。
目前我們的團隊組成是 PM 一位（我）、Design Lead 2 位、Dev Lead 1 位，設計師 4 位，後端 2 位，App 前端 1 位。
從 C-Camp 到 Productlife 過程中，我一開始依照之前實習和工作坊的一些經驗規劃工作流程與節奏，卻遇到一些挑戰，因此了解到一般工作的團隊與 Side Project 的團隊差異，進而慢慢調整成目前的團隊協作模式。
如果你喜歡我的文章，可以按下面的拍手！用推薦 ID【daniellee2309】免費註冊 LikeCoin 並在帳號設定中驗證手機號碼，我就能因為你的鼓勵獲得一些收入
取得「彈性發揮」與「精準規格」的平衡
在工作坊期間，我首先依據規劃的功能，產出細節的功能規格以描述使用者故事與互動方式，也給了幾個概念式的 Wireframe，但並未針對 UI 進行設計。對於大部分處於職場新人階段的工作坊成員，這造成了雙面刃：
- 優點：讓成員學會分析規格，進而專注在產生對應的資訊架構與 UI 設計
- 缺點：成員被 Wireframe 限制，難以跳脫既定印象，成為只是產出視覺的工具
因此在工作坊結束後，我決定調整指派設計任務的方式：
- 一樣給定明確目標，包含產品目標與設計目標，讓設計師知道如何評估他們最終的設計
- 調整規格顆粒度：只給一定要有的規格，其餘全部不講讓設計師有更大的發揮空間
- 提前 Review：我們每兩週一次 Sprint Review 和 Planning，但不把所有該 Review 的東西丟到 Sprint Review 才討論，而是在此之前就必需完成 Design Lead 或是 PM 的 Review。Sprint Review 的目的除了讓各個設計師 Sync，也是讓其他彼此的回饋能透過一個正式場合表達出來，在正式進到開發之前還有一個微調的緩衝。
放棄所有「可以做」的需求，集中資源做好「最」有影響力的事情
一切都是假的，只有產品上線才是真的。在與開發團隊討論過後，我們評估在年中只能開發出一項最核心的機制。
我回頭與設計團隊多次討論了我們該怎麼在最精簡的產品規模下提供最核心的體驗，然而設計團隊的想法擅長發散卻難以收斂。當時我們已經設計了社群討論以及協助分享者增加影響力的功能，但最後一一被我刪減，設為 Pending。
Productlife 的願景是「讓每個產品知識學習者能因找到共同學習的夥伴而成長」，希望打造社交優先的學習體驗。當我回過頭來檢視我們核心的目標，就發現一對一的配對就可以實現最精簡的社交功能，但還是能保有透過社交來學習的體驗。所以我們接下來只專注把一對一的配對體驗做到最好，別的需求和功能可以稍微想想，但暫時都不會進行設計。
了解成員成長目標，將成長也視為團隊任務
設計團隊的成員目前即將交付最終版的設計給開發，在此之前我曾經把死線壓在 3 月就應該要交付，為什麼會拖到 4 月了才終於要結束？
我了解到這次混亂的根因是我忽略了團隊成員也要有學習的時間。一味的讓設計師趕上該交付給開發的進度，會讓這些還需要一些反思才能更穩定的設計師變得節奏混亂。在問題解決後我透過這個契機，與所有人進行了 1 on 1 面談，並在 1 on 1 的過程中了解大家各自期望的成長路徑。
我最後做了一個任務指派上的調整，就是把「學習」也變成任務，這樣在規劃工作時，就不會排擠掉成長的時間，同時團隊投入在學習計畫的資源也比較容易掌控。
現在我們有兩個學習任務：
- 了解 UI 設計該注意的所有眉眉角角
- 了解如何以數據輔助設計
這些學習任務的內容規劃將會由成員主動提出，而我則會負責思考可以運用的資源有哪些，最終再討論出可行的計畫並實踐。
賦權團隊，讓成員從負責到當責
在設計團隊中，每個人都負責一個設計，最基本的效益，就是彼此可以看見產出的細節有哪些差異，進而向團隊成員學習。然而在我眼中讓他們負責是一回事，讓他們感受到自己有責任，並且願意為此產出超出期望的結果又是另一回事，在 1 on 1 的過程中，成員提及了這種狀態就是有 Ownership。
至於要怎麼知道成員有感受到 Ownership，總結有兩個層面可以展現這件事：
- 個人：獨立負責一個設計，在各方面都能仔細地考慮並在限制下交付符合或超出期望的成果
- 團隊：會主動溝通來彌補規則缺口，甚至主動推動該被重視但未被推動的任務
無論是個人或是團隊層面，成員們都已經展現部分特質，而我都還在努力讓兩點都能 100% 達成，期許未來能打造出一個有良好組織文化的產品團隊。
結論
以上就是在帶設計團隊時所總結的四點心得，我個人認為大部分應該是跨團隊通用的準則。近期開發團隊剛開始成形，而未來也有可能會組建使用者研究團隊，如果未來有任何新的學習，會再找機會與大家分享！
iOS App Developer 招募中
目前我們團隊正在招募 iOS App 開發人員，我們目前使用 Flutter 作為開發語言，後端使用 Go。如果你有意透過這個 Side Project 實作上線產品，累積一些經驗並創造社會影響力，歡迎私訊我與我聊聊加入團隊的可能性！
如果你喜歡我的文章，可以按下面的拍手！用推薦 ID【daniellee2309】免費註冊 LikeCoin 並在帳號設定中驗證手機號碼，我就能因為你的鼓勵獲得一些收入
