都說產品與開發(fā)之間的矛盾由來已久。在很多互聯(lián)網(wǎng)企業(yè)，都發(fā)生過類似這樣的一幕：

工程師日以繼夜，終于在約定的時間里交付產品——雖然這在產品經理看來可能還只能算個高保真的原型。產品經理體驗了這個原型之后，發(fā)現(xiàn)一些與期待不符的地方，提出了改進意見。工程師帶著泛起充滿自信的笑容，再次進入了封閉的開發(fā)階段。

類似這樣的過程持續(xù)往復下去，開發(fā)工程師和產品經理對對方的耐心都會受到挑戰(zhàn)：

產品：新的方案也就是改了一種排列方式，數(shù)據(jù)都是一樣的，再花點時間不就能搞定了么？

開發(fā)：你知道上次那個推薦算法，我花了多久才做出來的么？你說改就改？

產品：可我已經跟老板回復了，說咱們三天就能搞定！

開發(fā)：……

在互聯(lián)網(wǎng)企業(yè)里，開發(fā)人員作為產品的直接生產者，地位受到優(yōu)待；工程師作為“創(chuàng)客”所具有的自豪感及自信心也理所應當。直到隨著項目的持續(xù)，業(yè)務越來越復雜，工程師終于不能在期待的時間里順利交付功能，即使加班加點已在不知不覺中成為習慣。

開發(fā)人員與客戶思維

在大量的團隊里，大家表面看似春意盎然、合作愉快，實際卻危機四伏。問題的原因可能很復雜，而從開發(fā)人員的角度來說，一個很重要的因素在于開發(fā)人員普遍缺乏客戶思維。

這樣的開發(fā)人員也能交付能夠工作的產品，但從產品設計人員的角度來說，要么他們交付的產品在細節(jié)上與需求有較大出入（或多或少，或錯），要么就是花費了大量時間，卻沒人知道他們在做什么，也無法估計一項需求到底需要多久才能開發(fā)完成。

開發(fā)人員大多有相似的特性，他們擅長解決問題，卻不擅長與人溝通。甚至一些人還有“技術至上”的自負心理，認為測試人員和業(yè)務分析師等其他角色可有可無。這或許與他們理工科的成長背景有一定的關系?！耙驗椤⑺?、得證” 這是數(shù)學里常見的論證步驟，理工科的同學們擅長運用已有命題推理出一個個新的命題，這一特點在軟件開發(fā)人員這里有著很好的體現(xiàn)。那些曾在算法練習中用過的代碼片斷就像一段段積木，當產品設計人員提出一個想法，開發(fā)人員就心生一計：這事兒沒問題！似乎，接下來就缺時間了。

事實卻不會那么簡單。一個需求的提出，必然有其商業(yè)上的考量，其所在的業(yè)務場景、適用的范圍和限制，以及要實現(xiàn)的可度量目標。在實現(xiàn)過程中，還需要考慮不同的解決方案，各個方案中可能存在的風險，以及需要投入的成本。在團隊中，只有所有人都對業(yè)務有一致的理解，所有的努力都朝著一致的方向，才有可能獲得成功。

有客戶思維的開發(fā)人員，能夠把工作當作為客戶提供服務：自己是服務提供方，而同事、老板就是客戶。他們積極地從客戶角度思考需求的真正來源，在開發(fā)過程中與客戶保持溝通，適時給出合理的建議。最終在更高效完成工作的同時，建立更順暢的協(xié)作機制，培養(yǎng)出更健康友好的團隊關系?？蛻羲季S也能夠培養(yǎng)開發(fā)人員轉變視角的習慣和能力，令其習慣于分析價值并作出決策，既而為職業(yè)和事業(yè)的發(fā)展帶來更多可能。

思考并溝通

當接到一個新的需求，無論是初次提及，還是后續(xù)反饋，首先要思考的是為什么會有這個需求產生，它解決了什么問題、提供了什么價值。雖然開發(fā)人員很聰明，卻很容易忽略這樣一個其實很簡單的部分。大部分開發(fā)人員的思維方式真的就如同數(shù)學證明那樣，習慣于接受指令并醉心于實現(xiàn)一些看起來很酷的功能。

然而，如果一開始不弄清楚需求的前因后果，就會出現(xiàn)在做了一半、甚至完成了之后，才發(fā)現(xiàn)最終得到了一個與設計人員的期待并不符合的產品。其他情況，由于開發(fā)團隊內部理解不一致導致接口不兼容、由于前期沒有溝通清楚而導致返工浪費等情況更是數(shù)不勝數(shù)。

舉一個實際發(fā)生過的例子。

作為一個基于瀏覽器來管理的電商網(wǎng)站運營方，產品經理希望管理員能夠在瀏覽器中即時收到網(wǎng)站用戶下的新訂單，而不再需要隔一段時間去刷新瀏覽器，以便做好發(fā)貨準備。

在拿到這樣的需求之后，工程師很興奮。他開始著手研究服務器推送的各種技術，并深陷其中不可自拔，學習了長輪循、WebSocket等技術。三天過去了，他終于成功地完成了相關開發(fā)工作，急切地找產品經理要演示其進展?？蓻]想到，產品經理卻并不買賬，沒等工程師演示，就黑著臉向他回復，“這三天里，我兩次向你詢問進展，你都說‘快了’?？晌乙恢睕]見什么動靜。后來，我已經請旁邊的阿哲搞定了，他只花了一小時！”

