Лонгрид о том, как Роман Черных позвал цифровую артель «Eleven» провести у него в РШСД несколько мастер-классов. Как я в этом поучаствовал, что рассказал, какие выводы сделал. Ну и почему темой было выбрано именно «Техническое проектирование».
Об инфобизнесе и вообще
Для меня мастер-классы всегда были чем-то на грани мошенничества. Инфобизнес в целом склонен к преувеличению собственной полезности: легко представиться экспертом перед новичками. Некоторые виртуозы даже умудряются сколотить только на этом довольно громкое имя. К счастью, меня это не касается. Сейчас я выступаю не очень часто, да и раньше у меня были больше закрытые корпоративные сессии (на которых особенно не прославишься). Но именно мастер-классам я почему-то не доверял особенно. И тем интереснее стало предложение Ромы — его эвенты в РШСД обычно довольно занимательны. В общем, для меня этот мастер-класс был скорее этаким самоиспытанием, чем рядовым выступлением перед публикой.
Тем более, что моей задачей было не только донести до участников основы технического проектирования и рассказать, нафига вообще оно надо; от меня требовалось подготовить неискушенные кодингом мозги к настоящему взрыву. Ибо сразу за мной выступал еще один партнер бюро — Вадим Митякин, а у него там была полная функциональная жесть. Да, мы с Вадимом решили провести своеобразный эксперимент: разделили день на два мастер-класса, а участникам предложили восемь часов мозговыносящей программы.
Почему именно техническое проектирование?
Начнем с того, что на территории бывшего СССР смысл слова «дизайн» оказался порядком искажен: его истинное значение почти полностью подменено «проектированием» (да и последнее, когда речь заходит об IT, все больше скатывается в глубочайшую пучину юикса). Для меня же оба эти понятия куда шире и если не идентичны, то очень и очень близки. Оба они родом больше из инженерии, чем из иллюстрирования или живописи.
Явление дизайна значительно глубже, чем принято считать в русскоговорящих странах: дизайн должен решать реальные проблемы комплексно, а не просто выражать эстетические пристрастия дизайнера или провести пользователя за ручку по CJM. Для всего этого есть узкие специалисты: например, UI-UX-дизайнеры или даже вымирающий вид мифических «графических» дизайнеров. Не нужно вешать на них весь дизайн целиком, ведь дизайн — это и про воплощение продукта, про его техническое функционирование. Разработать (а тем более воплотить) дизайн сложного технического продукта не получится одним только юиксом.
И не нужно говорить мне про тонкости перевода: дизайн и design — это одно слово. У меня есть даже отдельный пост на эту тему.
Все изложенное — не просто мои измышления. Отрасль постепенно начинает понимать, что в ее рядах, сплоченных кубиклами, нарастает напряжение. Продукты становятся все сложнее; маркетинговые каналы переплетаются между собой, а пользовательский сценарий, простой и коротенький в MVP, к финальному релизу превращается в такую сантабарбару, что не умещается в тридцатидюймовый монитор, заслоняющий вид на горы. И проектирование, призванное, в числе прочего, упрощать разработку — вдруг ее усложняет. Отрасль задумывается, она не очень хочет в это верить, но откровенные факты лезут в глаза.
Так о чем этот пост? Если вкратце — то о том, почему проектировщики и продуктовые дизайнеры должны в обязательном порядке знать матчасть (хотя бы на базовом уровне). Почему неприемлем подход «кодеры разберутся» и какую цену заплатит бизнес, если вы считаете иначе.
Краткое изложение
Не стану подробно пересказывать все содержание мастер-класса, коснусь лишь основных тезисов. Я практик, поэтому все тезисы подкреплял реальными кейсами, однако каждый из них — это отдельная история, и здесь я расскажу лишь о нескольких. Если какой-то вопрос вас заинтересует — велкам в комменты.
Что такое техническое проектирование?
На самом деле, все просто. Техническое проектирование — это предварительное описание программной логики и средств реализации проекта. Определение довольно общее и, возможно, не точное — но вся соль не в нем, а в задачах ТП:
- Фиксация границ проекта. Реальных границ, а не тех, которые в голове у фаундеров.
- Поиск, определение и минимизация рисков, связанных с технической реализацией продукта.
- Выявление реальных интерфейсных возможностей.
- Оптимизация процесса разработки (это уже для суперпрофи).
Но обо всем по порядку.
Фиксация границ
Типа такого:
Запускаем децентрализованный сервис по автоматизации процесса телепортации домашних животных. Работать будет на блокчейне, монетизация за счет доставки питомцев от точек телепортации. MVP нужен через месяц.
Клиент
На самом деле, это хорошо: сразу ясно, что проект — чушь, а клиенту нужно еще побыть с собой. Однако куда чаще встречаются более сложные случаи, которые так просто не распознать. Причем речь идет не только о принципиальной невозможности реализации. Бывает, что пользовательские истории — это одно, а их техническое воплощение — совсем другое. И отнюдь не всегда эти самые границы нужно лишь сужать.
Безусловно, еще чаще именно UX становится фактором, обуславливающим границы проекта. Однако в пылу танцев вокруг HCD и восхищения собственной дальновидностью, очень легко забыть про самые приземленные вещи.
У каждого опытного пээма наберется тьма историй о том, как разработчики были вынуждены пилить чудовищные костыли, в пять раз увеличивая стоимость итерации — и все из-за того, что на этапе проектирования кто-то не озадачился до конца проверить возможности внешней интеграции или технических особенностей платформы.
Есть у меня на эту тему хороший факап. Втянули меня как-то в дизайн сервиса по оказанию неких услуг определенной категории граждан. Пять основных сценариев, три десятка второстепенных. Персонажей — можно в массовке снимать. Почти две сотни экранов. Сам сервис был абсолютно бесплатным, монетизация строилась на процентах с продаж партнеров: в сервисе был встроенный маркетплейс-агрегатор. Я тогда был еще совсем юн, только пришел в проектирование из кодинга, многого не понимал.
Конечно, мы выяснили, могут ли технически передавать нам данные товаров магазины. Даже выяснили, каким именно образом они будут это делать. Такие выдохнули: ок, могут, вот так. И поперли дальше, глубже не копая. А когда копнули, проект едва не заморозили. Потому что больше половины партнеров просто технически не могли передать нам в управление оплату и доставку. А уход пользователей на другой сайт был катастрофой — в сценариях покупка была частью достижения одного из профитов. Фреймы проблемы бы тоже не решили, так как платежный агрегатор, с которым должен был работать сервис, давал льготные условия только при определенном обороте. Итого: половина оборота, комиссия платежного агрегатора заоблачная, сервис нерентабелен. Расходимся.
Перещупали кучу вариантов, но в итоге отказались от маркетплейса в его изначальном виде. Поменяли два из пяти основных сценариев. Ввели подписную модель. Сервис запустился и даже через некоторое время окупился и принес какие-то деньги. Правда, все равно быстро сдох из-за маркетинга на аутсорсе, но в том уж моей вины нет.
Резюмируя. Если вы рассматриваете границы проекта только со стороны пользователей, вы можете очень легко выстрелить себе в ногу. Ну или не себе, а бизнесу, который вашу работу оплачивает.
Определение рисков
Что такое технические риски в программном продукте? В первую очередь, это какие-либо ограничения, которые необходимо разглядеть до начала разработки. Под техническими ограничениями я подразумеваю ограничения, связанные с серверными мощностями, с инфраструктурными особенностями, с особенностями внешних интеграций. Вместо того, чтобы разжевывать, что это значит, приведу простой пример.
Например, у нас есть сервис, в котором подразумевается генерация каких-нибудь сложных графиков в реальном времени. Такие графики могут серьезно нагружать серверный процессор (нужно будет производить большое количество просчетов на стороне сервера), сеть (гонять данные потоком по веб-сокетам) и клиентский браузер (все это безобразие нужно будет отрисовывать). Последнее — вообще напрямую влияет на пользовательский интерфейс. Поэтому иногда имеет смысл рассмотреть внешние системы для генерации (а это минус в скорости, плюс в заглушках/лоадерах) и минимальное количество одновременно выводимых графиков на клиенте (даже если «ну оочень надо»).
Или взять всеми любимые гугл-карты. Это же кладезь ограничений: от довольно жестких рамок на количество запросов (по ключу или с одного IP) до жутковатых схем серверной кластеризации маркеров (когда их становится много). Если вы не подумаете об этом на этапе проектирования, то в какой-то момент у пользователей может перестать отображаться карта; или мобильное приложение вылетит, сожрав всю оперативку. Вы можете сказать что-то типа «об этом должны думать программисты, а не я». Вообще нет, но окей, они подумают. А вы уверены, что вообще предусмотрели кластеризацию маркеров в своих сценариях? Или может, вам нравится, как выглядят интерфейсы, нарисованные программистами? Вряд ли.
В общем, ограничения/риски — это важно. Но чтобы их определить, не нужно знать о них все. Нужно уметь задавать правильные вопросы. И хотя бы примерно понимать, где искать ответы.
Выявление реальных интерфейсных возможностей
То, как пользователь будет взаимодействовать с вашим продуктом, напрямую зависит от того, как технически этот продукт реализован. Если у вас сайт, вряд ли вы будете основным способом взаимодействия делать свайпы. От того, какую технологию мобильного приложения вы выберете, будет зависеть все: от стоимости и сроков — до плавности анимации и даже использования теней у блоков. От того, каким способом вы решите получать данные в админке сервиса, будет зависеть эффективность работы менеджеров.
Вот допустим, есть у вас админка. Что-то типа CMS, для управления корпоративным блогом. И работают в ней два контент-менеджера. У них равные привилегии, они все могут изменять одни и те же записи. Один заходит, начинает править запись. Разметку, например. Цитаты там выравнивает, картинки центрирует. Другой заходит туда же, в эту же запись, и начинает поправлять ошибки. Синтаксические, орфографические. Один нажимает «Сохранить», другой нажимает «Сохранить». Что произойдет? Второй перезатрет к чертям изменения первого. Причем не важно, что первый провел два часа, выстраивая композицию, а второй только запятую добавил.
Решений тут несколько. Можно попробовать объединить изменения, и тут нас поджидают факапы со всякими оффлайнами и строковыми конфликтами. А можно блокировать запись для второго, пока первый не закончит — и выводить специальное сообщение. Или даже не давать второму вообще войти в запись, пока ее кто-то правит — прямо в списке сообщать, что «сейчас эту запись редактирует Василий» (чтобы второй контент-менеджер знал, кому крикнуть через весь оупенспейс). А еще надо давать возможность перехватить управление, например, через час — если первый вдруг забыл закрыть дома браузер и умотал в отпуск.
И да, все это нужно делать в реальном времени, чтобы второй не был вынужден обновлять страничку, ожидая, пока первый закончит. И уже тогда подтягивать изменения первого второму — снова в реальном времени.
Ну ок. Придумали, описали. А так вообще можно сделать? Этот сценарий реализуем? Или даже так: не проще ли забить болт на неудобство контентщиков, если реализация такой штуки будет стоить, как три месяца работы одного из них? Подсказка: можно, не проще. Такое довольно легко реализуется при помощи веб-сокетов — но это, на самом деле, вообще не уникальный случай. Порой куда правильнее забить.
Основная мысль проста: техническое проектирование напрямую влияет на все аспекты продукта — и на пользовательские сценарии в том числе. Вы должны понимать, как передаются данные и как они обрабатываются. В чем отличие синхронных запросов от асинхронных, в чем преимущество каждого и где какие стоит использовать.
Если вам не хватает знаний — общайтесь с командой. Даже если вы суперюиксер. Много нового узнаете о проекте. Или о себе, если общаться не будете, и тупо отправите документацию в топку кодинга.
Оптимизация процесса разработки
Это, если хотите, цель. Как правильно фиксировать функциональную часть проекта, какой рукой вытирать кровавый пот и почему за грамотную юмээльку кодеры продадут душу.
Оптимизация процесса — это такая емкая штука, что она заслуживает отдельного цикла лекций, мастер-классов и культа. Те, кто только начинают копать техническое проектирование — вот вам четкий ориентир. Когда вы сможете не только персонажей с сиджиэмками рисовать, но и детально описать программную логику продукта, структуру базы данных и прочие прелести — вот тогда можете встать и сказать: да ну вас нафик с такой зарплатой, я теперь знаю техническое проектирование.
Программисты не должны создавать программную архитектуру сложного с точки зрения UX проекта. Вернее, это должны делать не только и не столько программисты. Архитектура, компоненты, программная логика — это штуки, напрямую зависимые от внешней части проекта. Что, впрочем, справедливо и в обратную сторону: интерфейсы и их поведение зависят от своей реализации. Как вы собираетесь продумывать нюансы пользовательского взаимодействия, если слабо представляете себе, на что теоретически способен ваш продукт или даже как он будет вообще работать?
Всегда проще разрабатывать систему, если она описана до старта кодинга. Не обязательно всю, детально и целиком. Архитектурно — в целом, какой-нибудь функциональный раздел — в частности. Ну а там проектирование и разработку можно запускать внахлест.
К примеру, у вас есть десяток похожих действий в приложении: допустим, шаринг. И еще десяток: например, логин в разных местах. И еще: асинхронная подгрузка элементов при скролле, обновление списков свайпом вниз, отправка сообщений, что-то еще. И все это повторяется, перемешивается, усложняя разработчику анализ вашего документа. А ведь нужно еще учесть функциональные разделы: раздел с аутентификацией/регистрацией, раздел профиля пользователя, раздел настроек, новостной раздел и так далее. А еще — сервисы развиваются. И не всегда можно сказать, куда попрет.
Большинство даже хороших программных архитекторов работает с данными. То есть: вы им засунули описание, они выдали архитектуру. Они редко анализируют бизнес-требования. Они могут и не знать, что вот эта маленькая функция потенциально родственна вот той маленькой, что их стоит объединить для того, чтобы впоследствии не городить кучу велокостылей.
Понимаю, что это несколько сложно для вот такого, теоретического понимания. Но в рамках одной статьи, а тем более — раздела этой статьи, не получится рассказать всего. Если сообщество изъявит желание, я накидаю отдельный пост (или даже цикл) про оптимизацию разработки дизайном.
Практическая часть
У кого-то может остаться чувство, что, мол, это все клево, но у меня проект маленький, я как-нибудь обойдусь. Или «процессы в компании уже заточены, не мне их менять». Или «блин, это так сложно, ну нафик, проектировал как-то раньше». Ну и подобные отмазки.
Поэтому в мастер-классе была довольно объемная практическая часть, где участникам предлагалось крупными мазками спроектировать работу несложного вроде сервиса. Победить должен был тот, кто спроектирует его так, чтобы команда разработки не страдала мигренью, а бюджет проекта не приблизился к ВВП Гондураса.
Заглавный слайд практической части назывался «сейчас вы завалите проект» — что, в общем-то, и случилось. Не победил никто, а большинство его все-таки откровенно завалило. Хотя справедливости ради стоит отметить, что несколько человек были очень близки, а кое-то даже нашел потенциальную уязвимость в моей схеме.
Выводы
Очень интересно было наблюдать за трансформацией отношения участников (большинство из которых являются действующими UX’ерами) к техническому проектированию. На мастер-классе у тебя куда больший контакт с залом, нежели на обычном докладе: ты задаешь и отвечаешь на вопросы, выстраиваешь свой рассказ, исходя из ответов. И если поначалу большинство относилось к ТП несколько скептически, то к концу практической части даже разгорелась небольшая дискуссия о том, как и где стоит хранить данные, чтобы пользователи не испытали дискомфорта и решили свои задачи.
При этом факт остается фактом: практическую часть завершили (пусть и не идеально) только два человека. Так и было задумано, конечно. Нет более четкого стимула приступить к изучению предмета, чем собственный фэйл, с ним связанный. Однако еще это может значить, что наш, российский дизайн несколько хромает по части технической подготовки (и начинает это осознавать). Что скоро упомянутая мною Отрасль окончательно перестанет игнорировать комплексный подход к продуктовому дизайну.
Сервис-то реально нужно было спроектировать не сложный. И всего-то предусмотреть потенциальные фэйлы и при необходимости отказаться от каких-то функций. Даже знаний никаких не нужно было особенных — просто уметь задавать правильные вопросы.
