打造高效團隊：談技術團隊進入專案的時機

我前陣子在 Linkedin 上看到一篇有趣的推文，表現軟體開發時，從企劃階段到實際成品的巨大落差。看圖請從此去。

這不禁讓我想起客戶常有的疑問：「該何時讓開發（或其他專業技能）團隊進入專案呢？」

定義市場需求時？
討論如何開規格時？
完成系統分析文件時？
介面設計完成時？

這題沒有標準答案，因為背後真正的重點是「如何解決跨部門、跨階段的溝通落差」。

若純粹看分工，開發團隊在開始實作時參與就可以。畢竟開發團隊手上有其他工作，一般都希望工程師不要花太多時間在還沒要開發的工作上，輪到自己投球時再進場。且那時候規格完整，工程師也有東西可以評估。

但最後才讓團隊進場，就非常考驗溝通：既要言簡意賅，更需毫無遺漏。

一個軟體產品從發想到產出規格需求時，會進行大量需求研究，收攏為「結論」，產品「該解決什麼問題」也會從結論中誕生。企劃者梳理出規格並把規劃交給開發團隊時通常是中後期，這時若開發團隊一看就發現實作會有問題，能調整的彈性也有限。往往會變成「先做再說」，也為後續改善擴增埋下隱憂。

風險還不止於此。如果沒有為工程師留足夠的技術評估時間，又或者開發團隊太晚加入專案，會有什麼風險呢？

難以一開始就做對事

產品如何替客戶（此指產品用戶）解決問題，不僅在規格設計時要考慮，工程師開發時也必須思考。就算是在 MVP 階段，也必須考慮未來擴增時的需求。我們曾見某位外國新創客戶，經營的是 SaaS 產品，用戶數當然越多越好。但最初設計時沒有保留擴增彈性，雖然產品成績很好，系統則瀕臨爆炸上限。之後我們花了數月的時間逐步翻新系統設計，才為客戶建構好符合他商業模式的結構。

問題最後依然能解決，但 MVP 階段所投入的成本，就浪費了。

無法為解決問題提出建言

常見立意良好的設計，會增加實作端複雜度甚或降低體驗效能。著重在「Nice to have」的設計容易在早期階段就佔用過多資源，讓營運團隊難以用效率最高的方式驅策產品發展。例如為追求更好的 UI ，過度設計或追求酷炫，讓視覺效果的開發工時堪比核心功能所需工時，也是一種資源浪費。

有些朋友看到這裡，應該會反批：「你如何能定義這是 Over Design（過度設計）？我們是基於嚴謹的研究上才做出合理設計。」

是的，沒錯。不過這就是問題所在。

工程師確實很難知道何謂「Over design」或是「Poor design」，因為背景資料不夠。最後才加入，讓開發團隊能判斷的依據只有文件規格，遑論提出建言，判斷「如果要展現產品價值並驗證商業模式，現在做這件事是否為開發資源的最好配置。

Launch 新產品時，如果有任一方無法獲得足夠的背景資訊，就沒辦法做出適切的判斷。尤有甚者，就實現了本文開頭所分享的圖，是所有產品領導人不樂見的。
早期介入，問題都能早期解決。

如果想要避免上述風險，又不想佔用團隊太多時間，應該怎麼辦呢？以下建議幾個方式。

前置作業就共享結論

當產品進入一個新階段，例如市調完進入規格發想，就可以將目前進度和全體分享一次。分享時是重點式的，不超過五頁 A4：

- 契機
- 假設
- 驗證結果
- 洞察（Insight）
- 判斷
- 下一步
- 其他：例如時程。

讓團隊都有心理準備，產品真正價值是什麼。

實作時定期同步

進入執行後要定期同步工作進度。尤其設計師在設計畫面時，工程師也開始做準備：套件研究、架構設計等，以實現設計師的規劃。因此同步時最好搭配摘要式的背景交代，確保雙方認知一致。

雖然工程師實際開發時仍會提問，不過定期同步能夠節省工程師拿到素材後的消化時間，更可以早期獲得技術面的建言，免去後續走錯路補救的工夫。

產品反饋是全團隊的事

讓全體團隊理解產品進入市場後的成績，是所有成員的義務，也是權力。不論事前考慮多周延，人不是完美的，下決定時免不了犯錯。把錯誤與成功都共享給團隊，將能激勵團隊不重蹈覆徹，不斷優化決策思維。

當產品團隊領袖有意識的運用「過度溝通」，就可以打造出更有效率的工作節奏，也能夠逐步消除分工團隊之間的齟齬，創造更有黏性、更高 Motivation 的團隊。