О заказчиках

Заказчиками на проекте выступали две компании. Чтобы соблюсти соглашение о неразглашении и при этом не запутать нашего читателя, дадим им кодовые названия:

ГК «ФармАльфа» — автор идеи и конечный заказчик приложения МИС. Это группа фармацевтических компаний, одна из крупнейших в России.

ООО «IT-Бета» — дочерняя IT-компания «ФармАльфа». Занималась разработкой приложения и внедряла в него наш дизайн.

О проекте

Команда fuse8

Руководитель проекта
Вениамин Мустафин

Дизайнеры
Алексей Пилишков
Наталья Календарёва
Александр Ефремов

Фронтенд-разработчики
Владимир Лысов
Юлия Поспелова

Команда «ФармАльфа»

Руководитель отдела маркетинга

Врачи, представители частных клиник

Специалисты по продвижению IT-сервисов в сфере медицины

Команда «IT-Бета»

Руководитель отдела разработки 

Разработчики

Дизайнер

Пролог

Когда к проекту присоединились мы, у МИС была первая рабочая версия — для мобильных устройств и десктопа. Интерфейс существующего приложения и логика его работы не устраивали заказчика. Приложение выглядело устаревшим, тяжеловесным и непонятным для пользователей. Поэтому «ФармАльфа» начала искать студию, которая могла бы проанализировать МИС, понять, что с ним не так и спроектировать новый удобный интерфейс приложения. Такой студией стали мы. 

Глава первая: знакомство

Собираем требования

Работу над проектом мы начали со сбора требований. Нам важно было знать о МИС всё — что это за приложение, что в нём можно делать, кто и как будет им пользоваться. Чтобы выяснить все это, мы провели несколько встреч с заказчиком.

Сперва «ФармАльфа» и разработчики из «IT-Бета» презентовали нам уже существующее приложения и показали всю его функциональность.

Затем мы обсудили целевую аудиторию приложения — пол, возраст, уровень достатка, регион проживания и т.д. Поскольку в первую очередь в каталог МИС попадали частные клиники, особое внимание уделяли характеристикам потребителей платных медицинских услуг. 

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

Планируем работы по проекту

После сбора требований вместе с «ФармАльфа» мы отметили, что совершенно точно должно остаться в новой версии МИС, и зафиксировали это в Функциональных требованиях. Функциональные требования — это обязательный минимум.  Меньше нельзя, больше — можно, но только если это оправдано нашей основной целью — создать понятный и удобный интерфейс приложения. 

Мы работали над проектом вместе с «IT-Бета». На нас — проектирование интерфейса и дизайн, на них — разработка и внедрение. Чтобы не растягивать сроки и не заваливать наших коллег сразу всеми макетами, мы решили двигаться по проекту поэтапно: закончили разработку интерфейса и дизайн страниц первого этапа — отдали в разработку «IT-Бета». Пока программисты внедряли новый дизайн в МИС, мы работали над следующим этапом. 

1 этап — интерфейс записи к врачу

• Выбор врача
• Карточка врача
• Выбор даты и времени приема
• Календарь пациента
• Просмотр информации о событии
• Просмотр событий на текущую дату

2 этап — интерфейс личного кабинета пациента

• Главная страница
• Личный кабинет
• Дневник здоровья
• Электронная медицинская карта
• Совокупные рекомендации

3 этап — интерфейс справочных страниц МИС

• Мои анкеты
• Справочник врачей и клиник
• Обратная связь

Глава вторая: аудит

Чтобы создать удобный и понятный новый интерфейс, нужно было понять, что не так со старым. Для этого мы провели аудит МИС. Придерживались стандартного для нас плана действий:

1. Проанализировали конкурентов.
2. Поговорили с пользователями, изучили их потребности и создали их портреты.
3. Зафиксировали сценарии использования МИС.
4. Прогнали наших персонажей по этим сценариям.
5. Отметили, где интерфейс путает пользователей или заводит их в тупик.
6. Зафиксировали всё в отчете по аудиту и предложили решения конкретных интерфейсных проблем. 

Анализируем конкурентов 

Нам хотелось понять, в чем конкуренты опережают МИС, что у них реализовано хорошо, а что не очень. Какими‑то решениям мы вдохновлялись, а что‑то занесли в список «ни в коем случае не повторять это».

Мы отобрали несколько приложений с интерфейсом поиска врача, выписали в таблицу всю их функциональность и сравнили между собой. Оценивали и существующий интерфейс МИС. 

В этой же таблице мы вместе со специалистами «ФармАльфа» отмечали приоритет функциональности для МИС, где А — высокий приоритет, а С — низкий.

Создаем портреты пользователей МИС

Закончив с анализом конкурентов, мы приступили к детальной проработке портретов пользователей МИС. Для этого мы еще раз обратились к исследованию ЦА от «ФармАльфы» и провели несколько интервью с людьми, которые пользуются услугами частных клиник.

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

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

Формируем сценарии использования МИС

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

• Павел должен был записаться на прием к урологу в клинику рядом с домом или работой в самое ближайшее время. Он нашел приложение МИС в интернете и решил опробовать его.
• У Натальи заболел сын, но с работы ее не отпустили. Пришлось искать педиатра в частной клинике, чтобы подруга, которая согласилась отвести ребенка Натальи к врачу, не сидела долго в очереди в бесплатной поликлинике.
• Жанну настиг приступ мигрени прямо на рабочем месте. Обезболивающее не помогло, но Жанна вспомнила, что ее подруга недавно посоветовала ей хорошего невролога — доктора Подшивалину. Жанна хочет записаться на прием именно к ней.

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

Проводим аудит по сценариям

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

По созданным сценариям мы провели Павла, Наталью и Жанну через существующий интерфейс МИС. И зафиксировали, на каких шагах у них возникают проблемы.

Результаты исследований мы оформили в отчет и презентовали его заказчику. Зафиксировали комментарии и замечания и отправились работать над следующим важным этапом проекта — проектированием и прототипированием нового интерфейса МИС.

Глава третья: проектирование и прототипирование

Подведем промежуточный итог. На этом этапе у нас уже были:

• понимание, кто наши пользователи и что им нужно;
• сценарии использования приложения МИС;
• интерфейс, который ломал эти сценарии и мешал пользователям достигнуть желаемого.

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

Проектируем интерфейс

Мы снова изолировались в переговорке и приступили к работе.

Мы продумывали, как сделать путь пользователя до цели максимально быстрым, удобным и понятным. Фактически, мы выстраивали новую логику работы МИС, упрощали ее.

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

Детализируем прототипы

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

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

На этом этапе нам важно было получить полный фидбек от заказчика — чтобы быть уверенными, что мы движемся в правильном направлении. Поэтому, в течение всей работы над прототипами мы часто встречались с «ФармАльфой» и «IT-бетой» — презентовали им результаты, проводили по новым сценариям работы МИС и собирали замечания.

Все замечания, предложения и пожелания выписывали в отдельную таблицу, ранжировали по приоритетности и отмечали готовность методом светофора:

Глава четвертая: дизайн и передача в разработку

На этап дизайна мы вышли с максимально детализированными прототипами и с брендбуком, который нам предоставили в «ФармАльфа».

Cоздаем дизайн-макеты

У заказчика был еще один сайт-сервис медицинский тематики. И в «ФармАльфа» хотели, чтобы МИС был похож на него. Поэтому, работая над макетами для МИС, мы опирались на фирменный стиль, цвета и шрифты из брендбука этого сайта.

В процессе работы над макетами мы добавили в существующий брендбук новые оттенки цветов (в том числе и для темной темы МИС), иконки и другие элементы.

Формируем дизайн-систему

Мы знали, что после окончания нашего проекта «ФармАльфа» и «IT-бета» продолжат поддерживать и развивать МИС. Чтобы со стороны дизайна у них не возникало с этим сложностей, мы подготовили дизайн-систему и собрали в неё все наши наработки.

Теперь, если понадобится добавить какой‑то компонент в МИС, не возникнет вопросов, как он должен выглядеть, — всё есть в дизайн-системе.

Передаем дизайны в разработку

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

В ТЗ и дизайн-документах мы детально описали новое приложение, логику его работы и поведение всех компонентов и элементов МИС. Это облегчило задачу ребятам из «IT-бета», которые занимались разработкой новой версии приложения и внедрением наших дизайнов.

Результат

Результатами нашей работы на этом проекте стали: прототипы и дизайн-макеты интерфейса приложениям МИС (мобильная и десктоп-версии), дизайн-система приложения, технические задания и дизайн-документы для команды разработчиков.

Дальше за дело взялись специалисты из «IT-бета». Опираясь на наши дизайны, они разработали и запустили новую версию МИС.

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

Предположим, вы изучили язык, фреймворк, инструменты, получили опыт разработки и теперь стоите на распутье:

Путь 1 enterprise разработка: микросервисная архитектура, СУБД, очереди, gRPC и проч.

Путь 2 геймдев: Unity

Путь 3 CMS (content management system) и DXP (digital experience platform): Kentico, Sitecore, Optimizely

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

Что такое enterprise 

Из чего состоит типичное энтерпрайз приложение

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

Логирование. Недостаточно просто настроить его, нужно подобрать сервис, который будет сохранять логи. Без логирования зачастую невозможно разобраться в проблемах на проде, невозможно восстановить какие‑то артефакты. 

Метрики и хелсчеки. Мы не можем, запустив проект, отправить уже созданную его часть в свободное плавание, пока сидим и разрабатываем следующую. Сервис может и упасть, а мы этого не узнаем. Падения – это всегда финансовые потери для бизнеса, а их быть не должно. Чтобы их избежать, нужно превентивно, на основании бизнес-метрик, понять, что   идет не так, и исправить ситуацию. 

Помимо логирования стоит предусмотреть error tracking или трекинг исключений и сервис, который будет хранить ошибки отдельно. Трекинг-сервис помогает группировать, анализировать и фильтровать ошибки, отслеживать их частоту, предоставляет более детальную информацию, чем логи, и быстро отправляет нотификации об ошибках. Можно интегрировать трекинг ошибок с чатами. А еще можно создать кастомные интеграции, чтобы, например, сервис отправлял сообщения об обнаруженных ошибках на телефоны разработчиков. 

Внутри enterprise приложения должно быть настроено эффективное общение между сервисами: задачи должны выполняться своевременно, нагрузка – распределяться равномерно. В этом помогут очередь, шина, или планировщик задач.  

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

Если у нас монолит, мы можем кэшировать данные в памяти. Если микросервисы и для каждого отдельного сервиса могут подниматься несколько инстансов – кэшировать в памяти каждого не выйдет. Не понятно как это потом синхронно обновлять. В таких случаях на помощь приходит распределенный кэш: отдельно поднимается сервис, который хранит определенные данные и предоставляет быстрый доступ к ним. Как правило, это key-value хранилище.

Отдельные файловые хранилища. Зачем? За тем, что хранить файлы просто на диске – не удобно. Хранить файлы в базе данных – проблемно. Поэтому зачастую в enterprise проектах используются отдельные файловые хранилища. Это еще один инфраструктурный сервис. 

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

Отдельный блок – code style и анализаторы. Когда команда уже большая или среднего размера, каждый может писать код по-своему. Это порой вызывает споры на код-ревью. Поэтому зачастую на enterprise проектах используются анализаторы, которые помогают автоматически находить проблемы, потенциальные ошибки и проверять единый code style.

За что любят enterprise разработку

• Возможность использовать самый последний стек технологий.
• Возможность совершенствовать свой код на протяжении долгого времени.
• Полное погружение в доменную область бизнеса.
• Работа с разными библиотеками и инфраструктурными сервисами.
• Самостоятельное проектирование БД и архитектуры приложения.
• Хорошая документация по проекту.
• Налаженный процесс полного цикла реализации задач.

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

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

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

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

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

Что почитать по теме

Зачем вообще проводить демо? Есть же дизайны, детально расписанные юзер стори или ТЗ, критерии приемки. В конце концов, есть люди с зарплатой, которые проверяют, соответствует ли разработанное нами требованиям заказчика. Профит демо как процесса выражается в ценностях для заказчика и исполнителя. 

Ценность для заказчика. Демо дает возможность потрогать продукт еще на этапе разработки и скорректировать ее курс — может, понадобится пересмотреть юзер стори, пофиксить что-то, добавить или наоборот убрать. 

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

Есть множество практик проведения демо. Некоторые очень распространены. Другие используются редко. Демо — вообще весьма индивидуальный процесс для каждой команды (особенно при отсутствии зафиксированных регламентов проведения демо). 

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

Итак, мы условно разделяем клиентское демо на два основных этапа — подготовка и «экшон».

Подготовка к демо 

Есть простой постулат о тяжести в учении и легкости в работе. Можно его переформулировать в тяжесть подготовки и легкость проведения демо. Серьезно, если потратить на подготовку достаточно времени, можно серьезно облегчить себе задачу на демонстрации. Вот, как к демо готовимся мы: 

Пишем сценарий или демо-документ

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

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

Чтобы заранее определить ход демо, мы готовим специальный документ. Сценарий, если угодно. Его лаконичность полностью в нашей власти: можно расписать все подробнейшим образом и сделать заметки для каждого из участников процесса, или ограничиться ссылками с названием компонентов/страниц. 

Тот же документ можно расшарить с клиентом и предложить ему прописать в секциях фидбэк.

По моим наблюдениям, это нередко добавляет баллов команде-исполнителю, показывает, что ей  и  правда интересно мнение клиента о  продемонстрированных фичах.

Готовим среду

Следующий шаг — подготовить подходящую для демонстрации среду. Важно убедиться, что: 

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

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

Но тем не менее, если у нас в локали лежит добротная фича, которой по каким‑то причинам нет на стейджинге (неполная реализация/работа только при участии духовых инструментов/не успели залить), а откровенно нового в демо мало — мы ее покажем! В конце концов, почему бы приятно не удивить клиента? ;) 

Распределяем обязанности и роли

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

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

Есть несколько причин, по которым стоит привлечь к проведению демо всю команду: 

• это снимает нагрузку с тимлида: все-таки одному человеку тяжело своими силами провести часовое демо; 
• необходимость презентовать культивирует более ответственное отношение к результатам своего труда;
• это повышает качество демо: лучше всего разработанный функциональность может представить именно тот, кто ее разрабатывал; 
• это дает возможность всей команде похвастаться «детищем», который они произвели на свет.

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

Проводим внутреннее демо

Это опциональный шаг, который особенно ценен обычно на ранних этапах или в новых командах, которые еще не до конца сработаны, но не будем обделять его вниманием. 

Часто даже у такого незначительно события, как свадьба, есть репетиция.  И нам тоже было бы неплохо ее провести. К тому же,  в отличие от свадьбы, репетиция демо принесет нам существенно больше профита. Ведь именно на этом этапе часто можно заметить/отловить огрехи, которые были допущены в процессе подготовки.

Пара советов для повышения продуктивности внутреннего демо:

• Позовите на демо в качестве таргетируемой аудитории менеджеров проекта, продакт-оунеров и других людей, причастных к процессам и проверкам разрабатываемой вами функциональности. Они обязательно накидают полезного фидбека.
• Проводите внутреннее демо за пару-тройку дней до основного, чтобы материал и ход презентации были достаточно свежими в голове, и при этом осталось время внести какие‑то критичные правки на основе полученного фидбэка; 

На этом с подготовкой мы закончили. Осталось пробежаться по чек-листу, убедиться, что мы ничего не забыли, и ждать назначенного дня и часа нашего основного «экшона»!

Проведение демо

Итак, мы всё подготовили, сверились с приведенным выше чек-листом и назначили встречу с клиентом. Открыт демо-документ и вкладки с нужными страницами, команда в сборе и знает, что делать. Чтобы все прошло гладко, вот еще несколько моментов, о которых стоит помнить уже непосредственно на самом демо. 

Управление ожиданиями

Здорово, когда команда понимает, чего ждет клиент от каждого конкретного демо. Великолепно если команда еще и может все эти ожидания оправдать. А если нет? В этом случае лучше сразу дать клиенту понять, что столь вожделенный конструктор видео-каруселей к демонстрации пока не готов — то есть, фактически, снизить ожидания еще на старте. 

Хорошая практика — перед началом демо обозначить повестку и кратко обрисовать, что и в каком порядке вы будете демонстрировать. Это поможет клиенту скорректировать ожидания о предстоящем демо и понять, какие именно компоненты и функциональность он сможет увидеть и «пощупать» прямо сейчас. 

Сторителлинг вместо сухих перечислений

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

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

Мы в таких случаях стараемся придерживаться трех правил демонстрации: 

1. Рассказываем о сложных и «скучных» компонентах через сценарии их использования. 
2. Показываем пользу разработанной нами функциональности для конкретных пользователей. 
3. Приводим много примеров и выделяем время для ответов на вопросы клиента.

Нет ❌🙅‍♀️

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

Да ✅💁‍♀️

Это инструмент для работы с  данными из  каталога интернет-магазина. С  его помощью контент-менеджеры могут: загрузить или удалить товары, отредактировать описание товара, добавить изображение и  т.д. Сейчас мы  покажем, как всё это работает.

*показываем*

Чтобы менеджерам было удобно работать сразу с  большим объемом товаров, мы  добавили ...

Есть ли у  вас какие‑то вопросы или пожелания по  работе этого инструмента?

Упор на то, что интересно клиенту

Часто команда, которая проводит демо, может зациклиться на визуале и забыть нормально описать функциональность. Или наоборот — слишком углубляются в функциональную составляющую и технические нюансы, упуская внешний вид. Но как понять, что важнее в каждом конкретном демо? Ответ — в вашем клиенте! 

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

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

Сбор фидбека

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

Положительный фидбек

Если фидбэк исключительно положительный — поздравляю! Скорее всего, вы отлично понимаете, что именно хочет клиент. Конечно, есть вероятность, что вы показывали дизайн инженерам, которым на эстетику, в общем-то, плевать. Но это вряд ли)) Опустим этот вариант и остановимся на том, в котором вы просто идеально провели демо. 

Что же можно сделать с исключительно положительным фидбеком?  

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

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

Отрицательный фидбек

Отрицательный фидбэк — удивительная штука. Его довольно неприятно получать, но по части полезности он превосходит положительный. А еще с отрицательным фидбеком (если он по делу) зачастую проще работать: если клиент недоволен скоростью загрузки приложения — это значит, что скорость загрузки приложения нужно увеличить.  Да, пример утрирован, но отрицательный фидбэк действительно довольно четко обозначает конкретную проблему, о которой вы могли и не догадываться до демо.

Иногда в рамках отрицательного фидбэка можно услышать про отсутствие фич, которые вообще не были запланированы в документации. И это не повод расстраиваться! Всегда можно обсудить с клиентом расширение скоупа проекта или скорректировать план следующих спринтов разработки.

В общем, мораль такова: негативный фидбек — это точки роста, поле для развития и еще один повод становиться лучше. Мыслим позитивно и фиксируем все замечания, чтобы принять решение по ним позднее!  

Если фидбека мало

Если есть ощущение, что фидбэка недостаточно, мы просим еще. И, чтобы помочь клиенту и разговорить его, начинаем задавать вопросы. Много вопросов! 

Например, можно узнать мнение о конкретных компонентах и функциональностях, задавая закрые вопросы: «Поведение этого компонента для анонимного пользователя прописано в ТЗ размыто, он должен показываться ему или нет?». 

А открытые вопросы помогут настроить клиента «на порефлексировать» — что понравилось, что не понравилось, а если бы было так, а не иначе и т.д.

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

Лайфхак: демо может быть неофициальным

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

Каждый цикл разработки в себе имеет определенные артефакты: итерации планирования, дейлики и демо, например, по понедельникам. Мы на некоторых проектах видоизменяем регулярные демо на уровне концепции: превращаем их из клиентских согласований в мероприятия, где клиент выступает вольнослушателем. Зовем клиента в каждый недельноспринтовый созвон, но приходить или нет он решает сам. Эти демо мы проводим преимущественно скорее для себя, чтобы синхронизироваться внутри команды и быть хорошо погруженными на протяжение всей работы. Так и планировать легче.

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

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

Что происходит после демо

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

Обычно мы разбираем фидбэк по зонам ответственности и распределяем по исполнителям. Огрехи разработки уходят разработчикам на ремонт. Туманные моменты в ТЗ, — людям, ответственным за написание документации на прояснение. Хотелки, всплывшие во время демо, — руководителям и менеджерам проекта. 

Заключение

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

Ну и пара советов в заключение: 

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

Удачи!

Автор статьи: Кирилл Кодин

Редактура: Марина Медведева

Какие-то фичи окажутся сложнее, чем предполагалось. Подрядчик сорвет интеграцию. Заказчик внезапно придет с «а давайте еще вот это» и «вот прям обязательно». И всё — план (или его часть) превращается в тыкву. Однако глобально ничьей вины в этом нет — так разрабатывается любой реальный продукт, в котором бизнес действительно нуждается.

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

Что такое FFF

Fixed Time. Fixed Budget. Flexed Scope.
Три F, три опоры.

• Время фиксировано. Мы не вываливаемся из дедлайна.
• Бюджет фиксирован. Мы не требуем дополнительных денег за разработку в рамках зафиксированного срока.
• Функциональность гибкая. Мы адаптируемся — и сохраняем результат в рамках времени и денег.

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

Появляется новая задача — значит, от чего‑то нужно отказаться. Что‑то пошло не так — пересобираем скоп. Главное — к установленному сроку есть продукт, который работает и нужен. Он не раздут комом спорных фичей, не находится в бесконечной бете. А законченный и – главное – работающий MVP.

Пару слов об MVP

Прежде чем углубиться в прелести FFF, нам с вами важно договориться о базовом термине. MVP — это не «вырезали всё, что не влезло, и хоть что‑то показали». Это не черновик продукта, не его прототип. Не «ну, оно запускается — и ладно».

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

Когда мы говорим «флексить» в контексте FFF, мы не предлагаем забить на всё. Мы предлагаем трезво посмотреть на то, что реально нужно, чтобы MVP стал живым, рабочим продуктом. И всё, что выходит за рамки этой цели — может быть честно отложено.

Почему FFF лучше, чем «традиционные» подходы

Waterfall

Старый-добрый водопад живет в фантазиях, где всё можно распланировать заранее. На практике — в момент первого форс-мажора вся модель рушится. Команда в панике, сроки сдвигаются, клиент в недоумении. Все делают вид, что «ещё немного, и всё будет». Никто не понимает, что именно сейчас происходит.

Scrum

Скрам признаёт хаос, но уходит в другую крайность: «мы не можем сказать, сколько займет задача, но будем «спринтить». Это ок для стартапов или внутренних команд. Но если у клиента ограниченный бюджет и жёсткие сроки, скрам превращается в лотерею.

FFF

FFF — методология, которая предполагает, что что‑то пойдет не по плану. Но не просто знает — предлагает, что делать, когда это случится. Это честный, прагматичный, и при этом прозрачный способ довести проект до результата.

Почему FFF нравится заказчикам

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

• Получить продукт в срок.
• Не выйти за рамки бюджета.
• И при этом иметь возможность вносить изменения по ходу.

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

