最初的观察
新的营销活动和功能,反复受到相同的技术限制。
案例研究 · 行业:电商与零售
一场新的营销活动、一次集成,或是一项新服务,本不应该从摸清技术能做到什么开始。当每一个想法都需要绕开限制、依赖技术介入或做出妥协时,平台就不再支持业务增长,反而开始拖慢它。
一套通往清晰认知的固定方法
每一次业务上的变更,都必须先绕开技术限制,才有机会被评估其对企业的真正价值。
哪些关联因素让问题持续存在?
需求被固定死
变更变成了例外情况
管理依赖开发人员
日常变更不断延误
集成不断叠加
脆弱性持续累积
从最初印象到真正问题的思考路径。
我们没有一开始就选择解决方案,而是先验证表面上的问题是否就是真正需要解决的问题。
以下内容基于已记录的挑战、目标与成果,对思考过程进行了编辑重构,并非Discovery会议的逐字记录。
最初的观察
新的营销活动和功能,反复受到相同的技术限制。
最初的假设
不完整这个项目本可以被当作对一个已无法满足当下需求的商城进行替换。
为何看似合理
现有商城的限制是具体而实际的,确实延误了营销活动、集成和功能的推进。
促使我们改变判断的原因
需求一直在随着业务的发展而变化。
日常变更依赖于技术介入。
每一次新的集成,都会给现有基础增加新的例外情况。
为何调整方向
替换商城本可以解决当下的问题,但如果不改变平台与变化之间的关系,同样的瓶颈还会再次出现。
新的方向
我们不再罗列缺失的功能,而是转向识别业务会随时间反复出现的变化。
深入分析
每种模式对应的是哪一项原则?
原则 01
原则 02
原则 03
工作方式发生了哪些变化?
此前
每个想法都要向平台申请许可
此后
平台能跟上企业决策的节奏
想法要等待平台
平台能跟上想法的节奏
每次变更都需要技术介入
团队自行管理日常运营
集成如同临时补丁
集成成为系统的一部分
表象背后的根本原因是什么?
表象
功能缺失
真正的问题
基础架构无法承载变化
原则
为已知必然会发生的变化预先构建
“灵活性不代表什么都允许,而是要识别出哪些地方会发生变化,并构建一套让这些变化不再需要推倒重建的基础架构。”
相关思考
当技术开始决定企业能做什么一个当初为解决小问题而选择的平台,多年之后,可能正是一个简单想法需要依靠技术变通才能实现的原因。意识到这个转折点,是第一步。深入了解推理过程下一个案例
行业:专业服务当团队不得不一再打断同一些人,只为了得到一个答案情境会变,方法不变。