Разделяй и властвуй Оценка задач — вечнозеленая тема. Я уже писал, как дать точную оценку трудоемкости задачи. Сегодня копнем глубже. Первое. Нужно оценивать конкретные задачи, а не техническое задание или бриф клиента. Разбиваем все на сабтаски, детализируем. Это муторно, но если не сделать, может получиться история с ТЗ на 140 страниц (реальный случай). У нас на одном проекте так вырос монструозный бриф, который менеджер раскидал по программистам, а через три месяца получили цирк уродов. Проект не готов, сроки прошли, все плохо. Потому что не было нормальной декомпозиции. Второе. Если ты не можешь разбить задачу на конкретные подзадачи, значит, у тебя не хватает фактуры. А это означает, что на проекте будут стопроцентные вилы. Это прям правило. Чувствуешь, что что-то упускаешь, не хватает макета или где-то еще серое пятно — жди беды. Третье. Все задачи можно классифицировать на три типа. — Делал, знаю. Это задачки, которые делаются постоянно. Оценка трудозатрат почти точная. — Не делал, но знаю. Типа «делал давно, но уже позабыл» или «понимаю, как устроено». Задачи штатные, легко гуглятся, проектируются. Нужно немного ресерча — и вперед. Погрешность в оценке есть, но терпимая. — Не делал, не знаю. Вот тут, как правило, всякий стрем. Это либо инновация, либо какая-то экзотическая фигня. Гуглится плохо, проектируется еще хуже. Для менеджера это самый тяжелый случай. Вывод. Чтобы нормально прогнозировать проект и оценки, сначала пишем ТЗ, потом режем его на подзадачи, а подзадачи классифицируем на три типа. Первые два — ок, можно ставить сроки. А вот с третьими нужно работать отдельно, брать паузу на проработку. Все просто, но многие компании не справляются и с этим.