创业团队技术Leader应该避免的九大错误

17611538698

webmaster@21cto.com

登录注册

创业团队技术Leader应该避免的九大错误

21CTO

资讯 0 3571 2017-03-25 12:00:47

21CTO社区导读：
此文说的是创业技术团队管理如何组建，要遇到的坑，咋填旧的坑，咋应付互相伤害，如何不给自己挖坑。不论是创业团队和小公司都有参考价价值，尤其对于一些非技术产品老板治下的技术负责人，所谓早看早得利，谁用谁知道。

要成为创业公司的技术Leader或技术合伙人，从自己心理上再不能只是一个单纯的码农。

许多朋友和我吐槽，这些CEO们看见一个认识的程序员、工程师就晓之以情动之以理说服来做CTO，结果失败率非常非常高。

其实不管是在大公司还是小公司，做产品一定是靠一个团队。

优秀的技术团队一定不能有个人主义的氛围。技术leader要思考的不是某个功能模块的代码如何实现，而是优先考虑如果打造一支“短小而精悍”的核心技术团队、如何搭建高可用的技术框架、如何高效打造出优秀的互联网产品。

组建技术团队的正确姿势

如何建立初期技术团队？以下的经验或许有参考意义：

第一，根据技术解决方案和个人做事风格去挑选和掌控团队。

这点很重要。比如有一家拿了天使轮的团队，CEO是从阿里巴巴出来的“女神”，项目启动不到半年，原技术Leader因为各种原因走了，后来急着想拉我替补进来。

我只提了一个条件：“阿里巴巴的文化我不懂，如果我进来，我可能需要按照我自己的风格去管理。”

但是公司的负责人否认了我，说：“CEO是从阿里巴巴出来的，团队我们会自己去带，你只负责写代码和解决技术问题就好了。” 于是我没有往下谈了。

其实这种事情没有对错，这是我个人的做事风格和原则。

第二，前期的技术团队也许谈不上管理，但是基本清晰的组织架构和简单的绩效考核制度必须到位。

第三，前期的技术部门最好用“弹性工作制”来管理。

团队越小越应该实施这样的制度。因为不拘小节、没有时间概念的技术研发工作反而效率更高。

第四，发现“蛀虫”立即砍掉。

我之前带过一支团队，所有技术成员没日没夜的开展着开发工作，大家根本没有时间考虑福利、节假日这些事情（当然、这些东西应该是由公司主动做就可以了）。

有这么一个人，事情还没做好就不断跟我斤斤计较、谈各种条件，多上一个小时都觉得自己委屈，工作紧急时候却偷偷占用公司网络资源下载电影，还经常发出消极的言论、做事慢效率低下。

这种人就像一个“蛀虫”时不时折腾得让大家都不爽，负能量满满，影响他人不说，团队破坏性极大。

于是我立马让他工作交接对其劝退。

第五，技术Leader要引入或者培养自己的左膀右臂。
CEO要有自己的军师和大将，CTO或技术Leader也一样。

第六，团队成员要有责任心、人品好的，而不是要最优秀的、浮躁的。

令我感动的一段经历，团队里有个工程师下班坐车回到一半，就突然给我发微信说，有个事情没做好，问我在不在公司，他要坐车回来重新做一下。

他不是团队技术最优秀的，确实最能吃苦和有责任心的，这是我喜欢的员工类型之一。

第七，技术团队一定要有定期的一对一沟通。

技术团队不论大小，团队里的直属上司一定要有定期的沟通制度。

我也是程序员出身，我知道程序员是以“闷骚”的特点著称。对于长期的低调、苦逼的IT技术宅男，没有定期的心理疏导工作，会出现很多尴尬的问题，不信你认真观察试试。这也是团队磨合的一个重要工作。

技术团队的管理

那么问题来了，初创技术团队需要管理吗？技术团队如何做管理？

老夫掐指一算：当然需要！

尤其是技术团队，只要大于3个人，就必须有管理。这个管理包含：代码管理、项目管理、团队管理等角度。

见过太多失败的案例了，大多数的技术团队出现的效率低、团队一盘散沙、开发没有方向、团队不稳定等问题都是因为缺乏管理或者管理不到位引起的。

如何做好技术团队管理？我没事闲的时候，脑子里总在思考这个问题。

将来有一天我成为一家创业公司的技术负责人，哪些错误应该是避免犯的呢？

人从一种状态到另一种状态的时候，先思考的不应该是如何快速去做，而是如何避免犯一些错误。

为了避免我太跑题，先设置一个限定，比方一个创业团队近期融了一笔钱，需要快速的抢占市场。这时需要有一个技术负责人（已谈好全权负责）来带领研发团队更好的支持业务发展，这个团队原来的技术人员没有超过 5 个人。

