论发展的十大关系。总结过去,正视未来!!!


目       录

1.      产品型市场和项目型市场之间的关系... 2

2.      堆砌代码与基础框架之间的有关系... 3

3.      业务或技术深度与广度之间的关系... 3

4.      公有云建设与私有项目之间的关系... 4

5.      发展与方向正确之间的关系... 4

6.      产品与商业模式之间的关系... 5

7.      人力资源与未来发展之间的关系... 6

8.      项目实施与产品迭代之间的关系... 6

9.      全行业拓展与某行业突破之间的关系... 7

10.   团队收入与回馈社会之间的关系... 7

11.    结束语... 8


        曾经有一位伟人在1956年写过一篇文章《论十大关系》,收录在《毛**ze**东选集》第五卷。新中国成立后百废待兴,这篇文章是在国家建设各方面的指导思想。在发展过程中,防止出现极端主义、教条主义等情况起到了关键作用,为后续可持续发展奠定了基础。

       团队从小发展到大的过程,同样面临选择和路径的问题,先干什么、后干什么或同时干的效果会完全不同大家都有目标,拆解目标、路径、实施、验证和结果,我们怎么走出一条可迭代的持续路径?需要我们做出大量的工作。这是发展模型思维模式不是单一因素的问题,而是多维因素交织又相互作用的空间环境,也可以把这个空间环境理解为风水。因时因地因势的环境改变,又要做出相应关系的调整,适应发展的目标。

1.   产品型市场和项目型市场之间的关系

 对这个问题感触比较深。2017年,我就找过人员一起开发类似iNeuOS工业互联网操作系统的平台,没有合作成功的主要原因就是产品和项目的分歧,类似于华为的技术研发和联想的技术贸易路线,无法达成一致。他们认为产品和技术都不缺,唯一缺少的是项目,所以找人、找关系、找项目才是重点。我认为他们所说的产品”和“技术”并不是真正的体系化和产品化的产品,另外没有项目的时间里可以把精力投入到产品持续的规划和开发中

  实际产品型和项目型并不矛盾,这个的核心问题是对发展的认知和发展起步阶段切入点的选择。行走江湖之中,没有权势、没有关系、没有资本、没有门户的四无人员,付出小点的成本、多一些精力,买点铁、炉子、木炭等,锻造一把并不锋利的刀,用漂亮的布给包裹起来,给刀起个响亮的名称,再把气质装的像侠客一样,总能有立足之地吧。一个四无人员,一点都不想付出,在任何时代要么是骗、要么纯装B、要么嗟来之食,不是长久发展之计

  假设我们发展的目标都是为了赚钱,实施路径需要解决怎么进行交换和寻找变现的途径。从2017年到2021年的发展路径来看,我们现在走的道路无疑是正确的。

2.   堆砌代码与基础框架之间的有关系

  我在上大学的时候,系主任对我说过一句话:软件需要一个代码块一个代码的积累。这句话对于一个初学者无疑是正确的,但是对于发展来讲不一定正确。

  编程的时间长了,踩过坑积累了经验,完成过功能积累了代码,但是大部分人会掉入到类似“中等发展陷阱”的状态中,工作状态很好,复制和粘贴能够很快完成任务。在不断重复堆砌代码的工作中,唯一不同的是可重复使用代码的比例是多少的问题。最近,和几个国企团队交流,他们也承认:有活就干,没有什么积累

  既然有了经验、有了积累的代码块,怎么向基础框架和产品跨域?这需要一个附加条件:从技术角度对业务场景进行抽象,不是抽象一个接口,而是抽象N多个接口,这样才有生命力。就是要从技术向工程技术能力的提升,在《作为软件开发人员,看中国工业软件差在哪?》提到过这个问题。能够达到这一个层次,作为领导者必须得有推倒重来的勇气,否则无从谈起。

