搜索
当前位置: 7303刘伯温开奖6374 > 迭代 >

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

gecimao 发表于 2019-06-06 09:42 | 查看: | 回复:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文链接:http://olivierlutaud.net/diedai/504.html
随机为您推荐歌词
推荐文章

联系我们 | 关于我们 | 网友投稿 | 版权声明 | 广告服务 | 站点统计 | 网站地图

版权声明:本站资源均来自互联网,如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

Copyright @ 2012-2013 织梦猫 版权所有  Powered by Dedecms 5.7
渝ICP备10013703号  

回顶部