Do you maintain documentation for the site or application you are designing?

Question

Project management

Situation: you work in a studio, rent a website, sign a maintenance agreement, and put a junior employee on maintenance. So that he does not waste time on "pouring" into the project, do you make documentation for the project for such cases (from and to: on which account the site, domain, mail; why this is so and not; where did it come from, etc. .)?
If you do, with what tools?
ps I ask you to refrain from commenting that everything is wrong if you do not work like that. There is little I can change here, and the position of the whole team needs to be improved.

Answer 1

Docks in a separate tool / site / one click from the code = no one will write docks Docks
either in code or nowhere More descriptive power is the project bug tracker + its turnip

Answer 2

It is difficult to maintain documentation for the project if the requirements change ten times a day. And the time lead (senior, middle) spends on writing detailed documentation is much more valuable than the time spent by junior to delve into the project. Now, if it were possible to write documentation right in the course of writing the project itself! But it's fantastic and I don't know anyone who can do it.

Answer 3

I try to write in such a way that everything is clear without documentation. This is the only thing that works. In all seen projects, except for Enterprise, a discrepancy between documentation and code immediately begins, as requirements change daily, and there is no time to maintain documentation.
With deployment, the situation is the same: it is better to invest time in developing an automatic deployment script than to write documentation that will first become outdated, and then generally begin to contradict practice.

Answer 4

We do it with notion.so - we store basic documentation there, a glossary of concepts, very brief descriptions of administrative procedures, explanations of why and how some things work, and of course - documents for individual tasks (if the task is large and writing a full description in the bug tracker is inconvenient) . It is important that the client side works with these documents, that is, they write tasks themselves, insert screenshots there, etc. After that, what they wrote can be finalized, add explanations for the developer - and into the process.
But the issue of documentation in the code, which was written about here, worries me a lot; we need to take care of it. It is to ensure that developers, especially new ones, see the big picture in a more understandable way. Of course, there is some kind of navigation in the IDE, but it's still not quite right.
All documentation cannot be kept in code, in my opinion, since we want to involve the client in working on it. But for a developer to write code separately and separately docks is also a problem, extra time and context switching. Nobody likes to do this. Therefore, I think that it is necessary to have two sets of documentation - purely for development, auto-generated from the code, and in the knowledge base, focused on the client. In this sense, I like Notion incredibly, I have not seen anything like it in other places. Although there is no limit to perfection and I want even more :)
PS Eugene : regarding literary programming... I tried to do something similar in a student hobby project, I dabbled. But it did not work out very well, since the linear sequence of the document comes into conflict with the structure of the program, which looks like a graph.
However, it gave me a fair amount of pleasure that the result is not only Python code, but also an incredibly beautiful PDF made by LaTeX, with pictures and formulas. And if you contrive - you can actually generate all sorts of pictures directly from the code, for example, database schemas; it will be beautiful. We must somehow return to this topic, it is very interesting.

Answer 5

Yes, of course, we use the knowledge base for this. For each product/customer, it has a section that describes the basic rules/accounts/passwords/appearances.

Answer 6

If at a minimum of effort, then you can support the API by commenting only on public methods (a la https://ru.wikipedia.org/wiki/Javadoc, https://ru.wikipedia.org/wiki/JSDoc and the like) and subsequently generating documentation.
The ease of the approach is that when you change the method, you immediately see its description in the code and change it if necessary.

Answer 7

Redmine with knowledge base on wiki

Answer 8

Writing documentation separately is a waste of time not only for writing it, but also for maintaining it.
Project documentation should be tests (primarily high-level ones - for example, on Cucumber), code and user stories described in tickets.

Answer 9

When it comes to saving time on injecting new people into the project, then all you need is:
1) Find out which information is missing that causes the most work for the new supporter
2) Describe the necessary information, provided that the time spent on the description, will cost less than the time that would otherwise be spent figuring it out on your own and eliciting it from colleagues (taking into account the time of colleagues).