自己闲的时候总是思考一个问题，将来有一天我成为一家创业公司的技术负责人，哪些错误应该是避免犯的呢？人从一种状态到另一种状态的时候，先思考的不应该是如何快速去做，而是如何避免犯一些错误，这就是本文的出发点。
首先为了避免太跑题，先设置一个限定，一个创业团队近期融了一笔钱，需要快速的抢占市场，需要有一个技术负责人（全局负责）来带领技术团队更好的支持业务发展，这个创业团队原来的技术团队人员没有超过 5 人。
这个产品目前融资了，而原有技术团队肯定付出了很多，也许他们技术能力并不突出，也可能听不懂你的技术术语，也没有做过高负载的网站。但是他们肯定足够辛苦，因为一直在默默付出，对待他们要抱着帮助的心态，不要一上去就提出批评或者质疑，不要提扩展性、可维护性这样很虚的概念，而要了解目前遇到了什么难题，你能够坐下来仔细和他们分析，并实实在在帮助解决问题，技术人员都很单纯，你帮助了他们，就会服你，会尊重你。
假如技术负责人不能帮助他们，那就不要去添乱，比如用行政的命令要求他们遵守代码规范，画架构图，进行代码审查，不要有高高在上的感觉，你过来是解决问题的，而不是来生产制度的。
就算你看到了技术团队有很多问题，也要逐步的去优化，因为在现阶段，原有团队是最了解目前的技术组成，不要全部推翻，也不要用新来的人去替代他们，尊重他们，帮助他们，才是最好的方式。
很多公司负责人找技术负责人的一个标准，就是看这个人的人脉，能不能找到很多技术人员，快速搭建技术团队，这个思路其实是没问题的，因为公司负责人需要放权，专业的事情交给专业的人去做，可是假如技术负责人招的人都是原来的朋友、同事，形成家族式技术团队，那么就要警惕了。
首先这个用人成本非常高，招来的人并不完全是因为技术负责人的个人魅力而来的，他需要平衡是否值得，所以高工资成为必然，当然假如确实是高水平的技术人才，这也是合理的。
其次以关系这种方式引进的员工，技术水平肯定良莠不齐，很多人因为和技术负责人良好的关系而进来的，更要命的是技术负责人引进人只是为了证明他的人脉那就危险了，所以技术负责人只要觉得一个人听话，这个人可能就会被引进，而不是以技术能力而衡量了。
另外一般技术负责人的年龄可能不小了，而必然原来的同事年龄也不小了，可能他们原来是技术人才，可随着年龄的提升，他们可能是个“技术管理者”，而失去了编码能力，对于创业团队来说这是非常不好的事情，创业团队其实更需要业务开发人员。
在特定的时间，家族式管理很有用，因为技术人员任何的行为都是建立在帮助技术负责人的角度，所以干劲会很足，对于技术负责人来说就更好了，不用动员，不用讲管理技巧，只要建立兄弟之间的关系就行了，任何事情都能搞定。
假如这些兄弟确实技术能力很强，那么技术体系可能会很好，假如技术能力不强，设计和开发出的东西没有任何的审查，技术负债就会很多，而技术负责人本来的职责不就是掌控技术质量吗？你完全放开，要你何用？
家族式团队很有可能和原有团队产生摩擦，比如原有团队感觉受到了排挤，很有可能处处不配合，而新进团队可能为了有更多的话语权，会抢班夺权，所以这两个团队就为了私利，不会专注于技术，内耗会很严重。
这种事情就很多，比如某个公司，新来的技术负责人带来了自己的团队，并且都是级别很高的职位，而老同事感觉这些人啥都不懂，什么也解决不了，而新来的团队又各种的变革，导致互相利益不平衡，很多老同事走了。
对于一个刚来的技术负责人来说，有许多工作，比如组建团队、了解产品，但更重要的是设计靠谱的技术方案。
首先要了解系统存在的问题，要了解产品未来的走向，要了解技术团队的现状，针对这三点，你需要亲自操刀，设计一个针对目前最优的技术方案。
为什么要亲自呢，因为你是技术负责人，不了解技术问题，就无法进行技术管理，亲自设计了，才能有针对性的去解决问题，将来系统遇到瓶颈，就能更好的优化或者重新设计。不要用各种理由不去做这个事情，在早期这很重要。
其实在创业公司，一般追求小而快的概念，但是很多从大公司出来的技术负责人充满激情，任何事情都想追求专业化，这可能会出现很多问题，这里举几个例子。
存在很多没有意义的技术岗位，比如现在很多产品并没有多少的用户，可非要搞数据挖掘，很多数据通过简单的 Shell 脚本就能解决，可专业的数据挖掘岗位要求并不低，从成本和效益看，并不建议有。
喜欢造轮子，在创业团队，其实应该多用开源的解决方案，现在发现很多公司喜欢自己实现或对原有软件做扩展，假如没有特殊原因，应该用成熟的解决方案，原因第一就是研发成本，第二就是这个开发成本会很长，第三就是稳定性有待考量。
过度设计，就是设计的方案不结合目前的实际情况，考虑的太复杂，所以实现的也特别复杂，和造轮子一样，也存在同样的浪费，其实过度设计到还好，就怕错误设计，比如我原来单位，非觉得 MySQL 性能不好，要加一层 Memcached 缓存，最后设计并线上使用发现后，缓存命中率非常低，白白浪费了大量服务器，损耗了性能，并增加了系统的复杂性。
不要有开发语言歧视，比如前端业务层用 PHP，后端数据层用 Java，性能没有想象的那么夸张，这也是细分岗位的一种缺陷。
专业化的反面其实就是技术负债，上面也只是简单的说下，有很多的最佳实践指导，想表明的就是太专业化是对效率的最大打击（时间、成本等等），我原来也遇到很多类似的情况，这个伤害分为两个阶段，第一阶段就是短期的一锤子伤害，比如说技术方案上线了，浪费了一些时间和成本，但是这个浪费是固定的，可衡量的。第二阶段就非常难衡量了，为早期的决策还债，比如说原来的技术方案上线后，后期开发特别难扩展，维护也非常困难，累计起来是对生产力的极大打击，成本非常昂贵。
关键词就是数量和质量，没有合适的情愿不招。在创业团队，项目一个接着一个，很容易造成一个假象，开发人员不够，所以就大量的去招人，这是非常不成熟的行为，尤其假如这个技术团队没有太强的最佳开发实践，新来的人员可能会很茫然，各有各的开发习惯和模式，会导致 1+1
第二就是重视质量，质量这个词每个人都有自己的标准，我核心的观点就是情愿使用一个技术底子扎实的毕业生，也不愿意使用一个有多年开发经验但无技术底蕴的人。一个没有技术体系的开发人员总有一些瓶颈和不好的习惯，会有很多累。
很多公司负责人找技术负责人的时候，都是求才若渴，目标就是希望这个人去搞定技术事宜，可在头脑中并没有衡量标准，一切都是变化的。
对于一个技术负责人来说，可以天天和他聊，告诉他架构的重要性，人员的重要性，这些确实很重要，但并非必要性，对于公司负责人来说他其实就关注开发速度、稳定性、产出，他并不关心深层次的技术内部是如何运转的。
举个我遇到的情况，原来一个同事去一个公司做负责人，他天天搭基础，优化系统，后来不知道什么原因走了，而产品负责人这么评价他“来这么久一个产品也没上线”。这个例子对技术人员应该很具有打击性。
和技术合作最多的就是产品人员，个人觉得产品人员思维有点发散，做任何事情都比较着急，天天思考这个功能，那个功能；一个简单的数据需求就问技术要不要弄个后台出来。反正一刻也不会让你闲着。
对于一个成熟的技术负责人来说，不能什么都快速答应，因为这是对自己的伤害，第一开发人员就算多一倍也会不够，需求会源源不断的来；第二产品人员很多情况会考虑不成熟，假如你完全按照他们说的去设计，方案会非常复杂，有的时候逻辑性也会显得有问题，会让系统很难有效的持续运转。第三有时候人工完成的时间比开发一个系统完成的时间少得多，所以少开发一些无意义的脚本或后台，比如刚开始产品人员觉得这个数据很重要，过了几天就会突然觉得没用了。
这样的例子很多很多，我的意思并不是不去配合产品人员，而是从自己专业角度出发，给出合理的意见，当然需要避免激化矛盾。
在创业团队，由于开发时间要求特别高，开发人员在评估时间的时候，特别喜欢加上测试时间，等同于拿测试时间完成其开发时间，这是一种非常不好的行为。比如说一个项目开发时间要 5天，测试时间要 5 天。看上去好像开发时间只占一半（开发人员好像很高效），但实际上测试时间开发人员肯定还在开发，给测试人员的是一个半成品。另外开发人员知道有测试人员会测试出问题、会把关，初期的开发质量肯定不高，这种案列见过很多。
所以不要变现的用测试时间弥补开发时间，有可能的话，开发人员自己负责测试，当然这个实际操作起来有困难。
这篇文章有点偏理论，每个公司有其特殊的情况，中心想表达的思想就是先考虑不犯错，然后再考虑更好的改进；在创业早期，追求轻量而不是重量；技术成本非常昂贵，需要效率。
虞卫东，新浪网高级技术经理，前赶集网移动事业部技术总监，主要供职于新浪网，经历所有新浪博客技术演变，有十余年的互动类产品开发经验，熟悉 LAMP 平台 和 Python 的开发，提倡益软件开发理论。
今日荐文
点击下方图片即可阅读
Google开源新算法，可将JPEG文件缩小35%
为了提升开发效率以及让系统更快地响应需求的变化，不管是面向个人消费者还是企业级的应用，都在采用微服务架构。
这次，StuQ工作坊特地请来58集团技术委员会主席——孙玄老师，为中高阶技术人开讲用得到的“微服务架构设计与实践”。上海和深圳的朋友们，抓紧报名啦！前20人特享7折优惠价。具体详戳 「 阅读原文 」惊喜不停！
