2020- 我的技术之路:创业公司中的研发效能与技术赋能
2020 年,诸多不易,大家都是披荆斩棘砥砺前行;在这一年我在技术、产品、行业认知上也是起起伏伏,在挫折、摔打中不断地深化自己对行业的认知,融入制造团队,打磨产品,构建更顺滑的体验与交付能力。从技术与产品的视角看,2020 我的核心关注点如下:
研发效能,以尽可能小的技术团队保障全线产品的按时上线、交付。我们的产品涵盖了典型的 工业互联网/MES/CRM/电商系统,跨越了 Web/移动端/小程序/桌面端等多个触达点,服务于海内外客户(需要维护跨地域的公/私有云及边缘节点)。
技术赋能,挖掘并驱动业务发展,单点突破与全线贯通齐头并进,以正合,以奇胜。我们需要某些产品点打动客户,但是如果不能给客户提供完整的解决方案,是无法得到最好的认可。
做时间的朋友:八大体系超千篇数百万字技术笔记
天地逆旅,时光飞逝,岁月如梭,年近而立也是愈发感觉有急迫感;每次回顾过去十年的职业生涯,想起自己曾经学过、做过很多,但是也忘了很多,不由地内心惶惑。此时唯有自己做的这数百万字笔记体现了技术一途上留下的痕迹:在线阅读:ng-tech.icu/books,书籍托管于 Github:https://github.com/wx-chevalier
今年我会针对每个系列编写专门的导读文章,希望能与更多的人分享我看到的、学到的、记下的。
既能组装也能造轮子:模板、库、项目的沉淀
经历了不同的大厂与创业团队,对于技术人员而言需要具备极强的机动性、灵活性;在小型的创业团队中不能墨守成规,照搬大厂的规范、流程、制度以及技术架构。另一个方面,也不能因为是小团队就忽略了对于架构、编程规范(如 Lint)、重构(如 Code Review)等的坚持,否则随着业务发展迅速增加的技术负债终会显示出它的破坏力。就如笔者在《SoftwareArchitecture-Series》中关于所谓复杂性的讨论,软件架构的核心价值,即是控制系统的复杂性,将核心业务逻辑和技术细节的分离与解耦;互联网软件系统架构的设计不是一蹴而就,而需要渐进、持续、多次设计的。
作为创业团队的技术人员,核心矛盾是提高生产力,提高团队的研发效能。我们既要能发现现有的轮子,去快速组装他们,去支撑业务需求;也要能造轮子,去完成团队自身的工具化与工程化。同时也不能盲目追新,很多令人激动的新技术、新特性,但是也要考虑到新技术本身的不确定性、团队成员的学习成本。这里以 Web 开发做简单示例,在 wx-fe 主题下大概有十来个项目,其典型包括:
m-fe-* 系列: 微前端工程化系统项目,包含了前端开发基础脚手架、React/Vue/Node/Electron/Taro 以及各种微前端模板。
micro-components 系列:包含 Web 电子白板、Excel 全栈解决方案等一系列项目。
ueme-* 系列: 构建用户体验中台系列项目。
这部分笔者会在单独的专题中进行讨论,此处仅引出笔者的代码库的沉淀。
杂谈:程序员的职业转折,小团队与大团队
不觉入行已有十年,十年苍狗,我却是一直怀着对行业的焦虑前行,35 的槛一直如达摩克里斯之剑;不过回头来看,至少对于身边认识的很多前辈,在这个时代以 IT/编程为敲门砖进入某个行业/领域是极好的选择。只要是真正的有心人,能够在日常工作中进行人脉、管理、行业等等多维度的积累,是肯定能打破职业生涯的桎梏,完成转型的。技术好的,不妨进入一些传统行业。只要跨过了行业门槛,有公平竞争的机会,以更现代化的产品与研发效率,也是有可能进行降维打击的。
但是,需要特别强调的是,无论进入哪个行业,必须心怀敬畏;毫无行业经验的人,看了几个 PPT 就扬言要颠覆行业,不觉得是对于前人的不尊重吗?同时不能太过画饼,于己于人皆是如此,反对强行让别人为自己的梦,或者错误买单。很多人既要独断专行的权利,却不愿意承担责任义务。
职责的变化
我从 2014 年开始一直陆陆续续参与创业团队的工作,期间也在大厂工作了三年;颇有感触的一点是,创业对于纯技术背景的同学并不友好,往往技术越强,落差越大。譬如心态的转变,很多技术背景的管理者往往会不适应类似于接口协调这样的工作,觉得似乎是在浪费生命。但是需要慢慢地将自己从日常工作中抽身出来,为团队保驾护航,上善若水,水利万物而不争;然后慢慢起身远眺,做更偏重于协调,以业务整体绩效为目标的事情。此时在团队沟通上也需要注意技巧,良好的组织气氛,是提升团队研发效能的重要保障。就像玩游戏一样,对于团队、对于自己,想要翻越某些藩篱的时候,需要不断地给予正向反馈。无论是公司、团队的管理,还是自我管理,成就感都是非常不错的活力棒与路标;而保证自己在日常工作或者 Side Project 中获得成就感的一种前提,就是尽可能细粒度的切分任务。
此外,研发往往有明确的目标、指标,但是在未知行业中,要提取、抽象出指标却并非易事,并且目标也是不断的变化;这点在大公司中往往是由 PD、PM 去屏蔽,但是在创业团队中缺颇为考验技术人员的辨识能力。譬如目标和过程的区分。最初我们以为目标是:客户能够用上我们的软件与解决方案,后来发现这只是实现最终商业目标的过程,后来发现我们需要的过程是建立联接而不是拘泥于软件使用这件事。竞争意识损害竞争力,同样达成目标的执念有时反而会损害执行力,很多开始以为的阶段目标反而会成为你要征服的最高的巅峰。
团队的组成
在创业型小团队中,团队构成不稳定。开发往往身兼数职,不仅仅实现功能,经常要处理用户反馈和投诉,还要和产品讨论需求、和设计讨论界面实现,甚至有时要修电脑、装软件、解决疑难杂症。同时创业期的产品可能质量要求不高。用户量级小,即使质量稍差也能接受。做的功能亦不太考虑可扩展性,能用就行。技术视野狭隘。整体业务场景少,技术以使用为主,很少深挖底层原理和实现。产品的生命周期不可预测。做了 1、2 年的产品,可能因为各种原因而无法上线。但是,小团队也同样具备优势。人数少的优势,使得团队易于扁平,决策层到执行层是直接关系,甚至有时执行层也参与决策。指令下达速度快,沟通成本降低。而且作为早期参与者,在渡过艰难的生存期之后,更容易成为核心人员。核心代表着股份与期权,持股干活更是动力十足。再往后,如果团队能够扩招,核心人员往往是管理人员的首选。
合适的人才是团队的基石,招聘也是团队长久的任务与挑战;特别是对于技术负责人,往往也需要承担起招聘。早期的团队往往是内部推荐,或者以人带人,应当尽量招聘合适的人才,过低或者过高往往都会加重团队的管理成本。在第一轮快速扩张之后的平稳期,稳定是重中之重,同时注意流水不腐,户枢不蠹。同时团队无论大小,即使没有专门的 HR,也需要尽量保证面试流程的正规性,并且针对不同的面试者展示团队不同的优势:氛围良好/极客文化/快速发展/行业优势等等。不过随着团队的迅速扩张,人员扩充本身是熵增的过程,但是熵增也意味着混乱与无序,作为技术团队的领导者,需要不断地进行重新定位与角色转变。从早期的核心开发者,到渐进的团队协调者,再到团队的管理者。
健康的团队,应该是离开任何人都可以正常运转;反过来看,如果核心成员发现自己在团队中的地位是无可替代的,反而需要有危机感,宁可牺牲些可用性,也要换取些分区容忍性。技术负责人首先要能够将任务合理划分,将业务型的与通用型的模块化切割开来,尽可能地定义明确边界与交互的接口协议。这样就能够将任务打包给兼职/实习人员,尽可能地实现调度优化。
结语
前两日有校友撰文写道:人生之路,不似挥舞剑花那般行云流水,更若一首平仄绝句,错落有致。面对道路的蜿蜒,唯有携着“柳暗花明又一村”的笃定坚守,才能穿过眼前横亘的“山重水复”。国学大师陈寅恪曾说,“唯此独立之精神,自由之思想,历千万祀,与天壤而同久,共三光而永光。”于个人,既要失败要乘早,穷人家的孩子承担不起失败的代价。不过也要随时转换,如多年前一次失败的创业,创业痛苦的并不是灿烂热烈的死去,而是将死不死,虽静美却无心赏秋叶。
最后,谨以此文,致敬认识的或者不认识的创业者,也是赠言给身边走在创业路上的朋友。
版权声明: 本文为 InfoQ 作者【王下邀月熊】的原创文章。
原文链接:【http://xie.infoq.cn/article/3c0052a39faec925917132e6a】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论