善待原有技术团队

这个产品能够成功融资，原有技术团队肯定付出了很多。也许他们技术能力并不突出，也可能听不懂你的技术术语，可能也没有做过高负载的网站。

但是他们肯定足够辛苦，因为一直在默默付出，对待他们要抱着帮助的心态，不要一上去就提出批评或者质疑，不要提扩展性、可维护性这样很虚的概念，而要了解目前遇到了什么难题，你能够坐下来仔细和他们分析，并实实在在帮助解决问题，技术人员都很单纯，你帮助了他们，就会服你，会尊重你。

假如技术负责人不能帮助他们，那就不要去添乱。比如用行政的命令要求他们遵守代码规范，画架构图，进行代码审查，不要有高高在上的感觉，你过来是解决问题的，而不是来生产制度的。

就算你看到了技术团队有很多问题，也要逐步的去优化。因为在现阶段，原有团队是最了解目前的技术组成，不要试图全部推翻，也不要用新来的人去替代他们，尊重他们，帮助他们，才是最好的方式。

整锅挖来一个团队需要慎重

很多公司负责人找技术负责人的一个标准，就是看这个人的人脉，能不能找到很多技术人员，快速搭建技术团队，整锅拉来一个团队，这个思路其实是没问题的。公司负责人需要放权，专业的事情交给专业的人去做。

可是假如技术负责人招的人都是原来的朋友、同事，形成家族式技术团队，那么就要警惕了。

首先这个用人成本非常高。招来的人并不完全是因为技术负责人的个人魅力而来的，他需要平衡是否值得，所以高工资成为必然，当然假如确实是高水平的技术人才，这也是合理的。

其次以关系这种方式引进的员工，技术水平肯定良莠不齐，很多人因为和技术负责人良好的关系而进来的，更要命的是技术负责人引进人只是为了证明他的人脉那就危险了，所以技术负责人只要觉得一个人听话，这个人可能就会被引进，而不是以技术能力而衡量了。

另外一般技术负责人的年龄可能不小了，而必然原来的同事年龄也不小了，可能他们原来是技术人才，可随着年龄的提升，他们可能是个“技术管理者”，而失去了编码能力，对于创业团队来说这是非常不好的事情，创业团队其实更需要业务开发人员。

家族式管理的弊端

在特定的时间，家族式管理很有用。技术人员任何的行为都是建立在帮助技术负责人的角度，所以干劲会很足，对于技术负责人来说就更好了，不用动员，不用讲管理技巧，只要建立兄弟之间的关系就行了，任何事情都能搞定。

假如这些兄弟确实技术能力很强，那么技术体系可能会很好，假如技术能力不强，设计和开发出的东西没有任何的审查，技术负债就会很多，而技术负责人本来的职责不就是掌控技术质量吗？你完全放开，要你有啥用？

家族式团队很有可能和原有团队产生摩擦。比如原有团队感觉受到了排挤，很有可能处处不配合，而新进团队可能为了有更多的话语权，会抢班夺权，所以这两个团队就为了私利，不会专注于技术，内耗就会很严重。

这种事情就很多，比如某个公司，新来的技术负责人带来了自己的团队，并且都是级别很高的职位，而老同事感觉这些人啥都不懂，什么也解决不了，而新来的团队又各种的变革，导致互相利益不平衡，很多老同事就走了。

请先进行技术方案的设计

对于一个刚来的技术负责人来说，有许多工作，比如组建团队、了解产品，但更重要的是设计靠谱的技术方案。

首先要了解系统存在的问题，要了解产品未来的走向，要了解技术团队的现状，针对这三点，你需要亲自操刀，设计一个针对目前最优的技术方案。

为什么要亲自上呢？因为你是技术负责人，不了解技术问题，就无法进行技术管理，亲自设计了，才能有针对性的去解决问题，将来系统遇到瓶颈，就能更好的优化或者重新设计。不要用各种理由不去做这个事情，这在早期这很重要。

不要过度追求专业化

其实在互联网创业公司，一般追求小而快的概念。但是很多从大公司出来的技术负责人充满激情，任何事情都想追求专业化，这可能会出现很多问题。举几个栗子。

（1）没意义的技术岗位

比如现在很多产品并没有多少用户，可非要搞数据挖掘，很多数据通过简单的 Shell 脚本就能解决，可专业的数据挖掘岗位要求并不低，从成本和效益看，并不建议设置这样的岗位。

（2）重复造轮子

重复相同的开发工作，应该多用开源的解决方案。现在发现很多公司喜欢自己实现或对原有软件做扩展，假如没有特殊原因，应该用成熟的解决方案，原因第一就是研发成本，第二就是这个开发成本会很长，第三就是稳定性有待考量。

