团队 | 不同阶段产品打造适配的产研团队

一、背景

某次,和业务聊天,业务反馈了一个事情,自从团队纳入体系后,觉得团队的产出变慢了,虽然一切看上去有条理,但做出来的产品缺乏灵魂。

我有点惊讶,然后细问,对方表示,以前团队虽然乱,但是做出来的产品是有灵魂,感受到大家的激情。现在虽有章法,但是挺机械,简单来说,团队气氛微妙。

基于这个出发点,我也去思考了一个问题,不同阶段产品究竟要打造一个如何适配的产研团队呢?(会基于在公司接触的产品来分析)

1. 产品生命周期

每一个产品都有生命周期,产品生命周期是指产品从进入市场到退出市场的周期性变化过程,一般分为探索、成长、成熟、衰退四个阶段。

不同发展阶段产品对应的产研团队规模不同、组织架构不同,所以团队的协作方式也需要随之变化。

2. 团队协作

想要做好产研团队的内部协作,人和事两方面缺一不可。一方面,团队成员间需要做到开放合作、互相信任,另一方面,团队需要有统一的目标、合理的任务安排,以及有效的沟通

二、探索阶段(A产品-某数据产品)

1. 阶段概述

1)产品特点

  • 产品方向还未完全得到市场验证;
  • 一般只具备核心功能,且功能简单粗糙;
  • 用户数量少,且增长缓慢。

2)产品策略

  • 只做核心功能,用低成本的方式进行试错;
  • 通过快速迭代来响应市场需求,调整产品方向。

3)团队特点

  • 装备轻便的作战小组。团队规模为6人,基本上每个职能都只有一个人,但职能分工完整;
  • “项目式”组织架构。团队以实线项目团队为主,以虚线职能团队为辅,由项目团队进行向上汇报。

4)团队协作难点

  • 产品方向不确定。产品前途不明朗,产品方向经常调整可能会影响团队信心;
  • 版本节奏不规律。探索阶段产品要快速响应市场需求,所以无法很好计划版本节奏。

5)理想团队状态

  • 团队成员开放合作、互相信任;
  • 能快速响应版本规划。

2. 团队氛围

由于探索阶段产研团队规模较小,所以团队氛围构建的难度也相对较小,可以通过以下方式提升团队氛围:

  • 团队负责人很重要。团队负责人自己要做到开放合作、互相信任。
  • 挑选团队认同度高的人。从一开始就尽量挑选跟团队比较契合,且认同团队的人。
  • 尽可能为团队创造良性沟通的机会。包括工作环境中沟通和非正式环境中的沟通。
  • 产品相关的仪式感。对产品过程中得到的良好反馈或阶段性进展进行有仪式感的庆祝。

3. 产品目标

探索阶段的首要目标是验证市场需求,而对于B端产品来说,有用户愿意为产品付费是市场需求得到验证的硬指标,所以探索阶段的产品目标为购买客户数,产研团队的工作也应该围绕着提升购买客户数来展开。

4. 任务管理

任务管理包括版本节奏、工作计划、任务分配及任务跟踪四个维度。

1)版本节奏

探索阶段的产品需要根据市场反馈进行快速迭代,所以在考虑版本节奏时既需要小步快跑,又需要灵活机动。综合行业情况、用户现状,我们最终确定常规版本节奏为按月进行版本发布。但产品经理可根据临时需求&bug的紧急程度在月度版本间插入小版本,或者根据临时需求的开发工作量与开发经理等量置换计划任务,然后做开发计划的变更。

2)工作计划

由于探索阶段的产研团队基本等同于项目团队,所以产研团队的工作计划也基本等同于项目计划。

3)任务分配

在项目上线时间及里程碑节点确认后,由团队成员认领相关任务,并形成个人总体工作计划、周工作计划、日工作计划。

4)任务跟踪

根据个人总体工作计划、周工作计划、日工作计划重新汇总成项目进度,来进行项目进度监控、个人工作量评估及个人任务跟踪。

5. 团队沟通

影响团队沟通的因素有沟通形式和沟通模式。

不同的沟通模式具有不同的优缺点,不同发展阶段的团队情况不同,所以需要根据所在阶段的特点,选择适合的沟通模式。

探索阶段由于外部环境多变,需要产研团队灵活响应外部需求变化,所以本阶段的团队沟通模式为轮式沟通模式。

轮式沟通模式具有信息传递速度快,沟通效率高的优点,且由产品经理作为过程中信息沟通的核心,产品经理一方面可以接收所有的信息,有利于了解、掌握、汇总全面情况,另一方面可以迅速把自己的意见反馈出去,确保沟通过程中的信息不失真。

探索阶段的沟通形式为口头沟通(占比50%)、群消息沟通(30%)、书面沟通(10%)及会议沟通(10%)。基于上述轮式沟通模式,通过各种形式的沟通信息最终都会汇总到产品经理处。

三、成长阶段(B产品-某投放产品)

三、成长阶段

1. 阶段概述

1)产品特点

  • 产品方向已得到验证;
  • 产品更新迭代快;
  • 产品复杂性增加,可能会由单一产品变为产品矩阵。

2)产品策略

  • 优化核心功能产品体验;
  • 丰富产品应用场景,更好地满足用户需求;
  • 开始考虑产品的稳定性、数据安全性以及功能可扩展性。

3)团队特点

  • 专业作战的敏捷小组。团队规模为9~14人,每个职能都开始人员扩充,逐渐演化为小团队;
  • “矩阵式”组织架构。团队仍以项目团队为主,职能团队为辅,项目团队负责产品目标落地,职能团队负责人员培养与调配;
  • 多项目组。原有的单一产品发展为产品矩阵,相应团队也变化为多项目组。

4)团队协作难点

  • 项目团队与职能团队双线管理。每一个成员都既属于项目团队,又属于职能团队;
  • 不同项目组间资源调配。项目组间涉及技术、人员共用,导致项目组间存在资源调配情况;
  • 产研过程要求兼具规范与灵活。成长阶段的产品具有一定客户基数,产品的任意改动都会影响到客户以及销售、市场等协同部门,所以产研过程需要具备规范性。但是成长阶段的产品仍然需要快速响应市场需求,所以产研过程也需要具备灵活性。

5)理想团队状态

  • 团队成员梯队合理、分工及协作内容明确;
  • 职能团队具备一定的专业性;
  • 项目团队执行力较强。

2. 团队氛围

