|
我 1998 年毕业，至今工作了将近 20 年的时间。我写了很多年程序，在早期编程的时候，我的领导觉得我是一个适合做团队管理和协调的人，因此我做了很多年的技术团队管理工作。 今天有这样的机会来跟大家做一个 CTO 如何打造优秀技术团队的分享。 优秀的 CTO 需要必备什么样的素质？ 技术团队，一般来说就是分成两个因素，一个是人，一个是技术。 从人的角度来说，很多程序员的终极梦想就是成为 CTO。非技术人员创业，会发出这样的感慨，我们就差一个 CTO了。仿佛他做了一个很好的创意，只要有一个 CTO 就能把这个创意实现，然后就会占据某一个市场份额的多少多少，最终获得成功。 但是实际上，CTO 不能解决所有问题。我觉得 CTO 是一个很宽泛的概念，CTO 应该具备这样的一些特色：
所以，一个公司对 CTO 的要求非常高，既要具备良好的技术前瞻性，又要判断什么时候引入什么样的技术；然后要懂业务，要能够管理团队，要懂得人性。 我觉得这是一个过程，每个人可能都有一个 CTO 的梦想，但是到底能不能成为 CTO 呢？我觉得比较现实的目标是先让自己成为一个技术领导者。 成为一个技术的领导者后，你会产生很多的困惑，好比我之前做技术写代码，感觉自己做的很好，很自信，因为我的技术能力很强。 最后公司可能会赋予你一个管理职责，但是在这个转型过程中，你会有很多的困惑就是：我怎么去发挥我的技术优势？怎么去管理别人？怎么让团队的绩效和我个人的绩效融合到一起？ 成为 CTO 必经的四个阶段 我把技术领导之路总结了四个阶段：野蛮生长、分组而治、救火队员、无为而治。 野蛮生长 一开始，你带一个很小的团队，在这个团队里你表现很出色，也有一定的沟通能力，你就会被委以小任去管理这个小团队。 这个时候基本上你就是这个小组的组长，然后你的技术也很强，所以你会承担一些培训新人、去和其他组去做沟通的工作。实际上这个管理起来比较容易，而且你的核心能力可能还是体现在编程上。 在这个小组内，你的编程水平，包括你的代码量都会保持一个很高的水准，我觉得这是一个野蛮生长的阶段，不需要太多的管理。 分组而治 在一个小组里面，你做的很出色，公司就会给你更多的工作，让你承担更多责任。有的时候，一个出色的程序员可能可以顶十个程序员。 当然这也是在管理过程中，要避免的，就是有时候在一个公司如果某个人特别出色，公司就会给他更多任务，不仅累得半死，而且工资绩效也没有相应的提升。 比如说你管理团队的十几个人，这时候你可以做的事情就是把这个团队分成两个小组。管理上有一个原则，就是一个人最多只能直接面对七到十个人。 如果你已经管理二十多个人，这时候你就要把它拆组，因为你不可能直接面对这么多人，而且还要跟他们去做交流，去规划这么多人的工作。 这个时候，你可以把整个团队分成两个小组，你自己带其中一个组，然后你再提拔一个组长带另一个组。接下来你的工作，就是给自己组成员分配工作，然后定期和第二组的组长进行沟通，保证整个组的运作方向是没有问题的。 救火队员 当你管理的人员更多的时候，即管理的人员到了几十个那么多。 在初期会有一个演化过程，一般你会自己带一个组，你在这个组里面还是编程，管理这个组的任务，然后你可能会再设其他的三四个小组，你自己去面对三四个小组的组长在一块儿去沟通工作。 在发展的过程中，你会发现你已经没有精力去管理自己的组。最终你就开始直接面对各个组的组长，你不再去承担一个组的领导任务的时候，那你可能是一个部门经理了。 这时候你可能要管理四五个组，直接面对四五个领导。但是你仍然是对公司的技术体系最为熟悉的一个人，因为整个的公司技术体系，你是从一个小兵开始建设起来的。 我觉得这个阶段，你就是去当一个救火队员，你要帮助下面几个组的领导，去搞定他们的工作。 无为而治 这个阶段基本上就是到了研发总裁或者是 CTO 这个职位。 你已经不再关注自己的技术是不是公司里最强的，你的技术能力和你的管理能力等等已经融合在一起。 你会去关注一些更大的层面，公司未来的技术是什么？整个互联网未来的技术是什么？我们要在新方向去做哪些投入？你可能会和CEO去沟通这些问题。 在这个阶段，你需要为整个部门或者为整个公司的技术定出方向或规则，然后让这些优秀的技术人员，在这个规则和方向里面，去发挥自己的聪明才智。 实际上，如果未来你成为一个公司的领军人物，我觉得很多时候，我们需要思考的问题，不是我们做的太少了，而是我们管得太多了？ 到现在这个时代，我觉得每一个人的聪明才智都是可以发挥出来。我们不一定非要把所有的事情都规划好，然后去让他们做一个执行的人。 如果你成长到这样一个阶段，我觉得就要注意去发挥更多聪明人的力量，并不是仅仅靠你自己的力量，因为你不是最聪明的，你可能只是对全局的把握、对整个的走向会更了解一些而已。 CTO 如何组建技术团队？ 组建团队，实际上要有两种方式：一种方式就是从头开始做，另一种方式就是空降。 从头开始做 从第一个人开始招，我觉得这实际上对于我们个人能力和团队的稳定性是一个非常大的考验。这样的团队，如果把它建立起来以后，实际上是非常稳定的。每个人都是你的兄弟，是从战火里厮杀出来的伙伴。 针对这种情况：到了团队里面，你会觉得整个团队的气氛非常腐烂，或者每个人都说，你为什么要来这个公司？然后说谁谁都走了，你怎么还不走？弥漫着这样的公司氛围，你就会有这样的想法，公司为什么不给我涨工资？ 如果你到了一个好的团队，你会发现团队的管理者虽然走了，但是大家还是非常坚定，希望在这个公司做一些事情。 我建议的处理方式就是：对公司充满抱怨的人，就迅速让他离职，然后把公司现有的技术资产保护好，让原先的那些有价值的技术能够继续发挥作用。 面对消极的员工，如果他觉得公司不好，或者说他去意已决，让这样的人尽早离开。把这样的人清理走了以后，迅速重建团队，这样团队就会鲜活起来。 空降 空降会面临两种情况，一种是团队已经很差了，就是一个烂摊子，需要你来解决问题。还有一种，就是这个团队很优秀，你的前任由于其他种种的原因离开了这个公司，所以需要一个带头人，来把整个团队带起来。 针对这种情况：你会发现这个团队本身精神面貌很好，但是因为你的前任走了，组员会有一点失落，或者说觉得公司不受重视等等这样一种情况。 这时候，团队一般会保留很好的机制，对于团队的技术语言、技术的选型，包括团队的组织，都会是一个比较完整的情况。 这种情况下，最不应该做的事情就是新官上任三把火，把团队的机制按照你自己的思路重新打造，包括去用你自己熟悉的技术战略去改造整个公司的产品，我觉得这都是非常忌讳的事情。 因为作为一个技术管理者，大家都喜欢用自己特别熟悉的技术，我觉得这是每个人的人之常情。但是做到一个优秀的技术领导，应该把胸怀放更开一点。 如果这个团队很优秀，他们用的技术战略你不熟悉，那你可以学，你不一定要去强制别人改变。 实际上在遇到这样的团队的话：你只要保留他原来的机制，再逐渐根据公司的发展去调整。对于原有的技术战略也是一样的，缺少哪些，你就补哪些，而不是去断掉他的根本。 从技术的角度分析团队建设 对于一个公司，尤其是对于一个创业公司来说，我觉得用好当下的这些技术，就是最好的选择。 作为程序员，我们有时候会忍不住去追求一些新的技术。因为你会觉得一些新的技术出来以后，如果不懂，跟别人交流你都会觉得低人一等，然后就会特别恐慌。 实际上，很多时候我们去追逐各种各样的新的东西，是为了消除我们自己的焦虑感。 但是在一个公司里面，尤其是一个创业公司，你最终要实现的就是公司的盈利，公司就是要赚钱，要用户，所以用什么样的技术能解决当下的问题，我们就用什么样的技术。 对于创业公司来说，用好当下的技术，我觉得是一个最好的选择。当然成长过程中，你需要做一些新的规划。你要去寻找新的方向，就不局限于一个原则。 技术最重要的是支撑现有的业务发展。技术一定要驱动业务，最终用业务来赚钱，或者是找到足够多的用户。我觉得这是一个技术人员要非常明确的一点。 推送系统 每一个手机厂商都会有推送系统。比如说我们可以按照用户画像，给用户去做推送，可以推送实时的消息，手机在线的时候，用户接收到这个消息。 如果没有接收到，这个消息就损失掉了。还可以推送离线消息，只要手机上线，就能收到消息，但是，这个消息可能只会在消息端保持一天或者两天等等。推送的精准度可以达到 99.99% 以上。 规划产品 一定要有长远的打算，现在，在一个迭代里面，多长算长呢？ 不管是创业公司，还是成长中的创业公司，我觉得一年到两年的时间，就可以了。因为你会发现，你规划产品，可能还没做完，你的公司就已经死掉了，这是非常有可能的。 所以，这个产品一定要有规划，然后在迭代的过程中不断去修正它。实际上，我们基本上很难规划出三年以外的产品，因为这个世界变化实在是太快了。 比如三年以后，VR 会发展成一个什么样的样子，会不会取代手机等等？我觉得这是不可预知的一个事情。 好的成熟的技术，要尽快引入。追求新的技术和求稳之间要有一个平衡。同类型的技术，在不同的应用场景下的使用。 要重构代码，而不是重写代码。程序员最喜欢重写代码了，因为重构总是会耗费我们更多的精力，但是哪一个更值得？ 我觉得大部分的时候，我们去重构代码，更有利于我们自己产品的迭代。因为一旦重写完了以后，会发生什么样的事情？ 这一点我们是不太知道的。而且对于程序员而言，他就像一个诗人，或者像是一个作家，文章永远是自己的好，代码永远是自己写的好。然后在没有代码的时候，总是会觉得别人的代码比较烂。 而且我们自己本身也在进步，在进步的过程中，我们自己的代码质量也会提高。 有一次我在部门里面，有一个程序员跑过来说这个代码写的太烂了，他必须要重写，你不让他重写，他会给你拼了。我说这代码谁写的，然后往上翻一看，是他自己半年前写的一个代码，最后，他说那要不我们重构一下吧。 所以，这个是需要程序员自己去考虑的一件事情。实际上在重写完之后，需要大量的测试，如果你的接口有变化，需要大量的测试才能满足系统的稳定性。 要把变化集中在某一个领域，而不是散落在系统的各个地方，这是架构师的一个原则。 CTO 管理工作中的三个原则 最后再跟大家分享三个原则，这是我自己工作中常常会遇到的三个原则：闭环原则、谁难受，谁推进原则、Think Bigger原则。 闭环原则 作为一个管理者，这是非常重要的。你应该起到上传下达的作用，你要让上面的人知道你要去做什么，然后也要让你的下级知道你正在做什么。如果是做一个普通的程序员，或者是个执行者，我觉得这一点也非常重要。 这个说起来是一件很容易的事情，但是在过程中，你发现能做到这一点的人，非常的少，你可能要不断的训练他，他才会做到这一点。 比如说你开一个周会，开完周会以后，你发现有四件事情要做，本来你写了一封邮件，第一件事情谁应该负责，第二件事情谁应该负责，第三件事情谁应该负责，第四件事情谁负责，然后你抄给所有的参会人员。 但是到下次开会的时候，你发现这四件事情中有三件事没有人给你反馈，有可能是做了，有可能是完全没做。我觉得程序员有时候都不太喜欢反馈，要做一个事情他默默的就给你做了，然后也不告诉你做没做，永远是这样。 但是反馈这件事，其实是非常重要的，如果有这样的一个反馈的话，你会完全的形成闭环，你会知道自己的进度。 尤其是当这个闭环还要往外延伸一下的时候，还可以延伸到产品上面。你做了一个产品，你把这个产品扔到市场上去，谁来给你反馈，这个市场的反映是什么？我觉得这也是需要大家考虑的一个问题。 实际上，一个好的产品，扔出去之后应该有自己的数据感知能力，用户喜欢哪些功能，用户不喜欢哪些功能，日活跃量是多少，然后对你的用户很多行为的统计等等。 这是需要产品数据经理，能够拿到这些用户的反馈，然后根据自己的感觉去判断，哪个功能应该加强，哪个功能应该减弱，这是产品的闭环。 如果你希望你的产品扔到社会上去，或者扔到市场上去，它就会自己成长，这是很难做到的。除非是那种百年难遇的产品，比如说微信。 谁难受，谁推进原则 在组织里面，经常会有一些跨部门的合作。这些跨部门的合作，往往是因为公司的一个空白的区域，大家好像都觉得是对方的事情。 但事实上，应该有一个组织者，就是有一个牵头的人，但是我们不能只是去等牵头的人去推动进度，因为他推动起来可能也会比较麻烦。 就举一个最简单的例子：比如说，我们的发布会。在发布会之前，我们一般是需要把所有的产品，包括产品的销售模式、产品特性，还有一系列资料全部都做好。 在上线的过程中，你会发现产品的特性设计页面总是没给出来，那作为技术人员你应该不断地促使设计者尽快地把这个设计提交给我。如果你16号要发布产品了，那在15号，把这些设计稿给你，谁最难受？ 设计同事已经完成任务了，那肯定是这些前端程序员特别难受，因为他只有一天的时间要把这个页面上线，所以他们就要不断地催促。 所以这个原则就是：如果你觉得这件事情不做的话，你会特别难受，那你就应该去主动推进它。这样的话对整个团队合作，或者说对于把整个事情做成，是非常有价值的。但是你主动推进的过程中，这个流程慢慢地可能就会变得合理。 Think Bigger 原则 这是我想的一个词，大概的意思就是从大处着眼、小处着手。就是有时候我们做一个事情，眼光会特别浅的时候，就会看不到一个事情未来的发展。 无论是你写需求也好，编程也好，或者在一个公司创业也好，我觉得再往大里说，就是一个公司的创见，就是创业的见解。你有一个伟大的想法，能够鼓舞着你自己和你团队的人，去往前走。 这是非常重要的，如果这个想法有缺失的话，就会造成我只是来这儿挣一份工资，你并不会和你的团队共同成长。然后你的团队有任何的风吹草动，你可能就会离开，会找一份更高工资的工作。 所以，我希望每个人都能够在自己的岗位上往大方面去想一想，在这个岗位，如果你的部门能拓展到五十人，你会去做什么事情。 如果你的用户扩展到了五千万，你能做什么样的事情，我觉得这是需要大家在埋头赶路的过程中，思考的一些问题。 作者：池建强 |
|
|
来自： jackeyqing > 《项目管理》
