“假敏捷”到“真敏捷”：产品经理与敏捷相爱相杀的岁月.pdf

假敏捷“”到真敏捷“”：产品经理与敏捷相爱相杀的岁月

“假敏捷”到“真敏捷”：产品经理与敏捷相爱相杀的岁

月

做任何改变都是需要付出一些代价的。

从半年之前，为了快速相应市场的变化和为无数的ABtest做基础准备，产品开

始初步响应敏捷的速度，版本由每月一个发布改为做每周一个版本。

一个月之前，团队迎来了敏捷教练，在敏捷教练的带领下，我们逐步由假敏捷“”

渐渐开始尝试真敏捷“”，作为产品经理的我，也开始了和敏捷相爱相杀的过程。

这里总结和分享下：

什么是假敏捷和真敏捷？

用户故事的魔力

敏捷中的团队精神

敏捷给产品经理带来的成长。

一、真敏捷还是假敏捷？

事业部是在去年年底开始实时每周一个版本的迭代，那个时候,在全公司我所在

的项目组是第一个开始做频繁发布的。

在变幻莫测的互联网环境下，快速的响应和发布是非常必要的，并且能得到

ABtest的快速验证。

但是在这种快速迭代的初步尝试中，团队慢慢出现了一些问题。

1.假敏捷-7个团队各自为营

1

假敏捷“”到真敏捷“”：产品经理与敏捷相爱相杀的岁月

我们从一个需求从产生到落地的过程来看，首先需求的来源有一些问题。

3月份在敏捷诊断的时候，几乎所有的产品都把最需要解决的问题投给了产品“

定位”。

产品定位可以没有明文规定，但是在快速奔跑的过程中，每个人都要有一致的目

标。

当项目组的每个人对产品的理解不一致的时候，我们传达给用户的，也是一些非

常矛盾的东西。

举个例子，本着一个服务于全球女性的APP，在一次商务的合作当中，商务的同

学拉来的合作是“恐怖电影”。可想而知用户看到了这些启动页广告、banner大图

的时候被惊吓的状态。

同时，需求的产生是在每一条业务线中产生的；按照不同的业务线，产品、开发、

测试被分成了7个团队，团队之间更多的是一些同步的工作，缺乏沟通和讨论。

没有总体的共识，一个APP被分为7个团队，需求的产生比较分离，没有重点。

2

假敏捷“”到真敏捷“”：产品经理与敏捷相爱相杀的岁月

在需求迭代的过程中，每个组是只有一个开发和测试加入到需求讨论中，最后把

会议精神带回团队;更多开发和测试的同学是直接按照PRD进行开发和测试的

——团队缺乏沟通，对需求细节的把控没有那么到位。

最后，在需求交付的时候，功能核对大概几种是在上线前1-2天。

这会导致很多风险项都没有办法提前暴露，需求理解不一致的情况没有办法得到

有效的处理。

2.真迭代-两个团队试点，每周一个敏捷冲刺

敏捷项目启动初期，在面对一个需求从开始到落地的五个环节：产品“定位”-用“

户定位”-“需求挖掘”-“需求开发”-“需求跟踪”时，几乎项目组所有核心人员都把最

紧急、最缺失的一票投给了产品“定位”。

我们发现，因为没有清晰的产品定位，所以每个人的着力点是不同的；大家像一

盘散沙，看似忙碌充实却绵软无力。最致命的是：因为没有清晰的RoadMap，

大家走一步算一步的状态影响团队士气和凝聚力。

于是，产品团队利用将近一个月时间的依据公司战略、产品目标、用户需求和市

场环境确定了清晰的产品定位“打造用户的专属摄影师”，以及根据产品定位确定

3

假敏捷“”到真敏捷“”：产品经理与敏捷相爱相杀的岁月

了接下来1-2年的长期目标和近三个月的短期目标。同时，每条线也根据共同目

标制定了版本迭代的计划。

计划的结果是无意义的，价值在与计划的过程本身“”，在互联网瞬息万变的环境

下，RoadMap肯定是会变的，但RoadMap能够让全项目成员做到心中有数“