不懂敏捷开发的产品经理不是好的项目掌控者——道与术的结合

前言

道与术是中国传统文化中非常有意思的两个概念,道讲述原理和思想,术侧重方法与实践。王阳明先生的心学中有过一句名言叫“知行合一”说的就是这个道理。虽然我们已经来到了互联网的时代,可我觉得,传统文化中的道与术思想依然可以指导我们去更好地掌握工作和生活。

在敏捷开发中,毫无疑问,道就是敏捷开发的思想,而术则是敏捷开发的实践。道惟一法,术有千变,短短一文不可能把所有的应用都说清楚,但希望以一些的简单例子起到抛砖引玉的作用,让大家重视敏捷开发对于产品经理管理项目的价值所在。

道:敏捷开发

本节将从敏捷开发的历史背景和其与产品经理千丝万缕的关系讲述敏捷开发的道。

历史背景

上世界90年代有一种“极限编程”的思想,其中提到了以下一些概念:自选任务(self-chosen tasks)、测试先行(test first)、三周迭代(three week iterations)、集体代码所有权(collective code ownership)和结对编程(pair programming)。随着时代的发展,编程,特别是指的软件编程,因为软件变更速度越来越快,传统的瀑布式开发方式再无法快速响应时代的需求,从“极限编程”中汲取营养最后形成的敏捷开发,开始成为互联网时代的新宠儿。

可以说敏捷开发和互联网时代是一个彼此造就的关系。在互联网时代,资本快速的涌进,市场需求的变动难以预测,才让敏捷有了其用武之地。

敏捷与产品经理

敏捷是为了响应市场快速的变化,而产品经理则是产品需求的发掘者和客户使用体验的代表。

从敏捷项目管理的角度去看,产品经理在提供完需求以后就对整个环节不再有掌控了。虽然不排除创业的团队中因为人手不足,产品经理需要身兼数职这种情况,但是本文所讨论的主要是产品经理和敏捷的关系。

那么到底为什么产品经理需要了解敏捷开发呢?其实道理很简单,因为敏捷开发每个需求都来自产品经理的梳理。很多时候,用户提出的需求是庞杂和混乱的,产品经理需要从场景出发,有逻辑地梳理出来每个场景下用户真正需要的是什么。而更加重要的是,一个懂得敏捷开发的产品经理,知道如何对产品需求进行更加有效细致地划分,尽可能地使得每个需求相对独立,并且都可以满足敏捷开发的安排。这样,从产品最终落地的这个大项目上,敏捷开发这个小的子项目才能够更好地完成。

敏捷开发有几大工具,如何把这几个工具使用好,才是贯彻敏捷开发的核心要素,而这几点和产品经理都有着或多或少的关系:

  1. 需求池。敏捷开发中,开发者会自己从需求池中选取要去开发的功能点,把研发速度向前推进,这就需要产品经理对于产品功能需求的划分比较到位,才能让需求池中的需求研发做起来,彼此之间的耦合度最低。
  2. 快速响应。敏捷开发需要快速响应市场需求的变化,这就需要一个产品经理对于自己产品市场的反馈和跟进是非常及时,并能跟进其结果得出新的需求方案。
  3. 快速迭代。敏捷开发需要产品能够快速迭代向前,这就是考验一个产品经理对于产品开发的规划能力,需要相当的前瞻能力和判断能力。

所以,本文的题目叫做不懂敏捷开发的产品经理不是一个好的项目掌控者,就是希望产品经理既能够从宏观层面上了解好用户的需求,也能够从项目掌控的层面上理解敏捷开发的原理和周期,从而让每个小的需求适应好敏捷开发的特色,最优地发挥所有参与人员的价值。

术:实践出真知

在术这个章节,笔者将用一个简单的OA开发为例子,讲述如何完成一个敏捷开发的项目规划,以及哪些工具可以更好地帮助我们进行敏捷开发。

小OA也有大道理

