專案管理｜01.打造高效團隊：談技術團隊進入專案的時機
更新於 發佈於 閱讀時間約 4 分鐘
※此文同步刊載在本人所任職的五倍紅寶石軟體開發公司。
我前陣子在 Linkedin 上看到一篇有趣的推文，表現軟體開發時，從企劃階段到實際成品的巨大落差。看圖請從此去。
這不禁讓我想起客戶常有的疑問：「該何時讓開發（或其他專業技能）團隊進入專案呢？」
定義市場需求時？
討論如何開規格時？
完成系統分析文件時？
介面設計完成時？
討論如何開規格時？
完成系統分析文件時？
介面設計完成時？
這題沒有標準答案，因為背後真正的重點是「如何解決跨部門、跨階段的溝通落差」。
若純粹看分工，開發團隊在開始實作時參與就可以。畢竟開發團隊手上有其他工作，一般都希望工程師不要花太多時間在還沒要開發的工作上，輪到自己投球時再進場。且那時候規格完整，工程師也有東西可以評估。
但最後才讓團隊進場，就非常考驗溝通：既要言簡意賅，更需毫無遺漏。
一個軟體產品從發想到產出規格需求時，會進行大量需求研究，收攏為「結論」，產品「該解決什麼問題」也會從結論中誕生。企劃者梳理出規格並把規劃交給開發團隊時通常是中後期，這時若開發團隊一看就發現實作會有問題，能調整的彈性也有限。往往會變成「先做再說」，也為後續改善擴增埋下隱憂。
風險還不止於此。如果沒有為工程師留足夠的技術評估時間，又或者開發團隊太晚加入專案，會有什麼風險呢？
難以一開始就做對事
產品如何替客戶（此指產品用戶）解決問題，不僅在規格設計時要考慮，工程師開發時也必須思考。就算是在 MVP 階段，也必須考慮未來擴增時的需求。我們曾見某位外國新創客戶，經營的是 SaaS 產品，用戶數當然越多越好。但最初設計時沒有保留擴增彈性，雖然產品成績很好，系統則瀕臨爆炸上限。之後我們花了數月的時間逐步翻新系統設計，才為客戶建構好符合他商業模式的結構。
問題最後依然能解決，但 MVP 階段所投入的成本，就浪費了。
無法為解決問題提出建言
常見立意良好的設計，會增加實作端複雜度甚或降低體驗效能。著重在「Nice to have」的設計容易在早期階段就佔用過多資源，讓營運團隊難以用效率最高的方式驅策產品發展。例如為追求更好的 UI ，過度設計或追求酷炫，讓視覺效果的開發工時堪比核心功能所需工時，也是一種資源浪費。
有些朋友看到這裡，應該會反批：「你如何能定義這是 Over Design（過度設計）？我們是基於嚴謹的研究上才做出合理設計。」
是的，沒錯。不過這就是問題所在。
工程師確實很難知道何謂「Over design」或是「Poor design」，因為背景資料不夠。最後才加入，讓開發團隊能判斷的依據只有文件規格，遑論提出建言，判斷「如果要展現產品價值並驗證商業模式，現在做這件事是否為開發資源的最好配置。
Launch 新產品時，如果有任一方無法獲得足夠的背景資訊，就沒辦法做出適切的判斷。尤有甚者，就實現了本文開頭所分享的圖，是所有產品領導人不樂見的。
早期介入，問題都能早期解決。
早期介入，問題都能早期解決。
如果想要避免上述風險，又不想佔用團隊太多時間，應該怎麼辦呢？以下建議幾個方式。
前置作業就共享結論
當產品進入一個新階段，例如市調完進入規格發想，就可以將目前進度和全體分享一次。分享時是重點式的，不超過五頁 A4：
- 契機
- 假設
- 驗證結果
- 洞察（Insight）
- 判斷
- 下一步
- 其他：例如時程。
- 假設
- 驗證結果
- 洞察（Insight）
- 判斷
- 下一步
- 其他：例如時程。
讓團隊都有心理準備，產品真正價值是什麼。
實作時定期同步
進入執行後要定期同步工作進度。尤其設計師在設計畫面時，工程師也開始做準備：套件研究、架構設計等，以實現設計師的規劃。因此同步時最好搭配摘要式的背景交代，確保雙方認知一致。
雖然工程師實際開發時仍會提問，不過定期同步能夠節省工程師拿到素材後的消化時間，更可以早期獲得技術面的建言，免去後續走錯路補救的工夫。
產品反饋是全團隊的事
讓全體團隊理解產品進入市場後的成績，是所有成員的義務，也是權力。不論事前考慮多周延，人不是完美的，下決定時免不了犯錯。把錯誤與成功都共享給團隊，將能激勵團隊不重蹈覆徹，不斷優化決策思維。
當產品團隊領袖有意識的運用「過度溝通」，就可以打造出更有效率的工作節奏，也能夠逐步消除分工團隊之間的齟齬，創造更有黏性、更高 Motivation 的團隊。
為什麼會看到廣告
留言0
查看全部
你可能也想看
Google News 追蹤
現代社會跟以前不同了，人人都有一支手機，只要打開就可以獲得各種資訊。過去想要辦卡或是開戶就要跑一趟銀行，然而如今科技快速發展之下，金融App無聲無息地進到你生活中。但同樣的，每一家銀行都有自己的App時，我們又該如何選擇呢？(本文係由國泰世華銀行邀約)
今天我會用不同角度帶大家看這款國泰世華CUB
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
「所以，你想要用A框架，但又覺得B框架也不錯？」David挑眉問道，一臉的疑惑和一絲不易察覺的笑意。
....
David神秘地笑了笑，「技術選擇可不是簡單的喜好問題，它牽扯到技術轉移的成本、技術負債的累積，還有整個團隊的長期發展。先來聽聽我的想法吧。」
我們可能會有一種迷思，不管開發什麼系統，開發團隊都袛會有一種方式來工作。反正不管怎麼樣，系統最終也一定是能開發出來的。那麼選擇開發生命週期又跟我何干？本篇將會介紹專案經理應該如何為不同特性的專案選擇最合適的管理策略，即生命週期。
業務與研發之間的溝通是職場一大挑戰，常因認知差異產生誤解，影響工作氣氛與專案進度。
透過本文提出的三點提醒，設定對應方案來打破專業壁壘，就能建立起有效的跨部門合作關係。
產品開發的成功，除了品質，更在於是否能夠在適當的時程內推出並滿足客戶需求。
身為開發、設計人員，從文中提供的三個角度來思考，以確保產品與公司的競爭力。
在產品開發過程中，及早分享文檔初稿並從團隊成員那裡收集反饋是非常關鍵的。這樣做不僅可以在早期階段發現潛在的問題，而且還能讓團隊成員對文檔的發展有所貢獻，從而提高他們對最終產品的接受度。當文檔在創建過程中被共享，它成為了一個動態的工具，可以根據團隊的反饋進行調整和完善。
在設計有四年快五年的時間，大部分都是從實戰經驗中去不斷摸索產品開發的流程。從視覺傳達的背景出來，在用戶體驗的經驗都是在實際開發中去摸索出來的。不是理論派，只是根據我本人的經驗摸索出來的設計方法，也不會用太多高深的詞彙說明。
以前搜尋怎麼做產品設計？究竟是要從什麼步驟開始的這件事情，大部分看到的
這篇文章探討了在專案開發中遇到的時間壓力和執行困難，以及如何無效應對這些挑戰。 沒有工時估算、客戶溝通、交付時間表設定、程式品質管理、工作量管理、合同和專業態度等方面的建議。
追求乾淨的程式碼是好的開始，但不要陷入過度設計的陷阱，導致程式難以維護。實際上，考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況，適時調整工作重心。技術不斷進步，使得寫程式變得更加容易，但這並不意味著工程師的角色會消失。在選擇技術時，也要考慮隱形成本有時簡單的解決方案反而更有效。
現代社會跟以前不同了，人人都有一支手機，只要打開就可以獲得各種資訊。過去想要辦卡或是開戶就要跑一趟銀行，然而如今科技快速發展之下，金融App無聲無息地進到你生活中。但同樣的，每一家銀行都有自己的App時，我們又該如何選擇呢？(本文係由國泰世華銀行邀約)
今天我會用不同角度帶大家看這款國泰世華CUB
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
「所以，你想要用A框架，但又覺得B框架也不錯？」David挑眉問道，一臉的疑惑和一絲不易察覺的笑意。
....
David神秘地笑了笑，「技術選擇可不是簡單的喜好問題，它牽扯到技術轉移的成本、技術負債的累積，還有整個團隊的長期發展。先來聽聽我的想法吧。」
我們可能會有一種迷思，不管開發什麼系統，開發團隊都袛會有一種方式來工作。反正不管怎麼樣，系統最終也一定是能開發出來的。那麼選擇開發生命週期又跟我何干？本篇將會介紹專案經理應該如何為不同特性的專案選擇最合適的管理策略，即生命週期。
業務與研發之間的溝通是職場一大挑戰，常因認知差異產生誤解，影響工作氣氛與專案進度。
透過本文提出的三點提醒，設定對應方案來打破專業壁壘，就能建立起有效的跨部門合作關係。
產品開發的成功，除了品質，更在於是否能夠在適當的時程內推出並滿足客戶需求。
身為開發、設計人員，從文中提供的三個角度來思考，以確保產品與公司的競爭力。
在產品開發過程中，及早分享文檔初稿並從團隊成員那裡收集反饋是非常關鍵的。這樣做不僅可以在早期階段發現潛在的問題，而且還能讓團隊成員對文檔的發展有所貢獻，從而提高他們對最終產品的接受度。當文檔在創建過程中被共享，它成為了一個動態的工具，可以根據團隊的反饋進行調整和完善。
在設計有四年快五年的時間，大部分都是從實戰經驗中去不斷摸索產品開發的流程。從視覺傳達的背景出來，在用戶體驗的經驗都是在實際開發中去摸索出來的。不是理論派，只是根據我本人的經驗摸索出來的設計方法，也不會用太多高深的詞彙說明。
以前搜尋怎麼做產品設計？究竟是要從什麼步驟開始的這件事情，大部分看到的
這篇文章探討了在專案開發中遇到的時間壓力和執行困難，以及如何無效應對這些挑戰。 沒有工時估算、客戶溝通、交付時間表設定、程式品質管理、工作量管理、合同和專業態度等方面的建議。
追求乾淨的程式碼是好的開始，但不要陷入過度設計的陷阱，導致程式難以維護。實際上，考慮團隊狀況和專注於解決真正的問題更為重要。了解公司的規模和現實情況，適時調整工作重心。技術不斷進步，使得寫程式變得更加容易，但這並不意味著工程師的角色會消失。在選擇技術時，也要考慮隱形成本有時簡單的解決方案反而更有效。