与师兄之泛谈 2
今晚与师兄两人回校，聊起互联网分工时，师兄不免又多说了许多。说着说着，话题又过渡到人生道路上。因觉得颇有共鸣，这里依旧流水账般，记在下面。
关于互联网分工
产品
个人认为，互联网分工的必要组成部分是产品，产品分PM和PD两种，PM和PD上有产品总监。PD即Product Designer，产品经理。负责具象化用户需求，交给技术去实现。话说起来简单，但实际上，具象化需求不是那么好做的，产品总监提出大体构想后，PM多半会召集身边各部门开会，并去整理会议上各方杂乱的美好设想。首先，总监的构想有时会很模糊，甚至会有方向上的错误；其次，会议上各方的建议并不能覆盖所有细节，尤其是枯燥的细节。毕竟产品做不好是PD背锅。接下来，整合好的具体需求是不能直接拿给技术看的，否则很容易被砍死。PD需要融合、简化需求，减轻技术团队的压力。产品，做出来才是真的。接下来，把任务交给PM。除此以外，PD需要尽量为自己所带领的技术团队争取资源，作为挡箭牌处理和营销以及运维的关系甚至办公室政治，这也是让产品成功的重要一点。综上，PD是个多方受压的角色，一旦失误很容易背锅，同时它也是产品流程的重要一环，把控好产品方向，安抚好烦躁的程序员，着实压力巨大。所以，有句古话说得好，PD常有，好的PD不常有。
PM即Project Manager，项目经理。和PD在互联网产品开发中是多对一（多PD）或一对一的关系。PM需要将需求进一步细化到技术上，拆分成各个部分，交给手下的技术团队完成。同时，PM负责把握工程的时间进度。时间过了deadline是没法交差的。PM不一定得很懂技术，但一定得能让技术团队信服（虽然大多数的PM都很懂技术）。否则，手下心不齐，三天两头添乱，PM是很不好受的。毕竟产品开发不完，是它背锅。相比PD，PM距离技术更近，也会经常参与技术团队的开发。
营销
产品从设计到原型结束后，交给营销团队推广拉客。营销部门只负责拉客，并不负责接客。因为它的kpi是按照入驻用户数来计算的。营销又称销售，它做的工作和安利很像，负责为产品招揽足够数量的客户。为了保证每月或每天kpi的硬性要求，营销会将产品好的一面，甚至没有的一面展示出来。这里遇到了两个矛盾：第一，为了产品能卖得更好，营销部门会向PD施压，改变产品需求，使得更种各样的用户都能入驻。万一这时PD不够“硬”，技术团队就要砍人了。第二，营销的kpi不包括客户流失率，毕竟不是它负责接客，不负责任的拉客和承诺很容易招揽垃圾用户和愤怒的用户，这就要考验运营部门的智慧了，它要努力把人留下来，并用甜美的笑容迎接客户的怒骂。可见，运营部门也是个很考验心理素质的地方。
运营与技术
营销说完了，下面是运营。运营的KPI包括客户流失率。上面说过，用户反馈的所以负面意见90%都由运营部门的客服来扛着。产品当然不会做出的第一版就很完美，因为用户是不会接触到产品原型开发的。运营吃的营销的亏，会扔给产品和技术。埋怨产品是怎么设计的，并向PD施压，要求改变产品需求（这话听得怎么那么耳熟），因为用户反馈blablabla。这时，重复修改是无法避免的，PD再调整，PM下的程序员免不了做重复工作。如果调整得不好，技术砍死产品经理就会发生。
技术分两种。第一种是学术型技术，多半不会和产品、营销、运维三个部门一起提，即真正的技术。它是埋头做的，不一定短时间内就会生效的。大公司里会分成专门的部门。第二种是工程型技术，和产品在一起提到，很多互联网公司会有“技术池”这个概念，即程序员们的工作并不固定，自己自由选择或分从分配到某个产品线，和某个PD合作。
综上，我们看到，产品、运营、销售是三个相互坑与被坑的角色，矛盾统一的是它们的目标一致——这个产品的前景。换句话说，它们是一条绳上的蚂蚱，相互间痛并快乐着。高工资不是白拿的，它们的压力透过文字就可以辨别出。
关于悲惨的程序员
程序员的悲惨，其实是不需要这段文字就能看出来的。对需求的重复修改是程序员即普通技术的噩梦。技术（以下均指普通技术）的KPI是按照需求数量来计算的。PM把需求分解，按照难度打分后，交给技术完成，很像完成成就。如果PD或PM的功底不够，产品细化的不够狠，技术的KPI就会比较难看。这还不算悲惨。如果PD不够“硬”，产品原型还没出来，就被销售改了几个需求，技术的开发工作就会重复进行，而新的实现方法是不计入KPI的。不计入KPI倒可以忍，改得晚，deadline就在眼前才是最要命的。实际上，程序员加班并不是工作量大，而是重复工作太多了。而PD里有许多应届，出色的PD少，这也就成了业界程序员的常态。
产品推出后，运营也加入了挤压产品、技术的队伍，技术又会针对客户的反馈进行修改。大家也猜到了，这个修改也是不计入KPI的。如此多的工作，却对KPI毫无贡献，悲惨的程序员该怎么想呢？呆不下去就走呗！这也是互联网离职率高的重要原因。
以上讲了技术跟错了产品和产品经理的悲剧。好的产品新修改多，重复修改少，KPI高，年终奖拿到手软，不好的产品线注定会多处很多重复修改，却，见不到用户量的大提升。如果我们隐忍的程序员还没有放弃，产品线终于崩溃了。这时，技术面临两种命运，一，等着被随机分配到另一个产品线上，用鸟枪法找一个靠谱的产品和产品经理；二，原来工作努力上进，口碑好，被好的产品线挑走，从此人生改变。可见，对于技术来讲，找一个信得过的产品是多么重要；幸运的是，对于产品经理来说，找一个信得过的技术也是很重要的（产品实现不了是它背锅）。说到底，这里做事还是看人。
关于技术的前途
工科学校出身，有技术功底，出去最有可能就是技术了。那该选择什么道路，能避免上面的悲惨命运呢？上面也提到了，说大了，技术无非两种，研发型和工程型。前者强调在深度，后者强调在广度。因此，对于前者，在知识上的精深，对高深技术的掌握很重要，Google、微软中国这样的公司将是理想的归宿，尤其是对于技术痴迷者。若出世没那么厉害，互联网等公司的研发岗也是不错的选择。这一切的前提是，得好好学习。
工程岗，又称技术民工。在知识上的灵活，对多领域的技术掌握、有工程技术实践经验很重要。因为，技术毕竟不能干一辈子。长期来看，管理岗位是理想选择；短期来看，PM是最好的跳板，如果因为产品线大限已到，或是因为其他原因调岗后，能因为之前的经验升任PM。那恭喜，你终于能翻身农奴把歌唱，由被坑的角色，转成坑人的角色了。不过，这个几率在你跟对产品线才会比较大。
看来，说到底，还是得跟对人。