Как мы укладываемся в два месяца с проектами, на которые нужно 20 недель

Мы каждую неделю получаем запрос с формулировкой «Нужно срочно!». Часть таких запросов укладывается в стандартные сроки, но иногда нам встречаются проекты с совсем уж убийственными дедлайнами, простите за каламбур.

У нас накопилось целое портфолио так называемых быстрых проектов. Мы попросили их руководителей поделиться принципами управления ими — как уложиться в срок и при этом не дать выгореть всей команде. Рассказываем на примере проектов для «РОСГОССТРАХ Банка», KFC и «ДОМ.РФ».

Мы создавали новую версию сайта. Фактически надо было переделать N страниц сайта, проверить их на работоспособность и выпустить в свет.

Работу начали в конце октября. Новую версию мы должны были закончить к Новому году. В нормальном режиме мы бы затратили на этот сайт от 4 до 6 месяцев. Но проект пришёл от крупного и стратегически важного для нас клиента.

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

И вот чем мы пользовались в работе.

Сразу обратились к референсам

Когда вы разрабатываете структуру сайта, нужно проводить исследование и проверять гипотезы. Смотреть, как разные пользователи реагируют на предложенные решения, находить оптимальные варианты — и использовать уже их.

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

Оставили в стороне устаревшие версии браузеров

Адаптировать интерфейс под устаревшие системы сложно: нужно написать код, протестировать, исправить баги и запустить всё. На каждой версии браузера.

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

Использовали опыт и экспертность, чтобы не согласовывать каждый пиксель

Если нужно сократить время, уходящее на правки и переделки, можно согласовывать всё поэтапно. Мы иногда так делаем — и расскажем об этом чуть позже.

Здесь не было времени даже на поэтапное согласование.

Мы объяснили это заказчику и предложили согласовывать не каждый отдельный макет, а только концепцию и ключевые разделы сайта. Всё остальное мы хотели показать уже в вёрстке. Заказчик согласился.

Работу стали согласовывать раз в неделю. Это всё равно часто, но нам не мешало. И заказчик, и его команда видели, что интерфейс будет работать — и помогали быстрее перейти к следующему этапу, поэтому времени уходило меньше.

Запустили вёрстку и программирование параллельно, а не последовательно

Когда процессы последовательны — можно быстрее исправить макет, а любая возникающая проблема становится очевидной.

Если менеджер не очень опытен или впервые запускает параллельные процессы, можно набрать проблем и сорвать даже разумные сроки.

У нас проблем с опытом не было, а работы было слишком много для последовательных процессов.

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

Запустили сайт по частям

Ближе к дедлайну мы поняли, что даже в текущих условиях работы 24/7, с кранчами и перегораниями, сайт к 31 декабря мы все равно не запустим. Даже если бы мы сдали всё посреди новогодней ночи, оставлять новый сайт на неделю было бы неразумно.

Мы запустили часть сайта.

Вечером 31 декабря разместили на старом сайте баннер «Добро пожаловать на новый сайт РГС Банка». По нему пользователи могли перейти на готовые разделы для физлиц. Это «ключевая» часть сайта — её посещают чаще всего, и она приносит банку больше всего лидов. Так мы выиграли время и заодно получили бесплатных бета-тестеров в лице b2c клиентов банка.

Фактически до конца января работало два сайта, ссылающихся друг на друга. Мы ловили баги и доделывали разделы, а всё полностью выкатили к первым числам февраля. Для пользователей мы оставили и старый сайт, на всех страницах которого разместили сквозную перетяжку с сообщением.

И вот что получилось в итоге:

Что ещё мы вынесли из проекта

Сотрудничество началось с полного переделывания сайта для KFC. Изначально поставили срок в 3 месяца. Когда мы сделали часть дизайна, пришло требование — обновить сайт за 2 месяца с учётом обновленного фирменного стиля.

Мы заранее запланировали месяц на «бэкграунд» сайта, поэтому на редизайн осталось всего 30 дней.

И вот что делал наш менеджер Артемий Дерут, чтобы мы не сорвали срок.

В работе с KFC нам максимально повезло с менеджером со стороны клиента. Мы вместе прорабатывали план и старались сделать его гибким.

При этом лишнего давления со стороны не было, весь диалог строился по принципу «Что нам нужно сделать, чтобы успеть вовремя?». Это помогло: мы знали, что менеджер со стороны заказчика не навяжет свою систему, а будет действовать заодно с нами.

Для обсуждения нового дизайна были организованы регулярные встречи с руководителями подразделений.

Можно договориться, что клиенты со своей стороны всё посмотрят и как-нибудь набросают правки, которые вы обсудите позже. Такой подход порой работает.

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

Присутствие всех топов помогало двигаться ещё быстрее — мы обсуждали вопросы сразу со всеми и могли больше ни к чему не возвращаться. Без встреч так не получится. Поэтому мы использовали выделенное время по максимуму.

Каждую неделю мы приезжали и обсуждали сайт. В обычном режиме этого бы не потребовалось — все-таки команда KFC состоит из крутых профессионалов — но в этом случае такая частота встреч была обусловлена поставленными нам сжатыми сроками. Фактически мы обрабатывали замечания в реальном времени.

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

Компании ДОМ.РФ мы помогли «с нуля» создать единую информационную систему жилищного строительства. Цель этой системы — сделать рынок строящегося жилья по всей России понятнее и прозрачнее. Обычные граждане смогут найти всю информацию о застройщике, самим застройщикам будет проще контактировать с государством, а все причастные — банки, правозащитные организации и жилищные кооперативы — смогут общаться со всеми тремя сторонами, не тратя лишнее время на официальные запросы.

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

Чтобы завершить всё в срок (а сдвинуть дедлайны было нельзя), мы использовали следующие приёмы.

В первые два дня команды дизайна и разработки составили планы работ и совместно их согласовали. Мы прописали всё: если бы что-то упустили, то это бы «выпало» из процесса, и дело закончилось бы срывом сроков.

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

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

Задача была одновременно «локальной» и «глобальной». Мы должны были сделать первую версию системы, которая позже стала бы масштабнее и помогла бы конечному пользователю с новыми задачами.

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

Планёрки наши мы проводили совместно с командами заказчика и разработки. На них мы показывали прогресс по задачам.

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

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

Параллельно с разработкой макетов дизайнеры собирали их в специализированную библиотеку — UI-kit. Эта библиотека сделала разработку быстрее и проще: фактически мы стандартизировали весь интерфейс.

С процессом помогал аналитик от команды разработки. Это сильно помогло сократить время на этапе разработки, а вопросы по логике и поведению элементов удавалось решать моментально.

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

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

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