如果我们在一个敏捷开发团队(Scrum team)中工作，无疑都知道应该有一个产品订单(product backlog)和产品拥有者(product owner)，但是究竟什么是产品(product)呢？
对于一些团队来说，这可能是一个相当基础的问题。毕竟一个团队一开始不了解到底什么是产品的时候，无法确定合适的产品拥有者、团队和角色。同时，如果每个产品都有一个产品订单，那么在为每个产品创建订单之前，我们要知道我们的产品到底是什么。
在大多数情况下，确认一个团队的产品看起来很简单。比如，手表制造商可能将他们销售的每个商品都视为产品。但是就这样可能将事情过于简单化。一些团队在识别产品上面困难重重。
什么是航空公司的产品(Airline’s Products)
以航空公司为例。几年前当“何为产品”这个问题出现时，我和一个航公公司有合作关系。该公司一些人认为航空公司只做一件事：将乘客从一个地方运到另一个地方。因为，他们认为尽管公司有4万多名员工，公司应该只有一个产品。
其他人认为航空公司内有很多产品。例如，他们有一个面向乘客的网站，能用来预定，登机（check in）和查询航班状态。他们还有一个用来监控和调度飞机维护的系统。还有一个允许机组人员根据其资历来选择他们希望工作的航班的系统。
这些也是产品吗？
产品的定义和实例
我将产品定义为通过一个流程(Process)所创造并给市场带来价值的事物（有形或无形）。
从这点来看，一个椅子是一个产品，Microsoft Office是一个产品，敏捷咨询服务(Agile consulting services)是一个产品，一幅画是一个产品。产品可以是实体，比如椅子，它也可以是数字产品，比如Microsoft Office、一本电子书或者流媒体视频。产品也可以是一个服务，如怎么采用敏捷的咨询。
一个产品甚至可以只是一个想法（idea），比如一个专利算法或者在Tinder（一款手机交友APP）上正确滑动的方法。
这些都是通过一个流程所创造的，更通俗的说是由一个或者多个活动(Activity)所创建的。有人加工并组装了椅子，Microsoft Office由设计、编码并测试得到。创造产品的流程不需要被正式定义，创造者甚至可能没有意识到这个流程，但是，每个产品都要由一些特定的活动所创造。
产品可以被递归(Recursively)的定义
一个产品可以并存于另一个产品中。例如，一支笔可能有可替换的墨芯。笔是一个产品，而在笔内的墨芯也是一个产品。
甚至一把椅子也有子产品。制造和销售椅子的公司可能从另一家企业采购了被完全加工的椅子脚。椅子脚就成了要给产品。
产品可以被递归的定义的。一个木材公司采伐树木使木材本身成为一个产品。接下来，一个加工公司用这些木材做椅子脚，然后另一家公司拿这些预加工的椅子脚，用他们的设计组装成椅子。所以说产品可以并存于其他产品中。
产品给市场带来价值
当我们定义一个较大产品的子产品时，我们需要注意每个子产品都要给市场带来价值。上面的定义并不是说需要购买的才叫产品，而是，作为一个产品，必须满足需求或者愿望。
对于椅子的椅子脚和笔中的墨芯这个定义是正确的。当对一个项目中的产品下定义时，如果是敏捷开发的项目还需定义产品拥有者和产品订单，这时定义每种产品至关重要，这有利于市场发展。
将此定义应用于航空公司的例子
如果产品是通过一些流程创造出来的，并且对市场带来价值，那么软件组件(software components)是产品吗？
为了回答这个问题，可以回顾下刚刚提到的航空公司的例子。知道了产品是由一个流程创造出来的，并且给市场带来价值，这对定义航空公司定义其产品有何帮助？
首先，很容易看出，将乘客从一个地方运到另一个地方这是一个产品。对那些乐于为能将自己飞往某地而付钱的人来说，这个活动给这个市场带来了价值。
然而，关于用来监控和调度飞机维护的系统呢？我认为，这也是个产品。
它通过一个流程所创造，同时对市场有利。那么，这个市场指的是？
是的，我们可以从头到尾说乘客从保养良好又安全的飞机中收益。但是，更接近这个产品的过程，我们可以说是航空公司的员工从中收益，他们用计算机来监控和调度飞机维护，而不是用纸来人工维护。
航空公司的网站也可以这样说，它使得用户可以在线预订航班，这就是一个市场。
所以，我们的航空公司有一个大的产品，同时，它也有很多子产品。公司内部任何被认为能给市场带来价值的，都是产品。
将此定义应用于软件
正如刚刚说的，考虑到一个软件，如果一个团队开发的软件被其他团队使用，这能被认为是一个产品吗？以一个团队开发日历组件(calendar widget)为例，这个组件给市场带来了价值：别的团队将会使用这个组件，这个为多个团队开发的组件就是一个产品。
我将那些仅被一个团队所使用的日历组件（或者任何组件）区分开来。是的，技术上来说只有一个客户，市场也能存在。比如一幅画被卖给一个人。
但是，当讨论到产品开发（如敏捷）时，如果某些东西只由一个人或一个队伍使用，那么把这些东西当做产品是见危险的事。例如：它会导致将代码（做为产品）是交付给测试者这个市场的。这不仅回到顺序（或阶段）开发，也是一个局部最优化(suboptimization)的形式。
避免将产品局部最优化
根据圣荷西州立大学经济学教授泰勒·沃特金斯(Thayer Watkins)的说法，“局部最优化”是指将重点放在一个组成部分的做法，并进行改进，旨在改进这一个组件…而忽略对其他组件的影响。
虽然团队确实想要定义他们所有的产品，以便最好的管理工作，但是他们也不希望将焦点缩小到看不到整体的程度，如果产品被固定到各自独立的部分上。因此，团队都希望能尽可能广泛地定义每个产品。
话虽如此，当我们回看航空公司的例子，在定义产品时就有一个过于广泛的事情。当一个产品非常大以至于要服务多个市场时，我经常更愿意把它视为多个产品，每一个产品服务一个唯一的市场。
比如，将Microsoft Office作为一个单一产品很容易，然而，Office是一套产品，每一个子产品提供了不同的功能，并为略有不同（有重叠）的市场服务。
因此，我愿意将Word、Excel、Power Point等都视为各自的产品。每一个都将有自己的产品拥有者和产品订单。
有了像Office这样的大型产品，则很可能会有基于跨越其他产品（如Word、Excel、PowerPoint等）的共享功能的产品。例如，把拼写检查程序(spell checker)作为一个产品就可以说得通。拼写检查程序可以给市场（对于那些不需要自己从头开发他们自己的拼写检查程序的团队）带来价值。
然而，我不会将Excel的功能部件(Function widget)，例如：Sum, average, count等定义为产品。他们对于Excel是唯一的，只服务与这一个客户。在Excel之外，给予这些功能部件产品订单和产品拥有者是很危险的。
除了避免一个客户的产品之外，另一个在多产品工作中减少局部优化思想的方法是任命一个首席产品拥有者。这是一个战略角色，负责在所有子产品中建立视野(Visio)。例如，在Office产品上，首席产品拥有者将会关注每一个产品如何影响整体。
你怎么认为？
正确地识别你团队中的产品，可以帮助你避免团队结构、产品订单管理、人员角色错误的问题。你是如何定义你团队中的“产品”？是否有可以让你推断出创造一个一般定义的产品的方法？请在下面的评论中分享你的观点。
作者简介：
作为山羊软件公司的创始人，Mike Cohn专门帮助公司采用和改进敏捷流程和技术的使用，以建立极高绩效的团队。 他是敏捷软件开发用户故事，敏捷估算与规划和敏捷成功的作者。 Mike是敏捷联盟和Scrum联盟的创始成员。 Mike可以通过hello@mountaingoatsoftware.com联系。 如果您希望通过敏捷成功，您还可以让Mike每周向您发送一个简短的提示。
原文链接：https://www.mountaingoatsoftware.com/blog/what-is-a-product
长按二维码关注