YAGNI principle in project management
Our company is developing custom web applications. Not sites, business cards, namely applications. Most often - for internal corporate use.
One of the most pressing issues of custom development is the correct estimate of the time and budget of the project, so that the work is done, the customer is satisfied, and the profit is adequate. For 3 years we have tried various ways of working and approaches to solving the problem of time and budget. Reread a bunch of books, visited dozens of conferences, webinars, etc. Under the cut a description of the solution, which we have now found for the maximum benefit to the customer for an interesting budget for us.
First you have to talk about the way we have come to this.
Selling hours: the client sits down on the “endless” contract, the team gradually increases, and possibly the rates. Often someone distributes the work on the part of the customer, there are no analysts in the development team. Minuses: it’s rare to raise rates, sometimes it turns out that the project doesn’t take off and everyone is demoralized, people get bored and often have to rotate the team. It is beneficial in the presence of mediocre programmers, without stars, but really interesting and complex projects with such a team are not done.
')
Small fixed price on oDesk: a little work in a short time, well suited for rock stars who can work alone and quickly. Cons: the stars quickly realize that they themselves can work like this and go into freelancing.
Fixed Price: make a project on TZ for a specified period of a team in which there are different roles. Ancient classics - all analyze, evaluate, program, test, implement and ... fly out of the budget.
Methods of struggle:
Tried on several projects, even wrote in the criteria for the selection of projects - the willingness of the customer to work on SCRUM. Disadvantages: it is difficult to explain to the customer why he needs all this, it is quite difficult to properly organize the process in a team, the velocity estimate in the context of changing commands is inadequate, many customers have a prejudice. Could not find the answer to the main question of the customer: “And how many sprints will be required before the project is completed?”
What is taken from the SCRUM: the process of continuous improvement through retrospectives - up to change the process; acceptance criteria for features compiled with the customer; prioritization of features; planning pocker for evaluation.
There are many people who work at work, do what they say, and find pleasure in something else - games, hobbies, drunken people in the end. My partner, nem , and I don’t feel like that, and so we eventually came to the conclusion that we want to see people in the team who enjoy what they are doing.
And when an intelligent person - especially developer in the widest sense of the word - wants to enjoy his work, first of all he wants to understand that what he is doing makes sense and that someone needs it. (There is a degenerate case - an ultra-geek is buried in technology by the ears, technology for the sake of technology, and all this is needed only by him and a narrow group of like-minded people).
Since we are working for someone else's business, then what we are doing should benefit the business. Or, if this is a product for ordinary Internet users, please and benefit them.
As soon as, instead of technologies and processes, the happiness of users, developers, and customers becomes paramount, in that order, the view changes radically. I do not want to think in terms of asshole hours at all. Basically, the projects that we like, belong to the category of team faksed price.
In order for users to be happy, you need to be able to make good interfaces and think over each feature in terms of usefulness, convenience, beauty, finally. The team begins to think about marketing at its best: just make a good product and users themselves will spread the rumor.
For a team to be happy - they need to know that all this is necessary for someone, the more alive the users, the better. The team must see the customer, whose eyes are burning from a product that adequately perceives reasonable arguments, and does not measure everything in terms of “it's 100 bucks more, remove”. And the important point is that the team should not work on a permanent deadline and a deadline, there should be a normal weekend and evening. But if someone is carried away so much that even at home he takes on the project - this is normal, it means like. But it is better to explain that this way you can go far and try to limit everyone to working time.
If we are talking about the happiness of the customer, the skill “to keep within the time and budget” is important. From all of the above, we have a certain way of working with the project, which we are trying to use recently. And this is not some kind of methodology - this is common sense + understanding of the customer’s business, which makes it necessary to select a combination of methodologies or simply break all the rules when it is justified. At some point, the accumulated knowledge of the 1st law of dialectics led to a paradigm shift. We began to treat the customer's product as if it were our own.
FFF can be considered as a high-level way to keep within the time frame and budget, guaranteeing the customer that for the money he pays, and the period he is ready to allocate, he will receive the best that could be done.
One of the basic principles here is the already mentioned YAGNI. For each feature and wish, priorities are ascertained, importance for the product as a whole, etc. At this moment, any person in a team has the right to ask questions “Why do we need this feature?”, “Why is it important to release it in this release?” And “What will the product lose if this feature does not / will be later?”
The principle can be applied to any creative work, in particular, Andrei Shapiro told how you can make slides for a report in a very limited time. In general, the allocation of a finite time to solve a problem forces one to look for a simple way to solve it, sometimes going far beyond programming.
Further techniques help achieve this goal.
So - we want to understand what we are doing and for whom, in order to participate in discussions with the customer about the functionality on an equal or almost equal basis. For this purpose, methods are used that are usually advised to be used in business planning (for example, startupers like them very much).
Why are stickers and blackboard better? Everyone gets together, involved in the process.
We make a draft version of page navigation (if web) or client transitions between stages in other cases. We take all the people who have been identified as important, and we make them for each. Before each page we try to understand the context in which the user came here.
We put ourselves in his place and evaluate his feelings from what he saw and the motivation to move on to the next steps. Purpose: to understand what content of the pages motivates the user to continue communication with the product, and what can make him leave. Tools: board, A0 sheets, stickers, pens, markers.
An important point to understand the functionality - even if there is a specification - is the prototyping of the interfaces. Even if there is no UX specialist in the team, everyone can draw rectangles on paper. It is very important to agree with the customer a common understanding of the interface.
Why we do not work with the designer from the first day of work on the project? Designers love to delve into the little things and work through the models to the end, in color, with all the shadows and gradients. They are artists, but we have another goal - we need to understand, quickly drawing 5 options for arranging blocks on a page, whether the layout corresponds to business needs. Despite the fact that the progressive Jpeg method is being promoted by one of the most famous design studios - Bureau Artem Gorbunov - not every designer is ready to change the paradigm. Two designers of the Bureau known to me who perfectly understand this, use and train others, have higher technical or physical and mathematical education.
The essence of the method is the gradual addition of detail. With regard to web development: at first only a general page layout and navigation scheme, then detailed layouts and layout, then implementation. Important: the process of gradual improvement and detailing go through all the pages together, and not one by one. If there is an opportunity and time - you can play with the team, teams of other projects, the customer in an interactive game with paper prototypes.
The goal: to harmonize the high-level understanding of the interface, to involve the customer in the creative process — by investing a piece of soul in the layouts, he can no longer say that they are worthless. Tools: paper, scissors, stickers, pencils, pens, glue; or products like balsamiq
So, the release functionality is defined. Acceptance criteria for all features are made. Now it is important together with the customer to determine the order of priorities of all features. And select a part of those that are not strictly mandatory, again remember YAGNI. These features will go under the knife, if for some reason the development will not fit into the allotted time.
Until now, we have demanded concessions only from the customer’s side - we expect him to agree on cutting back the functional, loyal attitude to our questions about goals and meaning, understanding the objective reasons why something might not be done. And what do we ourselves do in order to do as much as possible without sacrificing quality?
We try to use Goldratt’s constraint theory to optimize the development process. We determine the critical path, lay down buffers wherever required. The diagram also shows the places where customer participation is needed - answers to questions, provision of materials, etc. Purpose: at each moment you can see what task to tackle, the customer sees where the deadline shift directly depends on him, helps to use safety buffers more competently than just multiplying the term by pi. Tools: any spreadsheet or special software (I do not know).
We do not welcome the drafting of TK. Sometimes the customer comes with him already, but we know that it can live to the end of development in the unchanged form only in one case: everyone resists changes to the last, even if they understand that what is written in the TK is no longer relevant.
Instead, we allow the possibility of changing the functionality on the go. A brilliant idea can come to the customer at night and he runs with it to us. With SCRUM, for example, this idea will go into the backlog of tasks. For it will not take up before the next sprint and will not even be, perhaps, to discuss. We inform the customer that his idea can make changes to the composition of the release not only in the direction of adding functionality, but also in the direction of reduction. We explain that half a day of discussion will force us to throw some feature out of the tail in the list of priorities. If all this does not cool him down and he really believes that this idea should be discussed and implemented, we are engaged in it.
It is no longer possible to apply any methodology in its pure form. It is necessary to study someone else's experience, to be interested in techniques that are not related to programming directly, and to draw tools and ideas from there.
Well, you need to understand that no methodologies and processes will help to make high-quality products. We'll have to include the head and develop responsibility in yourself! To each.
PS The article is not possible to talk about each of the methods in detail. Google will help and watching the author’s video-performances, where it was all told in a bit more detail - suddenly someone wasn’t tired of reading :-)
Speech on the same topic, including answers to questions from the audience, there are explanatory pictures and some details on the techniques:
Learn more about practices like Story mapping, paper prototyping, etc.
One of the most pressing issues of custom development is the correct estimate of the time and budget of the project, so that the work is done, the customer is satisfied, and the profit is adequate. For 3 years we have tried various ways of working and approaches to solving the problem of time and budget. Reread a bunch of books, visited dozens of conferences, webinars, etc. Under the cut a description of the solution, which we have now found for the maximum benefit to the customer for an interesting budget for us.
First you have to talk about the way we have come to this.
Classic outsourcing - selling watches or fixed price
Selling hours: the client sits down on the “endless” contract, the team gradually increases, and possibly the rates. Often someone distributes the work on the part of the customer, there are no analysts in the development team. Minuses: it’s rare to raise rates, sometimes it turns out that the project doesn’t take off and everyone is demoralized, people get bored and often have to rotate the team. It is beneficial in the presence of mediocre programmers, without stars, but really interesting and complex projects with such a team are not done.
')
Small fixed price on oDesk: a little work in a short time, well suited for rock stars who can work alone and quickly. Cons: the stars quickly realize that they themselves can work like this and go into freelancing.
Fixed Price: make a project on TZ for a specified period of a team in which there are different roles. Ancient classics - all analyze, evaluate, program, test, implement and ... fly out of the budget.
Methods of struggle:
- splitting into short iterations,
- risk assessment, probabilistic methods, multiplying the estimates by pi, etc.,
- The combination of both options is short iterations, each of which uses estimates of development speed and uses risk management using probabilistic methods, that is, for example, SCRUM.
Down with the cult of cargo - why SCRUM in its pure form did not work in our team
Tried on several projects, even wrote in the criteria for the selection of projects - the willingness of the customer to work on SCRUM. Disadvantages: it is difficult to explain to the customer why he needs all this, it is quite difficult to properly organize the process in a team, the velocity estimate in the context of changing commands is inadequate, many customers have a prejudice. Could not find the answer to the main question of the customer: “And how many sprints will be required before the project is completed?”
What is taken from the SCRUM: the process of continuous improvement through retrospectives - up to change the process; acceptance criteria for features compiled with the customer; prioritization of features; planning pocker for evaluation.
Production of happiness by industrial methods - why we do not want to just write code for money
There are many people who work at work, do what they say, and find pleasure in something else - games, hobbies, drunken people in the end. My partner, nem , and I don’t feel like that, and so we eventually came to the conclusion that we want to see people in the team who enjoy what they are doing.
And when an intelligent person - especially developer in the widest sense of the word - wants to enjoy his work, first of all he wants to understand that what he is doing makes sense and that someone needs it. (There is a degenerate case - an ultra-geek is buried in technology by the ears, technology for the sake of technology, and all this is needed only by him and a narrow group of like-minded people).
Since we are working for someone else's business, then what we are doing should benefit the business. Or, if this is a product for ordinary Internet users, please and benefit them.
As soon as, instead of technologies and processes, the happiness of users, developers, and customers becomes paramount, in that order, the view changes radically. I do not want to think in terms of asshole hours at all. Basically, the projects that we like, belong to the category of team faksed price.
In order for users to be happy, you need to be able to make good interfaces and think over each feature in terms of usefulness, convenience, beauty, finally. The team begins to think about marketing at its best: just make a good product and users themselves will spread the rumor.
For a team to be happy - they need to know that all this is necessary for someone, the more alive the users, the better. The team must see the customer, whose eyes are burning from a product that adequately perceives reasonable arguments, and does not measure everything in terms of “it's 100 bucks more, remove”. And the important point is that the team should not work on a permanent deadline and a deadline, there should be a normal weekend and evening. But if someone is carried away so much that even at home he takes on the project - this is normal, it means like. But it is better to explain that this way you can go far and try to limit everyone to working time.
If we are talking about the happiness of the customer, the skill “to keep within the time and budget” is important. From all of the above, we have a certain way of working with the project, which we are trying to use recently. And this is not some kind of methodology - this is common sense + understanding of the customer’s business, which makes it necessary to select a combination of methodologies or simply break all the rules when it is justified. At some point, the accumulated knowledge of the 1st law of dialectics led to a paradigm shift. We began to treat the customer's product as if it were our own.
Practices that we apply now
1. FFF - fixed price, fixed timing, flexible scope
FFF can be considered as a high-level way to keep within the time frame and budget, guaranteeing the customer that for the money he pays, and the period he is ready to allocate, he will receive the best that could be done.
One of the basic principles here is the already mentioned YAGNI. For each feature and wish, priorities are ascertained, importance for the product as a whole, etc. At this moment, any person in a team has the right to ask questions “Why do we need this feature?”, “Why is it important to release it in this release?” And “What will the product lose if this feature does not / will be later?”
The principle can be applied to any creative work, in particular, Andrei Shapiro told how you can make slides for a report in a very limited time. In general, the allocation of a finite time to solve a problem forces one to look for a simple way to solve it, sometimes going far beyond programming.
Further techniques help achieve this goal.
2. MVP - just the right and nothing more
So - we want to understand what we are doing and for whom, in order to participate in discussions with the customer about the functionality on an equal or almost equal basis. For this purpose, methods are used that are usually advised to be used in business planning (for example, startupers like them very much).
- Lean canvas helps to understand the main target audience, its problems and expectations, proposed solutions, costs and revenues. Well, when the customer has already done all this. If not, we do it with him. Purpose: to understand whether you need to engage in this project. Tools: A0 sheets, stickers, pens, markers.
- Persons are collective images of the target audience, animated characters that perform certain roles when using the product. Purpose: when planning new features or improving old ones, to be guided by their “opinion”, to represent how they will react. Tools: A4 sheets, pencils, pens.
- Impact mapping is a mind-map of business goals, where we try to imagine how our people and how they can help businesses achieve these goals. Purpose: to determine the main actions and functionality of the product. Tools: board and marker, or online service.
- Story mapping is an analogue of impact mapping, only from the users. Already existing people are taken, from which we choose the most important ones, according to Impact mapping, we write down high-level functionality for each of them. Then we describe the minimum required set of feature attributes, which will make the product valuable for the person. And we supplement the picture with development options that only come to mind in a limited time. Objective: to determine the scop of the first release, it is also the minimum valuable product or MVP. Tools: board, A0 sheets, stickers, pens, markers; any spreadsheet will do as well.
Why are stickers and blackboard better? Everyone gets together, involved in the process.
3. Customer journey - roles, contexts, moods
We make a draft version of page navigation (if web) or client transitions between stages in other cases. We take all the people who have been identified as important, and we make them for each. Before each page we try to understand the context in which the user came here.
We put ourselves in his place and evaluate his feelings from what he saw and the motivation to move on to the next steps. Purpose: to understand what content of the pages motivates the user to continue communication with the product, and what can make him leave. Tools: board, A0 sheets, stickers, pens, markers.
4. Interface Prototyping - Quick Hypothesis Testing
An important point to understand the functionality - even if there is a specification - is the prototyping of the interfaces. Even if there is no UX specialist in the team, everyone can draw rectangles on paper. It is very important to agree with the customer a common understanding of the interface.
Why we do not work with the designer from the first day of work on the project? Designers love to delve into the little things and work through the models to the end, in color, with all the shadows and gradients. They are artists, but we have another goal - we need to understand, quickly drawing 5 options for arranging blocks on a page, whether the layout corresponds to business needs. Despite the fact that the progressive Jpeg method is being promoted by one of the most famous design studios - Bureau Artem Gorbunov - not every designer is ready to change the paradigm. Two designers of the Bureau known to me who perfectly understand this, use and train others, have higher technical or physical and mathematical education.
The essence of the method is the gradual addition of detail. With regard to web development: at first only a general page layout and navigation scheme, then detailed layouts and layout, then implementation. Important: the process of gradual improvement and detailing go through all the pages together, and not one by one. If there is an opportunity and time - you can play with the team, teams of other projects, the customer in an interactive game with paper prototypes.
The goal: to harmonize the high-level understanding of the interface, to involve the customer in the creative process — by investing a piece of soul in the layouts, he can no longer say that they are worthless. Tools: paper, scissors, stickers, pencils, pens, glue; or products like balsamiq
5. Optimization of the development process
So, the release functionality is defined. Acceptance criteria for all features are made. Now it is important together with the customer to determine the order of priorities of all features. And select a part of those that are not strictly mandatory, again remember YAGNI. These features will go under the knife, if for some reason the development will not fit into the allotted time.
Until now, we have demanded concessions only from the customer’s side - we expect him to agree on cutting back the functional, loyal attitude to our questions about goals and meaning, understanding the objective reasons why something might not be done. And what do we ourselves do in order to do as much as possible without sacrificing quality?
We try to use Goldratt’s constraint theory to optimize the development process. We determine the critical path, lay down buffers wherever required. The diagram also shows the places where customer participation is needed - answers to questions, provision of materials, etc. Purpose: at each moment you can see what task to tackle, the customer sees where the deadline shift directly depends on him, helps to use safety buffers more competently than just multiplying the term by pi. Tools: any spreadsheet or special software (I do not know).
6. Willingness to change
We do not welcome the drafting of TK. Sometimes the customer comes with him already, but we know that it can live to the end of development in the unchanged form only in one case: everyone resists changes to the last, even if they understand that what is written in the TK is no longer relevant.
Instead, we allow the possibility of changing the functionality on the go. A brilliant idea can come to the customer at night and he runs with it to us. With SCRUM, for example, this idea will go into the backlog of tasks. For it will not take up before the next sprint and will not even be, perhaps, to discuss. We inform the customer that his idea can make changes to the composition of the release not only in the direction of adding functionality, but also in the direction of reduction. We explain that half a day of discussion will force us to throw some feature out of the tail in the list of priorities. If all this does not cool him down and he really believes that this idea should be discussed and implemented, we are engaged in it.
Summary
It is no longer possible to apply any methodology in its pure form. It is necessary to study someone else's experience, to be interested in techniques that are not related to programming directly, and to draw tools and ideas from there.
Well, you need to understand that no methodologies and processes will help to make high-quality products. We'll have to include the head and develop responsibility in yourself! To each.
PS The article is not possible to talk about each of the methods in detail. Google will help and watching the author’s video-performances, where it was all told in a bit more detail - suddenly someone wasn’t tired of reading :-)
Speech on the same topic, including answers to questions from the audience, there are explanatory pictures and some details on the techniques:
Learn more about practices like Story mapping, paper prototyping, etc.
Source: https://habr.com/ru/post/177241/
All Articles