2020年，困难重重，大家一起披荆斩棘；历经坎坷，历经挫折和打击，我们不断加深对行业的理解，融入制造团队，打磨产品，打造更流畅的体验和交付能力。从技术和产品的角度来看，我2020年的核心重点是：研发效率，以尽可能小的技术团队，保证所有产品的按时推出和交付。我们的产品涵盖典型的工业互联网/MES/CRM/电商系统，跨越Web/移动端/小程序/桌面端等多个触点，服务于海内外客户（需要维护跨地域的公有云/私有云和边缘节点）。技术赋能，挖掘驱动业务发展，单点突破与全线渗透齐头并进，相互配合，出奇制胜。我们需要一些产品来打动客户，但如果我们不能为客户提供完整的解决方案，我们就无法获得最好的认可。做时间的朋友：八大系统技术笔记千余条，百万字。学了很多，做了很多，但也忘记了很多，不禁感到迷茫。此时只有我做的几百万字笔记反映了技术路上留下的痕迹：在线阅读：ng-tech.icu/books，书籍托管在Github：https://github.com/wx-chevalier今年我会为每个系列专门写一篇攻略文章，希望能把我的所见所闻，所记录的分享给更多的人。会组装造轮子：模板、库、项目沉淀都经历过不同的大厂和创业团队。对于技术人员来说，需要有很强的机动性和灵活性；在小型创业团队中，你不能墨守成规。复制各大厂商的规格、流程、制度、技术架构。另一方面，因为是小团队，所以不能忽视架构、编程规范（如Lint）、重构（如CodeReview）的持久化，否则随着业务发展迅速增加的技术债务，最终会暴露出它的不足。不足。破坏力。就像《SoftwareArchitecture-Series》中作者对所谓复杂性的论述一样，软件架构的核心价值在于控制系统的复杂性，将核心业务逻辑与技术细节分离解耦；互联网软件系统架构的设计不是一蹴而就的，而是需要循序渐进、连续不断、多次设计的。作为一个创业团队的技术人员，核心矛盾是提高生产力，提高团队的研发效率。我们需要能够发现现有的轮子并快速组装它们以支持业务需求；我们还必须能够制造轮子来完成团队本身的工具和工程。同时，也不能盲目追求新技术。有很多令人兴奋的新技术和新特性，但你也必须考虑新技术本身的不确定性和团队成员的学习成本。下面是一个简单的Web开发示例。wx-fe主题下的项目大概有十几个，典型的包括：m-fe-*系列：微前端工程系统项目，包括前端开发基础脚手架，React/Vue/Node/Electron/Taro以及各种微前端模板。微组件系列：包括Web电子白板、Excel全栈解决方案等系列项目。ueme-*系列：构建用户体验平台的系列项目。这部分笔者会另开专题讨论，这里只介绍笔者代码库的沉淀。杂谈：程序员的职业转型，小团队大团队入行十年，十年过去了，我却一直带着对这个行业的焦虑前行。35的门槛，一直是达摩克利斯之剑；但是回过头来看，至少对于我身边认识的很多前辈来说，在这个时代以IT/编程为敲门砖进入某个行业/领域是一个极好的选择。只要你是一个真正有爱心的人，在日常工作中积累人脉、管理、产业等，一定能够打破事业的束缚，完成蜕变。如果你技术好，不妨进入一些传统行业。只要跨过了行业门槛，就有公平竞争的机会，有了更现代化的产品和研发效率，也有可能进行降维打击。但是，需要强调的是，无论进入哪个行业，都要心存敬畏。没有行业经验的人，看几张PPT就扬言要颠覆行业。你不觉得这是对前辈的不尊重吗？同时，蛋糕也不能做得太过分，这对自己和他人都是如此，反对强迫别人为自己的梦想买单，也反对犯错误。很多人想任意行使自己的权利，却不愿意承担责任和义务。职责变动我从2014年开始陆续参与创业团队的工作，期间也在一家大厂工作了三年。印象比较深的一件事是创业对纯技术背景的同学并不友好，往往技术越强差距越大。比如心态的转变，很多技术出身的管理者往往不适应界面协调这样的工作，觉得好像是在浪费生命。但你需要慢慢从日常工作中抽离出来，为团队保驾护航，行善如水，水利万物而不争；然后慢慢起身，放眼远方，做一些更注重协调，以业务整体绩效为目标的事情。这时候，我们还需要注意团队沟通的技巧。良好的组织氛围是提高团队研发效率的重要保障。就像玩游戏一样，当你想要克服团队和自己的某些障碍时，你需要不断地给予积极的反馈。无论是公司、团队管理，还是自我管理，成就感都是很好的活力棒和路线图；而确保你在日常工作或SideProject中能够获得成就感的前提之一就是将Task分割得尽可能细粒度。另外，研发往往有明确的目标和指标，但在不知名的行业中，指标不易抽取和抽象，目标不断变化；这在大公司经常被PD和PM挡住。但是创业团队的缺乏，对技术人员的识别能力还是比较考验的。例如，目标和过程之间的区别。一开始，我们认为目标是：客户可以使用我们的软件和解决方案，但后来我们发现这只是实现最终商业目标的一个过程，后来我们发现我们需要的过程是建立连接而不是而不是坚持使用软件。竞争意识会损害竞争力，同样对实现目标的痴迷有时会损害执行力。很多你最初以为的阶段性目标，都将成为你想要征服的最高峰。团队构成在小型创业团队中，团队构成不稳定。开发往往具有多重角色，不仅要实现功能，还要处理用户的反馈和投诉，与产品讨论需求，设计讨论界面实现，有时还要修理电脑，安装软件，解决疑难杂症。同时，初创期的产品可能对质量要求不高。用户层次少，即使质量稍差，也是可以接受的。我做的功能没有考虑扩展性，能用就行。技术视野狭窄。整体业务场景少，主要是用技术，很少深挖底层原理和实现。产品的生命周期是不可预测的。一个已经生产了1年或2年的产品可能因为各种原因无法推出。但是，小团队也有优势。人数少的优势，让队伍很容易被压扁。决策层与执行层有直接关系，有时执行层也参与决策。订单下达速度快，沟通成本降低。而作为早期参与者，在经历了艰难的生存期后，更容易成为核心成员。核心代表股份和期权，持股工作充满动力。未来，如果团队能够扩招，核心人员往往是管理者的首选。合适的人才是团队的基石，招聘也是团队长期的任务和挑战；特别是对于技术负责人，他们经常需要承担招聘工作。早期的团队通常是内部推荐或由人领导的。我们应该尽力招聘合适的人才。太低或太高往往会增加团队的管理成本。在第一轮快速扩张后的稳定期，稳定是重中之重。同时注意流水不腐烂，铰链不腐烂。同时，无论团队规模大小，即使没有专门的HR，也要尽可能保证面试过程的正规性，向不同的面试官展示团队的不同优势：氛围好/极客文化/快速发展/行业优势等然而，随着团队的快速扩张，人员扩张本身就是一个熵增的过程，但熵增也意味着混乱和无序。作为技术团队的负责人，他需要不断地重新定位和转变自己的角色。从早期的核心开发人员，到进步的团队协调员，再到团队经理。一个健康的团队应该能够在没有任何人的情况下正常运作；另一方面，如果核心成员发现自己在团队中的位置不可替代，他们需要有危机感，宁愿牺牲一些可用性来换取一些分区的容忍度。技术负责人首先要能够合理划分任务，分离业务型和通用型模块化，尽可能定义清晰的边界和交互接口协议。这样可以将任务打包给兼职/实习生，尽可能优化调度。结语前两天，一位校友写道：人生之路，不似刀光剑影挥舞鲜花，而更像是一首平平淡淡的绝句，错落有致。面对曲折的道路，唯有“柳暗花明又一村”的坚定执着，才能闯过横亘在我们面前的“山河”。国学大师陈寅恪曾说：“唯有这种独立的精神，自由的思想，千百年来祭祀，与天长地久。三明灯，万古灯。”“付出失败的代价。但你要随时切换，比如多年前的失败创业，创业的痛苦不是辉煌热血的死去，而是死去，虽静美却无心赏秋树叶。最后，我想借这篇文章，向我认识或不认识的创业者致敬，送给走在创业路上的朋友们。
