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