Все это звучит разумно и логично и прельщает вот этой самой гибкостью. Когда ты честно показываешь клиенту, как работает эта система — почти все говорят: «Логично. Погнали». 

Но…

Флекс – всегда боль

На этапе продаж FFF воспринимается отлично. Даже на моменте, когда мы четко проговариваем: «Чуваки, все будет круто, но стопроцентно настанет момент, когда мы придем к вам и скажем, что что‑то не влезет, что для вот этой хотелки нужно вырезать что‑то из ранее утвержденной функциональности». Люди понимают, что идея разумная.

И как бы вы классно все на старте ни обговорили, этот самый момент флекса всегда будет камнем преткновения. Когда надо выбирать, от чего отказываемся, всегда появляется элемент стресса.

Тогда и начинается настоящая работа. Сомнения, обиды, микроскандалы. Ключевое тут — доверие. Если заказчик команде не доверяет, любое «пофлексим» он воспримет как «вы мне ничего не сделаете, просто хотите слиться». 

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

Сначала мы просто оформляем рабочий процесс и показываем, как все делается. Это работа на доверие. И только потом, когда оно появится с обеих сторон, — можно начинать говорить про гибкость. О том, как это самое доверие выстраивать с первого касания с заказчиком, мы рассказали в другой статье.

Пример: FF Manager

Один из наших продуктов, где FFF себя отлично показал, — FF Manager. И нет, мы не назвали продукт в честь методологии, в FF Manager FF – это Freedom Football 🙂

Мы запланировали MVP. Среди фич не было драг-н-дропа тренировок в календарь — он казался слишком сложным для первой версии. Зато был, например, годовой календарь для планирования тренировок (в дополнение к недельному и месячному его видам).

Потом: приходит клиент и говорит, что драг-н-дроп нужен позарез. Окей. Сели, подумали. 

Мы могли сказать нет. Но мы работаем по FFF. Поэтому:

1. Мы пересмотрели план.
2. Поняли, что драг-н-дроп не такой сложный, как казался.
3. Выкинули годовой календарь.
4. Сделали нужную фичу.

Всё честно, всё в срок. Бюджет тот же. Просто мы вместе выбрали, что важнее. А годовой календарь, который казался очень важным сначала, в итоге так и остался в бэклоге, как не самая необходимая в реальности фича. 

Было тяжело? Да. Были острые переговоры? Ещё как. Но продукт получился ровно такой, какой был нужен.

Как флексить: 4 рабочих тактики

Когда нужно менять скоп, мы используем несколько подходов. Вот самые частые:

FFF — это зрелость

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

Для заказчика: FFF требует вовлеченности. Это не пассивная история «заплатил и жду». Это история про партнерство и совместные принятия решений.

Для команды: FFF диктует общение без обманов и накруток. Нужно объяснять, доказывать, разбираться и создавать доверие через эту коммуникацию. 

Гибкость в FFF – не способ закрыть дыры в опыте или ответственности. Это способ собраться, когда всё пошло не по плану.

Классическая история. Кажется: два человека — в два раза быстрее сдадим проект, десять человек — в десять раз быстрее. Логично же?

Ну, на самом деле нет. С каждым новым участником команды появляется всё больше точек, где нужно согласовывать решения и синхронизировать изменения. А критические вещи — спроектировать архитектуру, продумать структуру базы, настроить интеграции, согласовать бизнес-логику — всё равно остаются последовательными этапами. Их просто не получится делать одновременно, даже если вы соберёте сотню программистов.

Почему добавление людей только замедляет проект с горящими сроками

В чём корень проблемы? Вот типичная логика: чем больше людей в команде, тем проще распределить между ними задачи. Значит, всё сделается настолько быстрее, насколько больше исполнителей мы привлекли. Так обычно рассуждают те, кто никогда не создавал цифровые продукты своими руками.

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

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

Новичков нужно вводить в курс дела. Опытные разработчики отвлекаются от своих задач, чтобы объяснить новеньким, как всё устроено. Недели три-четыре производительность падает у всех — и у тех, кто объясняет, и у тех, кто разбирается.

Координация съедает время. Появляется больше созвонов, больше проверок кода, больше согласований. Кто‑то ждёт, пока коллега допишет свой кусок. Другой ждёт результатов тестирования. Третий не может двигаться дальше, пока не получит фидбек по своей правке.

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

Ключевые этапы всё равно идут по очереди. Архитектуру нельзя проектировать параллельно — это последовательное принятие решений. Модель данных тоже. Интеграции настраиваются одна за другой. Релизы выходят по очереди. Скорость здесь определяется качеством решений, а не количеством рук.

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

Проджекту и тимлиду становится сложнее выбрать разработчика, на которого назначить задачу. С командой старичков любую задачу можно назначать на любого человека: нужно учитывать только текущую занятость. Если набираем новичков, то становится все сложнее распределять ответственность.

Насколько можно ускорить релиз через найм

Окей, допустим, мы всё равно хотим сделать тот же объём работы быстрее просто за счёт увеличения команды. Можно хотя бы посчитать, на что рассчитывать? Для этого обратимся к закону Амдала. Он показывает теоретический потолок ускорения. Помним: часть работы можно делать параллельно, а часть — только последовательно.

Это идеальные условия, когда нет вообще никаких накладных расходов на синхронизацию. В жизни будет только хуже.

Давайте посчитаем на примере. Допустим, 70% задач можно распараллелить (p = 0,7), и один разработчик делает весь объём работы за 9 месяцев. Мы наняли девятерых, думая, что уложимся в месяц. Что получается:

S(9) = 1 / ((1 - 0,7) + 0,7/9) ≈ 2,65

T(9) ≈ 9 мес / 2,65 ≈ 3,4 мес

То есть даже в идеальном мире, где нет затрат на координацию по Бруксу, мы получим максимум 3,4 месяца. А не один.

Чтобы уложиться в месяц при исходных девяти, нужно ускорение в 9 раз. По формуле 1/((1 - p) + p/9) = 9 получаем, что p должно быть равно 1. То есть нужна стопроцентная параллелизация всех задач. Что в реальности невозможно.

Как реально ускорить разработку: практические шаги вместо увеличения штата

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

Шаг ноль: сначала поймите, что на самом деле тормозит

Львиная доля задержек релизов происходит вообще не из‑за нехватки рук. 

Бывает, в разработку просто нечего отдавать, потому что дизайн и аналитика не поспевают. Или ситуация противоположная: материалов вагон, но они постоянно меняются и дополняются. Это называется feature creep, и добавить людей в такой проект — всё равно что подливать бензин в костёр.

Потратьте несколько часов и проверьте четыре момента:

Первый шаг: используйте готовые решения

Это реально сокращает объём критических последовательных задач и увеличивает долю независимых, которые можно делать параллельно. 

И ещё момент: унифицируйте повторяющиеся вещи в том, что уже написали. Если у вас на сайте три типа контента — не делайте три разных редактора. Сделайте один с настраиваемыми полями или переиспользуйте существующий. Меньше кода — проще жить. Проще тестировать, проще вносить изменения, проще поддерживать.

Второй шаг: зафиксируйте правила игры

Контракты между компонентами системы. Идея простая: сделать обмен данными предсказуемым, даже если в проекте куча неопределённости (а ее всегда куча). Не нужно расписывать всё до мелочей на века вперёд. Зафиксируйте минимально необходимые правила, которые дают команде свободу действий и снимают лишнюю головную боль.

Для каждой точки обмена данными (клиент–сервер, сервис–сервис, ваш бэкенд–внешние системы) проговорите и запишите: кто инициирует запрос, кто отвечает, какие поля туда-сюда передаются. Сразу задокументируйте это и положите туда, где увидят разработка, тестирование и эксплуатация.

Контракты внутри команды. Ещё один способ снизить когнитивную нагрузку — определения готовности задач. Definition of Ready отвечает на вопрос «когда задачу можно брать в работу». Definition of Done — «когда её можно считать законченной и закрыть».

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

Третий шаг: режьте функциональность вертикально

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

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

Если поделить весь продукт на такие срезы, вы сможете гибко управлять объёмом работ в каждом из них. Время поджимает? Другая фича стала важнее? Не проблема — режем скоуп конкретного среза, не трогая остальное. Подробнее о том, как это делать, мы писали в статье про FFF.

Читайте также:

FFF: методология, которая принимает реальность и помогает делать цифровой продукт

Анастасия Мартынова, Редактор

Как превратить кучу фич в срезы? Возьмите большой блок («оплата», «личный кабинет» или «каталог») и разверните его на 3-5 минимальных путей пользователя. Вот пример с оплатой:

• первый срез — «оплата картой без сохранения и без промокодов» (самое базовое)
• второй — «оплата с промокодом»
• третий — «оплата с сохранением карты для будущих покупок»
• четвёртый — «оплата подарочным сертификатом»

Каждый срез содержит ровно столько UI, логики и интеграций, сколько нужно, чтобы пройти путь от начала до конца.

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

Четвёртый шаг: уберите избыточную координацию

Об этом все говорят, но многие понимают буквально: «удалить встречи из календаря». Но прям так не надо.

Да, стоит сократить регулярные созвоны до разумного минимума. Но параллельно нужно перевести договорённости в письменные каналы. Чтобы это работало, организуйте единую понятную структуру: тема, решение, ссылка на конкретный артефакт. Так вам не придётся записывать встречи и потом рыться в расшифровках — все решения уже зафиксированы в одном месте.

Если на проекте делаете код-ревью — оптимизируйте этот процесс. Сделайте его максимально предсказуемым: чёткий чек-лист критериев, понятные SLA по времени проверки, короткие очереди.

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

Когда расширение команды реально имеет смысл

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

Вот простой тест: можете ли вы прямо сейчас выдать новому человеку план работы на две недели вперёд без оговорок типа «зависит от того, что сделают другие»? Если да — отлично, тогда расширение команды действительно ускорит работу, а не создаст новые проблемы. Давайте подробнее.

Эффективный онбординг разработчиков: опоры и предсказуемая первая неделя

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

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

• вёрстка на готовой дизайн-системе
• перенос контента по шаблону
• написание автотестов по уже описанным сценариям
• небольшие сервисы на одном и том же каркасе

На входе в каждую такую зону у нового человека должны быть четыре опоры:

1. Ссылка на действующий контракт или спецификацию
2. Примеры данных для работы
3. Инструкция для запуска окружения
4. Понятные критерии того, что считается готовым результатом

Человек должен сразу видеть, как работать и что значит «выполнено».

Сделайте онбординг коротким и предсказуемым. Подготовка проекта к адаптации новых людей и удобный developer experience должны быть в приоритете.

В идеале у каждого разработчика в голове должна сложиться такая картина:

• Я понимаю архитектуру приложения и принципы написания кода — они нормально описаны
• Я знаю, как проверить и задеплоить свои изменения без ошибок, есть тестовые данные и готовые тесты
• Я понимаю функциональность продукта и то, над чем буду работать, вся информация в одном понятном месте
• Проверка кода максимально автоматизирована — линтеры, кодстайл, SAST, AI-помощники уже настроены

Установите ограничители. Чётко разделите, какие решения новый участник принимает сам, какие согласует с ответственным за архитектуру, а какие вообще трогать нельзя.

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

Дальше масштабируйтесь осторожно

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

• релизы стали чаще
• среднее время код-ревью сократилось
• задачи закрываются без дополнительных встреч и согласований

Помните о качестве, а не только о количестве. На практике замена нескольких мидлов и джунов на пару сильных сеньоров на критических участках даёт кратный эффект. 

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

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

Как распознать «решателя»? Смотрите на конкретные маркеры в работе и на собеседовании:

• Человек быстро формулирует план из нескольких шагов, даже если данных неполные
• Уточняет границы задачи и сам предлагает, что можно отложить, чтобы не тормозить релиз
• Фиксирует договорённости (не надеется на память)
• Не боится принимать обратимые решения и вовремя эскалирует необратимые
• Держит прозрачность в коммуникации, коллеги всегда знают, на каком он этапе

Измеряйте результат

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

Для долгосрочных усилений обычно смотрят на:

• Throughput — поток выпускаемых задач
• Lead time — время от начала работы над изменением до его выкатки
• Частоту релизов — как часто выходят версии
• Качество — количество и критичность багов в продакшене

Если все показатели улучшаются вместе — расширение работает. Если два из них стоят на месте или ухудшаются — откатитесь назад: стабилизируйте правила, упростите сценарии, доработайте окружение. И только потом снова пробуйте масштабировать.

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

Тогда каждый новый специалист действительно приблизит релиз, а не добавит ещё одну причину для задержки.

Это будни проекта, где вы — проджект-менеджер из агентства — управляете гибридной командой, которую отчасти не выбирали. Тут треть – ваши люди, еще треть – штатные сотрудники клиента и еще – дизайнеры из другого агентства. А вы посередине. Вы не нанимали этих людей. Не можете их уволить. Но отвечаете за результат.

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

Что такое гибридная команда и почему это не просто аутсорс разработка

Говоря о заказной разработке, обычно представляют простую схему: есть заказчик с идеей и деньгами, есть агентство с готовой командой. Агентство приходит целиком — со своим проджектом, разработчиками, тестировщиками, дизайнерами. Все процессы внутри этой команды, все люди друг друга знают, сработались на предыдущих проектах.

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

И вот вы должны всем этим управлять.

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

Включайте здоровое недоверие с первого дня

Есть хорошая новость: в IT-нише роли более-менее стандартизированы. Когда вы приходите на проект как проджект, вам не нужно объяснять разработчикам и тестировщикам, кто вы и почему они должны отвечать на ваши вопросы. Есть команда, есть PM — вот структура, с которой все знакомы. Примерно того же мы привыкли ожидать и в контексте остальных участников команды. 

Но есть нюанс.

Когда в команде появляются люди со стороны клиента или еще одного агентства, возникает странный эффект. Ты воспринимаешь этих людей ровно так, как их презентовал заказчик. Если сказали «это наш тимлид» — значит, он опытный и компетентный. Если «это звездный бэкендер» — значит, профессионал

Почему непросто с этим работать:

• Страх перед сторонним ресурсом: возникает ложное ощущение, что раз человека нанял клиент (который сам по себе IT-директор), значит, он точно эксперт и трогать его нельзя. Нет установки проверить человека, потому что он от клиента. Кажется, что сомневаться в его навыках — ставить под вопрос выбор самого заказчика.
• Иллюзия иерархии: штатные сотрудники заказчика часто считают, что их статус «инвестора» дает им право на автономные решения, даже если они идут вразрез с общим процессом.
• Скрытое управление: у людей из сторонних агентств есть свои руководители и свои KPI, которых вам не видно, но которые влияют на их работу.

Не у всех есть привычка сразу включать критическое мышление. А вдруг вы усомнитесь в людях, а окажется, что это вы чего‑то не понимаете? Да и к тому же все эти проверки будут занимать время, а мы тут в огне, вообще-то!

Вот как было. Клиент дал тимлида фронтенда, которого сам нанял под проект. И все ожидали от него тимлидского перформанса: он ревьюит код, помогает планировать, берет сложные задачи. Прошло время. Оказалось, что у него грубые ошибки в архитектуре. Он не знает, как работать с компонентами. Системно работать не умеет, с коммуникацией тоже было туго: суть «лида» никак в нем не раскрывалась. По факту — джуниор-плюс, максимум. Но это мы только спустя три месяца узнали.

Как мягкость может стоить полугода разработки

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

И сначала все вроде было окей, работали потихонечку. Но потом начались странности. Он не отвечал в чатах, игнорировал тикеты в Jira, не реагировал на дедлайны. На созвонах появлялся с одним вопросом: «Есть ко мне вопросы? Озвучьте, пожалуйста. Если нет — я отключаюсь». Единственный человек, с которым он нормально общался — аналитик. Она работала над его функцией, писала документацию по его коду, и он ей доверился. Через нее приходилось ставить задачи и узнавать статус. Так получалось работать какое‑то время – не хотелось сразу рубить с плеча.

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

Но давайте теперь про то, как это выглядело в моменте. Вот вы РМ, вам дали человека и сказали: «Через три месяца должен быть сервис. Вот тебе он — разбирайся». Вы в ответе за его онбординг, скорость работы. Изначально казалось, что он надолго. Что его нужно спокойно вкатить в команду, сделать «нашим человеком», водить на планирования и ретроспективы. Про нюансы его коммуникации известно не было, и никто не знал, что человека стоит сразу за горло схватить, чтобы он понял, что на проекте действительно нужно работать. 

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

Как предлагать помощь в найме и почему это ваша страховка

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

Почему так происходит? У клиента может не быть компетенций в найме именно для вашего проекта. Или компетенции есть, но их недостаточно, чтобы понять, насколько конкретный человек подходит под текущие задачи, команду и контекст.

Решение простое: предлагать помощь в найме.

Не заходите с ноги и фразы «мы знаем лучше». Нужно вкладывать смысл «давайте вместе». Если клиент планирует нанимать фронтендера — пусть ваш тимлид фронта посидит на собеседовании как фасилитатор. Нанимает бэкендера — подключите своего архитектора или сильного бэка. Пару часов их времени — это не космические деньги, но это резко снижает риск получить неадекватного сотрудника.

Иногда клиент откажет. Иногда у него позиция «я сам решууу». Ок. Но предлагать все равно нужно. Зафиксировать, что вы готовы помочь, объяснить риски на примерах.

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

Нестандартные решения и дизайнер в роли владельца продукта

Можно пойти глубже – искать внутренние ресурсы там, где их никто не ожидал увидеть. Особенно, когда ситуация на рынке не самая понятная. 

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

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

Почему внутренний ресурс сработал лучше классического найма:

• Не нужно было притираться к контексту.  Леша уже понимал продукт «от и до», знал бизнес-логику и то, как всё устроено внутри, пока человек со стороны тратил бы месяцы на адаптацию.
• Практическая польза победила пробелы в теории. Леша мог не знать всех академических терминов, но он понимал, как продукт должен зарабатывать и как, например, руками поправить макеты для достижения цели.
• Заказчик понимал, о ком идет речь. Удалось оторваться от привычки искать «человека-методичку» и довериться тому, кто уже показал себя в деле. Всем как‑то сразу стало ясно, что это эффективное решение.

Почему команда из агентства работает не так как штат клиента

Вот что становится заметно через несколько месяцев работы: люди из вашего агентства и люди из штата клиента работают по-разному. И нет, это не заход к тому, что одни профессиональнее других. Просто у всех разная мотивация и разные привычки.

У нас был инцидент с тестировщиками со стороны клиента, они постоянно жаловались, что задачи приходят, а они не знают, как тестировать. Не готовились заранее, не разбирались в контексте — просто ждали, пока задача упадет к ним в работу, а потом начинали выяснять, что с ней делать. Окей, с этим тоже можно работать. Мы выстроили отдельный процесс: погружение тестировщиков в контекст задачи еще до ее готовности. Чтобы к моменту, когда нужно тестировать, все уже понимали, что проверять и зачем. Это предупредительная работа — разруливать проблемы до того, как они превратятся в конфликт.

У штатных сотрудников заказчика может быть по-другому. Это их постоянное место работы. Проект для них — очередной рабочий фокус, которых может быть множество. Мотивация другая: сделать свою часть, не ввязываться ни во что, не брать на себя лишнее. Не хочется обобщать, но так реально часто происходит.

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

Почему неумение хватать людей за горло на самом деле спасает проекты

Логичный возникает вопрос: как поженить друг с другом людей в этой всей неразберихе, где у всех своя мотивация (у кого‑то вовсе отсутствующая) и свои методы общения? 

Можно пойти по пути жесткости, как та самая Галина Ивановна, которая стучала указкой по доске, пока вы учились в 4«Б». По ее заветам вы начнете рыться в каждом конфликте, выяснять, кто виноват, раздавать предупреждения, требовать дисциплины. Звучит для кого‑то может и правильно, но чаще всего это способ угробить сначала команду, а потом и проект. Потому что если вы начнете биться за правду в каждой ситуации, у вас не останется времени вести разработку. А люди, которых вы пытаетесь утихомирить и дисциплинировать через жесткость, просто закроются. Или начнут саботировать. Или уйдут, и клиент найдет им замену, которая может оказаться еще хуже.

Другой подход — поиск альтернативных путей. Игнорировать чьи‑то выкрутасы, если результат есть. Искать посредников и компромиссы для тех, с кем по классическому пути не построить связь.

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

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

Короче, тут можно до бесконечности эти примеры приводить. Главное – усвоить, что тут гибкость всякого рода работать будет явно лучше, чем попытки всех построить.

PM — это коммуникатор, которому отчаянно нужны «свои»

Если проект – это лоскутное одеяло специалистов с разным бэкграундом, проджект – это нить, которая удерживает кусочки вместе через постоянный мониторинг: списаться утром, уточнить прогресс днем, вовремя заметить, что кто‑то выпал из контекста. Такое превентивное управление конфликтами и притирка людей друг к другу часто остаются за кадром официальных отчетов, но именно они позволяют фичам запускаться.

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

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

Что делать, если вы PM в гибридной команде

Давайте зафиксируем, Работа в гибридной среде — это всегда игра с высокой степенью неопределенности. Никогда не знаешь, где бабахнет. Чтобы во всем этом выжить и принести пользу, стоит придерживаться нескольких принципов, выведенных «кровью» и сорванными сроками.

• Откажитесь от веры в «дано». Не воспринимайте компетенции людей со стороны как аксиому; проверяйте их в деле с первой недели, чтобы не обнаружить джуниора на позиции лида спустя три месяца.
• Транслируйте мягкую силу. В коллективе, где смешаны штатные сотрудники заказчика и несколько агентств, жесткое давление приведет лишь к саботажу. Становитесь медиатором, который объединяет интересы и сглаживает углы.
• Выходите за рамки таблиц и отчетов. В гибридном проекте PM — это прежде всего коммуникатор. Ваша работа — это ежедневный ручной мониторинг настроений, планов и реального прогресса каждого участника.
• Влияйте на найм. Если вы видите, что клиент раз за разом ошибается в людях, предлагайте помощь в фасилитации интервью или ищите ресурсы внутри. Так вы не посягательствуете на власть, а защищаете проект от потери времени.
• Берегите свой внутренний круг. Найдите команду, с которой можно быть собой и обсуждать стратегические моменты вашей совместной работы, чтобы всем было хорошо. Это единственный способ сохранить адекватность, когда в основном на проекте приходится постоянно держать лицо.

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

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

Дано

У нас есть два героя: разработчики Тоня и Мартин. Оба талантливые, оба знают, как устроены фреймворки, как работает PostgreSQL и даже разбираются в таких нюансах, как вариации консистенции данных по ACID. Но их подходы к задачам кардинально различаются.

Тоня: продуктовый разработчик. Будет нашим эталоном. 

Мартин: классный технарь. 

I суперспособность: понимание продукта

Задача: сделать выгрузку отчетов данных в Excel. 

Что делает Мартин

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

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

Как действует Тоня

Она спрашивает: «Для чего нужен этот отчёт? Как его используют?». Оказывается, это бухгалтеры хотят видеть цифры и сверять их с 1С. Тоня добавляет формулы и базовое форматирование: итоговые суммы выделяются, данные фильтруются по датам, рассчитывается стоимость единицы товара. Итог: отчёт становится понятным и удобным, а бухгалтеры экономят время.

