分类
管理

浅谈小型技术团队管理:问题篇

开篇先画一下范围:

  1. 针对小公司和小技术团队
  2. 技术团队地位中等偏上,作用比较重要,又不是那么重要
  3. 通常来说没有很核心的产品

比如外包公司,客户当然期望你做出佳作,但实际上也做好了不行就换人的心理准备;或者老板本身不是做互联网的,拉起一支队伍想“赋能”一下自己的行业。总之就是资源不会太多,能做好当然皆大欢喜,做不好背锅走人也不要意外。

这里我主要想和以技术研发为核心的纯互联网产品公司区分开。此时资源都会向研发倾斜,节奏也会跟着研发走,对于技术管理者来说,施展的空间要大得多。


好,相信很多技术同学都有类似的经历:

工作几年之后,自我感觉良好,大部分技术问题难不倒你。突然有一天,某位曾经合作愉快的前同事突然找到你,说有个改变世界的产品,需要一位足够出色的 CTO 来统领团队,想来想去你最合适。

你觉得项目听起来靠谱,也觉得自己有能力接手,然而更重要的是:工作几年,想多接触些管理,但是现在的领导并不打算让贤,公司也没有那么多坑等着你填,这似乎的确是个好机会。

于是你接受了对方的条件,成为这个小型技术团队的领导,公司非常需要你的团队做出好产品,但是你要面临很多不利因素:

  1. HC紧张,岗位设置很难做到面面俱到
  2. 业界知名度低,难以招幕到高级人才
  3. 资金压力大,要求快速迭代、变现,给研发部门自由发挥的空间不大
  4. 名义上“技术一小步,公司一大步”,但实际上技术并不是绝对核心,至少在几位合伙人的眼里不是。

无论如何,先搭建团队,然后动手开发,活儿总是要干的嘛。大多数同学面临这种情况,会直觉性地选择俩眼一闭,先写代码。毕竟,写了代码才有产品,有了产品才有后面的其它工作。

早期的开发一般会比较顺利,毕竟没有限制,只管做功能就好。但是,随着开发进行,踏踏实实写代码很快变成了奢求,一茬接一茬的问题出现,大家疲于奔命,到处救火,真正的产品优先级反而抛在后面。以我的经验,常见的问题有:

  1. 出了问题,前后端互相甩锅,前端说是后端的问题,后端说是前端的问题
  2. 测试人员高高兴兴的测出来一大堆问题,其中一多半可能不是问题,但是测试也需要职业成就感,所以他们宁可错杀一千不愿放掉一个
  3. 因为缺少回归,做新功能或者改 bug 的时候一不小心就把之前的代码改坏了
  4. 后端没做出接口,前端开始的时候要等后端,比较闲;后来接口出来了(多半延期),为了项目整体进度,又要赶时间,忙得要死
  5. 没有测试集,不敢重构,不敢升级依赖,不敢更换系统
  6. 没有压力测试,市场费用花出去,一波流量涌入,服务器挂了……
  7. 长期零和博弈导致团队内部关系紧张,内耗严重

早年我也认为这个问题无解。大家只能夹缝中求生存,想方设法把产品搞出来弄上线,寄望产品成功,争取到足够多的时间旧代码,还技术债。用发展解决问题,或者至少延缓问题。

但是我厂工作几年之后,我开始有新的想法。想要保证产品质量和代码质量,同时一点代价都不付出,当然不可能;但是,以优秀的技术产品、良好的流程,在保证产品质量和代码质量的同时,减少付出的成本,使得我们最终能够在项目进度、团队建设、产品质量之间找到平衡点,是绝对可能的。

可惜的是,我暂时找不到能够立刻满足这套需求的产品,所以我决定在未来的一段时间把它整理开发出来,至少能够满足我自己的日常使用。希望这个坑能填上,能够真的派上用场。

由meathill

爱编程,爱旅游,爱吐槽。
今年的目标是完成并运营至少一个 Side Project。
《Electron + Vue 实战开发》龟速创作中……

欢迎吐槽,请勿装死

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据