创业团队初期，规则小，对开发人员的能力需求其实很苛刻。然而，能够建立团队的人员无非来自两个方面，要么是新手或其它公司能力稍欠缺的，要么是大公司挖来的（还有一定低几率的野生大神）。
而无论是哪种人员构成，按他们的经验，在面对早期项目开发时，为了快速验证主流程，架构设计特别是组件的技术选型无疑都是采纳熟悉的、主流的、通用的框架。随着功能需求的丰富，就会发现这种通用越来越不能适应业务的变化了，项目的架构反而受到厚重组件的制约?：
1.组件的通用特性几乎用不到，试想对于早期产品来说，比如使用ORM是为了有事没事换数据库好玩吗？
2.组件的可替代性低，基本上一旦使用，调用代码的风格会和自有代码紧密结合。再想更换成本相当高。
3.组件的bug影响了项目的质量，?如果是开源的组件或许还能通过自身努力修复，当然有多少人使用第三方开源组件还乐意去研究源码还是一说，如果是?闭源乃至商业组件，那真的是尴尬，项目bug的修复还得等待一个不可知的因素。
因此，对于小型创业团队，真正要想达到技术稳健，灵活支持项目变化的程度，就必须勇于从开发团队的内部进行变革。其实不是非得采取什么惊天动地的手段，最容易想到也最可行的方式就是对严重依赖的第三方的组件逆向微创新（开源组件可二次开发，闭源则完全自行开发）逐步替换掉不可控的环节，为项目组件压力减负。这里有两个关键点：逆向和微创新。
逆向：体现在对组件设计做减法，在了解组件对于项目提供的作用后，去除掉不需要的部分 ，降低通用性以换取组件运行效率的提升和复杂度的降低。
微创新：体现在对组件中有利于业务的特性要强化和放大，适当地牺牲设计规范的要求，能提供控制的果断要暴露充分，能减少配置的地方多提供配套和便捷的接口。
实际上，我们团队在公司创业初期的研发工作中，根据这个思路在自主研发组件上贡献了数个内部共享代码库，从产品上积累了一些技术收益。我想，如果逆向微创新的意识提炼到方法论的高度，将成为创业团队特别是工程技术团队走向成熟的法定之一。