互联网产品的研发创业潮，印象当中最激烈的时候莫过于11，12年前后，各种基于互联网开创的应用开始逐渐丰富和完善，基于浏览器作为用户客户端，与服务器进行数据交互的主流产品模式开始逐渐成型，于此对应的是一段前端技术理论和应用框架的爆发式发展。
从业之时，初期的互联网创业巅峰期已经从混沌无序开始逐渐形成了成体系的，从代码开发，到应用上线的完整理论，没有经历到更早期的一段被php，jsp，asp所只配的年代，我觉的还是很幸运的。
突然想要写这么一段文字下来，主要源于近年来混迹于各种互联网创业公司的经历，有感而发，感觉就好像又经历了一个互联网产品研发的历史轮回一样。
这两年，接触过，并亲自参与设计，开发的互联网产品也有很多了，掰掰手指头一数，十指也显的有些不够了，而这些经历当中，最让人感触良多的就是时间和创意的竞争。
人多了，社会结构复杂了，自然也就衍生出了诸多欲望与需求，逐渐便也形成了许多产品创意，但很多创意都无法被实现，且不说那些从未付诸行动的创意，单论那些曾经付诸过确实创意的行动而言，产品早期最严重的问题就是，开发的速度往往跟不上创意变化的速度。
许多初创的互联网产品项目，在早期并没有明确的产品化思路，往往从一个并没有那么细节明确的产品思路便开始着手研发，这也导致了许多情况下在不断深入挖掘产品领域内的需求时，初期的思路就会显的十分淡薄，往往是一周甚至几天就会挖出点新的思路对原有的产品进行补充。
但很显然，这个时间并不足以满足开发实现，于是乎也就出现了产品在前面吹，开发在后面追的奇怪情况，往往都是一些没有被实现的产品功能被先一步搬到了对外宣传的术语中。
而解决这种问题的思路大致被分为了两种，其一认为，客户才是产品的本质，是盈利的更本，因此即使创意不够完善，产品细节不够严谨，能对外进行展示便算是完成了产品研发阶段，总而言之，用一句听到的最多的话就叫做：先让用户用起来，其他再说！
其二认为，产品的核心是稳定与贴合实际，无需急于求成，即使初期没有把握到更多客户，中后期依然可以使用过硬的行业口碑和产品质量逐渐抢占市场，客户的问题自然便会解决，于是乎其初期往往名声不显，或是从此消失，或是一鸣惊人，赌的就是产品对行业的细节把握。
其实这两种思路近年都走过，本质而言这两种模式归根究底的区别在于创始人对产品在行业内的竞争力自信所导致，而其结果并没有什么不同，前者通常由于创始人对产品的信心不足，认为市场需求并不明确，因此最先打出核心概念的产品往往才能开拓市场成为第一个吃螃蟹的人，而后者则是相反，对于行业需求有绝对的自信，认为可以把握市场内的客户群体，从而徐徐图之。
然而近几年，第二种情况越发的稀少，巨大的研发成本和长时间没有特别明显的业务增长是很多公司和创始人都无法承受的，逐渐的第一种情况便开始越发的极端起来。
甚至曾经有很多言论，笃定的认为，一个产品的成功与否，只需要3个月，从创意到推广，如果无法达到满意的数据，那么这个产品就是没有意义的。这般计算起来，去掉各项调研，前期准备，后期推广等，留给开发的时间可能就并不多了，从接触到的绝大多数产品开发需求看，这个时间，大概一半都会期望控制在1到1个半月（这个周期并不能通过人员的多寡来缩短，增加人员的同时并不等同与增加效率缩短工期，有时候往往会因为人员多而导致混乱加大工期）。
但实际上，这个时间可以说基本上是无法满足一个需求完善的产品从0-1的整个开发周期，对于这一点，许多人会很难以理解，曾遇到过最多的情况就是认为，同样的功能在拥有源代码的情况下，只需要简单的做复制黏贴即可，就如同打开一个word文档，抄一篇毕业论文一样，或许在细节除需要修改，但大体上不过只是复制黏贴，修修改改便可以完事了。
本篇的核心倒也不是讨论技术，却也大致想提上那么一下，且不说不同的开发语言，即使相同的语言，依然分诸多的开发体系，几乎每一款产品的功能都是无法直接将代码应用到其他产品内，便也造成了看似相同的业务，实际上做的永远只是模仿而不能拷贝，也就形成了1到1个半月的时间无法实现从0到1的产品开发周期定论。
其实在互联网早期的一些开发构思中，也有这么一段很相似的时间，也有类似如今这般的产品思路，俗称：不要重复造轮子，初期的互联网开发，尚无法明确划分各开发流程只见关系的时候，便是以这种思维占据了主导，也就是当年曾风靡一时的php，jsp，asp等实现手段，其主要特点便是，打开代码编辑器，就真的与打开一个word文档没有什么区别，到处复制黏贴，修修改改，毫无壁垒障碍，同样的功能就是同样的代码，拷贝即可使用。
但这样的体系并没有维持太长的时间，实际应用证明，这样的思路有非常巨大的局限性，不利于长期维护，也不利于版本迭代，随着互联网需求的日渐增多，这样的模式也被逐步淘汰，而随之兴起的，也是后面逐渐被接受的另外一种思路，从工具化、代码重用化变成了框架化。
这一点也不难从一些成型的，并且持久运行的互联网产品中看到其演变过程，其最大的特点就是，从代码衍生到了对人的分工，开始走向了一个标准化有序化的阶段，这恰恰也是许多互联网产品在长期运营后表现出的特征，当产品运营周期变长，出现问题后，逐渐需要更多的人去加入维护和升级，那么更细化的分工，更容易被非功能开发者的第三人接手工作的体系就显的非常重要了，印象当中，这种开始逐渐从单纯的代码，跨越到对人员分工定位的框架化模式大概就是从我开始入行的那段时间被提出并逐渐推广的。
而这样的理论也被逐渐发展，越发的完善，伴随如今日益复杂的各种互联网需求，也同时表明了这种体系化的必要性，其根本目的并非是一味提现在代码与技术层面，而更侧重于后期的维护与升级。
同时这样的设计也就形成了上述出现的问题，看似相似，实则不同，只能模仿，不能拷贝的情况，稍稍具个例子，甲产品由一个百人团队进行设计开发完成，完成了其中的1、2、3、4种需求，那么其框架结构必然是以百人团队的运作为根本进行设计并实现的产品，此时若有乙产品由10人构成的团队想要复制甲产品的2号功能，那么即使获取到了甲产品的2号功能全部代码，也难以直接使用，因为这些代码，本质上是基于甲产品百人团队的研发基础上运行的，除非复制整个甲产品，否则也就没有办法使用。退一万步来讲，已经获取了甲产品的全部代码，但甲产品的构思是基于百人团队协同完成，而乙产品要提取2号功能，那么必然先要模仿这百人团队的开发结构让乙产品保持同样的结构才能使用，但百人团队的协作开发，真的是十人团队可以做到的么？显然答案也是不可能。
话题及至此，又出现了新的分支，也就是前文提及的产品有效论，逐渐庞大，复杂化的框架体系，对应的是更庞大的用户群体和开发运维群体，而通常情况下，初创型的产品并不具备等同框架设计所需要的团队配置，也就造成了研发时长的进一步加剧。
言即至此，亦有一句近年来听到过最多的一句话：那就不要用什么框架啊，直接复制黏贴，怎么快怎么来，乍一听似乎极端的有道理，毕竟不同的情况下要用不同的方式来处理问题，而这往往也是许多软件外包公司应对其他公司产品开发委托的时候所采用的方式，于是乎1，2人对应的需求开发之后，怕也是只能有1，2人使用不出问题了，但不得不说，其确实满足了当下互联网产品研发的主流思维：1、确实能用，2、确实短期完成了客户所需的产品需求。
但取而代之的是后续无力，往往在产品成型推广后，出现的问题范围日益扩大，最终不得不重新设计重新开发，影响已有用户的口碑，造成更大的代价。
从业的这些年，听闻的各种指责外包的言语数不甚数，甚至许多产品因此一蹶不振，于是乎，近年来，又发展出了第三种极端情况：低代码平台。
其原型来自于早期的建站平台，早期为了满足非开发者低成本创建自己的企业官网而形成的一种面相非专业人员的软件生成平台，其主要特点有2个：1、其本身使用的是框架化开发思路，可以满足开发团队的订制开发需求，2、其本身也是一种面相互联网产品的产品，提供了非专业的配置入口，可以让非专业人员也和专业人员一样去制作稳定可靠的定制化产品。
乍一看简直是互联网产品的天籁之音，集各方之大成，即不会出现外包的无序无标准不可长期运营使用的弊端，又可以在即使没有专业技术人员的支持也可以快速产出产品的优点，还可以做到框架化，在日后的运营维护升级迭代过程中，无缝的插入开发人员进行有序的规范化的团队扩充，可以说几乎无懈可击。
然而真有这么好的事么？显然不尽然，“既要也要”的好事若真的有，那还要开发作甚？低代码平台一家独大，也用不着这许多开发技术人员了。
其中必然是有某些缺陷造成了低代码平台火而不广的局面，而其核心的问题也恰恰是其框架化和非专业人员的定制化，过度的泛用化设计导致了看似使用简单，实则拓展困难的局面，越是面对复杂的业务逻辑，其功能就显的越是疲乏无力，每一次的功能拓展都需要做到“既要又要”，其结果往往是倍数级别的难度提高以及研发成本提高。
如此这般的弯弯绕绕一大圈，再回首，突然发现，近年来做的诸多产品设计，往往最终还是会绕回到原点，变成无序混乱的产品开发模式，无框架，无规范，不考虑维护成本，不考虑运营成本反而成为了当下主流的产品研发模式，或许这就是市场规律，作为一个产品研发者，不应该执着于各方平衡，虽然过去并不是特别认同“三个月产品理论”但如今看来，或许这才是真相。
