У меня как раз в свете одного из проектов есть неудачной кейс, по которому я получил бесценный опыт управления временем разработки.
Каждая твоя задача имеет определенное время на решение. Пока ты тренируешься “время” это твой опыт. Когда ты уже стал разработчиком “время” – деньги. Чем быстрее и качественнее ты делаешь задачу, тем дороже оплата твоего рабочего часа. Но тут есть момент – дедлайны. Профессионал должен укладываться в них. Чем меньше ты их нарушаешь, тем лучше.
Как правильно оценивать дедлайны
У тебя есть определенная задача. Например, написание калькулятора. Вопрос первый: “ты уже решал такую задачу?” Да. Отлично, например ставим на выполнение 2 часа. “А если не решал?” Разложи алгоритм решения задачи и оцени, сколько примерно времени тебе потребуется на его реализацию. Допустим, 5 часов. Первый пункт у нас есть. Теперь заложи коэффициент на подводные камни.
- Если ты задачу решал уже и ничего сверхъестественного нет – заложи 20% до времени.
- Если не решал – закладывай 50%. Соответственно мы уже имеем +-2,5 часа для первого случая и 7,5 для второго.
Менеджерство задачи
Помимо выполнения задачи тебе понадобится время на разговоры с менеджером/заказчиком. Если задача простая и ты её делал большое кол-во раз, то заложи до 1 часа. Тебе надо посмотреть на дизайн, обсудить кратко логику. Если задачу никогда не делал, то до 1,5 часов. Большие задачи требуют больше времени, но они в свою очередь декомпозируются на более мелкие, а о такой мы сейчас и говорим. И вот мы уже имеем 3,5 часа и 9 соответственно.
Тестирование и правки
Тут все сильно зависит от функционала и дизайна. Больше на глаз я бы определял. На такой задаче максимум 30 минут. То есть 4 часа и 9,5 соответственно.
И что мы имеем в итоге? Время, которое мы можем озвучить и исходя из которого строится ваша оплата. Причем там, где вы сделаете быстрее из-за опыта вы заработаете больше. При этом у вас есть относительный запас времени. Сделали быстрее – круто. Сделали дольше – не круто, надо брать и подстраивать формулу под себя, а также прокачиваться, как разработчик.