Форматирование – минимальное. Настроить выгрузку на это форматирование – прописать пару строчек. Зато как круто на выходе.

Как Мартину стать как Тоня

Тоня, прежде чем приступить к задаче, сформировала User Story.

Это фиксация требований, при которой мы не просто берем задачу в работу как есть, а добавляем ей дополнительного смысла. Здесь самое сложное ответить на вопрос «Зачем?». Важно не путать пользу с возможностью и не получать утверждение вида «Хочу загружать пользователей, чтобы пользователи загружались». Нужно копать до конечной потребности пользователей. 

А еще неплохо участвовать в прояснении требований к продукту. Да, звучит странно. У нас ведь есть продакт/аналитик/дизайнер для этого. Однако на деле реальное устройство продукта могут знать только разработчики. Ценность этого знания высока на начальном этапе работы над функцией: разработчик может подсказать неочевидные связи, более простое техническое решение, чтобы не тратить много времени всей команды.

Полезные практики + что почитать

• Соберите полезную документацию по проекту. Чтобы онбордить новичков в команду, нужна медленно устаревающая информация, например:
  • общий бизнес-контекст продукта: как он зарабатывает или экономит нам деньги, как он встраивается в контекст компании;
  • портреты пользователей: кто пользуется продуктом, какую боль этих людей решает продукт;
  • ключевые сценарии использования: тут пригодятся user story mapping или customer journey map — оба формата довольно наглядные и могут дополнять друг друга.
• Если вы сами разработчик, который только пришел в команду — не бросайтесь сразу пилить таски. Изучите документацию, пользователей и реализованную функциональность.
• Поймите ключевые метрики продукта: бизнес оценивает результаты деятельности по определенным показателям, и стоит узнать у продакта, какие они сейчас, и чего нужно добиться. Если есть возможность – покопайтесь в дашбордах, где их отслеживают.
• Jobs to be done — альтернативный, немного более глубокий подход для понимания ценности продукта, вместо более простого user story. В нем мы представляем, что пользователи, как бы «нанимают» ваш продукт на определенную «работу». Для старта лучше всего почитать гайд у Ивана Замесина
• Догфудинг – самостоятельно пользоваться разрабатываемым продуктом, если это возможно. Легко это делать, если ты пишешь интернет-банк, в который тебе приходит зарплата, сложнее – если систему управления электростанцией. Но стоит пробовать проходить отдельные сценарии, как реальный пользователь (не с тестовыми данными). Например, если заполнить десяток-другой заявок на обслуживание нашей электростанции, часто можно обнаружить пару хороших мест для улучшений в процессе. 

• Алан Купер, «Психбольница в руках пациентов» — довольно старая, но актуальная книга об интерфейсах цифровых продуктов. С момента выхода книги многое в мире стало лучше, но мы все еще сталкиваемся с ужасно неудобными интерфейсами. Книга научит базовым принципам, по которым программы должны общаться с людьми, чтобы вы смогли выявлять и предлагать хорошие решения.

II суперспособность: коммуникация с не-технарями

Кросскомандное взаимодействие – одна из составляющих процесса создания цифровых продуктов. Часто разработчикам приходится общаться не только между собой, но и с другими членами команды, которые не так подкованы технически и могут просто не понимать «программистский» язык. И эта коммуникация может быть очень разной. 

Как общается Мартин

Возникает потребность что‑то изменить или добавить в функциональности. Мартин на такой запрос отвечает: «А может вы там как-нибудь без меня разберетесь?». Когда становится понятно, что не разберутся, Мартин просит скинуть ТЗ и обещает глянуть его, как освободится время. Спустя пару часов получаем от Мартина письмо примерно следующего содержания:

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

Как общается Тоня

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

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

Как Мартину стать как Тоня

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

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

Полезные практики + что почитать

• Книга «Пиши, сокращай» Максима Ильяхова — вроде про написание текстов, но на самом деле про то, как выделить и донести пользу в частном случае в виде текста. Вставляет на место мозг, измученный канцеляризмом и школьными уроками русского.
• Участвовать в клиентских демо, когда разработчики сами демонстрируют реализованную функциональность из первых рук. Демо – не только для того, чтобы отчитаться о сделанном, но и чтобы команда лучше узнала бизнес, получила прямую обратную связь и возможность ее обсудить. Так дальнейшее создание продукта будет проще. Бонус для руководителей: разработчики автоматом становятся ответственнее.
• Проводить 1-2-1 с не-технарями (продактами, сейлзами, дизайнерами, саппортами): если вы пришли в проект, который создает небольшая команда, полезно поближе познакомиться с другими коллегами. Так можно узнать об их собственных взглядах на пользователей, их потребности, и продукт. Особенно это полезно это в отсутствие хорошей документации. 
• Собственно работать в паре с теми же не-технарями. Может быть полезно, например, сделать набросок интерфейса вместе дизайнером, поработать над проектированием какого‑то бизнес процесса вместе с аналитиком или планом выпуска фич с продактом. Совет довольно очевидный, но регулярно сталкиваюсь с командами, в которых принят многоступенчатый подход, где все работают отдельно и потом передают какие‑то артефакты в следующий этап на ревью. А потом через боль все переделывают. 
• Участвовать в Customer development интервью. Обычно их проводят продакт-менеджеры, и, если они делают это регулярно в вашей команде, вы можете присоединиться в качестве слушателя или ассистента и вести заметки.
• Полевое исследование или Гэмба 現場  — это когда мы идем на место, где пользователи работают с продуктом, и наблюдаем за ними, общаемся. Иногда «увидеть своими глазами» и пара часов такого времяпровождения дают больше, чем чтение кучи документов. Например, вот история, как Александр Поломодов, техдир Т-Банка, ходил на гембу и развозил карты клиентам. 
• Если участие пользователей в демо и полевые исследования вам недоступны, можно проводить отдельные встречи для сбора фидбека с небольшой группой пользователей (возможно, это ваши самые лояльные клиенты или бета-тестеры), где продакты могут обсудить проблемы, а разработчики – послушать и лучше понять их.
• Еще вариант – поработать на саппорте. Например, в продуктовой команде Basecamp разработчики регулярно дежурят на саппорте. Аналог: почитать отзывы о продукте.

III суперспособность: проактивность

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

Как проактивность проявляет Мартин

Мартин видит бардак в коде и буквально кричит о необходимости рефакторинга. С точки зрения руководителя рефакторинг – это, конечно, круто, но денег не принесет.

Мартин, разумеется, молодец, потому что думает о развитии продукта. Это с одной стороны. С другой – он предлагает продолжительную и часто непредсказуемую задачу как‑то внедрить в существующий план проекта, но не учитывает контекст: сроки, приоритеты, продуктовую стратегию.

Как проактивность проявляет Тоня

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

Как Мартину стать как Тоня

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

Нужно уметь оценить, что действительно полезно предложить в текущих условиях. Сделать это можно только при понимании приоритетов и того, как должен работать продукт.  

Полезные практики + что почитать

• База проактивности: Увидел – записал. Фиксируйте все идеи, проблемы, предложения и наблюдения, которые могут сделать продукт лучше, но не являются срочными. Это могут быть как технические улучшения (рефакторинг, оптимизация производительности), так и продуктовые (улучшение UX, добавление новых функций). Можно будет вернуться к ним позже, когда появится подходящее время или ресурсы. Главное — вести такой список системно, например, в виде отдельной доски в таск-трекере, и периодически его просматривать и переоценивать.
• Ретроспективы – регулярное обсуждение с командой, что получилось хорошо, что пошло не так и какие улучшения можно внести в следующий спринт. Вовлекает разработчиков в рефлексию и проактивную позицию, они участвуют и вносят предложения. Главное тут — выбрать какие‑то отдельные предложения, взять в работу и не забыть реализовать. 
• Прокачивать насмотренность: мы все время пользуемся кучей цифровых продуктов, иногда они нравятся нам, иногда приносят боль – полезно отмечать такие моменты. Например, в папочке со скриншотами интересных находок. В них стоит задавать себе вопрос «Почему так сделано, а не иначе?», «Что конкретно не так?» и «Как можно было сделать лучше?» или наоборот «За счет чего так удобно?». Дополнительно, как хобби, можно устанавливать и тестить разные продукты. 
• Если лень собирать примеры самому, можно подписаться на канал Ильи Бирмана, где он регулярно постит примеры такого и делает разборы интерфейсов своих студентов 

IV суперспособность: планирование непонятных задач

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

Как действует Мартин

Мартин человек ответственный и понимает, что просто так накидать оценки не получится – нужна детализация. Поэтому требует подробное ТЗ. И такой подход на самом деле может работать.

Однако порой слишком глубокое погружение в детали может убить продукт еще на старте. Вот ТЗ прописали, Мартин на него посмотрел и говорит: «Разработка займет три года». С Мартином спорить сложно, но вот вопрос – кому этот продукт вообще будет нужен через три года? И точно ли будет?

Читайте также:

Почему продуктовое проектиро­вание лучше формального ТЗ 

Вениамин Мустафин, Директор по развитию бизнеса

Как действует Тоня

У Тони другая установка. Она знает, что в целом в продукте работает правило, при котором 20% усилий дают 80% результата. Она думает итерациями и понимает, что нужно выделить первую версию для самой большой группы пользователей. А дальше двигаться в сторону расширения сервиса, параллельно собирая обратную связь с пользователей.

Как Мартину стать как Тоня

Продуктовый подход здесь состоит в том, что неопределенные задачи нужно прототипировать. Например, вместо того чтобы заранее говорить «сложнааа, поэтому делать будем 300 лет», можно посоветоваться со смежной командой, чтобы получить взгляд со стороны. Это позволит разбить задачу на этапы и примерить временные и технические затраты.

Еще важно, что продуктовые компромиссы обычно лучше технических.

• Технические компромиссы – это, например, наделать костылей (пусть и работающих), готовясь морально к тому, что в будущем придется разбирать гигантский техдолг.
• Продуктовый компромисс – это когда, например, у нас есть в плане система оплаты через крипту, но мы понимаем, что реально пользоваться ею будут полтора землекопа. Поэтому просто не делаем эту функциональность. Отпадает сразу ряд задач и проблем.

Полезные практики 

• Делать быстрые черновые прототипы —  накидывать интерфейс в Figma или набросать неработающих компонентов в React/Vue, не стремясь к идеалу. Нет времени на такое? Нарисовать карандашом на бумаге или в Paint. Сложный интерфейс с кучей данных и графиками? Можно набросать в Гугл Таблицах. И так далее. Главное — показать идею и обсудить её с командой.  
• Показывать демо незавершенных решений. Не каждую фичу можно сделать в спринт, но часто важно получать фидбек и по ходу разработки: на реальных данных могут обнаружиться необычные кейсы, которые лучше скорректировать до релиза.
• Spike: это короткая исследовательская задача. Её цель — выяснить, насколько реалистично выполнить сложную часть проекта. Вместо гадания и споров команда получает конкретный ответ: стоит ли браться за задачу сейчас или отложить. Обязательное условие — чётко ограниченное время на исследование.
  Пример: Мы разрабатываем онлайн магазин, нужно добавить Apple Pay. Разработчик берёт spike на день, пробует SDK и делает прототип. Выясняется: работает только в мобильном Safari, нужен отдельный эндпойнт на бекенде.
• Метод прогрессивного JPEG – cначала делаем костяк решения: от начала до конца, без стремления к идеалу. Главное — дойти до рабочей версии как можно быстрее. Потом улучшаем и допиливаем. Такой подход экономит ресурсы, ускоряет проверку гипотез и быстрее приносит пользу пользователю.
  Пример: Вместо полной реализации покупки в онлайн магазине команда запускает базовую версию: товар → корзина → оплата → спасибо. Пользователи уже могут заказывать, бизнес — зарабатывать. Остальные детали (разные варианты оплаты, доставки, промоакции, связь c CRM и т.д.) добавляют позже, шаг за шагом.

V суперспособность: ответственность за  результат

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

Что есть результат для  Мартина

Мартин долго трудился над  бэкендом системы. Делал-делал и  выдает: «Бэк готов!». Все  протестировано, тесты зелененькие, все  работает – красотища. И  да, к  качеству реализации вопросов нет, но  «Бэк готов!» – это  все-таки не  совсем цельный результат. Это  скорее шаг  к  нему, пусть и  довольно существенный. 

Что есть результат для  Тони

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

Для Тони «готово» — это  когда:

• фича интегрирована в  продукт,
• проверена в  связке с  другими модулями,
• доступна пользователям,
• получена обратная связь.

Полезные практики + что  почитать

• Явно описывать Definition of  Done. Перед началом работы договориться, что  значит «готово»: фича протестирована, задеплоена, проверена в  проде, заанонсирована. Это  формирует привычку доводить до  результата, а  не  останавливаться на  этапе «код написал».
• Введение новой роли — Feature lead. Это временная роль. Как тимлид, только для одной фичи. Один разработчик берёт ответственность за выпуск всей фичи: от уточнения требований и синхронизации с командой до выката и получения обратной связи. Такая роль помогает тренировать навык видеть продукт целиком и доводить дело до конца.
• Применять подход You build it, you  run  it. Команда, которая разрабатывает фичу, отвечает и  за  её  поддержку после релиза. Это значит: следить за  логами, быстро реагировать на  баги и  инциденты, участвовать в  улучшении стабильности. Такой подход усиливает чувство ответственности: ты  не  просто «сдал фичу», ты  за  неё  в  ответе и  после продакшена. Со  временем это  меняет мышление — разработчик начинает проектировать так, чтобы проще было сопровождать и  отлаживать. 
• Тестировать самому.  Есть продуктовые команды, которые работают без  выделенных QA-специалистов. Например, Intercom, Basecamp, GitHub. Разработчики сами обеспечивают качество через автоматизацию, статанализ кода, мониторинг, CI/CD и  код-ревью. Даже если у  вас  есть QA, не  стоит уповать только на  них  – полезно провести тестирование новых фич: своих или  чужих.

Темная сторона

Погоди, не многовато ли? И с бизнесом пообщайся, и фичу сделай, и сам протестируй, и баги поймай, и метрики проверь, и пользователям покажи. И всё это — на фоне дедлайнов, сложного продукта и часто небольшой команды. Можно я просто буду код писать, а вы ТЗ мне дадите?

Отвечаю: можно.

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

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

Подведем итоги

Задавайте вопрос «Зачем?» 

Вот прямо так: зачем эта задача? Что она решает? Иногда вы можете заметить, что задача вообще не нужна или её можно решить проще. Ну и другие вопросы тоже задавайте, если чувствуете, что они могут углубить ваше понимание. Всегда лучше спросить чем не спросить. 

Разберитесь в продукте.

Вы не сможете задавать правильные вопросы, если не понимаете, как работает продукт. Нужно погружаться: изучать документацию, пробовать использовать продукт, читать отзывы пользователей – иногда в них больше мудрости чем в 20 встречах с продактом. Ну и общайтесь с ребятами из команды, которые работают над разными частями функциональности.

Не ждите указаний сверху, действуйте сами.

Видите, что что‑то можно улучшить? Предлагайте. Нашли баг, который всех раздражает? Почините. Продуктовые разработчики постоянно ищут, что можно сделать лучше. Кажется, что такая фишка в подходе к работе вырабатывается сама, если продукт, который вы разрабатываете, действительно вам нравится. 

Умейте искать компромиссы.

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

Общайтесь с разными сторонами процесса.

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

Но для начала ответим на вопрос — зачем?

Для заказчика, незнакомого с разработкой, может казаться, что глубокое продумывание архитектуры на ранних этапах — это не очень важный шаг. Часто можно услышать стартаперское классическое: «Давайте скорее сделаем что‑то работающее, а потом уже будем рисовать красивые диаграммы».

Но это очень опасный путь. Без сомнения, разработчики могут придумать что‑то и без всех этих «красивых диаграмм и схем». Например, возьмут готовую типовую архитектуру из учебника или ту, с которой у них уже есть опыт работы, а может вообще будут продумывать всё на ходу. И к какому‑то моменту у них даже что‑то «построится». Но, исходя из нашего опыта, выглядеть это будет скорее всего как‑то так: 

Да, у нас есть здание. У него есть стены, окна, двери, балконы и крыша. И в нем даже можно жить. Но сколько это здание простоит? И соответствует ли оно пожеланиям тех, кто будет в нем жить? А что, если из‑за архитектурных неточностей строительство в какой‑то момент остановится — в момент, когда станет понятно, что продолжать опасно или дорого. Придется всё снести и начать заново.

Так же и в разработке: вместо удобного и понятного продукта мы получаем что-то, что начнет тормозить, как только зайдут реальные пользователи. А когда вы захотите внести изменения, на это будут уходить человеко-месяцы разработчиков — ведь разобраться в продукте невозможно! Разработчики уволятся, а новые придут и скажут, что надо все переписать. 

На другой стороне спектра — основательные заказчики и архитекторы, которые перед стартом разработки пишут подробнейшее ТЗ. В нем они предусматривают все возможности, продумывают архитектуру вплоть до классов и UML-схем и структур таблицы в БД. Основной риск такого подхода — зависнуть на этапе написания ТЗ и так и не решить бизнес-задачу быстрее конкурентов (вот тут можно почитать, как перестать писать огромные ТЗ и быстрее стартовать разработку). 

Принцип 1: Архитектура подчиняется целям продукта и бизнеса

И никак иначе.

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

Вот вам простой пример. Представьте, что нам нужно сделать обычный блог. А разработчик, увлекшись задачей, начинает внедрять микросервисы, Kafka, Kubernetes и все паттерны, какие может вспомнить, строя мини-космолёт. И вот космолёт есть. Но он никуда не полетит. Потому что нужен был просто блог.

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

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

А как надо?

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

Выстраивается логическая цепочка. Фундамент — это стратегия компании. С оглядкой на нее прорабатывается стратегия продукта. Архитектура будет опираться на стратегию развития продукта. А разработчики, в свою очередь, будут структурировать и писать код, отталкиваясь от архитектуры. 

Поэтому: первым делом перед созданием архитектуры стоит изучить текущую продуктовую стратегию или ее аналог.

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

Я не предлагаю создавать продуктовую стратегию. Обычно, это не задача для архитектора, но стоит изучить, обсудить и зафиксировать ее ключевые моменты с заказчиком. 

Стратегия продукта

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

Цели

Вопросы: Зачем продукт нужен бизнесу? На какие метрики бизнеса он должен повлиять?
Инструменты: Понимание задачи, Карта влияний. 

Экономика

Вопросы: Сколько мы готовы потратить на проект? Каким образом он будет зарабатывать или экономить деньги? Сколько он должен заработать, чтобы быть прибыльным? Когда мы должны получить эту прибыль? Каким образом он может принести убытки?
Инструменты: бюджет проекта, Юнит-экономика, Return of investment

Функциональность продукта

Вопросы: Кто и как им будет пользоваться? Какие сценарии или пользователи наиболее важные (или например, прибыльные)? Какие наиболее частые? Что пользователи могут делать в продукте? В каком порядке мы хотим создавать или запускать продукт?
Инструменты: Customer journey mapping, User story mapping, Roadmap 

Мы в своей работе используем многие из этих инструментов на этапе аналитики проекта. 

Иногда также важно учесть технологическую стратегию компании. В ней обычно можно узнать, какие технологии, платформы, подходы и продукты можно или нужно использовать, а какие нет. А также какие ресурсы запланированы на развитие продукта в будущем.

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

Принцип 2: Архитектура описывает программные системы, их границы и связи

Вроде очевидно, да? Но давайте разберем поглубже.

Для наглядного примера рассмотрим срез растения под микроскопом, который изобилует большими и малыми клетками. 

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

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

Неясные границы системы: заказчик может неявно предполагать, что система будет интегрирована с другими IT-системами компании или включать их. И в один прекрасный день он придет и скажет: «Подождите, у нас эти данные должны быть в CRM обязательно — это же очевидно!». 

Ограничения связей: оказывается, что те возможности связей, которые есть, не позволяют делать то, что нам нужно. Например, нам нужно отдавать и получать данные c CRM в реальном времени, чтобы клиенты могли общаться с менеджерами через чат, а CRM поддерживает только массовый импорт данных, который работает медленно.

Неявные связи: мы меняем что‑то в продукте, и оказывается, что это ломает работу других IT-систем компании.

Вывод: границы и связи, их ограничения – это самое важное.

Чтобы как‑то приземлить этот принцип, мы чаще всего используем вариацию диаграммы системного контекста из так называемой Модели С4 — обычно она понятна абсолютно всем, а не только технарям.

В ней все просто. Для примера, представим, что мы создаем систему «Агрегатор сервисов доставки»:

У нас есть клиенты, которые заказывают доставку, и администраторы, которые следят за качеством работы сервиса. А также другие IT-системы, с которыми сервис должен взаимодействовать. Например, API сторонних сервисов доставки, система бухгалтерского учета и телеграм-бот.

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

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

Принцип 3: Архитектура работает с двумя типами ограничений — железо и люди

Архитектура – это всегда про ограничения. Есть фундаментальные ограничения, которые не позволяют нам взмахнуть волшебной палочкой и мгновенно получить работающий продукт.

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

Ограничение первое: железо 

Очевидный факт — все мы видели приложения, которые неадекватно работают и тормозят даже в простых условиях  — с небольшим количеством данных на достаточно мощных компьютерах и смартфонах (привет, Notion!). 

Чтобы избежать такой истории мы, как архитекторы, должны всегда думать вот о чем:  

1. Рабочая среда:  На каких устройствах и операционных системах будет работать программное обеспечение, каковы их характеристики?
2. Данные: Сколько места потребуется для данных и где эти данные будут храниться?
3. Сети:  По каким сетям будут передаваться данные и каково качество этих сетей?

И, поскольку мы живем в физическом мире, в нем всё рано или поздно что‑то сломается. Поэтому подумаем сразу и об… 

4. Устранении неполадок: как мы будем справляться с поломками? 

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

В таблице ниже представлены примеры фундаментальных ограничений:

Ещё одну полезную статью-выжимку об основных показателях задержки для фронтенд-разработчиков написал CTO американской облачной платформы Vercel Малте Убл — Latency numbers every frontend developer should know. 

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

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

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

Ограничение второе: люди

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

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

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

Архитектура должна работать на тех, кто будет с ней взаимодействовать. Нам важно понять, кто эти люди, что они уже знают и что им еще предстоит изучить. 

Если сейчас этих людей нет, нужно придумать, как они появятся — мы наймем их, привлечем подрядчиков или найдем еще какой‑то способ собрать команду? 

Кто будет работать с архитектурой:

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

Внутренние заказчики и аудиторы. Те люди, которым вы будете сдавать проект. Иногда это CTO, иногда архитектурный комитет, который следит, чтобы архитектура всех продуктов компании следовала общей IT-стратегии.

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

Команда поддержки и развития. Иногда разрабатывает продукт одна команда, а развитием продукта занимается другая.

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

Примеры:

