與開發溝通的藝術

與開發溝通雖然不是咱們設計組的核心工做，但溝通不暢會直接影響工做效率和成果。

溝通不是一件容易的事。由於以開發的視角，看見咱們可能就像瘟神同樣自帶不詳的陰影，每次過來不是改頁面改需求就是催進度。一個溝通很差再遇到火爆脾氣的開發還有被打的風險。

其實，有效的溝通比肌肉更有力量。溝通和其餘技能同樣，是能夠經過學習和練習提升的。

如何與開發溝通最有效？

1、讓開發瞭解需求的願景

咱們在以前的不少設計中都很是在乎交互的全面和具體，而每每忽略背景和產品目標這部份內容的溝通。相應的，有的開發只關注本身負責的開發任務，就像盲人摸象對項目的總體並無清楚完整的認識。

需求的背景和產品目標，我將它們統稱爲願景。願景看似虛無縹緲無關緊要，實際很是的重要。讓開發充分了解需求的願景，有如下幾點好處：

1. 實現同一個目標，開發可能有更高明的解決方案。

開發長期奮鬥在寫代碼的一線，比咱們更加了解前沿的技術。條條大路通羅馬，實現同一個功能，開發可能有更成熟、更先進，或更低成本的解決方式。咱們應該聽取開發的建議，選擇最優的方案。

2. 對將來變化有所預判，開發在設計架構時會更加註重兼容性和擴展性。

由於市場的變化或領導的要求等各類各類的緣由，改更或增長需求的狀況時有發生。若是開發可以提早了解需求的願景，把將來可能出現的變化考慮在內，能夠減小後期改動的難度，萬一真的要改不至於徹底推倒重來。

3. 共同的目標讓團隊更有凝聚力。

願景是工做的目標也是意義所在。每一個開發的心中懷着「讓世界變得更美好」的願望，但願本身的成果能夠改變世界。工做有意義對開發是一種無形的鼓勵。

擁有共同的目標也會增長整個項目組的歸屬感，讓你們統一戰線，成爲相互支持共同奮鬥的戰友。能夠經過這種方式，在情感上得到開發小夥伴的支持。

2、小事釘釘說，大事當面說。

開發在工做時會進行大量的邏輯複雜的思考，若是忽然被打斷，有可能幾個小時思考的成果就前功盡棄了。並且從新進入心流也須要啓動時間。普通的小問題，像一些特別的小的變更啦，補充的提醒啦，諮詢一些不急的小問題啦，能夠在線上問，等開發忙完了會看的。

重要的事情，例如比較大的、緊急的需求變更，必定要當面說。不要由於懼怕衝突而選擇線上溝通。

有研究發現，只有小部分信息是由語言文字傳遞的。語調、眼神、表情和肢體動做等非語言溝通能夠傳遞更豐富的信息。文字溝通雖然能減輕產品經理的心理壓力，卻爲衝突埋下了更大的隱患。

網絡上乾巴巴的文字很容易腦補出生硬的語氣和鐵板同樣的臉。相信好多人有過這樣的經歷，原本是正常的工做交流，微信上越說越生氣，以爲屏幕對面那我的沒禮貌好討厭。可是當面聊天時，又以爲對方人還不錯，最起碼能夠維持的禮貌和客氣。

當遇到潛在的矛盾，積極主動的面對面溝通，加上真誠、禮貌、解決問題的態度，是避免產生的激烈衝突的良好開始。

3、覆盤每一次不良的溝通。

在溝通前作功課，提早梳理須要溝通的內容和邏輯，準備好技術可能質疑的點。預習是提升溝通效果的好方式，不過大部分人每每忽略溝通後的覆盤。其實對於提升溝通力，覆盤更加有效。

什麼狀況須要覆盤呢？覆盤每一次觸發雙方不良情緒的對話。各位小夥伴必定要對本身和對方的情緒有所察覺。這個就像咱們小時候的錯題本，記錄下每一次失敗的溝通，找到緣由，持續改進。

記錄的多了你會發現，不少分歧並非真的觀點相悖，並且雙方討論的側重點並無在一個層面上。設計與開發的知識背景、項目經歷和崗位立場自然差別，不少時候對於同一個問題，你們的理解角度各不相同。

出現分歧不可怕，怕的是雞同鴨講，雙方不知道誤解的存在。每次出現誤解，正是咱們彌補思惟盲區的好機會。深刻理解開發的想法，學着站在開發的角度看待問題，可無限接近「技術思惟」。

有的同窗可能會說，不少時候不是理解的分歧，純粹是技術那我的很差溝通哇！對於這種狀況，覆盤依然有效。是哪句話觸發了對方的情緒機關槍？又是哪句話讓對方很受用？覆盤能夠給咱們不少的反饋，讓咱們找到最適合這我的的溝通方式。

與開發溝通的三大技能

與開發溝通中最多見的三大終極問題：