3.   业务或技术深度与广度之间的关系

  这是个人或团队发展过程中无法回避的四象限选择,这里边有两个核心问题:1)发展起步阶段的切入点落在哪个象限?(2)何时何地向其他象限发展?从小到大、从大到强,必须很好的思考和回答这两个问题,否则就没有章法。

  团队初创起步阶段比较艰难,但是向其他象限拓展同样比较艰难。我认为突破最大的瓶颈是领导或是老板,他们要么懂业务、要么懂技术、要么都不懂、要么不敢向未知领域发展

  iNeuOS工业互联网操作系统相对做到了技术深度,我们也在思考向技术广度发展,例如:AI、云计算、数据治理、区块链等方面;向业务深度和广度发展,例如:行业工艺机理层面、通用业务层面等方面。但是选择的过程是在与现在产品互补、团队稳定与整体运营等方面平衡的结果,其实是发展模型自我认知不断迭代的结果

 

4.   公有云建设与私有项目之间的关系

  这是一个比较大的问题,涉及到业务、技术、运维、团队和资金等方方面面。阿里云、华为云、腾讯云都是重资本,一般性的企业肯定是玩不起。垂直行业的公有云平台建设,更侧重行业属性,技术相对弱化,在行业壁垒及其他影响因素的限制条件下也不容易建设。受行业边界的限制,普世性的行业应用和拓展比较困难。以全中国的市场空间也才有知名的几个通用公有云,小众的行业云平台机会比较渺茫。但是,我们团队建设的面向炼铁行业的钢铁行业云平台,相对比较成功。

  有人问iNeuOS工业互联网操作系统是否支持本地部署,其实我们就是面向本地部署,线上只是演示的系统。如果我们的系统搞成公有云的模式,从硬件、软件、人员、运维等全部需要突破,无法控制成本。麻雀虽小,五脏俱全。私有本地部署可以把“云”的部分去掉,更关注于行业业务应用部分。

  但是,我一直认为公有云建设和私有项目之间不冲突,有一定的互补性。公有云的方案移动到私有本地部署相对容易些,更需要关心的是资金和定制化的业务。更注重私有本地化部署的企业,有实力的情况下,应该尝试公有云建设,一是能力的整体提升,二是探索加速变现的渠道

5.   发展与方向正确之间的关系

  每个人都可以谈论发展,但是相对于方向来讲,在一个团队里能够做出相对正确抉择的人有且只有一个。新中国成立、公司上市,这个路径就是唯一正确,任何一个节点出现问题,时机错过了。学习历史是正视未来,但是历史不能假设。

  大家都喜欢开会讨论,如果是最终连一个错误的决定都没有,那么即不存在发展、也不存在方向的问题。《乌合之众》有一个核心的观点,为了融入和认同感而降低自己的判断和智商。所以,我们在谈论发展与方向的问题,首先就要避免这种情况的存在,否则就是内卷。

  最近看了一篇文章《永远不要用战术的勤奋,掩盖战略的懒惰》,如果战略方向失明,发展速度快与慢直接反映是伤亡大小的问题。但是现在人们大多急功近利,即付出即回报,实际上没有3-5年的持续投入很难有实际的回报或跨越式的发展如果借助资本来发展,那么不可否认可以缩短试错的周期,但是不能够违背发展过程和规律

  iNeuOS工业互联网操作系统的后台框架是从2015年底开始重构,2017开始规划开发应用系统,2018年正式投入人力开始开发,到2021年持续发展了6年的时间,最近两年才实现整体本质上的突破,逐步正向迭代发展。只看发展速度,我本人是比较焦虑的;看发展方向,我本人又是淡定的。发展与方向是一个辩证的关系,本质是时间与空间相互协调的过程。如果人高速移动,那么人会变形,要时常停下脚本来思考。

