April 19, 2013 at 00:05YAGNI Principle in Project Management
Our company is developing custom web applications. Not business card sites, namely applications. Most often - for corporate use.
One of the most pressing issues of custom development is the correct assessment of the terms and budget of the project, so that the work is completed, the customer is satisfied, and the profit is adequate. Over the course of 3 years, we have tried different ways of working and approaches to solving the problem of deadlines and budgets. Re-read a bunch of books, attended dozens of conferences, webinars, etc. Under the cut is the description of the solution that we have now found to deliver maximum benefit to the customer for an interesting budget for us.
First, we have to talk about the way we came to this.
Sale of watches: the client sits on an “endless” contract, the team gradually increases, and possibly the rates. Often, someone distributes the work on the part of the customer, the development team does not have its own analysts, Cons: it’s rarely possible to raise rates, sometimes it turns out that the project does not take off and everyone is demoralized, people get bored and often have to rotate the team. It is advantageous if there are mediocre programmers, without stars, but really interesting and complex projects cannot be done with such a team.
Small fixed price at oDesk: small work in a short time, well suited for rock stars who can work alone and quickly. Cons: stars quickly realize that they themselves can work this way and go to freelance.
Fixed Price: make a project on TK for the agreed period a team in which there are different roles. An ancient classic - to analyze, evaluate, program, test, implement everything and ... fly out of the budget.
Methods of struggle:
We tried on several projects, even wrote in the criteria for selecting projects - the willingness of the customer to work on SCRUM. Cons: it’s difficult to explain to the customer why he needs all this, it’s quite difficult to properly organize the process in a team, the estimation of velocity in conditions of changing teams is inadequate, many customers have a prejudice. We could not find the answer to the main question of the customer: “How many sprints will be required before the completion of the project?”
What did SCRUM take into service: the process of continuous improvement through retrospectives - until the process change; acceptance criteria for features compiled with the customer; prioritization of features; planning pocker for evaluation.
There are many people who work work at work, do what they say, and find pleasure in something else - games, hobbies, binges in the end. My partner nem and I don’t belong to these, and therefore, over time, I came to the conclusion that I want to see people on the team who enjoy what they do.
And when an intelligent person - especially a developer in the broadest sense of the word - wants to enjoy his work, first of all he wants to understand that what he does makes sense and someone needs it. (There is a degenerate case - an ultra-geek digs into technology headlong, technology for technology's sake, and all this is necessary only for him and a narrow group of like-minded people).
Since we work for someone else’s business, then what we do should be beneficial to this business. Or, if it is a product for ordinary Internet users - like and benefit them.
As soon as the main focus instead of technology and processes is the happiness of users, developers and the customer - in that order, the look changes radically. I don’t want to think completely in terms of ass hours. Basically, the projects that we like belong to the category of team fixed price.
To make users happy, you need to be able to make good interfaces and think about each feature in terms of benefits, convenience, and beauty, finally. The team begins to think about marketing in its best form: just make a good product and users themselves will spread the rumor.
For a team to be happy, they must know that someone needs all this, the more lively the users will be, the better. The team should see the customer, whose eyes are burning from a product that adequately perceives reasonable arguments, and does not measure everything in terms of “this is 100 bucks more, remove”. And an important point - the team should not work in a constant deadline and breakdown deadlines, there should be normal weekends and evenings. But if someone is so passionate that even at home he takes on the project - this is normal, then like it. But it’s better to explain that you can go this far and try to limit everyone to working time.
If we are talking about the happiness of the customer, the skill of “meeting deadlines and the budget” is important. From all of the above, we have a certain way of working with a project that we are trying to apply recently. And this is not some kind of methodology - it is common sense + understanding of the customer’s business, which forces them to choose 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 our own.
FFF can be seen as a high-level way to stay within the deadlines and budget, guaranteeing the customer that for the money that he pays and the time that he is willing to allocate, he will get the best that could be done.
One of the basic principles here is the already mentioned YAGNI. For each feature and wish, priorities are clarified, importance for the product as a whole, etc. At this moment, any person in the team has the right to ask the questions “Why is this feature needed?”, “Why is it important to release it in this release?” And “What will the product lose if this feature is not / will be later?”
The principle can be applied to any creative work, in particular, Andrei Shapiro toldhow to make slides for a report in a very limited time. In general, the allocation of finite time to solve a problem makes us 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 and for whom we are doing in order to participate in discussions with the customer about the functionality on equal or almost equal terms. For this, methods are used that are usually advised to be used in business planning (startups, for example, are very fond of them).
Why are stickers and board better? Everyone gets together, involved in the process.
We make a draft version of navigation on pages (if web) or transitions of the client between stages in other cases. We take all the people who have been identified as important, and do 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 page content motivates the user to continue communicating with the product, and what can make him leave. Tools: board, A0 sheets, stickers, pens, markers.
An important point for understanding the functionality - and even if there is a specification - is the prototyping of interfaces. Even if the team does not have a UX specialist, everyone can draw rectangles on paper. It is very important to agree with the customer a common understanding of the interface.
Why do not we work with the designer from the first day of work on the project? Designers are very fond of delving into little things and working out layouts to the end, in color, with all the shadows and gradients. They are artists, but we have a different goal - we need to understand, quickly by drawing 5 options for the location of blocks on the page, whether the layout corresponds to business needs. Despite the fact that the progressive Jpeg method is promoted by one of the most famous design studios - the Artem Gorbunov Bureau - not every designer is ready to change the paradigm. Two Bureau designers known to me, who perfectly understand this, use and train others, have higher technical or physical-mathematical education.
The essence of the method is the gradual addition of detail. With regard to web development: first, only a general outline of pages and a navigation scheme, then detailed layouts and layout, then implementation. Important: the process of gradual improvement and detail goes through all the pages together, and not one at a time. If you have the opportunity and time, you can play with the team, teams of other projects, the customer in an interactive game with paper prototypes.
Purpose: coordination of a high-level understanding of the interface, involving the customer in the creative process - having put a piece of soul into the models, 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 compiled. Now it is important to determine the priority order of all features together with the customer. And to highlight part of those that are not strictly mandatory, we recall YAGNI again. It is these features that will go under the knife if, for some reason, the development does not fit into the allotted time.
Until now, we have demanded concessions only on the part of the customer - we expect him to agree to reduce functionality, to be loyal to our questions about goals and meaning, to understand the objective reasons why something may not be done. And what do we do ourselves in order to be in time as much as possible without sacrificing quality?
We try to use Goldratt's theory of constraints to optimize the development process. We determine the critical path, lay the buffers wherever required. The diagram also shows the places where customer participation is needed - answers to questions, provision of materials, etc. Purpose: at every moment it is clear what task to take on, the customer sees where the deadline shift directly depends on it, helps to use safety buffers more correctly than simply multiply the term by pi. Tools: any spreadsheet or special software (not known to me).
We do not welcome the drafting of TORs. Sometimes the customer comes with him, but we know that it can survive to the end of development unchanged in only one case: everyone resists changes to the last, even if they understand that what is written in the statement of work is no longer relevant.
Instead, we allow the possibility of changing functionality on the go. A brilliant idea may come to the customer at night and he runs with her to us. With SCRUM, for example, this idea will go to the backlog of tasks. They will not take up it before the next sprint and will not even possibly discuss it. We inform the customer that his idea can make changes in 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 priority list. If all this does not cool his ardor and he really believes that this idea is worth discussing and implementing, we are engaged in it.
Сейчас уже не получается применять какую-либо методологию в чистом виде. Нужно изучать чужой опыт, интересоваться методиками, не относящимися к программированию напрямую, и черпать оттуда инструментарий и идеи.
Ну и нужно понимать, что никакие методологии и процессы не помогут делать качественные продукты. Придется включать голову и развивать ответственность в себе! Каждому.
P.S. В статье нет возможности рассказать о каждой из методик подробно. Поможет Google и просмотр видео-выступлений автора, где все это было рассказано чуть подробнее — вдруг кому-то не надоело читать :-)
Выступление на эту же тему, включая ответы на вопросы аудитории, есть поясняющие картинки и некоторые подробности по методикам:
Подробнее о практиках типа Story mapping, бумажном прототипировании и т.д.
One of the most pressing issues of custom development is the correct assessment of the terms and budget of the project, so that the work is completed, the customer is satisfied, and the profit is adequate. Over the course of 3 years, we have tried different ways of working and approaches to solving the problem of deadlines and budgets. Re-read a bunch of books, attended dozens of conferences, webinars, etc. Under the cut is the description of the solution that we have now found to deliver maximum benefit to the customer for an interesting budget for us.
First, we have to talk about the way we came to this.
Classical outsourcing - sale of watches or fixed price
Sale of watches: the client sits on an “endless” contract, the team gradually increases, and possibly the rates. Often, someone distributes the work on the part of the customer, the development team does not have its own analysts, Cons: it’s rarely possible to raise rates, sometimes it turns out that the project does not take off and everyone is demoralized, people get bored and often have to rotate the team. It is advantageous if there are mediocre programmers, without stars, but really interesting and complex projects cannot be done with such a team.
Small fixed price at oDesk: small work in a short time, well suited for rock stars who can work alone and quickly. Cons: stars quickly realize that they themselves can work this way and go to freelance.
Fixed Price: make a project on TK for the agreed period a team in which there are different roles. An ancient classic - to analyze, evaluate, program, test, implement everything and ... fly out of the budget.
Methods of struggle:
- splitting into short iterations,
- risk assessment, probabilistic methods, multiplying estimates by "pi", etc.,
- a combination of both options is short iterations, each of which uses estimates of development speed and uses risk management using probabilistic methods, i.e., for example, SCRUM.
Down with the cult of cargo - why SCRUM in its pure form did not work in our team
We tried on several projects, even wrote in the criteria for selecting projects - the willingness of the customer to work on SCRUM. Cons: it’s difficult to explain to the customer why he needs all this, it’s quite difficult to properly organize the process in a team, the estimation of velocity in conditions of changing teams is inadequate, many customers have a prejudice. We could not find the answer to the main question of the customer: “How many sprints will be required before the completion of the project?”
What did SCRUM take into service: the process of continuous improvement through retrospectives - until the process change; acceptance criteria for features compiled with the customer; prioritization of features; planning pocker for evaluation.
Manufacturing happiness with industrial methods - why we don’t just want to write code for money
There are many people who work work at work, do what they say, and find pleasure in something else - games, hobbies, binges in the end. My partner nem and I don’t belong to these, and therefore, over time, I came to the conclusion that I want to see people on the team who enjoy what they do.
And when an intelligent person - especially a developer in the broadest sense of the word - wants to enjoy his work, first of all he wants to understand that what he does makes sense and someone needs it. (There is a degenerate case - an ultra-geek digs into technology headlong, technology for technology's sake, and all this is necessary only for him and a narrow group of like-minded people).
Since we work for someone else’s business, then what we do should be beneficial to this business. Or, if it is a product for ordinary Internet users - like and benefit them.
As soon as the main focus instead of technology and processes is the happiness of users, developers and the customer - in that order, the look changes radically. I don’t want to think completely in terms of ass hours. Basically, the projects that we like belong to the category of team fixed price.
To make users happy, you need to be able to make good interfaces and think about each feature in terms of benefits, convenience, and beauty, finally. The team begins to think about marketing in its best form: just make a good product and users themselves will spread the rumor.
For a team to be happy, they must know that someone needs all this, the more lively the users will be, the better. The team should see the customer, whose eyes are burning from a product that adequately perceives reasonable arguments, and does not measure everything in terms of “this is 100 bucks more, remove”. And an important point - the team should not work in a constant deadline and breakdown deadlines, there should be normal weekends and evenings. But if someone is so passionate that even at home he takes on the project - this is normal, then like it. But it’s better to explain that you can go this far and try to limit everyone to working time.
If we are talking about the happiness of the customer, the skill of “meeting deadlines and the budget” is important. From all of the above, we have a certain way of working with a project that we are trying to apply recently. And this is not some kind of methodology - it is common sense + understanding of the customer’s business, which forces them to choose 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 our own.
Practices that we apply now
1. FFF - fixed price, fixed timing, flexible scope
FFF can be seen as a high-level way to stay within the deadlines and budget, guaranteeing the customer that for the money that he pays and the time that he is willing to allocate, he will get the best that could be done.
One of the basic principles here is the already mentioned YAGNI. For each feature and wish, priorities are clarified, importance for the product as a whole, etc. At this moment, any person in the team has the right to ask the questions “Why is this feature needed?”, “Why is it important to release it in this release?” And “What will the product lose if this feature is not / will be later?”
The principle can be applied to any creative work, in particular, Andrei Shapiro toldhow to make slides for a report in a very limited time. In general, the allocation of finite time to solve a problem makes us look for a simple way to solve it, sometimes going far beyond programming.
Further techniques help achieve this goal.
2. MVP - only the necessary and nothing more
So - we want to understand what and for whom we are doing in order to participate in discussions with the customer about the functionality on equal or almost equal terms. For this, methods are used that are usually advised to be used in business planning (startups, for example, are very fond of them).
- 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 do this project at all. Tools: sheets of A0 format, 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, focus on their “opinion”, imagine how they will respond. Tools: A4 sheets, pencils, pens.
- Impact mapping is a mind-map of business goals, where we try to imagine how our people and how to 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 on the part of users. Already existing persons are taken, from which we select the most important, according to Impact mapping, write down a high-level functional for each of them. Then we describe the minimum required set of feature attributes, which will make the product valuable to the person. And we supplement the picture with development options that only come to mind in a limited time. Purpose: to determine the scope of the first release, it is also a minimally valuable product or MVP. Tools: board, sheets A0, stickers, pens, markers; Any spreadsheet will do.
Why are stickers and board better? Everyone gets together, involved in the process.
3. Customer journey - roles, contexts, moods
We make a draft version of navigation on pages (if web) or transitions of the client between stages in other cases. We take all the people who have been identified as important, and do 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 page content motivates the user to continue communicating 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 for understanding the functionality - and even if there is a specification - is the prototyping of interfaces. Even if the team does not have a UX specialist, everyone can draw rectangles on paper. It is very important to agree with the customer a common understanding of the interface.
Why do not we work with the designer from the first day of work on the project? Designers are very fond of delving into little things and working out layouts to the end, in color, with all the shadows and gradients. They are artists, but we have a different goal - we need to understand, quickly by drawing 5 options for the location of blocks on the page, whether the layout corresponds to business needs. Despite the fact that the progressive Jpeg method is promoted by one of the most famous design studios - the Artem Gorbunov Bureau - not every designer is ready to change the paradigm. Two Bureau designers known to me, who perfectly understand this, use and train others, have higher technical or physical-mathematical education.
The essence of the method is the gradual addition of detail. With regard to web development: first, only a general outline of pages and a navigation scheme, then detailed layouts and layout, then implementation. Important: the process of gradual improvement and detail goes through all the pages together, and not one at a time. If you have the opportunity and time, you can play with the team, teams of other projects, the customer in an interactive game with paper prototypes.
Purpose: coordination of a high-level understanding of the interface, involving the customer in the creative process - having put a piece of soul into the models, 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 compiled. Now it is important to determine the priority order of all features together with the customer. And to highlight part of those that are not strictly mandatory, we recall YAGNI again. It is these features that will go under the knife if, for some reason, the development does not fit into the allotted time.
Until now, we have demanded concessions only on the part of the customer - we expect him to agree to reduce functionality, to be loyal to our questions about goals and meaning, to understand the objective reasons why something may not be done. And what do we do ourselves in order to be in time as much as possible without sacrificing quality?
We try to use Goldratt's theory of constraints to optimize the development process. We determine the critical path, lay the buffers wherever required. The diagram also shows the places where customer participation is needed - answers to questions, provision of materials, etc. Purpose: at every moment it is clear what task to take on, the customer sees where the deadline shift directly depends on it, helps to use safety buffers more correctly than simply multiply the term by pi. Tools: any spreadsheet or special software (not known to me).
6. Readiness for change
We do not welcome the drafting of TORs. Sometimes the customer comes with him, but we know that it can survive to the end of development unchanged in only one case: everyone resists changes to the last, even if they understand that what is written in the statement of work is no longer relevant.
Instead, we allow the possibility of changing functionality on the go. A brilliant idea may come to the customer at night and he runs with her to us. With SCRUM, for example, this idea will go to the backlog of tasks. They will not take up it before the next sprint and will not even possibly discuss it. We inform the customer that his idea can make changes in 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 priority list. If all this does not cool his ardor and he really believes that this idea is worth discussing and implementing, we are engaged in it.
Summary
Сейчас уже не получается применять какую-либо методологию в чистом виде. Нужно изучать чужой опыт, интересоваться методиками, не относящимися к программированию напрямую, и черпать оттуда инструментарий и идеи.
Ну и нужно понимать, что никакие методологии и процессы не помогут делать качественные продукты. Придется включать голову и развивать ответственность в себе! Каждому.
P.S. В статье нет возможности рассказать о каждой из методик подробно. Поможет Google и просмотр видео-выступлений автора, где все это было рассказано чуть подробнее — вдруг кому-то не надоело читать :-)
Выступление на эту же тему, включая ответы на вопросы аудитории, есть поясняющие картинки и некоторые подробности по методикам:
Подробнее о практиках типа Story mapping, бумажном прототипировании и т.д.