Hidden threat: critical moments that are not enough attention after the end of software development

It is not enough just to code and test the program.

Have you ever had an employee who has worked with it for a long time leaving the program after launching the program? Or there is a need to finalize the program, but no one remembers how it works?

Continuation you know: everyone starts frantically to recall what the program is, how it works, where it is stored and where it comes from, etc.
')
Agree, such situations occur with enviable periodicity and occur very often.

If the program does not have normal documentation, then it is very and very difficult to restore its internal structure. And sometimes it even results in serious errors or a complete stop of the process.

Therefore, it is good practice to create simple instructions for use (which, for speed, can be replaced, for example, with screencasts).

However, there is one thing that few people pay attention to.

Let's look at it with a specific example ...

Imagine that you made a directory of Russian cities, which is used, for example, when registering on your site.

Everything works fine, but a year or half of a year passes and the names of many cities change (this is a very real situation - the names of localities change constantly).

How do you find out about it? What will you do when you find it?

And then what? Soup with a cat?

Will you wait until users start sending you angry letters with questions where are you sharing their city? It is unlikely that you are interested in this, right?

Therefore, it is not enough just to make a reference book. It is also necessary to foresee what will happen to it later, after its commissioning.

Moreover, this part is unexpectedly important and rather laborious. But it is necessary to do it!

Let's bring the reference book example to the end and think about the procedure for updating them.

You can update the directory in two ways: automatically and manually.

Of course, it’s best to update automatically, but often this is not enough.

Imagine that the source from which you take the list of cities has broken - it has ceased to be updated or an error has occurred on it.

If the error can still be somehow detected (for example, automatically sending letters to admins), then you will not find out the termination of the update (after all, there is no error, but the information is not updated)

Therefore, it is more correct to single out a special person who will be in the know on this directory and will be able to determine that he is not true.

Wow! The challenge is growing.

It is up to the person’s responsibilities to check the directory periodically, or even better add a task to his calendar and write instructions on what to do when a problem is found.

And in a year to remember how the handbook works, you should write information about it on the wiki: how the module works, where and how information is stored in the system, who the letters go to, the reference to the TOR, what kind of person is needed to support it and what its responsibilities are.

It turned out a full-fledged business process.

Results

As you can see, it is not enough just to write and run the program.

Be sure to think about what will happen with your program further: how it will be used, how to keep it up to date and how to act in emergency situations.

The usual objection to this is: not enough time. Yes, time is always not enough, but think about how much time you will lose later, when you need to do something urgently. Believe me, the losses will be much higher and more expensive than now, when the program has just been created.

Try instead of text instructions to do video screencasts - it's faster and easier.

If you want to make a finished product and take care of your users and colleagues, think about what will happen after your program starts working.

Just make a small checklist and use it for each of your programs.

And success in your work!