6.   产品与商业模式之间的关系

  有了产品是不是就高枕无忧了?我看到过大学教授研制的很多感觉不错的产品,但是最终没有形成市场化、商业化和生态化。就像侠客携带宝刀行走江湖,但是不一定能当武林盟主。

  拥有产品只是我们发展过程其中一个阶段,后面可能面临品牌化、市场化、商业化和生态化,更直白的说产品只是搞“传销”的一个介质。有人拿iNeuOS与某控对标,我们抛开技术和框架不同之外,商业合作模式是不是可以走某控的模式?我们是这样思考的,如果自己的产品和市场上同类产品类似,那么竞争优势在哪,是不是要有不同的商业模式;如果自己产品和市场上同类产品不一样,那么是不是要有与之匹配的商业模式加强市场竞争优势呢。

  总之,产品与商业是硬币的两面,这才是价值。商业模式是包含多种因素的复杂逻辑,一直在探索中,在此不做深入讨论。

7.   人力资源与未来发展之间的关系

  决定发展的核心因素是人,决定发展结果是怎么用人。这个道理相信大家都明白,但是为什么大部分人做不到呢!有的老板认为大部分人都是平庸的,团队的发展就用差不多的人就行了,这样也好控制。但是我们从发展的结果导向来思考人力资源的问题,谁能最快最好的达成目标结果!我们承认大部分人是平庸的,那么我们是不是更应该用能力强的人呢?!因为能力强、又合拍的人不好找呀!既是思维模式的问题,又是带头人胸怀的问题

  团队在发展过程中,为什么会出现人力资源内耗的问题?一是人性的原因,大部分人是弱者,弱者的同理心更容易报团,不太适合强者的生存,这考验一个团队有没有纠错的能力;二是团队战略规划和实施路径不清晰,战略方面领导朝令夕改、优柔寡断,实施路径方面磨磨唧唧、嫉贤妒能。人员在推动发展的过程中的内耗貌似很难避免,但是从宇宙观来考量内耗又微不足道

  人力资源与当前的发展现状要匹配,可以以发展目标为导向适度超越现状配置人力资源。关键是如何评估发展现状和目标,这可能也是初创企业很快消失的原因

8.   项目实施与产品迭代之间的关系

  项目实施的过程中进行产品化的工作,本身是一举多得的事,但是往往相互矛盾,就算进行产品化,产品可扩展的能力也有限。我认为主要有两个因素:(1)人员主要的职责目标是完成项目,产品化的意愿和人员整体素质受限;(2)团队整体组织结构缺少产品化的过度环节,这个和团队创立之初的基因关系。产品应用于项目中,定制化业务功能受控在50%以内,我认为就算是比较成功。我们在开发iNeuOS产品的发展过程中保持着良好的设计和定力,应用到中核某测控项目实践过程中表现比较突出。

  不管是项目实施中进行产品化,还是产品应用到项目中,形成相互促进的迭代关系是比较理想的状态。肯定要走产品化的路线,现在用户对实施方的要求不断提高,价格压的越来越低,从零开始的项目基本没有利润

  产品化也受限于应用场景,但是对用户也具备战略性的忽悠能力。

9.   全行业拓展与某行业突破之间的关系

  这也是我们现在考虑的主要问题,iNeuOS能够应用到全行业的基础能力建设中,但是也想聚焦某个行业能够深入业务应用,也就是处理“业务或技术深度与广度之间的关系”过程中从技术深度向行业业务深度发展,从技术和业务两个层面构建发展的地基,这样才能够走的更长远。但是找准行业、深入行业也比较困难,这是高于现在换档发展的问题。

  单点突破某个行业,受限于行业周期发展的波动和行业规模,从强向大发展的过程也必然是向全行业拓展的过程。从做事角度看,在某个行业后会有固化的思维模式,在向全行业拓展的过程会出现两种极端情况:套用现在做事模式的固执己见和畏手畏脚,以事实为依据的客观评价才是推动事物发展的前提条件。

  全行业和某行业突破是发展过程中做大和做强转型期的必然选择,但是转型阵痛期也不是每个企业能够承受的。

