在一些公司中，可能没有明确的需求owner的概念。所谓的需求owner，是指，主要负责需求的人。这种负责，涵盖了整个需求开发的生命周期。他可以说是实现一个需求的核心人物。需求owner是一个介于普通开发者和项目经理之间的角色。他实质上就是一个开发人员，只是在为了需求能够按时交付，而必然要承担一下额外的责任。
这种需求owner在使用敏捷开发的团队之中比较常见。举个例子来说，在一些采用Scrum，并且由每个人认领用户故事的情况下，认领需求的那个人就是所谓的需求的owner。在采用分派需求的方式的时候，如果只分派给一个人，那么毫无疑问该人就是需求的owner；在分派给多人的情况，有时候会显示指定某个人负责这个需求，他也就是需求的owner，在没有显示指定的时候，这些人里面通常也会有一个默认的人选，他可能是资历最老，也可能是技术最好。
成为需求owner是一个程序员向上发展的重要的一步，它能够完全体现你身为一个开发人员的开发水平，也能初步反应自身的管理水平。但是，要成为一个合格的需求owner，还是需要付出很大努力的。

全面理解业务，掌控全局

这是一个很虚的目标，并没有什么准确的标准来衡量一个owner是否已经全面理解了业务。如果只是作为一个码农，那么只盯着自己的那一亩三分地就够了，基本上也能完成任务，就是一个质量的区别。但是身为一个owner，仅仅关注于自己的那一部分是不行，还需要对提出需求的场景，需求要解决的问题，以及需求将会涉及哪些模块都要有一个清晰的认知。有一个感性的标准可以用来衡量是否真的已经全面理解业务了：“当发生问题的时候，你第一时间就能知道问题发生在哪里。”
理解需求，首先要理解业务。有些团队会用用户故事，有些团队会用场景，也有一些直接用用例，但是他们实际上都是问题的一种描述。owner应该理解问题提出的背景，解决了用户什么痛点，并且要清楚自己是如何解决这些痛点的。owner还应该仔细分辨出系统的边界，之后才能确定系统的输入和输出。
从模型上来说，owner应该熟悉每一层次的模型。在数据库层面，应该清楚数据模型，并且能够解释清楚数据模型的设计理念和它对业务的契合点。在业务层面，应该能够清楚不同业务模型是如何解决问题的。
从代码层次上来说，身为一个owner，那么该需求的核心部分肯定是自己开发的。对于这个部分，自然是烂熟于心。同时，owner还必须对依赖的模块，或者被依赖的模块都要了解清楚。这种了解并不需要详细到清楚代码是如何实现的，但是应该要知道不同模块之间的交互的“契约”，以及模块需要满足的一些约束条件。在开发完成之后，owner需要把握这些契约被遵守的程度，以及约束条件是否都被满足了。
掌控全局，就结果来说是指，当任何一个人问及这个需求的时候，owner都应该能够从各个层面，无论是需求分析、设计、编码还是测试，进行详细的分析。就过程而言，是指时刻关注需求的进展。如果这个需求仅有自己一个开发，那么问题并不会太大。但是当是多人合作的情况下，跟进进度就是必要而且是必须的了。owner并不需要时刻盯着合作者，实际上owner也没有那么多的时间。更加多的是心中有数，如合作者已经进行到了哪一步，是否遇到了问题，以及遇到了什么问题，什么时候解决能问题，这些内容都是owner要关注的信息。在遇到一些难以解决的问题的时候，owner就需要承担起一种“定心丸”的责任来。这并不是说owner必然要能够解决这种问题——实际上owner不一定就是技术最强的人，但是owner要表露出自己能够解决这个问题，并且付诸于实践。owner可以撸袖子自己上，也可以给出思路，或者寻求别人的帮助。从这个方面来说，owner就像是军队当中的排长这种低级军官，既能够指挥小规模的作战，必要时刻，也有端起冲锋枪上阵厮杀的勇气。owner就是一种介于普通人和管理者之间的角色。
最后一点是，owner要能把握需求演化的痕迹，即能够解释需求最初的状态，是如何演变到现在的状态。相应的是，解决这个需求的系统的演变痕迹，owner同样也要清楚。后一个要求比较难达到。一般来说，一个需求只不过是一个系统的一小部分。能够做到对整个系统的演变都了如指掌，那自然是极好的。但是底线是，对系统的涉及需求的部分的演进要了如指掌。即便是这个小目标也会有一些困难。最重要的一个困难是，对于第三方提供的支持，要想了解它的演进过程是比较麻烦的。