工程師轉向阿哲，卻發(fā)現(xiàn)阿哲用了一個每隔5秒向服務器再取一次數(shù)據(jù)的“笨方法”。工程師感到委屈不已，向產品經理解釋自己的方案比阿哲的方案更有效率，也更先進……

在這個例子里，工程師自認為的高效和先進似乎并不是產品經理所關心的。產品經理作為功能設計者，自然更關心其功能價值，而不是技術方法是否先進。另外，對需求里的“即時收到新訂單消息”里“即時”的理解，工程師一開始就將自己的臆測加了進去。

不妨考慮一下，需求的價值是使管理員更早知道新訂單到來，但這個“即時性”要求有多高呢？顯然沒有達到秒級，大概，分鐘級也是能接受的——畢竟之前管理員是手動刷新瀏覽器去完成這個需求的，這說明新訂單并沒有頻繁到需要秒級通知。因此，不管是工程師提前想到了這個結論，還是與產品經理及時溝通了自己的技術方案計劃，都可以提早防止浪費。

在工作中，如果只將產品經理視為規(guī)則制定者，將領導視為發(fā)號施令的老板，我們便會失去思考的機會。逐漸地，思考的能力也將失去。但如果將他們視為客戶，那么就更容易理解客戶與我們之間可能存在的誤解，畢竟大家術業(yè)有專攻。這時，不少人便會考慮客戶可能的隱藏的想法，耐心地溝通核對，態(tài)度也端正友好。

靈活地給出建議

對于一家IT公司來說，開發(fā)人員是當之無愧的寶貝，各企業(yè)為了招來優(yōu)秀的工程師，都不惜重金。他們是那么的天才，似乎什么問題到了他們那兒都有解決方案。是的，其實一個用技術能夠解決的問題，往往都有很多種解決方案，有些方案甚至不涉及技術。在擁有天才一面的同時，開發(fā)人員也相當?shù)墓⒅?，有時候甚至過于耿直，過早地將精力集中到技術方案上，而這時的方案往往還只是開發(fā)人員一廂情愿的期盼，不一定是客觀上合適的方案。令人不安的是，與這些技術人員合作的業(yè)務分析人員和管理人員卻沒有辦法預測或是驗證其中的風險。

在手機支付的概念在技術圈風聲水起時，有人正對“刷手機乘公交”的想法感到興奮，在一邊走一邊與朋友分享的時候，正好有公交車到站。只見朋友伸出手機在刷卡機邊輕輕一滑，“嘀”的一聲，刷卡成功！他好奇地問朋友，你是怎么做到的？朋友淡定地翻開手機蓋，從中緩緩抽出一張公交卡。

雖然這只是一個笑話，但現(xiàn)實中類似的情形卻在真實的發(fā)生著，就像上一節(jié)中提到的例子一樣。 如果開發(fā)人員擁有客戶思維，就應該在真正行動之前，考慮多個可能的方案、權衡其中的優(yōu)劣，及時向客戶闡明這些方案的利弊；根據(jù)對需求的理解，以及客戶提供的更多信息，給出具有可操作性的建議。對于一些經驗豐富的開發(fā)人員來說，給出有價值的建議早就成為了他們的工作習慣，這也正是能體現(xiàn)他們更具專業(yè)性的行為之一。

不過，對于老油條們來說，也需要警惕：請注意保持對客戶的尊重。作為客戶，他們有時候顯得不太專業(yè)，甚至不太友好。但開發(fā)人員，請一定尊重自己的客戶?？蛻舻淖罱K目的是解決問題，而解決方案不一定要花哨炫酷，或是技術先進——開發(fā)人員應該在合適的時機，讓客戶知道他們可以做出選擇，而不是由開發(fā)人員自行決定。即使開發(fā)人員自己有什么偏好，也不應該直接或間接地強加于客戶，那樣只會畫蛇添足、招致反感。

《軟技能》一書中指出了一個事實，雖然聽起來有點殘酷：當我們?yōu)榱酥\生而一頭扎進代碼的世界里時，其實與小時候老家鎮(zhèn)上鐵匠鋪里的鐵匠并沒有什么區(qū)別。那樣的我們，不用考慮顧客為何需要打造一件那么奇形怪狀的鐵器；在顧客一而再地提出挑剔意見時，我們一開始爭辯，后來喪氣，最后麻木了。那樣的我們，數(shù)十年如一日，作為鐵匠的技藝愈加純熟。直到有一天，一種叫做“鑄造機床”的遠在天邊的東西，奪去了我們的飯碗。

如果養(yǎng)成了思考的習慣，擁有為客戶提供專業(yè)服務的能力，隨時都能換個地方另起爐灶。實際上，企業(yè)的價值正是體現(xiàn)在它為客戶解決的問題上。習慣將工作視作服務客戶，把自己當作一個企業(yè)去思考，也就具有更獨立的人格，為今后真正做出良好的商業(yè)決策積累經驗、奠定基礎。 一旦擁有了這樣的心態(tài)，開發(fā)人員也就不會只關注完成手頭的工作，還知道要計劃接下來的職業(yè)發(fā)展，關注自己和同事的成長；也不會因為覺得作為開發(fā)人員去幫老板實現(xiàn)夢想沒有意義而煩燥不安。很快，開發(fā)人員這種聰明的人種就會成為有思路、有規(guī)劃的進步青年。