作者部分功力背景
中国第一批ERP系统实际落地实施参与者 用户身份
参与数据结构设计; 客户化报表设计; 业务及财务岗位再造和优化;客户管理软件推广
应用并参与实施企业软件建设: MFG/Pro JDE SAP
金蝶 用友
民营企业电商平台,小程序及SAAS 平台建设
区块链生态构建及相关专业知识点学习
现场观摩中国一流区块链技术人员即时场景编程挑战
作者学业专业背景
财务战略 财务管理
作者职业背景
财务战略管理财务分析信息系统建设内部控制财务负责人
作为有系统建设的企业,一定会碰到系统运行中的尴尬。日常用语为：系统出问题了!
20年过去，随着互联网的普及和每个企业信息化数据化建设，企业不仅享受到科技带来的效率和穿透感，同时也开始经历不同以往的问题。这和骑马、骑自行车、骑摩托车和开汽车、开游艇、开飞机和火箭一样。因为工具的不同，遭遇的问题也会不同。
就如目前许多技术大牛和我说的，每几个月技术就有很多变化，真正的技术高手，一刻也不能脱离前线。要么技术拔尖，要么技术管理拔尖。这在技术圈里，才会被认为是头“牛”。
那么，技术圈之外呢？作为充分利用信息化时代的工具的我们。也可以伴随这个前进，共同来体会一下，一些表象之下的真实。这样我们和技术的对话，将会更加客观而彼此理解。
谁的问题？
无论是否技术领域，但凡出了问题，常见现象是，大多数人先关心是“谁的问题”？潜台词是，谁应该对这个问题承担责任？
有些时候关于这个问题的答案，可以有助于解决问题。偏偏在技术领域，这个答案，十分无助于解决问题。因为
技术开发，除了自己写代码外，通行做法是会基于一些技术领域常规的开源平台，调用许多中间件，免费开源的。那些开源平台,建立开始，就不断在做升级和优化，投入大量人力物力。
越是庞大的代码群的bug每天都有，只是每个bug 导致的结果表现不同;
应用层的操作与开发原型图的规划不同，导致信息逻辑与代码逻辑冲突;
比如：1=1=2代码按这个顺序写，偏偏有人，先写加号，再写1，再写1, 用户手势的不同也会So
- 代码是建立在逻辑上的，逻辑逻辑！
- 除了主要应用和功能代码部分；
还有硬件驱动软件代码；
确保功能代码与不同中间件共同工作的代码；
监控代码；
安全代码；等等。。。。
这些代码交互的时候，出现bug,或许和数据量有关，数据形式有关，或许内部数据交互的问题，或许入口信息的问题，或许向下传输到其他接口的问题，或者回传信息的问题。。。。这些都会导致一些小的问题出现。
这也是为什么新建平台，要用敏态开发的原因。在小间隔期间内，不断作小的迭代。
这些都非常繁琐。记得那年那天，在ERP软件实施中，一个全球化的相对成熟的软件，具备成熟的自建模块，在为我调整一个客户化报表，2个字段的添加上，整整让大牛熬了一整夜。想想，他或许觉得20多岁的我太执着，担心我哭着他就不能上飞机。
总结：应用环节，监督环节，管理环节越多，代码的任何变动，就是一个系统性问题。
技能水平问题？
这也很自然，问好是谁？接下来就质疑技术水平。
对于开发人员而言，技术就是靠经历项目的数量，经历项目的类型，碰到和解决问题的数量，然后就是个人的学习能力，不断动手实践的能力，塑造出来的。
技术水平怎么判断？除了专业判断外，还有就是构建一个平台时，实际交付的投入成本，交付的时间，运行情况和规划的偏差。
99.9%的项目都会出现 5% 以上的偏差，无论任何类型，就是最牛的互联网企业。
因为不是一个人的技能搭出了整体，不同的角色协同一起工作，彼此之间的水平，沟通，管理项目人的水平等等都会有影响。
因此，技能水平，不可能在一个问题或少数几个问题上体现出来。
但，时间长了，同一问题反复出现在一个人身上，就是认知问题，还不是技术水平问题。
真正技术水平的问题，不是在后期出现的，在搭建时，肯定出现！
对待问题的正确姿势？
精准定义好问题。技术问题，从来不可能是单纯的技术问题，有些是沟通理解的问题，导致原型图表现有误，或者开发对原型的理解有误，或者人机互动的流程问题，或者有行业经验问题，或者有技术角色问题。
比如：前端开发工程师后端开发工程师测试工程师都有自己的代码规则。
个人一贯风格, 不回避问题, 不夸大缩小问题, 用最客观的态度, 专业的面对问题. 任何真正聚焦在成长上的人，企业和事物，都要先正视自己的问题，寻求第三视野，一起来合理理解并解决问题。
每一次面对问题的解决轨迹，是最大的收获！每一次面对问题的正确解决方式，也是最轻松的方式，就是任何时候，问题都可以放在桌面上面对和讨论。
扎克伯格说：不求完美，先求完整！
这就是标准的互联网思维，这就是典型的技术搭建思维。
作为一个非技术专业的人，融合业务效率，融合组织成长，融合个体发展，融合技术理解，
本文分享给更多的朋友, 一起探讨。
蕙雨总结：系统的问题，无法杜绝，成长的问题，不要停止脚步！
客观的理性 专业的直觉
网友评论