Как вы действуете, когда понимаете, что не успеваете к дедлайну?

Ответ

Моя стратегия в такой ситуации строится на прозрачности, проактивности и поиске решений.

1. Немедленная коммуникация Как только становится очевидным риск срыва дедлайна, я информирую тимлида или менеджера проекта. Сокрытие проблемы усугубляет последствия.

2. Анализ причин и переоценка Вместе с командой анализируем, почему оценка была неверной:

  • Техническая сложность: Неучтенные нюансы интеграции, баги в сторонних SDK.
  • Объем работ: Задача оказалась шире, чем предполагалось.

3. Предложение вариантов решения (Plan B) Я предлагаю конкретные альтернативы на обсуждение:

  • Упрощение задачи: Выпуск MVP-версии фичи с отложением части функционала.
  • Пересмотр дедлайна: Обоснованный запрос на продление сроков.
  • Перераспределение ресурсов: Можно ли подключить другого разработчика?
  • Временное решение (Workaround): Реализация, которая закрывает потребность, пока не будет готово полное решение.

Пример из практики:

Задача: Интеграция платежного SDK за 2 дня. Проблема: SDK содержал критический баг, приводящий к крашу. Фикс от вендора занял бы неделю. Предложенное решение:

  1. Краткосрочное: Реализовать fallback-оплату через WKWebView и страницу провайдера, чтобы не блокировать релиз.
  2. Долгосрочное: Параллельно вести работу с вендором над фиксом и нативной интеграцией. Итог: Функциональность была доставлена в срок, полная интеграция завершена позже.

4. Выводы и улучшение процессов После завершения спринта/проекта важно провести ретроспективу, чтобы улучшить процессы оценки (например, добавить буфер на риски, дробить задачи мельче).

Ответ 18+ 🔞

А, ну это классика, блядь! Ситуация, знакомая каждому, кто хоть раз в жизни код писал. Стратегия-то у меня, конечно, есть, но она не про то, чтобы сидеть и бздеть в углу, пока всё накрывается медным тазом. Всё проще и без этих ваших заумных словечек.

1. Как только запахло жареным — сразу орем. Первый и главный принцип: если видишь, что поезд летит под откос, не надо делать вид, что ты просто пассажир и тебя это не ебёт. Сразу — в уши всем, кто должен знать: «Э, народ, тут такое дело, блядь, похоже, мы в жопе». Молчание — не золото, а гарантированный пиздец потом, когда уже ничего не исправить.

2. Разбор полётов: почему нас наебал оптимизм. Садимся и честно, без взаимных обвинений, ковыряемся в причинах. Обычно всё сводится к двум вещам:

  • Технические подлянки: Взяли какую-нибудь библиотеку от левых ребят, а там, сука, сюрприз — она глючит так, что волосы дыбом. Или задача оказалась не «прикрутить кнопку», а «переписать половину ядра, потому что архитектура — говно».
  • Оценка с потолка: Просто на глазок прикинули, а по факту работы — овердохуища.

3. Не нытьё, а план «Б», «В» и даже «Ё». Приходить с проблемой и без идей — это уровень стажёра. Надо тащить с собой варианты, даже если они неидеальные.

  • Режем по живому: Может, не нужна сейчас эта анимация с летающими пони? Выпустим просто работающую фичу, а красоту — в следующем спринте.
  • Просим отсрочку: Но не просто «дайте ещё недельку», а с чётким обоснованием, на что уйдёт время. Иначе выглядишь как лох.
  • Зовём на подмогу: Есть ли кто-то, кто может кинуть пару дней, чтобы вытащить проект из ямы?
  • Временный костыль: Можно ли сделать проще, но чтобы бизнес-потребность была закрыта? Иногда iframe или заглушка — лучше, чем ничего.

Вот, к примеру, из моей же практики, блядь:

Что было: Надо за два дня прикрутить платёжку от новых партнёров. Что вышло: Их SDK, сука, оказался таким кривым, что падал просто от взгляда. От них фикс — через неделю, не раньше. Что сделал: Не стал геройствовать. Сказал: «Ребят, нативно — нихуя. Но есть временный путь: засунуть их веб-форму в WKWebView. Говнокод? Да. Но платить можно будет уже завтра. Параллельно будем пинать вендора и делать нормальную интеграцию». Итог: Все довольны. Функция работает, релиз не сорван, а через месяц мы эту лажу заменили на нормальный код.

4. Главное — не наступать на те же грабли. Когда всё утряслось, обязательно надо собраться и устроить разбор полётов без галстуков. «Так, блядь, какого хуя мы опять просрали сроки?». Может, надо задачи дробить мельче? Или закладывать буфер на непредвиденное? Чтобы в следующий раз не лететь в ту же воронку с криком «ёпта, опять!».

Вот и вся философия. Никакой магии, просто адекватность и желание не обосраться публично.