First of all, I’d like to mention that everything described below is based on the real experience and is not my personal wishes.
In order to correctly estimate the task, it is necessary to make the following steps in relation to the project:
1. To get a list of requirements to the project.
If there are technical documents, demand them.
If they are not available, make a list of questions and try to find out about the project as much as possible.
Any wish of the customer that was not taken into account is a minus in the karma that can influence the rating and even the payment.
Examples of real lists of questions:
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 fully estimate it, it is necessary to persuade the customer in the necessity to develop:
Processes Diagrams (they help to reveal the hidden logics), example,
Wireframe, they help to estimate future interface, example,
Detailed technical documents (it will not allow the customer to demand unaccounted features) from you, example.
3. After that it is necessary to dividing the task to 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 required for learning about the project if the development has already been started. It can take rather a lot of time.
– Time to study new plug-ins and frameworks used in the project.
– Time required to develop the external environment and to make pilot customization of the project.
– Time required to test and debug (it can take half of the time spent for the development).
– Time spent for 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 logics that will require some time and make it possible to perform 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 basic logics of the project.
Example of a bad 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 logics:
– To create a user’s model – 3 hours,
– Server logics to work with sessions – 3 hours,
– Server logics 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 logics of processing errors with a social network, etc. However, it will not make it possible to take your time for work with the basic logics 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 important not to give way to the wish to please the customer and defend your terms and tools you are going to use in the process of development. 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 the fixed price and hourly rate. The price for the project at the fixed price must be always 20-30% more than it should be because it includes expenses for agreeing small defects due to differences in seeing the result by the customer.
We are looking forward to meeting you on our website soshace.com