Как пройти стажировку бизнес- и системного аналитика и не «сгореть» в персональной преисподней

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

На тот момент у меня был бэкграунд разработчика (бэк) и даже давнишний (более 5 лет назад) опыт IT‑аналитика, также я проходила курсы по JavaScript. Это и плюсы, и минусы одновременно, но об этом по ходу статьи.

В чём была проблема на стажировке

Начинали мы тяжело как писал Гегель. Стажировка была в команде начинающих с нуля (совсем с нуля). Если честно, я думала, что в команде часть функций будут выполнять уже работающие в компании люди. Но это моя вина, что я не уточнила условия. Это не повлияло бы на моё решение стажироваться, но были бы другие литры кофе ожидания.

Если вы переучиваетесь на стажировке с другой IT‑профессии, а вокруг вас — новички, учтите, что вам предстоит:

• отвечать на очевидные, на ваш взгляд, вопросы;

• обучать инструментам и пояснять процессы;

• не обращать внимания на ошибки (они очень бросаются в глаза);

• нивелировать свой баттхерд по поводу того, что кто‑то что‑то не понимает.

На первой работе много лет назад я сама спрашивала у разработчика «Что такое API?» (Саша, привет). Тогда IT не было мейнстримом и брали всех подряд без особого опыта. Вспоминаешь себя «табулой расой» — становится легче.

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

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

«Подводные камни» стажировки

Тут можно было бы подумать: «на стажировке можно глубоко не нырять». А глубоко и не надо — «собрать камни» можно сразу на первых неделях.

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

С чем вы столкнётесь на стажировке

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

На что не обращать внимания:

• на своё желание сделать «всё и сразу»: всё равно будет не всё и не сразу;

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

• на невозможность получить информацию полную, непротиворечивую, максимально компактную, применимую.

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

Так делать-то что нужно было?

Нужно было реализовать условный таск‑трекер (менеджер задач).

Состав команды:

• аналитик, выполняющий функции бизнес- и системного;

• продакт‑оунер;

• скрам‑мастер;

• проджект менеджер;

• 4 фронтендщика (бэкендщиков не было),

• 3 тестировщика (1 решил уйти).

Что было: макеты десктопной версии веб‑приложения (сайт), макеты планшетной и мобильной версий, документация к API в Swagger (она врала!).

Разрабатывать требовалось только фронтенд (ReactJS), а готовое API и макеты в Figma предоставлялись. В этом тоже есть и плюс, и минус. Плюс: когда заказчик (или играющий роль заказчика) не может в ближайшее время рассказать о предполагаемом бизнесе, рабочих потоках, пользователях в системе, то хорошо иметь макеты, из которых можно понять что нужно. Минус: макеты могут не соответствовать бизнес‑логике или реальным требованиям. Так оно и было, что путало команду.

Какие проблемы могут быть с макетами интерфейса в Figma:

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

• На макете детали, которые оказались не убраны (дублирующие фильтры поиска, неактуальные кнопки создания задачи).

• На макетах противоречащие детали (в десктопной версии правильно, в мобильной — нет, и наоборот).

• На макетах «гуляют» стили: одна и та же кнопка может иметь разный фон, границу и прочее.

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

• Если не иметь большого опыта с Figma, а тебе не рассказывают детали, то можно не заметить, что у проекта есть несколько страниц:D

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

Попросить сразу доступ к API я не догадалась, получила через 2 недели, когда уже стали активно работать разработчики. Поэтому работала, основываясь только на макетах, а они, как уже было сказано, не во всём соответствовали. Тем не менее процентов на 80% можно было составить письменный «портрет» приложения.

Что делать аналитику перед первой итерацией

Разработка в стиле Agile часто предполагает использование разных уровней требований. Я пользуюсь User story и Use Cases, иногда выделяю и Epics.

Уровни требований к ПО «на коте»

