初来乍到 如何做好创业公司的技术 Leader？

本篇文章4493字，读完约11分钟

当人们从一种状态转移到另一种状态时，首先要考虑的不是如何快速完成，而是如何避免犯一些错误。

本文由我黑马授权的mactalk出版，余卫东&mactalk撰写。

2017年3月，一段新的旅程开始了，我加入了一家新公司，极客科技。每次我来到一家新公司，都需要组建一个团队。二爷在杭州用他的吉他嘲笑我。他花了两年时间努力建立一个团队，并回到解放前。必须从头再来一遍吗？我说，你会弹吉他吗？二爷消失在微信的时间线里。

事实上，每个团队建设都是一个有趣而富有挑战性的新过程，就像春天种树一样。虽然季节和树苗一样，但由于土壤、空气体、养分和果实的不同，每棵小树都以不同的方式生长。这一次，情况就更不一样了，因为产品、技术和设计需要整顿或重建，新产品需要迅速推出，这更具挑战性，也更有趣。

我的朋友们也不闲着。今天，极客榜公开号“谈论建筑”的主编扔给我一篇由作者提交的文章。他说，迟兄，这篇文章可能对你和你的读者有帮助。寄出去。读完之后，我感觉真的很好。这篇文章的想法和思路非常清晰有效，所以我从mactalk开始，希望大家喜欢。

作者简介

余卫东，新浪高级技术经理。和吉吉移动事业部前技术总监。主要在新浪工作。com，经历了新浪博客技术的所有演变，有十多年的交互产品开发经验，熟悉lamp平台和python的开发，并倡导有益的软件开发理论。

以下是正文。

在业余时间，我总是想着一个问题。总有一天我会成为一家初创公司的技术总监。我应该避免哪些错误？当人们从一种状态转移到另一种状态时，首先要考虑的不是如何快速完成，而是如何避免犯一些错误，这是本文的出发点。

首先，为了避免离题，先设定一个限制。一个创业团队最近赚了一大笔钱，需要迅速占领市场。它需要一个技术领导(全面负责)来领导技术团队，以更好地支持业务发展。这个创业团队最初的技术团队不超过5人。

请善待原始技术团队

这款产品目前已经融资，但原来的技术团队一定花了很多钱。也许他们的技术能力并不突出，或者他们不能理解你的技术术语，并且他们没有制作一个负载过高的网站。但是他们必须足够努力，因为他们一直在默默付出，他们应该得到帮助的态度。不要一上去就批评或质疑，也不要提及诸如可扩展性和可维护性这样的想象概念。相反，你应该知道你遇到了什么问题，你可以坐下来仔细分析它们，并以真正的方式帮助解决问题。技术人员都很简单。如果你帮助他们，你将会为你服务并尊重你。

如果技术负责人不能帮助他们，不要制造麻烦。例如，使用管理命令要求他们遵守代码规范，绘制架构图，并进行代码审查。不要觉得高人一等。你来这里是为了解决问题，而不是生产系统。

即使你看到技术团队中有很多问题，你也应该一步一步地优化它，因为在这个阶段，原来的团队是最了解当前技术构成的团队，所以不要完全推翻它，不要用新人来代替他们，尊重他们，帮助他们，这是最好的方法。

有必要小心地在整个罐子里挖一个团队

许多公司领导寻找技术领导的标准之一是查看此人的联系人，找到大量技术人员，并迅速组建技术团队。这个想法其实没问题，因为公司领导需要授权，而专业人士应该做专业的事情。但是，如果所有被技术领导者招募的人都是以前的朋友和同事，并且组成了一个家庭式的技术团队，那么我们就应该提高警惕。

首先，雇佣成本非常高，而被招募的人并不完全是因为技术负责人的个人魅力。他需要权衡这是否值得，所以高薪成为必然。当然，如果真的是高水平的技术人才，那也是合理的。

