无论是向新人介绍项目，又或者是上到一个新的项目，我们都需要事无巨细地列出一个个的关注点。既然如此，那么为什么创建一个检查清单，用来帮助我们一个个的检查一遍呢。

在过去的日子里，经历了几个不同的项目，每个项目都有自己特有的特色。它们往往也包含了一些不同的背景，在成功的交付项目之后，有的还要解决技术难题，有的要的是解决业务难题，有的复杂的部分在于跨团队的协作。正是因为这些情况，也导致了在不同的时候，我们需要着重考虑这些不同的因素，上一个业务复杂的项目，需要重点关注业务问题；来到一个项目团队结构复杂的项目，则重点解决团队复杂问题。

可是呢，对于每个项目来说，它们都存在一些相似的共同点。而这些共同点，即是我们开始一个新项目要做的，也是我们来到一个新的项目时，所需要了解的。于是，当我看到一篇 Tech Lead 的新项目检查清单时，我也想写一个面向开发人员的新项目检查清单。

清单设计

在那篇《项目初期的最优技术实践》中，我总结了项目的三步曲：技术准备期、业务回补期、成长优化期。而后在那篇《迈向 Tech Lead 之路》里，我将 Tech Lead 要做的事情，结合到了三步曲中。

为此，我们将一个 Tech Lead 要做事情分为了三个部分，即：Process、People、Programming。 这一点对于新项目的检查清单来说，也有些类似。稍有不同的是，我们需要在其中加入关于业务的维度。此此，我们可以划分为四个维度：

• Process，关注于从权限管理、获取代码、部署上线、代码集成等的流程。
• People，连接利益相关者、第三方合作伙伴（组织外）、协作团队（组织内）、团队成员等相关的人。
• Tech，包含了技术远景、文档（文档即代码）、项目代码、技术栈、软件库管理等。
• Business，涵盖了业务远景、业务需求、跨功能需求等业务相关功能的需求。

作为检查清单的第一个版本，它的维度设计可能并非那么完善。但是随着时间的改进，我们可以一起把它变得更好。

新项目检查清单

Tech

0. 技术远景

说明：在技术上，我们有什么追求？

1. 文档 - Path to Production - 上线及发布日记 - 项目相关的 wiki 和文档记录

说明：文档即代码——好的文档应该是版本管理的。

2. 架构 - 系统相关的架构图，如 C4Model 方式描述 - 现有的技术栈及其关系

3. 代码库 - 搭建指南。 - 架构决策记录。放置在代码库的 docs/adr 目录中。 - 编辑器配置和代码风格规范。 - 模式和风格指南。 - 分支管理模式。GitFlow 或者 master，或者 Feature Branch。 - 代码提交风格。

4. 测试 - 测试层级。 - 测试策略。

5. 项目演进 - 未来的技术栈 - 系统的演进方案

6. 安全 - 安全标准。安全更重要，还是体验更重要？ - 代码中的数据加密。 - 代码安全。

Process

0. Project Process

• 项目的 Roadmap？时间长短，上线时间等。
• 项目功能的生命周期。如敏捷中的故事卡工作流
• 沟通方式？如 IM，邮件，还有敏捷的每日站会，远程会议，Retro 等

1. Path to Development

• 开发机申请及网络等权限准备
• 代码库权限管理
• 编辑器和相关的工具申请

说明：不同的的组织包含自身特别的情况，如 PC 端口、网络权限、代码库权限等的开通都需要一定的流程。

2. Path to Production

• 上线每一步的流程
• 相关的关键人
• 每一步所需要的工具
• 每一步所需要的流程。如 QA 测试流程，上线流程

说明：代码中的 Path to Production 只是一份说明——针对于开发人员的，而这里的则需要一个更详细的说明。

3. Path to Roll Off

说明：换一个项目时，需要哪些东西？

People

1. 团队成员

• 非技术问题找谁？
• 团队成员的技术栈及水平
• 每个人的技术水平，应该怎么带：Coach（教练式）, Pairing（结对式）, Teach（教学式）
• 项目无关的技术，可以找谁一起“娱乐”？
• 1 to 1 Meetings

2. 利益相关者

• 了解各个相关者（Level 1）。如作为一个开发人员，大部分时间并不会和利益相关者有直接的沟通。
• 和相关者保持沟通（Level 2）。适当沟通，可以帮助项目更好地进行。

3. 跨团队协作

• 相关的合作方有哪些，各自的接口人是谁？
• 同组织、项目下的其它团队。

4. 用户

• 用户是谁？我们是否与他们直接接触？
• 反馈环。一个用户的反馈是如何变成需求的？

Business

0. 业务远景

说明：我们在做什么，我们要去哪里？

1. 业务需求

• 有没有接近全的需求列表。在一定的时间（如迭代内），需求应该是稳定的。
• 需求是如何从口头到待办列表的？中间是不是存在不规范的问题
• 业务是如何进行变更的？

2. 跨功能需求

• 运行质量。在系统运作时观察到的质量，例如保安性及易用性等
• 演进质量。软件系统结构及开发过程有关的质量，例如软件可测试性、可维护性、可扩展性、可伸缩性（scalability）等

在线工具

为了方便我未来在新项目使用它，我创建了一个项目来更新这个清单：https://github.com/phodal/new-project-checklist

与此同时，创建了一个 Web 应用来检测。

结论

如果我们的清单不是那么完善，那么作为一个 Tech Lead 又或者是一个额外的关键角色，我们应该完善相关的部分。

未来，我们是否还会有这样的工具，来帮助我们更好地做相关的工具呢？