从大厂到创业公司，管理上需要怎样转变？

你好我是舒超。过去十年间, 我职业生涯的上半段, 于腾讯专注负责微博微群、消息流广告、视频评论等社交型业务系统, 下半段, 在美团基础架构投身负责云原生基础设施的演进工作, 当下, 于星汉未来担任CTO, 负责公司产研推进工作。星汉未来的加入时间点很好记, 是2021年12月31日。要说这个时间呢, 它是我从大厂迈向创业公司的一个交界时刻, 在切实接手星汉未来的工作以后, 我察觉到了, 大厂跟创业公司在技术管理层面的差异是相当大的。故而就在今天, 我要来讲一讲, 从大厂到创业团队, 在技术管理上所面临的变化以及应对的策略。创业公司与大厂的差异星汉未来身为一家创业公司, 超八成员工往昔皆是字节、快手、微博等互联网大厂基础架构部门之研发人员。众人由大公司转至小公司, 于认知以及做事方式方面会存有大公司之印记。譬如有:对项目计划稳定性有着较高预期, 若预定交付内容以及交付时间被打乱, 将会明显影响状态与情绪。做事具备较强的边界和范围意识, 负责A模块时天然地不关心B模块的问题。对流程制度有较深依赖, 期望在各个环节都有相应规范以及责任人, 一旦出了问题就想要一套制度来填充。所有皆知悉的是, 刚才所提及的那些探究及开发从业者的特性, 乃是于某个具备业务平稳、人员数量繁多且部门设置齐全的背景状况下, 通过按照既定标准来推进企业运转这种管理模式所塑造而成的。我曾经就职过的美团以及腾讯, 同样也形成并积累了诸多管理观念、管用办法以及程序规章。而创业公司这些前提都不具备。比如启动那会儿, 目标客户或者市场需求, 根本就没经过验证, 甚至是模糊不清的, 这般状况必定会致使项目计划, 以及交付日期频繁地迭代。人力方面肯定是不足的, 常常是一个人当做一个半个人, 甚至两个人来用, 今儿做A模块, 明儿做B模块, 那么模块或者组件到底是谁的, 特别不容易区分。这个公司里主要的人员角色划分, 除了产品、研发这类大的类别, 就连前端、QA还有其他环节, 不是缺失就是兼任, 所以大厂的一个基本制度流程, 在创业公司实际可能就只是经手1至2个人, 几句话就能说完, 而且很可能明天就会有新的变动, 所以没必要为这个去建立制度。应对策略总归而言, 变动繁杂、速度迅猛、物资稀缺乃是创业企业的常见情形, 并且我们所采取的管理举措也必然依据这三项关键实情来施行, 至于怎样使处于创业阶段的公司能够“小幅度快速行进”, 这是管理者所肩负的重大职责。接下来我要进行一番分享, 是关于我加入星汉之后在管理层面的一些计策。研发分层首先, 创业公司研发人数虽有限, 却仍需分层管理, 在初次引入新成员时, 就要有意进行区分, 当前星汉的研发大致分为三层:一线研发的同学, 技术能力很强, 然而资历比较浅, 是那种喜欢钻研技术的人。架构师, 具备代码以及架构设计能力, 有一定业界视野。技术人员, 有能力, 并且有眼界, 还懂得团队管理。那么在创业公司对这三个层级的员工要提出什么样的要求呢一线所进行的研发工作, 最为关键的要点便是执行力, 要把那朝着实地化作行动的执行效率, 以及执行质量, 全都达成至高标准的极度, 从而变作公司战略所依靠的在最前方的支撑力量。架构师团队的主要职责在于, 不让客户那突如其来的需求, 直接对研发产生震荡, 架构师会先去做缓冲, 以此探寻可行性, 在搞清楚大概的技术方案之后, 再将其切分成较细的模块, 或者把动作传递给一线研发。所以, 整个震荡的节奏、频次以及复杂度, 都被架构师这个缓冲层给消化掉了。除去创业团队必备的技术能力与管理能力不说, 传递公司决定时, 传递客户需求时, 一定要将具体原因和要求跟整个团队同步得明明白白, 做到信息透明, 与此同时, 尽量给员工手上工作的收尾以及切换留出合理的时间。鼓励员工做全栈创业公司存在基础职能划分, 像产品这条线、研发这一环节、市场这一方面、社区这一板块等, 不过呢, 于实际开展工作进程当中得要迅速获得成果, 快速进行试错, 就基于这样地追求目标, 或许会出现研发直接操办了属于产品该做地事儿, 又或者市场去做了本应由社区负责地事情。这于创业团队而言是极为平常的操作, 鉴于人手着实有限。解决此问题存在两种方案, 其一为扩充人手, 其二是拓展员工的能力。但因资金问题方案一常常难以达成, 此时于管理方面, 能够朝着拓展员工能力的方向尽力, 激励员工们去做全栈。比如说, 当处于客户环境之中, 项目负责人针对一个压测功能展开验证工作时, 察觉到了产品未曾顾及到的状况, 于是没有任何迟疑地更换了压测算法。再来举例说明, 市场人员在面向客户订单发起攻克行动的期间, 发觉某个功能点的确具有一定价值然而客户在付费意愿方面表现得并不充分, 所以就将其放置到社区进行开源操作, 以此当作甜点去吸引流量从而导向商业产品。上述这些行为均超出了他们自身原本所具备的职能范畴, 不过却都对公司的成长有着积极的促进作用, 因而都是值得被予以肯定的。对于创业公司的员工来讲, 如果自身所拥有的自驱力足够强大, 实际上是能够广泛涉猎众多领域的, 这对于个人成长而言同样有着颇为显著的助力作用。所以, 我极为鼓励前端领域的人员以及后端领域的人员, 还有QA方面的人员, 甚至架构师这类人才, 在搞好自身本职工作之际, 敢于突破自身那有限的工作范围, 前往其他工作范畴去“品头论足”。比如说前端人员协助QA去调研自动化测试框架, 以此解决产研交付过程中QA所遭遇的卡点阻塞问题而后端人员在前端人手短缺之时也会担负起前端的工作任务, 进行全栈式的研发工作。如此一来就算人力存在限制, 也能够出色地达成任务, 与此同时还能够将人员的价值发挥到最大程度。管理者如何鼓励员工做全栈首先, 我们得在团队内部去倡导这般精神。接着, 要鼓励员工跨越既有领域。然后, 促使其横向往外拓展自身能力。最后, 给研发线上的每一个人种下一种意识, 便是全栈全流程之中, 我随时都存在可能要顶上去的情况。在开展任务分配工作之际, 存在一部分边界模糊的任务被允许留存, 旨在给予员工进行尝试的机会, 促使他们能够主动自行开展有针对性的探索。与此同时, 身为执行者身份的我们也不得不肩负起应付的责任, 针对人员“错位”方面极有可能致使的项目风险, 同样也要具备清醒明晰的认知以及拟定对应的PlanB。最终, 于具备条件之际, 我们同样能够于团队内部开展轮岗安排, 特别是针对那些怀有意愿且拥有能力的技术骨干, 借由轮岗制度促使他们更多地掌握一门技术, 涉猎别的一些领域, 这对于企业人才培养以及员工的个人成长而言是极为必要的。重视POC的反馈未与市场达成最佳契合点PMF时, 创业公司的产品基本不能被视作成熟实际上即便达成之后也未必就算成熟, 所以即便前期历经了周全的市场调研, 或者原型思路在大厂生产环境中得到了验证, 后续到客户现场时, 依旧难以避免地会出现不匹配、不兼容以及未考虑到的各类问题。这属于正常范畴, 并非归咎于任一个别的特定环节的责任。此时客户现场的那项目负责人也就是所谓的POC, 实则是处于“能听闻炮火之人的情形”, 他们直面着客户或优或劣的反馈。并且他们还是对产品颇为了解之人, 因而他们的意见具备相当重要性, 对待他们意见的重视程度以及响应速度, 直接判定着此客户能否被搞定, 以及搞定该客户的速率, 甚至客单价的高低状况。理想当中的POC人员配备, 乃是由产品、研发以及销售共同构成的“铁三角”情形。因为星汉在前期的时候, 人力处于紧缺的状况, POC暂时是由研发线人员来进行代理的。不过, 由于研发和POC在节奏以及日常任务方面, 存在着显著的差异, 所以, 从组织建设这个层面来看, 我们把它划分成了常规产研和POC驻场交付这两条线。POC线所反馈出来的Bug以及需求, 其优先级会远远超越产研线的非针对客户的需求。和产品落地有着关联的定制化需求, 首先会由POC线在现场承接并展开研发工作, 只有那些具有规模化价值的需求才会转交到产研线于此同时, 产研线的某些初步方案以及demo, 也会被交到POC线, POC线负责将其呈现给客户从而进行快速试探以及获取反馈。两边会协同开展联动, 以敏捷的方式进行配合, 一步一步地把设想里的产品形态朝着现实的商业交付物的方向去引导, 以此为公司创造价值。小结终归而言, 创业公司跟大厂于管理方法方面存有一些显著的不同之处, 创业公司惯常的状况是变动繁多, 节奏迅速, 资源紧张程度高, 我们要依据这些特性, 去调整管理战略。关于研发工作, 要实施分层管理, 其中一线研发着重于执行力以及代码能力, 架构师既要兼顾代码能力, 又要具备架构设计能力, 技术管理者得达成信息透明化这个要求, 以此减少信息差。当处于人力紧缺状况时, 要鼓励员工去拓展自身能力, 进而成为全栈工程师。另外, 要重视POC的反馈, 还要重视客户的需求。这些便是我自大厂来到创业公司后所体会到的差异, 以及我的管理策略, 期望能够给予你些许资助。思考题实际上对于全栈工程师, 相关争议可谓相当不少, 存在这样一些人, 他们认为变为全栈工程师这件事是极为不易达成的状态, 并且很容易有种才学有限却又四处显摆的情况出现, 另外还有部分人觉得全栈工程师应当大力予以倡导之举, 毕竟我们所处的社会特别缺乏这种类型的专门人才。那么你对于是否要成为全栈工程师这个问题是怎样看待的呢? 欢迎在评论区域留下你经过思索后的想法以及观点, 同时也欢迎你将这节课分享给有相关需求的朋友们。内容来源《技术领导力实战笔记》()