为什么技术人要懂一点产品？

为什么技术人要懂一点产品？程序员和产品经理之间的爱恨情仇，在互联网上比比皆是。这之间通常很难说谁对谁错，因为站在双方的角度，都是有道理的。但最后的结果却是不尽如人意，事情没做好，大家也都干的不开心。正所谓，“善战者无赫赫之功”。作为程序员，是当项目步入恶劣的处境中时再竭尽全力力挽狂澜，谱写英雄故事，还是顺利高效地把工作做完，保持轻松愉悦的工作状态，我一定会选择后者。

产品sense是一个容易让技术人忽略，但重要的软技能。这是一个很宽泛的词，不过可以简单地理解：

• 了解对自己所做的产品。比如：它为用户提供了什么价值？用户为什么使用它？为什么会愿意买单？
• 具有同理心，能站在用户的角度能够分辨产品的好坏。比如：什么样的设计好用或不好用？我们设计的使用流程是否符合用户的使用习惯？

我们在网上看到了铺天盖地的关于源码、框架、原理的文章。个人认为，这些文章很容易将我们引入一个误区，就是为了技术而钻研技术，而没有与工作进行结合。我们可能会觉得我看了多少源码、掌握多少框架和技术，才能体现一个技术人的实力。的确，这些东西在面试过程中是不可或缺的。但是我们也清楚知道，现实实际上是“面试造火箭、工作拧螺丝”。在实际工作中，对于大部分以业务为主的程序员很少会使用那些“火箭工程技术”。工作中起到作用的更多的是系统设计、设计模式、代码规范这些细节，以及各种我们在面试中很难准确考察的软技能。软技能在不同场景下有不同的做法，无法像技术解析那样通用。想要总结出通用的方法论、输出成文章会更难。沟通能力和产品sense就是这样的软技能。

如果一个程序员不懂一点产品，与产品经理之间的沟通可能就会变得被动和困难。如果产品经理怎么说，程序员就怎么做。那加班上线再加班回滚可能就会成为我们的真实经历，而不仅仅是我们在网上看到的谈资。这是岗位职责决定的，因为产品经理是决策者，程序员是执行者。但是产品经理通常和程序员又是合作关系，而不是直接的上下级。所以程序员也需要参与PRD评审，对产品设计不合理的地方提出自己的看法，以及对于实现的难度提供有效的信息输入。提前考虑到各方面的问题，帮助产品经理完善设计、并权衡成本收益，是程序员重要的职责，也是让我们的工作能高效完成的条件。如果指望产品经理将所有细节都考虑到是不现实的，毕竟人的思维总是有局限性，而且产品经理通常也不了解各种技术细节。《代码大全》中有一个缺陷和修复成本的曲线，我们越早找出问题，修复它的成本就越低。如果我们能在需求设计和技术调研阶段就发现问题，那么将节省后续很多的时间。而现实中，我们却很容易忽略他们的重要性，反而着急忙慌地开始写代码，希望能早点完成任务。

– 摘自《代码大全》第3章

如果技术人没有点产品sense，在工作中可能会发生下面这些问题，影响我们的工作效率：

• 误解需求： 如果不了解需求提出的背景，可能会误解产品经理传达的需求，从而导致开发出与预期不符的功能。最后的结果就是交付延期或者加班。
• 沟通障碍： 在沟通过程中，产品经理可能会使用涉及产品领域的专业术语和概念。如果程序员不了解这些术语，或理解有误，就会导致沟通障碍，阻碍信息的准确传达。这也是为什么DDD强调在沟通和写代码时要统一概念和词汇，即“通用语言(Ubiquitous Language)”。
• 难以提出有效建议： 对产品不了解，也无法分辨产品好坏的话，我们就无法提供有意义的建议和反馈。比如交互流程、技术可行性等。我们通常会认为这是产品经理的工作，和自己无关，但很多时候这层界限是模糊的。研发永远是产品的第一批用户，我们在开发、测试的过程中会无数次地使用我们自己的产品，对于用的顺手和不顺手的地方都有很直观的体验。研发的绩效多多少少会受到产品业绩的影响，如果我们能提供有效的输入，把产品优化地更好，对于研发也是有利的。如果我们在工作中做的是自己想做的事，那也会更有动力，更开心。同时，这也体现出了我们的团队意识以及推动事情的能力，构建了一个积极的形象：我们没有只盯着自己手中的工作，而是站在大团队的角度，推动产品被建设的更好。

总而言之，我觉得作为一个技术人，懂一点产品是非常重要的。不仅仅是为了日常工作的顺利进行，也是为了扩展自己的能力圈，获得更好的职业发展。

这些碎碎念是我的一点工作感悟，之后如果有值得记录的点，可能会顺着这个话题展开写写。