Implementation Experience Getting Real. Part 2 of 2
The second, final part of the article about the experience of implementing the Getting Real approach from 37signals by the example of our company. Start published yesterday .
One of the drawbacks of a small company is the inability to quickly complete a large amount of work. For example, if we are preparing a new version of a product that should include a large number of global changes, with a large team we can do it much faster than with a small one. And if we are small, then the product’s output will be delayed, competitors will release analogues of our innovations faster, some partners, we’ll be tired of waiting, will go to competitors.
In fact, by analogy with the well-known proverb “beer in the morning is not only harmful, but also beneficial”, limited size helps. Not being able to do whatever we want, we are forced to somehow get out. Break tasks into small pieces, leave less important work for later, look for ways to achieve the goal faster and better. This helps to significantly increase work efficiency and efficiency.
When we decided on the composition of version 4.5, we gathered ideas and wishes from three sources: our partners, our employees and management. Only large modules scored 18 pieces. According to our preliminary estimates, they would have to be developed at least a year (and now we understand that it would have been much longer). Then we came up with an assessment method that allowed us to decide what we do and what we put off “for later”.
The method is very simple and unscientific. We formulated three criteria by which we will evaluate each task, and each task was given points from zero to three. These are the criteria:
As a result, based on the total of eighteen points, we selected eight that received the highest points, after discussions we threw out three more and got five, which we started to develop. Here they are: new modules “Minimagazin”, “Basket of deleted objects”, “My Account”, a complete alteration of the module “Site Search”, a platform for embedding widgets of third-party services. Now we can already say that of these, only one point did not fully meet our expectations (this is the “Cart” module, which turned out to be not as popular as we thought). And of the remaining thirteen tasks, we released two in the next version 4.6, we will implement two in the near future, and the remaining nine have decided not to do so far, because according to common sense, they are not as relevant as some tasks that have appeared recently.
And what would happen if we, our staff, would allow us to realize all eighteen points? Half of our time would be spent on what ultimately turned out to be useless, or maybe even harmful, complicating product management. We would get a little more useful, spending a lot more money. And all new tasks would become a long line.
As I wrote above, the small size of the company helps employees to develop professionally. Limitations contribute to this no less. At the beginning of this year, we faced the need to develop an interface for one by-product, which we plan to release next year. This task is not of the most urgent, there was enough time. We could hire a professional interface designer, but we do not know how to evaluate the professionalism of such specialists. We could order this work of a specialized company, but their prices are quite bite.
Then the person involved in the development of technical specifications and having design experience began to study the principles of interface design. I read several books and articles and got started. The interface was redesigned and adjusted several times, and even now changes are being made to it, but we got what we wanted, and the employee received professional skill. Of course, we can say that a couple of books will not make a person a professional, and he can not be compared with a specialist who has been dealing with this issue for years. This is so, we risked a bad result, saving on experience. But in our case, we give the intermediate steps to an audit of one of the leading Russian companies in the field of interface design, which corrects our mistakes.
And now we are much better at interface design and the next such task will be easier.
Constraints also help the quality of our work. Our main competitor in the market, a company larger than us, of size, in addition to the site management system, produces several more types of products. Since the launch and maintenance of a new product requires large investments, we did not repeat the steps of a competitor, focusing on the development of the main product, because we have nothing else to do. A “narrow” product is much easier to control, both at the design stage, and at the sales stage, and in support.
It goes without saying that limitations do not imply only benefits. If there is more money or workers or marketing tools, this is generally better. Increasing profits is our main goal, as with any commercial company. We often have situations when, due to limited resources, we cannot afford to do what we want: quickly launch a large functional, sponsor an interesting conference, order a large advertising campaign. We are trying to approach this issue philosophically. If you really need to - you can exert yourself a little and find money in a reasonable amount. And if it doesn’t work out - well, the next time it will work out, but for now we are learning how to more effectively manage the resources available to us.
The year before last, I drafted a report entitled “Terms of Reference - the cornerstone of the project” and read it in several cities. The main idea of the report: write as detailed a technical assignment as possible, coordinate it with all interested parties, and in the future do not go a step away from it.
Now I am not so sure of the correctness of this approach. At least for internal projects (those that are created for themselves, and not for a third-party customer), this is definitely not the case.
After reading the GR chapter on specifications, I decided to conduct a retrospective of several recently written technical assignments on the topic of how much they were in demand. It turned out that 37signals were absolutely right: almost all the time that I spent on compiling TK, lists of functional elements, flowcharts and data circuits was wasted because nobody really used them. The last example is the technical task for the search module, where I described in detail the operation scheme, data structure, interaction interfaces with other modules. I did this with great care, as the module was written by a remote developer. As a result, only those parts where the module control interface was described were useful to him, that is, the settings and output screens. He looked through the rest of the chapters, but did it his own way; he didn’t even read the chapter on database structure. That is, 80 percent of the document could be reduced by writing in general terms what the module was supposed to do, as well as by drawing prototypes of screens.
Since then, we have written extremely few documents in detail, except when it is really needed, for example, an API description. It’s much more efficient to just draw what should work out and write briefly (or maybe even tell) your vision of how it should all work. It is too early to make global assessments, but interim results indicate that the quality has not deteriorated. And time has become free.
Speaking about specifications, one cannot but say about the problem of growth. Almost all the designers and developers I know consider it good practice to lay the growth in the architecture of the product so that it does not fall and does not become uncomfortable when it is used not by tens, but by hundreds of thousands of users or when the number of stored objects will be in the millions of documents. Getting Real authors advise you to forget about it until it happens. This problem is a pleasant problem, but most companies never achieve such serious growth. Why waste time on something that doesn't come in handy? And if you still come in handy - well, then you need to think about it.
We try not to be distracted by such things, just keeping in mind how approximately we will act when such a situation occurs. If we have a user who, for these reasons, our product does not fit, we will advise him another product. Or we will give advice to its developers on how to “finish” our product for its tasks (this has already happened more than once). And if the flow of such appeals is tangible, then we will deal with this problem closely.
And finally, the final GR thesis on specifications: forget about the little things. What specific points will be in the settings of this screen, what distance will there be between the previews of images, how many lines in the list show data - you don’t need to think about it until such a question really arises. As our own, albeit not very long, practice of following this advice shows, this is indeed so. On a live project, even a semi-finished product, making decisions is much easier and more correct than at the design stage.
“No beta is needed. The version must be one. " In our case, it is difficult to do without versioning, since we are not producing a service, but a standalone product. We cannot force users to update their copies, so versioning must be maintained. As for beta, we give the most significant releases to our partner studios for testing, namely in beta status. In our case, versioning has another advantage: marketing. By releasing features and modules as they are created (which is completely correct from the point of view of product development), we lose the opportunity to collect several large changes in one pile, assign a round version number to this, and send out a press release about this, which will be paid much more attention to. This has to be reckoned with.
“Do something and go fast.”This is a perfectly true principle for startups: made a new feature - included in the release / project. But we have not yet succeeded in switching to such a development cycle. Part of the reasons is objective: we are not a startup, the product is big enough, with a long history. And the subjective reason is that both we and our partners are accustomed to a certain development cycle. Breaking yourself is very difficult.
"Make a choice. Give up settings. ”Programmers love settings, and users love profiles (groups of predefined settings). Developing, for example, the “News” component, the programmer will want to enter the settings “whether to display an announcement”, “show a page listing”, “put a link in the full text on the heading or the word“ in more detail ”. The user is more convenient to choose from profiles: full or short. And the user is right. We have not yet managed to defeat the settings - we consider our product to be very flexible and do not want to deprive it of this property. Last year, we introduced the concept of “component templates” into the system, which partially solves this problem. So in this aspect we are still halfway.
“Do not share development and support.”Separation from the reality of developers is bad. When you, from a site developer, have retrained as a CMS developer, you stop thinking like the people for whom you are making a product. The combination of development and support helps to offset the shortcomings of this transformation. On the other hand, communication in support makes the programmer switch frequently, breaks his rhythm, creates discomfort. Therefore, we still try to separate development and support. On the other hand, we do not mind if one of our employees works part-time by creating websites (without prejudice to the work, of course).
“Say no to users.”... when they ask for innovations. In theory, this is correct. If we make a product, we should know better than the rest what it should be like, otherwise we simply cannot make it innovative and better. Users (and partners) want to solve their current needs, and we must do what is relevant in the future (even better if we do not guess the trends and create them - Apple will not let us lie). In our case, we depend too much on the satisfaction of our partners (sales through web studios and freelancers account for more than 90% of our turnover) to methodically ignore their daily requirements. Therefore, often we have to maneuver between our views and the vision of partners.
"Create a product that does not require training."And again, in theory, this is wonderful, but for us (the site management system) it is difficult to implement. Online site designers should strive for this, because they are focused on end users, but the products of our class are intended for developers. Without studying documentation, video tutorials, and consulting with a support service, a developer can only make a template project without using the capabilities that the system API gives him.
We do not perceive GR as an interesting toy or another newfangled management practice. 12 years of life is a serious period, during which time companies either grow into large corporations, or die, or stagnate. The reason for stagnation is usually the reluctance or inability of management to change the usual principles of work, to adapt to a changing market. Routine work, puffy documents, long projects contribute very well to this. GR helps in the first place to get rid of unnecessary and secondary, not to lose interest in your project, not to stop in personal and professional development.
Speaking about the past year: I can’t say how many percent increased work efficiency or how many man-hours we saved after implementing GR. The main effect is at the level of sensations. For example:
Restrictions help
One of the drawbacks of a small company is the inability to quickly complete a large amount of work. For example, if we are preparing a new version of a product that should include a large number of global changes, with a large team we can do it much faster than with a small one. And if we are small, then the product’s output will be delayed, competitors will release analogues of our innovations faster, some partners, we’ll be tired of waiting, will go to competitors.
In fact, by analogy with the well-known proverb “beer in the morning is not only harmful, but also beneficial”, limited size helps. Not being able to do whatever we want, we are forced to somehow get out. Break tasks into small pieces, leave less important work for later, look for ways to achieve the goal faster and better. This helps to significantly increase work efficiency and efficiency.
When we decided on the composition of version 4.5, we gathered ideas and wishes from three sources: our partners, our employees and management. Only large modules scored 18 pieces. According to our preliminary estimates, they would have to be developed at least a year (and now we understand that it would have been much longer). Then we came up with an assessment method that allowed us to decide what we do and what we put off “for later”.
The method is very simple and unscientific. We formulated three criteria by which we will evaluate each task, and each task was given points from zero to three. These are the criteria:
- If we do this, will it increase our sales? 0 - most likely not, 1 - unlikely, but maybe 2 - most likely yes, 3 - definitely yes.
- How significant is an informational occasion to turn out from this, can we be able to interest potential partners and observers by the presence of this functionality?
- How fast can we do this? 0 - several months, 1 - a month or two, 2 - three to four weeks, 3 - up to two weeks.
| Functional | Money | Info line | Speed | Total |
|---|---|---|---|---|
| New Search Module | 2 | one | 0 | 3 |
| Module "minimagazin" | 3 | 2 | one | 6 |
| Module "My Account" | 2 | 2 | one | five |
| Widget embedding platform | 2 | 2 | one | five |
| Changes to the Tag Cloud module | 0 | 0 | 2 | 2 |
| Alteration of the online store module | 3 | 3 | 0 | 6 |
And what would happen if we, our staff, would allow us to realize all eighteen points? Half of our time would be spent on what ultimately turned out to be useless, or maybe even harmful, complicating product management. We would get a little more useful, spending a lot more money. And all new tasks would become a long line.
As I wrote above, the small size of the company helps employees to develop professionally. Limitations contribute to this no less. At the beginning of this year, we faced the need to develop an interface for one by-product, which we plan to release next year. This task is not of the most urgent, there was enough time. We could hire a professional interface designer, but we do not know how to evaluate the professionalism of such specialists. We could order this work of a specialized company, but their prices are quite bite.
Then the person involved in the development of technical specifications and having design experience began to study the principles of interface design. I read several books and articles and got started. The interface was redesigned and adjusted several times, and even now changes are being made to it, but we got what we wanted, and the employee received professional skill. Of course, we can say that a couple of books will not make a person a professional, and he can not be compared with a specialist who has been dealing with this issue for years. This is so, we risked a bad result, saving on experience. But in our case, we give the intermediate steps to an audit of one of the leading Russian companies in the field of interface design, which corrects our mistakes.
And now we are much better at interface design and the next such task will be easier.
Constraints also help the quality of our work. Our main competitor in the market, a company larger than us, of size, in addition to the site management system, produces several more types of products. Since the launch and maintenance of a new product requires large investments, we did not repeat the steps of a competitor, focusing on the development of the main product, because we have nothing else to do. A “narrow” product is much easier to control, both at the design stage, and at the sales stage, and in support.
It goes without saying that limitations do not imply only benefits. If there is more money or workers or marketing tools, this is generally better. Increasing profits is our main goal, as with any commercial company. We often have situations when, due to limited resources, we cannot afford to do what we want: quickly launch a large functional, sponsor an interesting conference, order a large advertising campaign. We are trying to approach this issue philosophically. If you really need to - you can exert yourself a little and find money in a reasonable amount. And if it doesn’t work out - well, the next time it will work out, but for now we are learning how to more effectively manage the resources available to us.
Do not create specifications
The year before last, I drafted a report entitled “Terms of Reference - the cornerstone of the project” and read it in several cities. The main idea of the report: write as detailed a technical assignment as possible, coordinate it with all interested parties, and in the future do not go a step away from it.
Now I am not so sure of the correctness of this approach. At least for internal projects (those that are created for themselves, and not for a third-party customer), this is definitely not the case.
After reading the GR chapter on specifications, I decided to conduct a retrospective of several recently written technical assignments on the topic of how much they were in demand. It turned out that 37signals were absolutely right: almost all the time that I spent on compiling TK, lists of functional elements, flowcharts and data circuits was wasted because nobody really used them. The last example is the technical task for the search module, where I described in detail the operation scheme, data structure, interaction interfaces with other modules. I did this with great care, as the module was written by a remote developer. As a result, only those parts where the module control interface was described were useful to him, that is, the settings and output screens. He looked through the rest of the chapters, but did it his own way; he didn’t even read the chapter on database structure. That is, 80 percent of the document could be reduced by writing in general terms what the module was supposed to do, as well as by drawing prototypes of screens.
Since then, we have written extremely few documents in detail, except when it is really needed, for example, an API description. It’s much more efficient to just draw what should work out and write briefly (or maybe even tell) your vision of how it should all work. It is too early to make global assessments, but interim results indicate that the quality has not deteriorated. And time has become free.
Speaking about specifications, one cannot but say about the problem of growth. Almost all the designers and developers I know consider it good practice to lay the growth in the architecture of the product so that it does not fall and does not become uncomfortable when it is used not by tens, but by hundreds of thousands of users or when the number of stored objects will be in the millions of documents. Getting Real authors advise you to forget about it until it happens. This problem is a pleasant problem, but most companies never achieve such serious growth. Why waste time on something that doesn't come in handy? And if you still come in handy - well, then you need to think about it.
We try not to be distracted by such things, just keeping in mind how approximately we will act when such a situation occurs. If we have a user who, for these reasons, our product does not fit, we will advise him another product. Or we will give advice to its developers on how to “finish” our product for its tasks (this has already happened more than once). And if the flow of such appeals is tangible, then we will deal with this problem closely.
And finally, the final GR thesis on specifications: forget about the little things. What specific points will be in the settings of this screen, what distance will there be between the previews of images, how many lines in the list show data - you don’t need to think about it until such a question really arises. As our own, albeit not very long, practice of following this advice shows, this is indeed so. On a live project, even a semi-finished product, making decisions is much easier and more correct than at the design stage.
What we did not succeed
“No beta is needed. The version must be one. " In our case, it is difficult to do without versioning, since we are not producing a service, but a standalone product. We cannot force users to update their copies, so versioning must be maintained. As for beta, we give the most significant releases to our partner studios for testing, namely in beta status. In our case, versioning has another advantage: marketing. By releasing features and modules as they are created (which is completely correct from the point of view of product development), we lose the opportunity to collect several large changes in one pile, assign a round version number to this, and send out a press release about this, which will be paid much more attention to. This has to be reckoned with.
“Do something and go fast.”This is a perfectly true principle for startups: made a new feature - included in the release / project. But we have not yet succeeded in switching to such a development cycle. Part of the reasons is objective: we are not a startup, the product is big enough, with a long history. And the subjective reason is that both we and our partners are accustomed to a certain development cycle. Breaking yourself is very difficult.
"Make a choice. Give up settings. ”Programmers love settings, and users love profiles (groups of predefined settings). Developing, for example, the “News” component, the programmer will want to enter the settings “whether to display an announcement”, “show a page listing”, “put a link in the full text on the heading or the word“ in more detail ”. The user is more convenient to choose from profiles: full or short. And the user is right. We have not yet managed to defeat the settings - we consider our product to be very flexible and do not want to deprive it of this property. Last year, we introduced the concept of “component templates” into the system, which partially solves this problem. So in this aspect we are still halfway.
“Do not share development and support.”Separation from the reality of developers is bad. When you, from a site developer, have retrained as a CMS developer, you stop thinking like the people for whom you are making a product. The combination of development and support helps to offset the shortcomings of this transformation. On the other hand, communication in support makes the programmer switch frequently, breaks his rhythm, creates discomfort. Therefore, we still try to separate development and support. On the other hand, we do not mind if one of our employees works part-time by creating websites (without prejudice to the work, of course).
“Say no to users.”... when they ask for innovations. In theory, this is correct. If we make a product, we should know better than the rest what it should be like, otherwise we simply cannot make it innovative and better. Users (and partners) want to solve their current needs, and we must do what is relevant in the future (even better if we do not guess the trends and create them - Apple will not let us lie). In our case, we depend too much on the satisfaction of our partners (sales through web studios and freelancers account for more than 90% of our turnover) to methodically ignore their daily requirements. Therefore, often we have to maneuver between our views and the vision of partners.
"Create a product that does not require training."And again, in theory, this is wonderful, but for us (the site management system) it is difficult to implement. Online site designers should strive for this, because they are focused on end users, but the products of our class are intended for developers. Without studying documentation, video tutorials, and consulting with a support service, a developer can only make a template project without using the capabilities that the system API gives him.
Conclusion
We do not perceive GR as an interesting toy or another newfangled management practice. 12 years of life is a serious period, during which time companies either grow into large corporations, or die, or stagnate. The reason for stagnation is usually the reluctance or inability of management to change the usual principles of work, to adapt to a changing market. Routine work, puffy documents, long projects contribute very well to this. GR helps in the first place to get rid of unnecessary and secondary, not to lose interest in your project, not to stop in personal and professional development.
Speaking about the past year: I can’t say how many percent increased work efficiency or how many man-hours we saved after implementing GR. The main effect is at the level of sensations. For example:
- we have ceased to think that our small staff and informal management practices are flaws; it greatly affects self-perception and own motivation, removes false goals
- we have ceased to impose on employees or contractors our vision of the process of their work; if there is no professional trust, it is better not to cooperate at all
- we have become much less concerned with how we look from the side - more important is how we see ourselves
- development has become much more manageable; the time between the formulation of the problem and its solution was reduced significantly, and the quick result is very inspiring
- when designing, the efficiency increased sharply, there was a time for self-education and research