使您的技术和产品团队与技术产品画布保持一致

收听本文的音频版本

产品开发和技术团队之间的沟通不畅可能是软件开发中资源浪费的最大来源。 高增长的科技公司正面临对产品交付的日益增长的需求，因此，有时会放弃适当的规划。 有多种迹象表明产品和技术团队缺乏一致性：

• 未按要求交付的产品。
• 交付产品功能所需的时间比计划的要长。
• 团队每周几乎没有互动和沟通。
• 由于新产品的需求，技术团队不得不“重新做”他们的基础设施。
• 与竞争对手相比，发展速度感觉缓慢。
• 技术团队经常问：“你之前为什么不告诉我们？ ”

成功的公司积极管理这两个团队之间的接口，并拥有每个人都理解的清晰的产品和技术路线图。 然而，目前还没有任何流行的方法以结构化的方式解决这个问题。

相反，大多数时候，这些目标是通过非结构化会议以临时方式实现的。 与此最接近的比较是规模化敏捷框架，但即使是这些方法也并不总是适用于所有公司，尤其是较小的公司，因为这种方法需要采用整个框架。

轻松实现产品和技术团队之间一致性的方法之一是使用结构化的技术产品画布

什么是技术产品画布？

画布概念已经存在很多年了。 该领域的主要远见者和创新者包括创建商业模型画布的 Alexander Osterwalder、Roman Pichler 和他的产品愿景画布，以及以用户故事映射方法和他的机会画布而闻名的 Jeff Patton。 我使用画布方法来解决产品和技术对齐的问题，并创建了技术产品画布。

画布将作为促进团队讨论并让每个人都在同一页面上的快速方式 - 从字面上看。 这是创建此文档的最重要的好处之一。 通过整个过程（可能只需要一个小时），您将开始管理产品和技术团队之间的一致性。

技术产品画布迫使您的团队陈述和可视化产品路线图目标、技术路线图目标，并明确讨论路线图的每个产品技术阶段。 此练习可确保团队保持同步，并且每个人都可以带着明确的期望和方向离开房间。

通过与科技公司的合作，我注意到业务目标和技术能力之间的交叉点是最大风险所在。 创建技术产品画布是为了管理这种确切的风险。

何时使用技术产品画布？

技术产品画布讨论最好由产品所有者在您完全定义产品愿景、执行故事映射过程并制定初始产品发布路线图时发起。 在这个阶段，哪些产品功能对每个主要版本至关重要。 此时，团队已准备好就如何构建产品进行详细的技术讨论。

技术产品画布练习将带来清晰性，有时会产生冲突，但最终会就开发产品需要采用哪些技术架构以及技术平台将如何发展以满足产品需求达成一致。 它将允许技术团队集思广益，并确保获得他们对创新的投入。

让我们通过一个更详细的示例来说明如何在假设的新软件企业中使用技术产品画布，以便我们可以看到它的实际应用并学习如何使用它。

如何使用技术产品画布

技术产品画布主要是用于创建焦点、沟通和团队协调的工具。 画布允许您与您的技术团队进行对话，以确定支持产品开发所需的技术架构。 让我们使用一个新软件产品的假设示例。 一个新的基于位置的应用程序，可以将人们与周围的人联系起来 - 一个社区应用程序，可以将您与您的邻居联系起来。

您可以在此处下载技术产品画布。 您也可以打印出画布并在上面写字。 或者，您也可以使用我在本文中使用的 Miro 等在线工具。

配置

假设您已经与您的初创团队合作了几个月，您有一些很棒的想法，现在您热衷于计划软件开发。 您已经在精益画布上工作，甚至创建了用户在使用应用程序时将体验到的流程步骤的故事图。 现在您需要构建它。 因此，您让每个人、您的产品团队和您的技术团队都进入会议室，并在会议室屏幕上投影一个空白版本的技术产品画布。 从哪儿开始？

首先是对为什么每个人都在这里以及您要实现的目标设定期望。 向您的团队解释他们来这里是为了确保产品目标和技术任务之间的计划。 此外，强调您并不是在寻求完美，并且随着您了解更多和需求发生变化，您将每隔几个月继续审查一次。 但是，至少在今天，这是为了确保你们都在同一页上。

第 1 步：定义成功指标

您将如何衡量您的整体计划是否有效？ 业务目标是什么？ 它们可能是每个发布阶段的收入或应用下载次数。 如果您熟悉精益画布，您可能已经确定了这样的数字。 将该信息复制到此部分。 在这个例子中，我使用了以下两个成功指标：“在我们的第一年联系 1,000 人”和“在洛杉矶创建我们的品牌”——一个可量化的指标和一个定性的指标。

但是为什么我们首先关注这个呢？ 它确保整个团队都明白我们为什么在房间里。 我们有一个比任何产品或技术问题更大的目标。 这是我们都在这里的商业原因。

第 2 步：完成您的产品愿景和产品发布部分

这使团队能够清楚地了解我们的产品愿景是什么以及我们目前如何定义我们的产品开发优先级。 写下产品愿景声明以及主要目标群体是谁。 然后，确定您希望在每个版本中交付的一些关键产品项目。 我建议作为一个团队填写这些框，而不是事先预先填写。 它确保技术和产品团队成员都参与定义目标的过程。 从左到右工作：确定第一次产品迭代的目标——满足客户需求所需的主要功能。

