B端产品经理必须掌握的三个能力！

前面一篇文章分享了在禅道软件团队做产品经理的日常。禅道项目管理软件是面向B端的强协同流程管理软件，覆盖了整个研发的全生命周期，业务逻辑还是比较复杂的。这对我们产品经理团队提出了非常高的要求，除了需求梳理、日常沟通、原型图绘制、数据分析等基本能力之外，还对抽象能力、拆分能力和架构能力提出了很高的要求。今天这篇文章就和大家分享下这三种能力具体的要求。

首先是抽象能力，包括概念的抽象、角色的抽象和流程的抽象

先来看概念的抽象。什么是概念呢？就是用一个词对某一类事物进行定义。比如一群人进行协作，需要对每一个人要做的事情进行定义，那每个人负责的这些事情可以定义为任务。一群人在一定的时间里面完成一些事情，那这个过程可以定义为项目。项目要完成的这些事情，可以定义为需求。需求比较多，要分期来完成，这一期一期的过程可以定义为迭代。这些需求归属于某一个最终要交付的交付物，这个交付物可以定义为产品。产品的需求有很多，需要定义什么时候做什么，这个就叫做计划。相关的产品和项目需要一个更高的维度来进行概括管理，这个更高维度的概念可以定义为项目集。

以上是禅道项目管理软件里面的部分概念，禅道里面总共有100多种概念。这些概念大部分业内已经有共识，可以直接拿来用。但也有很多是需要自己来抽象。比如在禅道里面项目有不同的管理方法，敏捷、瀑布或者看板方法，这三种不同的管理方法我们会定义为项目模型。在比如敏捷模型下会使用迭代来管理项目，瀑布模型下面用阶段管理项目，看板方法里面用Board来进行组织管理，需要有一个统称的概念来概括迭代、阶段和Board，我们抽象出了执行（Execution）的概念。

对概念的极致细分是我们和竞品的一大区别。我们竞品里面啥都是Issue，程序设计简单了，但对各种概念的表达描述就会比较粗线条，没有那么精细。

接下来就是角色的抽象和定义。每一个概念都可以对应到一种对象，我们需要定义跟这些对象进行交互的人都可以分为哪些角色。比如禅道里面的角色可以分为项目经理、产品经理、开发人员、测试人员、过程改进人员、发布负责人、公司管理层、系统管理员等角色。每种角色都有自己的职责、权限，对应到系统里面就要做这些功能和权限的划分。包括我们在写用户故事的时候，也需要按照角色来定义。

有了概念和角色，接下来就是抽象不同的角色在不同的阶段对概念的各种操作。然后这些操作会影响到概念所对应对象的状态、属性。新的状态属性又可以触发新的操作。新的操作又可以对对象的属性和状态进行修改。不同角色之间就这样可以协作起来了。这种协作的机制和过程就是流程。

对于一个通用产品来讲，流程的抽象定义就需要有足够的通用性和灵活性。定制类的项目就简单，基本上按照客户的要求进行梳理实现即可。但像禅道这样的产品，就需要充分地考虑不同行业、不同规模、不同管理风格公司的情况，做最大可能的匹配。同时还要有足够的灵活性。这就非常考验团队的抽象能力和创造力。比如禅道内置的多人串行任务、多人并行任务、孪生需求、多平台多分支产品等等，都是在解决不同客户场景的需求而提出的解决方案。

在禅道团队，我是明令禁止大家遇到问题就去看竞品的。一方面是因为遇到问题就看竞品，会导致无法形成自己独立的产品体系。另外一方面我们现在遇到的问题基本上是无人区，也没有竞品可以参考。所以禅道团队一直在不停地对产品进行各种程度的折腾改进，有着旺盛的生命力。反观我们很多的竞争对手，基本上是靠抄袭模仿，产品进行成熟期之后，团队就失去了动力，不知道干啥了。

上面是对概念、角色和流程的抽象。这三板斧抽象下来，产品的雏形就有了。

接下来就是将产品拆分成模块、需求，并进行排期的能力

首先是模块。怎么理解模块呢，就是产品功能的大块划分。比如禅道会有用户管理模块，有项目管理模块。项目管理模块下面还会有任务管理、版本管理等模块。模块可以理解为是对产品空间结构上的一种拆分。当我们做一个新的产品的时候，先把模块结构维护好，那这个产品的框架就有了。后续产品不断地更新迭代，也需要对模块进行动态地更新维护。从我们实践经验来看，模块划分到两到三级比较合适，形成一个树状的结构。有了这样的一个模块的划分，我们在后面做需求拆分、排期等操作就会有一个宏观的视角，能够做到胸有成竹。像我们很多竞品不提供模块的功能，所有的需求都是压平了堆叠在一起，缺少结构化的能力。

能不能将产品拆分成合理清晰的模块结构，是拆分能力的第一层考验。

有了模块之后，就可以按照模块的重要程度开始拆分用户故事。这一层的考验就是你能不能用用户故事的方式把一个软件系统的功能、逻辑、交互都表达清楚。我之前写的文章里面有讲过敏捷转型产品经理最难了。难就难在很多产品经理习惯了写需求文档、画原型图，改用用户故事的方式来进行拆分会很不习惯。

从我们实际的经验来看，拆分用户故事比较有挑战的是拆细和写明白。很多产品同事在拆分需求的时候会把若干个有关联的点放在一个用户故事里面，导致这个用户故事不是单一的，无论是理解需求还是估算用户故事规模都会更困难一些。还有就是能不能用简短的文字把标题定义清楚、把描述和验收标准整理清楚。这对很多同事来讲比较有挑战。

用户故事拆分出来之后，接下来就是对需求进行迭代规划。前面说的模块是对产品空间结构的划分，迭代规划就是时间上的划分。资源始终是有限的，客户的需求始终是无限的，来自老板和客户的压力始终是大大的，如何把需求排期做出来，让各方面的角色都满意，也是很有挑战的事情。做迭代规划需要有更宏观长期的目标，需要平衡好投入产出，所以对产品经理还有另外一个考验就是控制好自己做一个完美产品的冲动，保持清醒和克制。

做好模块、需求和排期拆分之后，接下来就是如何将这些功能模块融合成一个好的产品。这就到了产品架构层面的考量。前面的抽象和拆分过程也是架构工作的组成和基础，就像是打地基。地基打好了，接下来就是盖房子了。房子盖得好不好就要看架构能力了。我总结的主要是合理的导航结构、合理的UI体系和合理的交互体系。

首先是导航结构。前面讲概念的抽象、角色的抽象、流程的抽象，再到模块的拆分、需求的拆分、计划的拆分，这些抽象和拆分做好之后，产品基本上骨架就有了。接下来就是如何将它的人机交互体系做好。当一个产品经理跟我讲清楚这个产品或者某一个模块的导航结构时，我认为他已经把产品想清楚了。我们有想法、做规划还是容易讨论的，但再往下落，有的时候就很难，落不下去。所以看一位产品经理是否真正地掌握了产品或者某一个模块，看他的导航结构。导航结构是人机交互最重要的部分，导航确定了，产品就成型了。

导航结构确定之后，就是定UI和交互体系。有很多团队UI和交互是有专门的设计师团队来负责，和产品经理职责是区分开的。但我认为产品经理还是需要关注UI和交互体系。因为产品经理是最懂业务逻辑的，UI和交互体系应当服务于业务逻辑。有很多产品做的UI和交互很酷炫，但产品的使用效率反而受影响，方向上就偏了。UI和交互应当克制，这方面我觉得做得国内做得比较好的产品当属微信了，张小龙先生在这方面确实炉火纯青了。

导航结构、UI和交互体系是一位产品经理架构能力的外在体现，是前面抽象和拆分能力的延伸。一位产品经理能够在这三个方面做得比较好，就是一位非常优秀的B端产品经理了。