再论媒体技术团队建设

2024-09-04 21:28

本文主要是介绍再论媒体技术团队建设,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

  随着互联网发展,新媒体迅速发展,以互联网为基础的新媒体平台,导致了传播格局的剧烈变化,促使整个媒体行业发生了一次以新型信息技术革命为特征的变革。新媒体的发展,与互联网和信息技术是孪生关系,因此改革发展需要导致的媒体技术变革成为必然。

  • 现状分析

传统媒体发展以来,主要以报纸、网站、广播电视为载体,基于这种生产要求,组建以信息中心或者技术中心为主体的二级信息技术部门,主要的职能为保障机构内部各种信息技术需求,作业形态主要为运维工作,核心是保障信息系统和网络的稳定运行,属于为内容生产服务的保障的部门。

其所运维的信息系统,基本上以采购市场上现有的系统和设备为主,再协同供应商和自身的力量进行运维。人员的能力水平、知识结构、薪酬结构、工作机制等,也是按照传统媒体技术需要进行构建,基本可以满足原有的技术需求。

  • 改革动因

互联网和信息技术发展,以商业互联网媒体平台为代表的新媒体平台的迅速发展,对原有的传播格局所带来的冲击,也不可避免的冲击到了机构媒体,流量、广告、影响力、品牌、营收等,甚至于全面的挑战之下,机构媒体为生存而必须要做出改革,改革的方向基本上以新媒体方向为主。既然要向新媒体方向发展,新媒体技术先行是不可回避的问题。互联网平台基本上是以技术先行搭建平台,然后再进行运营,在运营过程之中需要不断的技术投入对平台进行迭代升级,以此来适应运营的需要。而运营过程中所提出的技术需求,又反过来促进了技术的发展。二者是一对辩证统一关系。

面对新媒体改革所产生的技术需求,原有的技术团队的各个方面都难以适应新的需要,传统媒体原有的信息技术部门几乎没有研发团队或者少量的研发团队,很难适应新的时期对大量研发工作的需要。同时,通过继续采购技术的方式,最大的制约是成本大,采购流程长,弹性不足,难以适应业务高弹性的需求,以及随时可能的大量碎片化的技术需求。

因此,面对改革的需要,建设自己的研发团队是现实需要,互联网公司的技术团队与其自身是高度一体的状态,既然新媒体改革方向也是依托互联网的新媒体方向,那么这一特征同样适用于新媒体技术团队,只有如此方能从根本上满足自身的改革发展对技术的需求。

  • 顶层设计

新一轮的改革经常带有翻天覆地的变化,就是对原有的机构媒体内部的人员、平台、流程、机制等等进行最大可能的改造以及最为彻底的改造,以适应新媒体改革发展需要。由于传统媒体的很多机制已经运行多年,改革成本相当高,如果没有决心和相应的投入,很难迅速的推进,容易出现渐进式改革的状态,似乎有所变化,但变化又不尽如人意。

对于技术团队而言,传统的机构媒体的信息技术部门的定位是从属于原来的内容生产为主,顶层架构位置较低,而互联网技术和新媒体技术等研发部门要推进企业数字化转型,需要足够的层级或者相应高层级的制度保障,才能获得足够的投入,也才能具备促进企业数字化变革的能力。并且研发部门大多数情况下是成本型为主,属于投入大但不直接有很大现金流产出的部门。

同时顶层设计当中的人员,一定要有具备新媒体技术研发相对应的技能的管理人才,这种人才属于稀缺资源,要在薪酬上给予保障。并且骨干人员要具备足够的技术能力,由于成本限制和时间要求的原因,不可能让团队都是很高技能水平的工程师,这种情况下就要给骨干人员配备合适的技能的工程师,在骨干人员的带动之下,形成统一的协作体系,达到最大化的技术产出。同时在顶层实际运行中,要在方向正确的情况下,尽可能尊重专业技术人员,给予适当的灵活性、参与度、决策权限。

古人讲,欲治兵者,必先选将。顶层设计中除了专业技术人员以外,机构媒体的特征性决定我们,守正创新,因此原有内容、运营人员也必然不可少,以此来在业务层面与专业技术形成相互补充。毕竟以互联网为主的专业技术人员,在专业方向上能力很强,但在传统机构媒体所从事的内容以及运营方面需要补充相应的知识体系。