随着产品的增长,各个职能都开始扩充人员,导致产研团队总体规模扩大且逐步演化为“矩阵式”组织架构。新成员加入、团队规模扩大和“矩阵式”的组织架构都会一定程度上为团队氛围建设带来新的问题,例如:新成员的融入问题、新老成员的融合问题、职能团队和项目团队的归属问题等。

为了解决上述问题,可以通过以下方式促进团队氛围:

  • 挑选团队认同度高的人。从一开始就尽量挑选跟团队比较契合,且认同团队的人;
  • 导师带教制度。新成员加入时安排一对一导师进行带教,帮助新成员进行融入;
  • 按照职能进行座位安排。有利不同职能岗的团队成员归属感和专业学习;
  • 按照项目组织活动。可以通过团建、团队运动等形式来增加团队的集体活动;
  • 产品相关的仪式感。对产品过程中得到的良好反馈或阶段性进展进行有仪式感的庆祝。

3. 产品目标

成长阶段的首要目标是产品快速增长,而“新增订购客户数”能很好地体现产品增长情况,所以成长阶段的产品目标为“新增订购客户数”,产研团队的工作也应该围绕着提升新订购客户数来展开。

4. 任务管理

任务管理包括版本节奏、工作计划、任务分配及任务跟踪四个维度。

1)版本节奏

成长阶段的产品,大方向已经确定,未来的迭代相对比较可预测,且需要协同市场、销售、服务等部门进行营销、服务,所以需要规律的版本节奏。综合行业情况、用户现状,我们最终确定版本节奏为一年两次大版本,在此期间,产品经理可针对临时需求&bug的紧急程度,以及开发资源情况安排不固定的小版本。

2)工作计划

成长阶段的产研团队为项目团队为主,职能团队为辅的“矩阵式”组织架构,所以产研团队的工作计划等同于多个并行项目的项目计划。

项目团队分别按照所属项目版本节奏来制定项目计划,职能团队基于项目计划进行项目间的人员调配。

3)任务分配

在项目上线时间及里程碑节点确认后,由项目团队成员认领相关任务,并形成个人总体工作计划、周工作计划、日工作计划。

4)任务跟踪

根据个人总体工作计划、周工作计划、日工作计划重新汇总成项目进度,来进行项目进度监控、个人工作量评估及个人任务跟踪。

5. 团队沟通

成长阶段要求产研团队同时具备专业性与灵活性,所以本阶段的团队沟通模式比较多样化,具体应用中会涉及到链式沟通、Y式沟通、全通道式沟通三种沟通模式。

项目团队基于链式、Y式沟通模式,通过需求评审会、日报、项目周会、月度总结会来进行项目需求与进度沟通,基于全通道沟通模式来进行项目团队内跨职能协作。

成长阶段的沟通形式为口头沟通(占比20%)、群消息沟通(20%)、书面沟通(20%)及会议沟通(40%)。

四、成熟阶段(C产品-某订单系统)

1. 阶段概述

1)产品特点

  • 产品核心功能稳定;
  • 用户量稳定波动。

2)产品策略

  • 维持高质量且稳定的产品和服务;
  • 寻找新的业务方向。

3)团队特点

  • “矩阵式”组织架构。产研团队变为职能团队为主,项目团队为辅的“矩阵式”组织架构,并增设项目经理岗位负责全部项目的统筹与跟进;
  • 分设产品规划团队。产品规划团队负责产品长期规划及新产品探索。

4)团队协作难点

  • 项目组成员不固定。由于项目是不定期开展的,所以项目组也不是固定成员;
  • 不同项目组间资源调配。项目组间涉及技术、人员共用,导致项目组间存在资源调配情况;
  • 需要平衡研发过程中的规范性与效率问题。为了提升协作过程中的规范性,增加了留档、校验等步骤,会对研发效率有影响;
  • 职能团队管理问题。职能团队重要性提升后,对职能团队负责人的管理能力要求提升了。

5)理想团队状态

  • 每个职能团队都形成梯队,每个项目组都可以独立运作;
  • 项目团队执行力较强。

2. 团队氛围

成熟阶段产研团队团队规模扩大,大量新成员加入,团队多样性上升,且各个职能核心人员开始由自己做事转变为带人做事,这些变化都为成熟阶段产研团队的团队氛围建设提出了新挑战。

这些变化造成的最突出的两个问题是团队开始形成圈层,以及管理后备力量不足。

为了解决上述问题,可以通过以下方式促进团队氛围:

  • 管理后备人才的培养。实线的职能团队负责人及虚线的项目团队负责人是大部分成员的直接对接人,管理后备人才的管理能力及做事风格对其他团队成员影响很大,所以要想提升团队整体氛围,需要从管理后备人才的培养做起;
  • 形成工作和人才培养的SOP。团队圈层化会导致团队成员工作能力和工作产出不一致,所以需要将工作和人才培养形成标准化文档;
  • 举办集体活动。团队圈层化会导致团队向心力下降,所以需要通过举办集体活动的方式来增强团队凝聚力;
  • 创造团队共同的仪式感。对产品过程中得到的良好反馈或阶段性进展进行有仪式感的庆祝;
  • 在正式场合宣贯团队理念。通过正式场合来宣贯开放合作、互相信任等理念。

3. 产品目标

成熟阶段的首要目标是留存产品现有客户,而“客户续约率”能很好地体现产品现有客户留存情况,所以成熟阶段的产品目标为“客户续约率”,产研团队的工作也应该围绕着提升客户续约率来展开。

4. 任务管理

任务管理包括版本节奏、工作计划、任务分配及任务跟踪四个维度。

1)版本节奏

成熟阶段的产品开始进入增长瓶颈期,一方面需要加强与市场、销售、服务等部门的协同,另一方面需要通过关联产品的探索寻找新的增长点。综合行业情况、用户现状,我们最终确定核心功能版本节奏为一年一个版本,协同运营、营销相关功能版本节奏为一年两个版本,探索功能为一年两个大版本兼不固定的小版本。

2)工作计划

成熟阶段的产研团队为职能团队为主,项目团队为辅的“矩阵式”组织架构,并有专职的项目经理负责所有项目的管理,所以产研团队的工作计划是职能团队的工作计划兼项目计划。

工作计划的制定过程为:项目经理确定产品发布时间、制定项目计划、制定职能团队工作计划。

3)任务分配

职能团队工作计划确定后,由职能团队成员认领相关任务,并形成个人总体工作计划、周工作计划、日工作计划。

4)任务跟踪