（3）系统设计过度

另外，很多创业公司存在大量的系统过度设计。

即设计的方案不结合目前的实际情况，考虑的太复杂，所以实现的也特别复杂，和造轮子一样，也存在同样的浪费，其实过度设计到还好，就怕错误设计。

比如我原来的公司，非觉得 MySQL 性能不好，非要加一层 Memcached 或Redis缓存，最后设计并线上使用发现后，缓存命中率非常低，白白浪费了大量服务器，损耗了性能，并增加了系统的复杂性。

其实是代码写的烂，为了Redis而Redis，复杂会显得很牛吗，所以这个行为非常不值得提倡。

（4）技术债

另外不要有开发语言歧视。比如某些公司搞的前端业务层用 PHP，后端数据层用 Java，性能没有想象的那么夸张，这也是细分岗位的一种缺陷。

专业化的反面其实就是技术负债，上面也只是简单的说下，有很多的最佳实践指导，想表明的就是太专业化是对效率的最大打击（时间、成本等）。

我原来也遇到很多类似的情况，这个伤害分为两个阶段。

第一阶段就是短期的一锤子伤害，比如说技术方案上线了，浪费了一些时间和成本，但是这个浪费是固定的，可衡量的。

第二阶段就非常难衡量了，为早期的决策还债，比如说原来的技术方案上线后，后期开发特别难扩展，维护也非常困难，累计起来是对生产力的极大打击，成本就非常昂贵。

招人要慎重

关键词就是数量和质量，没有合适的情愿不招。在创业团队，项目一个接着一个，很容易造成一个假象，开发人员不够，所以就大量的去招人，这是非常不成熟的行为。

尤其假如这个技术团队没有太强的最佳开发实践，新来的人员可能会很茫然，各有各的开发习惯和模式，会导致 1+1 < 2 的现象产生。人一多，分工就要细化，一细化协作就会产生一定的问题，所以招人要控制数量。

第二就是重视质量，质量这个词每个人都有自己的标准，我核心的观点就是情愿使用一个技术底子扎实的毕业生，也不愿意使用一个有多年开发经验但无技术底蕴的人。

一个没有技术体系的开发人员总有一些瓶颈和不好的习惯，会有很多累。

不了解公司负责人

很多公司负责人找技术负责人的时候，都是求才若渴，目标就是希望这个人去搞定技术事宜，可在头脑中并没有衡量标准，一切都是变化的。

对于一个技术负责人来说，可以天天和他聊，告诉他架构的重要性，人员的重要性，这些确实很重要，但并非必要性，对于公司负责人来说他其实就关注开发速度、稳定性、产出，他并不关心深层次的技术内部是如何运转的。

举个我遇到的情况，原来一个同事去一个公司做负责人，他天天搭基础，优化系统，后来不知道什么原因走了，而产品负责人这么评价他“来这么久一个产品也没上线”。这个例子对技术人员应该很具有打击性。

不要有求必应

和技术合作最多的就是产品人员。个人觉得产品人员思维有点发散，做任何事情都比较着急，天天思考这个功能，那个功能。一个简单的数据需求就问技术要不要弄个后台出来，反正一刻也不会让你闲着。

对于一个成熟的技术负责人来说，不能什么都快速答应——因为这是对自己的伤害。

第一，开发人员就算多一倍也会不够，需求会源源不断的来；

第二，产品人员很多情况会考虑不成熟，假如你完全按照他们说的去设计，方案会非常复杂，有的时候逻辑性也会显得有问题，会让系统很难有效的持续运转。

第三，有时候人工完成的时间比开发一个系统完成的时间少得多。

因此，少开发一些无意义的脚本或后台，比如刚开始产品人员觉得这个数据很重要，过了几天就会突然觉得没用了。

这样的例子很多很多。我的意思并不是不去配合产品人员，而是从自己专业角度出发，给出合理的意见，当然需要避免激化矛盾。

不要依赖测试

在创业团队，由于开发时间要求特别高，开发人员在评估时间的时候，特别喜欢加上测试时间，等同于拿测试时间完成其开发时间，这是一种非常不好的行为。

比如说一个项目开发时间要 5天，测试时间要 5 天。看上去好像开发时间只占一半（开发人员好像很高效），但实际上测试时间开发人员肯定还在开发，给测试人员的是一个半成品。另外开发人员知道有测试人员会测试出问题、会把关，初期的开发质量肯定不高，这种案例也见过很多。

所以，不要变现的用测试时间弥补开发时间。有可能的话，开发人员自己负责测试，当然这个实际操作起来开始有一些困难，有了开始就能够适应。