В команде есть системный аналитик. Что разработчики ожидают от него получить?
Артём, фронтенд-разработчик, 5 лет опыта, финтех: Как бы банально ни звучало, задача должна быть понятно описана. Я жду, что аналитик ко всем сходит, всё узнает, согласует, уточнит и принесет мне полноценно подготовленную задачу. То есть проведет качественный дискавери ресерч. Не подумай, я не считаю, что мне принесут всё на блюдечке с голубой каемочкой. Я не предполагаю, что в задаче будет описано, как ее решать, реализация — это моя прерогатива. Но мне нужна четкая формулировка того, что ожидается в результате, и, поверь, это один из самых важных моментов.
В идеале требования в задаче должны быть описаны так, чтобы минимизировать уточняющие вопросы. Само собой, всё должно быть понятно, никаких двусмысленностей и расширенных толкований. А еще надо предусмотреть максимально возможное количество корнер-кейсов. Я говорю «в идеале», потому что в моей практике был такой опыт с аналитиком, когда суть задачи приходилось практически вытаскивать тисками, задавать очень много вопросов: как именно это должно работать? А что будет, если обновить страницу? А если пройти по хлебным крошкам и вернуться? Как ведет себя элемент при наведении курсора? Поиск осуществляется на лету или по кнопке поиска? А еще важно, чтобы аналитик говорил со мной на одном языке.
Что это значит?
Артём: Мне как фронтендеру недостаточно получить описание порядка и логики работы элементов на странице. Важно не придумывать своих слов и называть все элементы в соответствии с четким неймингом, без двусмысленности. То есть селект — это select, раскрывающийся список, а не выпадающий список (dropdown) и не аккордеон. Select — это стандартный HTML-элемент для выбора. Dropdown — более общий UI-паттерн, который может быть реализован по-разному (и не всегда на <select>). А вот аккордеон — это уже совсем другой элемент, он скрывает и раскрывает блоки текста, поэтому путаница здесь критична.
Что имеет в виду аналитик, когда пишет «Поле для ввода комментария»? Для ввода данных используются основные элементы: input или textarea, ни какая не «вводилка». Чем чреваты неточности в формулировках? Разработчик делает input на одну строку, а бизнес имел в виду полноценное текстовое поле на несколько абзацев. В итоге пользователи жалуются, что «комментарий обрезается».
На самом деле у меня много таких примеров.
Классика жанра: в задаче написано «Пользователь может выбрать варианты доставки», а нужно было «только один». В итоге на проде выбираются сразу две взаимоисключающие опции (чекбоксы вместо нужных радиокнопок, к примеру «самовывоз» и «доставка курьером» одновременно), что полностью ломает бизнес-логику.
Вот еще вспомнил: аналитик написал, что «необходимо показывать всплывающее окно с подсказкой». В итоге мы сделали модальное окно, которое при появлении блокирует весь экран, а оказывается, бизнес-заказчик имел в виду маленький тултип при наведении на элемент.
Почему так может случаться? Аналитик не владеет терминологией UI (и путает названия элементов). В требованиях описываются только «что», без «как». Для первой части, «что», аналитику не нужно глубоко погружаться в дебри фронтенд-разработки, но как минимум стоит изучить наименования элементов. Я рекомендую открыть любой storybook или документацию популярного ui-kit (shadcn, ant design, MUI material ui), посмотреть словарик элементов верстки, например Доку.
Со второй частью — «как» — сложнее. Здесь потребуется погружение с технической точки зрения.
Ты же говорил, что не ждешь от аналитика описание того, как задача должна быть реализована.
Артём: Действительно, я не думаю, что в задаче будут прописаны все JS-функции или пошагово, какие методы вызывать. Это моя зона ответственности. Но должно быть понятно, как решение будет работать в итоге. Например, в задаче написано «в поиске должен появляться список элементов». Мы стали делать select с 10 000 элементов, всё жутко тормозило из-за того, что грузился сразу большой массив данных. А на бизнес-ревью выяснилось, что в поиске должен появляться «автокомплит с подсказкой», то есть нужна была дополнительная интеграция.
Возможно, в задачах на бэкенд со стороны аналитика достаточно описать логику работы сервиса, интеграционное взаимодействие, входные/выходные данные в эндпоинтах, маппинг данных.
Системный аналитик может приходить к вам советоваться или вы ожидаете полностью готовое согласованное ТЗ?
Артём: Конечно, мы же одна команда и делаем одно дело. Тут важно без фанатизма. Если аналитик пришел спросить — это не значит, что он плохо справляется. Просто иногда мы можем подсказать решение проще, чем то, что аналитик придумал сам. Часто уточнить у разработчика в моменте будет быстрее и дешевле, чем потом всё переделывать.
Опытный аналитик, как правило, справляется самостоятельно: умеет собрать требования, описать бизнес-логику, подготовить юзер-стори, критерии приемки, пользовательские сценарии, если мы про фронт говорим, порядок экранов, переходы, схемы, диаграммы все. Контракты для интеграций, формулировки ошибок.
Но есть моменты, где советоваться точно стоит:
- Технические ограничения фронта и бэка, например можно ли реализовать ретрай без изменения API.
- Интеграции с внешними системами и протоколы обмена данными.
- Производительность и архитектурные последствия — что кажется простым, но в реальности ляжет огромной нагрузкой на базу.
- Нефункциональные требования — их лучше обсуждать совместно с архитекторами.
- Безопасность, например как хранить токены или как лучше обрабатывать ошибки авторизации.
С бэкендерами, кстати, аналитики советуются чаще: там задачи технически сложнее, много подводных камней и скрытых ограничений. Иногда одна уточняющая встреча экономит недели работы.
Хороший аналитик умеет держать баланс: он сам закрывает бизнес-логику, но точно не должен стесняться задавать «глупые вопросы» разработчикам про технические нюансы. Аналитик ведь и нужен, чтобы их задавать, часто это помогает корнер-кейсы вскрывать до прода. Это своего рода показатель зрелости: чем раньше команда синхронизируется, тем меньше переделок.
Как ставит задачи и работает команда без системного аналитика
У вас есть в команде аналитик? Что думаешь про его роль?
Владимир, фулстек-разработчик, 7 лет опыта, стартап: Сейчас нет, его обязанности размазаны между членами команды, задачи от бизнеса приносит менеджер. Я работал раньше в команде с аналитиком, и мне есть с чем сравнить. Сейчас требования собирает менеджер. Точнее, просто записывает пожелания от бизнеса, приносит их нам, все уточняющие вопросы задаем через него или сами ходим и спрашиваем. Остальная функциональность распределена между разработчиками, тестировщиком. Документацию как таковую не ведем — записываем своими словами кратко, что и как работает по логике. Плюс в последнее время приноровились в readme.md файле в GitHub описывать — помогает держать контекст.
А задачи кто ставит? Приоритизирует?
Владимир: Менеджер нарезает задачи, обозначает дедлайны. Приоритеты в целом сами определяем, что и когда делать, главное — успеть в срок сдать, приемку тестировщик делает.
Большой минус того, что задачу ставят менеджеры: ее внезапно могут изменить, когда мы уже начали работу. Прям посреди спринта. Иногда одна строчка в описании таски полностью меняет весь код, перечеркивает всё. А я уже оценил задачу, посчитал эстимейт, заложил архитектуру.
Была обычная задача: сделать экран авторизации. Всё вроде описали: поля ввода, типы ошибок, тексты для фронта, коды ошибок замапили. Отдаем на ревью, и тут всплывает сюрприз: после ввода пароля нужно ввести код из СМС. Оказывается, менеджер был уверен, что код «сам подставляется», ведь современные смартфоны подтягивают его автоматически. На самом деле да, подтягивают, но только если фронт реализовал специальный сценарий. В итоге менеджеры и разработчики друг друга недопоняли, пришлось всё переделывать: убирать лишний шаг, чинить логику и объяснять, что автоподстановка работает не «магией», а руками разработчика. Пока уточняли требования, доделывали — сдвигали сроки.
Это всё потому, что нет системных аналитиков? Без них никак?
Владимир: Ну не то чтобы совсем никак. Задачи аналитика между командой распределены, мы адаптировались, процессы выстроили. Просто без него всё происходит медленнее, задачи растягивают, а это напрямую влияет на time to market, метрики, то есть на прибыль. Время — деньги.
Вот был пример. Бизнес попросил сделать «фичу на удержание» пользователей после отписки — добавить колесо со скидкой. Менеджер идет к дизайнеру, договаривается о макете. Без аналитика сразу появляется несколько проблем:
- Нет процесса, как идея превращается в задачу.
- Нет документации, которая фиксирует, что именно согласовано.
- Нет истории решений — завтра никто не вспомнит, почему выбрали именно этот вариант.
И что в итоге? Как это обычно бывает: разработчик Вася берет и «пилит сервис». Все уверены, что он всё понял правильно. Документация? Она у Васи в голове. А Вася где? А он полгода назад уволился. Новый разработчик открывает код и понятия не имеет, почему логика именно такая.
Вывод такой: отсутствие аналитика = отсутствие процессов = высокий bus factor. То, что кажется понятным без уточнений, через месяц превращается в вопрос «А почему мы сделали именно так?».
Артём: Работать с аналитиком и без — две большие разницы. У нас как-то раз аналитик заболел, почти месяц не было его, было очень сложно, процессы почти встали.
И вместо заключения
Плохая аналитика делает из задачи баг, хорошая — фичу. А очень хорошая помогает избежать лишних созвонов 🙂