职能团队负责人负责进行团队成员日常工作进度监控、个人工作量评估及个人任务跟踪,项目经理负责按周监控项目进度、协调跨项目资源。

5. 沟通模式

成熟阶段的团队沟通模式与成长阶段差异不大,在具体应用中仍会涉及到链式沟通、Y式沟通、全通道式沟通三种沟通模式,但是为了规范化管理,在沟通过程中会增加书面沟通所占比例,同时会开始应用需求管理、文档共享、研发项目管理等协作工具。

职能团队基于链式、Y式沟通模式,通过日报、项目周会、月度总结会来进行职能团队内工作与进度沟通,项目团队基于全通道沟通模式来进行项目团队内跨职能协作。

成熟阶段的沟通形式为口头沟通(占比10%)、群消息沟通(10%)、书面沟通(35%)及会议沟通(45%)。

五、总结

为了解决不同发展阶段产品所面临的问题,势必需要打造具有不同特点的产研团队,而通过团队氛围建设、产品目标制定、成员任务管理、团队有效沟通这方面来优化团队协作是打造符合不同发展阶段产品的产研团队有效方式之一。

产品|系统重构的一些情一些事

一、背景

以前一直以为产品经理经历的产品 从0~n ,产品设计方法上应该有一套方法论。但经过一年对一个产品重构,发现以前的认知还是愚昧了。

重构产品的方法与从0-1区别很大,难度和挑战也高于0-1。

我所重构的这个内部系统,在接手前重构已经做了一年左右。(说明系统包含的范围、功能的体量是巨大的)

旧内部系统,曾经的模式都是业务方一句话需求直接提到开发团队,然后各个开发根据自己的理解直接做两个星期,无论能不能用,好不好用,因为公司强制要求都在无奈使用,过程中也埋下无数坑,重点是公司持续发展,原来的系统是否还可以支撑更完整的电商业务链条?旧系统的情况,显而易见,是不能。

经过一年的改造和优化,目前已经完成,推动上线,这个过程中遇到的问题和解决方案、总结经验教训。

二、重构方式

重构一般有三种方式

  1. 推倒重来:在原系统基础上重新开发,仅保留数据库等基础内容,上层代码重新开发;
  2. 另起炉灶:原系统保持运行,另起新项目,重新做个新系统替换,做数据迁移;
  3. 运行中改造:保持现有系统持续、稳定运行,同时对所需模块持续改造,直至达成目标

这里对这三种方式做个对比:

方式一,要求原系统即将废弃,但情况不多。大多数公司都会选择方式二或三。

从产研的角度,通常倾向方式二,因为不用考虑过多的历史包袱,处理起来更方便,如果需改造内容多,综合成本也更小。

从业务方和领导们的角度,通常倾向方式三,因为风险更小,感觉上成本更低,但实际上如果需要改造的模块较多,方式三的成本其实更高,因为有很多兼容、填坑、还技术债的事情。

而我接手的产品,当时团队决定是方式二。但虽然是另起炉灶,但是需要场景新做,或者场景新旧逻辑均需要兼容。

三、重构过程与方法论沉淀

1. 前期调研

(1)内容

业务调研

所有的调研都是先从业务开始,在这部分的调研中,我们需要了解两部分:

  1. 业务所在行业的通用玩法,知道行业内一般都是怎么运作的,有行业认识;
  2. 公司的整体业务流程、业务特色、形成的历史渊源,其中要特别注意公司与行业的不同之处,一旦忽略就容易在后面改造中照搬行业玩法,导致与实际业务需求不符。

这两部分学习、调研的内容是相互促进的,通过观察公司业务运作可以更好的理解行业做法的含义,通过将行业玩法作为参考系可以发现公司当前所处位置及优劣。

用户调研

首先需要了解有哪些用户在使用现有系统,通过提炼用户差异性,将用户从多个维度进行分群(后面细聊如何做B端用户分群),然后就能找出对应群体中一些典型用户,通过一对一访谈深度了解他们使用系统的目的、路径、痛点、期望

不过一对一访谈效率还是比较低,所以需要增加问卷等方式,大批量收集用户目前的需求、槽点

(2)目的

  1. 从业务方、领导层、用户各方充分了解为什么要进行重构
  2. 对现有系统情况做一个整体的摸排,初步形成较为全面的认识

(3)输出

  • 公司业务流程
  • 公司业务特色总结,形成文档记录
  • 各角色用例图
  • 用户调研报告。包含用户体验地图
  • 用户问题/需求池

2. 旧逻辑梳理

(1)内容

对系统现有主体逻辑进行梳理,包括系统主流程、产品架构、产品结构、功能模块、功能点等。

由于还没到具体模块的改造,所以有些细节暂时可以不用太深入,等到改造到那块时再梳理即可,一方面因为有些细节即使提前了解了,时间长了到后面可能也忘了,另一方面是可能由于文档缺失或更新不及时,已经没有人能记得很清楚了,需要开发通过代码看出原有逻辑,所以细节梳理需要耗费巨大的时间、人力成本,影响前期进展。

(2)目的

这一步的目的是为了对系统现有功能、逻辑有整体认知,便于后续对比业务需求,发现全局性、架构上、偏底层的一些问题。

(3)输出

  • 产品主流程图
  • 产品架构图
  • 产品结构图(脑图)
  • 通过表格整体的各模块功能逻辑清单

3. 对比分析

(1)内容

通过对比业务实际需求与现有规则的差异,发现、挖掘出系统现存的一些问题,明确后续需改造的内容。

(2)目的

很多同学在对现有系统做重构时,需改造内容的信息来源是调研结果或自我感受,但从我的经历来看,这些信息还不够,主要原因有两个:

  1. 很多调研内容用户无法告知你应该怎么做,相当大比例的问题是普通用户意识不到的,用户反馈由于自身的很多局限,认识不够全面,同时也认识不到系统底层问题,更多的还只是一些交互、视觉层面的问题;
  2. 很多看起来不合理的逻辑,其实是符合业务特点和要求的,也有其特殊背景,只有最适合你的业务需求的才是好的设计。

这就是专门对比业务需求与现有规则差异的目的。

(3)输出

补充用户问题/需求池。通过对比发现的系统现存问题清单,与前面调研结果进行合并在一张表里

4. 问题/需求整理与分层

(1)内容

问题/需求整理

通过前面的调研、分析,我们就有了一份用户问题/需求池,内容非常多,这就需要对这份问题/需求池进行整理。

  • 按功能模块归纳
  • 将重复问题/需求合并
  • 将明显不合理问题/需求删除

