對目前多數以技術背景為創辦人的新創團隊來說，要找到對的設計師真的非常困難;相對的，對多數不了解技術的設計師來說，要開心的與新創團隊的共事，也不是一件簡單的事。

不過我覺得對設計師來說，加入新創團隊是美好的，因為新創團隊的靈巧、活力與氣氛是多數大公司無法營造的，然而設計師必須多思考如何融入目前以敏捷開發為主要開發流程的環境。

敏捷式開發(AgileDevelopment)對新創的開發人員來說，是個非常熟悉的名詞，但設計系的教授從來沒有教過什么是敏捷開發啊!我在學習敏捷開發的過程中，也吃足了苦頭，總是覺得時間不夠用(太敏捷了!)，后來漸漸地抓到敏捷開發的步調，在此整理出幾個原則跟大家分享：

1 與團隊達成良好、敏捷的溝通

良好、有效率的溝通，可以讓往后的設計工作事半功倍，在一個開發團隊里，除了設計師以外，不外乎兩個角色–開發人員與項目管理員。所以我們設計師只要想好怎么跟RD 與 PM 保持良好的溝通及互動就好了，簡單吧!

與 PM 打交道的最大原則：

1. 確實了解每一項設計的需求，并且在約定的時間內達成。

2. 隨時保持解決急件的彈性空間。

每天上午的 Daily Scrum 以及使用 Trello溝通工作進度是一個很好的方法，這讓我們在每一天剛開始工作時，就能夠同步所有的信息，讓接下來的一整個下午能夠有完整的工作時間以及正確的工作方向，并且讓 PO(Product Owner) 清楚掌握設計師的工作負荷量，有助于 PO 判斷每件任務的輕重緩急。

與 RD 打交道的最大原則：

1. 明確交待設計稿上的細節，但保有彈性空間。

2. 適度了解 RD 的開發方式，藉以調整設計達到最高工作效率。

前一陣子非常夯的一張圖”Bad designer, Average Designer, Gooddesigner"，我看了是沒什么感覺，但是后來有人加了 “Good designer for Developer" 之后，我就有很大的共鳴，因為其實 RD們每天要煩惱的，就是解不完的 BUG，如果能夠減少 RD 調整layout 的時間，相對研發的時間就會提升，產品整體的穩定性、效能以及體驗一定會更好。

當然我并不是提倡簡陋的 Layout，而是以敏捷開發的角度來看，提前產品上線的時間遠比完美的視覺感受更重要。

整體來說，其實與RD 溝通的時間并不會比做設計的時間少，因此我剛加入團隊時，便花了很多時間與 RD討論有效的工作流程，并隨時檢討其中的細節。以切圖來舉例，我們試了很多方式，從最初的手寫筆記到電子文件，最后呢，我們甚至找出了一個不用切圖標坐標的解決方法，大大縮短了彼此的工作時間。回頭來看，這溝通的過程真的是非常值得!現在，我們彼此都有更多的時間做設計與研發了。

2 讓產品活下去比自己的作品集重要

很多設計師在做接口設計的時候往往將視覺美感放在第一順位，這會使設計師在產品設計初期就花太多時間在斟酌顏色與字體的細節，但其實使用者并不是那么在意接口的美丑，產品的好用永遠比好看重要!

以臺灣大部份證券下單 app 與 Yahoo!股市為例，使用者在意的是那些瞬息萬變的股價波動，雖然 Yahoo股市的接口非常的漂亮，但是卻無法直接下單，我想使用者在面對這樣的情況，還是會選擇接口視覺風格還停留在 iOS6 時代，但卻可以立即下單的服務吧!

因此，在設計初期，設計師在意的應該是在每一次產品開發周期內，優先設計用戶的"使用"體驗，而不是"視覺"體驗，讓用戶清楚體驗到這個產品解決了什么問題，遠比讓用戶覺得你的產品很美來得重要。

3 了解產品與公司發展的方向

當你選擇加入以敏捷開發為主的新創團隊時，你的未來已與公司的命運密不可分，所以我們應跳出設計師的框框，以產品遠景與公司的角度來思考許多決策。因為只有敏捷地面對市場的反應，隨時調整前進的方向才是王道。我想這可以從近期許多視覺風格簡潔，但功能卻深深打中使用者痛處，進而獲得巨額投資的產品得到驗證。

國內敏捷軟件開發轉型熱潮方興末艾，敏捷組織里的角色和責任比起傳統組織已經完全不同，每個組織實施敏捷都是量身定制的，每個團隊執行敏捷也是因人而異，如何判斷一個團隊就是敏捷團隊呢?項目管理面臨的挑戰是什么?如何把握時代的脈搏，在住址變革中占領制高點，發揮最大價值?一天不學習恐怕就OUT了，這是一個持續學習，精益求精的時代，項目經理的領導在哪里?

一切答案盡在《項目經理在敏捷環境中如何轉型》研討會，報名地址：http://www.huodongxing.com/event/4378803066000?