How do you keep project requirements always up to date? Instruments?

Question

Project management

The question is more for those who ate the dog in project management. The bottom line: there are requirements for the project, first in the form of an overview TOR, then in the form of tasks in the tracker, they are gradually implemented in the system (software) being developed, new ones appear, something changes, the customer changes his mind (some tasks lose their relevance), etc.
And then bam - and there is no whole picture, for example, a new developer comes to the project or even a new manager, then he starts asking the people, but how do you need it to work? The tester comes - "I was sent to test, but tell me how it should work at all?".
Guys, who uses what systems to manage software requirements, what do you store there? - tasks, or UserStories? Where to stick to read how it is generally in the mind to implement?
I’m not a PM, I know that I need to kick the PM, but I don’t really understand yet, what, should he stupidly manually track this, and the documentation in the wiki or in the Google doc?
Thank you all in advance.

Answer 1

> How to keep project requirements always up to date?
Good afternoon. Blitz answer - update information regularly )
> Tools?
Straight to the point - I'm the creator of such a tool. Details on the podium vc.ru ->
> The question is more for those who ate the dog in project management.
I have been working on this issue for almost 15 years as part of software development. Conducted webinars, conducted courses, wrote whitepapers, and eventually packed all the experience into a product, since the only way to actually transfer and consolidate the skill turned out to be software.
> The essence: there are requirements for the project, first in the form of an overview TOR, then in the form of tasks in the tracker, they are gradually implemented in the system (software) being developed, new ones appear, something changes, something the customer changes his mind (some tasks lose their relevance) , etc.
Requirements will always be manifested because attention is limited - we live and work in a situation similar to games like "strategy" - when the map is foggy we do not see anything, when we "reach" and "with our own eyes" see what is there - we see "new things". Were they new? no - they are new only in our attention. You are thinking right.
> And then bam - and there is no whole picture, for example, a new developer comes to the project or even a new manager, then he starts asking the people, how do you need it to work? The tester comes - "I was sent to test, but tell me how it should work at all?".
How it should work is determined at the very beginning, but it’s better to dive into the system, there are all the answers to how this knowledge about the result appears and how it is transmitted and how it is stored.
Also, the effect in the strategy game is the same, I call it the "flashlight effect" - where you "shine" there and you can see everything, but in the other corner where you don't shine (no focus) you can no longer see.
As in the strategy - when you leave the place of events and there are no your units on the map - your last "vision of the place" is "fixed" there, and in fact it will be different again when you return there.
> Guys, who uses what systems to manage software requirements, what do you store there? - tasks, or UserStories? Where to stick to read how it is generally in the mind to implement?
There are no tools and have not appeared for 15 years, I don’t know what this is connected with, although the question is on the surface - that’s why I made my product, for myself and for friends - but grew a little more.
A short answer in the group has already been given to the difference between Jira / Teamcity / Trells and more:
// quote
One key difference is that none of the products listed above "shape" the digital configuration of your product. In all these products, you need to "do" it yourself, having the skills and organizational capabilities of analysts and architects, documentarians and systems engineers.
The practices of Mjolnir are not entirely clear right off the bat - but following them you just work as if you were working in other systems, but the whole context will simply accumulate and you will never need to "transfer" knowledge to someone and lose context when changing employees.
But since I have been living on this soil for a long time, I will say this - the change of employees is such a sweet story that they tell at conferences - and how to deal with it with the help of wiki and confluence.
The problem is different - people cannot formulate tasks and their ideas in such a way that the problem of transferring these ideas between colleagues is not such a problem, because one says one thing, and the other hears and understands the third.
Mjolnir is designed in such a way that on the way, the operator periodically "turns on" thinking, and each time it becomes easier and easier, provided that exactly the information is stored in the system - which is important for the project and colleagues, and in the complete absence of the need to maintain "excessive" or superfluous information, which may be popular as a technique or schematization - but does not lead to a result in a general context, but is informational conference-article noise.
// end quote
> I'm not a PM, I know that I need to kick the PM, but I don't really understand yet, should he stupidly track it manually, and the documentation in the wiki or in the Google doc?
Try it, I have vids in the telegram group where I take it apart step by step how the development is going
> Thank you all in advance.
I hope they don't get banned - it seems to be a direct answer to the question.