Keeping things in place after participating in the project so that it can proceed smoothly

purpose

Here's a look at the best ways to get off to a better start after participating in a project. I hope I can make use of it when I participate. Basically, it is a viewpoint made for people who enter the field alone in about the first or second year, so I do not write so much detail.

Know the details of the project

5W1H to know what kind of project it is

• Who: Who is the original contractor of the service? What kind of business stream?
• Why: The purpose of this project. There are nuances included in What, but it is necessary to organize requirements and find specification bugs.
• What: What kind of service (and what features are you responsible for?)
• When: When are you targeting and what is the schedule for the phases to do so?
• Where: It is likely to indicate the location of the site, but it is thin in the place, so here we will refer to the equipment rules of the site.
• How: I can't write it down here, so I'll list it below.

First of all, keep these down to a minimum.

I will write more details below.

Memorizing Site Rules (Where)

• What are the hours of operation?
• Where is the toilet?
• What are the security rules?
  • How do I enter and enter the museum?
  • Can I use the emergency stairs?
• Where is the work floor?
• Where is the vending
• What to do for lunch
• Where are the convenience stores?
• How and who should I contact for attendance?
• What should I wear?

Learn the system (How)

• What kind of system is it?
  • Managers, leaders, common teams, SEs, PGs, testers, designers, planners, etc., who is in charge of what and what is they in charge of? If there is a window, who is the window?
• If you have a question, who do you ask?
• Who are the experts in business knowledge, and who are the technical experts (there may be people who are related to the role but are familiar with it outside the role)?
• Is it not composed of people with low skills→ Large operational potential
• At the very least, what kind of character are the people you are related to (you should be conscious of them when communicating). )
• What is the atmosphere and balance of power in the field (It is better to be aware of it when communicating) )

Remember the location of a document (HOW)

• What is a document server? Anywhere?
• What is the folder structure of documents?
  • requirement
  • Basic design
  • Detailed design
  • test
  • Materials received (such as submissions from subcontracting companies)
• Is there a wiki operation?

What are communication tools (How)

• How do you operate your e-mail?
• Is there a chat tool in operation and how is it operated?

Learn Source Control (How)

This is a necessary perspective for PG.

• Where is the source?
• What is the branch model for version control?
  • What will the deliverables be and how will they be submitted?
• Do I need to access the file server with an FTP (SFTP) tool? Can you do it?

Learn the architecture (how)

This is a necessary perspective for PG.

• Is there any documentation for the project's own architecture? If there is, look through.
• Who imports libraries and so on?
  • Who is responsible for license management?

How to make manufacturing smooth

This is a necessary perspective for PG.

• If you have a design document, learn how to read and structure the design document.
• Is there any sample code?
• Which team, who is ahead of the curve→ and who should be imitated?
• How do you proceed with unit testing? (The same goes for combined, synthetic, and other tests.) I won't go into the points of how to be aware of the test here. ）
  • What format should the unit test specification be used for?

It is roughly like this.