欢迎加入团队！如果你像本书的大多数读者一样，你可能是一名前端或后端开发人员，但你希望成为一名高级全栈开发人员。现在，想象一下，你的职业生涯已经进入到那个阶段：你是一个新的高级全栈JavaScript开发人员。这意味着你负责推动项目的技术方向，并协调不同团队的工作，以将软件交付给用户。你的任务是启动一个绿色田野应用程序，一个你从零开始构建的项目，没有现有代码，基于设计和与多个团队的对话。
让我们分解一下你将在本章中学到的内容：
- 如何与其他多个团队合作，充分定义功能
- 如何将设计拆解成小的、可执行的任务
- 如何确定你需要处理的数据
你将构建的项目
你将在本书的学习过程中构建的项目是一个电子商务平台，它可以访问大量的用户数据，包括一些个人身份信息（PII），并与多个第三方服务连接。你和你的团队的任务是创建一个用户仪表板，使得客户可以进行购买，查看他们的订单历史及其他操作记录，并与他们的数字购买（如电子书）进行互动。他们还将能够根据自己在应用中的权限采取不同的操作。
你将从一个全新的产品团队和设计团队开始合作，共同将这个仪表板变为现实。产品团队负责与不同的利益相关者沟通，决定应构建哪些功能。设计团队则负责为这些功能设计UI，并进行第一次用户体验的尝试。
项目的第一部分可能涉及产品和设计团队紧密合作，为你制作一些模拟屏幕和行为文档。这些模拟屏幕将在项目启动会议中展示给你，并进行讨论。
项目启动会议
启动会议通常由产品团队展示设计团队制作的模拟屏幕。很可能这些模拟屏幕在开发过程中会发生变化，但它们应该已经完成了约80%的工作。产品团队会带你了解用户流程，展示用户如何与应用互动，并告诉你所需的数据。在项目的这一阶段，尽量舒适地提出大量问题。通常，当你开始从技术角度审视设计时，你会想到一些产品或设计团队没有考虑到的事情。
提示
确保在这个初始会议中做一些自我介绍，让每个人都知道自己在和谁合作。虽然很容易直接进入工作，但请记住，认识你的同事同样重要。
记住，整个过程是高度协作的。早期并经常提出问题，将有助于项目顺利推进。现在，产品团队告诉你，尽管功能会随着时间的推移而扩展，但目前只需要为概念验证构建两个屏幕。让我们来看看这些屏幕并了解用户流程。
这些截图来自一个常用的设计工具Figma。通常会有一个设计，它以视觉方式描述应用程序的流程。在工程实现过程中，你将专注于一次查看其中一个视图，例如图1-1中的用户信息屏幕。
图1-2显示了一个屏幕，用户可以在其中查看他们的信息，例如订单、推荐的产品和其他细节。这也是用户编辑信息的地方，例如他们的地址，并且可以在这里取消订单并查看他们的数字购买。
图1-3中的设计展示了这些视图在移动设备上的显示方式。大多数与外部用户互动的项目都会有移动端设计。如果你没有看到这些设计，确保向相关人员询问！
许多设计师在创建应用程序或特定功能的模拟图时使用Figma。你可能还会遇到一些其他工具，如InVision（现在是Miro）或更新的替代品Penpot。Figma设计中还包含了HTML和CSS，因此当开发人员在页面上排列元素时，它们对于检查尺寸非常有用。尽管CSS在设计中有，但并不总是完全准确。你可以将它们作为起点，但要确保修改样式以满足要求。
当你看到这些模拟设计时，产品和设计团队已经开了几次会议，尽量敲定所有细节。那并不意味着他们已经把所有事情都搞定了，这正是你需要介入的地方。基于这些设计和用户如何与应用互动的解释，你需要与团队一起决定你们要采取的技术方法。
让我们按照你与产品团队的方式来逐步浏览这些设计。在第一个屏幕（图1-1）上，有：
- 页面侧边的导航栏，带有指向应用程序其他区域的链接
- 页面顶部的搜索栏，用于帮助查找产品
- 一个精选产品部分，显示用户最近的订单
- 一个可排序的、分页的表格，包含多个列，展示所有用户的订单
第二个屏幕（图1-2）上的几个部分有用户可以互动的字段。用户可以切换一些设置，更新字段，并根据他们的购买进行操作。这个屏幕比第一个屏幕复杂，所以你需要花时间与团队一起详细浏览它。产品和设计团队通常会向你这个高级开发人员寻求最终的技术决策。
注意 无论如何被推动，都不要在没有先与团队讨论的情况下做出承诺。产品团队可能会把你拉进会议，试图了解实现他们想法的复杂程度。这可能会导致他们期待一个快速的时间表承诺，作为一个更高级的开发人员，你需要适应这种情况。你必须坚决表示，在与你的团队讨论之前，你无法给出准确的估算。其他开发人员能够提出你可能没有意识到的顾虑，而且他们最终也会参与这个功能的开发。坚持自己的立场，如果产品团队继续要求确定日期，简单地拒绝承诺。这样，你就不会是把团队推入紧迫期限的人。
有了这些设计和一些文档，描述屏幕应如何工作的细节后，接下来是你需要理解业务逻辑的时刻。深入理解设计背后的业务决策，对于向其他开发人员解释这些设计非常有帮助。
在浏览这些信息时，你需要基于现有的设计考虑几个方面。
设计考虑因素
在这个阶段，你会发现自己提出很多问题，这是完全正常的。现在正是深入细节并精确琢磨的时机。提高在技术上评估设计的经验的一种方法是接触不同的设计集。例如，你正在合作的设计团队很可能正在为组织中的其他应用进行设计工作。
如果你对下拉功能的行为有疑问，可以问是否有其他设计可以作为参考。通常是有的，你应该花时间彻底理解它们是如何工作的。很多最好的问题都来自于对不同实现的经验。另一种获得不同设计经验的方法是开始仔细关注你使用的应用程序。你是否真的考虑过你的银行应用程序或健身或冥想应用的用户流程？这些都是你可以用来做对比的现有产品设计示例。
提示
找到时间进行探索性工作可能有些棘手。一种方法是通过编写一个任务单，详细说明你将要研究的内容、你迄今为止对这个问题的想法以及一些开放的问题。你也可以在任务单上加上点数，使其更加正式。
考虑一下其他产品的设计以及当你将其拆解为细节时，界面的表现。思考其中的差异时，记下它们带来的问题。
警告
当你编制问题清单时，提醒一句：在你想到一个问题时，先浏览一下你收到的文档。有时答案已经在其中，先阅读文档能为大家节省时间。花一个小时浏览团队为其他项目准备的任何工程文档。还要阅读有关正在使用的第三方服务的文档，以及你考虑使用的任何软件包的文档。
你可能在想，哪些问题是比较好的问题。这通常取决于设计和业务逻辑。
以下是一些可以帮助你开始的问题，针对这个示例项目中的屏幕：
- 是否需要考虑其他语言的翻译？
- 应用程序中需要使用哪些品牌指南，例如颜色、字体和响应式尺寸？
- 用户查看其信息需要什么权限？
- 用户在应用中执行操作需要什么权限？
- 会有多少种不同类型的用户？
- 我们期望用户活跃多长时间，以便确定访问令牌的有效期？
- 我们预计需要处理哪些用户数据？
- 我们是否想显示不同时间范围的数据？
- 表格是否应该按每一列排序，还是仅按特定列排序？
- 我们如何知道哪些订单应该被推荐？
- 输入字段接受哪些类型的数据？
- 用户保存更改时，应该显示什么？
- 如果客户端发生API错误，用户应该看到什么或能做什么？
- 用户在进行敏感操作（如更改个人身份信息）之前，是否需要输入更多凭证？
- 输入错误应该在字段内联显示，还是在提交按钮旁显示？
- 我们是否需要考虑平板设备和其他移动设备？
- 这个应用的后台是否会被其他应用使用？
- 前端是否需要集成到其他应用中？
- 这个应用是否受到任何合规性或法规的约束，或者是否会接受审计？
你可以看到，这个问题清单可能会非常长，我相信你也想到了一些其他问题。不要担心，如果清单很长也没关系。一次性解决所有这些问题可能很难，所以你应该根据功能优先处理这个清单。最好在一开始就问尽可能多的问题，而不是等到接近截止日期时再提。如果有些小问题，你可以凭借经验做出判断，比如表单处理方面。
这些问题可能杂乱无章，但产品或设计团队应该能够回答它们。虽然这些问题目前还没有涉及到技术，但它们的答案将推动技术决策。尽早获得这些问题的答案正是为什么高级开发人员往往能深入理解业务逻辑。
为了做出最佳的技术决策，你必须理解应用功能的目的以及它如何融入整体业务。这可以为你提供一些前瞻性思维，帮助你以最具可维护性的方式构建应用，因为你可以看到业务的发展方向。一些前瞻性思维将来自于你所知道的即将处理的数据。
数据驱动设计
数据驱动设计。所有设计的核心都围绕着如何最好地传递数据并让用户与之互动。例如，考虑表格屏幕。数据不一定非得以表格的形式展示，它也可以是一个可折叠的列表或图表。这就是为什么你需要深入了解业务逻辑以及你将要处理的数据的原因之一。这也是前端开发通常依赖于后端开发的原因之一。我们将在第二章中进一步讨论这一点。
在浏览设计时，记录每个屏幕所需的数据是个好主意。在设置屏幕上，你可以看到你需要用户的姓名、配送地址和语言偏好等数据。记下这些数据可能的变量名称和数据类型，并与团队分享你觉得可以的部分。这有助于启动关于如何推进项目的初步讨论。
还要与产品团队确认这些值是否正确，以及应用程序所期望的是什么。始终与产品团队核对，确保你拥有正确的数据和数据之间的关系。他们可能不会用技术术语来解释，但他们会带你了解不同的场景，帮助你描绘出整体的图景。
这就像是项目的开发团队的发现阶段。一旦你浏览了设计并记录了你的问题和笔记，准备好开始讨论具体功能。
将设计拆解为任务
你已经完成了项目的第一轮精炼！在下一轮中，你可以假设产品团队已经回答了你们团队的所有问题，并且你已经更新了设计。现在，你将与产品团队一起从这些信息中划分出功能。这个阶段，你将首次使用任务管理系统，如Jira、Trello、ClickUp或Shortcut。图1-4是Trello中的任务管理系统示例。
你在这里创建的任务票会在你开始引入更多开发人员和其他团队时经过进一步的细化。在这个阶段的目标是为设计中的各个部分创建行动项。例如，用户信息屏幕有几个可以拆解为功能的部分，如精选部分和表格。你是想让大家开始思考这些设计如何实际工作，并且你将开始引入技术角度。
你可以尝试根据数据关系将功能分组。这将有助于在构建前端时更容易进行后端的更改和部署。这也是一个阶段，当你开始思考技术栈时，你仍然可以指出遇到的任何大问题。每当你有一个功能或技术需求的想法时，确保创建一个任务票。如果没有任务票，工作就不会被优先处理。
从功能需求中细化任务
你现在处于项目的一个阶段，产品团队应该已经为你编写了一些用户故事，供你根据技术细节进行细化。这些用户故事是你收到的文档的一部分，定义了你正在开发的功能。它们通常是从用户的角度编写的，给你提供一些用户如何与功能互动的隐藏上下文。然而，这并不是每次都会发生。通常，你会与产品团队一起完全定义功能，但他们通常会从上轮会议中提供一些细节，以便开始。
你可以假设你的团队遵循一个正常的敏捷流程，包含两周的冲刺和标准的会议，如每日站立会议、待办事项梳理、冲刺计划会议和回顾会议。此时，开始在待办事项梳理会议中浏览Jira待办事项中的任务票。这个会议应该包括开发、质量保证（QA）、设计和产品团队，以便每个人可以提出或回答问题，并提出问题和担忧。功能任务票应该被拆解成开发人员可以完成的最小工作单元。
这是你需要使用艺术与科学相结合的时刻之一。“最小”单元可能意味着创建一个任务票来编写端点，并列出所有相关任务，还可能有一个单独的任务票来触发事件。可以从QA测试的角度来考虑。什么样的工作组合最适合一起测试？关于敏捷和这类项目决策，已经写了大量的书籍和资源。你可以查看一些关于敏捷的Atlassian文章。
为了保持团队能够输出的期望一致，通常会对每个任务票进行估算，以评估任务的复杂性。当你在待办事项梳理时浏览任务票时，不要犹豫放慢节奏。如果你把所有时间都花在一个任务票上，这会向产品团队展示他们需要改进的地方，这可以在回顾会议中提出来。
确保每个任务票有产品团队、QA团队和你的团队共同商定的验收标准。如果任务票中包含UI元素，确保你能访问桌面和移动端的设计。每个任务票还应包含背景信息，说明功能如何适应整个应用程序，以便开发人员有上下文。所有开发人员应该对每个任务票的估算达成一致。
这看起来可能是过于关注任务票，但做这些工作前期准备会节省团队的时间。一开始让每个人达成一致，有助于避免团队受到阻碍。对于每个任务票有这种程度的文档，就不应该有太多的任务不明确的问题。以下是你会在一个定义清晰的任务票中找到的信息示例：
标题： [后端, QA] 为用户信息屏幕上的表格数据创建端点
描述： 作为用户，我需要查看包含我的购买信息的表格。此信息应包括每行表格中的产品名称、价格、预计到货日期和数量。该表格还应能够通过点击列标题进行排序。应具有分页功能，以便我可以浏览过去12个月的购买历史。表格应与附带的设计一致。（参见图1-1。）
验收标准：
- 更新数据模式，以包括购买历史定义：产品名称、价格、预计到货日期和数量。
- 在数据库上运行迁移。
- 创建端点，响应过去12个月的用户购买历史。
- 确保身份验证正常工作。
- 实现请求数据的验证。
- 为新端点编写测试。
- 编写文档，说明端点的工作原理，以便前端使用。
点数： 5
任务票应该非常清晰地告诉任何工程师需要做什么，尽管票据本身不应告诉他们如何实现。这是团队讨论后可以决定的事情。像这样编写的任务票将激发更深入的技术讨论，有助于推动项目的整体架构。
这时，你开始从产品团队接手任务，并作为开发团队进一步细化这些任务。将团队会议中得出的重点包括在任务票中总是一个好主意，这样每个人都能记得为什么要以某种方式做事。你可能会发现，你的某个第三方服务只接受某种格式的数据，这导致你需要编写一些工具函数。但由于产品需求，你绝对必须这样做。这将是代码审查和测试中的重要上下文。
看起来这个过程可能很长，但通常你可以在几天内为即将到来的冲刺定义任务票。然后，一旦冲刺开始，你就可以开始工作了。但是，在你选择自己的任务并开始编码之前，你还需要进行一些对话。
与产品和其他团队讨论时间表
此时，在项目中，你可以假设你有了明确的任务票，并且细节已经尽可能被梳理清楚。现在是时候进行一次更高层次的讨论了。所有任务票估算完毕后，产品团队将准备好设定发布日期。
注意
有时，产品团队会在你还没有机会估算任务票之前就给出发布日期。如果你发现他们的时间表比工程团队所需的时间更短，无法充分完成任务票的工作，要求推迟。时间紧迫时，务必表达出来，这能帮助大家避免不必要的压力。
这次讨论不仅仅涉及你的团队。你可能需要与其他项目的开发人员、DevOps团队、支持团队和QA团队协调。具体情况取决于你所做更改的影响范围。在没有与这些团队沟通之前，别急着承诺发布日期。你需要看看你的目标与他们的目标如何匹配，以及你能做什么让他们的工作更轻松。
与其他开发团队沟通
你的项目可能依赖于另一个团队在他们的代码中实现某个功能，你的应用程序需要使用。你需要提前向他们提供充分的通知和细节，以便他们将其纳入他们的冲刺中。开发团队并不总是意识到一个应用的功能发布可能会影响到他们的应用。和他们讨论你需要什么，并尽量简化说明。告诉他们你的目标发布日期，并看看他们是否能帮助你实现。
另一方面，你应用中的新功能可能会对其他团队造成破坏性变化，你需要让他们知道需要进行哪些更新以及完成的时间。不要犹豫，主动联系你认为会受到影响的任何团队，确认一下。随着你了解哪些团队受到影响，更新团队文档，标明他们是你的应用的使用者。
在与你的团队沟通之前，你需要准备好以下几项：
- 明确的技术需求
给他们一个任务，确保它和你团队执行的任务一样明确。如果他们需要更多信息，给他们提问的机会。 - 需要更改的代码位置的概括
你不必进入他们的代码中实现这些更改，但有一个大致的起点是很有帮助的。 - 请求更改的背景
一个对你来说看似微小的更改，可能会改变他们应用中某个重要功能的运作。确保他们理解为什么需要这个更改。 - 截止日期
当然，你会问他们完成这项工作的时间，但心里要有一个灵活的日期。 - 执行工作的意愿
如果由你来实现更改，并且让团队审查会更快，也要保持开放态度。
当你知道所有开发团队成员达成一致时，你就可以开始与下一组人讨论了。这些讨论不必按顺序进行，但必须要进行。谁先有空就可以先进行讨论。
与DevOps协调
当准备将应用发布到不同环境时，你需要与DevOps团队进行沟通。假设有一个DevOps团队。在一些较小的公司，你可能还需要负责处理部署。本书假设你在至少有一名DevOps工程师的团队中工作，他们为你处理基础设施和管道更改。
由于这是一个全新的应用，你需要为QA设置好测试环境、生产环境和其他环境。你可能能帮助设置持续集成和持续部署（CI/CD）管道，使用工具如CircleCI、Jenkins或GitHub Actions，但当涉及到资源配置和处理基础设施问题时，那将完全由DevOps团队负责。
DevOps团队将提供重要信息，如应用托管的云提供商。你将向他们提供重要的信息，如使用的编程语言和框架。新项目的目标是，两个团队都能在准备生产发布之前，至少有一些环境可以用于测试。尽早让DevOps参与进来，将使开发过程更加顺利。
记住，你与之互动的所有团队已经有了各自的优先事项。所以，你必须考虑到他们可能不会立刻处理你的请求。这就是为什么在你有了技术方向后，尽早与DevOps协调非常重要。你最不希望的情况是，在重要截止日期前将DevOps置于紧迫状态。准备好随时与他们通话，讨论项目，以便他们理解该应用的性能和使用预期。在通话中，你需要覆盖几个方面：
- 开发应急预案——你们为解决生产环境中的故障和其他问题而制定的策略和步骤
当出现问题时，确定最佳的解决步骤可能会很困难。这就是你和DevOps需要提前考虑这些问题的原因。 - 确定应用程序所需的环境数量
一些项目可能有三个环境，而其他项目则可能为每个Git分支都有一个环境。找到一个适合的环境数量，既能在基础设施方面保持可维护性，又能灵活用于测试和其他用途。 - 找出最佳的部署策略
对DevOps来说，了解何时需要触发脚本执行以及它们执行的频率非常重要。有些部分将是自动化的，其他部分需要手动执行。最佳策略是既适合你们团队，也适合DevOps团队。 - 决定如何处理CI/CD的维护
大多数CI/CD工具使用YAML文件来定义管道的配置，这些配置文件通常存储在项目的仓库中。有时由开发人员进行更改，有时由DevOps进行更改，或者两者都能进行更改。无论如何，要确保大家在同一页面。 - 确定支持的JavaScript运行时版本，如Node、Deno或Bun
服务器并不总是运行最新版本的运行时，这可能导致应用出现奇怪的bug。了解你的项目能兼容的最旧版本运行时，以防万一。 - 查明凭证的轮换时间
一些应用依赖于基础设施中维护的密钥和秘密，例如npm令牌。在待办事项中添加提醒任务，以便在凭证过期并导致生产问题之前，更新它们。 - 选择存储资产的位置
对于一些应用，这将是云提供商的一部分，而对于其他应用，则会使用第三方服务。即使你现在无法给出绝对的答案，也可以创建另一个任务，以便以后再来处理这个问题。 - 在部署前安排时间一起测试应用
你知道应用应该如何运行，所以DevOps会依赖你来处理一些环境测试。他们通常能够让应用运行起来，但你需要验证它是否处于正确的状态。 - 为初始应用部署后留出一些时间
在第一次部署后，总是会有一些问题需要修复。提前把这个会议安排好。如果没有问题发生，那就为大家预留了庆祝的时间。
在与你的DevOps团队沟通时，需要记住的一件事是，并不是所有的内容你都需要完全理解。随着你与他们的合作，你会开始了解更多。如果你不想深入了解DevOps的世界，那也没问题。接下来，他们会处理自己那一边的所有事务。
现在，你需要与QA团队进行沟通。
与QA团队合作
虽然开发人员，特别是高级开发人员，应该彻底检查他们的工作，但有时还是会有bug漏网。这就是QA团队存在的原因：确保这些bug不会进入生产环境。奇怪的集成问题发生了，拉取请求（PR）覆盖了功能，边缘情况被发现，许多其他问题也会导致开发人员未能捕捉到的bug。及时将新功能和bug修复交给QA进行测试对于按时发布非常重要。你需要将新的代码交给他们，给他们时间进行测试并反馈缺陷，然后留出时间修复这些缺陷并将代码发送回QA。
注意
有可能你根本不会与QA团队合作，这实际上取决于公司。在一些早期的初创公司中，你可能没有专门的QA团队。可能只有你和其他开发人员，甚至可能是CEO。在其他公司中，你可能会看到产品团队手动进行一些功能的QA测试。无论是否有QA团队，你都可以使用本节中的步骤来帮助自己更彻底地进行QA。
你看，这个循环可能需要一些时间。为了缩短这个时间并确保最高优先级的任务首先被测试，尽量在开发过程中将QA团队包括进来。他们会有关于功能和bug的测试问题，这些问题需要被理解。他们编写的所有测试用例基本上就像是应用程序的历史记录。许多功能都会有测试覆盖，无论是自动化的还是手动的。这些测试即使在功能不存在时也会存在，因此QA以与其他团队不同的方式记录更改。
安排一次QA团队和开发团队之间的电话会议，确保你们已经讨论了以下内容：
- 自动化集成测试
这是通常由QA负责的任务，但由于这些测试通常存储在项目的仓库中，开发人员也可以编写这些测试。同时，要区分集成测试和单元测试。开发人员应该始终编写单元测试。 - 重现步骤的详细程度
这里有一个平衡，既不能过于简略，也不能过于详细。讨论哪些细节对于开发人员和QA工程师来说最好，这样大家都知道应该期望什么。你最终会和QA工程师一起深入解决问题，但有一个起点会更有帮助。 - 将QA包括在相关会议中，如待办事项梳理和站立会议
这能确保QA跟进即将到来的截止日期、优先级变化或发布情况，并且他们可以在遇到问题时提供更新。尽量在这些会议的开始部分安排更新，例如他们可以测试的任务票，这样他们就能更好地利用时间。 - 明确QA应该感到舒适地联系负责测试任务票的开发人员
开发人员应该愿意与QA配对，帮助他们确定问题是bug还是其他问题，比如环境差异。
QA是大家的好朋友，因为他们能找到很多如果没有被发现会在生产环境中造成问题的bug。当生产环境出现问题时，对任何人都没有好处。QA不是为了告诉开发人员他们错了或代码不好，他们只是想确保没有任何问题导致我们不得不启动生产应急预案。对他们报告缺陷时要保持耐心，因为他们只是在做好自己的工作。
一旦你准备好部署更改，你将与多个团队互动；这会真正依赖于公司。你可能会与销售团队合作，帮助他们了解产品的功能，以便他们为客户设定现实的期望。
还有集成或客户成功团队。这些团队通常与客户一对一合作，帮助他们将产品集成到他们的系统中。他们必须了解任何破坏性变化或新功能。
一些公司还设有专门的安全团队，特别是如果产品涉及金融科技、医疗保健、电子商务或制造业的话。这个团队可能会在QA之后介入进行安全测试，并且在整个开发管道中可能还会进行持续的安全扫描。
有一个团队无论如何都会参与，那就是支持团队。这是你需要与之沟通的下一个，也是最后一个团队。
与支持团队的规划
支持团队是直接与遇到问题的用户接触的人。你将修复的一些错误，可能直接来自支持团队。他们甚至可能将他们的支持票链接到你的错误票上，以便让用户保持更新。支持团队也是新功能的灵感来源。如果他们从不同用户那里收到相同的请求，值得考虑是否需要为此提供解决方案。
支持团队的工作很困难，因为他们需要处理不满的客户。你希望这种情况尽量少发生。当你和支持团队讨论即将发布的功能时，他们需要了解这些变化如何影响用户。产品团队应该已经和他们讨论了时间表。你需要了解他们从开发团队那里需要什么。
请记住，支持团队的成员通常没有很强的技术背景。他们理解应用程序如何从用户的角度以及作为管理员运作，但他们不一定理解技术细节。了解他们的背景将极大地帮助你沟通。你与支持团队的工作是将技术细节转化为他们需要的信息。
以下是一些你可以做的事情，以帮助支持团队：
- 提供文档：支持团队可以参考用于使用某个功能的文档。
- 描述与现有功能的变化：突出用户需要输入的值，因为用户输入通常是他们收到问题的原因。
- 倾听支持团队提出的投诉：接受他们从错误或其他请求中给出的反馈，并与产品团队合作，优先处理这些反馈。这并不意味着你要实施支持团队要求的所有内容，但这意味着你要做一些研究，了解他们为何提出这些要求，以及解决这些问题有多难。
- 同步发布日期和时间：支持团队有时会在发布前特意安排一些时间，因为会有更多的用户问题。他们需要确切了解变更的发布时间，以便不被突如其来的问题增加所打扰。
- 在发布前做功能演示：在变更批准发布后，做一个简短的现场演示给支持团队（以及其他团队成员）。这样，他们就能看到应用程序应该如何工作，并提出任何问题。
- 在发布前后给支持团队提供额外的开发时间：如果支持团队因为问题处理不过来而陷入困境，你可能需要回滚这些更改。只要你做好准备，密切关注他们的反馈。
与支持团队讨论这些事项是提早解决问题的另一种方式。这也是建立工程团队与支持团队关系的好方法，因为你们的合作比看起来的要紧密。这是你需要协调的最后一个团队了。现在是时候将所有的发现和笔记汇总起来，制定一个连贯的计划。
结论
你已经完成了项目启动的最后一步。你已经从不同团队的会议中获取了笔记，现在是时候将这些信息提炼出来，并将亮点汇报给产品团队了。所有这些讨论将帮助你制定一个合理的截止日期。
这时，一些谈判将开始。记住，设定截止日期时要考虑到开发过程中可能会出现的问题。给自己和团队留些余地，可能会提前交付。记住，低估承诺，超额交付。除非你需要实施的功能是时间敏感的，比如第三方服务的更新，否则可以为自己留出几天时间，以应对突发状况。在和产品团队确定日期后，考虑到其他团队的所有关切，召集所有人进行一次最终的简短电话会议。
注意
在软件开发中设定截止日期是非常棘手的。任何时候都可能发生意外，打乱整个进程。如果有人生病，或者自然灾害导致某人停电一周，一些任务可能无法完成。你可能会深入开发，发现你正在尝试集成的工具比你预想的要复杂。你也可能在等待另一开发团队的工作，但他们落后了进度，这也会导致你们的工作延迟。
这一切都没关系。你能做的最好的事情就是一旦发现问题，就立即与所有人沟通。然后你就可以开始制定下一步计划。生活中总会发生这些事，你必须尽力不让这些事情每次都给你带来压力——因为它们会经常发生！
这个电话会议将会有你与各团队沟通过的人参加。此时你需要确认的只是每个人的行动项和截止日期。召开这个电话会议的目的是建立责任感，并三重确认大家是否达成一致。作为这次会议的准备工作，将所有这些信息从笔记中提取出来，做一个简短的文档，供大家在发布前参考。
到此为止，你已经有了许多明确的任务，并且这些任务已经定义清楚。你已经记录了跨团队的连接。项目启动已完成，你拥有了所有需要的信息，终于可以开始编写代码了。在本书的下一部分，你将使用NestJS框架在TypeScript中构建一个可扩展的后端。
