Как оценивать задачи и их сроки?

Как говорил Марк Твен, “Есть три типа лжи: ложь, наглая ложь и сроки по задаче, которые дает джун в IT”. Когда ты приходишь в новую для себя область, то во-первых, тебе кажется, что неделя на решение вот этой вот задаче - это слишком много и за такие сроки тебя могут побить и во-вторых, тебе банально не с чем сравнить, чтобы оценить твои собственные трудозатраты, а дать правильную оценку - бывает очень важно, даже если она будет гигантской. Поэтому любой менеджер, пока ты не станешь как минимум мидлом, а лучше - синьером, будет просто автоматически умножать твои сроки на 1.5, а то и на 2.

Неправильные оценки в основном идут из-за того, что ребята, только что пришедшие в отрасль не знают всех аспектов, которые надо включить в анализ. Я попробую тебе их дать, чтобы хотя бы с самого начала твои оценки были чуть более реалистичными.

1. Мой любимый метод - по трем измерениям: оптимистическая оценка, когда все условия будут идеальными, а код будет за тебя писать какой-то эксперт, который попал к тебе в рабство, реалистичная - то, что на твой взгляд соответствует реальности, с учетом небольшого количества рисков и того, что придется много гуглить, ну и пессимистичная - если тебя будут постоянно отвлекать, а перед самой сдачей тебя одолеет мировая лень и ты ничего с собой поделать не сможешь. Не смотря на его простоту, это очень эффективный метод, так как ты будешь ориентироваться на крайние оценки, выбирая центральную, реалистичную.
2. Аналогии, этот метод требует наличие хотя бы какого-то опыта. Либо если опыта по конкретной большой задачей у тебя не было, то попробуй разложить ее на подзадачи, там наверняка найдутся те, в которых у тебя опыт уже был, ну а над пробелами тогда придется подумать.
3. Экспертная оценка, то есть просто спросить у более опытных коллег, сколько по их мнению может занять эта задача у джуна. Тут минус в субъективности оценки, ведь за тебя ее дает другой человек, который уже давно не является джуном или имел другие вводные в начале карьеры. Ну как минимум от этой оценки ты точно можешь отталкиваться.

И еще немного про то, что нужно учитывать при составлении оценки:

• Сложность задачи сама по себе. Если задачу можно решить без использования гугла - сложность элементарна, если как решить не знаешь, но в гугле сразу находится куча ссылок, то сложность низкая, если ссылок не много и там что-то написано непонятное, то высокая. Ну и есть отдельный класс задач, которые ты не найдешь в поисковике, но решить надо - по хорошему давать такую задачу джуну - плохая идея, пойди и обсуди это с лидом в разработке. Если ты миддл и выше - попробуй собраться с коллегами, похоливарьте, поугарайте, но найдите хотя бы общую канву решения
• Риски - если осень или весна, заложи риск отсутствия по болезни, если у ребенка день рождения или другое важное событие, которое нельзя пропустить - включи в оценку, ну и так далее. Найди наиболее вероятные риски и не бойся их включить в оценку. Если ты сдашь задачу раньше - молодец, менеджер будет больше верить твоим оценкам
• Отдельно выделю - доработку в результате неудачного тестирования или новых вводных пришедших от заказчика, не важно, все равно влияет на сроки
• Ну и не забывай, что ты человек и тебе тоже кушать и спать надо, а не фигачить код или тесты круглыми сутками

Как-то так и стоит оценивать на первых порах задачи, дальше получишь опыт и возможно скорректируешь эту мою схему под себя.

А пока - подписывайся и зови друзей!