"Virtual model" or how to gently and carefully remove the requirements for the project
Life is a difficult thing, sometimes throws out such amusing knees that make you not just jump forward with your eyes closed, rather, it’s like trying to drive away without an ignition key and with an empty tank. But as practice shows, many web studios are still pushing their cars. Let's try to fix it at least partially.
There are such projects when there is no opportunity to engage in analysis and research, as is customary in a civilized society. This happens for various reasons: staff leave, small budget, tight deadlines, and sometimes even opponents of a preliminary survey. Almost like in the famous joke: "what is there to think about - you have to shake it." Therefore, it is necessary to collect and formalize requirements in a very short time and one or two meetings with the customer, who cannot always tell about the tasks to be solved due to the lack of experience with sites.
Having drank a number of problems with the lack of data for further work, I developed a number of measures for myself, which I proudly called the “virtual model” =)
')
What am I doing. First, I prepare for a meeting: I study the subject area, possible competitors, their products, marketing methods and any other information that can be found. I go out to unwind and put the knowledge gained in my head, sketching important points in a notebook if necessary. I come back with a clean brain and start building a virtual system in my head. It is not necessary to deeply detail, the main thing is not to forget the key functional parts characteristic of the companies in this industry.
For example, for management companies, such attributes are daily fluctuation graphs of indices, share quotes, investment portfolios, and others. Next, I throw in a possible list of services - functional parts of the site: “news”, “personal account”, “import of quotations from the MICEX” and so on. After that I turn to the structure, and in the most primitive form I list sections of sites. All this will be used as a cheat sheet, with the help of which I will lead a project client at the meeting.
So, we come, we get acquainted, we ask for coffee and a branded pen. We apologize for the business cards forgotten in the office, we gather our thoughts, we smile and dazzle:
- I'll tell you now how the project will continue to live.
The customer, requesting a surprise (how is it, I see these people a second time, and they already tell me something), begins to listen. Here, the main thing is not to release the initiative. A little later, he himself is actively involved in the process.
And further communication is reduced to role-based dialogues. First, I talk a little bit about what I was able to learn about the market in which he earns, and begin to push piece by piece out of the “virtual model” of the project:
“We will link products with industry solutions so that there is an opportunity to go to a specific product page from this industry.
And so on. The customer, in turn, seeks to refute or supplement it:
“Good, but some of our clients select solutions not only by industry, but also by the platform on which the solution is implemented.
Ok, we make a note in a notebook and for ourselves we understand that the entity “product” has an additional sign “platform”, which will allow to further filter products by platform.
It takes some time and we notice that the “virtual model” has acquired quite realistic requirements, anti-requirements, scenarios for using services and data - this is great and will be very useful to us in the design process.
However, there is a subtle point. It is necessary to convey to the client that this is just a conversation and we do not design the system, but work out requirements for it. So that later there were no surprised faces and questions: “well, have we already discussed this ?!”.
At the end of the conversation a template for the future project emerges, which requires significant processing, however, the available information can already be shifted to the project concept in the logical parts of the system - services and draft interface prototype.
As a rule, one or two meetings is enough to cover the lack of information. Details can already be thought through in the following stages.
Along the way, it was noted that the games “I thought up and you break it” customers play more eagerly than they formulate problems themselves and describe their business processes.
It is important to understand that all of the above is not a solution for every day, but a way to achieve the best possible result with minimal resources, bypassing the phase of researching the subject area and analyzing requirements. In addition, if you arrive at the first meeting prepared and with thoughts on the project, the customer's loyalty will be much higher than if you came as an ordinary listener.
Of course, large projects cannot be pulled out in such a way, it is better to honestly say that it will turn out to be and increase the time / budget than to get involved in the “game” and then search for the “weak link”.
Successes in the development!
There are such projects when there is no opportunity to engage in analysis and research, as is customary in a civilized society. This happens for various reasons: staff leave, small budget, tight deadlines, and sometimes even opponents of a preliminary survey. Almost like in the famous joke: "what is there to think about - you have to shake it." Therefore, it is necessary to collect and formalize requirements in a very short time and one or two meetings with the customer, who cannot always tell about the tasks to be solved due to the lack of experience with sites.
Having drank a number of problems with the lack of data for further work, I developed a number of measures for myself, which I proudly called the “virtual model” =)
')
What am I doing. First, I prepare for a meeting: I study the subject area, possible competitors, their products, marketing methods and any other information that can be found. I go out to unwind and put the knowledge gained in my head, sketching important points in a notebook if necessary. I come back with a clean brain and start building a virtual system in my head. It is not necessary to deeply detail, the main thing is not to forget the key functional parts characteristic of the companies in this industry.
For example, for management companies, such attributes are daily fluctuation graphs of indices, share quotes, investment portfolios, and others. Next, I throw in a possible list of services - functional parts of the site: “news”, “personal account”, “import of quotations from the MICEX” and so on. After that I turn to the structure, and in the most primitive form I list sections of sites. All this will be used as a cheat sheet, with the help of which I will lead a project client at the meeting.
So, we come, we get acquainted, we ask for coffee and a branded pen. We apologize for the business cards forgotten in the office, we gather our thoughts, we smile and dazzle:
- I'll tell you now how the project will continue to live.
The customer, requesting a surprise (how is it, I see these people a second time, and they already tell me something), begins to listen. Here, the main thing is not to release the initiative. A little later, he himself is actively involved in the process.
And further communication is reduced to role-based dialogues. First, I talk a little bit about what I was able to learn about the market in which he earns, and begin to push piece by piece out of the “virtual model” of the project:
“We will link products with industry solutions so that there is an opportunity to go to a specific product page from this industry.
And so on. The customer, in turn, seeks to refute or supplement it:
“Good, but some of our clients select solutions not only by industry, but also by the platform on which the solution is implemented.
Ok, we make a note in a notebook and for ourselves we understand that the entity “product” has an additional sign “platform”, which will allow to further filter products by platform.
It takes some time and we notice that the “virtual model” has acquired quite realistic requirements, anti-requirements, scenarios for using services and data - this is great and will be very useful to us in the design process.
However, there is a subtle point. It is necessary to convey to the client that this is just a conversation and we do not design the system, but work out requirements for it. So that later there were no surprised faces and questions: “well, have we already discussed this ?!”.
At the end of the conversation a template for the future project emerges, which requires significant processing, however, the available information can already be shifted to the project concept in the logical parts of the system - services and draft interface prototype.
As a rule, one or two meetings is enough to cover the lack of information. Details can already be thought through in the following stages.
Along the way, it was noted that the games “I thought up and you break it” customers play more eagerly than they formulate problems themselves and describe their business processes.
It is important to understand that all of the above is not a solution for every day, but a way to achieve the best possible result with minimal resources, bypassing the phase of researching the subject area and analyzing requirements. In addition, if you arrive at the first meeting prepared and with thoughts on the project, the customer's loyalty will be much higher than if you came as an ordinary listener.
Of course, large projects cannot be pulled out in such a way, it is better to honestly say that it will turn out to be and increase the time / budget than to get involved in the “game” and then search for the “weak link”.
Successes in the development!
Source: https://habr.com/ru/post/66299/
All Articles