We will make this bike in a month

Proper management of the development process is no less a problem than the proper code itself. Novice leaders often do not even think about it, stepping on the same rake. Using the example of a fictional story, let's try to figure out what problems we are waiting for and what can be done.

In the article I will not reveal any secrets, and I do not have a silver bullet. Also, I do not pretend to have a deep and high-quality knowledge of the development process, but I will describe one of the simplest approaches that I apply myself. It will describe simple and elementary things, known to every experienced project manager. The article is intended primarily for beginners RP, timlidov, and those who combine these positions. However, it is useful in any complex activity.

Bicycle

So, Vasya worked for a long time as an ordinary programmer, a leading programmer, and finally became the Head. He has a team of desperate development thugs in the amount of two units. Certainly talented and knowledgeable professionals.
')
Vasya receives the first order - you need to make ... a bicycle.

Unfortunately, finished bikes are either too expensive or not suitable for the customer for a number of reasons. Well, thinks Vasya, we love to do and know how to make bicycles, and happily takes on development. Vasya, though a beginner, is already a manager, and he understands that it is necessary to make the bike simpler, because remembers the terms, contracts, budgets and everything else that is the basis of decision-making in a commercial organization. Having made a thoughtful face, after a minute of silence, he responds to the customer that it will take at least a month to go, because “The task is complex and non-standard”. Thinking to myself that the work there for two weeks, but reasonably multiplying by two. Vasya was a cautious guy after all.

He assembles the team and announces the task: we make the bike. Turns guys on with his enthusiasm, listens to brilliant ideas from everyone, he is inspired by the general attitude and makes a simple and logical decision: Vasya himself, as the most experienced, makes the frame, Seryoga, as the best expert on advanced technologies, makes the wheels, and Peter, as the youngest, engaged in other attachments. They drank coffee, painted bicycles on the white board with markers on the face, profile, and in cuts and sat down to code.
Looking a little ahead, we will see in a month that the project is on the verge of failure, the team is demoralized, and the bicycle, although it already drives, is not far and often falls. It could not be otherwise. What happened?

Let's leave for a moment our glorious developers, and we will look from the outside what happened to them. In this story, you can see a number of obvious mistakes, however, most of them are the result of the main mistake made by Vasily at the very beginning, even before the start of development. Vasily forgot that he is primarily a manager and not a programmer.

What to do?

1. Design a bicycle.
2. Plan work and resources.
3. Call the customer date.
4. Make a bike.
five. ??????
6. PROFIT !!!! 11

Obviously, there is no secret in these points. They are clear and logical. However, Vasya fulfilled, first of all, clause 3, he scored at clause 2 and it turned out what happened. We will not dwell on the design in this article, in the simplest case (bicycle) this is the usual decomposition of the problem. This Vasya together with the team performed, in contrast to paragraph 2.

Work planning

Let's draw a parallel between the development team and the multi-threaded application: the developer, like the software thread, works better if he does not have to synchronize with other threads. And he needs enough input to get going. The task of the leader is to correctly parallelize the work on the available resources, to build the most effective sequence of stages for solving the task.

Let's carry out the simplest decomposition of our task:

As can be seen from the story, the team constantly had problems due to the lack of a finished frame. Therefore, you first had to make a frame, and then do the rest.


But what will Seryoga and Petya do while Vasya makes the frame? Rest is nice, but not in this case. Why not draw the frame first and agree on the size once and for all? Having the right size, Serega and Petya will be able to do their tasks. By the way, we have a packing task. It is not very tied to everything else, and it can be launched immediately, as the sizes will be known. So, we all rest on the size. Select the task of designing the frame size and see what happens:


As you can see, the task was able to parallelize as much as 4 threads in the most difficult stage. In the history of the bike, the key task was the size of the frame (analog of the interaction interfaces). Interfaces, as a rule, are the most important task that should be solved in the first place, but not always. It is important to carefully analyze the problem and identify this critical point. Sometimes it happens that this is the simplest task for 5 minutes.

Resources and Timing

Let's try to impose the resulting development plan on the available resources:

We have one of the options for network graphics, a well-known and popular planning tool.
Now it is clear who and when does what. Vasya has the smallest development load, and this is not accidental. Like any manager, he has a lot of administrative work, and enough time should be left for her.

In this example, only the simplest decomposition is performed. Consciously simplifying the decision, I expect that any interested reader can plan the development of the bike much better. By decomposing the task into smaller stages, you will be able, firstly, to use the available resources more efficiently, and secondly, to improve the accuracy of the timing estimates. It is difficult to say how much you will do the bike. But it is much easier to answer how long it takes, for example, pulling the tire on the wheel - ten minutes with a smoke break. Estimating the time for creating a bicycle as a whole, you can easily make a mistake by an order of magnitude. Having assessments of simple, obvious stages is unlikely to go wrong more than twice. Therefore, it is necessary to multiply by two.
On the other hand, it is also necessary to go deeper into the division into stages so as not to spend a few days with this. The task should be decomposed until each stage becomes a separate task performed by one executive unit (developer) in the presence of clearly defined input conditions. It makes sense to divide even deeper with a large number of performers in order to avoid their idle time.

As a team leader or project manager, never forget that your main task is managing the development process. You can participate directly in the writing of the code, but by residual principle, working on the pickup and closing the holes where the command fails. Or, performing quickly and qualitatively the most critical stages, from which the separation of the process by performers begins.
Control is not magic, intuition, or the gift of God. This is a painstaking and methodical work on systematization and optimization.

PS: The article, including diagrams, is made entirely in Google Docs, for the sake of experiment. Convenient thing, as it turned out!