First of all, I’d like to mention that everything described below is based on real experience and does not represent my personal wishes.

To correctly estimate the task, it is necessary to take the following steps about the project:

1. To get a list of requirements for the project.
If there are technical documents, demand them.
If they are not available, make a list of questions and try to learn as much as possible about the project.
Any wish of the customer that was not considered is a minus in the karma that can influence the rating and even the payment.

Examples of real lists of questions:
Example 1
Example 2

2. Furthermore, much depends on the volume of the work and the scope of the project.
If the project is large and it is difficult to estimate it fully, it is necessary to persuade the customer of the necessity to develop:
Processes Diagrams (help to reveal the hidden logic).
Wireframe helps to estimate future interfaces.
Detailed technical documents (it will not allow the customer to demand unaccounted features) from you, for example.

3. After that, it is necessary to divide the task into smaller parts. A more detailed list of tasks can also help to see the hidden work.

In practice, I constantly face the situation when developers initially underestimate the task, which is actually 2 or 3 times larger!

4. When estimating the task, it is necessary to take into account such hidden factors as

– Time is required to learn about the project if the development has already started. It can take instead a lot of time.
– Time to study new plug-ins and frameworks used in the project.
– Time is required to develop the external environment and make pilot customizations of the project.
– Time is required to test and debug (it can take half of the time spent on development).
– Time spent agreeing and approving new details of the project (they usually occur in the process of communicating with the customer).

5. When dividing the task into sub-tasks, it is necessary to single out basic logic that will require some time and enable further development.
Then, it is possible to pass to details. Why? The customer often tries to downsize the project to decrease expenses. That is why it is important not to let him decrease the time included in the project’s basic logic.

Example of a wrong division into sub-tasks:
– Authorization via e-mail – 8 hours,
– Authorization via Facebook – 6 hours.

Example of dividing a project into sub-tasks taking into account basic logic:
– To create a user’s model – 3 hours,
– Server logic to work with sessions – 3 hours,
– Server logic to work with the OAuth protocol – 3 hours,
– Server validation – 3 hours,
– Customer validation – 2 hours,
– Logics of authorizing via Facebook – 3 hours.

The above example is not ideal because it does not take into account, for example, the logic of processing errors with a social network. However, it will not allow you to take your time to work with the basic logic of the project.

6. Often, there are situations when the customer tries to dictate the terms and conditions of the development himself, including the time required for the development, without having enough competence for it.
It is essential not to give way to the wish to please the customer and defend the terms and tools you will use in the development process. Remember, the customer always tries to get the best result at the minimum price. Don’t toe the line!

7. There are also some differences when working at a fixed price and an hourly rate. The fixed price for the project must always be 20-30% more than it should be because it includes expenses for agreeing to small defects due to differences in seeing the customer’s result.

We are looking forward to meeting you on our website, soshace.com