下文所有描述，都没有数据支持，本文并不打算做严谨的科学讨论

先说现象

该总结来自于个人工作经历（小地方），个人推测盛行的互联网产品也是类似的，欢迎补充和纠正：

1. 产品、技术 /开发是分开的，不管是外包还是自研。
2. 决定权在产品人员手中，表现以下情况中的某一种或多种：
   • 产品人员负责验收测试
   • 产品经理同时也是领导
   • 产品部最低级的是产品经理，开发部最高级的是开发主管，他们平级（这种结构仅在一个奇葩大公司中见过）
   • 产品总监和技术总监平级，但是，首席运营官，在产品部办公

再说目的

最近换的工作，都没有逃脱这种趋势，现在 31 岁，之后很难再换工作了，相当焦虑。

在上面的技术产品分割的架构下，因为把产品剥离了出去（同时带走了“软件业务设计”），所谓的技术人员也只有名字沾一点技术了，本质工作只剩下纯编码。只编码不做设计，连搬砖都不如，搬砖起码还能积累熟练度。

一些补充：

• 职业头衔变动：九年前刚工作的时候，是软件开发工程师，向前对接系统工程师，向后对接软件测试工程师，另外有关联的还有资料开发工程师、CMO、QA 等。现在变成了 Java 开发工程师，向前向后都对接产品，有关联的是 UI、前端。以前说设计，指的是软件设计，现在说设计，指的是 UI 设计。
• 收入：整体上，技术部的工资水平大于产品部的；局部上，产品部老大的收入大于技术部老大的，产品部小兵的收入小于技术部小兵的
• 加班：
  • 产品部:老大不在公司加班；小兵从来不加班（受制于工作场地，此项可能不准）
  • 技术部：小兵日常晚走，大牛经常加班，老大通常都是公司最后走的人
• 产品部交给技术部的输入文档，最好的情况是界面原型图；一般都是一句话；甚至直接给思维导图
• 除了交接输入文档、验收测试这两个阶段外，产品人员不会主动找技术人员沟通，除非是询问进度或改动需求；当然技术人员除了咨询、确定、请求改动需求外，也不会找产品人员沟通。
• 产品部交接输入文档时，有评审会，但通常会成为：产品部重新讨论需求，技术部旁听。
• 技术部不能打回需求。
• 在上文提到那个有奇葩结构的大公司时，bug 跟踪系统，人为删除了“不是 bug ”、“无法实现”、“需求问题”等选项