Привет! С вами Таня Тихомирова, Lead Systems Analyst и SA Community Lead. Я много читаю, в том числе всё, что нахожу о процессе Discovery, сборе требований и первых подходах к прототипированию в IT-разработке. Так что про вакуум и теории воздушных замков могу рассказать очень красиво. Но кому это интересно? Мне — нет, а вам? Готовьте попкорн: расскажу вам про «ванильность» этих фреймворков, когда дело доходит до «кровавого» enterprise.
Кроме любимой работы, много чего успевается при желании. В том числе масштабный ремонт с кардинальным сносом всех стен и возведением их заново. Вчера общалась с прорабом с моей стройки, говорит, мастера интересуются, почему «Тане всё время нужен космос?! Очередная космическая идея! И почему так всегда?!» Профессиональная трансформация: все вокруг теперь хочется сделать космически красивым.
В IT у нас своя стройка: такая же команда из небольшого количества людей, но со все увеличивающимся количеством компетенций в каждом. Хочешь быть в тренде? Хочешь быть звездой? Ну или хотя бы просто востребованным специалистом? Все просто: надо постоянно учиться, а главное — много читать.
Читаю я много, в том числе про процесс Discovery, сбор требований и первые подходы к прототипированию. К сожалению, в реальных условиях разработки применить описанные подходы не всегда получается.
Эти очерки — наш с Аней совместный очередной подход к теме понимания и оптимизации discovery-процесса. Нам важно постоянно учиться, изучать новые статьи, чтобы понять тенденции, найти актуальное и применить в работе. Смотрим одни и те же источники, сравниваем с прошлыми знаниями. Нет, опять красиво, но не про наш «кровавый» enterprise. Почему так получается?
Мобильная разработка: не просто, а юзабилити с умом
Давайте задумаемся: часто ли вы видите мобильное приложение с настолько убогим дизайном, что его пора актуализировать уже лет 10 как? Предположу, что нечасто. И кстати, не потому что мобильные приложения появились гораздо позже desktop'ных. Просто подход к разработке совершенно разный. И идеальный discovery-процесс в голове, когда про него читаешь, приземляется именно на мобильную разработку в первую очередь. А если хорошо подумать, то только на неё.
В этих описаниях присутствует Product Owner, UX-исследователь, UX/UI или даже продуктовый дизайнер, иногда подчеркивается важность бизнес-эксперта. Периодически упоминается аналитик — чаще всего data analyst, который собирает данные для первых двух товарищей. Если упростить, то весь discovery-процесс из этих описаний можно свести к тому, что dream team из перечисленных специалистов что-то анализирует, исследует, прототипирует и всё — идеальный прототип готов. Теперь, внимание! Dev-команда должна это реализовать.
Любопытно, что для мобилки такой подход сработает. И вот, почему:
- Мобильные приложения редко опережают в своих идеях основную разработку. Они скорее адаптируют уже существующий опыт и возможности основных web-app компании. А значит, используют уже готовые сервисы. В итоге мобильная разработка — это именно про максимум исследований UX, чтобы построить классный UI и про опыт пользователя, который важно не повторить, а оптимизировать и даже упростить для мобильного пользователя.
Backend у мобилки свой тоже есть, бывает, команды строят космос, но это скорее исключения. Если в игру вступает системный аналитик, он легко может эту ситуацию поменять, грамотно жонглируя знаниями о существующих в компании сервисах. В итоге сократить количество собственной логики за счёт переиспользования уже существующих, в целом совершенствуя подход к построению архитектуры в своем проекте.
- Вероятно, Аня кинет в меня камень, но на мой взгляд, UX в мобилке часто довольно простой и должен таким быть, это же мобилка: у пользователя есть только один палец на все манипуляции, максимум — два. Поэтому процессы должны быть простые, а, значит, и сервисы переиспользовать проще и правильнее, чем писать свои.
Но в «кровавом» enterprise редко мобильные приложения стоят в авангарде (если только мы не говорим про маркетплейсы). У всех прочих мобильные приложения — скорее канал второстепенный, тоже важный, и, тем не менее, не основной. Даже если с них начинается знакомство будущего пользователя с основной разработкой.
На практике разработка сложных систем с таким процессом discovery вообще не справится. Если вы считаете обратное, рискну предположить, что вы либо только в начале пути, либо уже успели докрутить шаблонный процесс под себя, причем так виртуозно, что даже сами заметили :)
Системная архитектура «большого» бизнеса — это challenge для сильных духом
Сейчас большинство крупных игроков в различных сегментах (я говорю о тех, у кого есть собственная home-разработка), если не все, стремятся избавиться от legacy, распилить монолиты и уйти в микросервисы. И все мы понимаем, насколько сложные задачи стоят перед нами, когда мы говорим о распределенных системах, об асинхронном взаимодействии, о необходимости это всё каким-то неведомым образом объединить в единый «организм» вкупе с желанием бизнеса стараться сделать не меньше, чем AS IS, то есть не меняя привычек пользователя.
В такой ситуации наивно полагать, что красивый идеальный прототип от UX/UI-дизайнера и бизнес-эксперта можно «просто приземлить на технику». Это не сработает в 99% случаев — «просто» не получится и не «просто» тоже не получится. Потому что здесь «космос» внутри продукта, а дизайнер уже снаружи целую Вселенную нарисовал. Как две параллельные прямые, эти Вселенные никогда не пересекутся, или, как касательная и график, встретятся лишь однажды. «Математике известна настоящая драма». А теперь и некоторым IT-подразделениям крупных игроков рынка с таким discovery-процессом настоящая драма тоже известна.
Вот к чему приводят попытки приземлить этот ванильный discovery на задачи, которые ставит перед нами, участниками команд-разработки, «большой» бизнес:
«Проседанию» сроков и даже срывам: ведь прекрасные макеты будущего на текущую ситуацию никак не приземлить.
Текучке хороших кадров: потому что собирать требования и проектировать макеты месяцами, а потом их положить в стол — это стресс, который не каждому под силу пережить.
- Созданию не оптимального и сильно урезанного UX, потому что сначала пытались выделить посильный MVP, а «потом» так и не настало.
На нашем проекте было это всё. И если раньше встречались не все проблемы сразу и на разных проектах, то на нынешнем было прямо сразу всё! Потому что, как тонко подметила Аня в прошлой статье,
проектирование сложной системы вскрывает все слабые места процесса.
И тут было важно понять, чего мы хотим: делать, как получится, с учётом этих ограничений? Или что-то изменить, чтобы строить космос не только внутри?
Это сложно, нигде не описано, как строить космолеты. Да еще этот бизнес наседает со своими сроками. Как суметь в них уложиться, построив космолёт, за который не будет стыдно?
Наверное, мы — безумцы нового времени, потому что для нас это был повод на практике проверить гипотезу о том, что надо строить свой «лунапарк с блэк-джеком и поэтессами». Мы попробовали всё, что описано, начали заново и придумали свой discovery-процесс. Теперь хочется делать только космос, причём не только на работе. Видимо, иначе я уже не могу.