Project evaluation is the first and inevitable stage of product creation. What difficulties await in the process of work and how to overcome them - read our article.
Approach the assessment seriously. This is not only information for the customer, but also work planning in principle. It is important to properly allocate resources and allocate a sufficient amount of time for each of the tasks.
When evaluating, it is necessary to take into account the features of a particular product, platform, audience. Sometimes companies use templates. But this is suitable only for standard projects.
Step 1. Discuss the project
Do not evaluate the project before you start working with the customer. It's a waste of time. Talk to the client. If he clearly understands what is needed in the end, adequately talks about the timing, complexity and cost of work - you are lucky. In this case, discuss the product, goals, functionality. Discuss organizational issues. Select the channels for further communication. Ask questions. The more information you get, the less likely you are to make a mistake.
If the client does not understand what is needed, you will have to choose from 2 options:
allocate time and an employee to discuss and list the features of the product. This is often done by product managers and/or technical writers;
offer a choice of 2-5 options for basic solutions, based on ready-made similar projects. In this case, it is important to show different sets of functions, explain the difference, pros and cons of each. The customer must understand what he is choosing.
"Life hack": customers see and appreciate the human attitude, so when evaluating the project, try to take into account the specifics of the idea and the sphere, vision and wishes of the customer. If this is not possible, explain it and adapt the idea. Conduct a dialogue with the customer. Start a conversation before you create a "Project Estimate for..." file.
Step 2. Contact the developers
No, the file "Project Evaluation for..." you can't create yet. It is possible and necessary to record important information from a conversation with the customer, analyze it and discuss it with experts. It doesn't matter how well you are at the technical side of the product. The opinion of an expert will not be superfluous.
If the evaluation of the project is on the manager - technical specialists will tell you which of the planned will take more time, effort and money. They will tell you what can really be done by the right day (or in principle), and what is not. In fact, it is the group of developers who sets the timing of the work. After all, only direct performers know how many hours it will take for a particular task.
If the developer is busy evaluating the project, you still need to go to your colleagues. Maybe they'll notice what you're missing. Do not neglect the advice of the more experienced. Listen even to those below the level. Beginners can notice some minor bugs, ask questions that you consider obvious, but then you will definitely hear from the client.
Step 3. Calculate time
You can create a file.
If you and the technical department have calculated the time of the team's work, this does not mean that the assessment is ready.
For example, time for edits, their discussion (it is often long), documentation and conclusion of contracts with contractors and contractors, holidays in the App Store and Google Play, and so on. Technical issues: time to get a domain name, software, SSL certificate, testing and more. Yes, hours have already been allocated for testing. But it is not known what changes will come from the customer. Perhaps the product will be redone so much that the tests will take longer than planned.
Do not rush with the assessment. If the customer requires to provide this in a day - say that you and the team need some more time, argue your request. Explain that this will reduce the risk of major edits, etc. A detailed, balanced assessment of the project is beneficial to both parties. It is better to wait a little at the beginning than to get a low-quality product at the end. Or not get it in the right time at all.
Evaluate calmly.
rate calmly
Do not panic and do not try to prescribe in the assessment much more hours than the developers indicated to you and you calculated yourself. Yes, you can and should have a small margin for force majeure. However, the more time is devoted to risks, the more nervous the customer is. It does not matter what reason you indicated in the assessment. You can scatter these hours on all tasks. The client won't like it anyway. At least because your team of specialists also managed to hedge their bets, which is why the deadlines were gigantic.
Trying to look better and reduce the time in evaluation is also not worth it. You either won't fit in, or you'll do the work somehow. The client, of course, will be pleased with a small round figure at the beginning of the work. But will the person be just as happy with the product at the end?
Argue all the time costs and explain to the customer why so much time is allocated for a particular task.
A cheat sheet that will come in handy when you sit down to distribute the hours.
We recommend paying attention to:
- communication with the team and discussion of the project;
- weekends, holidays and vacations in your company;
- work with documentation;
- conclusion of contracts with contractors and counterparties;
- edits and their discussion: both with the client and with the technical department;
- working hours of organizations related to the creation of the product: weekends of equipment suppliers, technical supports, vacations of application stores, etc.;
- working time and time for the work of state structures (if the product is created for them and (or) agreed with them);
- get a domain name;
- Obtaining an SSL certificate
- obtaining software and access to accounts;
- stabilization, especially when developing on Android;
- tests and acceptance tests;
- risks: each of the tasks separately and the project in principle.
If you are still confused , we offer 5 methods for evaluating projects of different levels of complexity. Choose the right one for your occasion and focus on it.
Introductory (fork) evaluation
Everything is considered, but in general. Two estimates are given: the most and the least likely. The difference between them is usually two times or more. This is due to the fact that the analysis is carried out exclusively with the help of assumptions and the most basic formulas.
Suitable for the initial evaluation of the project. Most often, fork evaluation is used when little or almost nothing is known about the upcoming tasks. And as such, the team did not develop a plan.
Fork evaluation is used to understand whether it is worth agreeing to this work. Even with this method, you can briefly introduce the upcoming costs of the client. This is done even without recourse to technical specialists.
However, you should not use fork evaluation in your work. The method is inaccurate, does not give much information, does not answer important questions for the client and the team. If you have a simple project, use the following method.
For projects of low and medium complexity
Evaluation in parrots
Another name for this method is story points. But the reference to the Soviet cartoon is justified: the smallest task is taken as a unit of measurement. With its help, larger tasks are further measured. The sum of such parrots (mini-tasks) in each sprint is equal to the speed of the team.
Suitable for evaluating standard projects. We do not recommend taking for evaluation new projects and projects with a fixed fee. In the first case, it will be difficult to consider individual processes and tasks in the course of work. In the second, there is no point in measuring the speed of workers on a fixprice.
Cost of quality
Non-trivial method, which is based on the division of value. First, they evaluate the development of functionality without taking into account risks and improvements. Then, the cost of troubleshooting is calculated. The number of problems is taken average, starting from a specific product.
Suitable for evaluation of most projects of low and medium complexity. During the evaluation of the project, you can also take into account the cost of testing, fixing external integration problems, purchasing and installing software.
For complex projects
Estimation of likely
The project is divided into tasks. The team considers each of the tasks in three versions: ideal (without risks), with partially realized risks and with all realized risks. The discussion decides which of the listed risks are most likely. They are included in the evaluation of the project.
This method takes time. Since the whole team is busy projecting and analyzing not one, but three situations. It is suitable if the task is extraordinary and we imply a lot of risks. It helps to make a list of tasks in advance, to foresee possible problems at each stage and to hedge your bets.
PERT
With the help of PERT, you make three estimates: optimistic, pessimistic and the most probable. Probability theory and mathematics in principle will help in this. For a full description of the PERT estimation algorithm and the formula of this method, see the scientific article by M. A. Fridlyanov (p. 20).
Suitable for long-term, one-time, complex projects, as it helps to give an assessment and working schedule of the project without accurate knowledge of the details and the necessary time for all components. The cons of PERT are complexity and time. If the client understands that the order is complex, and is ready to wait, evaluate the project by PERT.
A little about us
There are many methods. Some of them are based on the past experience of the company, they analyze previous projects and the already calculated ratio of payment - hours. Others go into statistics and science. We have chosen some of the most effective and convenient, in our opinion.
Which one to choose is up to you.
Personally, we evaluate projects in hours and money. The product manager studies the surface backlog by which the developer evaluates the project as a whole. We always involve professionals in the evaluation of the project and ask customers to provide the most accurate data. The more detailed the description of the project, the better the vision of the product, its understanding will be. And the more accurate the assessment will be.
Our experts recommend that customers when submitting an application have a specific goal of the project, understand the main sections and features. This and a constant dialogue with the manager will help to develop exactly what the client wants.
No comments:
Post a Comment