開發人員的客戶思維

都說產品與開發之間的矛盾由來已久。在很多互聯網企業，都發生過類似這樣的一幕：

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

類似這樣的過程持續往複下去，開發工程師和產品經理對對方的耐心都會受到挑戰：

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

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

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

開發：……

在互聯網企業里，開發人員作為產品的直接生產者，地位受到優待；工程師作為「創客」所具有的自豪感及自信心也理所應當。直到隨著項目的持續，業務越來越複雜，工程師終於不能在期待的時間裡順利交付功能，即使加班加點已在不知不覺中成為習慣。

開發人員與客戶思維

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

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

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

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

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

思考並溝通

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

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

舉一個實際發生過的例子。

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

在拿到這樣的需求之後，工程師很興奮。他開始著手研究伺服器推送的各種技術，並深陷其中不可自拔，學習了長輪循、WebSocket等技術。三天過去了，他終於成功地完成了相關開發工作，急切地找產品經理要演示其進展。可沒想到，產品經理卻並不買賬，沒等工程師演示，就黑著臉向他回復，「這三天里，我兩次向你詢問進展，你都說『快了』。可我一直沒見什麼動靜。後來，我已經請旁邊的阿哲搞定了，他只花了一小時！」

工程師轉向阿哲，卻發現阿哲用了一個每隔5秒向伺服器再取一次數據的「笨方法」。工程師感到委屈不已，向產品經理解釋自己的方案比阿哲的方案更有效率，也更先進……

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

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

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

靈活地給出建議

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

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

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

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

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

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

更多精彩洞見，請關注微信公眾號：ThoughtWorks