User story («пользовательские истории») — требование к программному обеспечению в одном‑двух предложениях. Пишется в примерном формате: «Как <роль> я хочу <цель/желание>, чтобы принести <выгоду>». Я всегда начинаю с них и ещё ни разу не пожалела. Иногда этого достаточно, но обычно User story делиться на несколько Use cases.

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

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

Пример очень краткий: в качестве акторов выступают владелец кота, кот, система. Кот: мяукает. Система: 1. Инициирует старт процесса. 2. Анализирует звук. 3. Переводит с кошачьего языка на человеческий. 4. Записывает текст. 5. Синтезирует из текста человеческую речь. 6. Воспроизводит речь. 7. Владелец: слушает речь.

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

Пример: «Распознавание кошачьего языка».

Вам могут говорить, что на первом этапе достаточно «верхнеуровневых» требований, то есть, начинать нужно с эпиков. Дело в том, что вы их, скорее всего, в адекватном виде не получите. «Подняться» от деталей к общим блокам — как раз умение аналитика, я считаю. По моему, это и есть навык «видеть систему». Если у заказчика (или того, кто выполняет его роль) нет аналога старого ПО, опыта проектирования, то он, как правило, самостоятельно разделить на блоки будущую систему не может. Кто‑то начинает с эпиков, но мне было неудобно.

Организация работы

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

Аналитик должен на первом этапе:

1. Познакомиться с командой менеджмента.

2. Познакомиться с командой разработки

3. Познакомиться с командой тестирования

4. Провести цикл встреч с менеджментом, подождать, пока менеджмент вникнет в суть вопроса и можно будет составить перечень доработок.

5. Изучить все макеты, понять назначение всех компонентов.

6. Проверить описание API на соответствие макету.

7. Написать введение к документации: что за проект, заказчики, глоссарий.

8. Выделить Epics, выделить User Story, выделить Use Cases для тех User story, которые будут взяты в первую итерацию.

9. Т. к. это стажировка, то изучить соответствующую литературу и источники (отдельная тема).

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

Прежде чем писать эпики

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

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

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

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

Что делать: не делать работу оунера, если он есть на проекте. Но я за то, чтобы обсуждать, а первый этап много времени проводить с продакт-оунером. Аналитик и продакт-оунер в целом на проекте неразлучны как Глеб Жеглов и Володя Шарапов. В отсутствии продакт-оунера аналитик часто его заменяет, проводя ежедневные скрам‑митинги с командой и распределяя задачи. Наоборот обычно процесс работает только отчасти: продакт не всегда может заменить аналитика, так как работа аналитика слишком объёмна, а нужно ещё управлять командой. Хотя продакт продакту рознь, некоторые мои находили ненароком и ошибки в коде.

C чего начать работу аналитика

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

Разделы документа аналитика (примерно):

1. Бизнес‑проблема.

2. Как решить проблему.

3. Характеристика и классы пользователей.

4. Общий взгляд на продукт.

5. Ограничения дизайна и реализации.

Пресловутое «какую бизнес‑проблему решаем» аналитика преследует даже ночью. Это верно даже в том случае, если уже есть макет и API. Даже где‑то уже реализовано работающее старое приложение, нужно понять, зачем оно вообще, всё ли в нём актуально.

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

Какие возможны ответы?

Для управления задачами существует готовое ПО, но оно имеет ряд минусов:

• Для платных: нужно платить каждый месяц за подписку, много лишних функций.

• Бесплатные слишком упрощённые, не имеют нужных функций.

• Есть сомнения насчёт безопасности данных.

• Хочется иметь инструмент под свои процессы, а не подстраивать процессы под готовый продукт.

• Хочется иметь возможность дорабатывать новые возможности.

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

Что делать аналитику, если получил только макет

Если перед вами только макет и API без документации, с макета и начните. Несмотря на тенденцию к mobile‑first, изучать лучше макет десктопной версии приложения, если она есть. Она бывает более полной.

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

