开发人员的客户思维｜洞见
都说产品与开发之间的矛盾由来已久。在很多互联网企业，都发生过类似这样的一幕：工程师日以继夜，终于在约定的时间里交付产品——虽然这在产品经理看来可能还只能算个高保真的原型。产品经理体验了这个原型之后，发现一些与期待不符的地方，提出了改进意见。工程师带着泛起充满自信的笑容，再次进入了封闭的开发阶段。
类似这样的过程持续往复下去，开发工程师和产品经理对对方的耐心都会受到挑战：
产品：新的方案也就是改了一种排列方式，数据都是一样的，再花点时间不就能搞定了么？
开发：你知道上次那个推荐算法，我花了多久才做出来的么？你说改就改？
产品：可我已经跟老板回复了，说咱们三天就能搞定！
开发：……
在互联网企业里，开发人员作为产品的直接生产者，地位受到优待；工程师作为“创客”所具有的自豪感及自信心也理所应当。直到随着项目的持续，业务越来越复杂，工程师终于不能在期待的时间里顺利交付功能，即使加班加点已在不知不觉中成为习惯。
开发人员与客户思维
在大量的团队里，大家表面看似春意盎然、合作愉快，实际却危机四伏。问题的原因可能很复杂，而从开发人员的角度来说，一个很重要的因素在于开发人员普遍缺乏客户思维。
这样的开发人员也能交付能够工作的产品，但从产品设计人员的角度来说，要么他们交付的产品在细节上与需求有较大出入（或多或少，或错），要么就是花费了大量时间，却没人知道他们在做什么，也无法估计一项需求到底需要多久才能开发完成。
开发人员大多有相似的特性，他们擅长解决问题，却不擅长与人沟通。甚至一些人还有“技术至上”的自负心理，认为测试人员和业务分析师等其他角色可有可无。这或许与他们理工科的成长背景有一定的关系。
“因为、所以、得证” 这是数学里常见的论证步骤，理工科的同学们擅长运用已有命题推理出一个个新的命题，这一特点在软件开发人员这里有着很好的体现。那些曾在算法练习中用过的代码片断就像一段段积木，当产品设计人员提出一个想法，开发人员就心生一计：这事儿没问题！似乎，接下来就缺时间了。
事实却不会那么简单。一个需求的提出，必然有其商业上的考量，其所在的业务场景、适用的范围和限制，以及要实现的可度量目标。在实现过程中，还需要考虑不同的解决方案，各个方案中可能存在的风险，以及需要投入的成本。在团队中，只有所有人都对业务有一致的理解，所有的努力都朝着一致的方向，才有可能获得成功。
有客户思维的开发人员，能够把工作当作为客户提供服务：自己是服务提供方，而同事、老板就是客户。他们积极地从客户角度思考需求的真正来源，在开发过程中与客户保持沟通，适时给出合理的建议。最终在更高效完成工作的同时，建立更顺畅的协作机制，培养出更健康友好的团队关系。客户思维也能够培养开发人员转变视角的习惯和能力，令其习惯于分析价值并作出决策，既而为职业和事业的发展带来更多可能。
思考并沟通
当接到一个新的需求，无论是初次提及，还是后续反馈，首先要思考的是为什么会有这个需求产生，它解决了什么问题、提供了什么价值。虽然开发人员很聪明，却很容易忽略这样一个其实很简单的部分。大部分开发人员的思维方式真的就如同数学证明那样，习惯于接受指令并醉心于实现一些看起来很酷的功能。
然而，如果一开始不弄清楚需求的前因后果，就会出现在做了一半、甚至完成了之后，才发现最终得到了一个与设计人员的期待并不符合的产品。其他情况，由于开发团队内部理解不一致导致接口不兼容、由于前期没有沟通清楚而导致返工浪费等情况更是数不胜数。
举一个实际发生过的例子。
作为一个基于浏览器来管理的电商网站运营方，产品经理希望管理员能够在浏览器中即时收到网站用户下的新订单，而不再需要隔一段时间去刷新浏览器，以便做好发货准备。
在拿到这样的需求之后，工程师很兴奋。他开始着手研究服务器推送的各种技术，并深陷其中不可自拔，学习了长轮循、WebSocket等技术。三天过去了，他终于成功地完成了相关开发工作，急切地找产品经理要演示其进展。可没想到，产品经理却并不买账，没等工程师演示，就黑着脸向他回复，“这三天里，我两次向你询问进展，你都说‘快了’。可我一直没见什么动静。后来，我已经请旁边的阿哲搞定了，他只花了一小时！”
工程师转向阿哲，却发现阿哲用了一个每隔5秒向服务器再取一次数据的“笨方法”。工程师感到委屈不已，向产品经理解释自己的方案比阿哲的方案更有效率，也更先进……
在这个例子里，工程师自认为的高效和先进似乎并不是产品经理所关心的。产品经理作为功能设计者，自然更关心其功能价值，而不是技术方法是否先进。另外，对需求里的“即时收到新订单消息”里“即时”的理解，工程师一开始就将自己的臆测加了进去。
不妨考虑一下，需求的价值是使管理员更早知道新订单到来，但这个“即时性”要求有多高呢？显然没有达到秒级，大概，分钟级也是能接受的——毕竟之前管理员是手动刷新浏览器去完成这个需求的，这说明新订单并没有频繁到需要秒级通知。因此，不管是工程师提前想到了这个结论，还是与产品经理及时沟通了自己的技术方案计划，都可以提早防止浪费。
在工作中，如果只将产品经理视为规则制定者，将领导视为发号施令的老板，我们便会失去思考的机会。逐渐地，思考的能力也将失去。但如果将他们视为客户，那么就更容易理解客户与我们之间可能存在的误解，毕竟大家术业有专攻。这时，不少人便会考虑客户可能的隐藏的想法，耐心地沟通核对，态度也端正友好。
灵活地给出建议
对于一家IT公司来说，开发人员是当之无愧的宝贝，各企业为了招来优秀的工程师，都不惜重金。他们是那么的天才，似乎什么问题到了他们那儿都有解决方案。是的，其实一个用技术能够解决的问题，往往都有很多种解决方案，有些方案甚至不涉及技术。
在拥有天才一面的同时，开发人员也相当的耿直，有时候甚至过于耿直，过早地将精力集中到技术方案上，而这时的方案往往还只是开发人员一厢情愿的期盼，不一定是客观上合适的方案。令人不安的是，与这些技术人员合作的业务分析人员和管理人员却没有办法预测或是验证其中的风险。
在手机支付的概念在技术圈风声水起时，有人正对“刷手机乘公交”的想法感到兴奋，在一边走一边与朋友分享的时候，正好有公交车到站。只见朋友伸出手机在刷卡机边轻轻一滑，“嘀”的一声，刷卡成功！他好奇地问朋友，你是怎么做到的？朋友淡定地翻开手机盖，从中缓缓抽出一张公交卡。
虽然这只是一个笑话，但现实中类似的情形却在真实的发生着，就像上一节中提到的例子一样。 如果开发人员拥有客户思维，就应该在真正行动之前，考虑多个可能的方案、权衡其中的优劣，及时向客户阐明这些方案的利弊；根据对需求的理解，以及客户提供的更多信息，给出具有可操作性的建议。对于一些经验丰富的开发人员来说，给出有价值的建议早就成为了他们的工作习惯，这也正是能体现他们更具专业性的行为之一。
不过，对于老油条们来说，也需要警惕：请注意保持对客户的尊重。
作为客户，他们有时候显得不太专业，甚至不太友好。但开发人员，请一定尊重自己的客户。客户的最终目的是解决问题，而解决方案不一定要花哨炫酷，或是技术先进——开发人员应该在合适的时机，让客户知道他们可以做出选择，而不是由开发人员自行决定。即使开发人员自己有什么偏好，也不应该直接或间接地强加于客户，那样只会画蛇添足、招致反感。
结语
《软技能》一书中指出了一个事实，虽然听起来有点残酷：当我们为了谋生而一头扎进代码的世界里时，其实与小时候老家镇上铁匠铺里的铁匠并没有什么区别。有些铁匠只知埋头苦干，不考虑顾客为何需要打造一件那么奇形怪状的铁器；在顾客一而再地提出挑剔意见时，我们一开始争辩，后来丧气，最后麻木了。那样的我们，数十年如一日，作为铁匠的技艺愈加纯熟。直到有一天，一种叫做“铸造机床”的远在天边的东西，夺去了我们的饭碗。
如果养成了思考的习惯，拥有为客户提供专业服务的能力，随时都能换个地方另起炉灶。实际上，企业的价值正是体现在它为客户解决的问题上。习惯将工作视作服务客户，把自己当作一个企业去思考，也就具有更独立的人格，为今后真正做出良好的商业决策积累经验、奠定基础。
一旦拥有了这样的心态，开发人员也就不会只关注完成手头的工作，还知道要计划接下来的职业发展，关注自己和同事的成长；也不会因为觉得作为开发人员去帮老板实现梦想没有意义而烦燥不安。很快，开发人员这种聪明的人种就会成为有思路、有规划的进步青年。
- 相关阅读 -
点击［阅读原文］到洞见网站查看文章全部内容&绿字部分。
本文版权属ThoughtWorks公司所有，如需转载请在后台留言联系。