Not a single plan

Inspired by the topics about the book Rework , the book itself and the topic " Why programmers break deadlines ." I will try to tell why in one month my attitude to planning and working with a team changed, not without the help of a book from 37signals.

It so happened that I was lucky enough to become the head of a new project in a small, yet still company. It was lucky. Basically, because, frankly, I do not have enough experience to manage any project from scratch. Yes, I had to do various things in my life that were not related to the profession, but I would not say that they are clearly expressed by my specialization. That is, I cannot call myself a pure make-up, designer, web programmer, manager, system administrator, and even more so a manager. Rather, he could not.

From the very beginning, my unconscious approach to work was simple - something like “who if not us”. So, I could not get past the problem, knowing that the whole enterprise was idle at the same time, or it causes me to feel a sense of internal discomfort. In a small team, the interaction between people is particularly acute, so at the moment when one person falls out of the general chain, problems begin. Often, it was I who had to solve them, due to my versatile preparation of training (well, or some kind of experience). After a frankly short time, I internally acquired a set of rules that would not be possible to voice a stranger right away — he would just laugh in his face. These are acquired little things (for example, snatched from the “Manual” of the same Lebedev), that is, knowledge, about the origin and history of which the unprepared person, that is, I only have to vaguely guess, and my own skills obtained during the work.

So, such rules and experience allow me to plan the work of a small team that is engaged in a rather interesting and completely new business.
')
Considering that the conditions in which we are working now are almost similar to “garage” ones, in a good sense of the word, I had the opportunity to try out several techniques, the mere thought of which had previously seemed unthinkable.

Failure to plan

Naturally, a fairy tale, when you can do nothing to the blue in the face of doing business that brings you not only emotional satisfaction, but also supported by material, is impossible. The slogan “the product will be released when we consider it ready” - in my opinion, nothing more than a public move. Management and investors need results, justification of the time and money spent, so developers are burdened with at least the first indicator, captured on paper, before starting work. Tasks are expressed in hours, hours in tasks, and how justifiable this can only be shown by time, the skill of the manager and all the people who participated in the creation of the plan.

Almost simultaneously with the consent of the management for the development of the project, I received a significant addition - the need to develop a detailed work plan for it. From stage to stage, with a clear description of all performers and forecasts of time costs. That is, I was required to have a plan of what was formed in my own head only as an idea.

I will not hide, at that time I considered this approach the only correct one, and I took it with great enthusiasm. The idea once to draw everything to the point, and then only follow the intended, occasionally making adjustments, of course pleases. But I was wrong.

And the main, unforgivable mistake, as I understood, pursued me for many years, from the very beginning of work in IT. For a long time I went to this knowledge, from simple theses like “you cannot learn new technologies when you start developing a new project / website / program”. Now my slogan, not an excuse, but the slogan becomes the phrase: "you can not plan something that you have never done before."

The idea is simple to ugliness, but the path to it was long and thorny. Indeed, as a programmer who needs to abandon the familiar programming language and move into an area unaccustomed to himself, can clearly and unambiguously answer the question “how much will this module take to create,” if he hadn’t been doing this before? And to find a hint, something will not work out - nobody has done just that yet. We have to either rely on our experience, designate the expected duration of the work, and then tear the vest and workahol until the task is solved, most likely late. Or honestly answer - I do not know that self-assessment does not always allow.

Of course, it is important to make a small amendment - the team in which we work is completely formed, so shuffling the staff and hiring new employees — professionals in their field — is useful, of course, but it’s very difficult to finally formulate the requirement for such a person. part of the work will be the main project. And, without taking off responsibility, I can say that this uncertainty is connected not with the lack of good planning, but for the most part with the “pioneering” fog in development. It turns out that I cannot make a good plan until I start developing, and development cannot be started until there is a good plan.

Only one way out - you can only appoint some milestones in the work. Of course, they should not be divorced from life, and behind the words “pilot launch” there should be a clear understanding of the requirements that are included in it not only from the manager, but also from the team.

Communication

While the developer is loaded with his small area of ​​work, he is divorced from the outside world. All that he has is input and output parameters. He knows what his module or function should do, or whatever else it is necessary for, but the rest of the work falls out of sight.

I just do not like this approach. When an interface developer looks up from the layouts and the code, he looks around in a dazed way, trying to compare what has changed in the product in parts unrelated to his work. Therefore, I am not ashamed to waste time on unloved meetings, and I spend them, speaking from time to time, what is a project at this stage of development, after which each team member clearly understands what is needed. In addition, the programmer is not shy about correcting the database developer in such a conversation and vice versa. Yes, and I myself bring out from him a clearer understanding and presentation of the final result of our work.

For planning such live communication is only a plus. Instead of a dry “deliberative” tone, I can quite accurately and quickly understand which task eats up too much time and which approach did not justify itself. And instead of correcting and re-planning, we need only to improvise and quickly, actually on the move, adjust the direction of movement.

Another important point that I met in the literature, but was able to realize only after reading Rework. The idea itself is not worth a penny. If she was thought out, counted, after which she lay down on the shelf - her price was worthless. Therefore, you should avoid this well-founded fear - to share with someone your ideas, the idea of ​​the project you are working on. Fear of losing primacy in your field can be overcome by training your acquaintances and friends. They are the most grateful audience who will be able to react fairly objectively, and sometimes share good advice with you. Do not be afraid - no one will steal the idea, because for this you need a realization, and you are just doing it. Even if at a relatively early stage someone starts working on a similar project, you are still on a horse. Noting the thought of the collective unconscious, if you love your job, competitors will only have to catch up, copying you.

Instead of conclusions

In order to dare to abandon plans on which it is very difficult to rely, it took me a month. To reach this thought - more than two years. Plans spur, do not give to relax, but poorly motivated. We come up with a time frame, often taken from the air, which is difficult to keep within. Any disrupted plan is the fall of the general spirit not only in the team. Even if you work as a freelancer and delay the deadlines, interest in the work falls, after which quality suffers. I tried to say no to plans and start improvising. Let's see what it will pour out.