2020-个人技术之路：创业公司中的研发效能与技术赋能

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 去屏蔽，可是在创业团队中缺颇为考验技术人员的辨识能力。譬如目标和过程的区分。最初咱们觉得目标是：客户可以用上咱们的软件与解决方案，后来发现这只是实现最终商业目标的过程，后来发现咱们须要的过程是创建联接而不是拘泥于软件使用这件事。竞争意识损害竞争力，一样达成目标的执念有时反而会损害执行力，不少开始觉得的阶段目标反而会成为你要征服的最高的巅峰。

团队的组成

在创业型小团队中，团队构成不稳定。开发每每身兼数职，不只仅实现功能，常常要处理用户反馈和投诉，还要和产品讨论需求、和设计讨论界面实现，甚至有时要修电脑、装软件、解决疑难杂症。同时创业期的产品可能质量要求不高。用户量级小，即便质量稍差也能接受。作的功能亦不太考虑可扩展性，能用就行。技术视野狭隘。总体业务场景少，技术以使用为主，不多深挖底层原理和实现。产品的生命周期不可预测。作了 一、2 年的产品，可能由于各类缘由而没法上线。可是，小团队也一样具有优点。人数少的优点，使得团队易于扁平，决策层到执行层是直接关系，甚至有时执行层也参与决策。指令下达速度快，沟通成本下降。并且做为早期参与者，在渡过艰难的生存期以后，更容易成为核心人员。核心表明着股份与期权，持股干活更是动力十足。再日后，若是团队可以扩招，核心人员每每是管理人员的首选。

合适的人才是团队的基石，招聘也是团队长久的任务与挑战；特别是对于技术负责人，每每也须要承担起招聘。早期的团队每每是内部推荐，或者以人带人，应当尽可能招聘合适的人才，太低或者太高每每都会加剧团队的管理成本。在第一轮快速扩张以后的平稳期，稳定是重中之重，同时注意流水不腐，户枢不蠹。同时团队不管大小，即便没有专门的 HR，也须要尽可能保证面试流程的正规性，而且针对不一样的面试者展现团队不一样的优点：氛围良好/极客文化/快速发展/行业优点等等。不过随着团队的迅速扩张，人员扩充自己是熵增的过程，可是熵增也意味着混乱与无序，做为技术团队的领导者，须要不断地进行从新定位与角色转变。从早期的核心开发者，到渐进的团队协调者，再到团队的管理者。

健康的团队，应该是离开任何人均可以正常运转；反过来看，若是核心成员发现本身在团队中的地位是无可替代的，反而须要有危机感，宁肯牺牲些可用性，也要换取些分区容忍性。技术负责人首先要可以将任务合理划分，将业务型的与通用型的模块化切割开来，尽量地定义明确边界与交互的接口协议。这样就可以将任务打包给兼职/实习人员，尽量地实现调度优化。

结语

前两日有校友撰文写道：人生之路，不似挥舞剑花那般行云流水，更若一首平仄绝句，错落有致。面对道路的蜿蜒，惟有携着“柳暗花明又一村”的笃定坚守，才能穿过眼前横亘的“山重水复”。国学大师陈寅恪曾说，“惟此独立之精神，自由之思想，历千万祀，与天壤而同久，共三光而永光。”于我的，既要失败要乘早，穷人家的孩子承担不起失败的代价。不过也要随时转换，如多年前一次失败的创业，创业痛苦的并非灿烂热烈的死去，而是将死不死，虽静美却无意赏秋叶。

最后，谨以此文，致敬认识的或者不认识的创业者，也是赠言给身边走在创业路上的朋友。