问题/需求分层

除了将这些问题/需求按模块划分,还要对它们进行提炼总结,然后将这些问题按数据层–模型层–领域(业务逻辑)层–交互层–UI层五个层次进行分层

  1. UI层:纯视觉问题,如icon语义、颜色、样式问题等;
  2. 交互层:页面交互上的问题,常见的如菜单结构、操作控件;
  3. 领域层:各种业务逻辑问题;
  4. 模型层:底层模型设计相关,如原设计不合理,与业务需求不匹配,扩展性差
  5. 数据层:常见如数据混乱,不统一、来源不一致等

(2)目的

问题/需求的整理是大多同学都会做的,就不做过多解释,但分层则是很多同学没有意识到,其实非常重要的事情,接下来就说一下为什么要对问题/需求进行分层?

当我们面对大量的问题、需求时,往往会是一脸懵逼、茫然无措的状态,主要有两个原因:

  1. 问题太多,不知道从何下手,先从哪里开始;
  2. 当我们深入这些问题/需求会发现,很多问题/需求都是相互依赖的,由于是对现有系统改造,很多功能已经成型,当我们选定一块内容时,往往牵扯其他很多部分,一类是横向关联,即模块与模块间的关联影响,另一种是纵向关联,即表面上是交互问题,但很可能会涉及业务逻辑层、甚至模型层的改动。

而我们在对已有系统改造时,很容易出现影响面评估不足导致线上bug的情况,所以除了将问题/需求从横向功能上整理归类,还要从纵向涉及层次划分,这样可以更好的分析出关联影响面,另外,不同层次的问题改动成本、策略、方法、时间差异很大,对我们后面优先级评估也有较大影响,所以需要有纵向划分。

(3)输出

整理分类后的用户问题/需求反馈清单

5. 明确重构目标与指标

(1)内容

重构不是为了改而改,需要有目标的改,改造的范围、最终希望达成的结果,如何衡量,都是在改之前要考虑清楚的问题。

明确了目标,就需要定义相应的指标进行量化评估,包括评估最终结果的全局指标和评估每块功能的功能指标,以便有数据支撑。

根据明确的指标,需要做好前期数据收集工作,提前做好埋点等,才能对比优化前后的结果。

(2)输出

数据指标定义:

6. 分析优先级

(1)内容

对用户问题/需求整理后,就要分析优先级,确定改造重构的先后顺序,主要从四个方面综合评估:

  1. 价值收益。在看重构价值时,需要同时看短期和长期两方面,短期收益大(如交互体验上吐槽较多的问题)和长久的事情(如模型、数据层的动作)需要同时做,不要完全搁置某一类;
  2. 依赖关系。根据依赖关系,一方面可以明确先后顺序,另一方面对于依赖过多的内容,尤其底层的改动,需要多花时间好好分析、好好讨论;
  3. 改造成本。需要根据成本评估ROI
  4. 资源支撑。

(2)输出

用户问题/需求反馈清单中的优先级结论

7. 模块调研

(1)内容

第一步的调研,主要是为了形成整体认知,还没深入到具体模块的细节中,当我们确定要重构的内容及优先级后,再对具体要改造的内容有针对性的做用户、竞品调研,就会更有收获,集中精力琢磨透一块内容,用户的痛点有哪些,使用的场景有哪些,同时看看其他竞品的针对这些问题的处理方式,也可以称为功能调研。

(2)输出

  • 对应场景用户调研结论
  • 对应功能竞品调研结论

8. 制定、实施优化方案

接下来就是根据规划的优先级来逐步改造优化了。

无论是一个产品还是模块的重构,这个流程方法都是通用的

四、感悟

1. 产品设计

(1)敬畏用户习惯

重构需要改很多内容,当涉及到交互层,需要改变用户原有的使用习惯时,一定要三思而后行,首先要考虑的是能否保留用户的使用习惯,哪怕这个习惯不那么符合规范,与通用做法不太一样,也要首先考虑保留,其实很多交互方式没有对错之分,只有是否合适之分,用户用得舒服才叫合适。

如果实在需要改,就要好好考虑如何比前任做得更好

用户习惯不是仅仅“考虑过”就足够了,是真的需要敬畏的心态面对,否则用户会用中华国粹回敬你。

(2)用户价值=(新体验-旧体验)-替换成本-感知门槛

所有产品动作根本上都是用户价值驱动的,俞军老师的用户价值公式大家应该都很清楚了,在这个公式的基础上我在后面增加了一个【感知门槛】,即用户感知到你新体验带来价值的门槛有多高,门槛越低,带来的价值越大。

可能俞军老师已经把【感知门槛】算到【替换成本】里了,这里我单独列出来,目的是想强调这部分,因为有时候会出现自己感动自己的情况,觉得我们做了一个非常棒的优化,用户这群白眼狼怎么就不领情呢,原因可能你这个优化确实很好,但用户没感知到。

(3)小细节能有大回报

产品重构很多是用户使用太痛苦,而改变这种痛苦不一定都是要做大的变动才能让用户减轻痛苦,很多细节优化能有大的回报,例如增加最近使用、操作记忆等。

(4)产品设计尽可能穷尽场景,扩充思考广度与深度

基于重构的方式二,容错率是很低的,风险极高。因此在产品设计上需要想明白。流程正向场景,逆向场景,分别罗列清楚。再细致整理和产出方案。

而且重构方式二,缺少验证环节,实际上是无法很好的控制重构结果的。

(5)识别和评估方案的风险,并且要制定风险应对方案

没有人能保证每一次改动都是向好的,哪怕不出bug,可能由于有的场景没考虑到导致新功能产生负面影响,所以功能上的实现需要遵照小步快跑,增加验证环节。

2. 心态

(1)重构是对产品能力淬火的绝佳机会,而不是火坑

接手一个前人留下的产品,是很多同学极不情愿的事情,就觉得是一个大火坑,都不知道怎么下手,都希望自己可以从0~1做一款产品,挖的坑让后面的人填。

我最开始的心态也是如此,但随着一年多的重构,会发现这其实不是火坑,而是对你产品能力二次打磨的火炉,当你深度长时间跟进后,你会对用户、场景、业务这几个词的理解更深。

(2)锻炼大心脏

