Client Through the Looking-Glass, or How Not to Devalue a Project by the Lack of Documentation
When during another meeting a customer has to remind the developer all over again about the need to not break anything, then perhaps it’s time to take a broader look at the project. In such cases, it would be logical to raise the issue of replacing this developer or find out the reasons for such situations, but in reality everything might be different.
Therefore, it may seem that instead of the customer, the project is managed by the developer. As if the client depends on them and at the same time pays for the development process. It turns out to be a situation with confused roles or “Client through the Looking-Glass.”
Why does this happen and how can it be fixed? Well, let’s figure it out.
“I Hope This Time Nothing Will Break”
The situation when the client continues to put expectations on the developer despite the incidents that arise, usually, occurs because of the following reasons:
- Perhaps the specialist has unique knowledge or skills that are difficult to replace, and the customer has to put up with the mistakes;
- Or, the project lacks documentation, which makes the task difficult for all participants to understand.
According to the standards of project management, in these cases, an analysis of the current state of the project would be carried out to identify the main problems. Development processes would also be reviewed, missing documentation would be compiled, and additional training for the team would be conducted. It would also be helpful to discuss expectations and requirements with the customer to ensure that all parties understand the goals and objectives of the project.
If the problems continue, despite all the efforts listed, then the question of changing a specific specialist or even the entire team would really be raised. Ultimately, a successful project requires the well-coordinated work of all participants and mutual understanding and trust.
But in fact, a project suffers from the lack of documentation because of the desire to save resources. Unfortunately, it is easy to fall into such a “looking-glass” if you reduce the time, effort, and resources spent on defining and documenting the requirements that a product must meet to achieve business goals. Usually, these requirements can be represented in a Scope of Work, Software Requirements Specification (SRS), and/or Product Specification (SPEC).
Without proper attention to these documents, the chances of the project to face many problems, such as miscommunication between all participants, missed deadlines, and budget overruns, increase. Therefore, let’s figure out the value of such documents and if they are even required on the project.
Software Requirements Specification Template
To make it easier for you, XB Software prepared a Free Software Requirements Specification Template. It is ready to use and captures all requirements.
Is Documentation Worthless, or Is There More Than Meets the Eye?
Often, before the first releases of the product, documentation has no value. Compiling and supporting it takes time and resources, and all you can care about at the start is to make new features and launch the product as soon as possible — there is no time for documentation. However, later on down the line, more and more situations, when changing the product source code in one part leads to bugs in another, will arise.
This leads to the team spending more time on fixing those bugs and troubleshooting than on developing new features. In such conditions, it becomes obvious that the lack of documentation significantly slows down the development process and worsens the quality of the product. When the project reaches a certain level of complexity, documentation becomes an indispensable tool.
Scenario 1. A Software Component Should Be Changed, But Nothing’s Recorded How It Works
Suppose a component has been adjusted several times, but it was so long ago that it is difficult to remember the details. The developer examines the application code and tries to understand how the specified feature should work. Without documentation, they have to spend a lot of time studying the code in an attempt to understand its specifics.
As a result, the specialist begins to refine the component based on their personal conclusions. After conducting Smoke testing, the developer shares their results with the client for verification and confirmation. Without knowing all the subtleties, the customer quickly sees that everything works as required and therefore approves the release of the changes. At the same time, neither the developer nor the client themselves expects any errors to occur or that the changes made will affect other features related to this component.
But due to the lack of documentation, understanding of the interaction of product components, and integration testing, a bug occurs. Eventually, it will be possible to learn about this kind of errors only from users, when they notice and report them.
Downside:
The lack of documentation slows down the development process and increases the likelihood of errors.
Scenario 2. A User Reported a Bug and Asks to Fix It
Let’s imagine a situation when a user discovered an error in the application and reported it through the customer support system. After receiving a bug notification and analyzing it, the client assigns a task to the developer to eliminate the identified problem and update the product.
The analysis can lead to the following conclusions:
Continue reading: https://xbsoftware.com/blog/documentation-for-product-development/
