互联网化敏捷管理的一篇方法论文章:《场景式建设与流量化运营》

smartsteven 2017-12-04 01:24:49
一、互联网化转型之惑
时代进步往往会让新鲜事物变成组织与个人生活中的必需品,当“互联网+”全然融入人们生活的时候,传统企业也早就过了仅仅打出“互联网+行业名字”之类口号的阶段,真正要考虑怎么进行互联网化转型了。转型是为求生存、省成本、跟上平均的社会生产力水平,这些离不开信息系统的支撑。
连接Internet、搭建网站、做出APP、开通微信号,都不等于做完了互联网化中的信息系统功课,尤其是想深耕互联网、达到大步超越的目的时。互联网的速度、病毒式的传播、极致化的体验,都会让传统信息化建设方式显得落后与乏力。
越来越多的传统企业通过互联网化转型为企业带来高效生产力,但高管们常会有对这一转型产生困惑。CIO困惑,手下以往的精兵强将为何跟不上节拍;CFO困惑,搞起互联网后,IT投入产出更加不好评估与控制,总担心迭代空耗钱,不知道试错何时了;CEO更困惑,尽管学些了新技术、新思维,但在信息系统方面,总是感觉总花钱用了互联网化的“术”,却没有抓住互联网化的“道”。
信息系统对于企业互联网化的关键作用毋庸置疑,但到底怎么让信息系统在企业互联网化转型中做到位又不越位呢?以下将以“场景式建设”和“流量化运营”的双路径作为主轴,探讨企业互联网化转型中的IT之道。

二、场景+流量的双路径探索
企业信息化实践,离不开IT建设和IT运营(或运行)两个关键环节。传统信息化中,因为行业特点差异,部分行业的IT建设以定制开发软件为主,还有不少行业以购买成熟软件后实施为主。在深度互联网化过程中,企业或多或少都要做一些定制开发。在技术公司售前人员、咨询公司专家顾问的口中,互联网化被打了“敏捷”“迭代”“云计算”“人工智能”“微服务”等一系列标签,但对于不同企业,这些标签不能包治百病。针对CEO、CFO和CIO相对宏观的视角,本文提出进行互联网化转型的两项新理念:场景式建设和流量化运营。
场景式建设,是以商业模式下有价值的场景为中心,以场景驱动研发组织及人员矩阵调整,面向场景做需求分析与优化,执行场景交错的任务管控,基于场景功能点分解管理进度,加强场景复制式快速开发,进行参数管理型场景配置简化,加强测试与交付的场景互动管理。
流量化运营,是将互联网访客流量作为IT运营关注的主变量,围绕流量的变化保障网络资源,基于流量带来的压力调整运算能力,评估流量驱动的数据增速提供存储能力,以流量的落点不同、密度不同进行应用容量的应对,靠流量的走向分析促进系统的优化改进。
本文看似为场景和流量两个热点概念设计了另类用法(在纯互联网公司里这两个名词往往不用在此处),但这实际上恰恰是对于传统企业转型的量身订制,将传统企业在这两方面的差距确立为其IT关键环节的主轴,形成双路径格局。在双路径中,场景式建设是基础,没有建设就没有运营;同时,即使考虑迭代建设的因素,流量化运营在时间周期、资源投入上上仍将占据更大的比例。

三、场景的魔力:场景式建设的理念与设计
场景式建设的核心理念是围绕企业互联网化中可能遇到的新商业模式,配套安排研发资源、组织研发工作、管控研发过程。在具体设计中将通过以下七方面加以落地,充分发挥场景在引导IT建设中的“魔力”。
1.场景驱动的研发组织及人员矩阵调整。研发组织内,人员的排布需要适应系统建设的特点,职能化、流程化、矩阵化等不同的组织模式均有各自优缺点。所谓场景驱动,是对场景分类编组,以场景群的方式编排人员。如此编排下,矩阵排布和项目边界切割的依据将不再是内部管理单元分工或业务类型分解,而是场景群。同样的场景群,对应IT人员需具备的技能和经验要求趋同,管理起来也更具有针对性。
2.面向场景的需求分析与优化。场景往往是诞生于与客户的交互中,先天具有很强的客户需求属性,面向场景做需求分析,更体现了互联网以客户为中心、给客户极致体验的理念。不断改造场景的要求是需求优化的重要源动力,在一定程度上,互联网系统的需求正是为创造场景而生、为改进场景而变。
3.场景交错的任务管控。企业互联网化转型中,一般都会有相当规模的信息系统建设任务,各种维度的任务并发并行时,新商业模式的灵活多变会带来场景在时间、空间、资源调度上的交错。任务管理中必须面对场景交错的局面,在时间空间的多维度任务交叉中安排项目工作,管理者需要具备在优先级难于排定的状态下做出取舍的能力,以及见缝插针调度好任务的工作技巧。
4.场景功能点分解的进度管理。由于互联网业务需求的多变,IT建设的进度通常会被市场的快速变化而不断打乱,进行场景功能点的分解便是为了应对这一问题。在研发建设中对场景系统实现过程进行功能点分解,进而结合功能点管理进度,达到有效可控的里程碑目标,实现系统交付的快速成果化。
5.场景复制式快速开发。虽然互联网商业模式创新不断,但在一定时期内,场景间存在复制的可能性,而不同场景的系统实现上更有相通规律。前述功能点分解为场景复制式的快速开发提供了一定的技术基础,由此加快速度、提高复用度,是节省企业成本、快速抓住商机的有效方法。
6.参数管理型场景配置简化。作为场景复制的一种变通,参数管理型场景配置是另一种提高研发建设效率的方法,以场景为对象把握同类场景的规律,抽象出共性规律建设系统,同时将可配置的参数预留于系统中,在互联网销售活动或服务工作中适时调整,实现场景配置的简化管理。
7.测试与交付的场景互动管理。软件测试及版本交付是建设的最后一环,需要对之前的建设成果进行功能、性能验证,并结合场景管理的时间特点,适时发布软件版本,将前期以场景为目标的开发,向真实的场景推送发布。
当系统建设全流程以场景为主轴时,企业将体会到建设的目的性更强,导向性更准,是为场景的“魔力”。传统企业随场景做互联网系统建设,能够提升速度、改善效果,助推企业的互联网转型。