产品重构确实很容易变成吃力不讨好的事情,你会随时受到多方的压力:

  • 用户会喷你。因为改了用户习惯被喷,因为加了些“乱七八糟”的被喷,因为不被理解被喷,总之有各种理由;
  • 前人留下的坑。你永远都不知道下个坑会在哪里,测试也回归不到,等到线上用户发现,就成了线上事故;
  • 上级压力与用户适应节奏矛盾。上级希望在短时间内看到变化,但其实这比从0~1花的时间要更长,除了各种挑战外,更重要的是要给用户适应的时间,不适合在短时间做大幅度的变动,而这种矛盾难以调和;
  • 不确定的风险。你也不知道这个版本的改造、优化上去能不能被用户接受,最终能否拿到你要的结果。

你需要同时面对更多的压力,所以调整好心态,锻炼大心脏才能更面对各种质疑和压力。

产品 |关于「在线教育」和「传统教育」的见闻录

今年刚好疫情问题,「在线教育」被迫高度发展,我一直关注教育的人,觉得「在线教育」终于迎来春天了。

然后我再次回到教育市场去探索情况,看是否真的遇上春天。来说说的我的见闻录。

K12课外教育——长坡厚雪,潜力巨大

行业规模:

2019年市场规模达到6191亿元,预估5年后市场规模达到万亿规模

市场空间:

海量的下沉市场未开发,增量维度包括课程、年龄

需求分析:

教育焦虑逐步加剧,“军备竞赛”必然引起整个教培行业的持续

K12行业玩家

K12行业有众多玩家,传统K12培训机构、在线教育、互联网巨头

需求:教育焦虑与军备竞赛

从上面可以看到我国的优质学位不停下降,考到985学校的人数也仅有20w人。

因此也引发了教育焦虑与军备竞赛。

现状:K12课外培训——高度分散

从图上可以看到巨型的教培企业占比非常少,但是微小型的教培机构占了绝大多数,入门门槛低,生命周期短,复制扩张能力差。

所以现在很明显看出一个情况:新东方、好未来这些仅在一线城市占优,但是下沉城市里却十分分散

疫情下的「在线教育」

在疫情的加持下,K12的「在线教育」强势跑出,但也引发了很多问题和争论,关于K12课外辅导,线上好还是线下好?

「在线教育」优势在于便捷和价格优势,但缺乏沉浸式与互动式的课堂体验。目前的商业模式也不明确,纯“在线教育”目前处于类似“百团大战”阶段

「线下教培」优势在于沉浸式与互动式的课堂,但是价格高昂,同时需要来回接送。商业模式也高度成熟,行业龙头是很明确,正处于规模复制与下沉阶段。

尽管双方都有利有弊,可是「在线教育」出现多个强烈的痛点。

痛点一:无法保证学生的专注度

K12教培的本质是提分应试,对专注度要求非常高

根据一些市场调查,「在线教育」最大痛点在于「互动性」+「专注性」

在线教育,学生缺乏老师的监督、互动,专注度会偏低,对于低龄学生这问题更严重。

这从而确定一个结论:K12线下教培根本不可替代。

痛点二:依赖免费推广,获客成本高

「在线教育」一直在烧钱,目前还没有烧出护城河,预计还要持续一段时间。

痛点三:考试地区差异大,互联网效应有限

小升初:各市各区各校都有差异。例如:同一个地区存在不同教材,有的使用人教版,有的使用北师大版。学校招生条例也不一致,民办学校考察内容更多更广。

中考:各省、各市有差异。例如:省市之间的教育水平不一致,导致考卷的难度可能也不一致。

高考:全国卷+各省差异。例如:某地区高考特别偏爱去谈论其地区的文化特点。

新趋势

今年7-8月时,我协作的线下教培项目,暑假报课数据暴增,新增学生倍级数增长,在读学生续课率可达95%。线下教育的需求复苏猛烈。

但是也不能磨灭「在线教育」的功劳,它终将成为新的教育工具,不会替代掉线下教培教育形式。

趋势:OMO,线上和线下教育融合

线下教育,可以逐步转向线上,利用强大的口碑、师资等能力,将「在线教育」变成新工具,成为他们新潜力的引擎。

在线教育,也可拥抱很多变化和机会

(1)提供更多优质的工具,例如数据分析学生上课行为、增加互动模式等,协作学生通过「在线教育」方式获得较好的学习效果。

(2)构建强有力的师资团队,教培的核心是老师,双师课堂。优秀老师做主教,班主任悉心解答。

(3)教学研发,教材+教师=教学内容,合适教材内容可助力在线教育课堂增加趣味性、互动性,从而增加学生的专注度

(4)构建强大的中台能力,前台的教学,收集相关的数据,后台提供科技(OCR、语音识别、拍照搜题等等)和内容(教材),中台将两者串联起来,将课堂质量推高

在以上形成良好的口碑,也可和传统教培机构一战。

产品 |用户账号系统设计——登录注册

文章讨论的「用户账号系统」,主要是从「建立用户」角度进行讨论,涉及用户的登录、注册、第三方应用等。


一、阐述用户账号体系的功能性和拓展性

用户是产品的基础和目的,一切创意,一切功能,皆为其服务。因此,用户账号系统,于产品而言,是一个重要的核心。所以,类似用户账号系统这种基础性的功能系统,在设计层面上,难点和重点都是显而易见的。重点是既要保证他的·功能性,难点即是又要保证其拓展性

(1)功能性

用户账号系统,可能乍眼看上去,说得比较大,通俗一点,就是管理用户账号系统。那如何管理?就是对用户账号的增加、删除、查看、修改。如果再换一个表达方式,那就是“注册、登录、修改信息”。这就是用户账号系统的功能性的设计重点。

虽然这些功能,看上去比较简单,实现方式也不难。可是这是面对用户第一道门槛,因此在界面设计和用户体验会抓得比较紧。

(2)拓展性

那么,如何理解用户账号系统的拓展性,这里基于业务列出几个例子:

1.第三方授权登录

登录的方式,从早期的「账号+密码」,这种方式实现非常简单,可是有一个最大的痛点——容易被遗忘。

后来,逐渐演变成「邮箱+密码」「手机+密码」,由于邮箱、手机等信息,都是大家经常使用的内容,所以,可以降低遗忘率。可是正常的用户账号需经历两个过程:先注册再登录,略繁琐了。

为了可快速登录,跳过注册流程,也产生「手机+验证码」这样的登录方式。

同时社交产品发达,微信、微博、QQ等社交产品都有相关的SDK,可协助一键登录。这样「第三方授权」登录方式也诞生了。

