Getting Realization Experience. Part 2 of 2
The second, final part of the article is about the experience of introducing the Getting Real approach from 37signals using the example of our company. Beginning was 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 the product, which 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 will be delayed, competitors will release analogues of our innovations faster, some of the partners, tired of waiting, will go to competitors.
In fact, by analogy with the well-known saying “beer in the morning is not only harmful, but also useful,” limiting the size helps. Not being able to do everything that you want, we have to somehow get out. Break tasks into small pieces, leave less important work for later, look for ways to achieve goals faster and better. This helps to significantly increase work efficiency and efficiency.
')
When we decided on the composition of version 4.5, we collected ideas and suggestions 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 for 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 are doing and what we postpone for later.
The method is very simple and unscientific. We formulated three criteria by which we will evaluate each task, and each task was assigned points from zero to three. These criteria are:
As a result, we chose eight of the highest points in the total of points out of eighteen points, threw out three more after discussions and received five, which we began to develop. Here they are: the new Minimagazin modules, the Trash of deleted objects, the Personal Account, a complete redesign of the Site Search module, a platform for embedding widgets of third-party services. Now we can say that only one point out of them did not fully meet our expectations (this is the “Cart” module, which turned out to be not as popular as we thought). We have released two of the remaining thirteen tasks in the next version, 4.6, we will implement two in the near future, and the remaining nine have decided not to do it yet, because due to common sense they are not as relevant as some of the tasks that have appeared recently.
And what would happen if we had our state allowed us to realize all eighteen points then? Half of our time would have gone to what was ultimately useless, and maybe even harmful, complicating product management. We would get a little more useful, spending a lot more money. And all the new tasks would be in a long line.
As I wrote above, the small size of the company helps employees develop professionally. Restrictions contribute to this no less. At the beginning of this year, we were faced with the need to develop an interface for a single by-product, which we expect to release next year. This task is not the most urgent, there was enough time. We could take on a staff of 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 biting.
Then the person engaged in the development of technical specifications and having experience in design, began to study the principles of interface design. I read several books and articles and began work. The interface was reworked and corrected several times, and even now changes are being made to it, but we got what we wanted, and the employee got the professional skill. Of course, one can say that a couple of books will not make a professional from a person, and he can’t be compared with a specialist who has been working on this issue for years. This is so, we risked getting a bad result, saving on experience. But in our case, we give the intermediate stages 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 versed in the design of interfaces and the next such task will be easier.
Limitations also help the quality of our work. Our main competitor in the market, a company larger than us, in addition to the site management system produces several more types of products. Since both launch and maintenance of a new product require large investments, we did not repeat the competitor’s steps, focusing on the development of the main product, because we have no choice. “Narrow” product control is much easier, and at the design stage, and at the sales stage, and in support.
It goes without saying that restrictions do not imply only advantages. If there is more money or labor or marketing tools, it is generally better. Increasing profits is our main goal, as with any commercial company. We quite often have situations where, due to limited resources, we cannot afford to do what we want: quickly launch a large functionality, sponsor an interesting conference, order a large advertising campaign. We try to approach this issue philosophically. If you really need to - you can do a bit of tension and find money in reasonable amounts. And if it does not work out - well, next time it will turn out, but for now we are learning to more effectively manage the resources available to us.
The year before last, I wrote a report titled “Terms of Reference - the cornerstone of the project” and read it in several cities. The main idea of ​​the report: write as much detailed technical task as possible, coordinate it with all interested persons and do not depart from it in the future.
Now I'm not so sure about the correctness of this approach. At least, for internal projects (those that are created for themselves, and not for an outside 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 how much they were in demand. It turned out that 37signals are absolutely right: almost all the time that I spent on drawing up TK, lists of functional elements, flowcharts and data schemes was wasted because no one used them in reality. The last example is a technical assignment for a search module, where I described in detail the scheme of work, the data structure, the interfaces of interaction with other modules. I did this with utmost care, because The module was written by a remote developer. As a result, only those parts were useful to him where the interface for managing the module was described, that is, the settings and output screens. He looked through all the other chapters, but did it in his own way; he did not 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 drawing screen prototypes.
Since then, we have been writing very few documents in detail, except when it is really necessary, for example, a description of the API. It is much more effective to simply draw what should turn out and briefly write (and maybe even tell) your vision of how this all should work. It is too early to make global assessments, but the interim results suggest that the quality has not become worse. And time is freed.
Speaking of specifications, one can not say about the problem of growth. Practically all designers and developers known to me consider it a good way to lay growth in the product architecture so that it does not fall and become inconvenient when it will be used not by tens but by hundreds of thousands of users or when the number of stored objects will be calculated in millions of documents. Getting Real authors advise 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 is not useful? And if it still comes in handy - well, then it’s necessary to think about it.
We try not to be distracted by such things, just keeping in mind about how we will act when this situation happens. If we have a user who, for these reasons, our product does not fit, we will advise him a different product. Or we will give advice to its developers, how to “finish” our product for its tasks (this has happened before). And if the flow of such complaints is palpable, then we will deal with this problem closely.
Finally, the final GR thesis about the specifications: forget about the little things. What specific items will be in the settings of this screen, what is the distance between the preview of the images, since the lines in the list show data - you don’t need to think about it until the question really comes up. As our own, even if not very long practice of following this advice, shows, this is true. On a live project, even if a semi-finished product, making decisions is much easier and more correct than at the design stage.
“No beta versions needed. Version must be one. In our case, it is difficult to do without versioning, since we produce not a service, but a standalone product. We cannot force users to update their copies, therefore versioning must be supported. As for the beta - the most significant releases we give to testing our studios-partners, namely in the status of the beta version. In our case, versioning has another advantage: marketing. By releasing features and modules as they are created (which is quite correct in terms of product development), we are deprived of the opportunity to collect several big changes in one heap, assign this all a round version number and send out a press release about it, which will be paid much more attention. This has to be considered.
"Do something and go fast." This is absolutely the right 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. Some of the reasons are objective: we are not a startup, the product is quite large, with a long history. And the subjective reason is that both we and our partners are accustomed to a specific development cycle. Breaking yourself is very difficult.
"Make a choice. Discard the settings. Programmers love settings, and users love profiles (groups of predefined settings). Developing, for example, the component “News”, the programmer will want to enter the settings “whether to display an announcement”, “whether to show page listing”, “put the link in the full text on the title or the word“ more ”. 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 very flexible and do not want to deprive it of this property. Only last year we introduced the concept of “component templates” into the system, which partly solves this problem. So in this aspect we are still halfway there.
“Don't share development and support.” The detachment from the reality of the developers is bad. When you from a website developer turned into a CMS developer, you stop thinking like those for whom you make a product. The combination of development and support helps to level the shortcomings of this transformation. On the other hand, communication in support causes the programmer to switch frequently, tearing his rhythm, creating discomfort. Therefore, we still try to separate development and support. On the other hand, we do not mind if any of our employees work on creating websites (not to the detriment of work, of course).
“Say no to users.” ... when they ask for innovations. In theory, this is correct. If we make a product, we need to know better than others what it should be, otherwise we simply cannot make it innovative and better. Users (and partners) want to solve their current needs, and we have to do what is relevant in the future (even better, if we do not guess the trends, and create them - Apple will not let you lie). In our case, we depend too much on the satisfaction of our partners (sales through web-studios and freelancers make up more than 90% of our turnover) in order to systematically ignore their daily requirements. Therefore, we often 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) 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 the documentation, video tutorials, consulting the support service, the developer will be able to do only a sample project, without using the features that the system's API gives him.
We do not perceive GR as an interesting toy or another new-fashioned management practice. 12 years of life is a serious time, during which time companies either grow into large corporations, or die or stagnate. The reason for stagnation is usually the unwillingness or inability of management to change the usual principles of work, to adapt to a changing market. Routine work, plump documents, long projects contribute very well to this. GR helps to get rid of unnecessary and minor things first, not to lose interest in your project, not to stop in personal and professional development.
Speaking of the past year: I can not say how many percent increased work efficiency or how many man-hours we saved after the introduction of 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 the product, which 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 will be delayed, competitors will release analogues of our innovations faster, some of the partners, tired of waiting, will go to competitors.
In fact, by analogy with the well-known saying “beer in the morning is not only harmful, but also useful,” limiting the size helps. Not being able to do everything that you want, we have to somehow get out. Break tasks into small pieces, leave less important work for later, look for ways to achieve goals faster and better. This helps to significantly increase work efficiency and efficiency.
')
When we decided on the composition of version 4.5, we collected ideas and suggestions 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 for 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 are doing and what we postpone for later.
The method is very simple and unscientific. We formulated three criteria by which we will evaluate each task, and each task was assigned points from zero to three. These criteria are:
- If we do this, will it increase our sales? 0 - most likely not, 1 - hardly, but maybe 2 - more likely yes, 3 - certainly yes.
- How significant will this informational occasion be? Can we be able to interest potential partners and observers in the presence of this functionality?
- How fast can we do this? 0 - a few months, 1 - a month or two, 2 - three or four weeks, 3 - up to two weeks.
| Functional | Money | Info wire | Speed | Total |
|---|---|---|---|---|
| New search module | 2 | one | 0 | 3 |
| Module "Minimagazine" | 3 | 2 | one | 6 |
| Module "My Account" | 2 | 2 | one | five |
| Widget Embedding Platform | 2 | 2 | one | five |
| Changes in the "Tag Cloud" module | 0 | 0 | 2 | 2 |
| Alteration of the Online Store module | 3 | 3 | 0 | 6 |
And what would happen if we had our state allowed us to realize all eighteen points then? Half of our time would have gone to what was ultimately useless, and maybe even harmful, complicating product management. We would get a little more useful, spending a lot more money. And all the new tasks would be in a long line.
As I wrote above, the small size of the company helps employees develop professionally. Restrictions contribute to this no less. At the beginning of this year, we were faced with the need to develop an interface for a single by-product, which we expect to release next year. This task is not the most urgent, there was enough time. We could take on a staff of 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 biting.
Then the person engaged in the development of technical specifications and having experience in design, began to study the principles of interface design. I read several books and articles and began work. The interface was reworked and corrected several times, and even now changes are being made to it, but we got what we wanted, and the employee got the professional skill. Of course, one can say that a couple of books will not make a professional from a person, and he can’t be compared with a specialist who has been working on this issue for years. This is so, we risked getting a bad result, saving on experience. But in our case, we give the intermediate stages 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 versed in the design of interfaces and the next such task will be easier.
Limitations also help the quality of our work. Our main competitor in the market, a company larger than us, in addition to the site management system produces several more types of products. Since both launch and maintenance of a new product require large investments, we did not repeat the competitor’s steps, focusing on the development of the main product, because we have no choice. “Narrow” product control is much easier, and at the design stage, and at the sales stage, and in support.
It goes without saying that restrictions do not imply only advantages. If there is more money or labor or marketing tools, it is generally better. Increasing profits is our main goal, as with any commercial company. We quite often have situations where, due to limited resources, we cannot afford to do what we want: quickly launch a large functionality, sponsor an interesting conference, order a large advertising campaign. We try to approach this issue philosophically. If you really need to - you can do a bit of tension and find money in reasonable amounts. And if it does not work out - well, next time it will turn out, but for now we are learning to more effectively manage the resources available to us.
Do not create specifications
The year before last, I wrote a report titled “Terms of Reference - the cornerstone of the project” and read it in several cities. The main idea of ​​the report: write as much detailed technical task as possible, coordinate it with all interested persons and do not depart from it in the future.
Now I'm not so sure about the correctness of this approach. At least, for internal projects (those that are created for themselves, and not for an outside 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 how much they were in demand. It turned out that 37signals are absolutely right: almost all the time that I spent on drawing up TK, lists of functional elements, flowcharts and data schemes was wasted because no one used them in reality. The last example is a technical assignment for a search module, where I described in detail the scheme of work, the data structure, the interfaces of interaction with other modules. I did this with utmost care, because The module was written by a remote developer. As a result, only those parts were useful to him where the interface for managing the module was described, that is, the settings and output screens. He looked through all the other chapters, but did it in his own way; he did not 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 drawing screen prototypes.
Since then, we have been writing very few documents in detail, except when it is really necessary, for example, a description of the API. It is much more effective to simply draw what should turn out and briefly write (and maybe even tell) your vision of how this all should work. It is too early to make global assessments, but the interim results suggest that the quality has not become worse. And time is freed.
Speaking of specifications, one can not say about the problem of growth. Practically all designers and developers known to me consider it a good way to lay growth in the product architecture so that it does not fall and become inconvenient when it will be used not by tens but by hundreds of thousands of users or when the number of stored objects will be calculated in millions of documents. Getting Real authors advise 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 is not useful? And if it still comes in handy - well, then it’s necessary to think about it.
We try not to be distracted by such things, just keeping in mind about how we will act when this situation happens. If we have a user who, for these reasons, our product does not fit, we will advise him a different product. Or we will give advice to its developers, how to “finish” our product for its tasks (this has happened before). And if the flow of such complaints is palpable, then we will deal with this problem closely.
Finally, the final GR thesis about the specifications: forget about the little things. What specific items will be in the settings of this screen, what is the distance between the preview of the images, since the lines in the list show data - you don’t need to think about it until the question really comes up. As our own, even if not very long practice of following this advice, shows, this is true. On a live project, even if a semi-finished product, making decisions is much easier and more correct than at the design stage.
What we did not work
“No beta versions needed. Version must be one. In our case, it is difficult to do without versioning, since we produce not a service, but a standalone product. We cannot force users to update their copies, therefore versioning must be supported. As for the beta - the most significant releases we give to testing our studios-partners, namely in the status of the beta version. In our case, versioning has another advantage: marketing. By releasing features and modules as they are created (which is quite correct in terms of product development), we are deprived of the opportunity to collect several big changes in one heap, assign this all a round version number and send out a press release about it, which will be paid much more attention. This has to be considered.
"Do something and go fast." This is absolutely the right 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. Some of the reasons are objective: we are not a startup, the product is quite large, with a long history. And the subjective reason is that both we and our partners are accustomed to a specific development cycle. Breaking yourself is very difficult.
"Make a choice. Discard the settings. Programmers love settings, and users love profiles (groups of predefined settings). Developing, for example, the component “News”, the programmer will want to enter the settings “whether to display an announcement”, “whether to show page listing”, “put the link in the full text on the title or the word“ more ”. 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 very flexible and do not want to deprive it of this property. Only last year we introduced the concept of “component templates” into the system, which partly solves this problem. So in this aspect we are still halfway there.
“Don't share development and support.” The detachment from the reality of the developers is bad. When you from a website developer turned into a CMS developer, you stop thinking like those for whom you make a product. The combination of development and support helps to level the shortcomings of this transformation. On the other hand, communication in support causes the programmer to switch frequently, tearing his rhythm, creating discomfort. Therefore, we still try to separate development and support. On the other hand, we do not mind if any of our employees work on creating websites (not to the detriment of work, of course).
“Say no to users.” ... when they ask for innovations. In theory, this is correct. If we make a product, we need to know better than others what it should be, otherwise we simply cannot make it innovative and better. Users (and partners) want to solve their current needs, and we have to do what is relevant in the future (even better, if we do not guess the trends, and create them - Apple will not let you lie). In our case, we depend too much on the satisfaction of our partners (sales through web-studios and freelancers make up more than 90% of our turnover) in order to systematically ignore their daily requirements. Therefore, we often 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) 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 the documentation, video tutorials, consulting the support service, the developer will be able to do only a sample project, without using the features that the system's API gives him.
Conclusion
We do not perceive GR as an interesting toy or another new-fashioned management practice. 12 years of life is a serious time, during which time companies either grow into large corporations, or die or stagnate. The reason for stagnation is usually the unwillingness or inability of management to change the usual principles of work, to adapt to a changing market. Routine work, plump documents, long projects contribute very well to this. GR helps to get rid of unnecessary and minor things first, not to lose interest in your project, not to stop in personal and professional development.
Speaking of the past year: I can not say how many percent increased work efficiency or how many man-hours we saved after the introduction of GR. The main effect is at the level of sensations. For example:
- we stopped thinking that our small staff and unformalized management methods are flaws; it greatly affects self-perception and self-motivation, removes false targets
- we stopped imposing our vision of the process of their work on employees or contractors; if there is no professional trust, then it is better not to cooperate at all
- we have become much less concerned with how we look from the outside - more importantly how we see ourselves
- development has become much more manageable; the time between the statement of the problem and its solution was reduced by several times, and the quick result is very much inspiring
- when designing, efficiency increased dramatically, there was a time for self-education and research
Source: https://habr.com/ru/post/133850/
All Articles