Effective project onboarding checklist
To avoid the onboarding slip and remove expectations and misunderstandings, the JetThoughts team defined a checklist of items to clarify. We will discuss how to start the project, but we won’t discuss the onboarding process.
We assume all the developers are familiar with the principles described in our article . The checklist should give information about the project and define some rules and conventions. Let’s take a closer look at each of those.
Define the helping person #
This item will be helpful if the project already exists and your team joins it. The helping person (or buddy) should be responsible for introducing the newcomers to the rest of the team. This will start onboarding and help the new employee join the development environment. Also, the direct introduction to the team members allows the newcomer to participate in all discussions and contact team members directly.
Buddy could arrange a project tour and serve as a resource for any of the newcomers’ questions. He’ll help solve problems or advise on how to proceed with tasks, deal with complications, answer any questions, address any difficulties, etc.
The accounts set up #
The new member should get access to all services used during development and the whole work. For example:
Financial tools: setup in accounting and time tracking service (create the project and add the team member)
Project repository
Collaboration tools
External testing services
Performance services
Errors tracking
And so on.
The project canvas #
This information should explain the project’s purpose and what it does. Define long-term and short-term goals — that is important. It’s also recommended to have screencasts showing the features of the application.
With that information, the developer understands the client’s expectations and the application’s functional side.
Definition of the development process #
Before running the development process, both the client’s and the developer’s sides should clarify and agree on it.
We define such questions:
Which channel(s) is used to share the finished job with a client?
How and who creates task lists and assigns tasks?
How do you ask for the task verification?
What defines the “completed” job?
What are the code review requirements?
Is writing daily standups necessary?
When does sprint planning take place?
How and when do retrospectives take place?
‘Who does what?’ questions: #
Before running the development process, it should be clarified and agreed upon by both the client and developer. So it’s essential to know the role of everyone working on the project:
Who is responsible for code quality?
Who writes tests and/or deals with support?
What is the stakeholders’ role in the project? How deeply are they involved in development?
Who maintains technical documentation and supports the product?
Who is in charge of architectural decisions?
How and who creates task lists and assigns tasks?
Who manages the development process, deals with requirements, business analyses, etc.?
Who communicates with customers/product users?
The answers to these questions help to avoid misunderstanding and build trust between both sides.
Set availability per person #
When work is going to be asynchronous, it is desirable to have information about the availability of the team members responsible for critical tasks. This helps prevent knocking on the closed door and plan the whole process thoroughly.
Also, the process of communication should be clarified and agreed upon. For example, the items that could be included:
The frequency of meetings.
Tools for communication.
Availability for meetings.
Regular text standups (e.g., they may contain goals for the day or progress reports).
And so on.
Guide about infrastructure and architecture of the project #
Another useful information is a guide about the project’s components. It could be information about existence and interaction with:
Continuous Integration
Continuous Delivery
Servers URL
Guides for UI
Guides and conventions for Code
Technical Debts and Long-term Refactoring in progress
The first tasks for the onboarding #
It is essential to lay the foundation for trust from the beginning. Determining the first week/sprint goals helps clarify expectations and diminish misunderstandings.
To start, it is better to define tasks related to the setup process, test fixing, or functions that don’t touch many other components. This facilitates the onboarding process.
For the first time, it is better to start with simple, small, and precise tasks and then go to more complicated tasks step by step.
Conclusion #
This list can be modified during the process and adapted to specific requirements. However, at the beginning of cooperation, it could help to lay a solid foundation of friendly and professional relations and find the understanding between the customer and performer.
Sergey Sviridov is a Software Engineer at JetThoughts . Follow him on LinkedIn or GitHub .