第三登录是登录方式演变和拓展,用户账号系统要满足此拓展。

2.同平台多账号绑定和解绑

第三方授权登录,虽然可以实现快速登录的目的,可是,第三方仅仅对外开放OpenID,用户的详细信息还是存留在第三方中,产品只能得知第三方公开的信息。但是产品都是需要自建用户体系,因此现在平台的账号体系和第三方授权的方式都是并存的。

正因为两者是并存的,所以,同平台就会出现多账号情况,用户通过手机/邮箱创建一个账号,然后又通过第三方授权创建了其他账号,绑定需将其全部捆绑在一次,可协助用户管理多个账号。而解绑,则是其的逆反应。

3.不同平台的账号打通

现在每家公司都不会只有一款产品,而是会以某个成功产品为核心,延伸更多其他类型的产品。因此,每个产品都会有其对应的用户体系,但是用户账号系统,基本都是唯一的,它需要满足不同的产品。

所以,接下来,需要总结如何处理以上重点和难点。


二、第一重点——登录

(1)登录方式的介绍
(2)相关的前端界面设计

1.账号/邮箱/手机 +密码登录为主

这是最常见的登录方式,适用于普遍的产品。

例1:豆瓣

2.手机+验证码登录为主

「手机+验证码」的登录,又名「免密码登录」或者「快捷登录」。

起源于团购类的产品,用户在购买商品,浏览、筛选、放入购物车,填写订单信息,最后一步付款,此时发现自己没有登录,因此,在这里提供快捷登录方式,免去其注册登录繁琐的流程,快速让用户完成订单

在实际运用上,大家都发现,这种方式优势明显,既可以保留用户信息,又可以快速注册登录,提高用户体验。因此现已经是成为登录方式一个很重要支线了。

例子1:轻芒

Tips:

1.输入手机号->输入验证码,中间是有一个过程的

(A)检测手机是否正确,包括是否11位,是否满足不同地区的电话格式等
(B)然后告知服务端发送验证码

这个过程,以往都是同一个页面实现——即“填写手机号+验证码”,同一个页面对熟悉的用户有较大的优势。可是同一个页面出现两个按钮:“发送验证码”和“登录”,会容易让用户混淆,不太清楚流程先后。

所以,现在很多产品都改善,使用分步(如例子所示),一页面承载一个功能,一个复杂的任务拆分成几个小任务,逐步引导用户完成,既给复杂的任务处理腾空时间,也让用户快速了解产品流程。

3.验证码登录和密码登录并行

上文讨论过,验证码登录有其快捷方便又保留用户的优势,而密码登录历史悠久,实现简单。所以也有一部分的产品都同时保留这两种登录方式,兼容新老用户。

4.第三方授权登录为主

第三方授权登录,于用户而言,是方便至极,无需填写任何信息,只需要授权登录即可。可是于产品而言,第三方登录只公开OpenID,因此很多用户数据,仍然在第三方,不利于后续工作展开,因此,很多产品都会登录后引导用户绑定手机或者其他信息。

然而,在产品的初期,也可不妨全面植入第三方授权,因为用户系统需时搭建,初期的产品步伐较轻,可将核心放进产品核心功能,使用第三方授权登录方式,一来于用户而言,注册登录成本几乎没有,低门槛让用户快速体验产品;二来可以验证产品的市场接受度。

三、 第二重点——注册

注册有三板斧:用户名(手机/邮箱),验证码,密码

但也有部分产品会增加「填写用户资料」的流程(如头像、性别、生日等等),以期待可以和用户建立关系。

若增加「填写用户资料」的流程,也要思考:

A.步骤是阻断性的还是可跳过?
B.内容哪些是必填,哪些是希望填?

站在用户体验角度,每增加一步功能或者内容,用户需要去思考,也容易出现流失。

除此之外,在用户登录注册的模块里,着重分析一下注册的交互——分步注册

(1)分步注册(Wizard 向导模式)

注册是一个很成熟的流程,所以在交互层面上很建议使用到分步注册,这和“Wizard(向导模式)”有异曲同工之妙。

Wizard模式在PC时代是十分流行,微软在安装软件时,大多数软件都是一步一步引导用户如何安装,将安装任务拆分成几个小任务,一个页面承载一个小任务,用户每次只需完成一个,直至全部完成。(上文也有涉及)

这样做有什么好处:

通过分解复杂工作流帮助用户更快的掌握内容
通知用户当前任务进度使其了解整个工作流的概况
将复杂流程分步进行能够提供充分的任务处理时间,避免用户长时间等待
国外某公司做过A/Btest,发现分布注册的转化率高于非分布注册

所以,注册流程,我们也引入这样的思维。拆分注册流程,每一个页面只承担一个作用。


四、第一难点——多平台账号打通

随着互联网的深入发展,对于公司来说,旗下不仅仅只有一款产品,可能是多个产品并行。因此于某个公司而言,用户账号体系只有一套,而且非常基础,可以面向不同的产品。

举个例子,网易系的产品,如考拉海购、网易云音乐等,账户体系是依赖于网易的邮箱。包括我工作上负责的产品:约约、MOJIKIDS、HOBBYLAB等的账户体系是由手机账号承载的。

这种需求是存在的,那我们怎么解决多平台账号打通呢?

接下来,会从技术的角度去谈论这个问题,可能说得不一定完全正确,毕竟我是负责产品工作。可这个问题需从服务端入手,从技术角度剖析,虽然不是我的强项,可是我对这个解决方法是很好奇,为此,我询问了程序猿和上网查阅了相关资料。

(1)认识三个参数

(1)AppID:接入用户系统时,首先分配,用于区别接入的各个APP
(2)UnionID:用户手机注册时,由用户系统根据手机号创建,在用户系统作为用户唯一身份标识
(3)AppUserID:用户注册时,由App服务端根据Union或者第三方授权的OpenID创建,在App内作为用户唯一的身份标识

(2)基本流程

解释:

(1)用户注册

使用手机注册,首先判断手机的正确性和验证手机,若符合要求,检查手机是否已经存在,若存在,就去引导登录;若不存在,服务端就会创建手机UnionID,同时也会反馈给App端,创建AppUserID并关联UnionID

(2)用户登录

使用手机密码登录或验证码登录,如注册时检查手机,若手机账号是新增的,流程和注册一致;

若手机账号已存在,服务端查询对应的UnionID,再返回APP端,查看UnionID是否在该APP存在过,若是,就查询到AppUserID并成功登录;若否,就创建AppUserID,并且登录。

