在互联网公司里，总有那么两拨相爱相杀的动物，程序“猿”和产品“狗”，你觉得我大忽悠，我觉得你傲娇，互相觉得是傻逼，两者之间总会发生一些驴唇不对马嘴的对话因而造成彼此的怨恨。要解决这种互看不爽问题，产品应该站在主动的位置。说得好听点，这是产品应该做的事情，直白点说，产品还得求人干活呢（个人不太喜欢这种说法，后面细说）。
工作中，我和各种岗位的工程师（客户端前端后台和数据）都有打过交道，自认为和工程师之间的沟通还算顺畅和谐，今天就给大家介绍一下我的心得。个人认为无非三点：尊重、信任和理解。这三个词比较虚，其实和所有人打交道都离不开这三点，但在对待工程师这种特定的物种时，这三个词都有一些更具体的含义。
尊重
*这个需求麻烦你帮忙开发一下吧，做完了请你吃饭！
因为产品经理是一个目标导向极强的岗位，简言之就是以项目成败论英雄，而工程师天然有着追求技术难度的属性（应该没有说错吧？这个在社会评价产品经理或工程师是否成功的标准中已经体现的很明显了），虽然有时候目标达成和技术难度在大方向大部分是时候是一致的，但追求上细微的不一致造成了我们现在看到的常见产品和技术的交流模式：产品跪舔技术去完成项目。也因此，我敢负责任的说，在大部分的产品经理眼中，工程师只是他们完成项目的工具而已。不相信？前面我说的“产品还得求工程师干活”这句话有多少人觉得不对劲？
在我看来，这种“产品求着工程干活”的思想就是对工程师岗位的不尊重，这种思想看起来在提高工程师的地位，但实际上是将工程师工具化并排除在最终的成果之外。尊重是应该从心里而来的，而不是在谄媚的行为和语言中（比如前面说的跪舔和各种甜言蜜语，但有时候请吃饭是必不可少）。那么什么才是代表着尊重的关系呢？个人认为，产品经理应该把工程师当做最亲密的合作伙伴。合作伙伴，就是大家有共同的目标，一起努力去完成目标，荣辱与共。从项目角度来说，一个项目的成功，除了产品层面的内容，也需要技术上的完美无瑕，而技术问题的解决，是离不开工程师的积极心态的。
在建立这种可靠的合作关系中，产品经理有主动的责任，那么如何才能激发工程师们的主人翁精神，建立合作关系呢？这里有几个可行的建议：
多向工程师描述大愿景而不仅仅是去描述眼前的功能
让工程师了解更多的背景、目标、成果等，而不是只是告诉工程师要做什么
少说“我”，多说“我们”，不要说“这个应该很简单吧”
作为合作伙伴，你也需要避免自己在工程师被定义为竞对功能抄袭机器和领导训话传达者，认真对待自己的每个需求，能够很好的解释需求的意义和目标，提升自己的靠谱程度。当然有时候，即使做好了自己，你也会碰到看不起产品经理的工程师（可能之前被我们不靠谱的同行伤害过而抱有偏见），你自己的工作都不能得到应有的尊重，这种情况下，唯有你持续的专业表现才是唯一的解药。
信任
*这个应该要不了这么久吧？
相信大家都听到过（或说过）类似“这个怎么要做这么久？”这样的描述，产品和工程师之间的互看不爽很可能都是从这类话开始的，将心比心，这类不信任的话谁听了心里都不会开心。做人啊，最重要的要始终做到善意猜测，即对任何人的任何行为，都要认为对方是基于一个积极的目的的。落实到工作中，善意猜测就是要相信工程师的能力和品格，尽量对工程师给出的技术反馈（方案设计、估时等等）保持足够的信任，绝大部分情况下，应该也没有人会故意耍滑头。如果你身边真的有这种工程师，我这边也建议先自省一下：有工程师朋友告诉我，他在估时的时候就习惯性的多估几天，因为产品总是在开发过程中有各种各样的需求变更。
如果你真的怀疑有诈的时候怎么办呢？我有两个建议：首先是增加自己对一些技术实现的了解，能够有自己的一些基本判断；二是在遇到有疑问时找其他的工程师朋友（别告诉我你把工程师都得罪光了[/吓]）帮忙确认，如果有问题时可以通过细化分解技术方案让一切花招显形，或者寻求升级解决。
理解
*不用这么复杂吧，我只要改一下文案就可以了啊！
在我看来，大部分产品经理对工程师的偏见，是因为不理解工程师的思维和工作方式造成的。一个产品需求摆在面前的时候，大多数产品经理想到的是产品要完成的样子，也就是现在，而工程师必须要去考虑如何实现，要考虑到过去、现在和将来。比如，一个文案的修改，产品经理看到的只是几个字的变化，而工程师要考虑现在文案的实现逻辑，文案的修改如何去完成，以及这种修改的方式在未来的拓展性。经验表明，很多后来被证明为坑的需求，真的就是没有考虑过去和将来造成的。所以我也坚持认为，真正牛逼的工程师和产品经理的组合，是完成当前的需求，填上过去的坑，不给未来留坑的CP。悲哀的是，大多数只做到了完成当前的需求（更悲哀的是在现实中，解决这些隐形的问题于未然并不会给工程师和产品经理带来足够的肯定）。
如何才能理解工程师，让大家保持一致的步调呢？我认为最重要的是要有一些工程师思维，这里的工程师思维我指的是了解计算机程序如何工作以及大致的实现逻辑。看过很多文章说产品经理不需要懂技术，这个观点我部分认同。确实，产品经理不需要懂怎么编码怎么实现，但不能对计算机世界的逻辑一无所知。在敝司我认为靠谱的产品经理或我的偶像中，无一例外都是逻辑清晰，能够描述出需求相关的逻辑实现和了解产品紧密相关的技术问题。
根据工作时间，在策略产品经理的工作中，有几组我认为必须要了解的技术逻辑/思维/…（我也不知道叫啥）：
1.MVC
在我短暂的玩耍式的coding生涯中，我理解最核心的就是这个词啦，如果能理解这个词，也就能理解工程师的思维方式。MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码。这个概念不重要，不用细究，但体现的是工程师的思维方式，通俗的来解释，就是让程序的每一步都去完成一个特定的功能，设计的宗旨是减少耦合方便改进优化和修改。因此程序的逻辑是分层分块的，每一层每一块完成特定的功能，这样当需要修改某些特定的功能的时候，只需要修改很少的部分就能完成。举个简单的例子，在这种程序设计下，删除评价内容在评价存储功能中处理，修改商品的评分在评分计算功能处理，修改评价的展示在客户端完成。所以，当工程师在说这部分更适合xx部门来做的时候，千万不要吃惊，事实上，谁来做什么这类事情你最好提前考虑好。
2.存储、接口和展示
在现在的工程实践中，对数据的处理离不开这三个步骤，像我们以数据为命的策略产品经理，所有的需求也不可能离开三件事。
存储就是将数据存在数据库啦，一般有生产数据库和离线数据库，前者是需要和线上服务一起进行增删改查操作的数据库，后者可以认为是生产数据库的拷贝，一般会定时从生产库同步过来，因而是有延迟的，主要用于数据的加工和分析。之所以这么做，是为了不给添加生产服务器增加无关的压力。数据可能存在硬盘也可能存在内存，工程师会在性能和价格中做出平衡选择。
让正常的理解，在展示的时候，我们直接从存储中获取信息就够了，《数据结构和数据库》课中也是这么教的。在数据量少的情况下，这是可行的，但现在可是大数据时代，那些数据库扛不起那么大的数据量，接口就是为了解决这个问题。接口的作用就是“连接”，根据上层的需求，在底层中获取数据并通过一些逻辑计算，按照信息需求和性能需求将数据提供给上层。
接口有各种格式，在不同的“连接”处都有合适的接口形式，产品经理最熟悉的一类接口，我们常称为API（按定义讲API有更广泛的定义，我也解释不明白），这是后台的最后一层接口，作用是连接后台和前端，所有的展示信息基本上都是从这类接口中来的，因为这类接口往往是http格式，所以也是产品经理可以把关检验的一类接口，在需求验收和故障排查中经常会用到。
3.响应时间、缓存和QPS
已经有很多数据证明，页面加载速度回影响用户体验和转化率，加载速度是产品经理必须了解和关注的内容，也因此如何用合理的架构和存储方式保障性能也是后台工程师孜孜不倦的追求，也是工程师是否牛逼的检验标准。前面在存储和接口中已经提到了性能问题，计算机的计算能力是有限的，当数据量大或运算复杂的时候，计算结果的时间可能会超出用户的忍受范围，这时候工程师往往会抛出缓存这样的解决方式。缓存简单理解就是放弃实时计算，将需要的数据提前准备好。它的坏处是牺牲了实时性，这个时候就需要产品根据产品特性，在实时性和性能之间做出平衡。
另外，QPS也是工程师经常会提到的名词，它的全称是Query Per Second（每秒查询率），这个值和性能紧密相关，后台结构的设计往往依靠对QPS的预估，一个qps10的功能和一个qps1000的功能对工程师来说完全是两回事。产品经理在设计功能时，最好能将这个值的预估提供给工程师，以免上线之后还得下线重构，与此相同的表述还有每天请求量等等。
以上是我认为要理解工程师必须了解的一些概念和问题，了解他们可以避免和RD产生一些不必要的冲突。当然，不同的产品岗位需要了解的常见技术知识是不一样的，但要记住的是不能对技术一无所知，尽量去理解工程师的话，平时多和工程师聊聊天，对于不了解的技术问题，把工程师当老师多问问。如果你连钢筋都不懂，怎么建出高楼大厦呢？
总之，产品经理应该从心里有这样的新年：和谐一点吧，毕竟大家都是十二生肖！总结一下，要和工程师有和谐的沟通，不妨先做到下面三条：
尊重工程师的工作，把工程师当做伙伴
信任工程师的能力和品格，做到永远善意猜测
了解一些技术思维和知识，尽量去理解技术实现
分享干货我们是认真的，更多干货尽在爱盈利！
