两年前，由于某些原因，重新学了学ruby写网站，才知道当前的互联网开发已经发生了翻天覆地的变化，除了前端框架的兴起外，还多了一个职位，叫产品经理。
听到这个名字，第一反应就是，what？这干嘛的？
从字面上理解就是做项目的，不是应该叫项目经理或系统分析员之类的吗？产品经理是干嘛的？
十年之前的软件开发行业，前端和产品经理的兴起
十年之前，刚好毕业，那时候前端这个岗位还没有现在需求这么大，更没听说过产品经理，公司统一招的基本清一色后端，业务也是以企业业务为主，也就是现在的B端。
产品部门是随着C端客户不断增大产生的，尤其是app的兴起。
上图是iphone发布时间表，注意看时间，2010年是iphone4发布的时间，不得不说，4代iphone才逐渐走入公众的视角中，前三代并没有4和4S这种划时代产品这么普及。
这是前端工程师的可视化增长趋势图，可以看到在2010年之后的移动端需求的增长趋势。
这是产品经理的可视化增长趋势图，2010年前，几乎无人问津。
回想十年之前的开发流程，根本没有产品经理这一说，就程序员~软件设计师~系统分析员，只有系统分析员才能接触客户，进行需求分析。这是当时大三上半年考软件设计师资格证书时了解到的，毕业后在企业里工作，也没见到过产品经理这个岗，也或许是没注意吧。
就是说，做需求的人必须具备程序的底子（程序员），还必须会做底层的系统架构（高级程序员、软件设计师），尤其是对公司已存在系统架构要熟记于心，否则，就会像现在的产品一样，要么乱改需求，要么做出来的东西没法实现，要么提供的需求不去想未来的扩展。
2010年之后的分水岭，C端客户与B端客户，产品经理与系统分析员
C端客户重体验，体验不好，就会存在大量的客户流失，这是产品的活；
B端客户重效率，用户体验和特效再好，工作效率受损了，一样不会用，这是系统分析员干的活。
由于app的兴起，市场上对用户体验的需求大量增加，系统分析员在C端逐渐被遗忘，而相应的工作由产品经理代替。
产品经理自身问题带来的隐患
但，这有一个非常大的问题隐患，就是从事产品的人一般不具备开发和架构的经验，这是导致产品和开发之间矛盾激化的根本原因。
而在中国，产品部门话语权往往很低，大部分需求更改是来自于客户和老板，也就是一拍脑门子的灵感，这种东西对于开发来讲完全是致命的，尤其是需求和特效折腾了几天，又改回原样。
而做产品的人，不会编程，不会做架构，对自己家的系统底层不了解，无法第一时间决定某个功能是否真正能落实在系统中，产品在老板、客户与开发中间夹着，便多了一层沟通成本。
解决两者之间的根本矛盾，是在于决策层。
开发角度看矛盾
而对于开发来讲，最关键的矛盾并不是需求的反复修改，而是需求改完之后工期不变，三个月的工期压缩至一个月，程序员只能通过加班来实现。
一个月的工期改需求占用两个星期，意味着开发时间又缩短一半，搁谁头上都会疯掉。
而产品本来应该承担改需求的责任，最后背锅却是开发，开发抗议，就被产品冠以难管的名义告状，这是开发角度能看到，但产品角度看不到的矛盾关系。
老板、客户角度
对于老板和客户，由于对开发和成本认知不足，普遍认为开发像写文章，写出来之后会越改越好，所以三个月能干的活会压缩到两个月，一个半月。
而系统开发比喻应该是盖高楼，压缩时间意味着质量受损，要盖多高的楼（潜在可扩展的需求），就要挖多深的地基，打多坚固的骨架（系统架构）。
老板要盖两层楼，压缩时间，地基便会只打两层楼的地基，而当需求改为盖十层楼，开发只能把地基全部扒了，骨架全拆散了，重新盖。
盖楼的成本看得见摸得着，改需求的成本看不见，摸不着，全是开发扛。
企业老板或产品经理，如果平衡不好这之间的关系，最先流失的会是整个链条末端的程序员。