▍這個可不能夠改一下？

這個XX的問題一看就是要改需求了，改需求的理由千萬種你能夠說老闆要改的，用戶想要的，但都顯得很low。讓開發以爲「~%?…,# *'☆&℃$︿★? ，就知道找藉口！」

適度的認慫能夠安撫一下開發受傷的心靈，但想要長久持續穩定的合做這裏須要第一個技能——產品思惟的專業度。

對於任何需求的變動產品首先要拿話出來，而這裏的說法不該該是推脫。須要的是你的專業度，舉個栗子：爲何購物車按鈕要改爲紅色或黃色？爲何購物車的文字用「放入購物車」而不推薦「當即購買」？ 更具說服力的方式是紅色和黃色的按鈕更具視覺衝擊力，而放入購物車的文案會更輕鬆如同超市購物同樣輕輕一放，不會像當即購買那樣形成用戶的心理壓力。慢慢的你高大威猛的形象便可樹立起來了！

PS : 這裏推薦一本書，大前研一的《專業主義》。指望咱們都能用專業的思惟方式來解決問題，達到目的。

▍這個可不能夠實現？

一看就是又開始腦洞大開，想了一個稀奇古怪的玩意找開發來實現了。對於這個問題的解決之道我以爲有千萬種，最好的方式固然是具有必定的技術背景。但我認爲解決此類問題還有一個方法和技巧就是——產品見識的廣度。

對於咱們設計組是否要懂技術也一直是個爭論不休的話題，我我的認爲須要懂一些。對於不少常識能夠本身平時多瞭解多學習。 可是對於沒技術背景的設計怎麼辦呢？開發說不能實現就不能實現嘛？這時我會建議用本身產品見識的廣度來彌補，俗話說的好「沒吃過豬肉也見過豬跑」。能拿出案例來給開發演示講解，讓開發明白你到底想要的是什麼」

記得看過不少相似的文章，討論的是咱們到底要不要懂技術。有的人以爲不要懂技術，這樣不會被技術所限制，能夠更好的發揮本身創意；有的人以爲要懂技術，這樣更有利於和研發人員溝通。
而目前咱們設計組也處於轉型階段，逐步的在瞭解開發知識，平常與技術人員的溝通向來是沒有太大障礙的。同時也喜歡與技術同事們一塊兒研究一些新的工具，討論一些比較淺顯的問題等。可是這不表明與研發人員溝通就徹底沒有問題，還須要繼續學習。
咱們目前接觸到的開發人員各個年齡階段的都有，開發人員大部分性格都屬於比較謙虛好溝通的。每次有些棘手的問題或無從下手的問題給到開發人員，多數狀況下都會獲得的回答是「我等下調研一下，看能不能解決。」因此無論咱們懂不懂技術，只要需求合理，通常開發人員都是會盡力配合的。與開發溝通需求過程中，必定不要說：「XXXX功能很簡單啊，你看，XXX產品都實現了。」這種話既不會給開發人員增長自信，也不會下降問題在他心中複雜程度，除了引起爭吵，毫無做用。

▍這個開發週期要多久？

這是最難以解決的一個問題，特別是對於沒技術背景的咱們。設計和開發是兩個不一樣的事業部，利益訴求點也不同。有時一個需求的開發週期評估徹底沒法接受，但又不知如何反駁。這時須要跟開發相處的終極大招了，那就是——搞基！

實在沒有比搞基更高效的溝通方式，跟開發一塊兒吃飯，下班陪開發ＬＯＬ，單身程序猿給人家介紹幾個女友……

最終達到的效果是開發耽誤了一點上線週期都以爲愧對了我們的兄弟情！

曉之以情動之以理，但願咱們設計組的小哥哥們能用本身人格魅力走進程序猿的世界，收穫滿滿的基情(.ﾟーﾟ)。

怎麼才能激發開發人員的能動性呢?

一，知道這個開發人員在意的是什麼

他是一個剛畢業不久、滿腔激情、想趕快升職加薪的人?仍是一個想解決最高難度的技術問題，哪怕產品沒人用，只要解決的問題難度足夠高就高興的人?仍是一個滿肚子主意，極其討厭產品經理告訴他該作什麼的「點子大王」?仍是一個有些害羞、不少想法都憋在內心，但其實特別但願本身有存在感的人?知道了他在意什麼，你才能知道怎麼激發他的能動性，以及該讓什麼人作什麼樣的項目。