基于以上论述,在新媒体改革发展中,技术先行的要求下,很多机构媒体也成立了足够高层的技术决策机构,如企业高层的技术委员会,以此来最大化注入技术动能。同时顶层设计的确立,为技术的发展、地位、资源、决策等提供了保障,企业在信息化、数字化的过程中,需要足够的推动力,才能改变企业原有的长期形成的流程,甚至是人员的习惯,这显然需要足够高的层级完成,很多时候应当是贯穿全企业的“一把手”工程,只有如此方能使得技术力量体现存在的价值。

  • 组织架构变革

组织架构变革,是在技术团队建设当中的关键一环,尤其是技术决策机制和流程,传统媒体的技术团队除了位置较低以外,技术与生产之间联系非常弱,且信息技术部门经常处在相对边缘的位置,主要职能就是支撑。这种情况在以前未必会有大的问题,但在信息技术革命促进的越来越快的状态下,相互之间很难支撑到位,信息没有获得最大化的同步,信息流在企业内部流转慢,给决策层的信息量不够或者没有及时、真实、有效的进行传递。

在解决了顶层设计之后,信息技术部门首先要创建合适的流程,且要带着科学精神和专业精神,及时的组建研发团队,并将决策信息及时不失真的向决策层传递,以更好的辅助企业决策。管理过程中,要对决策信息进行甄别,避免因专业技术领域不同,带来的信息失真以及错误,进而导致不必要的损失和资源的浪费。技术团队要尊重本身的技术规律,要避免被多种信息干扰,导致不科学的技术决策的出现。

传统的机构媒体原有的信息技术部门,以运维为主进行构建,人员的技能和知识结构很难满足新的互联网技术研发的需求,人员当中只有少量的部分可以转型到新成立的研发型的信息技术部门当中,其余人员可以保留在原信息技术部门,继续运维保障好原有的业务,毕竟在改革过程中,技术也不能一蹴而就,总是需要合理的时间过程才能完成研发的原始构建与积累。

新成立的技术团队由于是带有互联网和新媒体技术特征的部门,要尽可能保持其相对的独立性,避免原有的信息技术部门的流程引入,造成新的信息技术部门难以适应,而损失掉研发生产能力。同时新成立的信息技术部门,有高度分工的特点,这与传统的信息技术部门一人身兼多职的情况有很大的不同,分工是协作的需要,也是为了产生更大的技术生产能力在软件工程行业发展中形成的。按照互联网公司的组织架构,体系要尽可能完整,如产品、UI、前端、后端、测试、运维等,且人员配置上要有一定程度的冗余,大约20%即可,避免过度超配人员,成本大且管理成本高,以此避免人员稳定性所导致的生产协作系统的整体稳定性。

同时为了进一步加快技术生产力,组织架构要进行扁平化改造,缩短决策的流程长度,充分的突出专业技术的力量,避免新组建的技术团队的管理过度行政化,而损失大量的技术生产力,尤其研发团队是知识密集型的特点,需要足够的时间投入。扁平化改造之后,决策流程缩短,同时技术管理上层要确保基层有足够的时间,避免过度的行政性工作穿透,当然这并不是说不进行管理,而是将技术管理与行政管理的工作量比例控制在合适的区间,来保障技术团队有更多的时间研究专业。同时技术团队的管理团队,也要避免完全的行政化,管理能力和专业技术能力要不断提升,匹配提升,不能偏科,以免作出错误的技术决策,甚至没有足够的技术能力判断决策的正确性,也无法提出合理的技术决策想法。

同时研发团队的薪酬要尽可能提升,原有的信息技术部门的薪酬存在普遍偏低的情况,很难获得新的研发人员,新的研发人员的薪酬市场变化率频繁,与市场和当前实际情况比较,找到合适的团队而不是最优秀的团队,能够达到自身需要即可引进,先进行原始的技术积累,尤其是对于原来没有任何研发基础的媒体,IT技术人才依然是高价值人力资源,作出合理定位,骨干人员重点投入,工程技术人员合适投入,是机构媒体能够获得研发人员的可持续的方向,这与资本加持的互联网公司有很大的区别,要综合考量自身的经济负担能力,找到合适的团队和自己能够养活的起的团队。

