相信大家经历过一段时间代码工具的学习和使用之后，一定发现了更多问题，一定会有更多更高的要求，因为与最初接触时可能只是出于好奇和热心相比，此时所面临的境况已经大为不同，很多新局面都要求开发者不得不朝更高更远的目标迈进，技术掌握的再好也远远不够了。
- 厨师学徒有了一把好刀且练好了刀工，并不意味就可以做一桌好菜.
- 掌握好工具的用法和用好工具办成事办大事之间还有巨大的鸿沟。
6大决定因素
1、工具属性决定的
低代码是一种开发工具，不能被直接用作管理工具，在其上开发的应用才是管理工具。从开发工具到管理工具，需要开发者经常从开发思维转换到用户视角，否则很容易陷入开发者的思维定式里，做出的应用离用户实际需求相差甚远。这个问题很多人都没意识到，或者还没养成这样随时转换的习惯。
2、低代码特性决定的
由于不能写代码或者写很少代码，无法进行太多功能扩展，只能利用现有功能进行开发，但现实中又要满足变化多端的需求，这就要求开发者不但要全面掌握基础功能用法，还要有极强的变通能力创造能力——也就是带着镣铐跳舞的能力，要时常能突破很多既有认知，站在更高的维度，只有这样才能最大限度的挖掘出低代码的价值。否则就很容易出现由于需求处处被折中被妥协导致的功能缺失和使用体验不佳。
3、开发者环境变化了
一开始尝试开发的应用可能只是给自己个人用，或者自己所在部门用，可随着应用在企业内部的使用和传播，越来越多的人和部门加入其中，直至扩展到整个企业，再后来，慢慢地，随着业务管理的需要，可能开始把一些上下游的合作伙伴也纳入进来。那此时开发者所面临的局面已经大为不同，当越来越多的人和部门加入进来，问题再也不是只为解决自己的那点需求那么简单了，需要考虑协调和统筹的需求就会急剧增加。
4、企业要求不一样了
随着越来越多的人员和部门加入系统，越来越多的业务开始转向线上管理，那企业越来越多的业务数据就开始在线上流转和沉淀，越来越多的管理需要依赖线上系统，线上系统就慢慢成为企业越来越重要的核心资产。那与此同时，企业对系统的规范要求就和以前不一样了，要求更加严格了，就要有相应的规章制度，划分权责，明确奖罚等。那从此以后每次开发或修改，就不能随心所欲了，要时刻谨记规章制度，否则造成的损失可能无法承担。有了这些限制，开发的速度必然降低，难度也急剧增加。
5、开发者位置不一样了
开发了这些应用系统的人对企业的价值也将越来越突显，其角色或位置，也必将主动或被动的发生变化。因为任何一个懂得的领导都知道，此时的开发者不再只是一个普通的员工，而是一个具备了开发技能的数字化管理者，是有能力为同事为企业进行数字化赋能的人，那相应的，给予其相匹配的职位和薪酬就是水到渠成的必选动作。
开发者职位提升，站在了更高的高度，可以接触到更多的人和资源，那接收信息的维度和丰度也急剧增加。这对观察和理解企业的全貌都更加有益，那相应的，所要解决问题的难度也成倍增加，需要平衡和取舍的因素也更多，对开发者能力的要求也更高。
6、开发者心态不一样了
在掌握了基础的开发技能之后，开发者一定不再只满足于成为一个“会技术的工匠”，必然会有更高的追求。因为开发者会慢慢意识到，应用开发的过程就是研究企业如何管理的过程，有时面临的难题，很多都不是技术方面的，而是认知层面和管理层面的。能认识到其中的难度，更能认识到其中蕴藏的价值，于是开始想着把自己这么多年积累的行业经验和管理智慧融入到低代码的开发中，那么开发中面临的变量和不确定因素又陡然增加。
总的来说
总的来说，无论是由于低代码的特性或工具属性导致的对开发者能力要求提高，还是企业要求变严格，开发者所处的环境、位置以及心态发生变化引起的需求增多和不确定性增加，都说明开发者低代码技术掌握的再好也远远不够了
当使用开发工具的技能类知识不再是问题，如何提升对工具的认知，以应对如上所述的各种难题，让工具的价值真正发挥出来，如何让工具给企业管理企业发展带来更大的价值，都将是开发者更加关心的问题。
其实无论使用何种语言或工具进行系统开发，随着需求的细化和功能模块的叠加，各种各样的困惑一定会层出不穷。从一开始多是技术层面的问题，到后来越来越多的指向系统方案设计、框架规划、管理模式等上面来。一般技术方面的问题都相对容易解决，而其他方面的问题都较复杂，解决难度也急剧增加。
这是一个由量变到质变的过程，从最初的可以随心所欲的搭建，到后面需要统筹多方需求进行合理的规划，问题也将从已知走向未知，从技术层面转向管理层面，从功能层面转向认知层面。面对这些问题 ，对非专业的普通人群来说，如果再没有一些专业的人员辅助，几乎是不可能完成的任务，这也是目前很多用户随着学习和搭建的深入，越来越力不从心，越来越骑虎难下的主要原因。
最后的话
希望我们的出现，能在这方面帮助到大家。之前我们撰写的多是低代码技术类的文章（50多篇，社区阅读量超60万），以后这里将发布更多低代码认知类的文章。
这些年来，我们专注的从来都不只是技术层面的问题，因为从一开始我们就清楚，随着各大低代码平台功能的逐步完善，以及更多用户的学习和掌握，未来阻碍平台和大家的一定是认知问题，因为低代码平台面向的多是没有系统经验的普通人群。所以从一开始我们就注意对使用经验、管理经验以及各种新发现新认知的收集和整理。这些经验和认知，有的来自我们这些年来上百个真实项目的需求素材、需求文档、设计方案、开发和实施文档等，有的来自我们内部各类会议上同事们头脑风暴的记录和整理，还有一些得益于我个人的一些习惯。以后会单独用一些文章来介绍这些内容生成的路径和方式。
以后在这里会陆续发布的文章大致如下：
- 低代码平台选型相关（约20篇）
- 低代码带来的那些重大变化及应对策略（约6篇）
- 低代码相关概念再认知（约7篇）
- 关于低代码开发的需求管理（约17篇）
- 低代码常见认知偏误（约8篇）
- 低代码开发必备认知（约15篇）
- 企业低代码数字化成功必备认知（约10篇）
- 其他（N篇）
期待与大家更多交流！
注释：为了便于写作和阅读，我文章里的低代码一般是行业里常说的低代码和零代码的统称，因为在我看来，很多认知方面的知识二者可以通用。当然，在需要特别区别对待的时候，我会单独做说明，后续也会在“低代码平台如何选型”的章节对二者的区别和联系做深入详细的论述。
声明：牛中伟名下所有文章均为牛中伟原创，任何机构和个人未经允许不得转载！
作者简介：
- 牛中伟，微信：nzw888999
- 低代码行业表达者
- 利用低代码平台实施项目超300个
- 主流低代码平台六年生态合作伙伴
- 公开发布低代码技术类、认知类文章60余篇。
- 对如何在企业顺利推进低代码数字化管理系统落地有丰富经验和独到见解。
