20201225:拖垮中小技术团队的 11 宗罪

某人曾说过:“What does not kill me,makes me stronger.”

根据周围公司的情况,本文总结了拖垮中小公司技术团队的主要因素。当然,你也可以使用下面的手段,把你现在的公司拖垮(与本人无关),正所谓术高莫用,年轻人,耗子尾汁

外行管内行

大部分公司老板不懂技术,有些老板略懂业务,更多的老板是更懂市场。老板找一个会包装自己但没有做过开发的人来管理技术团队,那位说老板不傻,只能说在他懂的范围内不傻,在他不懂的范围内很多老板看不透彻,让一个没有写过一天代码的人管团队会出现什么情况呢?主要如下:
  • 流程一团乱,不知道用什么流程好或根本就没有流程可言
  • 常常忽略整体设计,没有任何设计思想可言
  • 脱离技术,浮于表面,正是所谓的'White paper' 设计
  • 裙带关系应运生成,因为厉害的技术人才往往有自己的思想,不会随便听从外行的指挥,一定会有矛盾产生
  • 其他…

去大公司挖技术牛人,认为一个人就可以力挽狂澜

许多短期内不缺钱(没有企业真正不缺钱)或刚融了资的中小企业,去大厂挖了几个所谓的牛(luo)人(si)回来,想造航母,养恐龙。不仅挖来的人发挥不了作用,还激怒了一起奋斗的老员工:舍不得给自家兄弟加工资,倒是给外人吃香喝辣的。这就叫:偷鸡不成蚀把米,得不偿失啊。

敏捷或 OKR

敏捷和 OKR 本身都没有问题,都很好也很积极,但敏捷和 ORK 对团队成员的素质有很高的要求。不仅仅是技术能力,还有自我驱动能力,在国内厉害的 master 都去了大公司,并且大公司可以用较长的时间进行团队的训练,促进团队成员之间的协作,敏捷或 OKR 也是需要成员之间合作的,就像走独木桥,很多公司不以为然,从网上找几个流程就用起来了。
其实中小公司的流程都是比较简单的,Leader 的权力也非常大,按常规的迭代出问题的概率要小很多,有的时候就要在快慢、出问题的概率上做取舍。

不遵循人员比例

中小公司资源有限,但也不能忽略人员比例。
让一个人干两个人的活,不难度,没有责任心的人也干不好,如果研发和测试全都由开发来干,估计不会有好的效果。所谓的全栈,大都比较水,写写demo尚可,一但涉及性能、规模级的应用,就捉襟见胳膊了,同时在一客程度上还要考虑重要岗位的B角,但也不能盲目扩张。

“狠”抓技术管理

Leader 一定是技术比较强的,业务和技术都比较强的更好,同时不能使用脱离团队的技术,有一定的规范和流程,如:代码规范、上线流程、一些必要的标准,同时还要兼顾灵活,做好激励,奖惩明确,考勤能没有就没有,十几二十个人,谁怎么样还是知道的。不要以 Leader 自居,应以身做责,起好带头的作用。小团队要有一定的灵活性,同时避免造轮子,不要为了追求极致而浪费时间。

鼓吹创业文化

一般技术人员不可能都是创始人,都是挣扎在温饱线上的同仁,为要深入谈什么理想,你有理想是你的,不是他们的,你可能衣食无忧了,他们还在为吃什么,给女朋友买什么,给家里寄多少钱而发愁。
同时也提醒广大同行们,和你大谈理想、称兄道弟的都是不想多给钱的老板,有多远就离他们多远,永远记住:身体是自己的,时间也是自己的,梦想是别人的,当然你也有你的梦想

按代码行数、bug 数,实行绩效考核

小团队(低于 20 人的)不建议有复杂的考核,大一点的团队也不建议有复杂的绩效考核。不会很客观的,存在很多主观因素,曾经有的公司使用互相打分机制来决定考核结果,也是创新!
代码行数不是工作量的直接体现,也不是工作难度的体现,往往一个关键路径的代码行数是极少的。代码行数、bug 数千万不要做为考核的依据,否则就等着团队解散吧。

苛刻的制度

迟到扣钱、早退扣钱、上班时间监控员工、行政或 hr 耍小手段、见风使舵,
绩效考核面谈扣各种细节……
总之让员工各种不爽,各种心里堵。

中台化

中台真的是大公司玩的。上中台后,流程会比较复杂,各种支撑软件、框架随之而来,7*24 小时不断,或许你的数据量业务量真的不适合上中台,能简单就简单,简单到不能再简单了为止。

极至的 UI 体验

人不多的时候,别追求什么 UI 的体验和效果,不可能做好。也别和大公司比,你永远不知道大公司投入了多少人力,一个简单的 PPT 模板,就有可能是大公司每年投入几十人在做。一个客户端的开发团队可能超过你整个技术团队,
别追求什么极致产品体验,就那几杆破枪、就那几个水平一般的人,没法极致。如果老板连这点智商都没有,你也别跟着瞎折腾了,前面是死路一条。

团队之间勾心斗角

几个团队之间,互相甩锅,都不是自己的问题,如果不是每个团队的问题,那一定是 Leader 的问题了,谁让你是 Leader 呢?你有权力也有责任帮忙处理这些问题。甩锅成风后,就等着吧,会越来越乱的。
(0)

相关推荐