四、流量的秘密:流量化运营的理念与设计
在传统IT治理领域,运营和运行一般会被划开,前者指业务运转管理,后者指计算机系统的运转管理。其实从字义来讲,无论是中英文,二者都没有显著差别。互联网企业和互联网化的传统企业里,二者的界限更是在淡化,业务运转和IT运转大有融合之势,所以本文统一用运营来表示系统建设后的运转管理。影响IT运营的因素多、层面多,运营岗位人员需要关注方方面面。如果企业做互联网化转型,会发现流量是一个很有意思的变量,扣紧流量往往就能抓住互联网化下IT运营的关键。
互联网信息系统的部署环境,上云了也好,自主部署也好,都离不开自下而上的物理层、网络层、主机层、系统软件层、应用层和数据层的运营保障。公有云环境中底层外包的偏多,私有云和自主部署下则需要自己统管。如果按各个层面分头去规划、设计、操作、监督,互联网系统的建设者、管理者会分散很多精力。但如果选择流量这一变量作为关键要素应对,就将以用户行为数据为抓手,观测用户的最终体验,用体验反推系统的问题。流量变成了系统运营状况的晴雨表,蕴藏着IT运营的“秘密”。
1.围绕流量的变化保障网络资源。互联网系统里说的流量是数据流,数据流有业务场景设计时预期的方向和速度。如果发生了偏差,有必要先审视网络管理是否出现问题,路由与访问控制是否影响了正常数据流,同时要定期主动优化网络,保障流量的顺畅。
2.基于流量带来的压力调整运算能力。主机性能决定着运算吞吐量,流量多也就需要吞吐得多,此处同样需要像网络资源管理一样的问题审视与主动优化。
3.评估流量驱动的数据增速提供存储能力。流量多少往往会影响数据增速,在大数据时代,数据需要存储更全、更久、更便于取用,所以存储保障也需要视流量而定。
4.靠流量的走向分析促动系统的优化改进。互联网系统的引流需要成本或品牌影响力,走向反映出的应用状态不佳可能会浪费有形或无形的成本,据此加强优化改进,才能让“春雨贵如油”的流量充分发挥价值。
在互联网系统IT运营中专注流量所揭示的“秘密”,将更容易发现运营问题,并且反溯建设阶段留下的隐患。有了基于流量的运营管理,云计算才能发挥最大价值,云托管能让CEO放心,运营才能提升效度。

五、双路径的实践与交融
场景式建设与流量化运营在企业落地实践,首先需要组织保障。CEO和HR经理们一般都不吝惜为此配置互联网技术专家,但同时也不能忽视互联网管理专家的配备,组织里需要有在企业互联网化方面懂管理、善于管理、适合管理的核心人员。
文化也是实践的重要基础。互联网化的企业要有开放的氛围让大家讨论新商业模式对IT的影响和对策。场景是融合出来的,流量是呵护出来的,要挖掘、培育、鼓励企业里有心的人、有心的建议。
在双路径实践中,高管角色很关键。CEO要关心IT的大方向;CIO要关注企业实际动作;CFO要依旧管住钱。从资金投入角度看,双路径必然要多花钱,但只要每一步努力做到有效率、有积累就依然值得。
在企业互联网化进程中,双路径间彼此的交融必不可少。建设与运营本来就密不可分,场景与流量又于此衔接,场景带来流量,流量烘托场景。场景式建设时,需要算好流量化运营的资源量,流量化运营的管理者,要定期将监测数据反馈给场景式建设,不正常的流量有可能会带来建设的改进。
交融的过程中难免会有冲突,场景式建设与流量化运营之间,谁快谁慢,谁好谁赖,会在急难险重的任务前出现冲突,会在价值贡献评估时分不太清。甚至有的时候,建设环境和运营环节,都在各自为企业战略目标努力,但合在一起却产生反作用,这就更需要管理者做好二者的交融。
...全文
592 4 打赏 收藏 转发到动态 举报
写回复
用AI写文章
4 条回复
切换为时间正序
请发表友善的回复…
发表回复
taotao1112 2018-05-02
  • 打赏
  • 举报
回复
先收下了,谢谢分享
smartsteven 2017-12-06
  • 打赏
  • 举报
回复
我们实践中也在是否用软件管理的问题讨论过,还特意看了别人的做法,初步认识是,脱离软件管理工具应该都可以支撑,但如果针对跨国搞开发,站会都是远程的,所以工具就成为必须了(这种跨国站会实际参加过一次)。
smartsteven 2017-12-06
  • 打赏
  • 举报
回复
其实,场景不成为阻碍,按照敏捷研发的理论,能拆解好。实际中我们比较怕的是一些时间因素混杂进来,场景交错了,就头大了。
fansay521 2017-12-05
  • 打赏
  • 举报
回复
请教,场景交错的任务管控、场景功能点分解的任务管理,正是敏捷实践时与互联网系统一些复杂情况冲突的焦点。套用楼主这套方法论,可以说是功能好拆解、场景难拆解,您实践中有什么好对策么?

1,557

社区成员

发帖
与我相关
我的任务
社区描述
软件工程 敏捷开发
社区管理员
  • community_144
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