Как говорил Марк Твен, “Есть три типа лжи: ложь, наглая ложь и сроки по задаче, которые дает джун в IT”. Когда ты приходишь в новую для себя область, то во-первых, тебе кажется, что неделя на решение вот этой вот задаче - это слишком много и за такие сроки тебя могут побить и во-вторых, тебе банально не с чем сравнить, чтобы оценить твои собственные трудозатраты, а дать правильную оценку - бывает очень важно, даже если она будет гигантской. Поэтому любой менеджер, пока ты не станешь как минимум мидлом, а лучше - синьером, будет просто автоматически умножать твои сроки на 1.5, а то и на 2.
Неправильные оценки в основном идут из-за того, что ребята, только что пришедшие в отрасль не знают всех аспектов, которые надо включить в анализ. Я попробую тебе их дать, чтобы хотя бы с самого начала твои оценки были чуть более реалистичными.
- Мой любимый метод - по трем измерениям: оптимистическая оценка, когда все условия будут идеальными, а код будет за тебя писать какой-то эксперт, который попал к тебе в рабство, реалистичная - то, что на твой взгляд соответствует реальности, с учетом небольшого количества рисков и того, что придется много гуглить, ну и пессимистичная - если тебя будут постоянно отвлекать, а перед самой сдачей тебя одолеет мировая лень и ты ничего с собой поделать не сможешь. Не смотря на его простоту, это очень эффективный метод, так как ты будешь ориентироваться на крайние оценки, выбирая центральную, реалистичную.
- Аналогии, этот метод требует наличие хотя бы какого-то опыта. Либо если опыта по конкретной большой задачей у тебя не было, то попробуй разложить ее на подзадачи, там наверняка найдутся те, в которых у тебя опыт уже был, ну а над пробелами тогда придется подумать.
- Экспертная оценка, то есть просто спросить у более опытных коллег, сколько по их мнению может занять эта задача у джуна. Тут минус в субъективности оценки, ведь за тебя ее дает другой человек, который уже давно не является джуном или имел другие вводные в начале карьеры. Ну как минимум от этой оценки ты точно можешь отталкиваться.
И еще немного про то, что нужно учитывать при составлении оценки:
- Сложность задачи сама по себе. Если задачу можно решить без использования гугла - сложность элементарна, если как решить не знаешь, но в гугле сразу находится куча ссылок, то сложность низкая, если ссылок не много и там что-то написано непонятное, то высокая. Ну и есть отдельный класс задач, которые ты не найдешь в поисковике, но решить надо - по хорошему давать такую задачу джуну - плохая идея, пойди и обсуди это с лидом в разработке. Если ты миддл и выше - попробуй собраться с коллегами, похоливарьте, поугарайте, но найдите хотя бы общую канву решения
- Риски - если осень или весна, заложи риск отсутствия по болезни, если у ребенка день рождения или другое важное событие, которое нельзя пропустить - включи в оценку, ну и так далее. Найди наиболее вероятные риски и не бойся их включить в оценку. Если ты сдашь задачу раньше - молодец, менеджер будет больше верить твоим оценкам
- Отдельно выделю - доработку в результате неудачного тестирования или новых вводных пришедших от заказчика, не важно, все равно влияет на сроки
- Ну и не забывай, что ты человек и тебе тоже кушать и спать надо, а не фигачить код или тесты круглыми сутками
Как-то так и стоит оценивать на первых порах задачи, дальше получишь опыт и возможно скорректируешь эту мою схему под себя.
А пока - подписывайся и зови друзей!
