当前位置:首页 > 产品中心

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

发布时间: 2021-08-04 06:32:56  来源:火狐平台开户 

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

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

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

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

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

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

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

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

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

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

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

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

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

  更大规模的团队合作,问题就改变了,不是“这个版本要上线哪些需求”,而是“这个需求要在哪个版本上线”。也就是多个小团队围绕着各自的需求来开展工作,做完后再选择合并到哪个版本上线,这种模式常见于大型开源项目。

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立9年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。