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

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

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

兩位都是從競爭激烈的游戲產(chǎn)業(yè)出身（他們之前在植物大戰(zhàn)僵尸的公司工作），各自都有將近十年的實戰(zhàn)經(jīng)驗，也曾經(jīng)管理過工程團隊，所以對于產(chǎn)品開發(fā)的理解比我們公司所有人都更熟悉。

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

導入產(chǎn)品開發(fā)流程

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

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

Daily Stand Up 每日站立會議

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

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

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

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

Sprint planning 沖刺規(guī)劃會議

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

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

Retrospective 回顧會議

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

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

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

2. 做得好的部分

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

3. 有待加強的部分

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

4. 解決方案的行動項目

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

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

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

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

迅速迭代

最后一項并不是實際方式，而是一種心態(tài)，跟設計工作室以往風格不相符的心態(tài)。

再一次，因為工作室的接案本質(zhì)，最終成品往往是送出去之后就沒有機會修改了，而送出去的成品代表著我們工作室的聲譽，如果交出的質(zhì)量不夠好，客戶就不會回購了，導致我們很多時候?qū)ψ罱K設計過于小心翼翼。

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

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

開發(fā)產(chǎn)品時就不能總是將完美當作目標，而是要以學習、改變?yōu)樽罡吣繕?，不畏失敗，先推出才有真實的?shù)據(jù)跟回饋得以學習。

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

友善的工程師

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

1. 溝通、溝通、溝通

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

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

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

2. 合作彈性

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

結(jié)語

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

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