Hourly project management

    I'll talk about how to turn hourly pay into a great way to manage a project. And also about how the customer (project manager) does not worry about the overstatement of the terms by the developer, and the developer does not worry that the customer will move it by the deadlines.


    The objectives of the project participants



    The goal of the customer is to complete the project within the allocated resources (temporary, financial and human). With hourly pay, the number of monitored resources narrows to one - man-hours, and the fewer parameters for control - the better control.

    The goal of the developer is to earn more and increase professionalism (return on time spent and, as a result, earn more). The developer has two ways to earn more - work more (more hours) and work better (more efficiently and have higher pay per hour of work). You can’t increase time to infinity, but you can reduce the time spent in vain. And the easiest way to do this is to study what you need to spend time in the first place, learning how to save customer resources.

    These goals are easily satisfied if we follow the algorithm that we came to in the process of implementing projects in various subject areas (from software to construction). The only condition for an excellent result in this algorithm is that the project manager (in our case, he is also the customer) must understand the subject area no worse than the developer.

    Method "How will you do this?"



    Key points of the method:

    • The contractor himself describes his actions to solve the problem and evaluates them himself;
    • The customer agrees with this assessment or offers his own way of implementation;


    1. Statement of the problem.



    The manager sets the task by describing the result that he wants to get from the required functionality.

    2. The developer divides the task into stages according to the functionality.



    After asking the manager about the nuances, the developer describes, in human language, how he is going to implement this task: which algorithm, what functionality is created for this, which files are moved / changed, which modules are used. We try to break the task down into features.

    Some developers are afraid of this step, expecting that they need something like a TK (which no one likes to write) - no TK, formalism, graphs, UMLs and other awesome technologies to escape from reality are needed, just describe the implementation as it is, how it is seen by the developer. For instance:

    1. I’ll look on the site such as others did this task.
    2. I will make changes to the database
    3. I will create a “messages” table in the database with the fields: id, from_id, to_id, message, time, is_readed.
    4. I will add the field "new_messages" to the table "users"
    5. I will supplement the model
    6. I will add methods to the user model: send_message (user_id, message), read_message (id), get_all_messages ()
    7. The send_message method saves the message to the messages table and increments the new_messages field of the sending user
    8. Alerts
    9. Download and connect jquery library
    10. I am writing the input functionality of the notification window
    11. I insert a notification code into the template
    12. Testing and debugging


    This is a rather important exploratory work and a very good exercise so that the developer himself understands how he will actually implement this functionality. Then he will be able to more accurately plan his actions and more accurately determine the timing of their completion.

    It is important - if a person cannot clearly describe how he is going to do something, he will not be able to do it in a reasonable amount of time at all.

    3. The developer determines the timing



    Knowing now how and what he will do, the developer calculates how long the implementation of each stage will take. It is important to first describe all the functionality (stage 2), without thinking about the timing, and then evaluate it.

    For instance:
    1. Finding solutions on sites - 20 minutes.
    2. Changes to the database - 15 minutes.
    3. Addition to the model - 30 minutes.
    4. Alerts - 90 minutes
    5. Test and debug - 30 minutes


    Total: 3 hours 05 minutes.

    It is rarely possible to immediately correctly evaluate the timing. But after 2-3-4-5 iterations, the skill and ability to plan and evaluate accurately appears.

    4. The manager evaluates the methods and terms of implementation.



    Looking at the description of the functional and the terms set by the developer, the manager decides to accept them as they are or not.

    If the manager believes that a certain stage can be completed faster, he explains to the developer how to do it (in fact, they return to the 2nd stage) until both agree on the timing and implementation methods. For instance:

    Manager: I think the notification can be done in 15 minutes if you use the NotifyBar plugin.
    Developer: 15 minutes is not enough, it will take about 30 minutes, since the plugin still needs to be tailored to your needs (it uses a different JS library)
    Manager: ok, 30 minutes for notification.


    If you are having difficulty planning a stage, you can break it into several smaller ones, describe and evaluate them first.

    5. The manager prioritizes the functionality.



    After the manager and the developer agree on all terms, he prioritizes the functionality depending on the time period for its implementation. It looks at how much time is allocated for the implementation of each item in general and how justified it is to spend such resources (time + payment) at this stage of the project. If this makes no sense, then such functionality is removed from the current task and transferred to the backlog, until better times.

    For example, the project was given 90 minutes to complete the “alert” task. This is wasteful at this stage, so let's simply display the mailbox icon in the profile, which takes not 90, but 5 minutes.

    6. Implementation.



    Now there is a clear functional, born by the developer, a plan and a deadline for completing the task. After the manager eliminated the unnecessary functionality and gave the go-ahead, the developer proceeds to implementation.

    Unexpected delay



    If the developer sees that he, nevertheless, is knocked out of the schedule, what is happening and there is nothing to worry about, it means that he did not foresee something in the initial plan (he did not complete the survey part) and immediately informs the manager about it. The manager and the developer again begin to discuss how to complete this stage (point 2) and find out what needs to be changed so that it is completed on time.

    If the deadlines change, the manager re-evaluates the prioritization (paragraph 5) and possibly excludes this stage from the task, breaks it into smaller ones or accepts new deadlines.

    7. Everything is ready, payment.



    Delay



    If the developer did not meet the deadlines set by himself, he receives an amount in the negotiated amount of the cost of an hour for the time actually spent. If this happens often, that is, the developer cannot learn to estimate the time (follow point 2), you pay special attention to this moment and train it, if in this case there is no result, you’ll have to deal with such an employee.

    Completed ahead of schedule



    If the developer meets the deadline and even manages to complete the task faster - he already decides to pass it earlier and proceed to another one or fill it with features that were refused (see backlog) or go for a walk. In any case, his work is paid in the amount of the planned period (cost of an hour * bonus coefficient * planned period), that is, in fact, he earned himself a bonus and a day off.

    Resume



    Thus, using the described technique:

    • A truly working schedule is being established, the developer is interested in doing it faster, and the customer is able to save resources by describing his task more correctly.
    • We have a task with a clearly defined plan: stages, methods and terms of their implementation. Not imposed, but born together with the developer (for the most part by himself).
    • The developer does not delve into the mythical “once necessary functional”, but does only what is needed, thus saving both his and other people's time.
    • We keep within the deadline by prioritizing the functionality.



    Also popular now: