Есть два типа подхода к оценке задач, назовем один «Стартапный», а второй «Энтерпрайзный». Сразу оговорюсь, это моя терминология и на научность я не претендую.
Стартапный подход к оценке задач проходит под лозунгом: «Дай оценку пальцем в небо, и начинай писать код». А уже в процессе уточнишь сколько времени на это надо. А энтерпрайзный кардинально отличается, сначала все оцени, договорись о том, как будешь писать код, предупреди всех кого этот код может атронуть, какие методы и контракты будет использовать каждый класс, и только потом пиши код. В этом случае сильно проще предсказать время, которое потребуется на выполнение задачи, но есть ощущение, что его потребудется больше, чем в первом подходе.
В крайних своих проявлениях эти подходы не применяются, и истина где-то по середине, просто кто-то тяготеет в одну сторону, а кто-то в другую. Мне вот близко дотошное планирование. Когда садясь писать код, я точно понимаю, что я буду делать. Да, для этого задачу нужно хорошо декомпозировать, и провести предварительный ресерч, и да потратить на это время, и да, иногда много времени.
Скорее всего, такой подход заложила в меня первая работа. Специфика была такая, что цикл разработки мог занимать несколько лет, компания сначала продавала проект, а потом его реализовывала. Программистов там было не много, всего три, и у каждого была своя зона ответственности, один писал протокол, другой писал серверное приложение, я писал фронт.
Так вот, тот чувак который писал протокол, был из тех, классических IT-ников из 90-х, в общем с причудами: никогда не пользовался общественным транспортом, на работе пил только зеленый чай и ничего не ел, но чувак был очень талантливый.
Он единственный, кто мог несколько недель работать из дома. Остальные работали исключительно из офиса (во времена были). Так вот, когда он собирался в очередную удаленку, я спросил, а почему он так делает. «Так а зачем мне ходить в офис, если все понятно? Два месяца я выяснял условия, требования. Мы прорабатывали MVP, а сейчас когда мне все кристально ясно, я могу просто идти и писать код».
И да, он несколько недель, просто сидел и писал код.
Когда работаешь с клиентскими продуктами, цикл разработки сильно меньше, а еще в b2c клиент чаще не знает чего хочет, и начинаются эксперименты. Пододвинь кнопку сюда, сделай баннер другого цвета, шрифт поменяй. И вроде плевые задачи, но глубокого погружения они не требуют, времени занимают не много и особо не интересны. Да даже без них, обычно сторю пытаются упихнуть в спринт, а это одна-две недели.
Тем не менее, в DC мы 2 дня в спринт тратили на декомпозицию, и в итоге пришли к очень хорошему проценту попадания в спринт. И мне это мне нравилось.
Сейчас мы тяготеем скорее к стартапному подходу, когда многие вещи станачала делаются, а детали выясняются в процессе.
Вообще я вначале сказал не правду, я знаю еще один способ оценки, но он совсем другой, поэтому о нем в следующем посте.
Спасибо, что дочитал до конца, буду рад обсудить эту тему в своем телеграм каналае.
Всем хорошего дня)