• Мы создаем продукт небольшой командой опытных сеньор-разработчиков, которые проектировали похожие системы. Дальнейшим развитием будут заниматься они же (например, так работает команда разработки Telegram). 

В таком случае можно не описывать глубоко архитектуру на начальном этапе — достаточно дать ключевые данные и каркас архитектуры.

• Мы — госкомпания, и хотим провести тендер на создание продукта, который должен вписаться it-стратегию компании. Разработка займет несколько лет. Задействована большая команда, собранная из разных подрядчиков. 

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

В архитектуре для людей важно описать: 

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

Разделение большой команды разработки на эти области повысит эффективность работы — разработчики не будут наступать друг другу на пятки. Это то, что в domain-driven design называют bounded context.

Общие ключевые архитектурные подходы. Например, это модульный монолит или микросервисы. Если микросервисы, но нужно будет также описать паттерны взаимодействия. 

Ваша задача — собрать те подходы, которые подойдут именно вашей команде и продукту. И описать их команде, конечно же.

Принцип 4: Архитектура нужна для роста и изменения продукта в будущем

Тоже довольно очевидно, да? Если бы нам не надо было менять продукт — про архитектуру мы бы не думали.

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

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

Принцип 5. Архитектура ПО может эволюционировать вместе с продуктом. 

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

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

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

Разработчики продукта постоянно что‑то «садят» — массы кода появляются, начинают разрастаться, где‑то затухают и загнивают. А мы, как садоводы, пытаемся это все организовать в единое целое. 

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

По факту, с такой концепцией получается, что у нас достаточно широкая, в отличии от строительных архитекторов, и более гибкая область действий.

Получается, что ответ на вопрос «Как сделать так, чтобы не переделывать» – никак. И вообще, это неправильный вопрос. Правильный вопрос – «Как сделать так, чтобы не пришлось переделывать в ближайшие N месяцев». 

Есть множество кейсов о том, как компании делали довольно масштабные изменения архитектуры по мере роста: 

• Khan Academy переписали монолит на Python в сервисы на Go без изменения логики

• Instabug перевели интерфейс в фреймворка Angular на Vue

• Uber переехали с PostgreSQL на MySQL

А вот пример из нашей практики: мы проектировали внутреннюю CRM-систему для финансового бизнеса с прицелом на развитие 3-5 лет. Нагрузка на систему на текущий момент была небольшая, но довольно высокой была сложность бизнес-процессов. Запустить первую версию хотели достаточно быстро - за полгода. Мы выбрали архитектуру модульного монолита. А для будущего роста предусмотрели возможность выделить отдельные модули в микросервисы и горизонтально масштабировать — это пригодилось только через пару лет. 

Принцип 6: Самоописываемость кода и архитектуры

Если кратко, иногда проще написать код, чем нарисовать диаграмму.

Диаграммы статичны. Они устаревают, когда код и продукт меняется, и становятся бесполезными, если их не обновлять (о чем обычно забывают), в отличие от других инженерных дисциплин. У нас всегда есть описание того, как на самом деле устроен наш продукт — это его исходный код. 

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

Примеры:

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

Аналогично — использование шаблонов проектов, следующих нужным паттернам (пример микросервисной архитектуры для .NET).

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

Автогенерация документации по коду. Вот несколько примеров: 

• Самый частый пример — документация для API, их запросов, параметров и форматов данных. 

• Для REST API разработчики пишут код бекенда, затем на его основе автоматически генерируется спецификация в формате OpenAPI и документация в виде Swagger UI. Аналогичные инструменты есть для AsyncAPI, gRPC. 

• ER диаграммы по коду БД. Они могут быть довольно наглядными, особенно если сначала таблицы сгруппировать вручную. 

• Документация по модулям на основе кода и комментариев в нем. Примеры: TypeDoc, docfx

• Более редкий пример — генерирование схем архитектуры по коду для инфраструктуры (например, K8S).

Автотесты для архитектуры. Многие языки позволяют написать свои правила, по которым можно проверить код проекта в время сборки на предмет следования нужной архитектуре. Например, что нет лишних зависимостей между слоями. Примеры: ArchUnitNET, ts-arch

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

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

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

Заключение

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

Вы сможете создать архитектуру на том уровне, который будет целесообразен вашему проекту и его текущей фазе (если у вас достаточно времени и навыков, конечно). 

Это непростая задача, но при должном внимании и терпении у вас обязательно все получится! Удачи!

Иллюстрации в статье: MChe Lee и Jan Canty, Сайт «История Москвы»

Команда fuse8

Руководитель проекта
Вениамин Мустафин

Дизайнеры
Алексей Пилишков
Наталья Календарёва

Тимлид
Артём Черненко

Бэкенд-разработчики
Максим Захаров
Илья Стародубов

Фронтенд-разработчики
Екатерина Чекина
Кирилл Зуев

QA-инженер
Алексей Герасимов

«Уралпромбанк»

Директор по развитию
Александр Яхнин

Ведущий маркетолог
Екатерина Арсеньева

Технический директор
Владимир Бучко

Разработчики
Нариман Ибатуллин
Николай Латыш

Начальник отдела
информационной безопасности
Антон Кучерявый

Председатель правления банка
Михаил Парфентьев

Заместитель председателя правления банка
Артём Курзанов

Предыстория

На момент обращения к нам у «Уралпромбанка» уже был свой сайт. Его разработали и запустили еще в 2014 году.

За прошедшие 7 лет сайт сильно разросся, структура размылась, накопилось много неактуальных документов и неработающих ссылок — пользователям стало сложно ориентироваться. Да и дизайн образца 2014 года сегодня смотрелся уже не так свежо. А ещё сайт не был адаптирован под мобильные устройства, хотя 48% пользователей заходили на него именно со смартфонов.

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

Цели и задачи

Итак, первое, что мы сделали — это познакомились с нашим заказчиком.

«Уралпромбанк» — это крупный банк, зарегистрированный в Челябинске в 1994 году. Работает с физическими и юридическими лицами. Основные направления деятельности — обслуживание и кредитование клиентов из Челябинской области, операции на долговом и межбанковском рынках.

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

• создать современный дизайн для нового сайта;
• спроектировать понятную и простую структуру сайта;
• оптимизировать анкеты-заявки на услуги и продукты банка, упростить процесс их заполнения; 
• создать новый каталог, в котором пользователям будет легко ориентироваться;
• проработать раздел «Раскрытие информации», сделать так, чтобы акционеры и регуляторы могли легко и быстро отфильтровать и запросить нужную информацию за разные периоды времени; 
• оптимизировать объём информации в разделах;
• разработать и запустить новый адаптивный сайт.

Аналитика

На этапе аналитики мы погружались в бизнес-процессы клиента, знакомились с его целевой аудиторией и основными конкурентами

Сперва клиент рассказал нам все о своей целевой аудитории: её средний возраст, географические характеристики, какие устройства они используют чаще всего для входа на сайт и какими продуктами и услугами интересуются

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

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

Затем мы погрузились в данные метрик. Это помогло нам еще лучше понять целевую аудиторию, выявить самые популярные разделы сайта и отловить страницы отказов.

В результате мы пришли к пониманию, каким должен быть новый сайт.

Мы изучили брендбук «Уралпромбанка» (на тот момент он состоял только из лого и цветовой палитры) и приступили к формированию общего визуального решения.

Дизайн

Общее визуальное решение (ОВР) — это наш способ достичь взаимопонимания с заказчиком в отношении дизайна сайта. Сперва мы выяснили все предпочтения по стилю и цветовой палитре, а затем подготовили два варианта ОВР для главной страницы сайта.

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

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

Результатом работы на этом этапе стали дизайн-макеты всех страниц нового сайта «Уралпромбанка» и обширная библиотека компонентов. Последняя значительно облегчила работу нашей команде разработки и помогла добиться консистентности дизайна.

Разработка

Новый сайт «Уралпромбанка» разработан на Umbraco. Это бесплатная CMS с удобной административной панелью и большим сообществом поддержки. Она постоянно развивается, в открытом доступе есть огромное количество модулей для оптимизации.

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

Отметим, что изначально у нас был один план разработки, но жизнь внесла свои коррективы. В какой‑то момент половина нашей команды слегла с ковидом (сейчас, к счастью, со всеми всё в порядке). В итоге пришлось экстренно менять планы.

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

Завершили этап разработки традиционно — тестированием, SEO-оптимизацией и запуском нового сайта.

Обучение сотрудников

Старая версия сайта «Уралпромбанка» была на самописной CMS. Поэтому административная панель Umbraco была для сотрудников отдела маркетинга в новинку.

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

Результат

Результатом всех наших работ стал запуск нового адаптивного сайта «Уралпромбанка».

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

Умный калькулятор

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

Конвертер курсов валют

Дополнили блок с курсом валют конвертером: пользователь указывает сумму, которую он хочет купить или продать в валюте, и сразу видит, сколько это будет в рублях.

Анкеты и заявки

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

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

Карта банкоматов

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

Раскрытие информации

Спроектировали удобный раздел с раскрытием информации для акционеров и регуляторов. В нем можно быстро найти нужные документы с помощью фильтров по году и виду раскрываемой информации.

Дизайн-система

В процессе работы над новым сайтом «Уралпромбанка» серьезно изменился брендбук компании. Клиент дал нам полный карт-бланш в этом вопросе, поэтому мы собрали новую дизайн-систему для сайта. В ней мы полностью переработали типографику и палитру — выбрали более светлую цветовую гамму, немного изменили логотип, добавили градиенты и выработали стилистику для оформления всех иллюстраций.

Отзыв клиента

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

О проекте

В течение 2020 года страница за страницей мы обновляли дизайн интернет-магазина. Активное участие в работе над проектом принимали маркетологи FORS. Главной целью было сделать интернет-магазин удобным для розничных и оптовых закупок.

Команда fuse8

Руководитель проекта
Вениамин Мустафин

Дизайнеры
Алексей Пилишков
Валентин Кротов

Команда «47.ru»

Директор по маркетингу
Тимур Кушаков

Разработчик
Артём Ванат

Процесс

Мы начали работу над проектом с изучения целевой аудитории интернет-магазина 47.ru. Это физические лица, юридические лица и специалисты. 

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

Мы также изучили сайты конкурентов FORS и популярные интернет-магазины — «Леруа-Мерлен», «Ситилинк», OZON, DNS, AliExpress и другие. Последние формируют пользовательский опыт — то, как люди привыкли взаимодействовать с коммерческими площадками в сети. Поэтому изучать их интерфейсные решения — всегда хорошая идея.

Собрав этот багаж знаний и идей, мы предложили свое видение дизайна интернет-магазина 47.ru в виде прототипов. Затем обсудили их с заказчиком, внесли коррективы и начали, страница за страницей, создавать дизайн-макеты обновленного сайта 47.ru.

Результат

Главная страница

Самый заметный объект на главной странице — блок с категориями товаров. Он выполняет сразу две задачи:

• привлекает внимание пользователя, дает понять, что продает магазин, и помогает сориентироваться — в какой раздел идти;
• разделяет целевые аудитории: профессиональные монтажники обращаются к разделам «Отопление», «Водоснабжение» и «Канализация», а обычные покупатели, которые делают ремонт в ванной, — к разделу с сантехникой.

Каталог

Сверху страницы есть раскрывающееся навигационное меню с разбивкой на категории товаров.

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

Пользователь может переключаться между двумя видами отображения товаров в каталоге: плиткой или таблицей.

Плитка удобна для сравнения товаров визуально. При наведении на карточку появляется дополнительная информация и кнопка «В корзину».

Таблица удобна для крупных закупок. На странице помещается больше товаров. В правой колонке — кнопка для моментального добавления в корзину.

Страница товара

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

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

Ниже на странице товара — информация о доставке, адресах пунктов самовывоза, и раздел «С этим товаром покупают». Его мы дополнили тэгами, которые помогут покупателю найти сопутствующие товары.

Сравнение товаров

На этой странице покупатели сравнивают несколько товаров по основным характеристикам — цене, наличию, весу, стране-производителю и т.д. Есть возможность показать в таблице только отличающиеся параметры.

Сравнив товары и выбрав из списка подходящую модель, покупатель может сразу добавить её в корзину.

Корзина

Корзина на сайте 47.ru — это инструмент управления заказом. Здесь можно добавить единицу товара, заменить его на аналог, удалить ненужное, поделиться списком с кем‑то еще или распечатать его.

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

Из корзины можно купить товар в один клик. Для этого нужно ввести только номер телефона и электронную почту. Менеджеры 47.ru свяжутся с покупателем, чтобы подтвердить заказ и уточнить способы его получения и оплаты.

Оформление заказа

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

Личный кабинет

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

Дизайн-система

Мы создали для заказчика большую библиотеку компонентов. В ней собраны все визаульные элементы сайта в разных состояниях. Теперь, если заказчику потребуется создать новую страницу на 47.ru, у дизайнера это не займет много времени.

Взыскание долгов: сложности и риски

Задачи продукта

• Создать единое хранилище для всех имеющихся дел
• Реализовать сортировку и быстрый поиск по базе дел с возможностью создания выборки
• Уменьшить количество ручных операций специалистов департамента судебного взыскания и помочь им быстрее ориентироваться в потоке документов
• Автоматизировать переход дел по стадиям
• Автоматизировать отправку отчетов в БКИ
• Автоматизировать отслеживание доставки документов из одной инстанции в другую
• Реализовать генерацию документов: выписок из договоров цессии, заявлений на выдачу судебных постановлений

Объединение экспертизы

Получилась система «Цессионарий», которая автоматизировала работу департамента судебного взыскания МФК «Лайм-Займ». Теперь ручного труда во всем цикле работ от подачи заявления на взыскание до погашения долга всего 10-15%. Система сама генерирует ряд документов и готовит их к отправке в суды. Регулярную отчетность в БКИ «Цессионарий» отправляет автоматически, а продвижение документов по стадиям происходит по нажатию кнопки. Ну и, конечно, никаких монструозных таблиц.

Подготовка и отправка дел в суды

Взаимодействие с судами

Как взыскиваются долги

«Цессионарий»: резюме по функциональности

• Генерирует ряд документов: выписки из договоров цессии, заявления на выдачу судебных постановлений.
• Позволяет вручную прикрепить к делу корреспонденцию: сотрудник подгружает в дело сканы писем и документов, которые есть исключительно на бумаге.
• Позволяет парсить данные из отсканированных документов и заносит их в базу.
• Отслеживает доставку документов по почте в суды и другие инстанции.
• Назначает нового ответственного сотрудника при переходе с этапа на этап.

• Сортирует и ищет дела в общей базе по нескольким параметрам: внутреннему ID, номеру договора, кредитору, статусу иска и другим.
• За раз готовит к печати пакеты документов сразу по нескольким делам.
• Контролирует размеры задолженностей и их погашение, а также переплаты по долгам.
• Уведомляет Бюро кредитных историй о заключении договора цессии, поступлении платежей, полном погашении долга или его списании.

Технологии

Результаты

И еще несколько слов от Екатерины о работе нашей команды: «Хочу отдельно отметить работу команды fuse8 — ребята занимают проактивную позицию в проекте, озвучивают предложения по улучшению работы системы. За прошедшие полгода были выполнены технические задачи, которые позволили обрабатывать больший объем портфеля без снижения скорости работы программного обеспечения»

О проекте

Команда fuse8

Технический директор
Андрей Степанов

Руководитель проекта
Вениамин Мустафин

Бизнес-аналитик
Юрий Торопчин

Команда Emex DWC 

Менеджер продукта
Александр Крашенин

Руководитель проекта
Кузнецов Юрий

Технический директор
Дмитрий Шнипов

Архитектор и разработчик
Евгений Рикунов

Предыстория

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

Что такое Seller Drive

Seller Drive — это внутренняя система Emex DWC для работы с поставщиками. Если кратко, взаимодействие между поставщиками, менеджерами Emex DWC и конечными клиентами, заказывающими запчасти, устроено так:

1. поставщики регистрируются в Seller Drive и загружают туда прайс-листы со своими товарами → 
2. эти товары попадают в каталог интернет-магазина Emex DWC →
3. покупатель выбирает нужный товар по подходящей цене в интернет-магазине и оформляет заказ →
4. этот заказ появляется в системе Seller Drive у поставщика →
5. поставщик обрабатывает заказ и отгружает товар покупателю.

В этой схеме Emex, как посредник/менеджер, помогает состояться сделке между покупателем и поставщиком и, если на каком‑то из этапов что‑то идёт не так, вникает в ситуацию и помогает разрешить проблему.

Что не так с Seller Drive

В 2021 году системе для поставщиков исполнилось 10 лет. И последние 7 из них она никак не менялась и не развивалась. Seller Drive попросту устарела — с точки зрения бизнес-процессов компании, архитектуры и технологий.

Основная проблема Seller Drive — это большие трудозатраты на её использование. Из‑за того, что она не соответствовала бизнес-процессам Emex, многое в ней приходилось делать/решать/исправлять вручную вне системы. Например, если поставщики совершали какую-либо ошибку при загрузке списка товаров, при обработке заказов или работе с претензиями покупателей, справиться самостоятельно с ней они не могли. Приходилось подключаться специалистам со стороны Emex.

Ещё одна проблема, от которой нам предстояло избавиться в ходе проекта — это обилие технологий в портфеле Emex. Часть внутренних сервисов компании был написаны на разных стеках. И потому развивать и поддерживать их было сложно и дорого — приходилось подключать разные команды на разные проекты. Начиная с новой версии Seller Drive компания хотела прийти к унификации всех своих сервисов и продуктов — сделать так, чтобы обслуживать и развивать их могла одна внутренняя команда.

Цели и задачи

Итак, мы должны были спроектировать новую версию Seller Drive — современную, масштабируемую и соответствующую всем ныне существующим бизнес-процессам Emex.

Основные цели на проекте:

1. снизить затраты на пользование системой: фактически, уменьшить количество вмешательств со стороны менеджеров Emex в процесс работы поставщиков с системой;
2. снизить затраты на IT: мы должны были подобрать такие технологический стек и архитектуру, которые позволили бы разработчикам Emex самостоятельно поддерживать и развивать систему, а возможно даже использовать её как основу для разработки аналогичных продуктов.

Еще один важный момент: новая Seller Drive должна будет создаваться на фундаменте уже существующей. Вариант «всё снести и сделать заново» не рассматривался — это было бы дорого, долго и нерационально. Нам предстояло сохранить удачные решения и улучшить их, а также найти всё неудачное/устаревшее и отказаться от этого в новой версии Seller Drive.

Чтобы добиться всего этого, мы должны были:

• собрать максимум информации об уже существующей версии Seller Drive;
• провести анализ и зафиксировать все актуальные бизнес-процессы Emex, затрагивающие систему Seller Drive и работающих с ней людей — поставщиков и менеджеров;
• прояснить и описать сценарии, по которым должна будет работать новая версия Seller Drive; 
• найти в российских системах Emex решения, которые можно переиспользовать в новой Seller Drive;
• провести технический аудит, сформировать архитектуру новой системы и подобрать технологии;
• прояснить, какой у нас в итоге должен получиться MVP новой версии Seller Drive и создать план его разработки.

Процесс

Проектирование новой системы для поставщиков Seller Drive заняло у нас пять недель. И это — с учетом всех встреч с командой заказчика, которая охотно делилась своими знаниями о старой версии Seller Drive и рабочих процессах в компании.

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

1 неделя

Составляем Impact Mapping

Первое, что мы сделали, это уточнили и подтвердили цели проекта и обозначили его границы. В этом нам помог Impact Mapping.

Impact Mapping — это ментальная карта, которая определяет цели проекта и влияния, которые должны помочь достичь этих целей. Подробнее о том, как составить такую карту, читайте в нашей статье «Impact Mapping: как на старте повысить шансы проекта на успех».

Общей целью проекта в Impact Mapping мы обозначили снижение затрат на пользование новой версией системы. Напомним, по требованиям от заказчика она должна стать современной, соответствующей всем действующим бизнес-процессам компании.

Действующими лицами, оказывающими влияние на достижение нашей цели, стали поставщики, которые размещаются в Seller Drive, а также менеджеры бэк-офиса Emex DWC — те самые сотрудники, которые решают все возникающие в Seller Drive проблемы.

Затем мы расписали, как наши действующие лица могут способствовать достижению поставленной нами цели, и что мы можем сделать, чтобы помочь им. Это и помогло нам определить границы проекта.

Обсуждаем бизнес-процессы Seller Drive и Emex

Дальше были созвоны с заказчиком. Представители Emex подробно рассказывали, как устроен их бизнес — на Среднем Востоке и в России. Мы обсуждали, какие рабочие процессы и инструменты у них есть, чего в этих процессах и инструментах не хватает. Задавали много вопросов о том, как работают Seller Drive и аналогичная система для поставщиков на российском рынке.

Изучаем текущую систему Seller Drive и Emex RU

Затем клиент дал нам доступ к действующей системе Seller Drive и познакомил с хранителем знаний о ней — разработчиком и проектировщиком Евгением.

Евгений помог нам досконально изучить Seller Drive — вместе мы буквально разложили систему по кирпичикам-разделам и начали фиксировать проблемы, которые возникали у поставщиков и менеджеров Emex DWC в процессе её использования.

Всё, что нам удалось обнаружить, фиксировали в специальной таблице — у кого возникает проблема, в какой момент, в каком разделе и чем будет ценно устранение этой проблемы:

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

Этот документ стал нашим первым сборником гипотез — что мы можем изменить/добавить/сделать, чтобы новая версия Seller Drive работала лучше.

2-3 неделя

Описываем компоненты новой версии Seller Drive

Это был один из самых интенсивных спринтов проекта, на котором мы методом прогрессивного джипега создавали подробное описание новой версии Seller Drive.

Мы шли от общего к частному и проводили по два созвона в неделю с клиентом. На первый мы приходили с нашим видением определённых модулей новой Seller Drive — верхнеуровневым, без лишней детализации. Затем вместе с клиентом мы обсуждали всё это, проясняли появившиеся вопросы, испытывали заложенные нами сценарии на прочность реальными бизнес-процессами Emex DWC, а после уходили работать дальше.

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

Так постепенно в течение двух недель мы описали, а затем детализировали с учётом фидбека заказчика все модули и компоненты новой версии системы.

Визуализируем интерфейс новой версии Seller Drive

На третьей неделе проекта к нам пришло понимание, что описывать интерфейс исключительно в формате текста, без какой-либо визуализации, очень непросто. Равно, как и презентовать его заказчику. В итоге мы начали создавать первые прототипы Seller Drive. А чтобы не погрузиться в излишнюю детализацию и дизайн, в качестве инструмента выбрали Google-таблицы.

Это оказалось решением на миллион! Табличные прототипы справлялись с поставленной задачей на все 100% — теперь мы не просто представляли интерфейс в голове, а реально видели его своими глазами. И при этом на создание прототипов уходило минимум времени.

Дизайнер, который позже присоединился к проекту, был рад узнать о существовании прототипов. Конечно, это были скорее верхнеуровневые черновики, которые в итоге довольно сильно трансформировались. Но даже в таком виде они принесли ему немало пользы: как минимум, было от чего отталкиваться при оценке проекта.

4 неделя

Финализируем описание новой версии Seller Drive

На четвёртой неделе мы завершили описывать новую версию системы Seller Drive. Мы убедились, что зафиксировали в нём абсолютно все внутренние процессы и закрыли все оставшиеся вопросы.

На этом этапе финальная версия описания Seller Drive включала в себя:

• общее описание системы;
• глоссарий, который помогает ориентироваться в документе и знакомит с внутренней терминологией проекта;
• общие требования к системе;
• подробные описания каждого конкретного процесса внутри Seller Drive (от входа и регистрации до изменения оферты поставщиков и работы с заказами);
• список возможных проблем/сложностей, которые могут возникать у пользователей системы, и сценарии/варианты их решений.

Подбираем технологии, формируем архитектуру

Затем у нас были созвоны с ведущим разработчиком из команды заказчика. Вместе мы обсуждали архитектуру новой версии Seller Drive и формировали стек. Важно было подобрать те решения и технологии, которые совпадали бы с другими продуктами Emex, чтобы после запуска внутренняя команда разработки клиента могла работать с Seller Drive и дальше — поддерживать и развивать систему.

С учётом всех пожеланий наших коллег-разработчиков из Emex, мы сформировали архитектуру новой Seller Drive и подробно прописали стек для бэкенд- и фронтенд-частей проекта. А также зафиксировали, какие библиотеки можно использовать для упрощения разработки фронтенда и предложили конкретное решение по хостингу.

Дополнительно мы просчитали нормы производительности Seller Drive, а именно — показатели нагрузки и количества данных, с которыми новая версия системы должна работать без ухудшения производительности:

5 неделя

Выделяем функциональность для MVP

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

Всё это было сделано ради оптимизации трудозатрат и скорости разработки без потери полезного действия MVP. Проще говоря — помогло нам понять, как за минимальное количество времени сделать и запустить в работу максимально полезную новую версию Seller Drive.

Оцениваем разработку новой версии Seller Drive и определяем метрики успеха

Затем мы оценили, сколько по времени займёт разработка MVP Seller Drive — с учётом наших архитектурных решений, выбранного технологического стека и всей заложенной в MVP функциональности. А также прописали метрики, по которым заказчик мог бы оценить эффективность новой Seller Drive после запуска:

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

Результат

Результатом нашей работы стал чёткий план по разработке новой версии системы для поставщиков Emex DWC — Seller Drive. В него вошли:

Подробное описание всей системы — со сценариями, разделами, процессами и метриками для определения её эффективности.

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

Сформированная архитектура и согласованный технологический стек с учётом всех пожеланий команды разработки заказчика

Оценки на разработку MVP Seller Drive с учётом всего вышеперечисленного.

Что дальше

В мае 2022 года Emex запустили новую версию Seller Drive, созданную по нашим планам и оценкам. Она уже используется поставщиками в странах Среднего Востока. На проекте работали бэкенд-разработчики из Emex и наши ребята-фронтендеры.

В планах — продолжать совершенствовать и улучшать систему Seller Drive, масштабировать её и активно использовать для развития бизнеса Emex.

Работая в команде с fuse8 мы смогли, наконец, понять и зафиксировать, какой должна быть новая Seller Drive, как мы можем её улучшить и сократить при этом затраты на пользование системой и её дальнейшее развитие. А ещё у нас появился конкретный план разработки новой Seller Drive, который мы быстро воплотили в жизнь — система уже работает, мы перевели на неё часть поставщиков. Что касаемо работы с командой fuse8, то и тут опыт мы получили очень позитивный. Все ребята самостоятельные, быстро вникают в процессы, умеют слушать и слышать. Соблюдают наши внутренние требования к работе. Отдельно хочу выделить аналитика проекта Юрия. Он отлично собирал информацию, правильно её интерпретировал и постоянно сверялся с нами — точно ли всё так, как он понял. У нас когда в штат приходит новый сотрудник, ему на знакомство с Seller Drive требуется месяца два. А тут Юрий, как человек со стороны, за 5 недель во всё вник, описал и спроектировал что‑то новое, более совершенное. Единственное, что хотелось бы поменять, это, пожалуй, формат встреч. Иногда казалось, что мы их немного перегрузили — слишком много людей участвовали и озвучивали свои пожелания и требования. Это приводило к тому, что иногда часть информации терялась. Думаю, тут помогла бы более жесткая модерация встреч или их разделение на бизнесовые и технические.

Нам предстояло создать новую версию Seller Drive взамен той, что существовала в компании последние 10 лет и никак не обновлялась 7 из них. Нужно было подстроить Seller Drive под актуальные бизнес-процессы Emex DWC и их технологическую экосистему. 

Разработку Seller Drive мы начали после проектирования системы. Этот этап длился 5 недель и стал основой для следующего за ним этапа разработки, о котором мы рассказываем в этом материале. О том, как проходил процесс проектирования, мы рассказали в отдельном кейсе. 

Новая Seller Drive базировалась на фундаменте уже существующей системы. Мы сохранили удачные решения и улучшили их, а также добавили системе новых возможностей, удалив устаревшую и бесполезную функциональность.

Как устроена работа в системе Seller Drive 

Стартовая страница содержит общую информацию о возможностях системы.  Это единственная индексируемая общедоступная страница Seller Drive – здесь мы настроили SEO-оптимизацию. 

Взаимодействие поставщиков с системой начинается со входа или регистрации. 

После регистрации система предлагает поставщику загрузить прайс-листы с товарами, чтобы начать работу.

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

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

Товары из загруженных в Seller Drive прайс-листов попадают на маркетплейс, где покупатели могут их заказывать. Заказы после оформления отображаются в ЛК поставщика. Там их можно обрабатывать и процессить. Чем быстрее поставщик обрабатывает заказы, тем выше становится его рейтинг, который видят покупатели на маркетплейсе. 

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

Когда товары отгружены, поставка переходит в категорию исполняющихся (pending). Дойдя до склада, она проверяется складскими работниками. Они работают в одной из связанных с Seller Drive систем и отмечают приход товара, а также недочеты, выявленные на стадии приёмки. Например, пришёл товар с неверным номером. 

Как только обнаруживается, что с товаром в поставке что‑то не так, поставщик в своём ЛК узнаёт об этом и может принять меры по устранению неурядицы. 

Немного о процессах

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

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

Первые несколько недель разработки проходили в тесной связке с руководителем фронтенд-направления Emex. Сверяли архитектурные паттерны и закрепляли их. После в созданной архитектуре продолжили автономную разработку, проводя еженедельные демо и сессии планирования. 

Требования мы получали от Emex в Notion, потом переводили их в Azure DevOps, где продолжали работу с ними.

Технологический стек

Стек технологий Seller Drive согласован со стеком российского подразделения Emex, чтобы поддерживать и дорабатывать системы одной командой.

Ещё один важный момент – консистентная дизайн-система Emex. Обновлённый продукт мы подстраивали под заданные визуальные паттерны – опять же, чтобы остаться верными экосистеме, в которой продукт будет существовать. 

Требования к архитектурной структуре Seller Drive также были продиктованы экосистемой программных продуктов Emex. Нужно было, чтобы разработчики из внутренней команды заказчика могли быстро переключаться между ними без долгого онбординга.

• React
• TypeScript
• State management: Redux, Redux Sagas
• Testing: Jest, React Testing Library
• Webpack
• CSS: Styled Components

Результаты

Через 6 месяцев после начала разработки новая версия Seller Drive вошла в эксплуатацию, после чего стала непрерывно совершенствоваться.

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

Что такое Headless CMS?

Headless CMS – это гибкая система управления контентом с удобным интерфейсом редактирования. Headless CMS позволяет отображать контент омниканально через API. Например, на сайте, в мобильном приложении, емейл рассылке и голосовом помощнике.

От стандартных CMS Headless отличается тем, что работает с разными типами фронтендов и любыми типами интерфейсов и устройств. Так получаем единый источник «правды» и не занимаемся переносом контента между разными системами.

В Headless CMS мы создаем только интерфейс для редактирования контента. Система по умолчанию ориентирована на хорошо структурированный контент, поэтому в результате получаем удобные для восприятия форматы на любых типах устройств.

В традиционной CMS мы редактируем контент, который потом отображается только на сайте. Чтобы отобразить его где‑то ещё – например, в мобильном приложении – нужно попросить разработчиков сделать дополнительную автоматическую процедуру экспорта данных или написать дополнительный API. Часто оказывается, что формат, в котором структурированы данные, недоступен для легкого переиспользования. Проще будет написать все заново или перенести руками.

Headless CMS бывают облачные и on premise – те, которые можно поставить на свою инфраструктуру (сервера и БД). Если CMS облачная, получаем масштабируемую систему для редактирования и выдачи контента – не нужно заниматься поддержкой и администрированием ее инфраструктуры. Это очень удобно.

On premise CMS подойдет, если по каким‑то причинам не хочется или нельзя использовать облако — например, из‑за внутренней политики хранения данных в организации. 

Похожие на Headless CMS решения

Первое и наиболее близкое к Headless CMS – генераторы админок для различных языков программирования и платформ разработки. Например, для Python есть Django, а на языке PHP есть Laravel Nova. Они подойдут для случая, когда вы уже разрабатываете приложение на этом языке, и нужно быстро добавить возможность администрирования для отдельных частей. Они не такие удобные для редактора, как Headless CMS. 

Второе – Backend-as-service. Например, Firebase, Supabase ли Amazon Amplify – они обычно используются для мобильной разработки, чтобы не писать отдельно бэкенд, а брать платформу. Они выдают API для типовых операций: сохранение и управление данными пользователей, логина, регистрации и отправки push-уведомлений, но не дают интерфейса для администрирования. 

Backend-as-service подойдет, например, если мы делаем приложение для ведения задач (to‑do лист) и хотим, чтобы пользователи могли регистрироваться и синхронизировать свои задачи на разных девайсах. То есть для сервиса не требуется какой‑то сложный интерфейс администратора, ведь все данные создают сами пользователи.

Третье – это полноценные no-code/low-code платформы для создания приложений. В них можно визуально создавать админки, веб-, и мобильные приложения. Некоторые такие платформы (например, Retool) похожи на Headless CMS тем, что позволяют создать произвольный интерфейс админки и отдавать данные через API для других потребителей. 

Создаем свой сервис: варианты реализации

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

Нам нужно реализовать landing page с основной информацией о нашем сервисе, где будет публиковаться и изменяться контент, помогающий продавать наш продукт. 

Сервис будет работать в виде мобильного приложения на iOS и Android. 

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

Традиционный путь 

Можно создавать сервис с нуля. И тогда мы все пишем сами: нанимаем мобильных разработчиков, бекенд разработчиков для создания платформы, фронтенд разработчиков для создания интерфейса администратора, тестировщиков для проверки всего этого. Но прежде нужно также нанять UX дизайнера, который спроектирует удобный интерфейс для админки, ведь разработчикам иначе будет не очень понятно, как все должно выглядеть и работать. 

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

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

Путь с Headless

Мобильных разработчиков все еще придется нанять, ведь наш основной продукт – приложение. Остальной процесс будет другим: ускоряем time-to-market.

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

Все – API готово – мобильные разработчики могут его использовать, чтобы получать данные уроков и заданий, редакторы-учителя могут эти уроки создавать, переводчики – переводить тексты на другие языки в удобной админке. 

Понадобится нанять дизайнера, чтобы оформить лендинг, и фронтенд разработчика, чтобы он этот лендинг запрограммировал.

Про временные разницы. Собрать структуру контента и админку для такого продукта получается быстро. У меня это заняло это 1.5 часа. 

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

Преимущества Headless CMS

Про ускорение time to market поговорили, теперь – о других преимуществах.

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

Для разработчиков — более чистая архитектура за счет разделения ответственности в частях. Разработчикам удобно отделять  бэкенд (контент)  от фронтенда (того, как контент отображается). Можно сконцентрироваться на своей части и не вникать в другие части продукта.

Для руководителей плюс организационный: нужно меньше людей и нет потребности нанимать ребят-единорогов, которые могут все и сразу. Когда продукту нужно сделать MVP, обычно нанимают суперфуллстека, который разрабатывает все: бекенд, фронтенд, мобилку. Такие ребята есть, но их тяжело найти, и чем больше растет проект, тем тяжелее его поддерживать. А если использовать хэдлесс, всезнающего человека искать не нужно. Чтобы сделать сайт на headless, достаточно компетентного фронтенд разработчика со знанием CSS/JS. 

Headless CMS легко можно интегрировать с другими платформами и пользоваться лучшими из них в своем классе. Например, когда мы разрабатывали ecommerce проект на headless CMS, часть проекта, включающая каталог и продажи использовала Shopify – ведущую ecommerce платформу с удобными интерфейсом. В итоге наш заказчик получил лучший интерфейс для управления контентом и лучший интерфейс для обработки заказов и управления каталогом.

И финальное – удобство редактирования контента. Многие headless CMS (например, Ghost или Kontent.ai) предоставляют крутой UX для скорости и удобства редактирования — хорошо подходит для онлайн-медиа или если вы пишете и публикуете много статей и делаете визуал.

Для чего не подойдет Headless CMS

Во-первых, для реализации сложных бизнес-процессов, воркфлоу и   интерфейса за рамками публикации контента. Headless CMS хорошо реализуют сценарии создания и редактирования контента, его публикации (а еще утверждения и перевода), различные права доступа к разному типу контента. Но они не помогут сделать, например, свою CRM систему заточенную под ваш бизнес. Для такой задачи лучше посмотреть в сторону no-code платформ или пойти по традиционному пути, и сделать большую самописную систему, если пророчите проекту большое развитие.

Headless CMS не подойдут для хранения и управления огромными массивами данных. Например, у нас был проект, где в headless CMS был архив из 600+ тысяч статей — это реально. Но не стоит рассматривать headless CMS, как замену обычной базе данных и пытаться хранить там какие‑то транзакции пользователей или что-то, что очень часто обновляется — например, биржевые котировки. 

Риски Headless CMS

Главный — вы зависите от вендора CMS, и того, как он будет развивать продукт. Это особенно актуально для облачных CMS: могут поменять интерфейс и сделать его перегруженным и неудобным, поменять тарифы, или вообще закрыться.

Как защищаться от этого риска? Поскольку все ваши данные предоставляются через API, вы в любое время можете их выгрузить в структурированном виде и сохранить в надежном месте. Также можно настроить регулярные бекапы данных, если беспокоитесь за сохранность.

Этот же способ помогает ответить на вопрос: «А что, если мне в будущем станет недостаточно возможностей CMS, и я захочу перейти на свою платформу?». Можно разработать свою платформу, перенести структурированные данные из API в нее и даже сохранить структуру API! То есть не придется переделывать приложения, которые использовали контент.

Защитится от изменений в функциональности продукта можно, используя не облачные, а on premise платформы. Однако и тут будут свои минусы — нужно будет самостоятельно поддерживать инфраструктуру для них. Также есть платформы Strapi, Ghost и Umbraco, которые позволяют начать работать на облачной версии, но при желании переехать на open source версию, которую можно будет развернуть на своей инфраструктуре.

Полезные ссылки

Подробнее ознакомиться с изобилием различных CMS поможет этот список. В нем можно настроить фильтрацию по типу CMS и типу ее доступности. Внутри – описание каждой CMS с примерами интерфейсов и оценкой. 

Есть и другой список, но уже с более детальной фильтрацией: по бизнес-сегментам, рейтингу, доступным языкам, ценам и функциям.

Что такое Feature Creep

Feature Creep — это неконтролируемое разрастание функциональности, которое размывает фокус, срывает сроки, раздувает бюджет и превращает продукт в переусложнённую конструкцию, с которой тяжело жить и команде, и пользователям.

Проще говоря, это когда вместо понятного инструмента на выходе получается монстр-франкенштейн: дорогой, громоздкий, украшенный красивым бантиком сбоку и обвешанный фичами, которые никому не нужны. Или вообще тот самый летающий асфальтоукладчик, как в примере от Бюро Горбунова: придумать легко, нарисовать можно, а вот реализовать — ну никак. 

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

Но есть и хорошая новость: при должном внимании и желании Feature Creep можно законтролить. Важно просто хорошо изучить своего врага — где он прячется, какие маски носит, когда атакует и как именно наносит удар.

Где прячется Feature Creep

Есть кратко — везде. Нет ни одного этапа разработки цифрового продукта, где нас бы не подстерегал Feature Creep. Да, неприятно. Но зато теперь мы готовы к этой встрече. Итак, пойдем по-порядку

Мы условно делим проект на пять ключевых этапов: пресейл, аналитика и проектирование, дизайн, разработка, тестирование. И на каждом из них есть своё пространство для зарождения Feature Creep — благодатная почва, в которой он легко прорастает, стоит лишь немного ослабить внимание.

Пресейл

Момент, когда мы только начинаем говорить о будущем продукте: изучаем бизнес клиента, понимаем его цели и предлагаем первые решения. Это этап вдохновения и широких жестов — хочется же заключить договор! 

Именно здесь проще всего наобещать лишнего. Всё кажется выполнимым в любые сроки и при любом бюджете. Но если дело дойдет до проекта, мы…

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

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

Аналитика и проектирование

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

И именно здесь Feature Creep чувствует себя особенно комфортно. По мере того, как мы разбираемся в предметной области, открывается неиссякаемый поток идей:

«Давайте добавим…»

«А я видел у конкурентов прикольное решение… »

«Пользователю точно пригодится…»

Каждая идея сама по себе звучит разумно. И каждая может оказаться первым шагом к Feature Creep. 

Дизайн

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

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

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

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

Разработка

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

И именно в этот момент появляется особый тип Feature Creep — тот, который рождается не из новых идей клиента, а из стремления команды сделать лучше. На практике это может выглядеть так: 

«Раз уж делаем фильтр, давай сразу добавим сортировку, это же почти то же самое».

«Мы сделали простую форму, но с автосохранением будет круче! Давайте добавим!».

«О, а давайте еще анимацию открытия меню сделаем!»

И так далее, и тому подобному. Нет предела совершенству и конца тому, что еще можно добавить/изменить/улучшить. Слышите? Это ваш проект уже начинает трещать по швам… 

Тестирование

Мы уже на финишной прямой: продукт собран, основная логика работает, команда вылавливает и правит баги, проверяет, что всё функционирует так, как должно.

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

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

Всё это выглядит как простая доработка, а не как новая функция. Но осторожно: за одним из этих предложений вполне может скрываться последний удар в спину от Feature Creep.

Три личины Feature Creep

Идея 

Самая обаятельная личина Feature Creep. Это вспышка вдохновения, которая нашептывает: «реализуй меня, и твой продукт взорвет рынок!». Идея обещает рост, усиление конечного результата, победу над конкурентами. И всё это как будто малыми усилиями. 

В какой форме встречается: 

• любые предложения формата «А давайте добавим…», «Было бы круто, если бы…», «У конкурентов есть, и нам нужно» — это идеи. 

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

Улучшение

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

В какой форме встречается:

• предложения «сделать удобнее», «добавить ещё одно состояние», «расширить сценарий», «дополнить маленькую деталь — иначе нелогично».

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

Доработка / устранение ошибки

Если идея — обаятельна, то доработка — очень коварна. Под видом фикса бага в проект попадает кусочек новой логики. Вроде бы поправили одну ошибку, а в бэклоге появилось еще +3 задачи. 

В какой форме встречается:

• устраняли ошибку при загрузке файла, и заодно решили прикрутить ограничение по типу/размеру;
• правили отображение списка и придумали добавить к нему сортировку и группировку;
• нашли дыру в сценарии — не просто закрыли ее, но и значительно расширили сам сценарий, чтобы пользователь точно не запутался. 

На каких этапах появляется: Обычно, в разработке и тестировании, когда найденный баг заставляет увидеть ещё пару недочётов, которые хочется учесть, поправить или вообще переделать.

Чем отразить удар

FFF (Fix Time, Fix Budget, Flex Scope)

База. Правильно выбранная для разработки цифрового продукта методология — это первичный фаервол от Feature Creep.

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

На каких этапах проекта работает: дизайн, разработка и тестирование. 

Карта влияний

Тоже мощное оружие против Feature Creep. Карта влияний на самых ранних этапах проекта помогает нам определить цель будущего продукта и выделить действия и изменения, которые напрямую влияют на достижение этой цели.

И в этом вся суть: карта влияний работает как смысловой фильтр: если идея приближает продукт к цели — мы ищем ей место. Если нет — откладываем или выбрасываем.

На каких этапах проекта работает: на всех, но особенно часто применяется на пресейле, во время аналитики и проектирования.

USM

Инструмент, который помогает удерживать фокус на том, что именно должно попасть в продукт. Когда мы составляем User Story Mapp, мы, по сути, фиксируем набор фич, которые действительно нужны продукту, и сразу расставляем приоритеты. Всё это делается с опорой на реальные потребности пользователей и цели бизнеса.

И в этом сила USM — это практический фильтр от Feature Creep. Если фича не поддерживает конкретное действие пользователя и не имеет понятного места в сценарии, значит, сейчас ей не место в продукте.

На каких этапах проекта работает: дискавери и проектирование, при формировании MVP и во время планирования релизов и спринтов.

Roadmap

Roadmap проекта фиксирует, что и когда должно быть сделано, и показывает общую траекторию развития продукта. Этот инструмент помогает держать курс и вовремя замечать, когда что‑то идет не так.

Если мы видим, что сроки по roadmap начинают плыть, одной из причин часто оказывается фича, которая прокралась в спринт вне очереди и без фильтров. В таком случае её стоит найти, провалидировать с помощью инструментов, о которых мы говорили выше, и осознанно решить, что с ней делать дальше.

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

А герои кто?

Все. Понимаем, хочется, чтобы на проекте был один Гендальф, который бы на каждую подозрительную идею, доработку или фичу кричал «You shall not pass», но так не работает. Ответственность за то, чтобы не допустить разбухания продукта, лежит на всех. 

Продюсер проекта — главный «плохой полицейский» и первый фильтр на пути фичей. Его задача — держать рамки: сроки, бюджет, ресурсы. Именно продюсер ставит под сомнение каждую новую хотелку.

Владелец продукта — следит за стратегической ценностью каждой новой идеи. Он может сказать: «Да, мы можем это сделать, но ценности для пользователя нет», — и забанить идею ещё до того, как команда начнёт думать о реализации.

Дизайнеры — отвечают за то, чтобы макеты не уводили продукт в сторону. Замечают, когда в интерфейсе появляется функциональность, которой не было в проектировании.

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

Тестировщики — отличают реальный баг от скрытой новой фичи, которая пытается попасть в релиз под видом логичного улучшения. И возвращают ее туда, где ей место — в бэклог (а то и в мусорку, если там вообще не критично, не важно и не сильно нужно).

Вывод

Feature Creep появляется в проекте, не потому что мы плохие, или продукт, или что-то/что-то еще. Это просто неизбежность. И если ее принять, с ней будет сильно легче справиться. Ведь создание и развитие цифрового продукта — это последовательность осознанных выборов. В том числе и в вопросах что делать сейчас, что отложить, а от чего отказаться совсем.