10.  团队收入与回馈社会之间的关系

  最近曹德旺出资100亿建大学,这是企业家的善举。养活自己、养活家庭、养活团队……,这都是回馈社会的一种方式。现在社会生存压力比较大,能够达到这个层次已经很不错了。这些都是和自己直接相关的人,我们努力的方向是回馈社会给那个不相关的人。

  从利他角度看,只有更高层次影响更多人,才能达到自己比较理想的目标。从自己或团队角度来讲,善心的初衷是好的,但是要视团队发展状况量力回馈社会,为国家共富做出微薄的贡献

11. 结束语

  总感觉有些没有说清楚,但是说透又感觉太多废话,就这样吧!!!


 物联网&大数据技术 QQ群:54256083

物联网&大数据项目 QQ群:727664080
QQ:504547114
微信:wxzz0151
博客:https://www.cnblogs.com/lsjwq
微信公众号:iNeuOS

文章来源:https://www.cnblogs.com/lsjwq/p/15604673.html

版权声明:本文为YES开发框架网发布内容,转载请附上原文出处连接
管理员
上一篇:在ASP.NET Core web API中使用Swagger/OpenAPI(Swashbuckle)
下一篇:AgileConfig-1.5.5 发布 - 支持 JSON 编辑模式
评论列表

发表评论

评论内容
昵称:
验证码:
验证码
关联文章

发展关系总结过去正视未来!!!
C#进化——C#发展史、C#1.0-10.0语法系统性梳理、C#与JAVA对比
对C#未来一点感悟
C#性能优化总结
electron与node.js版本对应关系
linux分析清理文件
中国式浪漫,二四节气倒计时去水印高清壁纸,承包你22年桌面壁纸
AI聊天机器人总结,图灵、思知、小爱、小微
C#数据类型和常见数据库(SQLServer,MySQL,Oracle,SQLite)数据类型对应关系
ABP VNext框架基础知识介绍(1)--框架基础类继承关系
win10各浏览器Cookies文件存放位置
系统登录后默认显示可视化数据
微信支付提示 No_Auth 受理关系不存在
SQL Server 数据库类型和.NET数据类型映射关系
Web service 超过了最请求长度
AI时代你都用过哪些模型?
DevExpress Winform统一设置字体
如何定位程序占用内存过问题-程序内存/CPU占用分析
.NET 百万级 数据插入、更新 ,支持多种数据库
搞工业互联网平台企业为什么不搞工业控制层?

