由於我這幾年都是就職於 design agency（設計工作室），我們並沒有很多 in-house （組織內）的工程師資源，唯一的前端工程師人在倫敦，我從來沒機會跟他合作。

因此，我一直以來對接的都是客戶端的工程團隊，將設計文件寄出去之後不一定有辦法實時回饋，如果不在檔案或信件中解釋清楚的話，對方有很大的機率會誤解，所以我交付檔案給工程師的時候都比較慎重、詳盡。

直到幾個月前，我們工作室為了孵育自家產品，招募了兩名工程師，一名後端工程師與一名偏向 UX Engineer 的工程師。

兩位都是從競爭激烈的遊戲產業出身（他們之前在植物大戰殭屍的公司工作），各自都有將近十年的實戰經驗，也曾經管理過工程團隊，所以對於產品開發的理解比我們公司所有人都更熟悉。

最近我也投入自家產品的開發，跟這兩位工程師和一位資深互動設計師組成四人項目小組，發現自己簡直愛翻跟工程師並肩合作了。

導入產品開發流程

由於設計工作室的性質，我們以往都是根據客戶的需求以及時限來推進項目，例如三個月的項目要花兩周完成產品策略、四周完成線框圖之類的決定都在項目一開始就非常清楚，所以我們雖然有設計迭代（從設計圖 A 轉變成設計圖 B），卻沒有很明確的產品功能迭代。

工程師將他們的產品開發流程導入到我們的 workflow 中，幾項簡單的例行事項就讓我們的 workflow 越來越流暢，也讓我學到許多產品開發的眉角。

Daily Stand Up 每日站立會議

工程師很堅持每天都要有十五分鐘到三十分鐘的 stand up meeting，讓每個人概略報告一下自己昨天做了什麼、今天打算做什麼。

站立，而不是坐着，強化了該會議打算簡短且避免浪費時間的想法。站立會議並不是一個解決問題的地方，而是讓一個團隊意識到現在的狀態。如果需要討論，適當部門可以安排另一個更長的會議。（摘自 MBA 智庫百科）

一開始我很疑惑為何需要如此堅持每一天都要開會，畢竟有時候設計卡關，可能連續幾天都在做一樣的事情，stand up 的時候反而會感到自己沒什麼能分享的。

後來發現每天 stand up 讓大家永遠有機會可以提出問題，或是分享遇到的困難，比較不會因為偶爾一次的大會而感到有問題太小不該問，或是有問題還等到下次開會的時候才問，那都可能已經太遲了，stand up 能夠幫助團隊迅速注意到癥結點。

Sprint planning 衝刺規劃會議

我們採用 sprint 的方式開發產品，利用 Asana 當作項目管理的工具。工程師提出一種理念是：在每個 sprint 開始時都重新建立一個 Asana board，目標是要在 sprint 結束時將所有卡片消掉，沒消掉的卡片就要在下一次 sprint planning 時決定是否延續此項任務，要不然就做好 documentation（文件紀錄）之後摒棄掉，絕對不存 backlog 在這個 board 裡頭。

另外，在創建任務卡片時也不會一開始就指定負責人，因為設計工作室的接案本質，每個設計師都有可能因為新進的項目而被抽出這個小組、轉移重心，所以最重要的策略就是要讓任務模塊化，卡片可以隨時交接，當我重新加入項目時可以將沒有人負責的任務撿起來做。

Retrospective 回顧會議

再來說說我最喜歡的項目 — 回顧會議（Retrospective，簡稱 Retro），在每次 sprint 結束后都會開一次，顧名思義是要回顧這個 sprint 的好與壞，藉此更加精進我們的流程，以下是我們 retro 的架構：

1. 回顧上次的行動項目（action item）

根據完成程度幫自己打分數，我們是用笑臉、木然臉跟哭臉當作評分

2. 做得好的部分

稱讚大會，將這次 sprint 裡頭運作良好的部分提出來。曾經出現過的讚賞是任務量計劃得剛剛好、工程師跟設計師溝通良好等；也會提到一些比較隨興有趣的，比如說倫敦的工程師當爸爸了、感恩節要到了。

3. 有待加強的部分

這大概是最重要的環節，只要專註於點出問題是什麼，避免直接跳到解決方案，以免時間浪費在試圖解決一個問題，卻沒有正視所有問題（這真的超級難，所以我們經常要口頭提醒彼此不要跳到結論）。