Небольшой дисклеймер в начале. Один из участников нашего исследования рассказал, что опрос показался ему предвзятым: «Авторы чётко пытались навязать мнение что с .NET что‑то не так. Это довольно странно. Наверное, авторы из тех, кто до сих пор считают, что всё закрыто в Микрософте, а .NET работает только на Windows».

Каждое мнение имеет право на существование, но тут считаем уместным предупредить, что это мнение неверно и ничего подобного мы в своих взглядах не преследуем. Напротив – наша позиция зиждется на уверенности в успехе и процветании платформы. Для нас как компании разработчика .NET – одно из ключевых направлений, поэтому глупо было бы с нашей стороны надеяться на его деградацию и скорую смерть, но некоторые провокационные вопросы мы все же вставили. 

А теперь к сути 🙂

Профиль участников исследования

Итак, кто все эти люди, о мнениях которых мы сегодня поговорим? Судя по результатам, 48.3% участников имеют более 7 лет опыта работы с платформой, а это значит, что многие из них видели взлеты и падения .NET, начиная от старого доброго .NET Framework и до его молодого и дерзкого наследника — .NET Core.

Остальные респонденты распределились следующим образом:

• От 1 до 3 лет опыта: 15.8%;
• От 3 до 5 лет: 15.8%;
• От 5 до 7 лет: 15.4%.

Доля новичков с опытом менее года — всего 4.7%. 

Около половины (43%) респондентов трудится на благо финтеха, корпораций и среднего бизнеса. Также существенная часть (17,6%) прошедших опрос работает над проектами в госсекторе и малом бизнесе. Среди участвовавших в исследовании были сотрудники известных компаний: Т-Банк, Ozon, Dodo, Ак Барс Диджитал, Контур, РТК, БКС.

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

Высшее образование и альтернативные пути в IT

Теперь поговорим об образовании. Казалось бы, без профильного образования нельзя стать полноценным разработчиком, но, как показывают данные, 73.8% разработчиков имеют высшее образование в области компьютерных наук или программной инженерии, тогда как 26.2% пришли в IT через самообучение, онлайн-курсы и другие нестандартные пути. То есть, четверть респондентов опровергают миф о том, что без диплома вы не можете достичь успеха в программировании.

Те респонденты, которые использовали для вхождения в профессию курсы, поделились ресурсами, которые оказались им полезны. Лидируют в этом списке курсы ITVDN и Ulearn.me. Также среди ответов нескольких разработчиков нашлись FoxMinded, Rubius, OTUS, MSD, CodeMasters, курсы Иосифа Дзеранова. Еще респонденты выделяли следующие ютуб-каналы: DotNext, Dev jungles, Nick Chapsas, Derek Comartin. 

Найм

Большинство респондентов отметили, что сложностей с наймом .NET специалистов в их компаниях не наблюдается. Однако перевес не слишком велик: об отсутствии сложностей сказали 58,1% опрашиваемых, а об их наличии – 41,9%.

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

И немного о том, как все-таки попасть в .NET команду. Меньше всего респондентов ответили, что получают разработчиков из тех ребят, что оказываются выпускниками школ и курсов программирования. Чаще всего найм происходит с рынка, причем количество таких ответов лидирует с большим отрывом. 

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

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

Итак, загибаем пальцы. Среднестатистический .NET разработчик, чтобы быть востребованным, должен знать, как проектировать и разрабатывать REST API на Web API и описывать его в Swagger, как общаться через ORM EF.Core с БД PosgreSQL или MS SQL и немного Redis, уметь работать с очередями RabbitMQ, Kafka, полнотекстовым индексом Elasticsearch, отслеживать метрики через Kibana или Grafana/Prometheus, использовать для деплоя Docker и Kubernetes. 

Важный вывод из опроса: современный кроссплатформенный .NET Core / .NET 5+ в России победил старый добрый .NET Framework. Только 27% респондентов ответили, что .NET Framework остается востребованным. 

В отличие от других стеков (например, фронтенда), список необходимых технологий в .NET не так широк, достаточно унифицирован и не меняется слишком часто. То есть, освоить его довольно просто: границы очерчены – нужна только ваша усидчивость. 

Зарплаты: то, что интересует всех

Как выяснилось, 78.2% разработчиков отметили, что их зарплата выросла за последние два года. Этот факт сам по себе уже является отличной новостью для тех, кто планирует оставаться на .NET и дальше. Но, как всегда, есть и ложка дегтя — 3.1% респондентов сообщили, что их зарплата снизилась. Причем это не связано с падением производительности (надеемся), скорее всего, тут сработали макроэкономические факторы. У 18,8% респондентов зарплата не менялась.

Насколько же выросли зарплаты у счастливчиков? 

• 25.3% разработчиков сообщили, что их зарплата увеличилась более чем на 60%. Джекпот! На самом деле, рост зарплат начинающих специалистов в разработке за 2 года более 60% является частым явлением, но опрос показывает, что это не только новички. 

• 19.3% заявили о росте на 20-30%. Это уже не такой феерический результат, но все еще вполне достойный.

• 17.2% респондентов отметили увеличение на 10-20%, что также неплохо, если учесть текущие экономические реалии.

Снижение уровня заработной платы, которое отметили всего 11 человек, чаще всего находилось в пределах 10-20% (у 5 человек) и 20-30% (тоже 5 человек). Лишь 1 респондент указал, что его доход упал более чем на 50%.

Одним из важных вопросов нашего исследования было сравнение зарплат .NET-разработчиков с их коллегами, работающими на других стеках. И вот что показали результаты: 59.9% респондентов считают, что их зарплаты примерно равны зарплатам других бэкенд-специалистов. Похоже, что в среднем .NET-разработчики не чувствуют себя ущемленными в финансовом плане по сравнению с коллегами на других технологиях.

Однако 29.1% участников (около 90 человек) всё же считают, что их зарплаты ниже. Причем это может быть связано не столько с самой платформой .NET, сколько с восприятием рынка. Например, Java исторически рассматривается как «корпоративная» технология, а Python — как «язык будущего», особенно в свете его популярности в Data Science и AI-разработке. По нашим данным, больше всего респондентов с таким мнением работает в корпорациях (29 человек) и на проектах для среднего бизнеса (23 человека). Респондентов, пишущих код для малого бизнеса, госсектора, промышленности и e-com, полагающих, что их зарплаты ниже, тоже нашлось достаточно: > 14 человек в каждом секторе.

Только 11% респондентов (чуть больше 30 человек) считают, что их зарплаты выше, чем у разработчиков на других стеках. Больше всего разработчиков с таким мнением работает корпорациях, среднем бизнесе и промышленности.

Почему зарплаты не растут у всех?

Хоть многие .NET-разработчики считают свои зарплаты на уровне с коллегами, возникает вопрос: почему некоторые всё же жалуются на их стагнацию? Возможно, дело в том, что рынок .NET в России часто фокусируется на крупных корпоративных заказчиках, которые не всегда готовы поднимать зарплаты так же быстро, как стартапы или бутиковые IT-агентства.

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

Карьерные планы 

Зарплаты, конечно, играют важную роль в мотивации разработчиков, но они не единственный фактор. Как показывает наше исследование, карьерные планы у разработчиков на платформе .NET могут варьироваться: 58.6% участников сообщили, что довольны своей текущей работой и не планируют её менять. Это довольно высокий показатель стабильности, особенно в условиях, когда IT-рынок постоянно трансформируется.

Однако 37.3% респондентов рассматривают возможность смены работы. Это вполне типичная ситуация для разработчиков, ведь мы все знаем, что IT-рынок предлагает множество возможностей, и иногда смена компании может дать тот самый нужный толчок для роста. Остальные 4.1% активно ищут новую работу, и им можно только пожелать удачи — с их опытом и навыками они наверняка найдут что‑то стоящее.

Фуллстек-разработка: кто эти универсальные солдаты?

31.7% респондентов отметили, что работают как фуллстек-разработчики. Рынок все еще требует специалистов, которые могут закрывать как бэкенд, так и фронтенд задачи.

Примечание: мы явно не очень удачно сформулировали варианты ответов тут. Загадочный «бекенд+другой стек» возможно было интерпретировать по-разному.

Почему фуллстек-разработчики так востребованы? Ответ очевиден: они могут сэкономить массу ресурсов компании, ведь им не нужно переключаться между разными людьми или командами. Они закрывают сразу оба фланга: и серверную логику, и пользовательский интерфейс. 