这是一个普遍的做法,第一,保证UnionID的唯一性,确立用户账号体系;第二,可以让不同App独立,虽然大家有相同的UnionID,可是不同APP有相关的用户信息。

(3)基本原则

根据以上的流程图,我们可以获得以下的基本原则:

  • 当手机号作为唯一注册途径,用户每次手机注册时,都会在服务端新建一个UnionID,然后返回对应的APP(使用AppID跟踪)创建相关的AppUserID
  • 一个UnionID可对应N个AppUserID
  • 第三方授权OpenID,只会存在APP里,即创建AppUserID,并没有创建UnionID

工作心得:

这样流程,是现在总结比较恰当的账户体系,可兼容多平台。但在自己的负责项目,并不是这样流程,区别的地方是,第三方授权的OpenID也可以创建UnionID,这里好处可以快速增加用户体系的用户数量,可是解决同平台多账号问题时,因为这样机制导致绑定和解绑环节很多坑,会非常折腾。

若没有存在历史原因,建议一开始用户体系需思考长远一点,如兼容多平台。

(4)问题解答

1.多平台的时候,用户资料等用户信息是如何管理?

答:首先归纳一下现在主流的用户系统服务端设计:

  • app级的用户系统,根据手机号邮箱注册或第三方授权创建用户身份,用户的身份信息、账号绑定、个人资料都保存在app服务端也只对单一app有效;普遍中小app都是采用的此种。
  • 公司级用户系统,根据手机号邮箱注册创建用户身份,用户的身份信息、账号绑定、个人资料都保存在统一的公司用户系统服务端,对接入的app有效,app端有读取修改权限;
  • 平台级用户系统,根据手机号邮箱注册创建用户身份,用户的身份信息、账号绑定、个人资料都保存在统一的公司用户系统服务端,选择极少信息提供公开接口,接入的app只有读取权限;例如qq微博微信等第三方授权。

我工作的情况,是第二种为主,公司级用户系统。这里举两个例子:网易(网易云音乐,考拉海购、网易严选)和百度(百度贴吧、百度地图)。

(1)网易公司的用户系统是网易邮箱去承载,但是承担功能仅有一个用户身份即UnionID,用户资料、账号、第三方登录等都是由APP自己去实现和修改。

(2)百度公司的用户系统是百度账号去承载,不仅有UnionID,还包括用户资料、第三方登录、账号等等都是保存在用户体系中,App端都有修改权限用户系统资料。

那我们看得出,用户资料管理方式有两种,一种是储存在App端,一种是储存在用户体系。网易是储存在App端的,而百度储存在用户体系。究其原因是:

  • (1)百度偏向工具,所以对于用户资料并不是很高要求,只需有昵称、头像等基础元素即可,资料保存在用户体系,app端直接接入即可
  • (2)网易偏向个性化,不同产品有不同的用户体系需求,所以将资料存放在App端,可以满足多样性,又互不打扰

我负责的产品,则是参考了百度的做法,将用户资料存在用户体系中,这样在我们不同的产品App上可直接修改相关昵称、头像等。

为啥会有这种初衷?因为我们的电商产品,用户关心的是买买买,而对个性化要求并不高。我们不希望让用户花时间放在用户账号上。

2.为什么不用手机作为唯一识别方式?

答:不使用。站在用户的安全性,手机是一个可变量,用户可能丢失手机无法找回,更换手机,甚至激活旧手机号码造成账号资料泄露。

手机号是我们保证账号安全性的一手段,常用方法有以下:

  • 绑定/解绑手机
  • 设置安全问题
  • app用户行为验证
  • 账号申诉

五、第二难点:第三方授权登录

难点1提出的基本原则,也写道,第三方授权的用户不是用户系统的用户,仅是单一App的用户。因此就这个原则,第三方授权登录流程如下:

解释:

(1)第三方授权注册登录

调取第三方sdk,查询此openid是否已有appuserid;若是,登陆;若否,创建appuserid并将基本资料存入app服务端;

我负责的产品——约约,还有尚早版本的京东,并非按照上图流程。
区别地方是,第三方授权的OpenID是直接进入服务端查找是否有UnionID,再由UnionID创建APPUserID

这里会有问题的,第三方授权OpenID和手机号在用户体系中是同一个层级,可创建UnionID。若手机号和第三方授权绑定在一起,就会出现两个UnionID,发生冲突。所以不建议这样的方式实现用户账号体系。

六、第三难点:同平台多账号的绑定和解绑

(1)账号绑定

账号绑定主要分为:绑定手机号和绑定第三方授权账号。

账号绑定是为了避免用户忘记其登录方式,有利于用户操作,也有利于产品用户的信息留存。

1.绑定手机号

  • Step 1:用户输入手机号并获得验证码,客户端进行基本手机判断,App服务端发送验证码给用户
  • Step 2:用户系统服务端验证手机是否已经存在对应的UnionID
    • 若是,提示已绑定此手机号,需更换手机号
    • 若否,按照手机号注册流程,用户系统创建UnionID,将UnionID传给App并关联当前登录的AppUserID

2.绑定第三方授权

  • 授权后,查询App服务端是否存在AppUserID
    • 若是,提示此号已绑定,建议先解绑
    • 若否,将OpenID绑定到登录的AppUserID中,绑定成功

所负责的产品,并不是这样实现绑定,上文提到,由于历史原因,手机号和OpenID是同一个层级,都有可能生成UnionID,那出现这种情况,如何解决?

提出以下的解决方案。

实际工作中,由于第三方授权登录,对于产品的用户资料的收集影响略大,所以通常第三方授权登录之后,就需要立即绑定手机,不允许用户跳过。

(2)账号解绑

(以下内容摘自《用户系统(下)第三方授权、账号绑定及解绑》)

账号解绑也只是针对手机号和第三方授权。

1.手机号:只允许更换手机,不能解除绑定

  • Step1:原手机号+验证码,app服务端验证是否为真,为真发送验证码;
  • Step2:新手机号+验证码+密码,app服务端验证手机号+验证码是否为真,为真进行step3
  • Step3:用户系统服务验证此手机号是否已存在unionid;
    • 若是,提示更绑失败
    • 若否,将新手机号替换原手机号,关联原手机号unionid,appuserid;并将原手机号从用户系统中删除;

我的工作心得:在现实工作中,过程并没有如此繁琐,实践中是直接去掉Step2,首先验证旧手机,然后再验证新手机,两者通过即可更换手机。

