August 6, 2009 at 02:19“Virtual model” or how to gently and accurately remove project requirements
Life is a complicated thing, sometimes it throws out such funny rings that make you not just jump forward with your eyes closed, but rather it’s like trying to leave the car without the ignition keys and with an empty tank. But as practice shows, many web studios are still pushing their cars. Let's try to fix this at least partially.
There are such projects when it is not possible to engage in analysis and research as is customary in a civilized society. This happens for various reasons: employee vacations, small budgets, tight deadlines, and sometimes even opponents of the preliminary survey are found. Almost like in a famous joke: "what is there to think - you need to shake." Therefore, it is necessary to collect and formalize requirements in a very short time and one or two meetings with the customer, who can not always talk about the tasks to be solved due to the lack of experience with sites.
Having drank several times of problems with lack of data for further work, I developed for myself a number of measures that I proudly called the "virtual model" =)
What am I doing. First, I am preparing for a meeting: I am studying the subject area, potential competitors, their products, marketing methods and any other information that can be found. I go out to unwind and put the knowledge into my head, sketching, if necessary, important points in a notebook. I return with a cleansed brain and begin to design a virtual system in my head. It is not necessary to deeply detail, the main thing is not to forget the key functional parts that are typical for companies in this industry.
For example, for management companies such attributes are charts of daily fluctuations in indices, unit quotes, investment portfolios and others. Next, I will distribute a possible list of services - the functional parts of the site: “news”, “personal account”, “import of quotes from the Moscow Interbank Currency Exchange” and so on. After that I turn to the structure, and in the most primitive form I paint sections of sites. This will all be used as a cheat sheet, with which I will lead the client on the project at the meeting.
So, we come, get acquainted, ask for coffee and a signature pen. We apologize for the business cards that were forgotten in the office, gather our thoughts, smile dazzlingly and broadcast:
- I’ll tell you now how the project will live on.
The customer, overcoming surprise (how can it be, I see these people a second time, and they already tell me something), begins to listen. The main thing here is not to release the initiative. A little later, he himself will actively participate in the process.
And then communication comes down to role-based dialogs. First, I talk a little about what I managed to find out about the market in which it earns, and begin to put forward piece by piece from the "virtual model" of the project:
- We will connect the products with industry solutions so that there is an opportunity to go to the page of a specific product from this industry.
Etc. The customer, in turn, seeks to refute or supplement it:
- Good, but some of our customers select solutions not only by industry, but also by the platform on which the solution is implemented.
Okay, we make a note in the notebook and understand for ourselves that the entity “product” has an additional attribute “platform”, which will allow us to filter products by platform in the future.
Some time passes and we notice that the “virtual model” has acquired quite real requirements, anti-requirements, scenarios for using services and data - this is wonderful and 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 a system, but develop requirements for it. So that later there would be no surprised faces and questions: “Well, have we already discussed this ?!”
At the end of the conversation, a template for a future project emerges, which requires significant processing, however, the available information can already be transferred to the project concept in the logical parts of the system - services and a draft prototype of the interfaces.
As a rule, one or two meetings is enough to cover the lack of information. Details can already be thought out in the following steps.
Along the way, it was noticed that customers play with games “I invented it, and you break it” more willingly than formulate problems on their own 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 research of the subject area and analysis of requirements. In addition, if you come to the first meeting prepared and with thoughts on the project, customer loyalty will be much higher than if you came as an ordinary listener.
Of course, large projects cannot be extended in this way; it’s better to honestly report what will happen and increase the time / budget than to get involved in the “game” and then searching for the “weak link”.
Good luck in the development!
There are such projects when it is not possible to engage in analysis and research as is customary in a civilized society. This happens for various reasons: employee vacations, small budgets, tight deadlines, and sometimes even opponents of the preliminary survey are found. Almost like in a famous joke: "what is there to think - you need to shake." Therefore, it is necessary to collect and formalize requirements in a very short time and one or two meetings with the customer, who can not always talk about the tasks to be solved due to the lack of experience with sites.
Having drank several times of problems with lack of data for further work, I developed for myself a number of measures that I proudly called the "virtual model" =)
What am I doing. First, I am preparing for a meeting: I am studying the subject area, potential competitors, their products, marketing methods and any other information that can be found. I go out to unwind and put the knowledge into my head, sketching, if necessary, important points in a notebook. I return with a cleansed brain and begin to design a virtual system in my head. It is not necessary to deeply detail, the main thing is not to forget the key functional parts that are typical for companies in this industry.
For example, for management companies such attributes are charts of daily fluctuations in indices, unit quotes, investment portfolios and others. Next, I will distribute a possible list of services - the functional parts of the site: “news”, “personal account”, “import of quotes from the Moscow Interbank Currency Exchange” and so on. After that I turn to the structure, and in the most primitive form I paint sections of sites. This will all be used as a cheat sheet, with which I will lead the client on the project at the meeting.
So, we come, get acquainted, ask for coffee and a signature pen. We apologize for the business cards that were forgotten in the office, gather our thoughts, smile dazzlingly and broadcast:
- I’ll tell you now how the project will live on.
The customer, overcoming surprise (how can it be, I see these people a second time, and they already tell me something), begins to listen. The main thing here is not to release the initiative. A little later, he himself will actively participate in the process.
And then communication comes down to role-based dialogs. First, I talk a little about what I managed to find out about the market in which it earns, and begin to put forward piece by piece from the "virtual model" of the project:
- We will connect the products with industry solutions so that there is an opportunity to go to the page of a specific product from this industry.
Etc. The customer, in turn, seeks to refute or supplement it:
- Good, but some of our customers select solutions not only by industry, but also by the platform on which the solution is implemented.
Okay, we make a note in the notebook and understand for ourselves that the entity “product” has an additional attribute “platform”, which will allow us to filter products by platform in the future.
Some time passes and we notice that the “virtual model” has acquired quite real requirements, anti-requirements, scenarios for using services and data - this is wonderful and 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 a system, but develop requirements for it. So that later there would be no surprised faces and questions: “Well, have we already discussed this ?!”
At the end of the conversation, a template for a future project emerges, which requires significant processing, however, the available information can already be transferred to the project concept in the logical parts of the system - services and a draft prototype of the interfaces.
As a rule, one or two meetings is enough to cover the lack of information. Details can already be thought out in the following steps.
Along the way, it was noticed that customers play with games “I invented it, and you break it” more willingly than formulate problems on their own 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 research of the subject area and analysis of requirements. In addition, if you come to the first meeting prepared and with thoughts on the project, customer loyalty will be much higher than if you came as an ordinary listener.
Of course, large projects cannot be extended in this way; it’s better to honestly report what will happen and increase the time / budget than to get involved in the “game” and then searching for the “weak link”.
Good luck in the development!