В книге «Как разговаривать с кем угодно, когда угодно, где угодно» Ларри Кинг предлагает быть всегда честным со своими слушателями. Не думаю, что он первооткрыватель этой идеи, но именно его книгу я прочла как раз перед тем, как приняться за написание этой статьи. И следовать буду именно его совету.
Я — Мария Анищук, ведущий продуктовый аналитик компании РТЛабс. Сегодня я расскажу, как мы за 44 часа подготовили и выпустили в прод новую услугу по выплате детского пособия и даже успели немного отдохнуть.
Важное уточнение: этот продукт был гораздо больше, чем просто MVP.
Важные пояснения
Обычно работа над услугой включает в себя аналитику, проектирование, саму разработку, тестирование, внедрение и поддержку. В нашей практике эти этапы имеют свойство не всегда идти именно в такой последовательности. Иногда они проходят параллельно или повторяются.
Какая-то часть статьи может показаться вам слишком обобщённой. Причина — в запрете на разглашение отдельных видов информации, принятом в нашей компании.
Итак, по порядку.
Как мы сделали продукт быстро?
Спойлер: пропустили часть этапов и не спали.
А теперь хронология.
Четверг, 14:00—16:00
К нам прилетела срочная задача: в силу вступал закон, предполагающий выплату нового детского пособия. От нас требовалось максимально быстро подготовить и вывести в прод услугу по его оформлению.
К 16:00 мы закончили изучение новой нормативки и смогли начать разработку услуги. Приступить к разработке мы смогли даже раньше официальной публикации документа.
Четверг, 16:00—19:00
К нам подключилась команда разработки. Процесс шёл параллельно: пока мы проводили аналитику и писали тексты интерфейсов, разработчики собирали стандартные экраны услуги.
Экран услуги — это то, что пользователь видит на экране своего мобильного, планшета или компьютера, получая услугу. На Госуслугах принят Request — внутренний гайд по проектированию макетов, описывающий варианты решений для шаблонных ситуаций. В нём собраны готовые решения, не требующие разработки с нуля. Например, это может быть вопрос о номере телефона или адресе электронной почты.
Четверг, 19:00 — пятница, 01:59
До 2 часов ночи мы всё ещё продолжали работать в онлайн-режиме: разработчик демонстрировал экран, а я на ходу корректировала тексты и логику переходов.
Логика переходов — это схема последовательности экранов. Она может собираться сразу из готовых экранов (например, экран подтверждения персональных данных, экран с адресом пользователя, вопрос «Кем вы приходитесь ребёнку» и т. д.), а может схематично изображаться с помощью небольших стикеров, как на иллюстрации ниже.
В основном мы использовали линейную логику переходов (экран за экраном), в отдельных случаях дополняя её блоками развилок. Например, когда мы спрашивали, на какого ребёнка будет подано заявление: до 14 лет или старше. От этого вопроса зависело, какой экран пользователь увидит следующим.
Стандартный этап отрисовки макетов мы пропустили, услуга собиралась из готовых форм.
Каждое изменение в схеме услуги тут же вносилось и проверялось на тестовом стенде, чтобы убедиться, что результат совпадает с нашим видением.
Пятница, 02:00
Примерно в 02:00 ночи мы вывели услугу в продуктивный контур с доступом только для заказчика. Чтобы сэкономить время, заказчик согласовывал не отдельные фрагменты макета, а уже готовую карусель экранов.
Пятница, 02:10—10:00
Пока заказчик оценивал наши труды, продуктовая команда отправилась по домам и продолжила работать уже там. Разработчики в это время начали интеграцию интерактивной формы с ведомственной системой, занялись созданием xml и разработкой печатной формы pdf — заявления, которое сохраняется у пользователя в его личном кабинете.
Пятница, 10:00
Готовую услугу отдали на приёмку.
Пятница, 10:30
Наконец-то долгожданный отдых.
Пятница, 15:00
Встреча со стейкхолдерами — заказчиком услуги, нашим непосредственным руководством и представителями ведомства, которое будет оформлять пособие. Выяснилось, что у нормативного документа появилась вторая версия и услугу нужно корректировать.
Пятница, 15:00—23:00
Конец рабочей пятницы и весь вечер мы вносили правки. Сначала планировали релиз на 23:00, но из-за ожидания финальных подтверждений перенесли на утро.
Суббота, 10:00
Ура! Услуга официально опубликована для пользователей.
Можно остановиться, спокойно отдохнуть в выходные и в понедельник приступить к другим рабочим задачам? Не всё так просто.
Процесс завершён, да здравствует процесс!
Новую рабочую неделю мы начали с бэклога доработок.
Откуда они взялись?
Требования к услуге прописывались параллельно с подготовкой нормативки по выплате самого пособия. Финальные формулировки НПА отличались от промежуточной версии, на которую мы опирались при разработке. Нужно было привести услугу в полное соответствие законодательству.
Тестирование за поставленные сроки не может покрыть все кейсы. Обычно регресс (проверка карусели экранов) и интеграционное тестирование с ведомством проводятся отдельно и предполагают проверку всех возможных сценариев. У нас оба тестирования слились в одно, были пройдены в урезанном формате и максимально быстро. Поэтому в MVP-версии у нас были некоторые баги, которые нужно было поправить.
Как мы структурировали задачу по доработке услуги
Параллельно с разработкой, выводом и согласованиями промежуточных версий мы собирали список новых требований и доработок, обратную связь от ведомства и т. д.
Собранный бэклог работ приоритизировали, определив задачи с высоким, средним и низким приоритетом.
Чтобы ничего не потерялось, оформили каждое требование в отдельную задачу, чётко сформулировали ожидаемый результат и передали в разработку.
Параллельно готовили ответы на потенциальные вопросы, с которыми пользователи могли обратиться в поддержку. После запуска услуги поддержка в свою очередь оперативно передавала нам обратную связь от пользователей.
Весь бэклог доработок был завершён в течение недели.
Какие выводы мы сделали
После завершения работы над услугой мы проанализировали процесс её вывода. Нужно было понять, как нам удалось справиться так быстро и что можно будет взять на будущее, на случай нового аврала.
Сработавшаяся команда
Для экстренных задач такой сложности и срочности лучше брать людей, которые не только имеют большой опыт, но и сработались на других проектах, буквально понимают друг друга с полуслова.Важное уточнение
Work-life balance вне такого проекта и оплату сверхурочных во время аврала никто не отменял, но при наборе команды это не должно являться решающим аргументом. Люди должны гореть самой идеей, искать новые вызовы и любить интересные задачи. Это — лучшая мотивация для такой команды.
Fullstack-специалисты: когда один в поле воин
Чем больше в команде «универсалов», которые могут объединить несколько ролей, тем лучше.В нашем случае:
— бизнес-аналитик заменил редактора текстов. На Госуслугах созданы подробные гайды, прописаны глоссарии и проработана Редполитика, которой могут пользоваться все желающие, а у вышеупомянутых сотрудников уже был опыт подобной работы;
Важное уточнение
Для авральной реализации проекта этого оказалось достаточно. Позже, на этапе доработок уже в спокойном режиме можно обратиться за консультацией. Например, попросить редактора провести редконтроль.
— аналитик собирал услугу на макете без привлечения проектировщика и дизайнера. Это давало представление, как услуга должна выглядеть. При работе над услугой мы начали отрисовку макетов не сразу, но, как показала практика, лучше было делать это с самого начала (даже если кажется, что отказ от них сокращает время);
— часть разработки и тестирования шли исключительно под присмотром аналитика. Так как аналитик не успевал перенести всё на макеты, то разработчик получал информацию либо в устном формате, либо кратким текстовым сообщением. Это было возможно, так как экраны услуги переиспользовались из уже существующих услуг, поэтому разработчику были понятны комментарии по типу «Сделай экран „Подтверждение персональных данных“, как у нас сделано в услуге „Получение паспорта РФ“» или «Сделай 5 полей для ввода, как мы обычно делаем в услугах для иностранцев»;
Важное уточнение
Позднее всё, что доносилось разработчикам и тестировщикам устно и письменно, отображалось на макетах. Это было нужно для финальных проверок и упрощения работы тестировщиков, дало осязаемую основу для разработчиков, которые позже вносили правки в услугу.
— разработчик услуги заменил системного аналитика. Так как у сотрудника уже был опыт описания системных требований ранее, а услуга была относительно несложной, мы смогли объединить этап описания системных требований и разработки в один;
— разработку услуги проводил один специалист. Чтобы ускорить процесс, в помощь ему привлекли ещё одного разработчика, но не на основную услугу, а на её дополнительные элементы (в нашем случае — для разработки pdf-заявлений, которые пользователь видит в своём личном кабинете). Почему мы так сделали: у каждого разработчика есть свои «фишки» и видение, как собирать услугу — с чего начать, какую часть кода можно сделать более ёмкой и так далее. Новому разработчику необходимо либо подстраиваться под уже «тронувшийся поезд», либо продолжать в своей манере, что иногда порождает повышение трудозатрат и, в нашем случае, увеличение времени. Мы не могли себе позволить такую роскошь, поэтому основная разработка легла на одного специалиста.
Тестирование в моменте: когда нет времени на тест-кейсы
Все участники проекта — аналитики, разработчики и тестировщики — были задействованы с самого начала.Мы понимали, что времени на написание тест-кейсов — сценариев прохождения услуги — просто не будет, поэтому тестировщики участвовали с самого начала разработки. Это позволило им ещё в момент разработки подмечать недочёты и начать тестирование с пониманием всех нюансов. Регрессионное тестирование мы смогли пройти практически без приключений. Проблемы выявились позже, при интеграционном тестировании.
Несмотря на анализ вида сведений, теги заложили не для всех атрибутов. Мы обнаружили, что для передачи информации о документе, подтверждающем права законного представителя, есть поля только для свидетельства о рождении. Но у гражданина может быть только актовая запись о рождении, а бумажное свидетельство о рождении отсутствовать. Как в таком случае передавать данные о детях? Так как это было MVP, а большинство людей продолжают оформлять бумажное свидетельство о рождении как самый первый документ новорождённого, мы приняли решение оставить реализацию неизменной, но внести себе это в список будущих доработок. С текущим решением выплату смогли бы оформить уже 99% пользователей, не дожидаясь наших новых правок.
Вывод на будущее: как только готова xml, её тут же нужно отправлять на тестирование.
Не нужно изобретать велосипед: сила накопленного опыта
Выводимая в аврале услуга была относительно несложной и схожей с некоторыми из тех, которые мы выводили ранее.Каждая услуга на портале предполагает наличие:
• точки входа — стартового экрана, на котором описывается самое важное: что это за услуга, для кого она нужна и как её получить. Такая информация помогает пользователю понять — это действительно то, что он искал, или нет;
• разводящих вопросов, которые позволяют уточнить информацию о пользователе. Например, если речь идёт о детском пособии, нужно узнать, есть ли у пользователя документы на детей. Даже если ответ будет отрицательным, мы всегда сообщаем, какие дальнейшие шаги нужно предпринять, чтобы подать заявление на получение пособия;
• экрана решения, на котором собрана персонализированная информация со списком необходимых документов, сроками оформления и перечнем дальнейших действий. Таких экранов в услуге может быть несколько. Например, если отличается список документов на детей разного возраста;
• персональных данных. Это ФИО, паспортные данные, телефон, почта, адрес и всё остальное, что может быть необходимо для идентификации пользователя, и что может понадобиться сотруднику ведомства. Список может меняться, но в сухом остатке он почти всегда одинаковый;
• ввода дополнительной информации — нестандартный блок, в котором могут быть вопросы о гражданстве, смене ФИО, данных предыдущего брака и другие;
• возможности загрузки файлов — этот блок встречается не всегда, только если пользователю нужно для получения услуги предоставить фото или сканы документов.Также каждая новая услуга дополнительно размещается в специальном каталоге и выводится в поиск Робота Макса.
В нашей услуге присутствовал каждый из вышеперечисленных блоков, но в упрощённом формате. Вопрос был не в скорости создания новых экранов, а в том, как быстро мы найдём подходящие готовые варианты и оценим, что в них нужно переделать.
Чтобы упростить сборку услуги, мы воспользовались конструктором. В нашей компании их уже несколько, например, здесь рассказывается о конструкторах лендингов (ВКЛ) и автоматических уведомлений (КАУ).
ВКУ — это визуальный конструктор услуг, который позволяет собирать услугу или сервис из готовых деталей или блоков. Процесс можно сравнить со сбором лего, где из отдельных деталей или даже целых блоков можно собрать здание, механизм или что-то другое. Подробнее о ВКУ можно почитать здесь и здесь.
Цепочка экранов в ВКУ 
Настройка экрана услуги в ВКУ Упростить то, что упрощается
Наша команда умеет делать по-настоящему сложные услуги с множеством вариантов развития событий и сотнями экранов. Но если речь идёт о быстром запуске, имеет смысл отказаться от этого всего, даже если мы это раньше делали и неоднократно тестировали.Согласно Request мы реализовали в нашей услуге циклы — возможность заполнения информации о нескольких детях в рамках одного заявления. Но обнаружилось, что система ведомства предполагает заполнение только одного документа, подтверждающего права законного представителя. Это не позволяет заполнять информацию на нескольких детей в рамках одного заявления — ведь на каждого ребёнка свой документ, подтверждающий права.
Изменения на стороне ведомства потребовали бы много времени, поэтому было принято решение пожертвовать комфортом пользователя. На каждого ребёнка заявление стало заполняться отдельно.
Приоритет № 1: освободить ресурс команды
С сотрудников команды, которые работали над новой услугой, сняли все остальные задачи. Люди сосредоточились на одном проекте, не отвлекаясь и не теряя драгоценного времени.Право на неидеальность и поддержка руководства
Руководство и стейкхолдеры осознавали, что мы выпускаем продукт очень быстро, а это значит, что он не будет идеальным в момент релиза. Услуга заработает, но потом нужно будет возвращаться к ней, чтобы убрать недочёты.Нам было нужно быстро создать работающую услугу, которая принесёт людям пользу и возможность уже через пару дней после публикации нормативного документа подать заявление на выплату, пусть и в ущерб некоторому удобству.
Чек-лист организации работы над авральной задачей
Если у вас авральная задача, предлагаю воспользоваться нашим чек-листом для быстрого запуска сервиса или услуги:
☐ Объединили несколько этапов работы над проектом и/или отказались от 1 из них
☐ Пригласили в команду специалиста-универсала, который может выполнять несколько ролей
☐ Сформировали команду из опытных специалистов, которые уже работали с аналогичными услугами
☐ Члены команды ранее уже работали вместе
☐ Все члены команды готовы работать над проектом добровольно, а не потому, что надо
☐ Все участники команды подключены к процессу с самого начала
☐ Команда знает, где и что можно переиспользовать, чтобы не придумывать продукт полностью с нуля
☐ Команда использует только простые решения на уровне MVP
☐ Услуга/сервис покрывает потребности 90%+ пользователей
☐ Участники команды не реализуют другие проекты одновременно с авральным
☐ Бизнес-аналитик сразу проектирует макеты
☐ Разработчик/системный аналитик сразу запрашивает у ведомства вид сведений и анализирует его
☐ Интеграционное тестирование начинается сразу, как появится возможность направлять документы в ведомство
☐ Коммуникация с ведомством ведётся с самого начала
Заключение
Собрать услугу за 44 часа так, чтобы в первые несколько суток ею смогли воспользоваться более 30 тыс. человек, — это серьёзный вызов, с которым наша команда справилась. Надеюсь, моя статья поможет вам в работе над вашими сервисами, подскажет, как можно сэкономить ресурсы (как временные, так и человеческие), будет способствовать минимизации и структурированию доработок после внедрения.
Желаю всем отсутствия релизов в пятницу вечером! Жду ваши вопросы в комментариях.