📜 ⬆️ ⬇️

Getting Realization Experience. Part 1 of 2

A year ago I read the book Getting Real by 37signals . She was very impressed with me, and I decided that it was worth trying this approach in our company, which I did right from the beginning of 2011. This article is a kind of report on the annual implementation of Getting Real in a single company. The report is of course interim, because the real effect of a change in approach to work (and Getting Real is not a management or development technique, but an approach) can be judged after a more tangible period of time; besides, we could not apply all the principles of the approach. I will tell about it too.

I will not retell the content of the book; if you have not read it, but are interested in managing development, be sure to read it, it is laid out in the public domain . The book is quite short. If you like it - I advise you to read the Rework from the same 37signals, this book is already larger.

First of all, I must say that Getting Real is most effective in startups and start-up teams. NetCat has 12 years of existence behind it, a lot of code written by different people at different times, established business processes and a large affiliate network. On the one hand, it hinders: it is easier to re-create than to rebuild. And on the other hand, having a lot of experience behind them, it is much easier to compare the advantages and disadvantages of different approaches and techniques.
')
Do not take this article as a guide for implementation or a master class: I just share my own experience in the format "thesis GR - as we understood it and realized what came of it."

Stay small


Every company employee must make a profit, directly or indirectly. So, the more employees, the more profit - with the proper organization of their work. This rule does not always work, especially in the IT industry. There are many examples where small teams of enthusiasts ate large chunks of the market from the giants of the industry, and even created their own segment. Large companies lack a priori mobility, but there is a lot of bureaucracy, and also:
Small companies in an effort to become big try to copy these attributes without thinking that it only hinders them. After all, if you think about it, it becomes clear that complex workflow schemes, the cycle of making and approving decisions, clear salary rates, formalized reports in large companies are not the way to develop them, but just the tools needed to not collapse right away tomorrow, having lost controllability. Large companies need these tools solely because of their size. The possibility of abandoning all this is a luxury that only small companies can afford. Since we stopped trying to introduce such entities with us, living and working has become much easier. And the manageability of the company has not deteriorated.

Previously, we always tried to find resources for growth, because there are always more tasks than we could digest. Our product requires constant development, at every moment there are many tasks that need to be addressed: create new modules, improve old ones, produce industry solutions, and so on. So, we need as many programmers as possible. At the same time, potential partners of our company are not only end users of sites, but also website developers, hosting providers, retailers, retail stores. So you need to take more managers and marketers. But what if there is no money for expansion? It turns out a vicious circle?

For some time we have stopped growing. Now the company employs 12 people (at the time of writing this article 11, we have a vacancy of a programmer-trainee): programmers (4), employees of technical support and maintenance (4), managers (3), the designer. Our employees are basically universal; they can, to varying degrees, do the work of their neighbor if he gets sick or goes on vacation. However, we are trying to outsource all non-core work. And sometimes even the profile. Thus, two of the five newly created modules of the NetCat 4.5 version, released in spring 2011, were created by third-party developers. For eight months of 2011, we worked on a subcontract with five companies and nine freelancers. At outsourcing we order:
We would be happy to outsource both support and all development and design, but, unfortunately, this is physically impossible in our case. However, we only do what we can and love, without accompanying bonuses.

Such a structure allows us to be more confident in the future. We have fixed expenses: salary, rent, taxes, etc., which change only when salaries are re-indexed. At the same time, sales can fluctuate greatly; in 2011 alone, the worst month was two times more profitable than the best. Below is a graph of our incomes for 11 months of this year, without absolute figures, as a percentage of the maximum.



This is the specifics of our business, when sales may depend on a very large number of factors that are not always subject to us. And if earlier in one month we could ride like cheese in butter, and in the other we had to delay salaries, then the last months we have been deprived of this headache. The extra money does not go into the pockets of the founders, because there are always enough tasks for an outsourcing. Thus, on the one hand, we live within our means, without attracting loans and outside investors, and on the other, we have the opportunity to develop in a flexible way.

Another major advantage of a small company is transparency. Everyone knows who does what, who to approach with any problem or suggestion. A dissatisfied customer or partner does not have to go through a chain of management levels in order to get his problem across to the director. In the spring of this year there was a case when the easy availability of a manager helped us to get out of an unpleasant situation and not lose a few hundred thousand rubles.

Finally, the small size helps employees develop professionally, brightening the need to do the same job year after year. If there is no staff in the state, for example, a coder who, by the nature of his activity, would have to know Javascript and HTML5, and ordering this work to the side is inexpedient, pushing it onto another will not work, you have to read the specifications, watch examples of someone else's code. It works differently. When once we needed to arrange handouts urgently, it turned out that our freelance designer went on vacation, and we need to urgently look for a new one. But it turned out that one of the managers draws very well. Since then, the majority of printing for us, she draws when it is not at the expense of the main work. Here are a couple of examples:



Less meetings, more freedom


