在软件团队中，业务人员和技术人员常常会出现一些矛盾，具有代表性的往往是产品经理和技术经理之间的矛盾。
一方面有技术背景的人往往会带入过重的技术思维到商业逻辑中，另一方面业务人员往往高估需求的可行性，这是业务人员和技术人员产生矛盾的主要原因。
业务人员和技术人员之间的矛盾往往还没有那么简单，而是老板（资方或者市场）、业务人员（产品经理或者业务分析师）、技术人员之间的矛盾。
某种程度上来说，老板也属于业务人员之列。
这三类人由于其背景的原因经常尿不到一个壶里去，但是又谁也离不开谁。
- 老板（资方或者市场）：关注商业模式和如何赚钱。
- 业务分析师（或者产品经理）：也需要关注商业模式，更多关注系统特性和用户体验。
- 技术人员：关注系统实现和技术方案，也关注系统特性和用户体验。
一个糟糕的公司各个角色的内心可能会是这样的：
- 老板： 产品经理根本无法理解我的战略和 IDEA，就知道做一堆没花里胡哨的功能；IT 的技术不行，系统不能用。
- 产品经理：老板都是傻*，决策都是拍脑门儿的；IT 的技术不行，到处都是 Bug，各种需求做不了，无法给用户极致的体验。
- 技术经理：产品都是傻*，很多逻辑都不通，一堆没用的功能，也不到市场上验证下有没有用；傻*老板天天知道催进度，技术债这么多怎么往前做。
有时候这三种角色似乎是对立的，但有时候又不是，我们来做一个思维游戏尝试分析其内在的逻辑。
假定，老板、产品经理、技术经理一起去餐厅吃饭，他们坐在看台的位置上，这是一个视野优良的位置。产品经理酒过三巡后说：这家店要是能在看台上增加一个厕所就好了，这样有更好的用户体验，一定会有更多人来。
技术经理嘲讽到，这家伙一点不懂建筑，看台上留有供排水管道吗？厕所离餐厅这么近异味如何处理？
老板得意的说，你们不要从自己的角度看问题，要看市场上有没有人愿意花额外的钱，就为了在看台上上个厕所，如果有人愿意花钱，技术上也可以再想办法，不一定就完全不能实现。
从这个思维实验中我们能看到这三种角色的思维差异。当他们看待一个问题时，出现在眼前的东西是不同的：
- 老板：更多关注投资回报 ROI，至于技术问题可以再想办法调用资源克服。一般的老板从经验和直觉出发决定产品和投资方向，优秀的老板从市场调研的结果出发决定产品和投资方向。
- 产品经理：有时候产品经理更像是用户代表，将需求转化为产品设计。一般的产品站在第一视角，用自己的体验度量用户体验，优秀的产品经理会站在群体和逻辑视角来评估需求的可行性。
- 技术经理：技术经理更关注如何实现。一般的技术经理从局部看待问题，而优秀的技术经理从全局看待问题。
在一些优秀的公司，技术经理会尝试去理解业务背后的生意；老板也充分信任产品、市场团队得到的用户和调研结果，尽量不从自己的喜好来干预决策。
反面的例子是，某专注用户体验的手机公司花了大量的精力打磨边框和按键，却连基本的通话质量都没有保证；很多 IT 系统做了一堆功能，但是实际上在用的不到 30%。
除了思维差异之外，利益差异也是导致这三方矛盾原因之一。
在 KPI 压力下，技术经理只追求需求是否容易实现、有没有风险，因此产品经理的需求如果存在逻辑问题，严重影响了按时交付，技术经理肯定不满意；产品经理的诉求是更多的功能、亮点，这样可以用来和老板汇报成果，而是否有用户那是老板和销售的问题。
在这种窘境下，技术经理和他的团队如何生存下来，并化解和产品经理、老板之间的矛盾（至于产品经理和老板之间的矛盾，不在这次讨论范围）？
遇到这类问题，我们一般还是会先从动机和痛点出发。
如果老板的动机就是压榨开发人员，给出超额工作量，必须加班做完。在这种动机的前提下，开发经理想要实现既要保护开发团队又要满足老板的诉求这几乎不可能。
这种情况可以考虑换工作，更不必投入更多感情，也不算坏事。
除此之外，产品经理可能有下面的痛点，这些痛点往往会导致矛盾的产生：
- 产品方案容易受到技术人员的质疑和挑战。
- 技术人员在可实现性上常常给出否定的结论，并常常砍需求。
- 技术人员抗拒需求变更。
- 技术人员常常抱怨需求不够细或者清晰。
而技术经理的痛点有：
- 产品方案和需求输出太晚，来不及进行技术方案。
- 产品经理在实现过程中调整需求。
- 产品需求比较粗糙或者逻辑不自洽。
- 产品经理不相信可行性评估的结论。
- 产品经理质疑工作量估算的结果。
其实一切问题都是上级管理者应该处理的问题，领导想要或者有意识解决，这些问题都能被解决。 站在技术经理的视角来说，合作、博弈、向上管理都必不可少。
和产品经理合作的要点有：
- 优化知识传递的工作方式。例如，使用更好知识载体，用技术、产品都能理解的方式描述需求。
- 约定产品方案和需求的输出时间、质量要求。
- 理解产品设计的意图和愿景。
和产品经理博弈的要点有：
- 利用工作量估算来处理不好实现的需求。
- 利用需求评审来处理逻辑不合理、质量不佳的需求。
- 利用向上管理来处理需求给出的时间不及时的问题。
- 利用掀桌子来处理伤害开发团队的问题。
向上管理的要点有：
- 充分理解老板对于公司的战略目标和方向。
- 充分理解需求的业务价值、优先级和重点。
- 陈述收益和成本，弱化感受和情绪，体现职场的专业性。
在产品经理和技术经理相爱相杀之间，老板的态度往往更加务实：你们吵归吵，别耽误我挣钱。
技术经理不能仅仅聚焦于技术，更多的需要通过技术服务商业价值，这是整个矛盾和冲突的焦点。
一些创业公司，产品经理和技术经理争执的点在于，某些需求看起来毫无意义，却需要开发团队加班完成；反之，技术经理和其团队却把商业价值弃之不顾，关注在"这技术很酷"上。
无论是产品经理还是技术经理，是否能争取到老板认可，都需要聚焦在商业价值上，并基于此来评估产品、技术方案。
所以关于是否能在看台上修建厕所一事，如果技术经理给出的理由是因为缺乏下水道而不好实现的话，他会站在老板和产品经理的对立面。
老板和产品经理从来不会同情技术人员是否需要花费更多的 effort 去实现一个想法，更多的在乎投入是否划算；同样的，技术经理也不需要同情老板的投资是否会打水漂。
"这不好做" 永远不要成为技术经理拒绝某个需求的理由，而是需要陈述相关需求的业务价值，进一步验证其逻辑性。
一次错误的产品决策诚然会伤害技术架构，但是为此买单的毕竟是老板。
如果产品设计上确实需要 180° 掉头的情况，技术经理只需要平静而诚实的估算相关工作量即可，然后愉快的下班喝一杯。