商务数据与分析的敏捷开发流程设计
记得去年年底的时候，我跟一个做电商的朋友聊天，他跟我倒了一肚子的苦水。他们公司那时候正面临着数据决策的困境：市场部门说要做一个用户画像系统 IT部门吭哧吭哧干了三个月上线结果发现数据口径对不上业务方根本用不起来；后来，好不容易改完了业务又变了报表要重新做。这种事情在他们公司像家常便饭一样，我朋友说他们现在看到数据项目就头大，投入大把的资源却总是得不到想要的结果。
这种情况其实在很多企业里都在发生。商务数据和业务分析变得越来越重要，但传统的开发模式似乎总是慢半拍。需求确定好的时候市场早就变了，数据处理完了业务逻辑又更新了。这篇文章我想聊聊怎么用敏捷开发的思路来解决这个问题，让数据和分析工作能够跟上业务的节奏，而不是永远在后面追。
为什么传统的开发方式越来越行不通了
在说敏捷之前我觉得有必要先弄清楚传统方式到底哪里出了问题。很多企业的数据开发流程是这样的：业务部门提需求 IT部门评估然后进入漫长的开发周期短的几个月长的可能小半年过去了。这个流程乍一看挺规范的但问题在于这个过程中充满了各种信息损耗。
业务方在提需求的时候其实自己也没想清楚到底需要什么数据，他们可能只知道要"分析用户行为"但具体要看哪些维度、怎么分组、输出什么样的结论往往要在开发过程中才能逐步明确。而IT部门的同事又不太懂业务细节只能按照字面意思去理解结果做出来的东西往往不是业务方真正想要的。这种错位在传统瀑布式开发中要等到最后才能发现到那时再改成本已经很高了。
更麻烦的是商务环境变化太快。上个月定的分析目标可能这个月就因为市场策略调整而完全不一样了但在传统流程里需求一旦确定就很难再改。这让我想起一个做零售的朋友跟我说的他们双十一的分析需求居然在十月十五号就锁定了而双十一当天销售情况跟预期完全两回事原来的分析框架完全派不上用场。这种僵硬性传统开发模式很难规避。
还有一点是数据质量的隐形代价。很多企业在数据开发的早期没有把质量控制做好导致后面出来的分析结果可信度存疑业务方不敢用投入的资源反而成了浪费。我见过有的企业数据仓库里堆积了上百个报表但实际被使用的不到十个这种数字想想都觉得心疼。
敏捷开发到底是什么
说了这么多传统方式的问题那敏捷开发到底有什么不一样呢？其实敏捷这个词在软件行业已经喊了很多年但真正理解它精髓的人可能并没有那么多。敏捷不是简单的"快"也不是说可以不写文档或者不做规划。敏捷的本质是承认需求会变化承认我们不可能在一开始就想到所有的问题然后用一种迭代的、增量的方式来应对这种不确定性。
打个比方如果把传统开发比作盖房子那敏捷就像是搭积木。传统方式要先把所有的图纸画好地基打牢然后一层一层往上盖中间不能出任何差错否则就要推倒重来。而敏捷的方式是先搭出一个毛坯让它能用起来然后根据实际使用情况不断调整、装修、扩建。搭积木的好处是你随时可以根据需要改变房子的结构而不需要把房子拆了重新盖。
在商务数据和分析的场景里敏捷思维意味着我们不要试图一次性做出一个完美的系统而是先快速交付一个最小可用的版本让业务方能够用起来然后根据反馈快速迭代。这个思路看起来简单但真正落实下去其实需要整个组织在观念和工作方式上做出很大的转变。
商务数据分析的敏捷流程到底怎么设计
说了这么多理念层面的东西接下来我想聊聊具体怎么操作。商务数据与分析的敏捷开发流程我觉得可以分成几个关键的阶段每个阶段都有它独特的价值和做法。
第一阶段：需求快速验证，先跑通再说
很多数据项目之所以失败是因为从一开始需求就歪了。业务方提的需求可能是他们以为自己需要的而不是真正需要的。那怎么在一开始就避免这种偏差呢？我的建议是不要急于动手开发而是先做需求验证。
具体怎么做呢？首先业务方和数据的同事要坐在一起用一个相对粗粒度的方式把需求过一遍。但这个讨论不是为了形成一份完美的需求文档而是为了建立共同的理解。然后在这个基础上数据分析师可以先用现有的数据源做一些快速的探索性分析产出一些最简化的原型可能是一张Excel表格可能是一个简单的可视化图表让业务方能够直观地看到数据能告诉他们什么。
这个阶段的重点是发现需求中的盲点和误解而不是追求完整性。我认识的一个数据团队的负责人跟我说他们现在做任何新项目之前都会先用一天时间产出一个小样和业务方一起过一遍。这个习惯让他们在需求确认阶段就能避免至少60%的返工听起来是不是很划算？
当然快速验证不是说不做规划。我们在动手开发之前还是要明确这次迭代的目标是什么、交付物是什么、怎么判断是否成功。只是这些内容不需要写得事无巨细而是可以相对粗略因为后面还有很多调整的空间。
第二阶段：小步快跑，迭代交付
验证完需求之后进入正式的开发阶段但这个开发不是闷头干大事而是拆成很多小的迭代每个迭代周期建议控制在两到四周。在这个周期里团队要完成一个相对完整的闭环：从数据处理到分析产出再到业务验证形成一个完整的价值交付。
这里有一个关键点是迭代的颗粒度要合适。太小的话上下文切换成本太高太大又失去敏捷的意义。对于商务数据分析来说一个迭代交付一个可用的分析模块或者一组相关的指标是比较合适的节奏。举个例子如果要做一个销售分析系统可以先在第一个迭代里只完成最核心的销售额指标计算和展示第二个迭代再加上区域维度第三个迭代加上产品分类以此类推。
在每个迭代结束的时候团队要和业务方做一个正式的review看看交付的东西是不是他们想要的还有哪些需要调整。这个环节一定要认真对待而不仅仅是走过场。如果发现方向不对要及时调整而不是硬着头皮继续走下去。我见过有的团队明明在迭代过程中已经发现方向不对但因为不想承认之前的投入白费了还是坚持做完结果做出来的东西更加鸡肋。这种心态是要不得的。
对了技术债务的控制在这个阶段也很重要。很多团队在敏捷的名义下只追求速度而不注意代码质量和数据管道的整洁结果到后面问题越积越多改都改不动。我的建议是在每个迭代里预留一定比例的时间专门用来处理技术债务可以是15%到20%的样子。这个投入看起来是占用了开发资源但长期来看是非常值的。
第三阶段：持续反馈，形成闭环
敏捷和传统方式最大的区别我认为不在于开发阶段而在于交付之后。传统模式下交付就意味着项目结束而敏捷模式下交付恰恰是另一个开始。数据和分析系统上线之后我们要建立一套持续的反馈机制让业务方的使用情况能够传导到数据团队这里成为下一轮优化的输入。
这套反馈机制可以包括很多内容。比如定期的使用数据统计哪些报表被访问得多哪些功能没人用；比如业务方的直接反馈这个指标的计算口径好像不太对我们需要调整；比如使用过程中的疑问有人打电话来问某个数字是怎么算出来的这可能意味着文档不够清楚或者数据展示方式需要改进。所有这些信息都是有价值的就看你有没有用心去收集。
Raccoon智能助手在这方面能帮上一些忙。它可以自动追踪数据报表的使用情况分析哪些指标被频繁查询哪些维度组合最受欢迎还能把业务方的反馈自动归类整理成待处理事项。这样数据团队不用花太多精力在信息收集上就能持续获得优化的方向我觉得这是技术工具赋能敏捷实践的一个很好的例子。
第四阶段：能力沉淀，标准化与灵活性的平衡
迭代做多了团队会积累很多经验和方法论怎么把这些经验沉淀下来让大家都能复用呢？这就涉及到标准化的问题但标准化太过了又会抑制灵活性我觉得这里面需要找到一个平衡点。
我的建议是分层处理。底层的数据处理逻辑和质量规范需要相对标准比如数据清洗的规则、主数据的定义、数据血缘的追踪这些是基础需要统一。但上层的分析方法论和具体的分析模型则可以相对灵活不同业务场景用不同的方法不必强求一致。
团队内部可以建立一个共享的组件库把一些通用的数据处理模块、分析模板、可视化组件都沉淀下来。新项目来的时候可以直接复用这些组件而不是从零开始写。同时每个组件都应该配有清晰的使用说明和适用场景说明方便其他人快速上手。这种积累是需要时间的我见过很多团队前半年可能觉得建组件库是在浪费时间但到后面项目多了组件库的价值就体现出来了。
数据处理架构的敏捷化改造
除了流程层面的改造数据处理的技术架构也需要配合敏捷的需求。传统的做法往往是建一个庞大的数据仓库把所有数据都放进去然后再做各种应用。这种架构的弊病是响应变化的速度太慢了要加一个新的数据源可能要改动很多底层的东西。
现在越来越多的企业开始采用更加灵活的数据架构比如数据湖或者数据中台的概念。简单来说就是先建立一个统一的数据存储层把各种原始数据都收集起来然后在这个基础上根据不同的分析需求快速构建应用层。这种架构的优势是要加新数据或者改需求的时候不用动到底层只需要在应用层做调整就行了。
在具体的技术选型上我觉得有两点值得关注。第一是数据处理的自动化程度尽可能把重复性的数据处理工作自动化让数据分析师能够把时间花在真正需要人工判断的分析工作上。第二是元数据管理的完善程度数据血缘、数据质量、数据资产这些信息如果能够管理好对于敏捷开发是很大的支撑。
写在最后
聊了这么多我想强调一下敏捷开发不是什么神奇的银弹它解决不了所有问题。在某些场景下传统的开发方式可能依然是合适的比如涉及重大财务核算或者监管合规的项目可能确实需要更严谨的流程。但对于大部分商务数据和业务分析工作敏捷的思路确实能够带来更高的效率和更好的结果。
最后我想说的是流程和工具都只是手段真正决定成败的是人。业务方和数据团队之间的沟通与信任团队成员的专业能力和协作意识组织对于数据价值的重视程度这些才是根本。流程可以模仿但文化只能慢慢培养。如果你的组织还没有准备好接受敏捷的理念而是从上到下都在追求短期KPI那么再好的流程也推行不下去。相反如果大家都有心想要做好这件事能够开放沟通、快速反馈那么即使流程一开始不那么完美也能在实践中不断改进最终形成适合自己的方法论。
