Online psychologist - Collecting requirements
You can find the previous post from the online psychologist series here .
Today we will talk about the process of collecting requirements for technical implementation. But not about the specific collection, but about the methodology as a better approach to this matter.
It's no secret that project requirements are very important. They are akin to the axioms on which to build the rest of the "theory" of the project. And even if we slightly change the axioms, then in one case we can get the “Euclidean geometry”, and in another “Lobachevsky geometry”! Therefore, I recommend to approach the collection of requirements with full responsibility, and not in the "brainstorming" mode, as is usually done.
')
So what is the requirements collection process? We recommend organizing it as follows:
At the expense of goal-setting, I recommend at the beginning to read the following recent publication .
From myself I will add: goals as vectors and in the same way they add up and lead to more “high” goals. I recommend in all projects to build goals based on their personal goals. So you will be much easier to motivate yourself, as well as determine the significance of things.
For example, you say: "I want to be rich." Accordingly, to any of your projects, the goal turns into something like: “The implementation of this project should help me to become richer.” If the project is customized, and not purely yours, then the goal could be for example: “Implementing this project for customer A should bring me both money, and new connections and good relations, since cooperation in the future will be very beneficial in relation to my main goal. "
For our project, we formulated a goal like this: “Maximum experience” . The money will be later - without the desire to get it (and more!) Practically nowhere :) But for now we want to get more experience, so that in the future we can correctly balance between “give us more money” and “the customer is always right”.
The parties can be divided into two groups:
In addition to identifying each of the parties, we recommend determining the purpose of its participation. This is most difficult to do for the passive group, but here I recommend this approach as a projection of your main goal. Here's what we got:
I think it is clear enough for each item. But I recommend before each "conversation" to try to write out the requirements of this party in relation to its goal, as well as to your global one. It:
Here, too, I hope everything is simple. But there is a small recommendation to make two assessments. One assessment in relation to the party who stated such a requirement, and the second from your personal assessment in relation to your global goal. For example, one of the requirements from psychologists was the possibility of transferring “earned” money from an online account to our account or e-currency. It was estimated by the psychologist at 8 out of 10. But in relation to our global it is absolutely not important, since we can always do it manually and at the same time check whether everything is OK with bills, etc.
What exactly are the two estimates? In order to discover, at the time, the cornerstones, which are very important to the party, and you do not care - well, and vice versa. Such things during the project should be given special attention.
At this stage it is important to understand that what you have documented coincides with the real expectations of the parties. And also to make it clear that the assessment of the requirement is needed not in order to exclude something forever, but in order to place these requirements on the implementation timeline.
UPD: If you minus it, please explain for what?
Today we will talk about the process of collecting requirements for technical implementation. But not about the specific collection, but about the methodology as a better approach to this matter.
It's no secret that project requirements are very important. They are akin to the axioms on which to build the rest of the "theory" of the project. And even if we slightly change the axioms, then in one case we can get the “Euclidean geometry”, and in another “Lobachevsky geometry”! Therefore, I recommend to approach the collection of requirements with full responsibility, and not in the "brainstorming" mode, as is usually done.
')
So what is the requirements collection process? We recommend organizing it as follows:
- Formulation of the main goal of the project
- Identify the parties
- Receiving requests from each party
- Determining the importance of requirements in relation to the goal
- Coordination of requirements and their importance with the parties
Formulation of the main goal of the project
At the expense of goal-setting, I recommend at the beginning to read the following recent publication .
From myself I will add: goals as vectors and in the same way they add up and lead to more “high” goals. I recommend in all projects to build goals based on their personal goals. So you will be much easier to motivate yourself, as well as determine the significance of things.
For example, you say: "I want to be rich." Accordingly, to any of your projects, the goal turns into something like: “The implementation of this project should help me to become richer.” If the project is customized, and not purely yours, then the goal could be for example: “Implementing this project for customer A should bring me both money, and new connections and good relations, since cooperation in the future will be very beneficial in relation to my main goal. "
For our project, we formulated a goal like this: “Maximum experience” . The money will be later - without the desire to get it (and more!) Practically nowhere :) But for now we want to get more experience, so that in the future we can correctly balance between “give us more money” and “the customer is always right”.
Identify the parties
The parties can be divided into two groups:
- Active: obviously interested or directly involved in achieving the project goal
- Passive: indirectly involved in achieving the goal. For example: "search engines."
In addition to identifying each of the parties, we recommend determining the purpose of its participation. This is most difficult to do for the passive group, but here I recommend this approach as a projection of your main goal. Here's what we got:
- Business owners: new experience in relation to the art of extracting money, as well as at least a profitable business in half a year
- Psychologists: get enough income
- Customers: get a quality service at low cost
- Server equipment (passive): load minimization
- Search engines (passive): content optimization
Receiving requests from each party
I think it is clear enough for each item. But I recommend before each "conversation" to try to write out the requirements of this party in relation to its goal, as well as to your global one. It:
- Gives some starting point for the party to further thinking. For the latter, the inclusion of highly “controversial” items in the initial list helps a lot.
- Gives the right direction for reflection on exactly your goals. If this is not done, then everyone in the requirements begins to pull the blanket over himself.
Determining the importance of the requirement
Here, too, I hope everything is simple. But there is a small recommendation to make two assessments. One assessment in relation to the party who stated such a requirement, and the second from your personal assessment in relation to your global goal. For example, one of the requirements from psychologists was the possibility of transferring “earned” money from an online account to our account or e-currency. It was estimated by the psychologist at 8 out of 10. But in relation to our global it is absolutely not important, since we can always do it manually and at the same time check whether everything is OK with bills, etc.
What exactly are the two estimates? In order to discover, at the time, the cornerstones, which are very important to the party, and you do not care - well, and vice versa. Such things during the project should be given special attention.
Coordination of requirements and their assessment
At this stage it is important to understand that what you have documented coincides with the real expectations of the parties. And also to make it clear that the assessment of the requirement is needed not in order to exclude something forever, but in order to place these requirements on the implementation timeline.
UPD: If you minus it, please explain for what?
Source: https://habr.com/ru/post/41443/
All Articles