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