How to achieve results by managing the development process

What is it all about

This will be a short post. First, a personal story, and then how to apply it in practice to the management of employees.
Pure experience, no theories.

First, they often talk about work on the result. About people focused on the process or on the result. The ratio is said to be 95% to five. I recommend all project managers to start off with a great video by Sergey Kotyrev on this topic. By the way, I warmly recommend other videos to watch - Sergey has achieved success in a difficult market and knows what he is talking about.


')
The video will answer you the questions why people around you (if you are a project manager by nature) do not want to take responsibility, often do not want to do the task as you would have done it, and are generally ineffective and ineffective from your point of view. They are not on purpose, just this is the nature of people who are focused on life on the process.

Personal case

Now my story. I wandered for a long time in the darkness of procrastination. And only recently I realized that I often could not determine for myself what exactly the result was, and therefore wandered between different tasks. Now this is not there, I have a vector in front of my eyes for every day, week, which I set myself. And to be precise, I use myTinyTodo . Very handy tool, flexible, like Excel, and placed on any hosting.

I create as many tabs for myself - for ideas, for tasks before leaving work, for a month - and every time I keep a tab with this thing open. This allows me not to dodge the goal. Such a simple case, but has been working for two years for me, and a plus for a number of my colleagues worked (people took other tools, but the essence — to see the list of things before my eyes — remained the same).

And now to how to reorient process-oriented people to the result (or rather, methods to achieve results, living and present). Also a few cases from life. Almost all of them concern programmers (I work with several dozens of programmers through a chain of people or directly, in total, projects are involved under a hundred people of different specialties).

How to deal with people

1. RERO

RERO - the principle of "release early, release often" (release early, release often).
It must go through your whole thinking process. For ideas are in your head, from the level of “make mega-expensive design, superproject, and all at once lay, with the right architecture” to the level of “bootstrap as simple and cheap as possible, get to the market as quickly as possible with MVP, collect feedback clearly and quickly, evolve, allocate points for refactoring and restructuring the architecture for the collected live data and real business requirements. ”

And all the rest - programmers, designers - are lined up in you in a chain, and work most effectively when you effectively think and see the whole process.

An example from life. Now, instead of introducing a megastore report into ERP, we are first doing a simple version and collecting usage statistics. The speed of releases in individual projects increased up to 10 times.

A simple statement of the problem (this will be discussed above) with the maximization of restrictions (to do concretely and not universally, not to make 100,500 filters or universal ones, to use a ready-made bootstrap layout instead of drawing 10 designs, etc.) when evaluating tasks acceptable time, and this will achieve a result.

2. The bonus from the introduction of the task

With one programmer, I could not make contact in terms of implementation. Then I began to allocate bonuses specifically for the implemented functionality. The bonus is simple, clear, clear, as the payment for the sale of a copy of the box software.
And a week later, my colleagues started asking me why my programmer was hammering them on the introduction of functionality (this is a common inter-project component). Actually, they began to implement, the programmer - to achieve results, and thereby earn a bonus. I am proud of him.

3. Statement, not causing questions + splitting tasks

I usually try to set tasks as olympiad ones. The essence of the problem, users story, input, output, data for verification. Of course, this is not necessary for a number of people, but if you set the final task and show how the final release should look and work - the likelihood of getting what you need is great.

Separately, I’ll say that you yourself have to split up the task (or your presenters) into pieces with a release of 1-2 days. The only way. And then you will be able to provide releases like Badu (5 releases per day? Or how many guys did not look for a long time).

A concrete example from life. It is necessary to make the complex integration of two historically randomly connected customer bases. I describe only the basic mechanisms of the scheme (improvements on the side of CRM), keeping in mind the architecture of the entire system. If you describe the entire system of customer connections (hotels, hotel chaining, networks, super networks, and complex ACLs), then it will take a month to write the solution.

A simple refinement to solve part of the problem (hotels and networks and a simple ACL) will take a couple of days, and the programmer sees them finished. Because the task is correctly broken.

4. Prechecking Market

This is very well described in one of the courses by guys from Stratoplan (post paid for, infa 100%). The point is simple - do not spend more than $ 1000 to check the market idea. It is best to simply conduct targeted spam on clients and see how many people will leave emails to wait for the release of the functional.

When you explain this task to people, you need to convey that the check should be as simple and fast as possible. Take one day working out, if possible. To say that to code the month thing, which then will not be needed.
And programmers - and they, as a rule, smart people - will understand that it’s better one day to do a thing to test an idea, than to do something for a month that will not be in demand later. Works.

5. Explaining the essence of things

Sometimes there are problem solving people. I myself am such, I think, this is a very important quality for a programmer and for a project manager.
A person likes to solve other people's problems.

So, if you are in the tasks (see above) to explain the essence of the problem, a programmer can often offer a simpler and faster solution than you would even think of. Because he is in the subject, in the code, in the architecture, and he understands the technical capabilities of the project better than you.

An example from life. I explain the task of connecting two chaotic bases and what needs to be obtained. The programmer himself (! Handsome and clever) offers different reports and filters, draws conclusions from these reports. And the whole picture - in full view. That allowed to get a vision of how the system should be arranged.

6. Replicable (reusable) solutions

We have a group of hotel projects. And there for the accounting of hotels I set the task to make a special counter, which would accept the ID of the hotel that entered the system. And each programmer on the project (I am only part of the hotel projects and infrastructure) happily screwed the counter, instead of doing his own.

If you are a programmer in the past, you understand the power of reuse. A buzz when a new functionality in the system is assembled from blocks already written, it is impossible to transfer.
If not, then believe me, if you propose a solution that will then be replicated and scaled, the programmer will gladly bring it to the end, because re-use is rushing to people, and when they use the products of their creativity

What's next?

In the comments I suggest experienced colleagues who are not shy about sharing their experience, tell you about successful cases from their lives.