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 put it into practice for employee management.
    Pure experience, no theories.

    First, they often talk about working on the result. About people focused on the process or on the result. The ratio is said to be 95% to five. I recommend to all project managers to start a great video Sergey Kotyrev in the subject. By the way, I strongly recommend that you watch other videos as well - Sergey has achieved success in a difficult market and knows what he is talking about.



    The video will answer you questions why the 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 in the way you would have done, and in general, from your point of view, are ineffective and ineffective. They are not on purpose, it’s just such a nature of people oriented on life to a process.

    Personal case


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

    I create as many tabs as I like - for ideas, for tasks before leaving work, for a month - and each time I keep a tab with this thing open. This allows me not to dodge the goal. Such a simple case, but it has been working for two years already for me, and it worked for a number of my colleagues (people took other tools, but the essence - to see a 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 the result, living and present). Also a few cases from life. Almost all of them relate to programmers (I work with dozens of programmers through a chain of people or directly, all in all, projects involve hundreds of people of different specialties).

    How to be with people


    1. RERO


    RERO - the principle of "release early, release often" (release early, release often).
    It must go through your entire thinking process. For ideas are brewing in your head, from the level of “making a mega-expensive design, a superproject, and laying it right away, with the right architecture” to the level of “bootstraping as simple and cheap as possible, getting to the market as soon as possible, collecting feedback clearly and quickly, "evolve, highlight points for refactoring and restructuring the architecture for the collected live data and real business requirements."

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

    An example from life. Now, instead of embedding a megacomplex report in ERP, we first make a simple version and collect usage statistics. The release rate in individual projects has increased up to 10 times.

    A simple statement of the problem (this will be discussed above) with maximization of limitations (do specifically, not universally, do not make 100500 filters or universal, use ready-made bootstrap typesetting instead of drawing 10 designs, etc.) will provide both programmers and all other participants when evaluating tasks an acceptable period, and this will achieve the result.

    2. Bonus from the implementation 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, like a payment for the sale of a copy of boxed software.
    And after a week, colleagues began to ask me why my programmer was hammering them on the topic of implementing functionality (this is a common inter-project component). Actually, they began to implement, the programmer - to achieve a result, and thereby earn a bonus. I am proud of him.

    3. Non-questioning + crushing tasks


    Usually I try to set goals as olympiad. The essence of the problem, users story, input, output, data to check. Of course, a number of people do not need this, but if you set the final task and show how the final release should look and work, there is a high probability of getting what you need.

    I’ll separately say that you yourself must split 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 have not watched for a long time).

    A concrete example from life. It is necessary to make a complex integration of two historically chaotically connected customer bases. I describe only the basic mechanisms from the circuit (improvements on the CRM side), keeping in mind the architecture of the entire system. If we describe the entire system of customer relations (hotels, the combination of hotels in a network, a network in a supernet, with complex ACLs), then writing a decision will take a month.

    And simple improvements 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 competently broken.

    4. Market check


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

    When you explain this task to people, you need to convey that the verification should be as simple and quick as possible. Take one day of development, if possible. To say that coding a month is a thing that then will not be needed.
    And programmers - and they, as a rule, are smart people - will understand that it is better to do a thing for one day to test an idea than to do something for a month that will not be in demand later. Works.

    5. An explanation of the essence of things


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

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

    An example from life. I explain the problem 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 is in full view. That allowed us 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 that would accept the hotel’s ID, which has entered the system. And every programmer on the project (I only manage part of the hotel projects and infrastructure) happily screwed up the counter, instead of doing my own.

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

    What's next?


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

    Also popular now: