產品團隊工作秘籍：如何與設計師、產品經理、開發者一起工作？
原文的作者是 非死book 的產品設計總監 Julie Zhao，這個系列一共有三篇文章，分別是如何與設計師，產品經理和工程師合作，早在去年年中就發布在 Medium 上，最近再讀的時候就想翻譯一下，網上的譯版看了以后更加堅定了譯一個自己的版本的決心。老文新譯，希望對還沒有看過的小伙伴們有幫助。
如何與設計師一起工作
——給工程師和產品經理的秘籍
在很久以前，我曾經做過產品經理，之后也做過開發工程師，在過去的 7 年里，我從事設計的工作。每一天我都和擔任這些角色的人一起工作，而每一天，在產品開發中，我對這三種角色相互合作背后的責任，挑戰以及藝術都有新的體 會。對于那些想搞清楚設計這個奇幻世界的工程師和產品經理，這篇文章就是為你量身定制的。
用設計師的語言，停止談論軟件指標，一起來說說用戶，
通常，這兩者差得并不太多。比如，你也許要說的是設定一個目標，將注冊轉換率提高X%，用另一種方式來說則是，你想做的就是要掃清那些讓用戶注 冊變得復雜的障礙。但是你看，怎么說在這就很重要，“讓用戶注冊變得更簡單”與“優化注冊流程的轉化率”。一個說的是對于用戶的價值，而另一個則是傾向公 司需要怎么做才能獲得成功。設計師通常都是站在用戶的角度來思考和行動的。
其他的基于設計師語言的翻譯：
我們能增加按鈕的點擊率么？ => 如何讓用戶知道這個貼心的新功能并且知道它很易用？
我們不能讓這個改變影響了軟件評定的指標 => 我們需要確保這個改變不會讓用戶的使用變得更加困難。
讓我們提高產品傳播率=> 讓我們鼓勵那些喜歡這個功能的用戶分享給他們的朋友
譯者注：產品傳播率，原文用詞是“viral coefficient”，直譯是病毒性系數，為此我還專門找到一篇文章， 這個傳播率= 參與邀請的活躍用戶的平均邀請數x活躍用戶中有邀請他人的用戶比例x受邀用戶中實際加入的用戶比例，比如產品有 100 個活躍用戶，其中 50 個人有邀請別人，平均是邀請 3 個人，而其中只有 2 人加入，那個這個數值為 3 x1/2 x 2/3=1, 這個參數大于 1 則說明你的產品用戶數量會以指數增加，小于 1 則說明你需要通過一些市場手段來提高用戶數。
設計師都有各自的強項， 好鋼要用在刀刃上
每個設計師都不一樣，即便是“全明星”設計師，他們思考問題的方式也不盡相同。因為設計包羅萬象：
1. 視覺設計：排版，對比度，層次感，以及那句老話“這看上去怎么樣？”都屬于這個范疇。正確的吸引用戶的注意力了么？細節是經過精雕細琢的還是草率完事的？還有更重要的，這套視覺設計是否系統化？
2. 交互設計：用戶完成某個任務是否簡單清晰？導航系統足夠強大么？動畫對于用戶來說是否自然？
3. 產品設計：這個設計很好的解決問題了么？這個設計點有用么？是否有清晰的愿景？帶來價值與否？
有些設計師在視覺方面是個大牛卻在交互方面經驗缺乏，有些有著很好的產品策略卻在設計建模上偏弱。每個設計領域都有獨特的難題，選擇擁有正確職 業技能的設計師來解決就顯得尤為重要。你不能指望隨便換一個設計師就能得到同樣的設計輸出，通常一個好的設計，以上三方面都是需要考慮到的。如果團隊里只 有一個設計師，那么這個人最好是個多面手，而非在某方面特別優秀但是其他的卻很弱。如果有一個設計團隊的話，聚集各領域的能手也行的通。
設計師越資深，就應該解決越抽象的問題
為了進一步說明，讓我們來看看一些設計師等級以及對應職責的例子：
設計師等級1： 設計一個表格，用戶可以通過它來編輯個人資料。非常具體——假定用戶需要編輯個人資料，設計出表格的形式作為解決方案。
設計師等級2： 設計一個界面，用戶可以通過它來編輯個人資料。這個界面可以是一個表格，可以是所見即所得的實時編輯控件，也可以是一個模態窗口。
設計師等級3（廣度）：設計一個可以更改個人資料，文章以及設置的編輯系統。這個要求就不只局限在個人資料上，而是一個靈活多變，橫跨應用的編輯系統。
設計師等級 3 （深度）：設計讓用戶更新個人資料的方式。這樣設計師需要思考，為什么用戶需要更新個人資料？在何種情況下？以及如果更好的引導？
設計師等級4：設計一個解決方案，從而提高應用中用戶的真實性。編輯個人資料也許甚至都不會成為我們關注的焦點了，也許用戶間的相互評價系統更靠譜。
設計師等級5： 找到應用/公司/網站存在的產品設計問題，并提供解決方案。在最高階，頂尖的設計師往往是能夠推動產品愿景的。
換句話來說，當一個資深設計師感覺自己對產品愿景和策略有很強的主導權時，他會在提案中表現出高度生產力。相反，如果一個資深設計師拿到是一個 初級的設計任務時，比如“設計一個表格”但是認為表格根本不是正確的解決方案，他們也許會對工作安排產生不滿情緒，甚至很可能無法很好的完成這個設計。這 種情緒正是影響團隊士氣的根源：越是資深的設計師，當他們根本不認同產品愿景和策略時，會越沮喪。
設計師之間的交流越多，工作開展得越順利（設計師也會變得更好）
設計師之間互相反饋意見是改進設計最重要也最為有效的方式。如果設計師是獨自工作并且從未給其他設計師看過自己的作品的話，那么幾乎可以保證這 樣的成果會比定期討論的效果差。這就是我們為什么希望設計師們在項目研發階段（設計隨時都會迭代更新）坐在一起工作，而僅在項目執行階段（設計基本已經定 稿，執行開發變得更重要的時候）與工程師坐在一起工作。
設計師的價值和他在產品團隊中付出的努力是很難衡量的
因為設計師的目標是高品質的體驗——不僅是應用的某一個方面，而且是橫跨整個應用；不僅是短期，更是經得起時間考驗的。舉“雜亂”為例，大家通 常都認為雜亂是不好的，但是如何評定在添加到什么程度后變得“太雜亂”呢？這根本沒有辦法量化，同樣你也沒法通過添加某個設計點而讓用戶馬上感覺到提升。 但是慢慢地，就是像海浪沖刷巖壁，這些點積累到一定程度，用戶就會覺得你的網站雜亂不堪，這時有其他更清新簡約的應用能取代你的話，就太遲了。
同樣的，設計師經常要求應用或是系統中不同部分做到一致，這看起來似乎有點過于挑剔，因為從功能層面來講，例如上傳照片的流程是一致的，這樣不就夠了么？
但問題是，用戶不僅只上傳照片。他們可能同樣會上傳視頻。如果上傳照片和視頻的流程是明顯不一樣并且是完全獨立的，這將十分令人困惑。用戶在上 傳照片和視頻的時候會很痛苦。想想一下如果“文件”菜單項在每一個產品里的位置都不一樣，有時在左上角，有時在右上角，或者是底部又或者是其他任何地方， 這對用戶來說都將是一個噩夢。
的確有些設計師在對重要性的平衡上不足。比如傾向于過高估計自己的個人經驗而低估大家乃至整個互聯網形成的經驗，又或是基于自己的體驗來設計產 品，而事實上他們并不是產品的目標用戶。（當然，這里只是寬泛的說明問題，顯然并不是每個設計師都是這樣的。）但事實上，短期內的量化指標會受設計的變化 而上下浮動，從而很難評估。像用戶對產品的信任、理解、長期的情感和喜悅——都會因為設計師對產品的改進而受到積極的影響，而這些卻是很難量化的。
關注細節，直擊設計師的內心
說真的，你想要讓設計師心花怒放，喜悅萬分么？那就精確地將每一個像素都實現出來。設定高標準決不允許粗糙的頁面存在。為了實現一個設計細節而 不惜大量工作，或是徹夜加班去做那些明確要取悅用戶的功能。據我所知，每一個設計師都喜歡與重視設計的產品經理和工程師一起工作——心甘情愿放棄夜晚和周 末的個人時間，就是為了與團隊一起奮斗將產品實現，因為這是大家的共同信仰，整個團隊都希望能創造出真正有用、閃耀和更上一層樓的好產品。
如何與產品經理一起工作
——給設計師的秘籍
產品經理就像是變色龍，為了產品能成功上線，他們不斷地去適應新的需求變化。作為設計師，如何對待他們的個人魅力、大量的數據分析、團隊聚合力以及能言善道的說話方式呢？往下看吧。
了解產品經理的工作是幫助團隊成功上線產品的橋梁
這意味著， 產品經理多半都極其善于：
1. 清晰的溝通：作為團隊里幫助產品成功發布的重要組成部分，產品經理需要將團隊的目標，優先級以及發展藍圖呈現給公司的不同部門，包括法律部、市場部、客戶 運營、銷售等等。這意味著他們的思路要非常清晰簡明，有重點。設計師或者工程師的表達如果有抓不住要點或是含糊其辭的傾向，還尚可原諒——這通常不是這些 職位描述的首要要素。但是對于產品經理，這是不能容忍的。這就是為什么產品經理需要向高管們或是外媒展示產品——并不是因為他們看上去比設計師和工程師更 加“正經”，而是因為產品經理普遍擁有更好的溝通技巧，如果他們沒有那肯定不會被公司錄用。
2. 善于組織：為了上線好的產品，產品經理必須隨時了解項目進度，以及項目是否在正常的運行。他們能夠在需要時將這些碎片化內容重組成一副完整的畫面展示出來，這需要超強（忍術級別）的組織能力。
3. 善于和各種各樣的角色合作：對于產品經理而言，每天和許多來自不同團隊的人交流是習以為常的事情。因為產品經理通常并沒有人事權去讓團隊做事（比如他們并 不能直接聘用或炒掉工程師或者設計師），他們需要向這些同事證明自己并獲取信任。如果產品經理是個傻冒，他們會很快地不加修飾說出自己的腦殘想法，這樣是 會降低交流的成效的。大家都知道那些陳詞濫調里古怪的人，難搞的工程師、無法信任的像 Don-Draper（來自廣告狂人）一般的設計師，但我曾經也遇到過類似的產品經理。要重申的是，這只是寬泛的說明產品經理的一些問題，但是我必須承 認，產品經理通常都比工程師和設計師有著更成熟的想法和同理心。
同時，每一位產品經理，和設計師一樣，都是有各自的強項的。
只有好的溝通能力，組織能力，好的協作能力還不夠。一個好的 PM 還要具備以下技能中的幾種：
1. 執行力：產品經理在發布產品中時表現的如何？ 這可以通過以下幾個方面來評定：1）成功與否取決于目標，2）及時與否取決于期望，3）順利與否取決與團隊的感受。越是資深的產品經理，就有著越大的執行 野心。（比如，一個初級產品經理負責的是給Y產品加一個X功能，而資深產品經理負責的則是建立一個移動平臺產品套裝Z）。好的執行能力，就像是船長平穩行 駛著一艘船。你需要保證每個人都知道自己的職責并且很好的執行，整個團隊齊心協力，這樣你就能有效評估是否帶夠了補給，還有當你駛向地圖上標記的X目的 地，不會被海怪搞死。
2. 設計思維：產品經理在理解，領會以及幫助推動成功的用戶體驗上表現如何？設計師十分渴望與擁有這種技能的產品經理一起合作。這并不是說她一定要在設計專業 上非常在行，但她應該對設計內容、目的，有挑剔的眼光，并且理解設計師的價值，即使她并不總是同意設計師的建議。
3. 分析能力：產品經理對已知信息是如何計劃以及得出結論（定量數據，任務，用戶反饋，過去的經驗等）以便于將來提出更好的工作劃分？一個具有分析能力的產品 經理總是會考慮一切已知和未知的因素，為之后的工作，獲取更多確定性和可預期的因素。一個極具分析能力的產品經理會使用各種工具去幫他確定目標，為任務排 定優先級，讓項目有序進行從而提高產品開發的信心。
4. 大局觀：產品經理是如何理解市場、現有技術、問題、以及產品的反響從而提出極具創新的解決方案的？這是更高階的技巧，產品經理都是夢想家，就像是燎原的星火，點燃了并激勵這整個團隊去追逐那些大膽有時也極具風險的新方向。
作為一名設計師，和產品經理一起工作，很重要的一點是需要謹記整個團隊必須要在工作任務上得到很好的平衡以及正確的安排。這意味著，例如缺乏設 計思維的產品經理應該避開以設計為中心的項目，像是重新設計產品、開發新產品，或是與資深的設計師合作來彌補這個技能缺陷。同樣的，那些在目標和時間上把 握不足的設計師就需要與極具執行力的產品經理一起合作，幫助他們關注在更重要的事情上。
別把產品經理當成監工，與他們并肩作戰，你的工作就會變得更容易
需要了解產品相關領域的知識？找產品經理去。（如果他們不知道，他們會幫你找到知道的人，或是開始研究直到找到答案）。想要客戶、銷售人員或者 用戶的反饋？找產品經理去。想了解現在產品開發優先級或者最嚴重的產品漏洞么？最新的數據能為Y功能帶來什么信息呢？也許你還要感謝產品經理從一些新的角 度給你提供的建議，如何給你的 7 個設計提案里排定優先級，哪一個應該優先細化。
你的產品經理可以為你提供相關背景、數據以及各種有效的反饋，讓你可以做出最好最適合的設計。他們同樣可以幫你搞定 85% 的干擾因素，好讓你更專注在設計上。所以，有事就去找產品經理吧。
當你與產品經理持不同意見
這是一定會發生的。大部分情況下都沒什么問題，這在產品開發團隊中很自然會產生的一種狀況，也是產品開發團隊中三座基石（產品經理，設計師和工程師）之間的正常平衡。通常有以下幾種方式：
1. 產品足夠好了么，是時候發布了么？ 在團隊中，產品經理負責將產品成功定時的發布到市場上，他們有著推動團隊去達到里程碑的天性，從而讓產品發布并且可以快速迭代。而設計師注重的更好的用戶 體驗，他們希望能夠有更長的時間去做設計、研發和優化。極端地說，這些都不是合理的視角。沒人希望明天發布的東西是坨便便，也沒人想花 10 年的時間去設計完美的登錄流程。真正有影響力的產品往往都是及時發布出還不錯的東西。（大部分人都知道這點，爭論的本質是關于具體哪些來評定是不是好和哪 些評定是否及時，但是由于某些原因，最后都會變成毫無效率的討論。）那么怎么解決這個問題呢？你可以冷靜理性地表明自己的立場；你可以分析延遲發布的得 失；你可以同意一起去找一個有權威的拍板人；你可以去征詢一下你們都信任的人的意見（這是我最喜歡的方法）；你可以做些用戶測試，判斷是否其他人的假設是 錯的。大體而言，只要你和靠譜的人一起工作，即使不斷出現異議，這也不是大問題。
2. 我們是否應該發布設計師認為較差但是又符合軟件設計指標的體驗呢？這點很微妙因為它通常會有兩種結果。第一種是設計師的觀點是清晰正確的，而指標并沒有正 確的反應出真實用戶（要么太短期，要么不完整——例如，對某一點來說是好的，但是對于另一個沒有被追蹤的點來說卻不好）在這種情況下，作為設計師，你應該 要找出其他的指標來照亮這塊盲區證明這是一個不好的體驗。第二種是設計師高估了自己的個人經驗，無視網絡形成的經驗。例如，過早給用戶展現“邀請朋友”的 流程也許并不是一個很好的選擇，但是從長遠來說，他們擁有的朋友越多，這個功能就能給產品帶來更多的價值。
3. 我們根本不認同產品策略。關于這一點，我在前文“如何與設計師一起工作”中有更多的描述，這是我認為設計師和產品經理應該很認真的重新考慮是否要一起工作的最主要的情況。
先拋開那些異議，其實大家在最終目標有著堅定的一致意見的情況下仍然很容易分歧。（如果對最終目標沒有達成一致，也就是剛才第 3 點提到的，那是時候做些改變了）。如果可以把這些討論過程記錄下來，并在事后回顧是非常有意義的。通常，它們很有啟發意義，可以為之后總結很多有價值的經 驗。有時你甚至會在回顧中發現這些很愚蠢。（我們竟然花了這么大的精力在這些小的細節上？最后這些根本不是事兒！）
最快虜獲產品經理的心，就是做個靠譜的伙伴
千萬別做 DonDraper（廣告狂人），在午飯后消失去尋找他的“創意魔法”，然后直到周四下午才出現，我是認真的！創意領域的東西并不能作為高大上的借口，為 你免除給團隊做出承諾和做出好設計的責任。沒錯，要預測出何時能夠做出符合你所期望的高質量的好設計確實很難。但是我說的是“靠譜”并不是“每次都按時交 功課”。你也許無法總是精確地知道何時能細化出好的設計，但是你至少應該順道花點時間和團隊溝通你在做些什么，為什么這么做，以及什么時候能完成即使它不 停在變動；分享你的進度和流程；解釋為什么你還在探索，以及為什么你對現有的成果還不滿意。事實上，你和產品經理探討這些會給你貼上“靠譜”的標簽，而且 能幫他更高效的完成工作。除此之外，這些還能幫助他了解你工作的方式，以便將來你們建立更加牢固的合作關系。
因為說到底，你，親愛的設計師，不只是僅僅為你的設計目標負責，應該為整個團隊一起為之奮斗的目標負責。只有這樣，你們才能做出前所未有的好產品。
如何與工程師一起工作
——給設計師的秘籍
工程師是團隊中的魔術師，他們只需要動動手指，執行計劃和繪制像素，你瞧！一款鮮活的產品就誕生了。作為設計師，如何才能跟得上他們精明縝密，自我否定又熱衷腳本的工作方式呢？往下看吧。
工程師是將創意變為現實的人
是工程師將每個好點子變成現實的，這是個大家需要永遠銘記的事實。不管你的公司里有 5 個，500 個或是 5000 個工程師，都不要把他們當做是一種“資源”。他們是產品基石的建筑師，也是讓產品正常運行的守護者，是他們，讓產品快速運作起來，變得穩定，可靠，從而擁 有數百萬記的用戶。通常，也是他們在創新，用新的算法在推動技術，將產品團隊無數投入變得有意義。
這一切的一切我就是想表明：工程師超牛掰！
這意味著…
想要創造點神奇？你需要做的就是說服一兩個工程師
真的，就這么簡單。許多傳奇般的產品是這樣誕生的：幾個好友在某個周末，一邊喝著啤酒一邊敲著代碼。產品經理和管理什么的那都是后來的事情，一切都從最基礎開始——創意，設計然后實現。這也就是為什么我們需要與工程師保持緊密的關系。
或者，試想一下這樣的場景：產品中某個細節部分讓你感到十分煩惱，就像瘙癢在你根本撓不到的地方的那種，你覺得這個設計很有問題，你該怎么做？
1. 在下次團隊討論會中提出來，加入到產品改進列表，然后大家一起來排定優先級，之后等待新的工程師加入團隊，在他熟悉了產品之后再把它做出來。
2. 和某個工程師保持良好關系然后徑直走向他的工位，請他幫個忙，花個三五分鐘處理，然后再看著他提交這個改進。（也許你需要幫他做一件印著 80 年代知名樂團圖案的T-shirt 或是其他點什么作為交換，反正你對插畫也很在行。）
你說哪種辦法更快？
也就是說…
如果工程師明白設計的價值，事情會變得容易得多
試想一下，工程師不需要來詢問你每個設計細節就知道如何處理頁面的空白處，即使你忘了詳細標注邊距的尺寸，他也會打開 PS 自己丈量——這是件多么美妙的事情。特別是他還能給你提出改進意見讓你的設計變得更好，這簡直不可思議。更有甚者，他細致精準到實現出的界面與你的設計完 全無二致，這是件多么驚人的壯舉啊！
你如何才能與這樣的工程師一起工作？如果能招到這樣的工程師，那將會是很幸運的事情，因為界面設計導向的工程師是炙手可熱的。
或者幫助工程師提高一些設計鑒賞力。如何做到呢？不要只是把你的設計丟給他們——和他們闡述你的設計，告訴他們設計的價值，以及為什么你的設計是值得實現的。幫助他們學會如何鑒別實現是否符合設計的要求。對于那些看起來很糟的東西告訴他們你是怎么想的。
建立良好的關系也很重要。人們總是根據和其他人的談話轉移自己的價值取向和優先級。這聽起來很老套但總是屢試不爽。（New Yoker 站點上一篇名為“Slow Ideas”的文章就很完美的闡述了這個策略）
工程師大多不會關注到設計細節，但是他們大部分都很關心用戶體驗而且希望產品有更好的體驗。這并不是說每個工程師都會熱衷于設計細節的實現工作，但是這樣的態度有助于他們理解設計背后的意義。
因為，工程師越是對設計喜歡，他就越能理解這樣設計的原理并且看到它的價值，也就能越快越好地將它實現。
盡早搞清技術限制，為自己節省時間
身為設計師，你很容易就會沉浸在各種設計假想的世界中難以自拔。如果我們能讀懂用戶的心思并且知道他具體想要什么然后再呈現給他？又或是點擊這個按鈕會產生火焰以及爆炸成顆粒隨風飄散的特效？
在沒搞清技術或是時間限制前，別沉迷中那種根本不可能實現的設計。（就算是值得你去爭取一下的設計方案，提前了解限制也會讓你更有底氣。）最壞 的情況就是你傾注大量的時間試圖將某個設計提案做到完美，最后卻發現它卻根本不可行。好的設計師本來就夠少的，而要解決的大問題又有很多，這種毫無效率的 事情應該盡量避免。
所以下次當你有個絕妙的主意在你腦海中閃過，而你卻對實現難度上感到疑惑時，別猜，直接去問工程師！
另一邊也是一樣…
任何時候都讓工程師了解最終設計會是如何，幫工程師節省時間
如果你對自己交給工程師實現的設計方案并不那么自信，在看到成品前都無法確定它是否能夠運作得好，請確保讓他們知道設計有可能會有變化。對于工 程師來說，沒有什么比“通宵完成實現卻在第二天早上得知整個設計已經改了”來得更困擾的事情了，因為這樣他們要把那些傾注了無數心血、成品級別的代碼統統 丟掉了。
當然，工程師都有寫出廢代碼的經歷。這是他們工作的一部分，設計也是一樣。好的工程師理解產品研發的流程是復雜的，東西做出來之前都不知道是否 能行得通，需求常常變化，設計也是。但是溝通清楚哪些部分仍然還在探索，哪些部分基本已經敲定，可以幫助工程師想出如何更好的構筑代碼，是更快速的編程， 還是寫得足夠靈活為將來的修改做好準備。
確保設計得到完美實現的最好方法就是極其密切地與工程師合作
像是坐在他們的邊上看著他們把東西做出來。大家都坐在同一個空間里工作，對于確保大家是否進度一致這件事，則顯得異常容易。問題更快浮出水面，也能更快得到解決。
最終產品如果不是每個人都引以為豪的成品，各種指責將輕易出現。“我們的設計很贊的，但是工程師根本就實現得不對。”這種思想要不得。作為設計 師，你需要對面向用戶的產品負責，而不是那些 PS 的設計稿。對于實現不對的地方為什么不拿出些該有的行動？為什么你不讓工程師給你演示一下他們實現好的東西這樣你們就可以一起摳摳細節？為什么不在開發階 段問問工程師們是否對你的設計有任何疑問？為什么不在發現后給工程師提交一個任務讓他去修復？
沒錯，拿出你的擔當來！
最快俘獲工程師的心的方法，就是提供完整的設計
說起來也可笑，人們總是用“細節導向”來形容設計師，然而事實上許多設計文檔遺漏了大量的場景，最終卻由執行這些分支開發的工程師找出來。
想成為工程師心目中的設計英雄么？請確保你的設計方案是完整的，考慮到各種邊緣場景例如：
1. 國際化： 設計在換了另一種語言后看起來如何？尤其是德語下長文字對排版的影響如何？
2. 出錯狀態：網絡連接丟失時會發生什么？或是數據崩潰？等等。
3. 極端用戶： 當用戶完全沒有任何信息或是活動時，頁面是如何的？那當用戶有著超級多的信息或活動時呢？
4. 頁面轉換：A屏到B屏的跳轉具體是怎么完成的？好的工具在將給你幫大忙，具體可以參考我的另一篇文章《如何在設計（以及僵尸啟示錄）中生存》
設計上述的這些場景不僅可以幫你全局的考慮產品從而增加對設計的信心，更可以幫助工程師去計劃如何構建系統，并給出時間上給出合適的評估。更不用說完整的設計可以避免臨時抱佛腳出來的粗制濫造，因為之前沒人發現直到想做得更好卻為時已晚。
請做一個合格的團隊貢獻者，確保你的設計是完整的，別只為理想的情景去做設計，從設計效果圖的幻境中走出來。因為每一個工程師都知道，唯一有價值的就是最后發布的那個產品。
<span id="shareA4" class="fl"> </span> </div>