Срок выполнения задачи?
Как определить сроки на задачу, если ты никогда ничего подобного не делал? И когда эти сроки становятся критически важными?
Поехали! Время чтения статьи 2 минуты, а может 10, ну или давайте оценим ее на 5 поинтов в стиле Agile 😂
Допустим у нас появился новенький Джун, назовем его Олег . Мы даем ему задачу, он смотрит на нее и ставит предположительный срок выполнения 3 часа.
На что он опирается? На внутренние ощущение, карты таро, голос интуиции или желание показать себя гением? Мы не знаем, поэтому выдаем ему калькулятор времени:
- если не можешь по шагам рассказать, что будешь делать + 2 часа
- если не понял суть/результат задачи + 2 часа
- если выяснилось, что недостаточно данных в тз + 4 часа
- если документация и реальный код проекта расходятся + 10 часов
Задача - подключение к внешнему сервису. Документация есть. Беремся делать, ставим срок 8 часов.
А в процессе выясняем, что есть расхождение того, как работает код сейчас и как он описан в документации. Такое можно встретить в любой компании и любом проекте. Документация устаревает и никто ее не обновлял, а код уже работает по новому.
И есть 2 варианта решения: либо писать в техподдержку, либо методом тыка пробовать. Об этом заранее так и не подумаешь, а сроки уже поставлены. Тут явно + 10 часов нужно ставить, смотря что произойдет быстрее - мы попадем пальцем в небо или нам ответят?
В этом калькуляторе, как и в настоящем, есть и более сложные функции:
Можно плюсовать все и всех, кто может помешать твоим срокам:
- кот лег на тебя и мурлыкает + 1 час
- хочется кушать + 1 час
- позвали на созвон + 1 час
- ревьюер + 10 часов
Ревью может затянуться, а без него ты слить задачу не сможешь. Время идет, а ты ждешь тех, кто сможет проверить.
Заказчики могут дать задачу, которая противоречит сама себе, а ты взял…)
Задача - вывести список сущностей уроков, у которых дедлайн не прошел. И прописано, что после дедлайна уроки выводить не надо. Но есть один нюанс. К урокам у нас могут крепиться домашки. Естественно, про домашки в ТЗ ничего нет.
Пошли к заказчику. Подождали 2 дня. Сели разбираться. Оказывается, надо. Вывели)
Но если снизить градус напряжения, то по сути джун может совершить только 2 ошибки, которые сильно сдвинут его первоначальную оценку:
Но это чисто опыт. Правильное решение приходит тогда, когда достаточно опыта выстраивания связей, системы и продумывания кейсов.
Что тут поможет?
1. Оценить степень неизвестности задачи.
То есть то, что вы точно не знаете, и что точно нельзя погуглить.
Если знаний на задачу и описания тз достаточно - сроки оценить реально.
Если вам нужно изучить новый фреймворк или дождаться чего-то от другого отдела - берите большой запас, тут сложно дать точные сроки на корректное решение.
Задача «создать онлайн-школу рисования» сама по себе большая и влечет поток вопросов, которые навлекают на нас одно большое «не знаааааю». А с чего начать, а какие будут сервисы, а какие роли, а какие технологии нужны? На каждый вопрос мы придумываем отдельную задачу, а к ней еще, и так далее. Чем проще задачи, тем выше шансы у всего проекта быть сделанным вообще.
Ну про оценку своей задачи плюс минус понятно, а как с командой быть?
Это новый уровень для нашего джуна Олега. Он раскроет опыт работы с командой.
Как в команде оцениваются сроки?
В отличии от пет проектов, фриланса и задачек на курсах на работе в Ит компании вместе с командой в жизнь Джуна приходит БИЗНЕС.
Бизнес ставит отделу ИТ задачу и ждет оценку по срокам(когда будет выпущен функционал?). На эту дату они радостно планируют и продажи и маркетинг и активности на платформе, а почему бы и нет? Бизнес придумал, заплатил и ждет фичу, чтобы всем показать как мы можем…)
Как мы работали в Умскул?
ТимЛид, PO(если он на проекте есть) и бизнес-аналитик садятся и начинают думать, а насколько может быть растянут этот проект?
Задача ТимЛида - оценить сроки и риски проекта. И проговорить их перед бизнесом.
Уже в этом моменте задача делится на составляющие, которые могут быть сделаны за спринт. А потом планируется спринт, где задачи делятся по разработчикам.
И тут уже сам разработчик оценивает сколько сил у него займет та или иная задача.
На практике, в Agile задача по времени не оценивается. Проблема оценки в часах - она всегда будет ошибочной. Просто примите это как факт при работе в команде) Ты можешь оценить свою работу в часах и уложится в этот срок, но в рамках команды - это практически нереально.
В Agile оценка идет через стори поинты(story points), это абстрактная единица оценки. Это, условно, силы, которая команда должна вложить.
Есть два варианта оценки:
1. Линейная, т.е. когда у нас поинты ставятся от 1 до 10.
2. По последовательности Фибоначчи, когда поинты ставятся в рамках некоторой прогрессии. Это 1,2,3,5,8 и т.д.
Мы придерживаемся второго формата, т.к. при линейной оценке через некоторое время мы внутри себя подсознательно адаптируем цифры к часам, что недопустимо с точки зрения Agile. Фибоначчи в этом плане усложняет нашему подсознанию эту задачу и мы продолжаем давать более абстрактную оценку.
Например, в линейно оценке ты поставишь 5, а команда 7 и 9. Среднее выйдет 7.
В Фибоначчи идет 5, дальше 8, дальше 13. Разброс с каждым разом больше и скорее всего оценка команды сойдется. Ты думаешь, а вдруг задача на 8. Но мы заранее договариваемся, что 5 - это средняя сложность, а 8 это когда больше неизвестных, 13 - это прям что-то сложное, 21 - это вообще бесперспективная хрень с точки зрения оценки)
Когда ты делаешь линейно ты больше сомневаешься в оценке, вдаешься в детали. Фибоначчи защищает нас и команду от этих мыслей. Так, оценка происходит значительно быстрее. Числа Фибоначчи - это понятные числовые значения, к тому же с приятным бонусом: элементы этой последовательности хорошо отражают рост неопределенности, который возникает с ростом сложности оцениваемой задачи.
Если айтишник говорит что опоздает на 10 минут, то возможно он делает это по Фибоначчи)) сравнивает ну ближе 20 минут опоздания к 10 или к часу)) выбирает 10👌
В начале работы команды - оценки самые неверные, но, по прошествии нескольких месяцев точность сильно возрастает, т.к. появляется командный опыт. И вы уже чувствуете, что правильно, а что нет.
Лучше ставить большую оценку, тогда ты сможешь уложиться в намеченный график.
Бизнесу лучше иметь негативную оценку, но ту, в которую ты точно сделаешь.
Бизнес, в нашем понимании, это и отдельный заказчик и твоя же компания. Точнее все то, что в ней, кроме IT. Это и отдел продаж, отдел образования и маркетинга. И у них на текущий план-график уже есть свои планы))) Поэтому, HR и ищут в компании ребят с опытом. Опытом работы с командой и бизнесом. Такой опыт мы даем в продукте, даже сильно больше. Мы сделали продукт, где команда из 7 человек разных направлений разработки в течении 6 месяцев работает над EdTech проектом. Можно будет прочувствовать и как твой лид оценивает сроки и как команда, и как ты сам. И насколько все это бьется с реальностью.
Можно ли, опираясь на прошлый опыт, оценить сроки задачи?
Оценка задачи производится на текущем проекте. Прошлые проекты не имеют большого значения, особенно, если ты делал это в соло. В команде работа идет всегда медленнее, чем если бы ты работал один. Сроки тянутся, но одновременно выполняется больший объем задач.
Бизнес всегда нестабилен. Эту мысль надо принять. Он адаптируется под текущие условия. Он всегда может сказать, что этот функционал нам не нравится. Мы провели демо и результат оказался не тот, который мы ожидали. И тут появляется дополнительный пул задач на переделку. И для методологии Agile это ок. Он и создан, чтобы адаптироваться под это.
Есть, конечно, еще waterfall. Но там все медленнее происходит. Для этого подхода нужна более четкая оценка. По waterfall обычно работают гос компании, которым важна точность, а не гибкость. Там оценка чаще в человеко-часах. И много бюрократии, чтоб согласовать задачу.