2.解绑第三方授权

  • Step1:当前第三方授权是否已经绑定手机号,若是,成功解绑;若否进行step2
  • Step2:当前第三方授权是否绑定其他第三方授权登陆,若是进行step3,若否提示无法解绑,首先请绑定手机号;
  • Step3:当前第三方授权是否为最早一个绑定(即注册账号);
    • 若是,调取第三方授权登陆页面,用户重新登陆要解绑账号+密码(需要确认是否能抹除用户登录信息要求输入账号密码),登陆成功则解绑成功;
    • ps:这里被开发同事验证不能抹去登录信息,因为我们只有调取接口的权限。但是当时之所以想要这么设计,是为了账号安全,可以试想一个场景,我把你的账号绑定到我的微信/微博等,然后接触你的账号,相当于这个账号就归我了。--事实证明现在的权限没办法解决这个问题。
    • 若否,解绑成功。

我的工作心得:第三方授权解绑Step1就要检测是否绑定手机,因为没有绑定手机,会导致后续解绑流程略偏复杂,用户会有疑惑。

所以,更推崇当初第三方授权登录,就必须引导用户绑定手机。这样才可以维护用户账号信息和简化后续的登录,也简化后续出现意外时,让用户快速处理问题,如解绑问题

产品 |产品设计流程

前记:文章写于2015年6月,当时的我刚刚在第一家公司过了实习期和试用期,文章就总结了我入门产品经理的第一课,产品设计流程。

3个月前,我入坑产品,发现产品所需的知识量突然是陡增的,我是一个计算机专业出来的学生,关于计算机逻辑、方法实现、流程等等都有一个较长的磨练。可是进入产品环节,发现知识量不是同一个量级,除了技术,还需要有对设计、需求、用户心理、运营等等有相关积累。那我开始做笔记,记录我在产品领域的成长。

进入某一个岗位时,最快的方式,首先找到岗位的工作流程,然后按部就班走一遍,这样就可以快速融入岗位角色,后续甚至可以思考流程。所以,工作上,我从产品的角度,总结对应的工作流——产品设计工作流。这个和计算机里一门课程——软件工程很相似,只是软件工程述说的工作流是从技术的角度阐述。

流程如图所示:

一、需求获取

  • 面向对象:老板、各种业务人员(市场、运营、销售、行政等等)
  • 工具:笔、笔记本、Excel表
  • 主要目的: 聆听需求,沟通别人的需要
  • Tips:不要急着反驳,站在别人的角度,思考为什么别人有这种想法。
  • 产物:Excel表

二、需求分析

  • 面向对象:老板、各种业务人员、技术人员
  • 工具:Xmind、Visio、PPT
  • 工作内容:
    • (1)需求的背景分析、市场分析、竞品分析
    • (2)需求的拆解,可按功能划分
    • (3)信息拆解,提交相关的流程图
    • (4)打草稿,手稿,画出相关核心流程的界面
  • 产物:MRD、BRD、思维导图、流程图
  • Tips:需求分析,是产品的重要工作,是所有开发和迭代的既基础又重要的环节,这个过程当中,有很多思考方式,如:

(1)5W1h(who,what、where、when、why,how)

这种方式,可以让你从根源角度思考需求,特别是目的,要挖掘,要询问,深度思考:

  • 究竟用户要什么?
  • 或者究竟解决什么问题?
    这里有一个最典型的例子,「福特与马」的故事
100多年前,福特公司的创始人亨利·福特先生到处跑去问客户:“您需要一个什么样的更好的交通工具?”
几乎所有人的答案都是:“我要一匹更快的马”。
很多人听到这个答案,于是立马跑到马场去选马配种,以满足客户的需求。
但是福特先生却没有立马往马场跑,而是接着往下问。
福特:“你为什么需要一匹更快的马?”
客户:“因为可以跑得更快!
福特:“你为什么需要跑得更快?”
客户:“因为这样我就可以更早的到达目的地。”
福特:“所以,你要一匹更快的马的真正用意是?”
客户:“用更短的时间、更快地到达目的地!”

(2)SWOT分析

(Strongness优势、Weakness劣势、Opportunities机会、Threats挑战)

竞品分析的时候,很多分析法,但是这个方法可以横向比对各个竞品,有利于寻找出竞品们的共同点和差异点。这样在思考自己产品的时候,更容易发掘自己的优势和差异。

三、制作低保真原型稿

  • 面向对象:业务、设计、技术
  • 工具:Axure RP 、Sketch、WORD、墨刀
  • 工作内容:
    • (1)根据需求分析/手稿,画出相关原型图界面
    • (2)撰写PRD文档,描述各环节的功能点、需求点和注意点
  • Tips:制作低保证原型稿之后,就核心流程和业务碰想法,如果可以,最好制作一个带动效的内容,毕竟大多数的业务不懂得看低保真原型稿

四、制作高保真原型稿

  • 面向对象:业务、设计、技术
  • 工具:PS、Sketch、墨刀、flinto、marvel(后面两个需要翻墙)
  • 工作内容:
    • (1)此环节已接入设计师,设计师协作制作高保真原型稿
    • (2)利用已制作的高保真原型稿,制作相关的动效交互文档
  • Tips:制作高保真动效交互文档,是让需求方,从视觉和体验上认知接下来的内容是如何呈现。

五、设计

  • 面向对象:业务、设计
  • 工具:PS、Sketch
  • 工作内容:
    • (1)阐述产品的理念,让设计师认知产品的作用
    • (2)和设计师交流,将产品理念和设计理念达到一致

六、开发

  • 面向对象:技术
  • 工具:开发工具、数据库
  • 工作内容:
    • (1)阐述产品功能,要达到的目的,技术需要实现的内容

七、测试与验收

  • 面向对象:测试、业务
  • 工具:测试工具
  • 工作内容:
    • (1)阐述产品功能,勾勒核心内容,测试需要注重的重点模块
    • (2)验收内容,判断是否符合初衷
    • (3)找相关业务,进行验收,是否符合需求方的初衷

八、交付上线,跟踪迭代

  • 面向对象:用户
  • 工具:数据分析工具
  • 工作内容:
    • (1)检查上线后程序是否运营正常
    • (2)部署相关外发渠道,相关的推广文案
    • (3)监测程序的相关数据并记录,分析相关数据,复盘相关工作
    • (4)若有相关的用户群,蹲点用户群,进行用户体验收集
    • (5)记录相关的槽点和需求,为迭代做准备