如何理解敏捷开发产品管理系列之一：序言及设立迭代目标

作者:课课家更新于： 2015-11-09 09:55:59

在众多学习中，文章也许不起眼，但是重要的下面我们就来讲解一下！！今天的产品运营的知识数不胜数，大家感兴趣的话，可以过来看看，具体内容如下：产品包装

本文是敏捷开发产品管理系列的第一篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，Product Owner团队，产品线管理）
序言
之前的“敏捷开发用户故事系列”已经提到了微观层面的需求管理问题。由于敏捷开发的提出者和实践者主要是开发团队及其领导，因此一般较少提及产品的整体规划、商业目标这些内容。
本系列汇集了本人在做产品管理的时候的一些心得，以及在与不同企业交流、做互联网软件分析的时候的一些所得，与大家分享。
本系列的顺序整体由微观到宏观排序，拟包括设立迭代目标，产品版本规划，新产品研发，Product Owner团队，产品线管理等话题。
为何设立迭代目标

产品经理职责
之前笔者的博客中曾经两次提到关于迭代目标设立的话题。
基于版本规划的迭代目标
一次是关于“迭代期内无变更”，即由于产品应该预先设定商业目标和客户群，因此整体版本规划也应预先设定，进而可以分解出相对稳定的迭代目标。
若能完成上述工作，则迭代期内尽管有微弱的变更，但迭代的总目标不会发生大的变化，从而保证迭代期内整体开发内容的稳定。
基于故事群的迭代目标
第二次则是提到用户故事的组织时，引入了“故事群”的概念，即某个迭代不应该简单地开发“当前最重要的功能”，因为万一这些最重要的功能零散地分布在不同的业务模块中，开发者就要同时面临同步了解多个业务模块的困境，前来评审的客户也会有如瞎子摸象一般只能看到多个局部的一角。
相对容易开发的方式，是在一个迭代中，应该安排相关的一组故事，从而将开发和评审的焦点都集中在一起。这样开发出来的产品也不完整，但却相对完整地交付了一部分功能，比之零散功能还是更有价值。
上述两种方法，一种基于外部的商业目标，一种基于内部的开发方便性，但都指向相同的结果。
怎样设立迭代目标
会前准备

用户运营是指，以网站或者产品的用户的活跃、留存、付费为目标，依据用户的需求，制定运营方案甚至是运营机制。用户运营已经扩展到针对不同类型的用户进行有针对性的运营策略的阶段。
简单来说就是引入新用户、留存老用户、保持用户活跃、促进用户付费、挽回流失或者沉默的用户。用张亮的一张图总结：
一篇文章让你知道什么是运营！
首先要掌握自身用户的用户结构，比如男女比例、年龄层次、身处省市、受教育程度、兴趣点；
其次要了解用户规模以及增长或衰退情况并进行适当的用户分级，比如新用户多少、老用户多少、每日增长规模、用户处于怎样的生命周期；
最后要熟练掌握用户行为数据，并通过数据分析，懂得用户为什么来、为什么走、为什么活跃、为什么留存；对新用户增长，已有用户的活跃和留存，活跃用户促付费，流失用户的挽回都有对应的措施。
开源
注册渠道和注册方式的影响：
产品本身的注册方式：手机、邮箱；
联合登陆再绑定资料，注册转化需要做好；网络运营
注册以及注册后的引导流程：图文并茂地引导用户从哪里开始、怎么玩；
节流
流失的标准：多久没登陆意味着流失；建立用户行为模型，管理用户的生命周期；
流失预警：流失前用户进行了哪些类似行为，这些用户有哪些共同特征，产品是否更改了核心功能；
用户挽回：通知用户（通知渠道、效果评估）、告诉用户新功能新改进等、挽回的用户更需要关怀；
促活跃
留下来不代表是活跃的，哪些行为标识出用户是否活跃，如何促进这些行为
转付费
通过机制让已付费的持续付费
通过一系列行为让活跃用户付费
提需求的成本主要分为2大部分：需求沟通成本，需求开发成本
沟通成本就是运营提出需求后，跟技术（策划）一起沟通，哪些要做，哪些不做，哪些需要调整的过程。
常规的需求，开发成本就2条：人力成本（谁做），时间成本（做多久）。操作的复杂程度不在成本的考虑范围内，可以归结为时间成本。
如果开发成本比较高，花一些时间在沟通上是有价值的。如果开发成本很低且无风险，却花了很多时间用来确定沟通要不要做，那就是浪费时间。
替代品
所有需求的出发点都是目的，为了实现目的，我们想到了一种手段，这个手段在实现上需要一些道具或者逻辑来支持，才有了需求。
迭代目标是提前设立的，早于计划会，甚至早于Product Owner将有开发意向的Backlog条目计划到迭代中。它实际上在做产品版本规划的时候，就应该捎带着被完成了。
它常常是一句简单的描述，如“一个能登陆和显示故事列表的版本”。
在迭代计划会之前，Product Owner会审视这个迭代的目标，从而决定将哪些故事置于本迭代中开发。
事实上，若已经设定了多个迭代的目标，Product Owner应该会同开发团队骨干，为未来2～3个迭代大致分配所需的用户故事，而不是赶在当前迭代前才匆匆分配。这个活动有利于开发团队骨干提前了解未来，从而在架构上做一些准备。
长期存在的一个难以平衡的问题是：若在架构上做了过多的准备，若中间发生变更乃至放弃某些功能，这些准备会浪费；若架构上准备不足，不断迎来新功能又会导致过多的“重构”发生，也会造成浪费。为多个迭代设立目标可以有效地帮助开发团队做出切合实际的架构准备，将浪费降低到最低点。
会后核对
在计划会上讲解故事、估算故事后，事情常常有所变动。
这时候要从已经计划要开发的故事总结一下看看，是否与原来设定的目标相符。
开发中跟踪
在日常开发中Product　Owner常常提出变更，若变更符合目标甚至能更好地达成目标，则应该被积极地接纳；若背离了目标，则应该缓做或重新考虑。
若“被激励”的程序员有了奇思妙想的时候，团队同样应该冷静地思考，做出判断。
“拥抱变化”与“迭代期内无变更”的矛盾其实向我们揭示了敏捷开发中的一个重要原则：变化的是路径，不变的是目标。
为每个迭代设立目标，非常好地让我们能够遵循这一点。
   大家学到了多少？如果意犹未尽，可前往课课家官网直接查看，希望大家获益匪浅哦！！！