108 things to do first when contract development starts

Tadashi Shigeoka ·  Mon, November 27, 2017

I’ve listed things to do first when contract development starts, so I’d like to introduce them. (Updates planned as needed)

受託開発

Set up various tools or get access permissions

When taking over development of an existing service, there should already be a version control system and communication tools, so let’s get access permissions for those.

If there are missing tools, let’s introduce them first.

Version Control System (VCS)

Not having a VCS is seriously problematic, so let’s set up GitHub or Bitbucket and use them.

Since you need to do the initial setup from scratch, I recommend doing these on the same day:

  • git init
  • Add .gitignore

Adding .gitignore files can be easily generated with gitignore.io, which is convenient.

Task Management Tools

Choose tools that fit the project, such as Trello, Asana, or Google Spreadsheets.

For those who don’t like dispersed tools, there’s also the option of using GitHub’s Milestones or Project boards instead of these tools.

Communication Tools

Get invited to the client's communication tools, or introduce new ones for the contract development project.

When adopting new communication tools, options would be Slack, Discord, etc.

Things to decide and confirm

Decide who the Product Owner is

When there are multiple stakeholders, who the Product Owner is can be vague and unclear. Let’s clarify who makes decisions for the service being developed under contract from the beginning.

Decide development priorities

Setting up the development environment should be done early on, so I recommend doing it with high priority. If you postpone it, minor tasks that take about 5 minutes each will accumulate and gradually eat away at development time.

Let the Product Owner decide other business priorities.

Confirm the release flow

I recommend confirming the entire flow from developing minor tasks to releasing them to production first.

When you try to release, you might discover unexpected pitfalls, such as lacking permissions or having designated release time slots for service operations.

That’s all from the Gemba that’s also doing contract development.