协调第三方资源

第三方就是一个事故多发地。通常来说，一个需求很少是一个团队内部就能够全部完成的，多多少少都需要第三方的支持。这种支持可能是提供接口，也可能是提供数据，或者提供一些机器资源等。协调包含了两层，一层是确保第三方能够按照需求提供支持；另外一层是，他们能够按时提供支持。
在开发尚未开始，或者初开始的时候，owner应该就所需的资源与第三方进行协商。这种协商不同于需求讲解。需求讲解是指正式的需求评审会议或者不正式的需求沟通。而这种协商，通常是技术层面而言的了。如果需要第三方提供的是接口，那么协商的应该是接口的定义；如果需要第三方提供的是数据，那么应该是数据的格式、大小等；如果需要第三方提供的是机器等实体资源，协商的应该是具体而且详细的资源要求，诸如内存多大，硬盘多大等。除了协商这些内容以外，还有一个很重要的东西需要协商，就是时间。owner必须要有约定好具体的时间，比如接口什么时候完成接口定义，什么时候能够提供真实数据，什么时候能够开始联调。
当这些协商好之后，并不是万事大吉了。因为涉及到第三方，那么可能出现各种意外。owner应该时刻跟进第三方的进度。在每个约定的时间节点之前，要去确认第三方究竟能否按时完成约定，如果不能，那么会推迟多久，以及是否有补救的办法。这里要注意的是，探究因为什么而延期了是没什么价值的，owner只需要确认的是会不会延期，延期多久，能否避免。为什么延期这种问题，除了破坏合作以外，没别的用处了。延期是一个很可怕的东西，但是却又是经常遇到。所以owner在最开始制定开发计划的时候，就应该考虑到这种情况。好的实践是，一个迭代的时间不能安排得太紧凑，应该留有适当的时间作为这种延期的应对。如果一个需求，当且仅当所有第三方都能按时交付的时候才能按时交付，那么就我个人经验来说，这个需求多半不能按时交付了。
对于一些复杂的需求，或者有比较多的约束条件的第三方的支持，还需要额外跟进他们提供的支持是否满足需求，是否满足约束条件。比如说，如果需要第三方提供一个能够应对高并发的接口，那么应该及早进行压测，确认接口能够满足条件，而不能拖延到需求提测的阶段。如果一些接口的业务逻辑十分复杂，那么owner需要跟进接口能否返回正确的结果。owner可以不必了解接口的细节，但要确保接口满足条件——包括非功能的条件。
此外，还要协调好联调的时间。千万要避免的是，一个个询问第三方什么时候有时间，然后取交集进行联调。这样很可能发现，当A有时间的时候B没有时间，B有时间的时候，C没有时间……最终找不到一个时间段是大家都有时间的。应该先确定下来一个联调的时间，然后通知所有的第三方。当然，很可能会有一些第三方说自己没有时间，但是，这已经把主动权掌握在自己的手中了。这之间的区别在于，前一种策略，是owner依据别人的时间来安排时间，而后一种时间让第三方适应自己的时间表。当真的有第三方表示确实没有时间，那么可以换一个时间，但是不应该将这种主动权让渡出去。
在需求发生变更的时候，还需要协调第三方进行相应的更改。这是最恶心的事情了，然而需求总是在不断的变化之中。需求发生变更之后，需要再次确认关键的时间点。如果约束条件发生了变化——比如原本只需要一般规模的并发，现在要求应对更高规模的并发，这些特性依旧需要再确认一次。总体来说，就是当需求变更了，应当尽量当成是一个新的需求来重新确认各个细节。
在测试的时候，有些时候还需要协调修BUG。有一些问题，属于A处理也可以，B处理也可以。如果两个人都觉得可以自己处理，那么什么问题也没有。就是担心，每个人都觉得不是自己的问题，那么这个时候就需要指定一个人来处理这个问题。（如果遇到这种人，下次和他合作就要多一份小心了）
以上讨论的，同样适用于为别人提供支持，只是角色和内容要发生相应的变化。

