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