Итак, при входе в приложение, скорее всего, будет какая‑то рабочая область с какими‑то списками (вряд ли это форма создания нового экземпляра). Скорее всего, дизайнер отобразил максимум, что может быть в этой области. Поэтому ваша задача понять, какой там будет минимум. Что сделать необходимо и достаточно. Для начала нужно делать минимально жизнеспособный продукт (MVP). Где слово жизнеспособный, пожалуй, ключевое. Ещё одна причина не погружаться сразу в сложную логику: вы не знаете уровень команды.

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

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

Например:

• Меню: Notifications, List, Board, Automate.

• Блок: To Do.

• Блок: In Progress.

• Блок: Done.

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

Как создать новую сущность, которая попадает в этот список:

1. Выписать меню.

2. Выписать названия блоков.

3. Выписать краткое содержимое блоков.

4. Найти списки.

5. Посмотреть пагинацию (постраничное отображение), кол‑во элементов на странице, сортировку (например, по дате обновления), фильтры (например, «являюсь автором»), настраиваются ли колонки для отображения (какая‑нибудь кнопка «дополнительно» со списком того, что можно отобразить), можно ли редактировать атрибуты сущности прямо из списка.

6. Понять, где создаётся сущность, из которой состоит список, есть ли кнопка создания, макет для создания/редактирования.

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

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

9. Что, на первый взгляд, могут делать другие пользователи с сущностью (есть ли отличия в ролях).

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

11. Есть ли поиск, что находится в поиске.

12. Есть ли профиль пользователя, настройки.

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

Делайте сначала то, что может сделать именно суперпользователь. Это «всемогущий» пользователь без какой‑либо роли, со всеми правами, оставьте роли и права, иначе есть риск не успеть.

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

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

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

Нарисуйте диаграммы вариантов использования (use‑case diagram), они простые, но вам будет понятно, кто и что может сделать в системе. Некоторые их считают не очень информативными — имеют на это право. Я рисую часто от руки, фотографию и сохраняю в электронный блокнот. Ими можно поделиться неформально с командой, но диаграммы для документации, чтобы согласовывать с заказчиками, я рисую в приложениях.

Уровни требований к ПО

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

Initiatives (Инициативы)

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

Epics (Эпики)

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

User story (Пользовательские истории)

Пользовательские истории: предполагается, что реализуются в течение 1-й итерации (нет). Повторим формат: «Как <роль> я хочу <цель/желание>, чтобы принести <выгоду>». Например: «Я, как автор задачи, хочу видеть подписчиков на задачу, чтобы понимать, кто оповещается.»

Use cases (Варианты использования)

Варианты использования: описывают действия пользователя и реакцию на это системы. Если бы был не фронтенд, могло бы быть взаимодействие система‑система, а не только пользователь‑система. Минусы: работа за тестировщиков 🙂, если хорошо расписаны все альтернативные потоки, исключения и т. п. Им тогда гораздо меньше работы остаётся. Я писала в формате таблицы: пользователь делает некоторое действие, а система на это отвечает некоторыми действиями. Бывало, что действия запускались самой системой (отправка запроса с периодичностью). Пример: «Пользователь инициирует создание чек‑листа. Система даёт возможность сохранить чек‑лист с названием или отменить создание».

Работа с документацией API

Хорошо, если есть Swagger, можно ознакомиться с документацией к API. Тут перечисляются эндпойнты: методы, которые нужно «дёрнуть» на бэкенде, чтобы получить данные. Что нужно искать: где получить токен, чтобы посылать запросы.

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

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

Нужно сравнить данные на макете и данные, которые присылает бэк. Следует поставить в известность продакт‑оунера,если данные не соответствуют, то сделать это не можем.

Почти наверняка в бэке найдётся другая информация, которую можно отобразить, но её нет на макете. Задаём вопросы через продакт‑оунера заказчику, что требуется, предлагаем варианты. Неправильно: «В JSON-файле 30 записей, что взять»? Правильно: «Бэкенд позволяет нам отобразить ещё 30 атрибутов в задаче, можно было бы добавить информацию, кто на неё подписан, чтобы постановщик задач понимал, получает ли участник задачи уведомления или нет».