其次，以这种方式引入的员工的技术水平必须是混合的。许多人进来是因为他们与技术总监的良好关系。更重要的是，技术总监介绍人只是为了证明他的人脉，这很危险。因此，只要技术总监觉得一个人是听话的，这个人就可以被介绍，而不是用技术能力来衡量。

此外，一般技术领导人的年龄可能不小，但原来的同事也可能不小。他们可能是技术人才，但随着年龄的增长，他们可能成为技术经理并失去他们的编码能力。这对创业团队来说是一件非常糟糕的事情，因为创业团队实际上更需要业务开发人员。

家庭管理的缺点

在特定的时间，家庭管理是非常有用的，因为技术人员的任何行为都是建立在帮助技术领导者的基础上的，所以他们会非常有动力，这对技术领导者来说更好。没有必要调动和谈论管理技巧，只要兄弟之间的关系建立起来，一切都可以做到。

如果这些兄弟确实有很强的技术能力，那么技术系统可能会很好。如果技术能力不强，没有对设计和开发的东西进行审查，就会有很多技术责任。控制技术质量不是技术负责人的原始职责吗？如果你完全放手，你需要什么？

家族式团队很可能与原始团队产生摩擦。例如，原来的团队感到被排除在外，很可能在任何地方都不合作，而新的团队可能抢班夺权，以便有更多的发言权。因此，这两个团队不会为了私利而专注于技术，内部摩擦会非常严重。

有很多这样的事情。例如，在某个公司，新的技术领导带来了自己的团队，他们都是高层职位，而老同事觉得这些人什么都不知道，什么都解决不了，而新的团队做出了各种改变，导致了相互利益的不平衡，很多老同事都离开了。

请先设计技术方案

对于一个新的技术领导者来说，有很多任务，比如建立一个团队和理解产品，但更重要的是，设计可靠的技术解决方案。

首先，我们需要了解系统中存在的问题、产品的未来趋势以及技术团队的现状。对于这三点，你需要为现在设计一个最佳的技术方案。

你为什么想自己做？因为你是技术负责人，如果你不了解技术问题，你就不能进行技术管理。只有当你自己设计时，你才能有针对性地解决问题。如果系统将来遇到瓶颈，您可以更好地优化或重新设计它。不要用任何理由不去做，这在早期是非常重要的。

不要过分追求专业化

事实上，在初创企业中，人们普遍追求小而快的概念，但大公司的许多技术领导者都充满激情，希望在每件事上都追求专业化，这可能会导致许多问题。这里有几个例子。

有许多没有意义的技术帖子。例如，现在很多产品没有很多用户，所以我们必须进行数据挖掘。许多数据可以通过简单的shell脚本来解决。然而，对专业数据挖掘岗位的要求并不低，从成本和效益的角度来看，这是不推荐的。

我喜欢造轮子。事实上，在创业团队中，我应该使用开源解决方案。现在我发现许多公司喜欢自己实现或扩展原始软件。如果没有特殊原因，他们应该使用成熟的解决方案。第一个原因是研发成本，第二个原因是研发成本会很长，第三个原因是要考虑稳定性。

过度设计意味着设计方案没有结合当前的实际情况，考虑过于复杂，所以实施起来也很复杂。就像制造轮子一样，也有同样的浪费。事实上，如果过度设计是好的，我害怕错误的设计。例如，我原来的组织并不认为mysql的性能不好，所以它需要添加一层memcached cache。经过最终设计和在线使用后，缓存命中率非常低，浪费了大量服务器，降低了性能并增加了系统

不要歧视开发语言，例如，php用于前端业务层，java用于后端数据层，性能没有想象的那么夸张，这也是细分帖子的缺陷。

事实上，专业化的对立面是技术债务，上面已经简单提到了。有很多最佳实践指南。我想展示的是，过于专业化是对效率(时间、成本等)的最大打击。)。我遇到过许多类似的情况。这种损伤分为两个阶段。第一阶段是短期的一次性损伤。例如，技术方案上线，浪费了一些时间和成本，但这种浪费是固定的和可衡量的。第二阶段很难衡量，为早期决策还债。例如，原技术方案上线后，后期开发尤其难以扩展，维护也非常困难。累积起来，这对生产率是一个巨大的打击，而且成本非常昂贵。