OA项目是非常常见的一种开发项目。不论是大公司,还是小公司,只要公司有不同职位、不同分工,只要公司需要绩效考核、看重KPI等,OA的存在就是必不可少的。本文将使用的就是笔者作为产品经理参与开发的一款OA系统为例子来进行说明。

首先,根据前文中所讲述的产品经理与敏捷开发之间的关系,我们首先需要的是先去理解用户的实际使用场景,然后将用户的场景分解成许多小的子场景,才能更好地适配敏捷开发的需求。

  • 用户场景

用户所在部门因为其本身组织架构的变化,业务流转发生了巨大的变化,因此需要一套新的OA系统来适配当前的组织架构图。

  • 用户业务梳理

对用户新的组织架构进行抽象以后,其中包括三个角色,分别为执行者、审核者、管理者。管理者负责分配任务给执行者,执行者完成任务以后提交审核者审核, 审核通过以后进入资源库,然后管理者可以在资源库查看任务的进度和结果。那么对这个三个角色再进行子场景的划分。如下图所示:

不懂敏捷开发的产品经理不是好的项目掌控者——道与术的结合

  • 子场景划分

根据以上对业务关系的梳理,最终可以划分为两个子场景

  1. 任务分配->接受任务->查看任务进度->提交任务。
  2. 任务审核->分享优秀任务。

宝剑配名士——谈工具的选择

一个好的开发团队离不开好的工具进行协助,好的工具就好比宝剑,配备恰当才可以事半功倍。

  • 业务梳理工具

不论是产品经理还是开发者,都需要能够将产品的业务流程梳理清楚,只是双方的侧重点不同而已。产品经理侧重的是从用户角度出发,操作上的业务流转。开发者则是从代码逻辑层面出发,看中的是具体实现方法。
这里笔者提供一个非常好用的工具——MindManager。MindManager是一款非常好用的脑图工具,而且该工具不只是可以画脑图,对于项目流转使用的泳道图等其他图,并且这是跨平台的软件,支持windows和mac版本,这个对于偏好苹果的产品经理和windows开发机器的研发人员也是一个很好的平衡。

  • 代码管理工具

代码就好比一个产品的内功,如何管理好代码就好比如何修炼好内功一样,是非常重要的。在这里,笔者谨慎安利一款非常好用的工具,其少有的可以将代码托管与项目管理兼顾结合的能力一下子就抓住了笔者的眼球,这就是——CODING。
CODING的本质是一个代码托管平台,其企业版则更是在代码托管的基础上增加了项目管理的功能。这样一个平台即可以进行编程工作,也可以实现对敏捷管理的需求。同时,CODING配套的云端编译器、app工具让企业的开发更加的灵活,也是非常符合敏捷概念的。下面一节将会专门讲述CODING与敏捷开发的结合。

CODING与敏捷开发的结合

项目管理

CODING有一个完善的项目管理体系,通过这个地方,可以很好管理自己团队的项目情况。

不懂敏捷开发的产品经理不是好的项目掌控者——道与术的结合

在项目内创建开发任务

  1. 创建里程碑。
    根据产品子场景的划分,开发者可以很好地利用里程碑划分开发阶段,如下图所示,可以将前期的工作划分为基础功能开发、任务下发联调、任务审核联调等。

不懂敏捷开发的产品经理不是好的项目掌控者——道与术的结合

  1. 创建任务

根据里程碑创建各类任务,可以有开发任务、联调任务、测试任务等等,与里程碑相呼应。

不懂敏捷开发的产品经理不是好的项目掌控者——道与术的结合

  1. 管理任务进度

在任务看板界面,开发者可以根据自己的习惯创建自己的分类方式,并根据每个任务的进展情况来管理整体任务看板。

不懂敏捷开发的产品经理不是好的项目掌控者——道与术的结合

总结

通过本文的说明,笔者讲述了一个产品经理如何通过对敏捷开发的理解更好地进行需求分解,从而解决开发和产品的本质矛盾,达到高效能完成产品项目的目标。同时,笔者推荐了两款好用的工具,来辅助团队更好地实践敏捷的思想。