Comparison of approaches to site creation: design, brief and agile
I have never seen a comparison of the methods of approach to creating sites. I understand perfectly well how subjective this will be: everyone praises what he can do. And yet, I decided to summarize my experience and observations of how others do it. In our sphere, there are, roughly speaking, the three most popular methods: design, writing “TK” and Agile. Here I also compare them.
Just in case, we will agree on the terms:
Nb. Please pay attention, dear agile-adepts! I deliberately use the term Agile not in the way it is written in Wikipedia or in the Manifesto. I use it to designate an approach when the development team does not know what will happen in the end and acts in short runs with evaluating intermediate results. That is what I had "pleasure" several times to observe as an approach to creating a site.
')
The comparison methodology is simple as a steamy turnip: we consider each method from the point of view of its pros and cons, applicability. Everything is subjective, based on personal experience and the experience of colleagues. I will consider each approach in relation to the two most common types of sites - the corporate website of a company and a commercial start-up service.
I would be very grateful if someone would argue with me, share my own thoughts. For this and write, actually. If someone thinks that I am for the design - you did not think.
Designing is the scrupulous creation of a site model that describes its business objectives, context, and solutions. As a result of the design, we get a clear understanding of what, why and how we should do, what resources and when it will be needed.
From the point of view of the design process, it is a long, time consuming, nerve and cost-effective exercise, which looks like this: collecting information, researching the context, creating a concept, creating characters and scenarios, describing communication: content, style, creating architecture: functional and informational, evaluating resource creation schedule.
The brief is an outline of the requirements, model and structure of the site with the requirements of the customer "what should be the site: creative, informative, functional, with a forum and social networking buttons."
A brief is often made on the basis of filling out the performer’s application form or is generally written by the customer. I will speak about this in the next article and have already spoken in How to set a task for a simple (template) site .
The process most often looks like this: talked with the client, sketched out the requirements, sketched the structure, described what would be in the sections, chose the CMS.
Agile is a flexible process control, which is divided into short sections with a specific task and a deadline, the result of which we get something working.
Agile has two features. Firstly, this approach does not provide an overall picture, and, therefore, does not allow planning and forecasting in a more or less long-term perspective. Secondly, the understanding of the general idea can be clarified along the way up to a complete rethinking. Making a video chat? Yes. For what? For consultation service. Okay, for this you need: video and audio connection, settings, window size adjustment, fullscreen, desktop broadcast. Go. Made. And how should it work? Do not just connect users? Connect authorized users ?! Let them manage? Let the admin connect to the conversation? This is a practical complete rework of the mechanism, except for the data transfer protocol. Go. Two more months.
So, my personal opinion about the applicability of the above approaches.
Design is useful everywhere, except for sites with a budget that does not allow to design. If the site is simple, then the design can be done quite quickly, reducing the time for research and thinking through. It will not give super quality, but it will still be much better than a brief.
The brief is applicable only where there is no money or skill. In the absence of several days for abbreviated design over the full cycle, I do not believe: it is laziness and incompetence.
I do not believe in the effectiveness of Agile when it comes to a business project. In general, Agile Manifesto was written as an approach to software development, but it was deftly dragged into the management of any projects and erected almost into a new religion, which allows us to do what “conservative waterfall models” do not allow.
"A working product is more important than complete documentation." Yes, but this, taking into account the methodology, motivates developers to solve problems according to the principle “works - and well”, which contributes little to the rapid and effective achievement of the business goal. “Reaction to changes is more important than following a plan.” So it’s true, and not in the case of a business project. Where do the changes come from? Most often, from a misunderstanding of the goal. If we bet on the reaction to change, then we increase the time and cost of development. Infinite choices of variants, this way and that, but it's not that, because in the case of Agile it can happen only by chance.
Another Agile problem in client projects is that the developer is actually not responsible for the final business result (and not the software). They made a sprint - they showed it to the customer or the manager - they approved it - further. The customer is forced, looking at intermediate results, to take responsibility for the final business result on himself. Can he? Most often, no. And when he receives not what he needs, there is nothing to argue: he himself asserted the results of all the sprints.
In my opinion, Agile works in two cases when it comes to sites. First, when the team itself is the customer and the carrier of knowledge and ideas. The guys clearly know what they want, go for it cheerfully and cheerfully, spend their time, are ready for risks. Secondly, when you need to do something “promo-like”: thedeepestsite.com . This does not negate the need for design, but here it has the right to be superficial and give only a clear understanding of the task, and not to paint the model and all the stages in detail. If you paint the model in detail, this greatly limits the subsequent "creative".
Just in case, we will agree on the terms:
- Design is a detailed study with research: tasks, concept, communication, architecture, resource assessment. I wrote about this several times before (you can see in the list of my posts) and I will continue to write.
- The brief (sometimes called TK, which is wrong in essence) is the requirements, the general structure of the site at the level of top-level sections and their brief description. Habra-authors wrote about this in different articles: Terms of Reference for a site , Terms of Reference: how to protect yourself from mistakes and risks or a typical template for a technical assignment for developing a site
- Agile - defined the general idea, general requirements, carried out the design - scenarios, users, architecture - to the best of our desires and abilities and rushed. No one knows when the site can be launched; This is decided along the way.
Nb. Please pay attention, dear agile-adepts! I deliberately use the term Agile not in the way it is written in Wikipedia or in the Manifesto. I use it to designate an approach when the development team does not know what will happen in the end and acts in short runs with evaluating intermediate results. That is what I had "pleasure" several times to observe as an approach to creating a site.
')
The comparison methodology is simple as a steamy turnip: we consider each method from the point of view of its pros and cons, applicability. Everything is subjective, based on personal experience and the experience of colleagues. I will consider each approach in relation to the two most common types of sites - the corporate website of a company and a commercial start-up service.
I would be very grateful if someone would argue with me, share my own thoughts. For this and write, actually. If someone thinks that I am for the design - you did not think.
Design
Designing is the scrupulous creation of a site model that describes its business objectives, context, and solutions. As a result of the design, we get a clear understanding of what, why and how we should do, what resources and when it will be needed.
From the point of view of the design process, it is a long, time consuming, nerve and cost-effective exercise, which looks like this: collecting information, researching the context, creating a concept, creating characters and scenarios, describing communication: content, style, creating architecture: functional and informational, evaluating resource creation schedule.
pros
- Lets check ideas. Here, for example, the customer has an idea about the site. How to understand how to implement it in practice: what should be the design, what functional solutions to use, what to say to the visitor, how much it will cost and take time, are there resources for it, is it realizable from the point of view of the customer’s organizational structure? No, if not design.
- Gives you a choice of solutions . We designed the site, we see possible architectural, functional and design solutions and we can choose how and what to do depending on the available resources.
- Increases efficiency. Designing makes the site aimed at solving problems that meet the needs of Central Asia and the context, and not someone's subjective views / desires.
- Gives a good tool to select a contractor. The contractor can be selected by recommendation, portfolio, personal feeling, intuition - in different ways. But the project, in which you can see and evaluate its implementation, is a great tool for holding a tender on the "price / quality" criterion.
- It provides an opportunity to estimate the cost and timing. I think it is not necessary to comment. There is a project - there is the most accurate assessment. In comparison with other methods.
- Ultimately, saves resources and time. Designing increases the accuracy of solutions, and, therefore, reduces the risk of errors, which always lead to additional costs for the development of the site and everything related to it.
Minuses
- More expensive and longer than TK. Usually not less than 50 thousand rubles, if done conscientiously.
- Need to learn . In order to design well, you need to shovel a lot of literature, fill a bunch of cones on dozens of projects, and also have the ability.
- Not every developer understands how to work on a project . Not enough knowledge, experience, too accustomed to the brief.
Brief
The brief is an outline of the requirements, model and structure of the site with the requirements of the customer "what should be the site: creative, informative, functional, with a forum and social networking buttons."
A brief is often made on the basis of filling out the performer’s application form or is generally written by the customer. I will speak about this in the next article and have already spoken in How to set a task for a simple (template) site .
The process most often looks like this: talked with the client, sketched out the requirements, sketched the structure, described what would be in the sections, chose the CMS.
pros
- Quickly. You can bungle a day or two.
- Cheaply How much are a couple of days of writing a brief in a regular web studio? A couple of thousand rubles.
- There is a certain freedom of action. Brief can be interpreted one way or another. For example, what does the phrase “there will be news on the corporate site” mean in the brief? Nothing, except that there will be news. You can make them so, and you can do so. The first will take 2 days, and the second - a week. For whom is it a plus? For someone whose character is stronger.
Minuses
- Unreasoned. Too little information, analysis, groundless choice of solutions. This entails mistakes, extra money, wasted time or the need to launch a bad website, because “the authorities demand”, “it’s time”, etc.
- Does not allow to properly assess the resources and timing. Because there is not enough detail and understanding (see paragraph 1).
- See point 3 in the pros.
Agile
Agile is a flexible process control, which is divided into short sections with a specific task and a deadline, the result of which we get something working.
Agile has two features. Firstly, this approach does not provide an overall picture, and, therefore, does not allow planning and forecasting in a more or less long-term perspective. Secondly, the understanding of the general idea can be clarified along the way up to a complete rethinking. Making a video chat? Yes. For what? For consultation service. Okay, for this you need: video and audio connection, settings, window size adjustment, fullscreen, desktop broadcast. Go. Made. And how should it work? Do not just connect users? Connect authorized users ?! Let them manage? Let the admin connect to the conversation? This is a practical complete rework of the mechanism, except for the data transfer protocol. Go. Two more months.
pros
- Fast start. You can start doing it right away without wasting time on documentation. True, the usefulness of this item is associated with some others. For example, with the following.
- There is something to show the investor before the start of the actual development. Investors respond very well to something that works and shows an idea. If you quickly make a prototype, you can quickly get the money and continue on the path of design.
- Quick results and validation of ideas on real users. We made the main piece of the service or site (you can remember the fashionable flex scope), showed the users, received feedback, changed something and went on. It is worth making a reservation that the result may be fast and working, but not sufficient to solve a business problem, and the feedback will relate to a specific piece, and not to the service itself. For example, when creating an online store with one quickly made catalog you will not manage: you need payment and data on the availability of goods in order not to take money for a non-existent product. And this will require a much more detailed study of business processes, and, therefore, new design, development and testing.
- Process flexibility The ability to change the idea on the go, functionality. Those. if you realize in time that you are doing something wrong, you can save time and money. But how to understand this without analysis, only the great gurus of Agile know. I dont know.
Minuses
- There are no criteria for the effectiveness of the final result. From a business point of view, it is not clear what will happen, how to evaluate it, whether our business = tasks solve what we do.
- Unpredictability. See point 1, as well as the inability to plan resources and events related to the readiness of the site. Are there many customers willing to fit into this?
- Longer and more expensive . Yes, I think so, because in Agile every hour spent by the development team is paid, and these hours, rest assured, Mr. Customer, will be many. Because we do not know what we are doing and why we are listening to your every whim, we are ready to shovel the whole architecture, because you pay for it.
findings
So, my personal opinion about the applicability of the above approaches.
Design is useful everywhere, except for sites with a budget that does not allow to design. If the site is simple, then the design can be done quite quickly, reducing the time for research and thinking through. It will not give super quality, but it will still be much better than a brief.
The brief is applicable only where there is no money or skill. In the absence of several days for abbreviated design over the full cycle, I do not believe: it is laziness and incompetence.
I do not believe in the effectiveness of Agile when it comes to a business project. In general, Agile Manifesto was written as an approach to software development, but it was deftly dragged into the management of any projects and erected almost into a new religion, which allows us to do what “conservative waterfall models” do not allow.
"A working product is more important than complete documentation." Yes, but this, taking into account the methodology, motivates developers to solve problems according to the principle “works - and well”, which contributes little to the rapid and effective achievement of the business goal. “Reaction to changes is more important than following a plan.” So it’s true, and not in the case of a business project. Where do the changes come from? Most often, from a misunderstanding of the goal. If we bet on the reaction to change, then we increase the time and cost of development. Infinite choices of variants, this way and that, but it's not that, because in the case of Agile it can happen only by chance.
Another Agile problem in client projects is that the developer is actually not responsible for the final business result (and not the software). They made a sprint - they showed it to the customer or the manager - they approved it - further. The customer is forced, looking at intermediate results, to take responsibility for the final business result on himself. Can he? Most often, no. And when he receives not what he needs, there is nothing to argue: he himself asserted the results of all the sprints.
In my opinion, Agile works in two cases when it comes to sites. First, when the team itself is the customer and the carrier of knowledge and ideas. The guys clearly know what they want, go for it cheerfully and cheerfully, spend their time, are ready for risks. Secondly, when you need to do something “promo-like”: thedeepestsite.com . This does not negate the need for design, but here it has the right to be superficial and give only a clear understanding of the task, and not to paint the model and all the stages in detail. If you paint the model in detail, this greatly limits the subsequent "creative".
Source: https://habr.com/ru/post/144442/
All Articles