同时要有相应的激励和措施来保障团队的稳定性,由于新组建的研发团队人员本身在市场当中具备一定的竞争力,再加上成本以及诸多限制因素,很多情况下都是最小化的团队配置,人员本身冗余度低,甚至于个别人员的离职,经常会导致整个技术生产系统生产能力下降,甚至降低。尤其在高度分工的情况下,人员之间有技能不通用,很少有人能够同时从事两个工种,再加上现在的信息系统的体量越来越大,实际需要的代码行数越来越大,单人能够产出的代码量有限。

团队规模以达到最精简化配置为适宜,综合考虑整体技术投入成本,几十至百人左右的团队就已经足够大了,且媒体技术的发展不会一直不停,研发工作成熟之后,必然要面临技术生产力过剩,为养活技术团队必然要考虑对外进行技术能力输出,但媒体技术的市场较小,同质化严重,输出难度大,且高度区域化,很多时候技术团队只能是补贴性的成本覆盖,很难自负盈亏。

在实际运转过程中,要科学合理的对我们的组织架构进行重构,以适应当时的情况下的需要。

  • 生产流程重构

由于软件工程行业新的变化,尤其是新组建的技术团队,一开始就要进行大规模的系统的研发,以支撑传统媒体改革发展的需要,这不同于传统的信息技术部门的琐碎的运维工作,琐碎的运维工作,经常存在行政化和流程化较重的情况,整体产能很低,而且容易出问题。

对于规模化的项目而言,必须要用科学的项目化的管理流程,这是人类上千年实践总结而来的最佳实践,如基于PMP国际项目管理体系的方式,ACP敏捷项目管理方式,信息化工程项目管理等,这些体系非常成熟,不需要过多的考虑,但在实际项目中要灵活运用,不能一味的追求体系的完整性,而不考虑团队的规模和能力,需要根据实际的项目需要和团队情况参照性进行流程的裁剪,流程的目标是生产力的提升,不是阻碍生产力发展,不可太过理论化,要从实际出发。

在研发过程中,要科学的实施研发管理,运用敏捷开发等软件工程的科学方法,尽可能快速的交付软件功能而非产品,以达到媒体融合改革的快速的技术需求的响应,但在原始系统创建期,要充分调研,合理设计,尽可能多的考虑到系统扩展的需要。在合适的时间,可以将软件功能进行产品化改造,以适应技术运营的需要。

同时初期系统构建时,高层要给予技术团队一定的时间和支持,从0到1开始构建直接应用一个软件系统,本身困难非常多,有技术层面的,如技术难点、技术风险、技术人员技能不足等,也有非技术层面的,如体制机构、决策流程、作业流程等,信息化本身能够解决的部分也是有限的,不能一味的要求技术将所有事项全部技术化处理。

在实际的研发管理过程中,要结合组织的扁平化、研发流程的规范化、人员考核、团队建设、学习培训、技能提升等全维度的考虑,来保障研发流程的顺畅,以及技术生产效率的较高产出。于此同时,生产流程要站在系统论的角度,来综合考虑整套流程最大的生产输出量,合适的时候对流程进行合理的再造和调整,以达到最合适的量值。

  • 人才和知识结构重构

对于一个标准的软件开发小组,6-7个人为形态的作坊式的软件生产是常见的情况,这也是分工协作管理的最大化效能要求。在媒体技术团队创建过程中,也可以参照这个模型,人才配备要以骨干关键人才和普通工程技术人员搭配,好的技术人才效率高,但也存在环境适应方面的挑战,管理成本也高,如果团队当中全部都是非常厉害的人,成本高、团队协作效能有可能下降。同时技术生产人员的结构,要坚持扁平化基础下,尽可能完整建制的生产,如结合项目化、产品化的配置,在同一个项目上所有的人力资源要尽可能的最大化的被调动,项目的组织架构尽可能多的采用弱矩阵方式,减少过程中调度人力的难度。并且要避免扁平化之后,纵向扁平了,但是横向扩展太过,在实际工作过程中会导致人员水平方向过于分散的问题,一定程度上会割裂生产协作,引入过多的流程损耗。

