全栈式团队

看到个新闻,雅虎取消了QA团队,工程师必须自己负责代码质量,并使用持续集成代替QA。 同时看到,听微软做数据库运维的工程师介绍,他们也是把运维工程师和测试工程师取消了,由开发全部完成。每个人都是全栈工程师。然而,普遍情况是,全栈工程师太少。

全栈工程师为什么很少?
1.分工太细
以我最熟悉的数据部门为例:
数据抽取、存储、加工、计算、推送、展现每一个部分都是一个团队在负责,再算上运维、运营、产品团队,这条流水线上的分工如此之细,一个人如何才能全部掌握?
2.管理制度
而一个员工就算积极聪明,也不可能把各个团队轮岗一遍。因为,这样的人被认为是不稳定,不定心,无方向。就算大BOSS愿意推进轮岗制度,在一个小团队竞争激烈的环境,又有谁会重点栽培一个注定待不久的成员?
3.责任心
这个自不必多说。
4.恶性循环
如此稀少的全栈工程师,必然被更多的推向管理岗位。当然,如果管理也是一项技能,那么工程师的思维在这一点上导致他们死伤惨重。

现有的全栈工程师哪来的?
1.团队较小时,一个人不得不承担工多责任时锻炼出来的。
2.能力出色,被老板赏识,每次打攻坚战时都被启用。
3.职业规划牛叉,每次换工作都挑战一个陌生领域。

综上,我觉得在现有情况下,大规模培养全栈工程师实在难度太大。

为什么全栈工程师备受推崇?
1.效率!效率何来?减少不必要的沟通,减少扯皮。
2.成本!HR不是一直推崇花两个人的钱雇佣一个人干三个人的活嘛!全栈工程师甚至可以干十个人以上的活。

然而,在现有环境下谈全栈工程师太奢侈,如果分工的大前提不变,组建适当规模的全栈式团队可能更有意义。请注意,我说的是适当的规模。麻雀虽小,五脏俱全。如此,每个团队便有了更高的机动性。团队之间的竞争也不用停留在嘴皮子上了,最终开发出来的产品定胜负。运维不用死守权限,运营不用逼开发干活不管成本如何,产品不会因为不懂技术变成个画页面的,团队也不会因为事故的责任归谁到处找其它团队的麻烦-全是你自己负责的嘛。见多了抢功劳,推责任,扯流程,搞对立的情形;身在其中的人恶心至极,YOU CAN YOU UP NO CAN NO BB.

一旦团队全栈化,那必然会带来工程师全栈化。工程师全栈化,必然带来团队效率的巨大提升。在同一个团队里,同一个项目的成员,你总说这块不是我开发的,找XX看一下,是不是该滚蛋了?我一直认为,随着效率的不断提升,团队应该越做越小,那些拼命堆人去干活并以此为借口去招人的团队,总让我感觉在侮辱IT这门手艺。

发表评论