Meetings in the book Getting Real are unequivocally set in a negative light. Meetings over time turn into loss of working time, chewing on unnecessary information, breaking up the working day, etc. We decided to follow the advice of the authors. We carry out general meetings once a week or two, but we do not use them to issue assignments and hear reports. On such a meeting, those who have something to tell, do it in a free form. Tech Support talks about his download, about unusual calls; the management - about the nearest plans and problems, other people - about the upcoming events, the current financial situation, etc. Also at the planning meetings it is discussed whether to buy a tennis table in the office, whether we go together next weekend to the country house to one of us, what needs to be changed the brand of coffee, because this one, which is sour in a coffee machine, etc. Thus, all employees are aware of the general situation in the company, there is no question “who does what” or “why are we doing this”. Each person can express his opinion on any issue, even if he is not within his competence. Although decisions are still made by those responsible for these decisions.

If you want to discuss something specific, then only those who will be useful to it come to the meeting. When a designer has a question for developers about the complexity of implementing some interesting functionality, he calls the lead developer “right now”; if a large number of employees are required to resolve the issue, set the time “in an hour” or “tomorrow”.

We also abandoned the fixed working day for the main part of the staff. We only have three people to be in the office from ten o'clock: the technical support officer on duty, the manager-administrator and the manager for working with partners. These are the roles that are really needed during a common working day. All the others work in the mode that is convenient for them. We were afraid that this would lead to the emergence of “freeloaders” who do nothing but receive their salaries. They really were, but it is very easy to recognize them. However, for them, being in the workplace does not mean efficient work. But the rest feel much more comfortable, and this greatly affects the efficiency of work. If a person likes to sleep a little longer and lie down later, why break it? If an employee wants to write some important part of the program at home, where his colleagues do not interfere with him, why force him to sit in the office?

Hire less and less


For the last year and a half, we have been working exclusively for the intern's position (this is not a dogma, it just happened). All programmers working now in the company came to it precisely as trainees, starting with support services, testing, and helping developers with basic tasks. For us, this strategy is definitely advantageous. We do not encounter other people's habits and approaches to software development, contrary to ours. We always have a reserve that can be quickly activated if the developer decides to leave the company.

Of course, this approach is controversial. Its disadvantage is as follows. Recruiting an inexperienced employee, we actually buy a cat in a bag, because we can make a mistake in assessing its potential. In this case, after a few weeks or months, the person leaves the company, and in fact we have invested time and money in it. This has to be tolerated. Sometimes a reverse situation occurs: an employee grows faster than a company, he is no longer interested in sitting on technical support, and we cannot offer him growth right now. Such situations are even more offensive, but creating jobs for good people is a bad practice.

Be open


We all want to see other people smarter and more successful than we really are. This is partly justified: no one likes losers. But when you hear about a continuous success story, but you do not see evidence of this, you stop believing your interlocutor even in what he is not lying.

Not that we do not hide anything at all ...;) But we are trying. For example, we stopped hushing up the facts of hacking our product, quite the contrary: according to the regulations, if we detect a critical vulnerability, we issue an emergency patch, open access to it to everyone (and not only to those who have technical support) and send notifications to users and partners. We also ceased to hide our financial performance and details of plans to conquer the world from employees. We try to honestly answer the questions why we do not have this or that functionality and whether we plan to introduce it. And while we are not confronted with what we were afraid of: there is no outflow of disappointed partners, the employees do not run to sell our secrets to competitors (and we don’t understand any special secrets to sell; at least, we don’t understand took advantage of similar knowledge from the camp of competitors).

On the contrary, we saw that people appreciate our honesty, try to help, understand us better. This removes the problem of disappointment due to high expectations.

Be yourself


This thought passes in the book as a red thread. Products need to be developed not for abstract users, but for yourself so that you yourself would be comfortable using them. For example, the Minimagaz module (only the function of placing in a cart, managing it, sending an order by email and an archive of orders; no 1C-a, online payment, comparison of goods, etc.; but it connects to the catalog of goods in a matter of minutes) I I came up with a year ago for my mom's site, after which we decided to release it in the product line. Now, according to sales statistics, he ranks second after the "My Account".

Projects cannot be made for sale, on the contrary, you should have a clear understanding of how the project will live on its own. The team should be built not in the same way as in well-known companies, but in the way that is convenient for you, taking into account your knowledge gaps and managerial deficiencies. You cannot allow customers to impose a product vision on you, otherwise you will always be a driven company and no innovations will shine on your product. More successful competitors cannot be copied, otherwise you will always remain company number two or five or twenty-five. A few years ago I saw on the Internet a ridiculous demotivator like this:


The world through the eyes of the first horse in harness


The world through the eyes of the second horse in harness

We will always see in front of us only someone's ass, if we are not ourselves.

In the next part of the article : “restrictions help”, “do not create specifications”; and that from the principles of GR we did not succeed.

Source: https://habr.com/ru/post/133784/


All Articles