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，也需要尽量保证面试流程的正规性，并且针对不同的面试者展示团队不同的优势：氛围良好/极客文化/快速发展/行业优势等等。不过随着团队的迅速扩张，人员扩充本身是熵增的过程，但是熵增也意味着混乱与无序，作为技术团队的领导者，需要不断地进行重新定位与角色转变。从早期的核心开发者，到渐进的团队协调者，再到团队的管理者。

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

结语

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

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