Not a single plan

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

    It so happened that I was lucky enough to become the head of a new project in a small company that was still. It was lucky. Basically, because, honestly, I don’t have enough experience to manage any project from scratch. Yes, I had to do various things in 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 purely a typesetter, designer, web programmer, manager, system administrator, and even more so a leader. 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 at the same time the whole enterprise was idle, or it made me feel of internal discomfort. In a small team, the interaction between people is especially acute, therefore, 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 preparationlearning (well, or some kind of experience). After a frankly short time, I internally overgrown with a set of rules that it wouldn’t work out to an outsider like that right away - he just burst out laughing. These are acquired trifles (for example, snatched from Lebedev’s “Leadership”), that is, knowledge about the origin and history of which an unprepared person, that is, I, only have to vaguely guess, and my own skills gained 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 currently working are almost similar to the “garage” ones, in a good sense of the word, I had the opportunity to try out several tricks, one thought about which previously seemed unthinkable.

    Opt out of planning

    Naturally, a fairy tale, when you can to no avail to the point of turning blue do business that brings you not only emotional satisfaction, but also financially supported, is impossible. The slogan “the product will be released when we consider it ready” is, in my opinion, nothing more than a public move. Management and investors need results, justification of time and finances spent, so developers are even burdened with at least the first indicator captured on paper before starting work. Tasks are expressed in hours, hours in tasks, and as far as justified, only time, skill of the leader and all the people who participated in creating the plan can show.

    Almost simultaneously with the consent of the management to the development of the project, I received a significant appendage - 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 plan what was formed in my own head only as an idea.

    I must admit, at that moment I considered this approach to be the only true one, and I took it with great enthusiasm. The idea to draw everything to the point once, and then only follow what was planned, occasionally making adjustments, of course pleases. But I was wrong.

    And the main, unforgivable mistake, as I understand it, haunted 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 is the phrase: "you can’t plan what you have never done before."

    The thought is simple to disgrace, 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 unusual area, he can clearly and unequivocally answer the question “how long will it take to create this module” if he hasn’t done this before? And to find a hint, google something does not work out - nobody just did it yet. You have to either rely on your own experience, designate the expected term of work, and then tear the vest and workaholic until the problem is solved, most likely with a delay. Or honestly answer - I do not know what self-esteem does not always allow.

    It’s important, of course, to make a small amendment - the team in which we work has fully formed, so shuffling the composition and hiring new employees - professionals in their field, is certainly useful, but it’s very difficult to formulate the final requirement for such a person - after all, it’s not clear what is part of the work will become the main project. Moreover, without relieving myself of responsibility, I can say that this uncertainty is associated not with the lack of good planning, but for the most part with the “first-mover” fog in development. It turns out that I can’t make a good plan until I start development, and development can not be started until there is a good plan.

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


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

    I really dislike this approach. When an interface designer looks up from layouts and code, he looks around in shockingly, trying to compare what has changed in the product in parts unrelated to his work. Therefore, I do not hesitate to spend time on unloved meetings, and spend them, saying from time to time what the project is at this stage of development, after which each member of the team clearly understands what is needed. Among other things, the programmer is not shy in such communication to correct the database developer and vice versa. Yes, and I myself bring out from it a clearer understanding and presentation of the final result of our work.

    For planning, such lively 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 has not paid off. And instead of correcting and rebuilding plans, we just need to improvise and quickly, actually on the go, 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 considered, calculated, and then lay on the shelf - worthless. Therefore, you should avoid this well-founded fear - to share with someone your ideas, the idea of ​​a project that you are working on. The fear of losing primacy in your field can be overcome by training with acquaintances and friends. They are the most grateful audience, which 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 this requires implementation, and you are just doing it. Even if at a relatively early stage someone starts work on a similar project - you are still on horseback. Noting the thought of the collective unconscious,

    Instead of conclusions

    It took me a month to dare to abandon plans that are very difficult to rely on. To get to this idea - more than two years. Plans spur, do not give relaxation, but poorly motivated. We come up with a time frame, often taken from the air, which is difficult to meet. Any frustrated plan is a drop in the general spirit, not only in the team. Even if you work as a freelancer and drag out deadlines, interest in the business falls, after which quality suffers. I tried to say no to plans and start to improvise. Let's see what it will pour into.

    Also popular now: