开篇先画一下范围:
- 针对小公司和小技术团队
- 技术团队地位中等偏上,作用比较重要,又不是那么重要
- 通常来说没有很核心的产品
比如外包公司,客户当然期望你做出佳作,但实际上也做好了不行就换人的心理准备;或者老板本身不是做互联网的,拉起一支队伍想“赋能”一下自己的行业。总之就是资源不会太多,能做好当然皆大欢喜,做不好背锅走人也不要意外。
这里我主要想和以技术研发为核心的纯互联网产品公司区分开。此时资源都会向研发倾斜,节奏也会跟着研发走,对于技术管理者来说,施展的空间要大得多。
好,相信很多技术同学都有类似的经历:
工作几年之后,自我感觉良好,大部分技术问题难不倒你。突然有一天,某位曾经合作愉快的前同事突然找到你,说有个改变世界的产品,需要一位足够出色的 CTO 来统领团队,想来想去你最合适。
你觉得项目听起来靠谱,也觉得自己有能力接手,然而更重要的是:工作几年,想多接触些管理,但是现在的领导并不打算让贤,公司也没有那么多坑等着你填,这似乎的确是个好机会。
于是你接受了对方的条件,成为这个小型技术团队的领导,公司非常需要你的团队做出好产品,但是你要面临很多不利因素:
- HC紧张,岗位设置很难做到面面俱到
- 业界知名度低,难以招幕到高级人才
- 资金压力大,要求快速迭代、变现,给研发部门自由发挥的空间不大
- 名义上“技术一小步,公司一大步”,但实际上技术并不是绝对核心,至少在几位合伙人的眼里不是。
无论如何,先搭建团队,然后动手开发,活儿总是要干的嘛。大多数同学面临这种情况,会直觉性地选择俩眼一闭,先写代码。毕竟,写了代码才有产品,有了产品才有后面的其它工作。
早期的开发一般会比较顺利,毕竟没有限制,只管做功能就好。但是,随着开发进行,踏踏实实写代码很快变成了奢求,一茬接一茬的问题出现,大家疲于奔命,到处救火,真正的产品优先级反而抛在后面。以我的经验,常见的问题有:
- 出了问题,前后端互相甩锅,前端说是后端的问题,后端说是前端的问题
- 测试人员高高兴兴的测出来一大堆问题,其中一多半可能不是问题,但是测试也需要职业成就感,所以他们宁可错杀一千不愿放掉一个
- 因为缺少回归,做新功能或者改 bug 的时候一不小心就把之前的代码改坏了
- 后端没做出接口,前端开始的时候要等后端,比较闲;后来接口出来了(多半延期),为了项目整体进度,又要赶时间,忙得要死
- 没有测试集,不敢重构,不敢升级依赖,不敢更换系统
- 没有压力测试,市场费用花出去,一波流量涌入,服务器挂了……
- 长期零和博弈导致团队内部关系紧张,内耗严重
早年我也认为这个问题无解。大家只能夹缝中求生存,想方设法把产品搞出来弄上线,寄望产品成功,争取到足够多的时间旧代码,还技术债。用发展解决问题,或者至少延缓问题。
但是我厂工作几年之后,我开始有新的想法。想要保证产品质量和代码质量,同时一点代价都不付出,当然不可能;但是,以优秀的技术产品、良好的流程,在保证产品质量和代码质量的同时,减少付出的成本,使得我们最终能够在项目进度、团队建设、产品质量之间找到平衡点,是绝对可能的。
可惜的是,我暂时找不到能够立刻满足这套需求的产品,所以我决定在未来的一段时间把它整理开发出来,至少能够满足我自己的日常使用。希望这个坑能填上,能够真的派上用场。
发表回复