跨团队的项目评估
Title
跨团队的项目评估
Patlet
要推销跨团队的内源项目的价值是很难的，因为这些项目并没有对公司的收入产生直接影响。 这里有一个数据驱动的方法来展示和凸显你的项目价值。
背景
你负责一个跨团队项目，为公司其他团队提供平台服务。
这种跨团队的项目并没有为公司的收入带来任何直接的价值。
问题
跨团队的项目有可能对公司产生非常大的影响，但很难用数据驱动的方式来表示。 因此，在不提供真正价值的项目中耗费很多精力或对本来会产生巨大价值的项目投资不足是一种非常容易产生和普遍的现象。
约束
项目需要向公司领导展示价值（客观或主观）以获得资金支持。
跨团队的项目价值分散在多个终端业务部门。
由于这种分散性，跨团队项目的价值很难直接衡量。
解决方案
定义一个如何评估跨团队项目价值的模式和模型。 这种模式给我们提供一个需要关注和放大公司的高价值合作的工具。
所有跨团队项目价值的核心是，我们可以一起完成比分头行动更多的工作。 衡量一个跨团队的工作价值是一个量化大家一起完成的工作 怎么就更多 的练习。 不同的领域和项目的生产效率存在差距。 有一个常见的流程，你可以用它来创建一个模型，用来计算这个协同带来的价值。
解释
组建一个由你的领域内的相关专家组成的小团队。 利用这个专家团队，对使用你项目的每个消费者进行4个方面的估计：
他们需要多长时间来消费你的项目产出？
如果一切都靠他们自己来实现，他们需要多长时间才能实现和你项目一样的功能？
你的项目产出中有多大比例对他们来说是有用的？
如果不这样做，他们会花多少时间（每个用户）来维护他们自己的解决方案？
在进行这些估计时，不可能高度准确地知道任何活动需要多长时间。 这不是你的目标。 与其说是准确，不如说你应该努力为这些估算 设定一个最坏情况下的界限。 我们的想法是让专家组能够达成一致："我们不知道到底要花多长时间，但我们都同意至少要花这么多时间"。 具体来说，你应该估计出使用你的项目的 最大 合理时间，以及消费者如果自制、使用和维护他们自己的解决方案的 最小 合理时间。
关于 "实现你自己的解决方案"（home-roll）的成本的一个说明。 自研解决方案的成本不一定（事实上不太可能）与制作一个共享解决方案的成本相同。 通常情况下，对于相同的功能，建立一个跨团队的共享解决方案所涉及的模块化和质量的投入明显高于只使用一次的快速、硬编码的实现。
公式
一旦你有了最坏情况的界定，你就可以通过简单的公式来评估你在给定时间内的跨团队项目产出。
评论
尽管有严谨的外表，这个过程并没有给出衡量跨团队项目产出的确切方法。 然而，在实践中，它确实提供了一个计算框架，你可以据此对如何资助这个项目做出合理的决定。 根据上面的解释，在有了好的、合理的数据之后，你应该运作项目投入专门的开发时间，投入 至少 要达到以下三个层面中的较小者。
通过上述公式节省的原始时间。 既然我们都确信这个公式会产生一个低于真实节省的小时数的数字，你就可以有信心，就项目投入到节省的时间，对你来说是稳赚的。
支持内源性贡献给跨团队项目所需的时间。 由于贡献者很可能会以一次性的方式完成工作，所以资助他们的工作以达到协同工作所需的时间是值得的。
只要你觉得好就行。拥有一个估值公式的一个有益的副作用是，它自然会迫使大家对项目消费者提供价值的关键使用点进行测量。
通过理解这些测量结果，并以其原始形式进行使用，那你就可以得到一个关于项目有多大价值的直觉想法。
有些人可能会担心这种评估方法缺乏准确性。 虽然这个过程不能给出一个非常准确的测量结果，但它只需要在两个方面提供足够准确评估：
为那些组织和资助跨团队工作的人提供一种展示正在发生的价值的手段。
帮助那些参与者根据价值的优先级明确跨团队工作的哪些领域是值得追求的。
在实践中，只要这些价值是在现实和彼此之间的一个数量级内，它们就足够准确，并满足这些目的。与本文开头的问题部分所描述的临时评估（以及由此产生的影响）相比，它们将在实际结果中提供一个从源头入手的改进。
结果
用数据驱动的方式与领导层讨论跨团队项目的价值和资金。
围绕跨团队项目的关键指标，以原始形式进行检测。
定义跨团队项目所提供的价值，可能导致它实际上为公司产生更大的价值。
推动更多项目成功，并且不断宣传这些成功项目。
已知实例
Nike
状态
结构化
在多个领域得到证实。
作者
Russ Rutledge
致谢
Jeremiah Wright教我把跨团队项目看作是以开发者时间为货币的内部业务。
翻译校对
最后更新于