技术层面
1. 如何在本地构建软件？
这是你应该了解的第一件事。毕竟，你的工作是开发和运行软件，构建是第一步！
2. 如何在本地测试软件？
虽然我们可以通过 CI 流水线发现测试错误，但是为了缩短内部开发循环周期，你必须能够在开发的机器上运行测试，确保你能够正确地运行测试，同时还需要执行回归测试。CI 流水线不应该成为检验代码错误的第一道关卡。
3. 如何设置开发环境？
也许团队文档中有明确的要求，但你应该了解需要在开发机器上安装哪些不同的工具，才能让你成为一名高效的团队成员。一次性解决95%的要求，总好过在开发的过程中不断遇到错误和依赖项。
4. 源代码在哪里？
除了还没有编写任何代码的新产品以外，通常项目都有代码库。你需要知道代码保存在何处，以及如何在本地机器上获取代码。
5. CI/CD 流水线在哪里，工作方式是什么？
对于一个可确保交付高质量产品的团队来说，CI/CD 流水线是最常用的工具之一。你需要找出CI/CD流水线在哪里，并大致了解它的工作方式（可能只需要到处点一点试试看）。查看一下最近的运行状况，了解都有哪些步骤。
6. 产品的待开发项在哪里？
你不仅需要知道软件当前的状况，而且还需要了解软件未来的样子。快速浏览待开发项，看看产品需要优先推出的功能。
7. 如何在预生产以及生产环境中运行测试？
有集成环境吗？团队是否采用了金丝雀构建与部署？团队是否采用了混乱测试？了解团队如何确保生产软件符合并保持特定的标准。
8. 是否需要随时待命？
这个软件是否需要随时待命？如果需要的话，轮班机制是什么？正常办公时间以外是否也需要随时待命？在待命期间，如何获取通知？通常如果不是遇到新组建的队伍，并被直接安排上值班任务的话，在熟悉这方面的流程之前，你不会接到紧急电话。
9. 内部文档在哪里？
团队维护的内部文档在哪里？这些文档都是如何划分的？是最新的吗？
合作
10. 团队中都有谁？负责哪方面的工作？
通常软件团队都有几位工程师。有的时候，每个工程师负责的工作都不一样，但这种情况并不常见。一般都由一个或几个工程师共同完成一个子项目。因此，你需要了解团队中每位程序员负责的工作。通常，你可以通过早晨的例会了解他们的工作内容。
11. 团队每周都有哪些例行会议？
每天早上都有例会吗？还是每周一次例行会议？你应该了解一下团队每周的例行会议。
12. 遇到“新手”问题，我应该找谁？
通常在刚加入一个团队的时候，都会给你分配一个“指导伙伴”，这个人已经在团队待了一段时间，了解团队的运作状况。这是一件非常重要的事情，尤其是你对新软件一无所知（或几乎一无所知）的时候，你的问题可以非常低级。即使你是高级工程师，在遇到“新手”问题时，也不要觉得不好意思。
13. 新功能的决定权在谁手里？
产品有产品经理吗？工程团队有架构师吗？我们应该了解功能请求的上游想法。如果能够跟这个人（产品经理）约个时间，了解一下产品近期与长期的发展计划就更好了。
14. 团队的主要沟通方式是什么？
他们使用 Slack ？还是Teams？或者通过电子邮件沟通？工程师通常会花费大量时间探讨问题和进行其他类型的讨论。当然，作为团队的新成员，你也希望加入这些沟通渠道。
外部因素
15. 如何获得客户的反馈？
我们的软件是 GitHub 上的开源软件吗？我们获取反馈的方式通过GitHub的议题吗？还是说由销售团队为产品团队获取客户的反馈？是否还有支持团队可以收集客户经常遇到的问题？换句话说，我们必须了解获取客户反馈的方式：无论是通过其他平台、个人还是团队。毕竟，我们是在为客户编写软件。
16. 客户的支持协议有哪些？
是否有我们必须遵守的 SLA？我们必须支持哪些协议？
17. 公开/客户文档在哪里？
这一点很重要。如今无论软件本身有多么好，我们都需要确保客户文档的准确性与及时性。这些文档在哪里？如何保持文件及时更新？是谁的责任？（希望答案是“每个人”）。
产品
18. 软件有哪些高层面的痛点？
我们必须知道软件和团队是否面临一些重大问题。是否有一些因架构引发的问题？是否存在安全漏洞？是否有一些常见的客户问题反复出现并需要解决？
19. 利益相关者关注的焦点是什么？
是否存在某个核心人物或其他团队希望看到的功能？这些利益相关者往往会对软件的短期和长期路线图产生重大影响。了解他们关注的焦点就可以让你看清接下来的发展方向。
20. 软件的发布周期是什么？
我们必须了解软件的发布频率以及时间。团队是否实施连续部署，每天都部署多次？还是说一年只有两次发布？了解软件的发布日程可以让你更好地掌握软件的开发节奏。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。