技术团队的知识结构要合理配置,以实际技术需要为准,在合适的时间进行知识重构,但知识重构成本往往较高,不能要求团队什么都会,避免出现多而不精,人员损耗了大量的执行时间,精力过度分散。同时知识结构要站在全局的角度,充分考虑整个团队需要的知识,这些知识是团队技术整体能力的体现,不是单个或者少数技术人员所具备的特长。一切的目标是以团队的最大化生产输出为基础,如果知识分散,团队难以形成系统性生产能力,无法承担规模化项目,很容易陷入到个体生产的状态当中,生产率受到极大的限制。

  • 研发方向与创新方向选择

媒体技术团队研发的主要方向,依然是先推进自身的技术改革和技术需要,满足自身的前提之下,再寻求可能的技术输出,互联网技术投入巨大,但直接产出往往较低,媒体技术所具备的技术性含量,主要以应用型为主,换句话说,就是以互联网产业成熟的技术应用到自身为主,即使现在新的AI领域的媒体应用,也是有条件的媒体在可能的资金支持下,储备自己的技术人员,加上行业的合作形成应用的能力,在边界进行创新尝试。更多的媒体技术科技引领,依然是在资本加持之下的大型企业,或市场上的专门的科技公司在努力创新创造,尤其是基础技术的研发这种高投入,产出不一定保障的高风险型的研发,很多时候机构媒体很难负担。

同时在应用型为主的状态下,技术合作是必要的,但要选择相对开放的平台,避免由此引入新的技术制约,虽然部分能力自己研发,但不可避免存在技术外部依赖,要尽可能采用云计算等开放平台的架构,以开放性减少技术依赖的被供应商再次限制的情况。于此同时不能忽视自身核心技术研发能力的构建,现行的IT技术很多是基于开源软件生态进行构建,在掌握初步的研发能力之后,要努力加深技术研发的深度,在合作技术无法满足的情况下,有自己相应的备用技术可以替代使用,从而长久的保持一定的核心技术竞争力。

于此同时,在选择研发所使用的技术体系时,应当尽可能采取较新的体系,选择技术团队能够驾驭的较为成熟的技术体系。随着软件工程的发展,虽然学习的资料越来越多,但新技术的学习门槛实际上越来越高,学习曲线是在上升的。因此选择合适的技术体系是对学习成本的关键衡量,尤其是在团队创建初期,直接影响技术团队的生产率。

在创建团队之后,形成初步的研发能力以后,具备一定的应用型创新能力,就可以尝试向新的领域进行创新,这是一个渐进的过程,但创新的方向依然在依赖于团队的技术水平和知识结构,需要相适应的技术团队,如此才能达到团队与产出相适应。同时企业内要努力创造创新文化、工程师文化,尤其是支持小步快跑式的创新,由于投资能力原因,企业要保持一定量的支持创新的资金。

  • 技术运营与宣传

媒体技术宣传要切合实际,很多时候由于媒体属性的原因,对外宣传技术能力的时候,可能会出现被夸大的情况,这种情况会造成不切实际的问题,进而影响了自身的核心技术能力的提升,也给品牌的实质性提升带来不好的影响。因而在对外宣传的时候,避免假大空的问题。

如果条件允许,应当就技术的经济价值展开技术运营,单纯的技术研发受限于思维方向的原因,很多时候创造的技术产品存在运营方面经济价值体现不明确的情况,容易就技术而论技术,此时应当配置一定量的负责技术运营的团队,将运营的需求与技术本身进行更加深度的结合,以体现一定的经济价值。

  • 后记

技术发展日新月异,只有保持开放的思维,才能拥抱变化,只有保持对科学和技术的追求,才能不断促使自己创新。机构媒体转型发展过程中,技术力量不可忽视,但往往受限于专业技术人员能力体系不够完整,尤其是通用能力方面,导致经常出现业务和技术脱节的现象,仅以此文与同行探讨。如果可能,本人将努力就信息技术在媒体领域中的应用与各行业专家探讨,不当之处,敬请批评指正。

这篇关于再论媒体技术团队建设的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1137078

相关文章

【专题】2024飞行汽车技术全景报告合集PDF分享(附原数据表)

原文链接: https://tecdat.cn/?p=37628 6月16日,小鹏汇天旅航者X2在北京大兴国际机场临空经济区完成首飞,这也是小鹏汇天的产品在京津冀地区进行的首次飞行。小鹏汇天方面还表示,公司准备量产,并计划今年四季度开启预售小鹏汇天分体式飞行汽车,探索分体式飞行汽车城际通勤。阅读原文,获取专题报告合集全文,解锁文末271份飞行汽车相关行业研究报告。 据悉,业内人士对飞行汽车行业

金融业开源技术 术语

金融业开源技术  术语 1  范围 本文件界定了金融业开源技术的常用术语。 本文件适用于金融业中涉及开源技术的相关标准及规范性文件制定和信息沟通等活动。

AI(文生语音)-TTS 技术线路探索学习:从拼接式参数化方法到Tacotron端到端输出

AI(文生语音)-TTS 技术线路探索学习:从拼接式参数化方法到Tacotron端到端输出 在数字化时代,文本到语音(Text-to-Speech, TTS)技术已成为人机交互的关键桥梁,无论是为视障人士提供辅助阅读,还是为智能助手注入声音的灵魂,TTS 技术都扮演着至关重要的角色。从最初的拼接式方法到参数化技术,再到现今的深度学习解决方案,TTS 技术经历了一段长足的进步。这篇文章将带您穿越时

系统架构设计师: 信息安全技术

简简单单 Online zuozuo: 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo :本心、输入输出、结果 简简单单 Online zuozuo : 文章目录 系统架构设计师: 信息安全技术前言信息安全的基本要素:信息安全的范围:安全措施的目标:访问控制技术要素:访问控制包括:等保

前端技术(七)——less 教程

一、less简介 1. less是什么? less是一种动态样式语言,属于css预处理器的范畴,它扩展了CSS语言,增加了变量、Mixin、函数等特性,使CSS 更易维护和扩展LESS 既可以在 客户端 上运行 ,也可以借助Node.js在服务端运行。 less的中文官网:https://lesscss.cn/ 2. less编译工具 koala 官网 http://koala-app.

Spring的设计⽬标——《Spring技术内幕》

读《Spring技术内幕》第二版,计文柯著。 如果我们要简要地描述Spring的设计⽬标,可以这么说,Spring为开发者提供的是⼀个⼀站式的轻量级应⽤开发框架(平台)。 作为平台,Spring抽象了我们在 许多应⽤开发中遇到的共性问题;同时,作为⼀个轻量级的应⽤开发框架,Spring和传统的J2EE开发相⽐,有其⾃⾝的特点。 通过这些⾃⾝的特点,Spring充分体现了它的设计理念:在

java线程深度解析(六)——线程池技术

http://blog.csdn.net/Daybreak1209/article/details/51382604 一种最为简单的线程创建和回收的方法: [html]  view plain copy new Thread(new Runnable(){                @Override               public voi

java线程深度解析(二)——线程互斥技术与线程间通信

http://blog.csdn.net/daybreak1209/article/details/51307679      在java多线程——线程同步问题中,对于多线程下程序启动时出现的线程安全问题的背景和初步解决方案已经有了详细的介绍。本文将再度深入解析对线程代码块和方法的同步控制和多线程间通信的实例。 一、再现多线程下安全问题 先看开启两条线程,分别按序打印字符串的

SSM项目使用AOP技术进行日志记录

本步骤只记录完成切面所需的必要代码 本人开发中遇到的问题: 切面一直切不进去,最后发现需要在springMVC的核心配置文件中中开启注解驱动才可以,只在spring的核心配置文件中开启是不会在web项目中生效的。 之后按照下面的代码进行配置,然后前端在访问controller层中的路径时即可观察到日志已经被正常记录到数据库,代码中有部分注释,看不懂的可以参照注释。接下来进入正题 1、导入m

Science Robotics 首尔国立大学研究团队推出BBEX外骨骼,实现多维力量支持!

重复性举起物体可能会对脊柱和背部肌肉造成损伤,由此引发的腰椎损伤是工业环境等工作场所中一个普遍且令人关注的问题。为了减轻这类伤害,有研究人员已经研发出在举起任务中为工人提供辅助的背部支撑装置。然而,现有的这类装置通常无法在非对称性的举重过程中提供多维度的力量支持。此外,针对整个人体脊柱的设备安全性验证也一直是一个缺失的环节。 据探索前沿科技边界,传递前沿科技成果的X-robot投稿,来自首尔国立