Кому и что «должен фронтенд»

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

Допустим в UI не должно быть кнопок, если нет прав на работу с задачами, бэкенд должен это проверять и запрещать доступ, и не «надеется на UI». Это означает, что даже если по ошибке доступ к кнопке получен, то при её нажатии задачу пользователь без прав не изменит. Если стоит задача реализовать роли пользователей, а на бэке их нет, то возможно сделать проверку нужных условий и «на фронтé», если на стажировке не приходится надеется на доработку бэкенда. Да, это не очень правильно, но это показало, что мы понимаем важность ролей и прав.

Что можно упустить

Можно упустить, зачем всё это: какая у приложения цель, как им пользуются, с чего начинают и в какую точку приходят. Как можно стартовать процесс? Куда деваются сущности после завершения процесса?

Например: у задачи должны быть статусы: «В очереди», «Активная», «Готово», «Не принята». Считаем, что можно завести новую задачу и она окажется в очереди. На макете было 2 кнопки «Создать»: в области «В очереди» и «Активная», поэтому мы с менеджментом сначала не знали об ошибках на макете. В результате решили оставить две кнопки «Создать», а для области «Активная» придумали, что в ней создает «Постановщик», который сразу становится «Исполнителем». (Впрочем, это потом «не даст» сделать нам бэкенд: выдавал ошибку.)

Как аналитик рисуем workflow, рабочий поток: в общем случае задача из «В очереди» попадает в «Активная», потом в «Готово» или в «Не принята». Или сначала в «Готово». Тут зависело ещё от наличия других действий: нужно ли с задачей «что‑то делать по дороге». Макет красноречиво намекал: «Нужно!» А именно: на одном из примеров у задачи появлялся атрибут «Отзыв» с неким комментарием.

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

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

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

Что нужно выписать: чем закрыть форму, можно ли менять размеры, появляются ли полосы прокрутки, если модальное окно — можно ли закрыть кликом вне области. Определить минимальные атрибуты вам поможет API: в нашем случае для создания задачи нужно было название и Id статуса.

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

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

В нашем случае минимально жизнеспособный продукт (MVP) для запуска мог включать:

• название задачи;

• статус задачи;

• постановщика задачи.

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

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

Если вы находитесь на стажировке, нужно понимать, что у вас всего 3 месяца (или другой ограниченный срок), в конце которого нужно презентовать командный результат. Это значит, что «двигаться итерационно», как в реальной работе, будет проблематично. У коллег может быть сессия, смена приоритетов, а кто‑то уже во время стажировки готов устроиться на другую работу.

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

А если делать не только MVP?

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

В этом помогут модели в Swagger и эндпоинты. Например, если «Важность» для задачи — это чек‑бокс, то в БД будет писаться одни из двух значений: true/false. Если «Важность» — это какие‑то значение из списка (варианты: «Сегодня!», «Не горит»), то нужно идти искать специальный запрос, который возвращает список возможных значений.

Будьте аккуратны с датами: как правило, они пишутся в формате UTC в БД, а отображаться должно локальное время пользователя.

Для каждого атрибута нужно понять параметры (что‑то зависит от бэкенда):

• название;

• тип;

• обязательность;

• мин. и макс. значение (зависит от типа);

• мин. и макс. количество атрибутов, если их несколько;

• значение: список, логическое (true/false) и т. д.

Пример приведён ниже.

Атрибут: Приоритет задачи

• Название: Приоритет задачи.

• Тип: Перечисление (enum) или строка.

• Обязательность: Обязательный (каждая задача должна иметь приоритет).

• Мин. и макс. значение:

  • Тип перечисления: значения могут быть ограничены фиксированным набором (например, «Низкий», «Средний», «Высокий»), то есть мин. значение = 1 («Низкий»), макс. значение = 3 («Высокий»).

  • Тип строка: если используется строковый тип, то минимальная длина строки = 1 символ (например, «Н»), максимальная длина может быть 10 символов.

