I'll tell you how to turn hourly pay into a great way to manage a project. And also about how the customer (project manager) doesn’t have to worry about the developer overstating the time, and the developer doesn’t worry that the customer will move it in time.

Objectives of the project participants

The goal of the customer is to carry out the project within the allocated resources (time, financial and human). With hourly rates, the number of monitored resources is narrowed down to one — man hours, and the fewer parameters for control, the better is control.
')
The goal of the developer is to earn more and improve professionalism (return from the time spent and, consequently, to earn more). A developer has two ways to earn more - work more (more hours) and work better (more efficiently and have a higher wage per hour). It is impossible to 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 easy to meet if you follow the algorithm to which we arrived during the execution of 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 the customer) must understand the subject area as well as the developer.

Method "how will you do it?"

Key points of the method:

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

1. Statement of the problem.

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

2. The developer splits the task into stages according to its functionality.

To the campaign, figuring out the nuances of the manager, the developer describes, in human language, how he is going to implement this task: what algorithm, what functionality is created for this, what files are touched / changed, what modules are used. We try to break the task into features.

Some developers are afraid of this step, expecting that something like TK (which nobody loves to write) is required of them - no TK, formalism, graphs, UMLs and other cool technologies escape from reality is needed, just to describe the implementation as is, as she sees the developer. For example:

1. I will look at the site such as this task was done by others.
2. I will make changes in a DB
3. I will create in the database a table “messages” with the fields: id, from_id, to_id, message, time, is_readed.
4. I will add to the “users” table the “new_messages” field
5. I will add a model
6. I’ll add methods to the user’s 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 the jquery library
10. I am writing the functionality of entering the notification window
11. I insert into the template the code causing the notification
12. I'm testing and debugging

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

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 time at all.

3. Developer determines deadlines.

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

For example:

1. The search for solutions on sites - 20 minutes.
2. Changes in the database - 15 minutes.
3. Addition of the model - 30 minutes.
4. Alerts - 90 minutes
5. I test and debug - 30 minutes

Total: 3 hours 05 minutes.

It is rarely immediately correct to estimate the time. But after 2-3-4-5 iterations, the skill and ability to plan and evaluate accurately enough appears.

4. The manager assesses the methods and timing of implementation.

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

If the manager believes that some stage can be completed more quickly - he explains to the developer how to do it (in fact, they return to stage 2) until both meet in terms and methods of implementation. For example:

Manager: I think the alert can be done in 15 minutes, if you apply the NotifyBar plugin.
Developer: 15 minutes is not enough, it will take about 30 minutes, since the plugin still needs to be customized for its needs (it uses another JS library)
Manager: ok, 30 minutes to alert.

If difficulties are experienced in planning a certain stage, it can be broken down into several smaller ones, described and evaluated first.

5. The manager prioritizes the functionality.

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

For example, the task “alert” in the project was given 90 minutes. At this stage, it is wasteful, so we make a simple conclusion of the mailbox icon in the profile, which takes not 90, but 5 minutes.

6. Implementation.

Now there is a clear, born by the developer functionality, plan and deadline for the task. After the manager has eliminated the necessary functionality and gave the go-ahead, the developer proceeds with the implementation.

Unexpected delay

If the developer sees that he, all the same, gets out of schedule, what happens and there is nothing terrible in that, then he did not foresee something in the original plan (he didn’t complete the survey part) and immediately informed the manager about it. The manager and the developer again begin to discuss how to complete this stage (clause 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 (clause 5) and possibly excludes this stage from the task, breaks it n less than the smaller ones or accepts new deadlines.

7. Everything is ready, payment.

Overdue

If the developer did not meet the deadlines set by him, he gets the amount in the agreed amount of the cost of an hour for the actual time spent. If this happens often, that is, the developer cannot learn how to estimate time (comply with paragraph 2), you pay special attention to this moment and teach it, and even if there is no result, you will have to spend time with such an employee.

Completed ahead of time

If the developer fits in time and even manages to complete the task faster - he already decides to hand it over earlier and start 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 per hour * premium coefficient * planned period), that is, in fact, he earned himself both a bonus and time-off hours.

Resum

Thus, using the described technique:

• A truly working schedule is established, the developer is interested in making it faster, and the customer is able to save resources by properly describing his task.
• We have a task, with a clearly defined plan: the stages, methods and deadlines for their implementation. Not imposed, but born together with the developer (mostly by himself).
• The developer does not delve into the mythical “ever needed functionality”, but does only what is needed, thus saving both his and others time.
• We keep within the deadline prioritizing functionality.