Open yunmc opened 4 years ago
文章来源： https://bytedance.feishu.cn/docs/doccnrAKU8Bne4qC86CxPnvbOod#X497BW
业务说明：付费专栏（现作者收益）是深耕内容付费领域的团队，提供多种内容付费题材：图文、视频、音频、解读书、电子书、杂志...，提供多种营销能力，建设从付费内容创作、分发、营销、用户管理、经营分析到裂变复购的完整闭环，赋能运营加快转速，致力于树立内容服务商品牌，加强生态变现服务能力，提供满意的用户服务。
业务说明：随着公司产品矩阵的不断丰富，各业务面临来自用户、媒体、监管部门的监管反馈压力日益增长，客服云解决方案定位于公司级别的客服服务中心，包括用户端和工作台，支持多种接入模式（Web、H5、小程序、Native），1.0人/天级别即可为业务方提供实时/离线的反馈交互，智能客服、人工客服处理能力。
_1. 支持10+个业务的实时/离线用户反馈场景
_1. 宿主接入反馈功能耗时降低70%
目标1：输出热点大事件解决方案，与产品协同抽象提炼业务技术模型，将热点大事件进行分层抽象：模版+区块，使用区块组装成模版，通过实例化模板快速应对突发/常规大事件，并且能够通过重新组装、修改可扩展性强的区块响应不同类型大事件的多样化需求。
目标2：输出大事件专题，提升热点消费体验、提升热点站内外影响力，完善从热点发现、热点挖掘到热点分发、热点消费的完整闭环，协同其他职能为热点团队的过程指标和终极指标服务。
热榜列表页：点击数、UTR、审出条数、审出率、榜单内容分类 热榜落地页：人均时长、PV停留时长、Top10 120s+日均、CTR 大事件专题：PV、CTR、用户停留时长
在字节的2年多时间里，精力基本都投入在内容创作、内容审核、内容分发、作者收益、作者培养...头条的整个内容生态里，主导过的业务包括付费专栏和热点大事件，并且有相应的沉淀和衍生。
付费专栏业务的核心部分属于作者收益的环节，它仍然需要贯穿整个内容生态，只不过相比于UGC来说内容需要更加专业。这里为了方便介绍思考的过程，我把业务发展的过程简单粗暴的分成4个部分：业务、业务中台、技术、团队，当然它们之间是没有先后顺序的，在整个产品生命周期中都需要统筹规划与推进，只不过不同的阶段可能有高优/低优之分、需要解决的问题各有不同。
好好学习产品在方向上进行过一次比较大的调整、从精品课转型到平台服务，而在进行产品方向调整和业务迭代的同时，可以发现不变的是内容付费领域的重营销特性，提升运营效率、赋能运营加快转速是非常重要的，以及在细分方向付费专栏、付费圈子、付费直播、付费问答...逐渐丰富的过程中，暴露出服务复用的需求，所以在高效保质推进业务需求迭代的同时，我也致力于内容付费中台建设的规划和推进。
在规划内容付费业务中台能力时，主要围绕赋能运营和服务通用化2个出发点，其中有些中台能力由于阶段性问题没有能推进到有比较完整产出的，财税平台、会员中台、内容质量管理平台、通用机器人服务...这些是有些遗憾的潜在亮点。
赋能运营 客服云解决方案：支持10+个业务的实时/离线用户反馈场景，所有业务线客服数达1577，IM工作台日接待人工会话数超过10W+ 开票助手：支持3+个业务的用户开票场景，实现自动化、解放运营人力 内容质量评估服务 精细化运营平台：支持 x 个业务的精细化运场景，提供圈选、触达用户的能力 服务通用化 付费内容交易中台 收银台中台能力：支持4+个业务的支付场景，统一业务支付流程、支付体验，支持不同业务的不同支付附属功能特性
建设内容付费中台的终极目标，就是可以通过简单的配置即实例化出一个内容付费业务需要的大部分基础功能，显然这是一个非常漫长的过程，所以我们需要有阶段性的目标和产出，比如说客服云、比如说精细化运营平台，在规划的时候各个基础设施可以独立输出（Open API、通用平台、SDK、组件、页面）、也可以组装成完整的中台能力。
技术建设可以用一个矩阵来定义或者说描述，横轴是业务、质量、体验、效率（研发效率和运营效率），纵轴是业务规划/业务痛点、业务能力/业务解决方案、业务组件/功能、基础设施/最佳实践、技术泛化/技术痛点，以及需要相应的流程机制和文档化来进行辅助。同时需要注意的是：
在说到团队管理之前，我想先总结一下关于个人的成长，简单来说经历过几个阶段：
可以独立完成需求迭代 可以独立解决难题 可以并行处理更多事情 可以为团队做些事情 可以带领大家做好某些事情 不断优化产品 扩大影响力、关注满意度
这几个阶段也是我期望可以沉淀成新人培养路径的方法论，其实每个阶段看起来容易、但是做好并不简单，“可以独立完成需求迭代”不仅需要我们有完备的设计、编码能力，还需要对公司现有的基础设施、服务有必要的了解，才能不断提高生产效率、保证质量，与此同时需求的推进、也就是如何做好FTO的角色也是非常重要的软素质；“可以独立解决难题”，关于这点我想说的是，发现问题、定位问题、明确责任人、给出短期方案和长期方案、反馈，这套方法论是大多数同学还需要改进的；“可以并行处理更多事情”这点上我深有感触的是，一定学会做好目标管理和时间管理，使用合理的工具组织和分配自己的精力，这也是让很多年轻同学感到迷茫的问题之一；“可以为团队做些事情”需要我们能够经常思考、挖掘团队当中存在的痛点，它可以是业务的、也可以是技术的，并且能够给出相对合理有效的解决方案；“可以带领大家做好某些事情”更多的是要求我们能够对复杂度较高的系统进行Use Case的梳理、模块的拆解和子模块间通信方式的设计、合理的制定RoadMap、严格的执行项目管理；“不断优化产品”则要求我们有相应的产品Sense，以及我想说的是，业务、个人、团队...都是可以当作“产品”来不断优化的。
而在能够合理的进行团队管理之前，首先要做好角色的转换：
“工作职责角度，从完成本职工作到带领团队前进的转变；负责对象角度，从对自己负责，到对上级负责、关心团队成员的发展和成长；关注焦点角度，由过程导向转变为结果导向；能力角度来看，由单一的专业能力变为多维的综合能力；任务来源角度，从被动“等活儿”变为主动规划；实施手段来看，从个人贡献者变为依赖团队一起完成；合作维度来看，由平级合作变为多维度的合作；合作关系来看，由平级合作关系变为全面合作关系；思维方式来看，由技术实施视角变为技术评估视角；技术视角来看，由技术实施视角变为技术评估视角...”
而团队管理需要做好的事情包含且不仅包含：项目流程规范的梳理和沉淀、梯度建设、团队文化的沉淀和对组员的正向影响、团队影响力建设。
最近到热点团队小半年左右的时间，大部分的成长是对头条的内容生态有更加完善的了解和贡献，以及对于“团队负责人”有些跟以前不同的理解。
热点业务的全流程从作者发文、热点发现/热点挖掘、热点审核、热点分发、热点消费到作者培养是形成闭环的。当前的业务目标是拉新，对此我是有些存疑的、也没有看到规划内有明确有效的争夺市场的手段，不过其隐性的价值是不可否认的，以及对用户留存、停留时长...过程指标的影响是比较正向的。
热点大事件解决方案的直接诉求来源于抗疫事件，从跨团队协作到基础设施都暴露出很多问题，同时我们发现系列页面当中存在很多可以复用的组件、以及大部分运营行为都是数据的维护，再结合事件本身的聚类性和周期性，我们选择使用区块+CMS的模式把事件产品模型化。团队由大事件专题作为切入口，期望可以在扩展区块业务能力的同时，做好团队基础设施的搭建、梯度建设，再向其他环节输出影响力。
以及在热点团队搭建过程中，对“团队负责人”的理解有2个比较有感触的认识：一方面是需要做好信息的传递和信息的共享，也就是要做好成员管理和向上管；另一方面是需要主动进行规划、而不是在了解问题后针对解决，这样是不利于协调、整合资源的，而规划是需要预见和动态调整的。
对于热点大事件解决方案的未来规划，在高效保质支持功能迭代、能够覆盖更多运营（要闻、热点、垂类...）需求外，还有4个方面的思考：
团队管理机制梳理：
🐂 🍺 /破音
highestop
commented
4 years ago highestop
commented
4 years ago
矩阵
付费专栏&内容付费中台
愿景：服务于1亿用户、创造10万就业机会，成为最大最全的内容付费服务平台
业务
技术
团队
客服云解决方案
目标：输出客服云解决方案，搭建公司统一客服平台，提供多种接入模式
_1. 支持10+个业务的实时/离线用户反馈场景
_1. 宿主接入反馈功能耗时降低70%
热点大事件
目标1：输出热点大事件解决方案
目标1：输出热点大事件解决方案，与产品协同抽象提炼业务技术模型，将热点大事件进行分层抽象：模版+区块，使用区块组装成模版，通过实例化模板快速应对突发/常规大事件，并且能够通过重新组装、修改可扩展性强的区块响应不同类型大事件的多样化需求。
目标2：支持大事件专题，提升热点消费体验、提升热点站内外影响力
目标2：输出大事件专题，提升热点消费体验、提升热点站内外影响力，完善从热点发现、热点挖掘到热点分发、热点消费的完整闭环，协同其他职能为热点团队的过程指标和终极指标服务。
业务
技术
团队
思考
在字节的2年多时间里，精力基本都投入在内容创作、内容审核、内容分发、作者收益、作者培养...头条的整个内容生态里，主导过的业务包括付费专栏和热点大事件，并且有相应的沉淀和衍生。
付费专栏业务的核心部分属于作者收益的环节，它仍然需要贯穿整个内容生态，只不过相比于UGC来说内容需要更加专业。这里为了方便介绍思考的过程，我把业务发展的过程简单粗暴的分成4个部分：业务、业务中台、技术、团队，当然它们之间是没有先后顺序的，在整个产品生命周期中都需要统筹规划与推进，只不过不同的阶段可能有高优/低优之分、需要解决的问题各有不同。
好好学习产品在方向上进行过一次比较大的调整、从精品课转型到平台服务，而在进行产品方向调整和业务迭代的同时，可以发现不变的是内容付费领域的重营销特性，提升运营效率、赋能运营加快转速是非常重要的，以及在细分方向付费专栏、付费圈子、付费直播、付费问答...逐渐丰富的过程中，暴露出服务复用的需求，所以在高效保质推进业务需求迭代的同时，我也致力于内容付费中台建设的规划和推进。
在规划内容付费业务中台能力时，主要围绕赋能运营和服务通用化2个出发点，其中有些中台能力由于阶段性问题没有能推进到有比较完整产出的，财税平台、会员中台、内容质量管理平台、通用机器人服务...这些是有些遗憾的潜在亮点。
建设内容付费中台的终极目标，就是可以通过简单的配置即实例化出一个内容付费业务需要的大部分基础功能，显然这是一个非常漫长的过程，所以我们需要有阶段性的目标和产出，比如说客服云、比如说精细化运营平台，在规划的时候各个基础设施可以独立输出（Open API、通用平台、SDK、组件、页面）、也可以组装成完整的中台能力。
技术建设可以用一个矩阵来定义或者说描述，横轴是业务、质量、体验、效率（研发效率和运营效率），纵轴是业务规划/业务痛点、业务能力/业务解决方案、业务组件/功能、基础设施/最佳实践、技术泛化/技术痛点，以及需要相应的流程机制和文档化来进行辅助。同时需要注意的是：
在说到团队管理之前，我想先总结一下关于个人的成长，简单来说经历过几个阶段：
这几个阶段也是我期望可以沉淀成新人培养路径的方法论，其实每个阶段看起来容易、但是做好并不简单，“可以独立完成需求迭代”不仅需要我们有完备的设计、编码能力，还需要对公司现有的基础设施、服务有必要的了解，才能不断提高生产效率、保证质量，与此同时需求的推进、也就是如何做好FTO的角色也是非常重要的软素质；“可以独立解决难题”，关于这点我想说的是，发现问题、定位问题、明确责任人、给出短期方案和长期方案、反馈，这套方法论是大多数同学还需要改进的；“可以并行处理更多事情”这点上我深有感触的是，一定学会做好目标管理和时间管理，使用合理的工具组织和分配自己的精力，这也是让很多年轻同学感到迷茫的问题之一；“可以为团队做些事情”需要我们能够经常思考、挖掘团队当中存在的痛点，它可以是业务的、也可以是技术的，并且能够给出相对合理有效的解决方案；“可以带领大家做好某些事情”更多的是要求我们能够对复杂度较高的系统进行Use Case的梳理、模块的拆解和子模块间通信方式的设计、合理的制定RoadMap、严格的执行项目管理；“不断优化产品”则要求我们有相应的产品Sense，以及我想说的是，业务、个人、团队...都是可以当作“产品”来不断优化的。
而在能够合理的进行团队管理之前，首先要做好角色的转换：
而团队管理需要做好的事情包含且不仅包含：项目流程规范的梳理和沉淀、梯度建设、团队文化的沉淀和对组员的正向影响、团队影响力建设。
最近到热点团队小半年左右的时间，大部分的成长是对头条的内容生态有更加完善的了解和贡献，以及对于“团队负责人”有些跟以前不同的理解。
热点业务的全流程从作者发文、热点发现/热点挖掘、热点审核、热点分发、热点消费到作者培养是形成闭环的。当前的业务目标是拉新，对此我是有些存疑的、也没有看到规划内有明确有效的争夺市场的手段，不过其隐性的价值是不可否认的，以及对用户留存、停留时长...过程指标的影响是比较正向的。
热点大事件解决方案的直接诉求来源于抗疫事件，从跨团队协作到基础设施都暴露出很多问题，同时我们发现系列页面当中存在很多可以复用的组件、以及大部分运营行为都是数据的维护，再结合事件本身的聚类性和周期性，我们选择使用区块+CMS的模式把事件产品模型化。团队由大事件专题作为切入口，期望可以在扩展区块业务能力的同时，做好团队基础设施的搭建、梯度建设，再向其他环节输出影响力。
以及在热点团队搭建过程中，对“团队负责人”的理解有2个比较有感触的认识：一方面是需要做好信息的传递和信息的共享，也就是要做好成员管理和向上管；另一方面是需要主动进行规划、而不是在了解问题后针对解决，这样是不利于协调、整合资源的，而规划是需要预见和动态调整的。
对于热点大事件解决方案的未来规划，在高效保质支持功能迭代、能够覆盖更多运营（要闻、热点、垂类...）需求外，还有4个方面的思考：
团队管理机制梳理：