• Мин. и макс. количество атрибутов: 1 (если это одиночный атрибут, то количество = 1).

• Значение: Строковое перечисление, например, [«Низкий», «Средний», «Высокий»] или булев тип (true/false), если приоритет ограничен только двумя уровнями, например, «важно»/»не важно»

В требованиях нужно написать, что происходит с атрибутом:

• Атрибут виден сразу при открытии или добавляется потом.

• Как добавить атрибут.

• Как удалить атрибут.

• Как отобразить обязательность заполнения.

Система уведомлений

Система с пользователями должна «говорить»: если происходит действие в фоне, которое нужно прокомментировать — нужно показать уведомление. Например, пользователь может нажать на архивирование задачи и по окончании процесса нужно показать уведомление: «Архивирована задача%название задачи%».

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

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

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

Спиннеры, лоадеры, индикаторы загрузки, «скелетоны»

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

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

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

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

Может, что-то ещё нужно сразу?

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

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

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

Как «пилить», если до старта итерации сущий пустяк, а информация не собрана?

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

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

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

Грабли для аналитика: не наступаем

Пожалуй, можно выделить четыре вещи, на которые нужно обратить внимание.

Проблема 1. Коллеги не знают, что такое итерационный подход. Могут ждать глубины и ширины проработки требований сразу к 1-й итерации. Ваша задача (не только ваша, впрочем) объяснить, что при итерационном подходе аналитик тоже двигается поэтапно. Требования ко второй итерации могут измениться.

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

Что я бы сейчас делала по‑другому? Тогда был макет и я сама смотрела в JSON-файл, то консультации разработчиков не требовались по реализации. Но в работе нужна более «стабильная» обратная связь для выработки реализации.

Проблема 3. Ещё пример: считается что требования должны излагаться как «пользователь инициирует прикрепление файла», поскольку аналитик описывает поведение пользователя, а не детали реализации — это уже задача разработчиков. А на практике в скобках всё равно добавляла про реализацию («нажимает на такую‑то кнопку»). Я тоже думаю, что это не совсем правильно, но повышало скорость понимания стажёрами. В реальной работе без готового UI и бэкенда буду писать «инициирует», а система «даёт возможность сохранить». Так как ограничивать в реализации разработчиков не стоит.

Проблема 4. С чем были ещё сложности? С понимаем описания командой некоторых вещей, которые в коде должны быть решены проверкой условий. Если у вас несколько шагов, даже с минимальным количеством кнопок, опишите их отдельно, даже если что‑то повторяется. Это кажется нехудожественно, но стиль изложения требований аналитиком немного в этом похоже на код.

Можно несколько раз подряд повторять «если <...>, если <...>, если <...>», одни и те же слова, если это делает описание чётким и понятным. Требования далеки от художественного текста. Скорее, это такой часто «псевдокод», где есть место тавтологии, очевидностям и другим особенностям, которых мы не можем простить в художественных текстах. Всё это ради того, чтобы достичь главной цели: донести однозначные, полные, непротиворечивые требования. Потому что, если есть место, которое может быть понято неправильно, его поймут неправильно.

Что поменять аналитику перед стажировкой

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

• Не бойтесь учить: от этого знаний не становится меньше, а больше, да и делать совместную работу гораздо легче.

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

• Не бойтесь быть «графоманом»: подробные описания вариантов использования (Use Cases) спасет нервы тестировщикам и сделает вашу работу понятнее для команды.

• Не беритесь за «все и сразу»: на стажировке важнее показать, что вы умеете работать в команде и правильно расставлять приоритеты, чем «сделать всё идеально», но в одиночку.

• Не бойтесь «конфликтовать» с продакт‑оунером: не стесняйтесь высказывать свое мнение, «поднимайте» его уровень знаний, «поднимайтесь» и до его уровня знаний.

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

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

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

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

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

Запомнилась ли вам ваша стажировка так, как запомнилась мне моя?