漫談團隊成員經驗之於成本
在不同團隊合作環境工作多年下來，經歷許多不同狀況，在這邊分享對於團隊運作的想法。以軟體開發團隊為例，理想的開發流程如下：
理想與現實
理想上最有效率的方式是單向，也相對較接近傳統瀑布式 (Waterfall)，我將之比喻做專制。好處是若上游 (皆) 是有經驗、有遠見、對趨勢及市場極度敏感之人，那效率會無比之高，成效無比卓越；壞處是這個前提風險大，像是賭博，而普羅大眾相信多人意見能帶來較為完善的考量，進而作出較為「正確」的決定。
實際上，這種完美是不存在的，端看過往強大王朝，皇帝們也都會有各種回饋系統以及考察系統，即便現代的專權政治體系亦是如此，而這些即已是雙向。
所以現實中箭頭是雙向，也是近代大家無論各種原因偏好的運作模式。既然是雙向的，代表溝通成本的上升，無效溝通或不夠有效率都會導致多次的來回和其他成本的提升。
實例
以網站前端開發為例，理想中，設計師出圖細節明確清楚，開發可以完全一版一眼地照刻，但現實中，因為時間限制、效果呈現方式及工具限制、經驗、思維等等因素，往往設計無法重現或顧及所有細節，導致設計成為參考或是工程師開發時需要再次和設計師確認或建議，或需要再次調整。
也許上述過於模糊，這邊再舉個例子：Responsive 頁面開發。若在三種不同螢幕尺寸有些微不同的設計，理想情況是設計師針對三種螢幕尺寸出至少三種版本設計，清楚展示期望的效果。現實中，設計師可能因為時間關係，只出了一版設計，這時來回溝通的時間成本就會變高，做出效果和預期有落差的風險也會提高，再者問題調整的各種成本也會飆升。
若上述例子還是過於複雜，這裡來個極簡例子：網頁開發中，若一個文字區塊文字長度不定，理想中設計會出一行和多行的設計，或是整體網站體驗一致，在元件指南 (Guideline) 中說明清楚最大寬度的定義以及多行時的效果、是否將其他內容往下推等；現實中，可能因為內容未知或其他原因，而只出了一行的設計，沒有其他說明，這時工程師在開發時就會需要另外確認是否會有多行以及多行時的效果，甚或以為內容只有可能一行導致後續需要再做調整。
以上例子遵照做實驗，一個操作變因其餘為控制變因原則，團隊中以設計部分做唯一變化，專案管理人員以及工程師維持原樣。現實中，是各個環節和理想的落差，導致更多的來回以及各種成本。
經驗的重要性
由於時間、資源有限，如何有效溝通就很仰賴經驗， 經驗可以達到的是實作的合理性以及降低溝通成本，合理的實作變相也可以幫助溝通，減少來回的必要性。在這裡不講最佳實作而是合理的實作，因為各種資源的限制，如何取捨、拿捏平衡點在有限的資源下達成共同目標、製造多贏才是最重要的。
實作合理性指的是不同角色的主要專業及職責，對產品 / 專案經理 (Product / Project Manager) 是需考量因素的全面性、推動產品 / 專案方式、時程大方向評估的合理性以及因應情況所需之文件詳細度等，對設計師是設計需考量因素的全面性、因應不同目的產出設計的完整性以及延展性等，而對工程師來說，則是技術開發時需考量因素的全面性、開發方式的選擇、保留彈性的方式。
而溝通成本則涵蓋許多，有不同角色間的溝通，像是對於考量因素的疑慮、實作上的方式以及可達成的成效差異，若能運用經驗考量對方角色顧慮的點而提出適當的建議、或是運用對方角色的語言來溝通，都能極大地減少來回；也有同等角色間的溝通，像是設計師與設計師之間的和工程師與工程師之間的，技術和方法上的討論以及流程的簡化等。
綜合以上，成員的經驗是團隊的重要資產之一。
我認為請有經驗的人是一種方式，但不一定是必需，一切看情況。所以如果想省成本省在請有經驗的員工，只要覺察因而提升的其他後續成本，納入考量後可以承擔或有相對應措施，就去吧。
當然，要降低成本還有很多種方式，有模組化後大量代工、心理戰、人力壓榨、利益交換等等，在這邊就先不討論。
上述以軟體產品團隊為例，概念上替換為其他種類團隊也適用。