А с появлением таких инструментов, как  Blazor (который позволяет писать фронтенд на C#), всё становится еще проще для тех, кто уже работает с .NET. Для нас неожиданностью стало, что около 40 респондентов отметили, что Blazor является востребованной технологией. 

Но что с бэкендерами? Неужели все хотят быть фуллстек-разработчиками? Не совсем. 61.7% респондентов предпочитают оставаться в бэкенде. Им вполне комфортно сосредоточиться на своей специализации и не лезть в хаос фронтенда, где каждый второй фреймворк меняется чуть ли не каждый год. «Фронтенд — это боль», — скажет вам любой опытный бэкенд-разработчик, сталкивающийся с новыми версиями React, Angular или, упаси боже, старого доброго jQuery.

Стоит ли идти в .NET начинающим?

На фоне огромного разнообразия технологий и фреймворков, выбор первой платформы может стать нелегким испытанием. Однако наши респонденты практически единодушны: 84.6% из них считают, что начинающим разработчикам стоит идти в .NET. 

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

Перспективы .NET в российских компаниях

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

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

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

Если говорить о той доле голосов, которая все же отмечает неудобства, то вместо описаний, лучше приведем мнения респондентов.

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

Миграция с .NET на другие стеки

Примерно одинаковое количество проектов на .NET находятся на поддержке и пишутся с нуля в командах, в которых работают наши респонденты. 

Большинство респондентов не сталкиваются с необходимостью переводить .NET проекты на новый стек. 

Из тех, кто проекты все же переводит, большинство голосует за Go, на втором месте – Java, за ним – JS и Node. 

Такое распределение сил, кажется, появляется неспроста: большинство респондентов, говоря о языке, на котором стали бы писать, если бы не выбрали .NET, голосуют за Gо. На втором месте Python, за ним Java.

Мнения в целом, конечно, разнятся. Вот, например, мнение одного из респондентов на эту тему: 

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

Хотя доля миграции на Java и Python небольшая, это всё же определенный сигнал. Он указывает на то, что некоторые компании продолжают экспериментировать с переходом на другие платформы. Но и это не значит, что .NET теряет свои позиции. Наоборот, большинство компаний остаются верны платформе, особенно если она уже интегрирована в корпоративные процессы и хорошо себя показывает многие годы.

Перспективы для начинающих и будущее .NET

Когда вы только начинаете свою карьеру в программировании, выбор первого стека — важное решение, определяющее ваш вектор развития на ближайшие (как минимум) пару лет. Ситуация с .NET такова, что его часто недооценивают начинающие программисты. Но вот что говорят опытные разработчики: 84.6% респондентов уверены, что .NET — это отличный выбор для новичков. Причем это мнение не просто сформировано на основе симпатий, а базируется на реальных возможностях и многофункциональности платформы.

Еще одно важное замечание: .NET давно перестал быть исключительно бэкенд-платформой. В прошлом он действительно был больше ориентирован на серверную разработку, но сегодня ситуация изменилась. С появлением таких технологий, как Blazor, разработчики могут писать полноценные клиентские приложения на C#, избегая зависимости от JavaScript. Это отличная новость для тех, кто всегда хотел разрабатывать как бэкенд, так и фронтенд, но не был готов осваивать новые языки.

С другой стороны, это не значит, что фуллстек-разработчики на .NET вытеснят бэкенд-разработчиков. Как показали результаты опроса, 61.7% участников предпочитают работать исключительно с бэкендом. Для них это проверенная и удобная ниша, где они чувствуют себя комфортно, и их ничто не заставляет покидать её ради новых горизонтов. В то время как 31.7% респондентов работают как фуллстек-разработчики, совмещая бэкенд и фронтенд задачи, остальные просто не хотят заниматься тем, что их не интересует.

Перспективы и вызовы .NET-разработки в ближайшие годы

Как показывает наш опрос, большинство разработчиков и компаний, работающих с .NET, не собираются радикально менять свою стратегию в ближайшие годы. .NET остается одной из ведущих платформ для разработки в корпоративном сегменте и, несмотря на все разговоры о переходе на другие языки, многие компании по-прежнему видят в .NET стабильное и проверенное решение. Однако это не значит, что рынок не претерпит изменений.

Практикующие опытные разработчики по большей части если и видят сложности в работе с .NET, то в контексте развития и адаптивности. То есть, суть вопроса не в абсолютной неприменимости или бесперспективности стека, а скорее в векторе его развития. 

Суммируя все вышеописанные пункты и мнения, можно говорить довольно уверенно о том, что направление, конечно, не умирает. Зарплаты растут, проекты развиваются, разработчики преимущественно положением дел довольны, сообщество живет. Тем, кто думал (ну вдруг) о смене стека, похоже, можно расслабиться: даже в госсекторе продолжается работа над .NET проектами, хотя многим кажется, что после отключения возможности свободно поддерживать доступ к необходимым ресурсам дела идут так себе. 

События – это объекты, которые получают уведомления о некотором действии в разрабатываемом ПО и могут запускать реакции на это действие. Разработчик может определить эти действия, добавив к событию обработчик. Разберем в этом материале само понятие событий в .NET и разные способы работы с ними.

Объясним на сахаре

Если говорить простым языком, то можно провести аналогию с просыпанным сахаром. Например, у нас в руках была сахарница, и мы сахар из нее рассыпали – это событие. Что делать, если рассыпался сахар? Идти за веником, чтобы убрать – это и есть обработчик события. Этот обработчик с предназначенным для него действием «сидит у нас в голове». Даже если сахар мы никогда не просыпали, мы все равно знаем, что веником его можно будет убрать. 

Обработчик может меняться. Например, мы покупаем пылесос – теперь у нас в голове меняется обработчик для того же события: мы пойдем не за веником, а за пылесосом (один обработчик мы удалили, другой добавили). Изменение обработчика не влияет на событие. Обработчика может и не быть вовсе – тогда человек будет просто ходить по просыпанному сахару.

О событиях в C#

В C# события существуют с самого начала. Например, при создании элементарного приложения Web Forms, для обработки нажатия на кнопку нужно добавить конструкцию вида

MyButton.Click += new EventHandler(this.MyBtn_Click);

Сlick – это и есть событие, которое уже было добавлено разработчиками в класс Button, а MyBtn_Click – это обработчик, написанный программистом. 

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

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

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

В C# события – это отдельный тип членов класса, обозначаемый ключевым словом event. Наряду со свойствами и параметрами.

Класс, который реализует событие, должен содержать следующую конструкцию:

event тип_делегата имя_события;

• тип_делегата указывает на прототип вызываемого метода (или методов);
• имя_события – конкретный объект объявляемого события.

Добавление обработчика события производится с помощью операции += :

имя_события += обработчик_события;

Разберем добавление обработки событий на примере логирования. Здесь, и в дальнейшем, мы будем использовать консольное приложение .Net 7.0, C# 11.

class Program
{
    static void Main()
    {
        EmailService emailService = new EmailService(emailFrom: "hr@disney.com");

        // Добавляем обработчик события
        emailService.MailSent += LogToConsole;

        emailService.SendMail(emailTo: "Milo.Murphy@disney.com", subject: "Welcome to Disney", body: "Today is your first day...");
    }

    // Обработчик, который логирует в консоль отправленное сообщение
    static void LogToConsole(MailSentEventArgs eventArgs)
        => Console.WriteLine(
            $"[Консоль] Письмо с темой '{eventArgs.Subject}' отправлено с адреса '{eventArgs.EmailFrom}' на адрес '{eventArgs.EmailTo}': {eventArgs.Body}");
}

// Класс в котором реализовано событие
class EmailService
{
    private readonly string _emailFrom;

    public EmailService(string emailFrom)
    {
        _emailFrom = emailFrom;
    }

    // Объявляем событие
    public event MailSentEventHandler? MailSent;

    public void SendMail(string emailTo, string subject, string body)
    {
        // Отправляем письмо пользователю...
        // Send(_emailFrom, emailTo, subject, body);

        // Вызываем метод запуска события
        var eventArgs = new MailSentEventArgs
        {
            EmailFrom = _emailFrom,
            EmailTo = emailTo,
            Subject = subject,
            Body = body
        };
        OnMailSent(eventArgs);
    }

    // Используем метод для запуска события
    protected virtual void OnMailSent(MailSentEventArgs eventArgs)
    {
        MailSentEventHandler? mailSentHandler = MailSent;
        if (mailSentHandler != null)
        {
            mailSentHandler(eventArgs);
        }
    }
}

// Объявляем тип события
public delegate void MailSentEventHandler(MailSentEventArgs eventArgs);

public record MailSentEventArgs
{
    public string? EmailFrom { get; init; }
    public string? EmailTo { get; init; }
    public string? Subject { get; init; }
    public string? Body { get; init; }
}

Мы добавили событие MailSent в класс EmailService и добавили обработчик этого события LogToConsole.

Результат:

[Консоль] Письмо с темой 'Welcome to Disney' отправлено с адреса 'hr@disney.com' на адрес 'Milo.Murphy@disney.com': Today is your first day...

Добавление и удаление обработчиков

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

Цепочка обработчиков реализуется через Delegate.Combine. То есть физически каждый делегат содержит ссылку на реализацию, внутри которой ссылка на следующую реализацию. Обработчик можно удалить в процессе.

static void Main()
    {
        EmailService emailService = new EmailService(emailFrom: "hr@disney.com");

        // Добавляем обработчик события
        emailService.MailSent += LogToConsole;
        emailService.MailSent += LogToFile;

        emailService.SendMail(emailTo: "Milo.Murphy@disney.com", subject: "Welcome to Disney", body: "Today is your first day...");

        emailService.MailSent -= LogToFile;
        emailService.SendMail(emailTo: "Milo.Murphy@disney.com", subject: "Welcome to Disney", body: "Today is your first day...");
    }

    // Обработчик, который логирует в консоль отправленное сообщение
    static void LogToConsole(MailSentEventArgs eventArgs)
        => Console.WriteLine(
            $"[Консоль] Письмо с темой '{eventArgs.Subject}' отправлено с адреса '{eventArgs.EmailFrom}' на адрес '{eventArgs.EmailTo}': {eventArgs.Body}");

    // Обработчик, который логирует в файл отправленное сообщение
    static void LogToFile(MailSentEventArgs eventArgs)
        => Console.WriteLine(
            $"[Файл] Письмо с темой '{eventArgs.Subject}' отправлено с адреса '{eventArgs.EmailFrom}' на адрес '{eventArgs.EmailTo}': {eventArgs.Body}");

Результат:

[Консоль] Письмо с темой 'Welcome to Disney' отправлено с адреса 'hr@disney.com' на адрес 'Milo.Murphy@disney.com': Today is your first day...
[Файл] Письмо с темой 'Welcome to Disney' отправлено с адреса 'hr@disney.com' на адрес 'Milo.Murphy@disney.com': Today is your first day...
[Консоль] Письмо с темой 'Welcome to Disney' отправлено с адреса 'hr@disney.com' на адрес 'Milo.Murphy@disney.com': Today is your first day...

Если нужно выполнить какие‑то действия при добавлении или удалении обработчика, можно переписать функции add/remove у делегата. Мы добавим логирование к действиям добавления/удаления обработчика.

private MailSentEventHandler? mailSent;
	public event MailSentEventHandler MailSent
{
		add 
		{
			mailSent += value;
			Console.WriteLine($"Обработчик {value.Method.Name} добавлен");
		}
		remove
		{
			Console.WriteLine($"Обработчик {value.Method.Name} удален");
			mailSent -= value;
		}
	}

Результат:

Обработчик LogToConsole добавлен
Обработчик LogToFile добавлен
[Консоль] Письмо с темой 'Welcome to Disney' отправлено с адреса 'hr@disney.com' на адрес 'Milo.Murphy@disney.com': Today is your first day...
[Файл] Письмо с темой 'Welcome to Disney' отправлено с адреса 'hr@disney.com' на адрес 'Milo.Murphy@disney.com': Today is your first day...
Обработчик LogToFile удален
[Консоль] Письмо с темой 'Welcome to Disney' отправлено с адреса 'hr@disney.com' на адрес 'Milo.Murphy@disney.com': Today is your first day..

Если в обработчике произойдет ошибка – ошибка будет на уровне приложения. Если добавить try catch при вызове обработчика, то в случае, если произойдет ошибка в первом обработчике, последующие обработчики выполняться не будут. Поэтому следует предусмотреть это в каждом обработчике.

static void LogToConsole(MailSentEventArgs eventArgs)
	{
		try 
		{
			throw new Exception("Ошибка записи");
		}
		catch (Exception e)
		{
			Console.WriteLine(e);
		}
	}

EventHandler

В .NET существует делегат EventHandler, предназначенный как раз для объявления события и принимающий определенный тип входных параметров.

Классы, которые мы собираемся использовать для хранения информации, передаваемой обработчику события, должны наследоваться от типа System.EventArgs. При этом имя типа желательно заканчивать словом EventArgs.

Начиная с .NET Framework 4.5 наследованиe аргументов от System.EventArgs стало не обязательным, но в примере мы его оставим, это никак не повлияет на результат.

Создадим тип параметров, используемых обработчиками:

public class MailSentEventArgs : EventArgs
{
	public string? EmailFrom { get; init; }
	public string? EmailTo { get; init; }
	public string? Subject { get; init; }
	public string? Body { get; init; }
}

И тогда событие может быть объявлено как

public event EventHandler? MailSent;

При этом обработчик должен принимать параметры object sender и MailSentEventArgs args. Где sender – текущий элемент класса, в котором определен event, a args – передаваемые обработчику данные. Обработчик может быть использован для событий в разных классах, поэтому разумнее принимать экземпляр типа object, а не конкретного типа. Так как в этом случае в метод обработчика могут приходить данные от разных событий, но с одинаковыми параметрами.

То есть обработчики будут выглядеть так:

public static void LogToConsole(object? sender, MailSentEventArgs args)
        => Console.WriteLine(
            $"[Консоль] Письмо с темой '{args.Subject}' отправлено с адреса '{args.EmailFrom}' на адрес '{args.EmailTo}': {args.Body}");

 
    	public static void LogToFile(object? sender, MailSentEventArgs args)
        => Console.WriteLine(
            $"[Файл] Письмо с темой '{args.Subject}' отправлено с адреса '{args.EmailFrom}' на адрес '{args.EmailTo}': {args.Body}")

А вызов, поскольку событие представляет собой делегат, например, так:

MailSent?.Invoke(this, eventArgs);

Порой необходимо передать внутрь функции какие‑то данные, а порой действие будет выполняться независимо от внешних данных – тогда передавать внутрь функции ничего не нужно. В случаях, когда не нужно передавать в обработчик никаких данных, мы можем воспользоваться EventArgs.Empty.  То есть объявление события не будет указывать тип аргумента:

public event EventHandler? MailSent;

Обработчик при этом должен принимать object sender и  EventArgs:

static void LogToConsole(object? sender, EventArgs eventArgs)
	=> Console.WriteLine("[Консоль] Отправлено письмо");

а вызов будет выглядеть так:

MailSent?.Invoke(this, EventArgs.Empty);

AsyncEventHandler

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

Подключив к проекту Microsoft.VisualStudio.Threading, получаем возможность сделать обработку делегатов асинхронной.

Тогда объявлять событие мы будем так:

public event AsyncEventHandler? MailSent;

Обработчик будет выглядеть так:

static Task LogToConsoleAsync(object? sender, MailSentEventArgs args)
	{
		Console.WriteLine(
			$"[Консоль] Письмо с темой '{args.Subject}' отправлено с адреса '{args.EmailFrom}' на адрес '{args.EmailTo}': {args.Body}");
		return Task.CompletedTask;
	}

а вызываться так:

await MailSent?.InvokeAsync(this, new MailSentEventArgs());

Реализация событий компилятором

Несколько слов о представлении событий в IL-кодe. При компиляции кроме объявления события также создаются два метода add и remove: они реализуют конструкции += и –=.  

Для наглядности можно скомпилировать и декомпилировать обратно наш код. Тогда станет видно, что добавляет компилятор. Прогнав таким образом наш первоначальный код здесь мы получим следующий код в месте создания события.

public event MailSentEventHandler MailSent
{
    [NullableContext(2)]
    [CompilerGenerated]
    add 
    {
        MailSentEventHandler mailSentEventHandler = this.MailSent;
        while (true)
        {
            // берем текущий делегат
            MailSentEventHandler mailSentEventHandler2 = mailSentEventHandler;

            // добавляем к текущему делегату новый
            MailSentEventHandler value2 = (MailSentEventHandler)Delegate
                                         .Combine(mailSentEventHandler2, value);

            // сравниваем MailSent и mailSentEventHandler2
            // и, если они равны, заменяем MailSent на value2
            // а в mailSentEventHandler записываем исходное значение MailSent
            mailSentEventHandler = Interlocked
             .CompareExchange(ref this.MailSent, value2, mailSentEventHandler2);

            // если предыдущая операция выполнилась успешно - заканчиваем
            // это нужно для безопасной многопоточной работы - если в 
           // параллельном потоке у события изменится список делегатов, 
           // то while запустится повторно и добавит новый делегат к уже 
           // обновленной цепочке делегатов
            if ((object)mailSentEventHandler == mailSentEventHandler2)
            {
                break;
            }
        }
    }
    [NullableContext(2)]
    [CompilerGenerated]
    remove
    {
        MailSentEventHandler mailSentEventHandler = this.MailSent;
        while (true)
        {
            // берем текущий делегат
            MailSentEventHandler mailSentEventHandler2 = mailSentEventHandler;

            // удаляем из него value
            MailSentEventHandler value2 = (MailSentEventHandler)Delegate
                                          .Remove(mailSentEventHandler2, value);

            // сравниваем MailSent и mailSentEventHandler2
            // и, если они равны, заменяем MailSent на value2
            // а в mailSentEventHandler записываем исходное значение MailSent            
            mailSentEventHandler = Interlocked
             .CompareExchange(ref this.MailSent, value2, mailSentEventHandler2);

            // если предыдущая операция выполнилась успешно - заканчиваем
            if ((object)mailSentEventHandler == mailSentEventHandler2)
            {
                break;
            }
        }
    }
}

Паттерн «Наблюдатель»

Реализация событий укладывается в паттерн «Наблюдатель», суть которого в наличии одного наблюдаемого объекта и нескольких наблюдателей. Если возвращаться к аналогии с сахаром, в рамках паттерна сахарница будет наблюдаемым объектом, а человек, который рассыпал сахар или просто находился рядом – наблюдателем. Наблюдателей может быть больше одного (кто‑то с веником, а кто‑то с пылесосом). Далее, когда рассыпается сахар, сначала один наблюдатель делает свои действия, а другой следом – свои.

Паттерн «Наблюдатель» можно реализовать через добавления наблюдателей как реализаций делегата, а можно – через добавление наблюдателей в список, хранящийся в наблюдаемом объекте.

Ниже приведен пример реализации этого паттерна без использования событий.

class Program
{
    static void Main()
    {
        EmailService emailService = new EmailService("hr@disney.com");

        // Добавляем обработчик события
        var consoleObserver = new ConsoleObserver(emailService);
        var fileObserver = new FileObserver(emailService);

        emailService.SendMail(
            emailTo: "Milo.Murphy@disney.com",
            subject: "Welcome to Disney",
            body: "Today is your first day...");

        fileObserver.StopObserve();

        emailService.SendMail(
            emailTo: "Milo.Murphy@disney.com",
            subject: "Welcome to Disney",
            body: "Today is your first day...");
    }
}

interface IObserver
{
    void Update(string emailFrom, string emailTo, string subject, string body);
}

interface IObservable
{
    void RegisterObserver(IObserver o);
    void RemoveObserver(IObserver o);
}

class EmailService : IObservable
{
    private readonly List _observers;
    private readonly string _emailFrom;

    public EmailService(string emailFrom)
    {
        _emailFrom = emailFrom;
        _observers = new List();
    }

    public void RegisterObserver(IObserver o)
    {
        _observers.Add(o);
    }

    public void RemoveObserver(IObserver o)
    {
        _observers.Remove(o);
    }

    protected void MailSent(string emailTo, string subject, string body)
    {
        foreach (IObserver o in _observers)
        {
            o.Update(_emailFrom, emailTo, subject, body);
        }
    }

    public void SendMail(string emailTo, string subject, string body)
    {
        // Отправить письмо пользователю
        //Send(_emailFrom, emailTo, subject, body);

        // Запускаем методы наблюдателей
        MailSent(emailTo, subject, body);
    }
}

class ConsoleObserver : IObserver
{
    IObservable? _stock;
    public ConsoleObserver(IObservable obs)
    {
        _stock = obs;
        _stock.RegisterObserver(this);
    }
    public void Update(
        string emailFrom,
        string emailTo,
        string subject,
        string body)
    {
        Console.WriteLine($"[Консоль] Письмо с темой '{subject}' отправлено с адреса '{emailFrom}' на адрес '{emailTo}': {body}");
    }

    public void StopObserve()
    {
        if (_stock is null)
        {
            return;
        }
        _stock.RemoveObserver(this);
        _stock = null;
    }
}

class FileObserver : IObserver
{
    IObservable? _stock;
    public FileObserver(IObservable obs)
    {
        _stock = obs;
        _stock.RegisterObserver(this);
    }

    public void Update(
        string emailFrom,
        string emailTo,
        string subject,
        string body)
    {
        Console.WriteLine($"[Файл] Письмо с темой '{subject}' отправлено с адреса '{emailFrom}' на адрес '{emailTo}': {body}");
    }

    public void StopObserve()
    {
        if (_stock is null)
        {
            return;
        }
        _stock.RemoveObserver(this);
        _stock = null;
    }
}

Результат:

[Консоль] Письмо с темой 'Welcome to Disney' отправлено с адреса 'hr@disney.com' на адрес 'Milo.Murphy@disney.com': Today is your first day...
[Файл] Письмо с темой 'Welcome to Disney' отправлено с адреса 'hr@disney.com' на адрес 'Milo.Murphy@disney.com': Today is your first day...
[Консоль] Письмо с темой 'Welcome to Disney' отправлено с адреса 'hr@disney.com' на адрес 'Milo.Murphy@disney.com': Today is your first day...

Минусы и плюсы такой реализации паттерна «Наблюдатель»

Минусы

• в этой реализации нам пришлось самим писать интерфейсы, а для событий есть прописанные интерфейсы и классы, которыми остается только воспользоваться;
• более высокий порог вхождения – нужно разобраться с работой паттерна;
• под каждое событие придется писать свой набор интерфейсов из‑за различий данных события, передаваемых в метод IObserver.Update (либо аналогично событиям использовать тип object, но тогда теряется наглядность);
• при этом код стал более отлаживаемым – весь код доступен для редактирования, и более прозрачным – можно пройтись по реализации и в точности посмотреть работу (в событиях, например, не очевидно, что будет, если случится эксепшен в одном из цепочки делегатов).

Плюсы

• подобную реализацию можно использовать также в языках, где нет делегатов – например, С++;
• можно обеспечить распараллеливание реакции наблюдателей;
• можно отловить случившийся эксепшн в цепочке и обработать в зависимости от логики задачи;
• точные контракты: есть конкретные методы с конкретным набором параметров под нужное событие, а не набор параметров вида "object sender, EventArgs e".

MediatR

В библиотеке MediatR из коробки есть своя реализация событий. Это не существующие в C# события, но есть некоторое сходство.

Как следует из названия, MediatR – это реализация паттерна «Посредник». Суть паттерна в создании прослойки между частями кода. Это нужно в случае наличия большого количества связей между объектами – есть вероятность запутать логику реализации. 

«Посредник» ограничивает объекты от явных ссылок друг на друга, уменьшая количество взаимосвязей. Основной принцип реализации в том, что мы создаем объект и можем добавить обработчики для него. При этом достаточно использовать у типа отправляемого объекта интерфейс IRequest  или INotification и указать у обработчика интерфейс, связанный с типом объекта. Тогда MediatR вызовет нужный обработчик при выполнении команды Send для интерфейса IRequest и Publish для интерфейса INotification, в который будет передан объект.

Обычно при работе с библиотекой MediatR используются интерфейсы IRequest и IRequestHandler. Тип, используемый медиатором, должен быть унаследован от IRequest<TResponse>, где TResponse – результат обработки запроса, а обработчик должен поддерживать интерфейс IRequestHandler<TRequest, TResponse>, где TRequest – созданный нами тип с интерфейсом IRequest. Но нужно помнить, что обработчик здесь может быть только один.

Для случая множества обработчиков в MediatR был создан интерфейс INotification. И, соответственно, обработчики должны поддерживать интерфейс INotificationHandler<TRequest>.

Рассмотрим пример (необходимо установить nuget-пакет MediatR и nuget-пакет Microsoft.Extensions.DependencyInjection):

using System.Reflection;
using MediatR;
using Microsoft.Extensions.DependencyInjection;

class Program
{
    static async Task Main()
    {
        var serviceCollection = new ServiceCollection()
            .AddMediatR(cfg =>
         cfg.RegisterServicesFromAssembly(Assembly.GetExecutingAssembly()))
            .BuildServiceProvider();

        var mediator = serviceCollection.GetRequiredService();
        EmailService emailService = new EmailService(mediator, "hr@disney.com");

        await emailService.SendMailToUserAsync(
            emailTo: "Milo.Murphy@disney.com",
            subject: "Welcome to Disney",
            body: "Today is your first day...");
    }
}

class MailSentRequest : INotification
{
    public string? EmailFrom { get; init; }
    public string? EmailTo { get; init; }
    public string? Subject { get; init; }
    public string? Body { get; init; }
}

class ConsoleHandler : INotificationHandler
{
    public Task Handle(
        MailSentRequest request,
        CancellationToken cancellationToken)
	{
		Console.WriteLine(
			$"[Консоль] Письмо с темой '{request.Subject}' отправлено с адреса '{request.EmailFrom}' на адрес '{request.EmailTo}': {request.Body}");
		return Task.CompletedTask;
	}
}

class FileHandler : INotificationHandler
{
    public Task Handle(
        MailSentRequest request,
        CancellationToken cancellationToken)
	{
		Console.WriteLine(
			$"[Файл] Письмо с темой '{request.Subject}' отправлено с адреса '{request.EmailFrom}' на адрес '{request.EmailTo}': {request.Body}");
		return Task.CompletedTask;
	}
}

class EmailService
{
    private readonly string _emailFrom;
    private readonly IMediator _mediator;

    public EmailService(IMediator mediator, string emailFrom)
    {
        _mediator = mediator;
        _emailFrom = emailFrom;
    }

    public async Task SendMailToUserAsync(
        string emailTo,
        string subject,
        string body)
    {
        // Отправить письмо пользователю
        //Send(_emailFrom, emailTo, subject, body);
        // Вызываем метод запуска события
        await MailSentAsync(_emailFrom, emailTo, subject, body);
    }

    protected async Task MailSentAsync(string emailFrom, string emailTo, string subject, string body)
    {
        var request = new MailSentRequest
        {
            EmailFrom = emailFrom,
            EmailTo = emailTo,
            Subject = subject,
            Body = body
        };
        await _mediator.Publish(request);
    }
}

Результат:

[Консоль] Письмо с темой 'Welcome to Disney' отправлено с адреса 'hr@disney.com' на адрес 'Milo.Murphy@disney.com': Today is your first day...
[Файл] Письмо с темой 'Welcome to Disney' отправлено с адреса 'hr@disney.com' на адрес 'Milo.Murphy@disney.com': Today is your first day...

Плюсы и минусы использования MediatR:

Плюс

• использование MediatR уменьшает количество зависимостей, что будет плюсом при большом количестве объектов и связей между ними.

Минусы

• классы хэндлеров помечаются не используемыми (это можно исправить, навесив атрибут [UsedImplicitly]);
• нельзя «по щелчку» перейти к реализации;
• не всегда очевидно, какие хэндлеры будут вызваны при вызове медиатора;
• не получится во время выполнения программы добавить/удалить обработчик;
• невозможно (или сложно) установить четкий порядок вызова обработчика. Он больше подходит для вызова независимых друг от друга обработчиков.

Есть способ обойти второй минус из перечисленных. Нужно реализацию запроса и обработчик поместить в один partial-класс:

public partial class MailSent
{
  public class Request : INotification
  {
	public string? EmailFrom { get; init; }
	public string? EmailTo { get; init; }
	public string? Subject { get; init; }
	public string? Body { get; init; }
  }
}

public partial class MailSent
{
  public class ConsoleHandler : INotificationHandler
  {
    public Task Handle(
		Request request,
		CancellationToken cancellationToken)
	{
		Console.WriteLine(
			$"[Консоль] Письмо с темой '{request.Subject}' отправлено с адреса '{request.EmailFrom}' на адрес '{request.EmailTo}': {request.Body}");
		return Task.CompletedTask;
	}
  }
}

public partial class MailSent
{
  public class FileHandler : INotificationHandler
  {
    public Task Handle(
		Request request,
		CancellationToken cancellationToken)
	{
		Console.WriteLine(
			$"[Файл] Письмо с темой '{request.Subject}' отправлено с адреса '{request.EmailFrom}' на адрес '{request.EmailTo}': {request.Body}");
		return Task.CompletedTask;
	}
  }
}

тогда при создании запроса нужно указывать оба класса:

protected async Task MailSentAsync(
		string emailFrom,
		string emailTo,
		string subject,
		string body)
	{
		var request = new MailSent.Request
		{
			EmailFrom = emailFrom,
			EmailTo = emailTo,
			Subject = subject,
			Body = body
		};
		await _mediator.Publish(request);
	}

При попытке перейти «по щелчку» к классу MailSent нам будет предложен выбор перейти к запросу или к реализации.

Дополнительные возможности

В MediatR есть удобная реализация поведения конвейера (pipeline behavior). Для этого используется интерфейс IPipelineBehavior<TRequest, TResponse>.

services.AddScoped(typeof(IPipelineBehavior<,>), typeof(MailSentBehavior<,>));
 
 
class MailSentBehavior 
    : IPipelineBehavior 
{
      	public async Task Handle(
            TRequest request,
            RequestHandlerDelegate next,
            CancellationToken cancellationToken)
      	{
            	try 
            	{
                  	Console.WriteLine($"Перед запуском {typeof(TRequest).Name}");
                  	return await next();
            	}
            	finally
            	{
                  	Console.WriteLine($"После запуска {typeof(TRequest).Name}");
            	}
    	}
  }

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

К сожалению, мы можем использовать PipelineBehavior только для   IRequest и не можем для INotification.

Чтобы реализовать подобную функциональность для событий нужно переопределить NotificationPublisher.

class Program
{
    static async Task Main()
    {
        var serviceCollection = new ServiceCollection()
            .AddMediatR(config =>
        {
           config.RegisterServicesFromAssembly(Assembly.GetExecutingAssembly());
           config.NotificationPublisher = new MailSentPublisher();
           config.NotificationPublisherType = typeof(MailSentPublisher);
        })
            .BuildServiceProvider();

        var mediator = serviceCollection.GetRequiredService();
        EmailService emailService = 
               new EmailService(mediator: mediator, emailFrom: "hr@disney.com");

        await emailService.SendMailToUserAsync(
			emailTo: "Milo.Murphy@disney.com",
			subject: "Welcome to Disney",
			body: "Today is your first day...");
    }
}

class MailSentPublisher : INotificationPublisher
{
    public async Task Publish(
		IEnumerable handlerExecutors,
		INotification notification,
		CancellationToken cancellationToken)
    {
        foreach (var handler in handlerExecutors)
        {
            try 
            {
                Console.WriteLine(
			$"Перед запуском {handler.HandlerInstance.GetType().Name}");
                await handler.HandlerCallback(notification, cancellationToken)
					.ConfigureAwait(false);
            }
            catch (Exception e)
            {
                Console.WriteLine($"Произошла ошибка {e.Message}");
            }
            finally
            {
                Console.WriteLine(
			$"После запуска {handler.HandlerInstance.GetType().Name}");
            }
        }
    }
}

Результат:

Перед запуском ConsoleHandler
[Консоль] Письмо с темой 'Welcome to Disney' отправлено с адреса 'hr@disney.com' на адрес 'Milo.Murphy@disney.com': Today is your first day...
После запуска ConsoleHandler
Перед запуском FileHandler
[Файл] Письмо с темой 'Welcome to Disney' отправлено с адреса 'hr@disney.com' на адрес 'Milo.Murphy@disney.com': Today is your first day...
После запуска FileHandler

Так, мы добавили некую обработку до и после запуска каждого обработчика события, а еще обеспечили выполнение следующих, даже если в предыдущем возникла ошибка.

Вместо заключения

Мы рассмотрели несколько вариантов реализации обработчиков Событий: с помощью стандартных средств C#, с помощью средств библиотеки MediatR и написали самостоятельно, реализовав паттерн Наблюдатель. В разных ситуациях может быть удобно использовать разные варианты, но полезно знать и об альтернативных возможностях.

Меня зовут Дима. Я Frontend разработчик в компании fuse8. Работая с TypeScript, рано или поздно сталкиваешься с вопросом: что выбрать — типы или интерфейсы? В нашей команде мы активно используем TypeScript, уделяя особое внимание типам. В статье я хотел бы поделиться особенностями работы с типами и интерфейсами, которые могут быть полезны в вашей практике.

Основные отличия типов и интерфейсов

Типы используются для задания именованных типов данных, включая примитивы, объекты, функции и массивы. Они позволяют объединять или пересекать типы и поддерживают использование ключевых слов typeof, keyof при присвоении.

Интерфейсы служат для описания структуры объектов. Интерфейсы поддерживают декларативное объединение и могут быть расширены другими интерфейсами или классами.

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

Для примитивов и кортежей используйте типы

Создать строковый, числовой или другой примитивный тип с помощью интерфейса просто не получится.

Пример с примитивами:

В интерфейсах примитивные типы можно использовать в описании свойств объектов:

Пример с кортежем:

Добиться похожего поведения можно и с помощью интерфейса, но так не рекомендуется делать:

Интерфейсы с одинаковыми именами объединяются

Интерфейсы обладают особенностью, которая отсутствует у типов: если у вас есть несколько интерфейсов с одинаковыми именами, они могут объединяться. Это особенно полезно, когда вы работаете с внешними библиотеками или проектами, где структуру объекта нужно расширять.

Рассмотрим пример:

В этом примере два интерфейса User сливаются в один, который содержит оба свойства: id  и  name. Это позволяет гибко добавлять новые поля к уже существующим структурам, не трогая оригинальный код. Если бы вы пытались сделать то же самое с типами, TypeScript выдал бы ошибку — названия типов должны быть уникальными, даже если типы находились бы в разных файлах.

Объединение происходит не на уровне одного файла, а на уровне всего проекта. Поэтому важно помнить, особенно, если проект большой, что есть возможность случайно расширить уже существующий интерфейс. Также это правило работает для предустановленных интерфейсов, например, если нужно затипизировать комментарий с помощью интерфейса, выбрав название Comment, то мы расширим интерфейс Comment, который находится в lib.dom.d.ts.

Для большего погружения можно ознакомиться с  документацией по объединению интерфейсов.

Типы можно пересекать и объединять, интерфейсы – наследовать

Пересечение типов осуществляется с помощью оператора &:

Здесь UserArticle объединяет свойства как пользователя, так и статьи.

Похожего поведения в интерфейсах можно добиться с помощью ключевого слова extends:

Но это не одно и тоже, extends используется только для интерфейсов и подразумевает наследование, тогда как пересечение типов с помощью & может использоваться как для интерфейсов, так и для любых других типов.

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

Однако реальные тесты показывают, что разница незначительна. Например, проверка 10 тысяч одинаковых конструкций для интерфейсов и типов не выявила существенной разницы в скорости компиляции. Эксперимент можно найти здесь.

Другое отличие заключается в том, что если оба типа являются объектами, и в этих объектах содержатся поля с одинаковыми названиями, но разными типами, то extends выдаст ошибку, а при использовании& ошибки не будет. Рассмотрим пример:

В UserArticle ошибки нет, но id имеет тип never, так как id не может быть одновременно и строкой и числом. А при использовании extends получаем ошибку:

Типы также поддерживают объединение с помощью оператора |. Это удобно, когда тип может быть один из нескольких вариантов:

Лаконичность типов при использовании Utility Types

Типы имеют более более лаконичный синтаксис при использовании Utility Types, чем интерфейсы. Например, для создания типа с необязательными полями можно воспользоваться утилитой Partial.

Вот как это выглядит для типов:

Теперь давайте посмотрим, как это будет выглядеть с интерфейсом:

В случае с интерфейсом нам приходится добавлять дополнительные конструкции extends и пустые фигурные скобки {}, что делает код менее читабельным. Это не критично, но может добавлять лишний «шум», особенно если часто используются такие утилиты как Partial, Pick, Omit и другие.

Свойства интерфейсов сохраняют источник

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

Пример:

Если вы посмотрите на объект userArticle, поле id будет связано с User.id: string, а name — с Article.name: string. Это может помочь лучше понять, откуда взято конкретное свойство при сложных наследованиях.

Теперь давайте перепишем тот же пример на типах:

В случае с типами при отладке оба поля id и name будут просто строками (string), и информация о том, откуда они взяты, будет потеряна.

Когда использовать типы, а когда интерфейсы?

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

Использование интерфейсов можно рассмотреть в библиотеках, которые будут ставиться в проекты, чтобы дать возможность расширить типы при необходимости. Либо в проектах, которые используют подход ООП.

Полезные ссылки:

• Merging Interfaces в TypeScript
• Преподчитайте наследование над пересечением из Гайда по производительности TypeScript

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

User Story Mapping — это метод, который помогает организовать задачи разработки продукта в виде карты, основанной на сценариях пользователей. В отличие от традиционного списка задач, USM описывает фичи с точки зрения ценности для пользователя, а не на уровне технической реализации. Поэтому команде проще отсюда понять, какие действия пользователь выполняет, и как каждая функция продукта поддерживает эти действия. Так получается сосредоточиться на создании полезной функциональности.

Из чего получается User Story Mapping

1. Роли пользователей — это конкретные группы пользователей, которые взаимодействуют с продуктом. 
2. Истории пользователей (User Stories) — это краткие описания того, что пользователь хочет достичь с помощью продукта. Например: «Как тренер, я хочу создавать тренировочные планы, чтобы эффективно отслеживать прогресс моих клиентов».
3. Карточки задач — конкретные задачи, которые нужны для выполнения пользовательских историй. Эти задачи помогают команде понять, что именно нужно разработать, и как это связано с потребностями пользователей.

Проблемы классического подхода к планированию

Многие всё ещё используют техническое задание (ТЗ) в качестве основы для планирования продукта. Мы в таком подходе видим парочку проблем:

• Сложность для клиента. Техническое задание часто превращается в сложный и непонятный документ, который сложно интерпретировать. Там появляется огромное множество описанных мелочей и деталей, которые отвлекают от фокуса на самом важном – что за продукт мы делаем и зачем.
• Узконаправленное видение у команды. Разработчики часто погружены в технические детали и упускают из виду общую картину продукта и потребности пользователей.

Вместо составления спецификаций и ТЗ мы делаем информативную и комплексную документацию. Ее мы составляем в ходе тщательного анализа запроса заказчика и описываем продукт так, чтобы было понятно и бизнесу, и разработке.

Читайте также:

Почему продуктовое проектиро­вание лучше формального ТЗ 

Вениамин Мустафин, Директор по развитию бизнеса

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

Формируем USM шаг за шагом

Давайте для начала верхнеуровнево зафиксируем, как получается целостная USM для продукта, и из чего она состоит.

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

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

1. Определение ролей пользователей. Важно понимать, кто ваши конечные пользователи. Например, в системе управления футбольной лигой это могут быть тренеры, администраторы и менеджеры лиги. Каждая роль должна быть описана максимально конкретно.
2. Создание сценариев взаимодействия. Описываем пошагово, как каждый пользователь будет использовать продукт. Например, тренер может создавать тренировочные планы, следить за прогрессом игроков и корректировать их тренировки, в зависимости от целей.
3. Создание карточек задач. Разбиваем каждый сценарий на задачи, которые описываем в карточках – каждую по отдельности. Их соединяем с пользовательскими ролями.

Так у нас получается наглядная карта функциональности системы.

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

Пример из проекта

Покажем, как все это работает. Возьмем карточки из проектирования продукта для одного из наших проектов – Freedom Football Manager. Это сервис для управления футбольной лигой Казахстана.

Пользовательская роль: главный тренер.

Функциональные блоки: аккаунт, команда, тренировки.

Сценарии: авторизация, выбор команды, управление тренерами, управление игроками, управление инфраструктурой, мои тренировки, база тренировок, создание тренировки, редактирование тренировки, удаление тренировки.

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

Связь «Карта влияний→Документация→USM»

Показываем все на том же примере – сервисе для управления футбольной лигой Казахстана. Возьмем функциональность создания тренировок в системе.

Сначала делаем карту влияний. Формируем цель продукта и метрики успеха в нем: затем выделяем пользовательскую роль – тренера команды – и описываем, что ему хочется делать лучше с помощью сервиса. 

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

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

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

Теперь у нас есть необходимый набор артефактов, чтобы сделать USM не ориентировочной и примерной, а отражающей ровно те функции сервиса, которые нам необходимы на текущем этапе. Текущий этап здесь – это, например, период разработки первой (или очередной) версии системы, которая может быть по-своему функционально ограничена, но все равно должна работать на определенную цель. 

Приоритизация USM: не растягиваем фазу проектирования бесконечной детализацией

Всегда нужно в чем‑то себя ограничивать, проектируя функциональность сервиса. Создавая продукт с нуля, как в нашем примере, легко напихать сходу миллион возможностей, и, если не разделить их на версии, никогда не дойти до релиза. «Резать» нужно в двух направлениях: в количестве фич и их детализации по ходу проектирования. 

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

Читайте также:

Карта влияний: как на старте повысить шансы проекта на успех

Вениамин Мустафин, Директор по развитию бизнеса

Вернемся к нашему примеру с футбольным менеджером. Вот хороший сценарий: «я создаю тренировку». Другой хороший сценарий: «я заполняю данные тренировки». Здесь бизнес понимает, что тренер может создать тренировку и загрузить ее нужными параметрами. Если начинаем раскладывать и дробить дальше, можем получить что‑то вроде «я заполняю название тренировки», «я заполняю дату тренировки», «я заполняю учебную программу тренировки» – это уже примеры плохих сценариев, просто не имеющие смысла.  

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

Когда USM согласован с бизнесом, он передается разработчикам для оценки трудозатрат. Затем вся информация преобразуется в таблицы, и создается дорожная карта, которая разбивается на спринты и конкретные задачи для команды. Таким образом, с самого начала работы над продуктом обеспечивается синхронность действий между бизнесом и предполагаемыми пользователями.

Клиент, знает, чего хочет, но этого недостаточно

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

Команда разработки, видя такой «список покупок», часто считает, что клиент – эксперт в своем бизнесе, поэтому можно следовать этим требованиям буквально. Но на практике, если команда разработки не вовлечена в обсуждение целей, ее работа сводится к выполнению задач по принципу «сделай то, что сказано». И тут команда превращается в группу исполнителей, а не партнеров. В результате создается продукт, который «работает по ТЗ», но не обязательно помогает бизнесу.

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

Почему цели важнее списка фич?

Фокус на результате

Представьте, что вы запускаете сервис для банка. Можно сказать: «Сделайте кредитный калькулятор», а можно поставить цель: «Увеличить количество заполненных анкет на сайте в два раза». В первом случае команда просто выполняет задачу, не углубляясь в суть. Во втором – она фокусируется на результате и начинает предлагать решения, которые действительно помогут достичь цели. Разница в уровне погружения – колоссальная.

Приоритеты определяются целями

В разработке всегда наступает момент, когда становится понятно, что выполнить всё задуманное в срок невозможно. Если нет целей, задачи, которые придуманы без привязки к чему-либо, могут быть мертворожденными. Начинается хаос: что отложить, а что сделать? Кто‑то решает это на основе интуиции, но это плохая валидация. Цели и метрики нужны, чтобы вычленить главное. Иначе начинается субъективизация – разные ЛПРы говорят: «Ну вот это уж точно надо внедрить», и у каждого «вот это» разное. При наличии оформленных целей, проще решить, какие задачи критичны для достижения успеха, а какие можно отложить или вовсе убрать.

Ответственность делится между клиентом и командой

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

Цена незафиксированных целей: как потратить время впустую

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

Что произошло

Команда берет макеты и текстовые описания, начиная работу. Аналитик погружается в разработку калькулятора баллов — это был самый подробно описанный элемент. На это уходит несколько дней: описание логики работы, уточнение формул и проектирование интерфейса.

Но когда аналитик возвращается к клиенту за уточнениями, звучит неожиданное:

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

Результат стараний

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

Как стоило сделать

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

• Что сейчас вызывает наибольшие сложности у пользователей?
• Каковы основные жалобы или пожелания?
• Какие задачи критичны сейчас?
• Какие из них можно отложить на потом?

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

Чему это нас учит?

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

Как определить цели проекта и уйти от пунктов в списке покупок

Базовый ответ на этот вопрос: формулируйте по SMART. Правильная цель должна быть конкретна, измерима, достижима, релевантна и привязана ко времени. Но эти характеристики не всегда получается применить в полном объеме и сразу. Поэтому рассмотрим на понятных примерах, как неоформленные цели можно преобразовать в «правильные».

Банковская сфера

Продукт: Мобильное приложение

Клиент приходит с запросом: «Нужно приложение, чтобы пользователи могли управлять своими счетами и кредитами». Это классический пример списка покупок. Команда разработчиков, следуя указаниям, делает базовую функциональность. Однако спустя месяцы использования аналитика показывает, что приложение не помогает увеличить объем активных пользователей.

Сравните это с подходом, основанным на целях:

Цель: Увеличить долю активных пользователей на 20% за 6 месяцев.

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

Образовательные платформы

Продукт: Платформа онлайн образования

Клиент говорит: «Нужна платформа с видеоуроками, тестами и сертификатами». Команда реализует все пожелания, но результаты разочаровывают: студенты бросают курс, не доходя до середины. Почему?

Цель не была поставлена. Если бы фокус был на достижении завершения курса минимум 70% участников, подойти к задаче можно было бы иначе: проработать геймификацию, мотивационные рассылки и персонализированную поддержку.

Ритейл и e-commerce

Продукт: Онлайн магазин

Клиент просит: «Создайте функциональность фильтров, корзины и оплаты». Готовый продукт работает, но трафик не конвертируется в продажи. Почему?

С целью «Увеличить коэффициент конверсии на 15%» команда изначально проанализировала бы путь пользователя, акцентировала внимание на удобстве поиска товаров, рекомендательных системах и оформлении процесса оплаты, чтобы убрать все «узкие места».

Как ставить цели: инструменты и подходы

Теперь, когда с важностью целей всё ясно, поговорим о том, как их правильно сформулировать. Вот несколько инструментов, которые помогают на старте:

1. Понимание задачи (ПЗ)
   Это базовый уровень фиксации целей. ПЗ помогает структурировать запрос клиента и понять, как он пришел к своему видению. 
2. Карта влияний
   Этот инструмент связывает цели бизнеса и функции продукта. Она помогает выделить, какие задачи действительно важны для достижения целей, а какие можно отложить. Карта влияний отлично работает, когда у клиента уже есть общее понимание, что нужно делать.
3. Карта гипотез
   Подходит для проектов, где непонятно, с чего начать. Она помогает генерировать гипотезы и задачи, а также увязывать их с реальными потребностями пользователей. Если карта влияний ориентирована на бизнес, то карта гипотез погружает в пользовательский опыт и помогает создавать что‑то действительно полезное.

Алгоритм постановки целей

1. Определите главную бизнес-цель (увеличить доход, повысить лояльность, привлечь новых клиентов).
2. Разбейте цель на измеримые метрики (рост на X%, конверсия Y%).
3. Свяжите метрики с задачами через карту влияний.
4. Используйте карту гипотез для поиска нестандартных решений.

Как начать правильно

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

Что такое ТЗ и почему его составляют

Техническое задание (ТЗ) – это документ или пакет документов, определяющих требования и порядок создания IT-продукта. Проще говоря, это задание исполнителю от заказчика, в котором прописано, какой результат хочет получить заказчик, и как исполнитель должен его достигать. 

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

Нельзя просто так взять и составить крутое ТЗ

У классического подхода к созданию ТЗ есть 4 основные проблемы:

1. Сложно оценить объём работ 
2. ТЗ пишется долго
3. Требования описываются очень детально для разработчиков, но от этого становятся нечитаемыми для бизнеса
4. ТЗ устаревает в процессе собственного составления

Теперь расшифруем.

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

Дальше просто факт: для крупного проекта с разработкой от 6-ти месяцев составление документации занимает 2-3 месяца без учета верхнеуровневого описания требований. Еще один факт: бизнес покупает у нас не ТЗ – он хочет работающий продукт. При этом процесс создания ТЗ оплачивается. Заказчик все это время в ожидании. То есть, он знает, что исполнители заняты делом, вникают, но результат «пощупать» пока нельзя. Находиться в таком подвешенном состоянии не нравится никому. 

Теперь о том, что внутри. Сила ТЗ в его детализации. Грубо говоря, по хорошему ТЗ команда без лишних вопросов может запилить работающий продукт. Но это фантазии. Во-первых, потому что нельзя идеально детализировать ТЗ. Во-вторых, потому что сильной команде разработки не нужно, чтобы за нее решали, как реализовать «вот эту вот фичу» – она сама придумает изящное решение. А раз так, то время (и деньги) на детальные описания тратится зря. 

Помните про 2-3 месяца создания документации? Так вот за этот срок она может стать дважды, а то и трижды неактуальной. Причин масса: вновь появившиеся требования бизнеса, выход новой версии языка программирования, обновление API для интеграций, новые тренды рынка. 

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

Ну и откровение напоследок. Классические ТЗ пытаются быть хорошими и для бизнеса, и для разработчиков. Это снова фантазии. Невозможно создать техническую инструкцию с легко считываемыми бизнес-смыслами. Это как писать руководство по эксплуатации автомобиля, надеясь, что оно будет работать как презентация для привлечения новых инвесторов. 

Как сохранить пользу ТЗ и избавиться от его несовершенств

1. Сделать оценку объема работ проще
2. Ускорить создание документации
3. Меньше деталей – больше бизнес-пользы
4. Меньше времени на описание – выше актуальность

Вместо длительного сбора требований мы стали проводить продуктовое проектирование. Оно занимает не более 5 недель. Сначала примерно договариваемся с заказчиком о занятости на каждую неделю, потом уточняем план. Отвечаем в ходе исследования на вопросы:

• Зачем создается продукт и каких бизнесовых целей он должен достичь?
• Что эта за система и как она должна работать?
• Какую архитектуру и какие технологии мы будем использовать?
• Как пользователь будет взаимодействовать с системой?
• Сколько будет стоить и сколько будет длиться разработка системы?
• Что мы делаем в первую очередь, а что оставляем на пострелизное развитие?

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

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

Результат продуктового проектирования – минимальный набор артефактов: 

1. Определение целей и границ проекта — Импакт Маппинг
2. Проработка и описание системы и ее работы — Описание системы
3. Архитектура и технологии для разработки системы
4. Приоритезация задач и выделение первой версии системы
5. Роадмап проекта со сроками и стоимостью разработки. Их всегда фиксируем точно. Фичи на пострелизное развитие проекта добавляем в беклог и роадмап на развитие продукта.
6. Набор метрик для отслеживания результата.

Дальше о том, что внутри каждого из артефактов.

Определение целей и границ проекта

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

Читайте также:

Карта влияний: как на старте повысить шансы проекта на успех

Вениамин Мустафин, Директор по развитию бизнеса

Синхронизируем нашу команду с бизнесом. Создаем базу для дальнейшей разработки и принятия решений. Всего этого не сделать без грамотной постановки целей. 

Читайте также:

Постановка целей в digital-разработке: как не провалить запуск цифрового продукта

Вениамин Мустафин, Директор по развитию бизнеса

Сбор требований и описание системы

Самый трудоемкий этап — 60–70% от всего объема работ.

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

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

Это работает. Для одного нашего клиента мы делали проектирование с описанием системы. Согласно фидбеку, время на онбординг в проект после этого стало составлять 2 недели вместо 2-х месяцев. Это не значит, что через две недели разработчик уже пилит фичи на 100% эффективности, но он может участвовать в обсуждениях по проекту и не теряться на них.

Архитектура и технологии

Когда у нас на 90% готово описание системы, мы формируем верхнеуровневую архитектуру и подбираем технологии, на которых будем создавать продукт.

Если у клиента есть своя техническая команда, то координируемся с ней. Смотрим на технологии, внутренние и внешние системы для интеграций, согласовываем технологии и подходы.

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

Читайте также:

Как заложить архитектуру цифрового продукта: 6 практических принципов

Андрей Степанов, Техдиректор, партнёр

Приоритезация задач и выделение первой версии продукта

Ближе к концу проектирования продукта мы приоритезируем описанные фичи и выделяем первую версию продукта. Работаем вместе с заказчиком: предлагаем свое видение и принимаем критику.

Эффективный инструмент для визуализации пользовательских сценариев и приоритезации функциональности – User Story Mapping. Он помогает команде сосредоточиться на создании ценности для пользователя и бизнеса. 

Читайте также:

Как использовать User Story mapping при создании цифрового продукта

Вениамин Мустафин, Директор по развитию бизнеса

Оценка разработки и роадмап продукта

Финальный этап: декомпозируем задачи, уточняем оценку на разработку первой версии и формируем подробный план работ с разбивкой по функциональности. Далее прикидываем роадмап развития продукта после запуска. В него идут те фичи, которые не попали в первую версию. Все это согласовываем с заказчиком, собираем обратную связь и вносим коррективы в план, если надо.

А что потом?

После продуктового проектирования идет стандартный процесс разработки продукта: прототипирование и дизайн, разработка, тестирование и запуск. И здесь, конечно, стоит подумать о составе команды, которая реализует все задуманное. 

Читайте также:

Собираем команду для цифрового продукта: роли, подходы и практические советы

Вениамин Мустафин, Директор по развитию бизнеса

Продуктовое проектирование в нашей практике показало себя как довольно универсальный подход. Единственный, пожалуй, случай, когда оно не будет работать – тендерная разработка. Для таких проектов важно четкое соответствие положениям ГОСТа. 

Но не поймите неправильно – наш подход удовлетворяет требованиям ГОСТ 34 на разработку ТЗ, просто улучшает его и делает менее бюрократическим. То есть мы меняем форму и упрощаем восприятие, а не бездумно вырываем куски из привычной для многих документации. А еще сокращаем время на онбординг команды и быстрее стартуем все то, что идет после проектирования продукта. Получается win-win. 

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

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

В таком подходе есть недостаток: на выходе не всегда получается то, что хотел клиент. То есть функциональность он получил какую заявлял, но продукт не достигает поставленных бизнесовых целей. Все потому, что ТЗ отвечает на вопрос ЧТО, но не отвечает на вопрос ЗАЧЕМ. То есть у нас нет четкого понимания как наши действия, описанные в ТЗ, приведут к достижению целей клиента. И именно эту задачу решает Карта влияний.

Что такое Карта влияний

Карта влияний — это ментальная карта, которая определяет цели проекта и влияния, которые должны помочь достичь этих целей.

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

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

Читайте также:

Постановка целей в digital-разработке: как не провалить запуск цифрового продукта

Вениамин Мустафин, Директор по развитию бизнеса

Ценность для заказчика

Заполняя Карту влияний, заказчик оценивает создание продукта с уровня достижения результата. Он видит, какие действия предпримет команда разработки и как это должно повлиять на конечную цель. 

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

Ценность для команды разработки

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

Ценность для менеджеров

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

Как составить Карту влияний

Создавая Карту влияний, мы последовательно заполняем четыре блока: Зачем, Кто, Как, Что. Не забываем перед этим прояснить и утвердить понимание задачи.

Зачем

Фундамент карты. Заполняя этот блок, мы отвечаем на вопрос: «Зачем мы это делаем». Фактически, определяем цель, которую бизнес стремится достичь.

Например, у нас есть клиент — банк, на сайте которого можно получить кредит онлайн. В месяц выдается 500 таких кредитов. Клиент хочет больше.

Мы собираемся с нашим клиентом, уточняем и фиксируем цель — увеличить количество выдаваемых кредитов с сайта в 2 раза через 6 месяцев после запуска. Это и есть наше ЗАЧЕМ.

В этом блоке обязательно нужно формулировать цель по SMART:

• цель — увеличить количество выдаваемых кредитов через сайт банка;
• объект измерения — количество выдаваемых кредитов через сайт банка в месяц;
• где считаем — отчеты отдела кредитования банка;
• сейчас — 500 кредитов;
• цель — 1 000 кредитов.

Кто

Действующие лица. Те роли, которые могут оказать влияние на достижение цели. Чтобы их определить, достаточно ответить на вопросы: на чье поведение мы хотим повлиять; кто может помочь в достижении цели; кто может помешать.

Можно указывать конкретных людей, отделы, сегменты целевой аудитории, организации и т.д.

Роли можно условно поделить на три вида:

1. Первичные действующие лица. Это конечные пользователи. Именно для удовлетворения их потребностей создается продукт.
2. Вторичные действующие лица, которые предоставляют услуги.
3. Закулисные действующие лица, которые могут повлиять на решения по продукту: основные ЛПР, регулирующие органы и т.д.

С нашим клиентом-банком мы определили, что действующими лицами будут:

• Клиенты банка, которым нужен кредит.
• Сотрудники отдела кредитования банка.

Как

Это примеры влияний. На этом уровне мы соотносим действующих лиц с бизнес-целью. Отвечаем на вопросы: как действующее лицо может помочь нам достигнуть цели; как должно измениться поведение действующих лиц.

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

Клиенты, в свою очередь, должны отправлять формы без ошибочных данных. И вообще, хорошо, если они это будут делать быстро.

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

Что

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

Чтобы посетители сайта подавали кредит через сайт, а не в офисах банка, мы можем упростить им заполнение анкеты. Например, автоматически заполнять некоторые поля информацией из Госуслуг. А еще проработаем логику анкеты и постараемся ее сократить.   

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

По этой же схеме формулируем другие гипотезы этого блока.

Не вдавайтесь в подробности реализации задач из блока ЧТО. На этом этапе нам важно выдвинуть гипотезы и обозначить влияния. Уточнять реализацию будем на следующих шагах разработки.

Если клиент пришел с готовым списком функциональных требований, мы должны сверить эти требования с нашей картой влияний — убедиться, что все они оказывают влияния на достижение цели из блока ЗАЧЕМ. Если оказывают, смело добавляем их в ЧТО. Если нет — обсуждаем, а нужно ли нам вообще это делать. 

После заполнения всех блоков стоит еще раз пройтись по карте и оценить, насколько ЧТО влияет на ЗАЧЕМ, и не записали ли мы что‑то лишнее.

После составления карты

Обычно после создания Карты влияний вы получаете огромную схему с гипотезами и верхнеуровневыми задачами. Перед тем, как брать задачи из блока ЧТО в проработку, полезно приоритезировать гипотезы и оценить — достаточно ли в первой версии продукта сделать самые приоритетные задачи, чтобы достичь поставленной цели? Если ответ «Да», то можно фиксировать границы первой версии этими задачами. Если «Нет» — добавляем менее приоритетные задачи в первую версию, пока не получим утвердительный ответ.

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

На практике одним из следующих этапов проектирования продукта после составления Карты влияний становится USM. К этому инструменту мы обращаемся, когда нужно переходить от глобальных целей к конкретным пользовательским историям. User Story Mapping помогает связать фичи с поведением пользователей. Мы рассказываtv, как правильно применять этот инструмент в отдельной статье.

Минусы и подводные камни

1. Карта влияний построена на гипотезах. Она не гарантирует достижения цели, даже если вы реализуете все влияния. 
2. Есть соблазн добавить в блок ЧТО функциональность, которая не будет напрямую влиять на конечную цель. Это лечится ответом на вопрос: как то, что мы записали, будет влиять на достижение цели.
3. Когда разработка уже идет полным ходом, можно забывать сверяться с Картой влияний. Мы после каждой итерации разработки стараемся синхронизировать наше текущее состояние проекта с картой.

Почему продуктовая разработка — это не про сайты?

Разработка сайтов или лендосов — понятный процесс с заранее предсказуемым результатом. Есть макет, структура страниц, минимальная степень неопределенности. Продукты — другое дело: более долгое и изменчивое. Здесь на каждом этапе может возникать новое «а что если?», которое меняет задачи и подходы. Например, что важнее: доработать интерфейс или срочно выпустить новую фичу?