在我们的应用示例中，我们的产品愿景是“让居住在我附近的人们之间能够进行实时交流，以加强社区”。 之后，在产品发布中，我们可能会说版本 1 是“识别您当前的位置，显示附近的人并与他们的电子邮件地址通信”。 V2 可能是“显示附近的人并允许实时聊天”。 V3 可能是“实现隐私和货币化”。 产品的这些迭代将输入到画布中，如下所示。 使画布尽可能简单，以便人们可以看到全局。 画布也旨在捕捉长期愿景。 请记住，这可能是技术团队第一次看到如此清晰的产品图景，因此请花足够的时间确保他们了解每个版本和随附的要求。

第 3 步：将技术愿景与产品愿景相匹配

现在是时候从技术团队那里获得意见并定义他们对技术架构将如何发展的愿景了。 从技术愿景开始，该声明概述了开发的大局，并且可以在供应商工具更改后继续存在。 在我们的应用示例中，技术愿景可能会声明：“使用提供位置信息的设备的地理位置功能，并使用无服务器微服务来启用云协作功能。” 在这一点上，我们没有选择特定的工具。 将技术愿景视为技术将如何提供帮助以及我们正在寻求采用哪些创新以实现竞争优势以及可以使我们实现愿景的技术跑道的大创意。

第 4 步：将技术计划与产品目标相匹配

这就是橡胶上路的地方。 在第 2 步中，对于每个产品发布迭代，都确定了关键特性。 现在您需要为每个版本定义技术计划。 确定需要哪些技术架构和工具来支持这些功能。 确定确切的工具并获得技术是可以的。 如果需要，您可以在未来的版本中进行调整。 该计划是让技术团队明确传达他们需要做什么。

让技术团队领导这部分，并向他们保证答案不一定是完美的。 如果他们需要离开并进行更多研究，他们可以在会议结束后进行。 但是这里的目标是完成画布的第一次迭代，以后可以更新。 完美是成功的敌人。

在我们的应用程序示例中，我们在产品版本 1 框中查看产品需求。基于这些要求，我们可以说技术计划 1 是“使用 Ionic 开发一个渐进式 Web 应用程序以启用跨平台应用程序。 使用设备的地理位置功能。 与 Firebase 后端同步。 使用 SendGrid 电子邮件服务。” 此处描述的技术计划和目标应该足以实现产品目标。 确保团队没有在不存在产品目标的情况下过度设计。

在这一步中，我们终于可以看到画布的力量——这就是我们调整团队的方式。 我们将产品目标与技术计划保持一致。 中间那条线呢？ 这就是接口，产品经理需要在团队之间积极管理。

同样，技术计划 2 将是“使用 Facebook/Google 授权实现用户身份验证，实现与 Firebase 数据库和聊天界面的实时聊天”。 技术计划 3 将是“为应用升级实施隐私/GPS 隐藏和应用内购买方法”。

该过程将要求您会议中的技术团队参与讨论。 您将有机会分享和讨论所有想法和见解，并且您将获得团队一致和支持。 在这里，团队各方面的人员将了解需要讨论的需求、优先事项和问题，并且您将在这里制定初步计划和协议。

至此，您拥有了与产品路线图相匹配的第一稿技术路线图。 关键技术任务以可视化流程布局，这将帮助您的团队了解应该关注什么以及何时关注。

第 5 步：识别风险和资源

最后，一旦从技术架构的角度决定了如何构建产品，讨论风险和资源是一个好主意。 在我们的示例中，我们可能会针对风险说：“渐进式 Web 应用程序可能不够快。” 如果是这样，我们可以转向 React 或 Native 应用程序开发。 对于资源，我们需要具备“Ionic、PWA、地理定位和 Firebase”技能的人员。

将这些项目包含在此处可确保这一单页摘要捕获讨论中出现的重要元素，并且在您稍后再次查看画布时会有所帮助。

全图

这是基于我们上面假设的应用程序示例的技术产品画布的完整示例：

不应该期望画布必须在第一次完成时就完全完成。 作为一个团队，您可能不同意与技术能力相比什么是产品功能以及在画布上放置什么。 画布的目的是发起和构建讨论，以便在会议结束时，您和整个团队对如何进行开发有更好的概念共识。

该文档现在是您的开发计划的核心。 这是高级开发路线图，技术团队现在可以根据业务目标制定更详细的开发任务。

结论：迭代您的技术产品画布

创建技术产品画布的五个步骤是：

1. 定义成功指标
2. 完成您的产品愿景和产品发布部分
3. 将技术愿景与产品愿景相匹配
4. 使技术计划与产品目标相匹配
5. 识别风险和资源

画布的一个非常重要的好处是它允许团队确定需要在每个阶段应用或开发的“最小”技术。 它可以帮助产品团队了解所需的技术工作和未来的任何挑战。 产品开发不会因为缺乏技术能力而放缓，因为技术计划是同步的，并且可以看到足够多的步骤。 在应用程序示例中，当我们接近发布版本 1 时，我们将对团队进行培训或寻找 SignalR 技术专家，以便为需要该技能的发布版本 2 做好准备。

您可以在此处下载技术产品画布。 我建议团队每季度进行一次审查，并且绝对是在每个版本完成时进行。 随意修改画布以更好地满足您的需求。 我真的很想听听您对如何改进技术产品画布的反馈。