风险管控

世界上没有什么东西是毫无风险的，需求也是一样。风险可能是业务风险，也可能是技术风险。这些风险可能来自于需求变更，也可能来自合作不顺畅，也可能来自于一些意外情况，但是不论来自哪里，识别风险和控制风险是一个owner应该努力做到的事情。
前面的几个部分，一直都有强调一点，就是第三方就是风险点。除此以外，时间也是一个风险多发地。主要的体现就是无法按时交付。owner应该能够尽早识别出这种时间上的风险。在敏捷开发里面，强调了一个概念，就是不关注已经完成了多少，而关注还剩下多少没有完成。对应于这种理念的，就是燃尽图。即便没有真正使用燃尽图，owner也应该要有一个衡量还剩下多少工作量的方式。如果确定进度已经落后于计划了，要及时采取措施。如果发现的确没有办法按时交付，应该及时通知产品经理，或者其余相关人员。
需求变更也是一个常见的风险。一个狡猾的做法就是，每次预估工作量的时候，多估计一部分，作为应对需求变更的余量。实际上，需求变更总是无法避免的，谁也不能要求产品经理不能变更需求。所以唯一能够做的，就是做好准备而已。牢牢记住一句话，如果一个需求只有在一切按部就班的情况下才能按时交付，那么这个需求绝对不可能按时交付。
除了这些每一个需求都会遇到的风险，还有一些风险是和业务紧密相关的。这种风险就只能依赖于owner对业务的理解了，并没有什么统一的处理方式，我也给不出什么好的建议。唯一能说的就是，料敌从宽。

树立主人翁意识

我并不是开玩笑，也不是谈论政治，我是在谈论一个很明显很简单的东西。
所有的开发者，大概可以分成两种，一种是积极的，一种是不积极的。或者说一种是主动的，一种是被动的。积极的程序员，会主动的沟通，主动的解决问题，毫不推脱。而不积极的就恰恰相反了。
那么，可以肯定的说，一个需求owner必然是一个积极的程序员，积极是成为owner的一个先决条件，必要但不充分条件。
在一些团队之中，肯定有这样一些老油条。这种人就是所谓的“踢一脚，滚一滚”。安排事情给他，不用担心会出问题，但是也不要期望会有什么惊喜。这种人不要给他逮到一点点的偷懒机会。用一句形容渣男的话来形容这种程序员也是恰当的，就是“不主动，不拒绝，不负责”。这种老油条，即便经验再多，技术再好，都无法胜任一个owner的角色。
成为owner，很重要的一点就是要主动投身进去。要主动去理解问题，发现问题，跟进问题。时时刻刻要准备好与人沟通，不管是不是自己一亩三分地上的事情，只要和自己有关，就得去了解一番。owner要时刻有一种“它是我的”的觉悟，克服与生俱来的那种偷懒懈怠的想法，不给自己任何一个放弃的理由，也不给自己任何一个松懈的理由。如果遇到难题了，就勇敢解决它；如果合作者或者第三方拖拖拉拉，那就使劲催，夺命连环催，喊上老大一起催。

后记

owner这个概念，是和老板交流的时候得知的。按照我的理解，owner就是一个介于程序员和项目经理之间的角色。它除了开发指责，还承担一定的管理指责。也可以说是一个部分产品经理+部分项目经理+开发人员的角色。我认为，一个企业的底子，就体现在这些owner的数量和质量上。如同军队一般，底层军官的数量和质量对于部队的战斗力有很大的影响。owner在不同的企业里面会有不同的说法，也可能压根就没有这么一个明确的概念。也可能就是体现为资深开发人员或者高级工程师什么的。但是，他们的戏份都是类似的。