互联网产品如何做好迭代规划?

容器云强势上线!海量镜像 自由组网!

互联网产品的迭代速度越来越快,大家都想抢占市场,那么怎样才是正确的打开方式呢?

确定迭代节奏

如果产品已经进入维护阶段,即无论搞什么都不会造成利润大幅变动,那大家可以轻松点,每个需求都不限时,做完为止。在前中期,为了配合快速迭代或敏捷开发,则需要限时。一般会把迭代周期定成两周或一月。固定节奏有助于提高团队凝聚力和协调度。

请注意,是迭代周期决定周期内做多少需求,而不是需求数量决定迭代周期。这会要求需求的总工作量贴近迭代周期,否则就得进行拆分(下节细述)。

实际的迭代计划可以微调多一两天,比如:需求真的无法拆或不想拆到两周计划内,那可以做三周计划,或者对此需求安排并行开发。但如果要四周,最好还是拆成2个两周。

如果排不满,那也不用把技术部门的资源用尽。空档期可以让他们组织重构、分享知识等。对不同的技术部门,安排会有差别:

app每月发布两个版本:一个版本是大版本,一个版本是修补的小版本。

前端项目:

  • web app、hybrid app、微信小程序的迭代应该和app一致;
  • 网站项目,一般除了第一版和大改版都不会有大需求,所以做完一个需求就上线一个;
  • h5活动页,无论多小的改动都立刻改好并上线。

后端项目:

  • 配合前端或app的项目,跟随即可;
  • 中间件型业务,可以按app的节奏迭代;
  • 给内部人员用的系统,由使用者决定需求优先级,可在闲时更新。如果某些部分是紧急需要的,可以拆出来先做。

需求规划

做好规划要有需求池的帮助。需求池最基本的作用是防遗忘,就像个记事本。在它的基础上做好梳理,就可以得出版本规划。如果需求池用excel来管理,可以有这些列:

(1)简述:最好只有一句话;

(2)优先级(下节细述):可以不要这列,直接在排序上反映;

(3)状态:未定,正在写,正在开发(哪个版本),已发布。可以不要这列,通过改变行的背景色来反映,例如已发布的是灰色,正在开发的是绿色。已发布的需求也可以删除或放到别的地方;

(4)关联:依赖哪个需求得先做完。

(5)备注:

  • 可以写上来源。比如是谁提的需求,真要做了可以再找他讨论细节;
  • 可以用来写更详细的描述,免得遗忘;
  • 预估的开发时长。

请注意,需求不一定只来自产品经理或运营的idea。技术需求、bug修复、运维事项等都可以放进需求池。不会直接影响营业额或者可随时修补的东西,可以交给开发自己规划,穿插在日常中实现。

在做整理之前,要对开发的战斗力心中有数,也就是自己能预计开发说这个需求要做多久。不管是否限时完成,都要对资源占用时长有个预期。如果有需要,可以找开发主管做个简单讨论。

整理的结果就是让需求安排符合迭代节奏,可以对需求做合并、拆分、删除(不做),其中最多的操作应该是把超过2周工作量的大需求拆成小件,拆分的思路只有一个——不影响核心功能的就可以拆。

比如:

  • 评论需求:在评论中穿插表情可以拆,点赞可以拆;
  • 某业务的推送通知、分享功能;
  • 额外的动画交互效果。

确定在下个版本要做的需求,应另外列出带时间表的开发计划。

更大规模的整理,会得出多个月的迭代路线图,总结出主题,甚至倒推出产品战略。清晰的目标能让团队更有凝聚力。

优先级

优先级可以分4级:

  1. 核心:必做,先做,不能砍,不做完就不发布新版本,可单独形成一轮提测;
  2. 高:必做。条件不允许的话可以降低为中优先级。可单独形成一轮提测;
  3. 中:如果时间允许,会做;
  4. 低:可以不做。

判断优先级最基本的原则是向钱看——对商业负责。不要用冠冕堂皇的理由,如公司战略、老板决策什么的来思考,要更直接的。一句话概括,需求的价值等于“产品在单位时间内创造的利润增幅”。

它可以分解为3个层面:

  1. 创造或提升价值;
  2. 降低成本;
  3. 提高产出效率。

其中第1点是可以估算的。首先我们假定成本在第一个版本时就固定了下来,那么利润的增幅约等于收入的增幅。

这几条公式是估算收入的:

  1. 收入 = UV * UV转化率 * 单价。也可以用PV算;
  2. UV = 新增量 + 留存量;
  3. 裂变的新增量 = 分享数 * 分享转化率;
  4. 最终转化率 = 1 – 各环节的流失率之和。

以上4个公式仅作为举例,还能继续把其中的变量拆分得更细,可留意它们跟价值的正负相关关系。我们要做的是评估需求能影响哪个因子以及程度如何,从而间接得到它对利润的贡献程度,以此作为量化手段来得出优先级。

这也就是所谓的数据驱动,其中的常量可以用现有数据、经验、业界数据、其它案例参照来确定。当然,常量在不同场景下还是会变的。

降低成本的某些方式也是可以量化的,比如提升性能从而降低服务器配置要求,或者进行数据压缩节省带宽,这甚至可以得出准确的成本值。除了各种机器投入的成本之外,最大的成本是人的薪酬。这方面的降成本手段通常是做自动化取代或部分替代人工,比如AI客服。

提高效率也就是提高单位时间的产出,一般是实行完毕才能得出它的价值,所以事前只能主观评定。自动化也是提高效率的方式之一,比如提升后台系统体验,让运营可以一键对用户推送通知或在多个平台发广告等等。

另外,通过重构、规范化等方式来解决历史遗留问题也能提高效率。而且效率也应包括质量的考量,能辅助整个迭代过程提高质量的手段也得考虑在内。

并行

团队人数足够多时,不仅是一个版本内的需求可以同时做,跨版本的需求也可以。当然,这时候应该也是多个产品经理同时参与的,最好是各自负责无关联的需求。如果能理解程序员的并行开发方式,知道合并代码的过程以及风险,那也许能把需求拆得更独立些。总体来说就是人和需求都要减少耦合。

还有一种并行的方式,可称作专项:一个大需求被拆分成多个小需求并在多个版本陆续上线。一些微服务、子系统的需求,相当于子项目,也可以看成专项。专项实施的前提是这个大需求足够的独立,跟主线版本的迭代基本没冲突。这进一步考验产品经理的需求整理能力。

更大规模的团队合作,问题就改变了,不是“这个版本要上线哪些需求”,而是“这个需求要在哪个版本上线”。也就是多个小团队围绕着各自的需求来开展工作,做完后

声明:本网站发布的内容(图片、视频和文字)以原创、转载和分享网络内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-62778877-8306;邮箱:hyg@west.cn。本站原创内容未经允许不得转载,或转载时需注明出处::西部数码新闻资讯门户 » 互联网产品如何做好迭代规划?

赞 (0)

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址