Hello, I'm Nishijo, the leader of the direction team.
Previously, I spoke about "knowing the distance between you and your customer and choosing words that will convey that," but this time I'd like to talk about communication on the production side, especially with in-house coders.
Share your goals
When a director asks a coder to do work, the first thing they do is hold a kickoff meeting. A kickoff meeting is a meeting held at the start of a project, where the project outline, goals, schedule, structure, etc. are shared.
In order to share the vision for the goal at the kickoff meeting, the following documents are prepared. By preparing these documents, we can prevent any misunderstandings during the upcoming production period.
- Project overview (business details of the company to be renovated, purpose of site creation, goals, etc.)
- Sitemap
- Wireframe (screen layout diagram)
- Design Instructions
- Basic site specifications (target OS/browser, recommended screen size, minimum guaranteed resolution, print layout, etc.)
- schedule
For sites that require a CMS, the following specifications will be prepared.
- Front end (the side the user sees)
- Backend (Administration screen side)
*CMS is a system that allows you to update and manage website content without specialized knowledge of HTML, CSS, etc.
There are a few things to keep in mind when preparing these documents.
It's about whether the documentation is finished to a level that coders can implement without hesitation. The key is whether it is clear to anyone who looks at it. If different people have different impressions, there is a possibility that the goal will stray from the goal that should be reached. If the coder is confused, it will be burdened accordingly, so it is necessary to prepare the documentation with sufficient care.
Understand the team structure of the coders
Even within a company, team structures differ depending on the department. In order to ensure the smooth progress of a project, it is necessary to first grasp the structure and roles of the coder's team before kicking off.
By knowing in advance how the team manages the project, the resources, and follow-up with creators, I think you will be able to provide individual follow-up that is tailored to the team and creators.
When you interact directly with a coder, you tend to ask them for advice on everything.
In fact, in the past, I have consulted with a coder about additional requirements without understanding the resource situation of the coder's team. The coder himself listened to my request and tried to respond within the schedule estimated in the initial requirements. However, as a result, the original schedule could not be met,
It put a strain on the coders.
Therefore, it is necessary to always be careful to ensure that the client's requests are not expanding too much from the initial requirements, and that they are within the initial estimated labor hours, and to provide direction while avoiding placing unexpected excessive burdens on the coder.
It is important to understand the team structure so that you can proceed flexibly, for example by changing direction rules depending on the project.
Get rid of the assumption that "no questions = understanding"
This isn't limited to kick-off meetings, but in any meeting, if the producer doesn't ask any questions after you've explained the project to a certain extent, you may tend to assume that they understand what you've explained.
However, sometimes production starts with the producer having an understanding that is different from what we intended, due to differences in the prerequisites to begin with, etc.
For example, at Monosas, we often use systems such as WordPress and MovableType for our projects, and we generally prepare specification documents for both the front-end and the end-end.
However, in the case of a layout that utilizes basic functions, we sometimes prepare only the front-end specifications and work together with the coder to develop the layout.
In the past, we had a case where we kicked off without preparing a front page for a layout other than the basic functions. It seemed like we were able to proceed without any problems, but near the end of development, we realized that the coder had not been able to paint a concrete image, and we had to reflect on the poor way we communicated our image and the way we followed up.
At the time, the reason I did not prepare a specification document for the management screen was that it seemed to me that the input screen I had in mind was lacking in some ways, and I was concerned that there might be a screen that was easier to operate, so I did not prepare one as a starting point, but instead only prepared a reliable specification document for the front side and explained it.
Looking back now, I think the coders might have been less hesitant if the director had first created a concrete image for the project, including any concerns he had, and then used that as a basis for discussion.
summary
This time, I talked about communication with people (teams) you're working with for the first time, but I think that even when working with people (teams) you regularly commission, if you keep these points in mind, you will be able to produce work of higher quality.
Now that I think about it, I remember something a programmer taught me when I was working at a systems development company.
The design documents must be easy for anyone to understand.
The most dangerous thing is to assume that people will understand without me having to write all this information.
It's not just about design documents, but I would like to provide direction that will eliminate everyday preconceptions and allow everyone to work without stress.
モノサスアーカイブ