• 想升職的開發人員確定喜歡作老闆能看得見的項目，哪怕這些項目沒有多高的難度，幫助這些開發人員在老闆面前"出出風頭」，他們確定對你死心塌地。
• 技術宅？那你就給他們強調一下，這個項目的哪些技術問題是其餘開發人員想一想就頭疼、根本解決不了的，知足他們的虛榮心。
• 「點子大王」?那就找機會表揚他的點子又多又好，就算這個想法是你先想出來的，你也能夠在和他交流時循循善誘，引導他說出你的想法，而後讚歎他的想法真厲害。好比，若是你認爲應該在視頻平臺上作一個讓用戶發彈幕的功能，不要直接和」點子大王」說:」你負責作彈幕」，而是要從問題出發，你能夠說」咱們的視頻互動性太差，用戶都不喜歡發評論」，而後引導他說出作彈幕的主意。
• 至於害羞的開發人員，你能夠在開會的時候刻意給他們表達本身的機會，他們絕對對你感激不盡，期待和你繼續合做。知道開發人員要什麼，想辦法在現有的項目裏給他們相應的機會，會讓大家之間的合做事半功倍。
  至於怎麼知道開發人員要什麼，你不如和他約個時間喝杯咖啡私聊一下，瞭解他的我的狀況，你甚至能夠直接問他:」你是如何決定本身作的事情有沒有價值的，你在意的是什麼?」

二，應該知道怎麼和開發人員溝通最有效率

不少開發人員最討厭的就是開會，由於30分鐘的會議打斷了他們的思考時間，拖慢了他們寫代碼的進度。因此要考慮一下這個會到底有沒有必要讓開發人員參加，可不能夠安排到這個開發人員其餘會議以前或者以後的時間，這樣儘可能少地打斷他們的思考，以便於他們有效率地編程。你還須要思考，除了開會以外，還有沒有其餘能夠高效作決定的方式，好比羅列出要點發個有道雲筆記的連接o(￣▽￣)ゞ 。

怎麼催開發人員加快進度?

讓開發人員先本身估計須要的工期,而後再設定截止日期。
若是他們預估的工期太長，就須要提出一些問題，弄清楚爲何須要這麼長時間，看看哪些部分能夠砍掉，到底值不值得爲截止日期砍掉這些功能。
開發人員估計完本身須要的時間後，和開發人員說明咱們的發佈計劃，好比某月某日營銷團隊會開始宣傳產品功能、某月某日咱們須要開始運營工做等等，這樣可讓開發人員瞭解其餘部門的進度,加強他們的歸屬感。
剛入行不久的開發人員估計工期的能力比較差，若是他們的工期估計得太長，千方百計讓他們告訴我工期是怎麼估計出來的，而後跟他一塊兒討論，哪些部分能夠用現成的API（Application Programming Interface,應用程序編程接口），哪些部分能夠少花些時間。
若是遇到確實要將截止日期提早的狀況,告訴開發人員須要提早的詳細緣由。這樣作的目的是，讓開發人員以爲你和他是一塊兒的，讓他感受到你的信任、你在思考如何一塊兒解決工期提早的問題。看看有沒有什麼方式可以從新組合一些計劃，以加快工期。
在這裏，必定要讓開發人員以爲本身是有掌控權的，就算這個截止日期是領導要求的，在表達日期的時候也要儘可能體現出對開發人員的尊重,用問問題的形式表達本身的見解，積極地和開發人員一塊兒尋求提早工期的方式。

須要改需求怎麼辦?

改產品需求是一個很是常見的過程，有些時候前期計劃作得很好，開始測試時卻發現，用戶對某個功能根本不理解，仍是須要改動。開發原本就是一個不斷迭代的過程，這裏就說說有哪些方式可以避免在開發後期改需求，若是真的要改需求，如何和開發人員有效溝通？

• 1.儘早和開發進行產品功能設計的討論，讓他們提早了解各類背景信息。先在產品需求文檔中寫明須要解決的問題、如何判斷成功，並寫幾個產品方案的初稿，和開發人員進行討論，回答他們的問題，讓他們一開始就參與進來。經過這個討論過程，知道有什麼技術上的侷限性，而後根據你們的反饋修改設計。這樣能夠避免在開發人員花費大量時間後才發現問題，而後從新來過，致使開發人員作無用功。
• 2.若是確實須要讓開發們從新寫已經寫好的東西，或者砍掉他們已經寫好的東西，必定要積極承擔責任。這種狀況，多是由於你少考慮了某些狀況，也多是忽然發生了一些變故，好比公司改變了策略、競爭對手忽然"搞事情」。雖然這並必定是你的責任，可是這時你仍是應該積極和開發人員交流，主動承擔責任，告訴他們:"這個賴我，辛苦你了」。其實不少時候，就算你主動承擔責任，開發也不會「順杆爬」埋怨你，他們反而以爲你靠得住，甚至會過來安慰你。積極承擔責任，說句」抱歉，辛苦了」，雖然對你來講就是一句話的事兒，但這能夠很好地安撫已經努力工做了一個月、天天加班加點兒的工程師。不少時候，給開發們一些鼓勵和溫暖，雖然看上去微不足道，但卻能讓他們幹勁兒百倍。

做業：你的一個工程師鄙視你沒有工程背景，在作決定的時候並不信任你提出的建議，你該怎麼取得他的信任?