|
不同的大厂与创业团队，对于技术人员而言需要具备极强的机动性、灵活性；在小型的创业团队中不能墨守成规，照搬大厂的规范、流程、制度以及技术架构。另一个方面，也不能因为是小团队就忽略了对于架构、编程规范（如 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 去屏蔽，但是在创业团队中缺颇为考验技术人员的辨识能力。譬如目标和过程的区分。最初我们以为目标是：客户能够用上我们的软件与解决方案，后来发现这只是实现最终商业目
（编辑：桂林站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
