Как мы выстроили процесс работы с макетами
Меня зовут Алина Шилова, я работаю системным аналитиком над внутренними продуктами Tele2. Вот уже два года наша команда занимается разработкой портала для сотрудников компании. Специально для создания платформы была набрана команда. За 10 лет работы в ИТ-сфере это был мой первый опыт такого глобального запуска рабочих процессов с нуля, и в этой статье я хотела бы поделиться с аудиторией Хабра частью полученных знаний. Я расскажу о том, как мы настроили цикл работы с макетами — от их создания до сдачи разработчикам.
За время своей работы я сменила несколько десятков проектов в разных компаниях, но все они работали по методике Agile. И, несмотря на огромное разнообразие продуктов, команд и процессов, все эти Agile-проекты на моих глазах сталкивались с одним и тем же вызовом — непрекращающимися изменениями. Хочешь быть гибким, как обязывает Agile? Будь готов постоянно меняться. Сумел выстроить эффективный надежный процесс, работающий как часы? Молодец. Спустя несколько месяцев он все еще работает так же эффективно? Неужели опять что-то нужно менять? Добро пожаловать в мир Agile!
На самом деле не все так страшно. Мир сошел бы с ума, если бы под каждый частный случай приходилось заново изобретать велосипед. Безусловно, за основу всегда берутся наработанные годами общепринятые практики разработки ПО, управления командой и проектами. Вот только дьявол кроется в деталях. Возьми этот самый базовый велосипед из магазина и попробуй сразу поехать. Ехать-то он едет, да только тут рукам неудобно, там колено в руль упирается. А если немного подкрутить, подтянуть, высоту отрегулировать, какие-то детали заменить, то на таком кастомизированном велосипеде ездить — одно удовольствие! И силы расходуются гораздо эффективнее, и результаты выше. Поняли, к чему я клоню, да?
Процессы всегда нужно подстраивать под конкретный проект (сроки, бюджет, состав команды, внутрикорпоративные реалии), команду, продукт. То, что работало сегодня, завтра может потребовать пересмотра. И нет универсальной таблетки, которая вылечит именно вашу боль. Это всегда про набивание шишек и поиски оптимальных путей методом проб и ошибок. Но если подсмотреть опыт других, можно этот путь хотя бы чуточку сократить. Поэтому я и рассказываю историю нашей команды.
Первый состав команды
Всех процессов в одной статье не объять, поэтому сегодня поговорим о разработке макетов. Попробуйте на минуту оторвать себя от чтения и мысленно порассуждать, сколько человек в команде обычно занимаются макетами? Точнее даже так — сколько ролей? Первый, кто приходит в голову — конечно же, дизайнер. Но вряд ли он сам нарисовал, что захотел, а разработчики молча ушли кодить по тому ТЗ, которое получили. Наверное, надо с кем-то эти макеты обсудить, согласовать? Давайте разбираться.
Действительно, как правило, если продукт предполагает графический интерфейс, в команде есть специально выделенный человек — дизайнер пользовательских интерфейсов, UX/UI-дизайнер или как вам угодно его величать (а для простоты далее по тексту будем называть его просто дизайнером), который занимается проектированием интерфейса и отрисовкой макетов. Некоторые дизайнеры могут и прототип создать — тогда можно будет даже пощелкать по кнопочкам как в «живом» продукте, но это не настолько критично для процесса разработки, как статические макеты. Итак, с дизайнером все понятно: он — непосредственный автор макетов, без него вообще ничего не случится. Едем дальше.
Чтобы что-то нарисовать, очевидно нужно иметь некую идею о том, что должно получиться. Значит, должен быть человек, который эту идею в голову дизайнеру сложит. Тут возможны варианты. В некоторых командах взаимодействие построено так, что задачу дизайнеру ставит менеджер проекта, в некоторых — системный или бизнес-аналитик. В нашем случае все сильно сложнее.
Изначально коммуникацию с дизайнером вел исключительно владелец продукта, он же — носитель бизнес-требований. Владелец продукта отвечает за видение конечного результата, анализ потребностей пользователей продукта и формирование на основе этих вводных бизнес-требований к дальнейшему развитию продукта. То есть, он прошерстил тонны метрик, статистических показателей, опросников и из всей этой кучи цифр элегантным движением руки вытащил готовое требование, что нарисовать в новом разделе интерфейса — так что ли получается? Ах, если бы все было так просто.
На ранних этапах формирования команды мы тоже наступили на эти грабли и пошли по самому очевидному прямому пути: владелец продукта → дизайнер.
Эти двое прекрасно взаимодействовали в своем тесном кругу, создавали невероятной красоты макеты и счастливые приносили их команде. Да только беда: дальше идеи многие из этих макетов так и не уходили. Дело в том, что ни дизайнер, ни владелец продукта очень часто не имеют представления, как предложенная ими реализация интерфейса будет вписываться в текущую архитектуру приложения с технической точки зрения и, как следствие, в какие трудозатраты выльется разработка (а может и вообще ни в какие, если технические ограничения системы вообще не позволят реализовать задуманное). В итоге, когда после декомпозиции требования набегает 200+ часов кодинга на реализацию одного несчастного флажка в интерфейсе (ну, таковы уж запутанные интеграции в распределенной архитектуре, кто ж знал), менеджер проекта округляет глаза, мысленно подсчитав бюджет, и волевым решением отправляет требование на переработку. Ведь соотношение development cost и business value еще никто не отменял, извините.
+ системный аналитик
Очень скоро стало понятно, что такой процесс работает против нас и нужно что-то менять. Почесав репу, вспомнили про человека в команде, который знает обо всем понемногу и может ориентироваться в технических аспектах проекта хотя бы верхнеуровнево. И тогда на арену вышел системный аналитик. Так в процессе постановки требований на нашем проекте появилась стадия экспресс-анализа. Она заключается в том, что владелец продукта приносит бизнес-требование на оценку системному аналитику. Последний в свою очередь прикидывает, какие понадобятся доработки в системе, чтобы его реализовать, какие есть ограничения, нужно ли привлекать смежные команды. При необходимости может сбегать проконсультироваться к архитектору, фронтендеру, девопсу — куда понадобится, лишь бы все вводные уточнить. Из «образа прекрасного далека» в голове владельца продукта картина понемногу трансформируется в осязаемые технические характеристики. Отлично, теперь в нашей супергеройской команде, сражающейся за идеальные макеты, собрались владелец продукта, системный аналитик и дизайнер. Кажется, в таком виде шансы на успех прибавляются.
+ менеджер проекта
Но любой команде для эффективной работы нужен лидер, способный организовать и направить всю деятельность в нужное русло. Мы тоже прекрасно понимали, что работаем не в вакууме, а на вполне конкретном проекте, у которого есть свои сроки, бюджеты, ресурсы, приоритеты. Кто знает все про организационную сторону проекта и способен возглавить процесс управления требованиями? Менеджер проекта — превосходный кандидат! Чтобы синхронизировать все составляющие, описанные ранее, мы ввели так называемое предпланирование спринта. Это регулярная встреча, на которой собираются менеджер проекта, владелец продукта и системный аналитик и обсуждают требования, прошедшие стадию экспресс-анализа. Картина уже обрисована крупными мазками: по составу требований, ограничениям и доработкам все понятно, есть понимание по трудозатратам. На этом этапе менеджер проекта продумывает, как распределить ресурсы команды по задачам, согласует с владельцем продукта приоритеты, составляет план. Может какие-то требования подвинуть по срокам, отложить, предложить разбить на этапы реализации.
«Боже, сколько можно болтовни и согласований, когда вы уже просто нарисуете эти многострадальные макеты?», — наверное думает сейчас нетерпеливый читатель. Все, все, обещаю, на этом согласования закончены — владелец продукта формулирует бриф и ставит задачу дизайнеру.
А теперь по второму кругу
Пожалуй, самый понятный и неизменный этап во всем этом сложном процессе — собственно отрисовка макетов. В творческий процесс дизайнера свой нос совать не будем, это его внутренняя кухня. Нам же сейчас больше интересно, как созданный макет живет дальше по ходу разработки. И здесь мы с командой тоже насобирали свою порцию граблей. Как и на этапе постановки требования, этап согласования макета тоже исходно включал в себя только дизайнера и владельца продукта. Посмотрели они вместе на макет, обсудили, поправили и выдали команде разработки. Мол, вот вам финальный вариант — вперед, разрабатывайте.
Окей, допустим системный аналитик принял макеты в анализ, написал спецификацию, выполнил декомпозицию требования. Разработчики ушли кодить, а довольный аналитик — пить чай и созерцать проделанную работу. И вдруг на него начинает сыпаться шквал вопросов. «А если элементов будет больше, чем нарисовано на макете, мне карусельку вставлять?», «А пагинацию делать?», «На 404 картинка есть?», «Тут текст слишком длинный, его как отрисовать?» и мн.др.
Хм. Оказывается, визуализации всех успешных пользовательских сценариев было недостаточно. Придется снова бежать к дизайнеру, ждать, пока он оторвется от других задач, потом по результатам доработки макетов заводить дополнительные задачи разработчикам, а у них уже в спринте все время распланировано… Сроки едут, начинается какой-то хаос, менеджер проекта нервно курит, владелец продукта капает валерьянку.
+ системный аналитик (не опять, а снова)
Стоп, давайте успокоимся и отмотаем немного назад. Мы же уже это проходили: коммуникации одного лишь владельца продукта и дизайнера на этапе постановки требования было недостаточно. Может и на этапе согласования макета расширять круг лиц? По аналогии включаем в процесс системного аналитика?
Да, идея выглядит вполне рабочей, так мы и сделали. Добавили регулярные встречи дизайнера, владельца продукта и системного аналитика, на которых дизайнер показывает драфты макетов, владелец продукта высказывает свои пожелания с точки зрения продуктового видения, а системный аналитик проходится по своему чек-листу. Мой чек-лист со временем стал выглядеть вот так (если пригодится, берите на заметку):
Неуспешные пользовательские сценарии (сообщения об ошибках, подсветка незаполненных обязательных полей или введенных невалидных значений и т.п.).
Разная визуализация экрана в зависимости от роли пользователя.
Множественный ввод значений пользователем (если предполагается).
Отображение нестандартного контентного наполнения (очень много элементов, отсутствуют элементы, слишком длинный текст и т.д.).
Визуализация ненайденной страницы (то самое знаменитое 404).
Активное и отключенное состояние контролов.
Переходы по всем активным контролам (стрелка на другой экран либо текстовое описание, куда идет редирект).
Пагинация или указание, что должна быть динамическая подгрузка элементов на странице.
Неуспешные пользовательские сценарии (сообщения об ошибках, подсветка незаполненных обязательных полей или введенных невалидных значений и т.п.).
Разная визуализация экрана в зависимости от роли пользователя.
Множественный ввод значений пользователем (если предполагается).
Отображение нестандартного контентного наполнения (очень много элементов, отсутствуют элементы, слишком длинный текст и т.д.).
Визуализация ненайденной страницы (то самое знаменитое 404).
Активное и отключенное состояние контролов.
Переходы по всем активным контролам (стрелка на другой экран либо текстовое описание, куда идет редирект).
Пагинация или указание, что должна быть динамическая подгрузка элементов на странице.
+ стейкхолдеры, отлов ошибок и завершение
Становится все больше похоже на идеальную картинку процесса, который работает как часы, неправда ли? Желательно еще показать макеты ключевым стейкхоледрам и получить от них согласование, тогда жизнь вообще станет прекрасной. Этот момент тоже не сразу пришел нам в голову, ведь стандартно в процессе Agile предусмотрены демо в конце спринта, где разработчики показывают результат своей работы до выхода в продуктив. И мы шли этой проторенной дорогой. Пока в какой-то момент не получили на демо после огромной проделанной работы команды разработки удивленного заказчика, который ожидал увидеть нечто совсем другое (хотя формально требования были выполнены, но пользовательский путь в интерфейсе вызвал бурю дискуссий). Внимательный читатель помнит, что у нас внутренний продукт, и бизнес-заказчик всегда под рукой — HR-директор, отдел поддержки, бухгалтерия и т.п. Если у вас внешний коммерческий продукт, на этом этапе может быть полезно, например, показать черновой прототип фокус-группе и убедиться, что вы движетесь в нужном направлении.
В таком виде проект действительно существовал весьма эффективно, без больших промахов по трудозатратам, перепланирования и повторных итераций одного и того же этапа. Но нет предела совершенству.
+ разработчик
В какой-то момент красную лампочку включил фронтенд-разработчик. Проблема закралась в статике макетов. С помощью набора статических экранов довольно сложно передать изменения интерфейсных элементов в динамике. Отсюда возникают разночтения, дополнительные вопросы. А беготня с уточнениями между аналитиком и дизайнером, когда ты должен уже сидеть и спокойно себе кодить по детально расписанной спецификации — бесспорно существенный повод забить тревогу.
Что будем делать на этот раз? Изящным кликом в аутлуке добавляем фронтендера на регулярную встречу по ревью макетов. Наблюдаем, как все больше вопросов и предложений отлавливается на самом раннем этапе работы с драфтами макетов. А это золотое правило разработки: чем раньше проблему отловил, тем дешевле проекту обошлось ее решение.
На этом рассказ об удивительных приключениях макетов на нашем проекте подходит если не к концу (ведь, как мы помним, Agile беспощаден ко всему постоянному), то как минимум к некоторой передышке. Уверена, что на этом трансформация процессов не закончится. Но чем больше опыта мы копим, тем менее болезненно обходятся новые изменения.
