Привет, Хабр! Меня зовут Дмитрий Кислов, я системный аналитик в команде автоматизированной банковской системы в ПСБ. 

Рано или поздно каждый ИТ-специалист сталкивается с ситуацией, когда бизнес ставит почти невыполнимую задачу с жёстким дедлайном. Как тут не вспомнить старую шутку: «Можно ли заставить 9 женщин родить ребёнка за один месяц?». Ответ очевиден — нет, законы природы (и разработки) не обманешь.

Конечно, мой главный совет по таким ситуациям — не оказываться в них. Но в реальности случается форс-мажор: внезапные изменения в законодательстве, упущенные сроки, требования ключевых клиентов. Команда оказывается перед фактом: «Нужно сделать невозможное, и, кстати, дедлайн — вчера».

На небольшом примере из своей работы я покажу, как не сгореть, сохранить результат и даже извлечь из этого опыт.

Итак, это случилось: на вас упала очень срочная и важная задача. Что делать?

Шаг 1. Успокоиться и понять суть задачи 


Первая реакция на срочную задачу — паника. И её нужно остановить. Поэтому выдыхаем, медитируем, рисуем, идём выпить ромашкового чая — что угодно, чтобы немного прийти в себя.

Что нужно сделать? Чётко сформулировать что и когда. Задайте заказчику три простых вопроса:

Что именно должно работать в конечный срок? (Какой минимальный результат устроит бизнес?)
Почему срок именно такой? (Закон, конкурент, штрафы? Понимание причины поможет искать нестандартные ходы).
Что будет, если не успеем? (Реальные риски помогают расставлять приоритеты).

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

  1. Дать клиентам возможность подать заявление на каникулы.

  1. Перестать начислять просрочку по процентам тем, кто на каникулах. Всё остальное вторично. И вот мы только что нашли наш фокус.

Шаг 2. Разделить «слона» на кусочки или декомпозировать задачу

Большую задачу («слона») невозможно «съесть» целиком. Её нужно разрезать на маленькие, понятные кусочки-задачи.
Как это делается? Берём конечную цель и начинаем задавать вопрос «Как это сделать?». Каждый ответ — это новая подзадача. Повторяем, пока не дойдём до простых действий.

Пример из нашей задачи:

  • Цель: Кредитные каникулы работают через месяц.

  • Как? 1) Не начислять просрочку. 2) Принимать заявления.

  • Как принимать заявления? → а) Вручную через операциониста (просто и быстро). б) Через онлайн-банк (сложнее, дольше).

  • Как не начислять просрочку? → а) Временно выключить автоматический процесс для таких договоров («костыль»). б) Встроить проверку каникул в процесс («правильное» решение).

  • А что ещё? Сформировать клиенту информационный план-график в случае оформления каникул. 

При этом, остаются вопросы, которые решать придётся немного позднее. Например, вопрос капитализации процентов к телу кредита, пролонгации кредитных договоров, формирование графика платежей после окончания кредитных каникул.
Когда вы всё разложили, становится ясно, что полноценное решение (со всеми автоматическими расчётами, графиками и отчётами) может занять 6 месяцев (а то и больше). А то, что нужно сейчас (MVP) — это лишь 20% от общего объёма работ, и его можно сделать за месяц.

Шаг 3. Создать MVPMVP (Minimum Viable Product) — это минимально жизнеспособный продукт. В условиях аврала его формула проста: «автоматизация + ручные операции».

  • Суть: определяем, какой минимум функций необходимо автоматизировать к дедлайну. Всё остальное временно делается вручную силами сотрудников (это те самые «руки»).

  • Зачем? Это позволяет уложиться в срок и дать бизнесу хоть что-то работающее.

  • В нашем примере MVP на месяц выглядел так:

    • Доработка (автоматизация): небольшое исправление в системе, чтобы проценты по договорам на каникулах не уходили в просрочку.

    • Руки (ручные операции): специалисты колл-центра принимают заявления от клиентов по электронной почте или телефону и вручную проставляют в системе пометку «каникулы».

Важно! MVP — это не навсегда. Это временное решение, которое даёт команде передышку, чтобы спокойно и качественно доделать всё остальное.

Шаг 4. Собрать главную команду

Для работы над MVP нужна особая команда — быстрая, опытная и с полными полномочиями.

В такой команде будет минимум людей: аналитик (который и будет вести проект), разработчик и тестировщик. Все — самые опытные и знающие систему, готовые использовать аварийные/запасные тех.окна для переноса на прод. Из команды я сознательно убираю менеджера проекта, его функции будет выполнять аналитик, имеющий соответствующие навыки.

  • Правила работы команды:

    1. Максимальный приоритет. Никто не отвлекает команду на другие задачи. В этот момент для членов команды нет других проектов, внезапных созвонов с кем-то, кроме друг друга.

    2. Короткие и постоянные коммуникации. Все общаются напрямую, без длинных согласований. Собственно, ради ускорения коммуникаций и отказываемся от менеджера проекта. Его подключаем, когда MVP уже работает и теперь нужно доработать всё, что отложили на потом. 

    3. Параллельная работа. Пока аналитик пишет окончательное техническое задание и согласовывает, разработчик уже начинает кодить на основе устных договорённостей. Потом аналитик и разработчик верхнеуровнево отлаживают получившийся код, а тестировщик (или несколько!) пишет тест-кейсы. Это критически важно для экономии времени.

Это основная, главная, команда. Для менее приоритетных задач можно понизить требования и собрать второстепенные команды.

Шаг 5. Действовать и держать оборону

Даже с лучшим планом что-то пойдёт не так. Будьте готовы:

  • Работать сверхурочно. К сожалению, в авралах это часто неизбежно. 

  • Тушить пожары. «Упадёт» тестовая среда, «сломается» сборка, найдутся неучтённые детали. Помним о законе Мёрфи: всё, что может пойти не так, обязательно пойдёт не так.

  • Жёстко говорить «нет». Не давайте бизнесу добавлять в MVP «ещё одну маленькую кнопочку». Всё, что не вошло в изначальный план MVP, идёт в очередь на вторую волну доработок.

Выжили. Что дальше?

Поздравляю, MVP запущен в срок! Но на этом история не заканчивается.

  1. Обязательно проведите «разбор полётов» (ретроспективу). Обсудите с командой: что пошло не так изначально, что помогло выжить, что нужно изменить в процессах, чтобы не попадать в такие ситуации.

  2. Немедленно начните работать над «второй волной».

Помните те 80% задачи, которые мы отложили? Теперь, без давления дедлайна, нужно качественно доделать автоматизацию, убрать «костыли» и «ручные операции».

3. Позаботьтесь о команде. Аврал — это стресс и риск выгорания. Дайте людям отдохнуть, поблагодарите их.

Главный вывод: срочные проекты — это школа выживания, а для новичков — боевое крещение, те самые «огонь, вода (а медные трубы славы будут попозже)». Они учат расставлять приоритеты, договариваться и видеть суть задачи. Но ваша главная цель — не стать вечным победителем авралов, а научиться строить процессы так, чтобы они случались как можно реже.

Удачи, и пусть ваши проекты идут по плану!