热门标签
.NET Core .NET Reactor ag-grid AI发布 api安全 ASP.NET Core C#DLL加密 C#播放声音 C#代码混淆 C#代码加密 ChromeDriver Codex DateTime DBeaver devexpress devTool DLL混淆 edge.js EF EFCore Electron element-ui el-form el-table excel FastReport FileStream FolderBrowerDialog FolderSelectDialog form提交 git gridcontrol gridview input javascript json字符串 JS转换对象JSON jwt JWT授权 linq log Math MCP mitmproxy MVC MySQL Navicat netstat nginx node_modules NSwag Nuget Nuget镜像 number PowerShell pyinstaller python pythoncom python爬虫 python抓包 pywin32 redis Requests-html RestSharp Selenium sql SQL Server Swagger to-cms Visual Studio VSCode vue VueRouter vue路由 VUE页面通讯 Webpack Windows Windows服务 winform wmi xlrd yaml YESCMS YESWEB开发框架 白象 表单提交 播放声音 打开URL 代码混淆 弹窗提醒 端口占用 对象转换 分布式 公共字典 机器码 进程排查 静态资源 开发指南 路由参数 密钥 配置教程 配置文件 权限 人工智能 任务 任务调度 日期间隔 日志 日志记录 省市区 授权验证 数据库 四舍五入 文案 文件读取 文件夹选择 文件目录选择 问题排查 行政区域数据 页面通讯 中间件 CSharp 事务锁 工单系统 并发控制 重复提交 CMS Markdig Markdown markdown-it marked 技术选型 VS Code 开发工具 源代码管理 版本控制 Docker PostgreSQL 时区 部署排查 CMS架构 EF Core 主题系统 二次开发 插件系统 容器 运维命令 镜像清理 Linux NAS 远程挂载 飞牛 fnOS S/4HANA SAP GUI SAP HANA SAP R/3 SAP入门 SAP版本 ERP SAP SAP MM 库存管理 物料管理 采购管理 入门教程 SAP S/4HANA SPRO 企业结构 采购组织 MM01 物料主数据 物料类型 BP分组 业务伙伴 供应商主数据 ME41 RFQ 库存物料 采购流程 ME51 消耗性物料 科目分配 采购申请 AC03 ML81N 外部服务 服务主数据 Business Partner SAP培训 ME51N MM模块 Lean Services MM-SRV 外部服务采购 PIR 供应来源 采购主数据 采购信息记录 ME31K 框架协议 计划协议 采购合同 ME01 供应来源确定 货源清单 MEQ1 供应源确定 配额安排 配额评分 MD04 MD21 MRP 计划文件 需求计划 批量程序 MD01N MD02 MRP Live MD05 MM 物料计划 优化采购 供应源 采购订单 ME2A 供应商确认 采购监控 Flexible Workflow 凭证释放 采购审批 释放策略 实地盘点 物料凭证 货物移动 MIGO 收货 移动类型 已撤回 供应商退货 货物发出 STO 库存转储 转移过账 生产订单 预留 GR/IR MIRO 供应商发票 物流发票校验 OMR2 税码 FI PP SD 实操教程 MRBR OMR6 发票差异 交货成本 后续借记 MI01 实物盘点 盘点差异 公司代码 工厂 组织结构 OMS2 主数据定制 自动科目确定 BP角色 CVI 伙伴确定 编号范围 凭证类型 字段选择 FBN1 OMBT OMC2 会计凭证 OMJJ BOM 委外加工 项目类别L MRKO 供应商寄售 特殊库存K MRKON PIPE Pipeline 特殊库存P ERS MRIS 发票计划 周期性结算 里程碑付款 变更追踪 版本管理 采购凭证 SFTP WebDAV 网盘 飞牛fnOS AMPL HERS MPN 中文教程 库存确定 可用性检查 缺件检查 Output Management 消息确定 输出确定 分割评估 库存计价 评估类别 评估类型 PB00 RM0000 条件技术 采购定价 MM-FI集成 OBYC 库存估价 文本类型 文本采用 EFB EVO MSV SU3 用户参数 发票校验 合同参照 履约保留款 特别总账 预付款 Fiori Launchpad SAP Fiori 应用导航 用户体验 LSMW LTMC Migration Cockpit 数据迁移 BRFplus OPD Output Control My Inbox 审批流程 灵活工作流 SAP PP 外部加工 SAP QM 检验批 质量信息记录 采购收货 SAP PM 维护BOM 维护订单 SAP SD SAP Service 端到端流程 MM模块培训 FI-MM集成 供应商管理 审批配置 FICO入门 SAP FICO 财务配置 供应商税务 预扣税 House Bank 银行对账 客户清账 应收账款 FI控制 验证与替代 印度 GST 税务配置 F110 FBZP EWM入门 SAP EWM 仓库管理 OX14 成本核算 物料评估 后勤配置 物料组 价值更新 数量更新 PP-PI 流程制造 生产计划 容差配置 SAP事务码 SAP基础 TCODE Basis 事务代码 MMNR 编号区间 采购实操 组织架构 OMSF SAP实操 FI配置
联系我们
联系电话:15090125178(微信同号)
电子邮箱:garson_zhang@163.com
站长微信二维码
微信二维码