4. 解決方案的行動項目

將有待加強的部分全數列出之後，選定幾個來想出可能的解決辦法，產生的行動項目要指定給某一個人，避免三個和尚沒水喝的情況。

我很喜歡 retro，因為這跟個人的自我省思很像，每次反省都能讓我們更了解自己、找出問題與解法，進而讓流程越來越進步、順暢。

工作過程中如果感覺自己因為某些流程感到困擾的話，也不會因為跟實際的設計工作無關而一直悶在心裏，retro 時就可以一一點出。

工程師說從來沒人喜歡過 retro，一直說我真是奇怪的人，但除了我認真相信反省能讓團隊變得更好之外，我也認為 retro 做得好的話是個近似於 team building（團隊建立）的環節，讓團隊成員更了解彼此在乎的點。

迅速迭代

最後一項並不是實際方式，而是一種心態，跟設計工作室以往風格不相符的心態。

再一次，因為工作室的接案本質，最終成品往往是送出去之後就沒有機會修改了，而送出去的成品代表着我們工作室的聲譽，如果交出的質量不夠好，客戶就不會回購了，導致我們很多時候對最終設計過於小心翼翼。

一開始我們總是在很後期才跟工程師說設計需求，擔心他們會做許多白工，工程師後來反倒反映說趕快產出各式各樣的原型才比較好進行測試，讓我們親身感受一下我們畫出的流程真的使用起來是什麼感覺。

他們說，在開發產品初期做任何決策時，我們要捫心自問的第一個問題不是「這會成功嗎？」，而是「我們可以從中學到什麼嗎？」

開發產品時就不能總是將完美當作目標，而是要以學習、改變為最高目標，不畏失敗，先推出才有真實的數據跟回饋得以學習。

工程師總是鼓勵我們只要產出「夠好」的設計就可以了，我們永遠可以在下一次迭代導入真實的回饋，無論是來自於真實使用者或是團隊外部的回饋，來進行迭代，而不是單純用設計師的臆測與想象中的完美不斷自主迭代。

友善的工程師

雖然說比起視覺設計師，我自己在思想上本來就跟工程師比較接近，但這兩位工程師真的是非常友善，從來沒有讓我感覺到設計師與工程師之間常有的緊張關係。

1. 溝通、溝通、溝通

第一次跟 in-house 工程師合作，能夠進行各種現場交談就已經讓我覺得樂勝遠程合作，而且他們又特彆強調溝通的必要性，他們不斷灌輸我一個觀念就是「如果被卡住超過 15 分鐘，來找我們」「如果對工程限制有什麼疑慮，來找我們」「如果想講垃圾話，來找我們（欸）」

閱讀文章 >>

總之就是設計師有什麼新想法都盡量跟他們說，他們都很願意仔細聆聽設計師的想法，同時也會提出身為工程方的見解，比較偏 UX Engineer 的那位甚至會提供解法，畫出線框圖跟我們溝通。

同時，他們也很尊重設計師的看法，當他們在架構後端的時候，偶爾也會丟出一些問題說「這樣的數據處理方式，好處是 ooo，壞處是 xxx，我覺得這樣做比較符合用戶流程，設計師你們怎麼想？」尊重設計師專業，不會徑行做決定。

2. 合作彈性

對於設計迭代他們也完全接受，因為我們不走瀑布式開發，所以有時候設計師在畫圖的時候，工程師也同時在寫同一個頁面的 code，設計經常在變，導致他們時不時會需要這邊改改、那邊修修，他們完全 OK，我跟另一個設計師常常打趣地說我們完全被寵壞了。

閱讀文章 >>

結語

幾個月的合作下來，跟這兩位工程師在私底下也變成好朋友，很常跟他們在 Slack 私訊（額外發現：工程師真的很愛 meme 跟 gif），也偶爾會跟他們出去 happy hour 喝酒聊天，他們也一直說要教我怎麼寫 React（真是太看得起我了）。

最近深深感到能夠跟他們認識併合作真的是太幸運了，從他們身上能學到很多在設計師身上學不到的東西，覺得自己對產品圈的知識又多了一些。

未经-摩登3注册-摩登3测速官网-允许不得转载：摩登3注册-摩登3测速官网 » 無極五平台_身為產品設計師，我從工程師身上學到的產品開發心法