MarinaWarm
New member
Помню, как в прошлом году я с улыбкой брал в спринт «ну, мелочь, на два дня выйдет», а сдавал через пять недель, проклиная каждого, кто когда-либо сказал слово «дедлайн». Звучит знакомо? Я полгода жил в этом цикле: закладывал пессимистичный срок при планировании, а в работе выжимал из себя оптимиста, потому что «сдаю завтра». Итого — хронический стресс, выгорание и репутация человека, который всегда «на подходе», но никогда не готов. Меня бесило, что каждый релиз превращался в квест на выживание.
Переломный момент случился не из-за курса или книги, а из-за одного раздражённого комментария тимлида на стендапе: «А почему ты снова оцениваешь задачу целиком, а не кусками?» Я тогда реально застыл. Оценивал. Везде. Брал эпик «рефакторинг модуля аутентификации» и сразу выдавал: «двухнедельный спринт, без вопросов». Никакой декомпозиции, никаких рисков, никаких зависимостей от другой команды. Просто магия цифр, которые я вытаскивал из пустоты.
С того дня я начал жестить над своими оценками. Первое, что сработало: разбивать любую задачу на подзадачи размером не более четырёх часов. Не «рефакторинг», а конкретно: «перенести валидацию из контроллера в сервис, обновить тесты, переписать документацию». Для каждого кусочка отдельно — оценка. Сумма кусочков почти всегда больше, чем «момент гениальной интуиции» на старте. Второе: добавлять буфер. Не «на всякий случай», а осознанно. Если задача три дня — пишу три дня плюс один на непредвиденное. Третье и самое сложное: перестать скрывать неопределённость. В Jira теперь ставлю «оценка: 3–5 дней», а не просто «3». Разброс не стыдит, он информирует.
Ещё один нелёгкий, но жизненно важный навык, который я прокачал, — это уметь говорить «нет» или «да, но не до пятницы». Звучит просто, а на практике — как ломать косточку. Первое время я боялся, что заказчик разлюбит, что стану «проблемным». Но оказалось, что честная фраза «мне нужно семь дней, а не три, иначе пострадает качество» звучит как профессионализм, а не как лень. Дважды за полгода мне пришлось так поговорить с проджектом, и оба раза — без драмы. Просто факты и альтернативы: либо срок, либо объём, выбирай.
Результат через полгода? Я перестал краснеть на демо, когда что-то «ещё дорабатывается». Спринты стали предсказуемыми: планирую на 60–70 процентов вместимости и в среднем укладываюсь в 80. Коллеги перестали просить «помоги, у тебя же ещё неделя в запасе», потому что запас перестал быть иллюзорным. Самое ценное — я снова начал получать удовольствие от кода, а не от гонки с самим собой.
Моя рекомендация простая: следующую вашу задачу не оценивайте «в лоб». Сядьте, напишите список из пяти-семи шагов, которые реально будут. Для каждого шага — время. Перемножьте на коэффициент 1,3. Добавьте один день на «а, блин, я не знал, что тут ещё баг». И не бойтесь, что цифра будет больше, чем у соседа по стенду. Ваш сосед, скорее всего, просто лжёт сам себе. А вы — нет.
А как вы оцениваете задачи в своей команде: по ощущению «ну, где-то так», по разбивке на шаги, или у вас вообще свой метод, о котором я даже не догадываюсь? Делитесь в комментариях, мне реально интересно, как другие выкарабкиваются из этой вечной драмы с дедлайнами. Может, кто-то найдёт подход, который я ещё не пробовал — буду благодарен за обмен опытом!
Переломный момент случился не из-за курса или книги, а из-за одного раздражённого комментария тимлида на стендапе: «А почему ты снова оцениваешь задачу целиком, а не кусками?» Я тогда реально застыл. Оценивал. Везде. Брал эпик «рефакторинг модуля аутентификации» и сразу выдавал: «двухнедельный спринт, без вопросов». Никакой декомпозиции, никаких рисков, никаких зависимостей от другой команды. Просто магия цифр, которые я вытаскивал из пустоты.
С того дня я начал жестить над своими оценками. Первое, что сработало: разбивать любую задачу на подзадачи размером не более четырёх часов. Не «рефакторинг», а конкретно: «перенести валидацию из контроллера в сервис, обновить тесты, переписать документацию». Для каждого кусочка отдельно — оценка. Сумма кусочков почти всегда больше, чем «момент гениальной интуиции» на старте. Второе: добавлять буфер. Не «на всякий случай», а осознанно. Если задача три дня — пишу три дня плюс один на непредвиденное. Третье и самое сложное: перестать скрывать неопределённость. В Jira теперь ставлю «оценка: 3–5 дней», а не просто «3». Разброс не стыдит, он информирует.
Ещё один нелёгкий, но жизненно важный навык, который я прокачал, — это уметь говорить «нет» или «да, но не до пятницы». Звучит просто, а на практике — как ломать косточку. Первое время я боялся, что заказчик разлюбит, что стану «проблемным». Но оказалось, что честная фраза «мне нужно семь дней, а не три, иначе пострадает качество» звучит как профессионализм, а не как лень. Дважды за полгода мне пришлось так поговорить с проджектом, и оба раза — без драмы. Просто факты и альтернативы: либо срок, либо объём, выбирай.
Результат через полгода? Я перестал краснеть на демо, когда что-то «ещё дорабатывается». Спринты стали предсказуемыми: планирую на 60–70 процентов вместимости и в среднем укладываюсь в 80. Коллеги перестали просить «помоги, у тебя же ещё неделя в запасе», потому что запас перестал быть иллюзорным. Самое ценное — я снова начал получать удовольствие от кода, а не от гонки с самим собой.
Моя рекомендация простая: следующую вашу задачу не оценивайте «в лоб». Сядьте, напишите список из пяти-семи шагов, которые реально будут. Для каждого шага — время. Перемножьте на коэффициент 1,3. Добавьте один день на «а, блин, я не знал, что тут ещё баг». И не бойтесь, что цифра будет больше, чем у соседа по стенду. Ваш сосед, скорее всего, просто лжёт сам себе. А вы — нет.
А как вы оцениваете задачи в своей команде: по ощущению «ну, где-то так», по разбивке на шаги, или у вас вообще свой метод, о котором я даже не догадываюсь? Делитесь в комментариях, мне реально интересно, как другие выкарабкиваются из этой вечной драмы с дедлайнами. Может, кто-то найдёт подход, который я ещё не пробовал — буду благодарен за обмен опытом!