招募人员时要小心

关键词是数量和质量，如果没有适当的措施，我们不愿意招聘。在创业团队中，一个接一个的项目，很容易造成错觉，而且没有足够的开发人员，所以招募大量的人是非常不成熟的，特别是如果这个技术团队没有强大的最佳开发实践，新人可能会不知所措，每个人都有自己的开发习惯和模式，这将导致1+1。二是注重质量。每个人对质量这个词都有自己的标准。我的核心观点是他们愿意使用技术基础。一个没有技术系统的开发人员总是有一些瓶颈和坏习惯，并且会很累。

不知道公司的负责人

当许多公司领导人寻找技术领导人时，他们渴望人才。我们的目标是希望这个人能够处理技术问题，但是他们的头脑中没有衡量标准，一切都在改变。

对于一个技术负责人来说，你可以每天和他交谈，告诉他建筑和人员的重要性，这些非常重要，但不是必须的。对于公司的负责人来说，他实际上关注的是开发速度、稳定性和产量，但他不关心深度技术在内部是如何运作的。

例如，在我的例子中，一个同事去担任一家公司的负责人。他每天都在打基础，优化系统，但后来他无缘无故地离开了。该产品的负责人评论说，他“很久没有推出产品了。”这个例子对于技术人员来说应该是非常引人注目的。

不要给你想要的任何东西

技术合作最多的是产品人员。就个人而言，产品人员的想法有点分歧，他们急于做任何事情。他们每天都在思考这个函数和那个函数；对于一个简单的数据需求，询问该技术是否应该有背景。不管怎样，这不会让你闲着。

对于一个成熟的技术负责人来说，你不可能很快做出承诺，因为这对你自己有害。即使第一个开发商翻倍，也是不够的，需求还会继续来；在许多情况下，第二产品人员会认为不成熟。如果你按照他们说的去设计，方案会很复杂，有时会有逻辑上的问题，这将使系统难以持续有效地运行。第三，有时手工完成的时间比开发一个系统的时间要少得多，所以有必要开发一些没有意义的脚本或背景。例如，起初，产品人员认为这些数据非常重要，几天后，他们突然觉得没用了。

这样的例子有很多。我不是说不与产品人员合作，而是从我自己的专业角度给出合理的意见。当然，有必要避免激化矛盾。

不要依赖测试

在创业团队中，由于开发时间要求极高，开发人员在评估时间时特别喜欢增加测试时间，这相当于花费测试时间来完成他们的开发时间，这是一种非常不好的行为。例如，一个项目开发需要5天，测试需要5天。开发时间似乎只有一半(开发人员似乎非常高效)，但事实上，开发人员仍在测试期间进行开发，测试人员得到的是半成品。此外，开发人员知道一些测试人员会测试问题并检查它们，并且最初的开发质量肯定不高。这种情况很多。

所以不要用测试时间来弥补开发时间。如果可能，开发人员自己负责测试。当然，这在实践中很难操作。

这篇文章有点理论化，每个公司都有自己的特殊情况，中心想表达的想法是先考虑不犯错误，然后再考虑更好的改进；在创业初期，追求轻量级而不是重量级；技术非常昂贵，需要效率。

在这个快速发展的互联网时代，人们总是喜欢快速，希望站在别人的肩膀上，打造自己的建筑。许多开发人员和架构师花费大量时间研究知名公司的企业架构，并将这些材料视为珍宝，但当他们将它们带回家时，他们发现情况并非如此。原因只能说是参考的架构实践太多了，但是了解和理解的架构知识太少了。

道是事物发展的本质规律，艺术是事物发展的具体方式。事实上，《谈论建筑》系列文章就是要向你讲述建筑的方式，希望你能理解建筑的本质，不要拘泥于现有的实践和理论框架，而是用最直接的方式解决问题，不输赢。

来源：搜狐微门户