Всем привет👋

Сейчас я активно готовлюсь к выступлению на конференции SimbirVolga 🤘, которая пройдет уже на этой неделе.

Я выбрала формат сторитейлинга на тему "Как мы командой учились читать требования к фиче".

В текущей команде я работаю больше двух лет, и мы совместно преодолевали и преодолеваем проблему: "Лень читать требования. Очень много букАв..".
Если разработчики и тестировщики не проводят ревью требований, не понимают суть проблемы и идею реализации новой фичи, то продукт/проект обречен на баги, некорректно работающий функционал и выгорание членов команды.

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

Лечу в Ульяновск с пересадкой в Москве, в общем около 8 часов.
Бесит😠
Ем, сплю и читаю книгу для руководителей, вышедших из программистов, «Как пасти котов». Я, конечно, не из программистов, но полезного написано много про управление разработкой.

Программисты оказывается такие котики🦁

Закончилась конференция SimbirVolga🥰

Итоги:
🌸Выступила впервые за долгое время. На удаленке скилл публичного выступления теряется. Голосок вначале дрожал. Но в целом я получила много положительной обратной связи, мне даже посоветовали заявиться с этим докладом на профессиональные аналитические конференции. Очень приятно😚
🌸Новые знакомства и обмен опытом. Например, один из участников конференции рассказал, что у них в компании есть кружек по игре в го (и это не язык программирования). Го - восточная интеллектуальная игра, которая развивает стратегическое и логическое мышление, что айтишникам необходимо для плодотворной работы.
Как интересный факт: ни один игрок в го не болел Альцгеймером. В общем, заинтересовал он своей страстью к этой игре и я даже подписалась на его канал, посвященный этой теме.
🌸Было очень весело. Танцы, песни, шутки до утра. Вначале конференции все такие важные, очень деловые, покерфейсы в пиджаках. А что в итоге?! Зеленый змей сближает..

А уже на следующей неделе 2 сентября ИТ-пикник Тинькофф, бесплатная туса в московском парке..

#обзор_на_тусу

Аналитики и дизайнеры🅱️🔠🔠

Аналитик и дизайнер - это команда, которая формирует требования к интерфейсу в веб-разработке или в мобильном приложении.
Тут взаимодействие между аналитиком и дизайнером зависит от того у кого больше скиллов в UX.

💬UX (User Experience) - удобство пользования интерфейсом.

Если дизайнер с мощной UX-экспертизой, а зачастую так и бывает, то аналитику достаточно изложить проблемы/боли пользователя, чтобы дизайнер отрисовал прототип интерфейса "как надо".
Если аналитик с мощной UX-экспертизой, то (дизайнер ему не нужен🤣) он сам может нарисовать полноценные мокапы или нарисовать вайфреймы и передать дизайнеру для отрисовки прототипа.

💬Вайфрейм - черновой набросок распределения элементов на экране.
💬Мокап - оформленный дизайн конкретной страницы.

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

💬CustDev (Customer Development) - тестирование идеи или прототипа будущего продукта на потенциальных пользователях с помощью интервью.

Лично у меня всегда проблема при проектировании интерфейса, сложно придумать понятные тексты ошибок или придумать побудительное описание кнопки. Интерфейсные тексты - это тоже UX. Год назад я прочитала книгу "Этой кнопке нужен текст. O UX-писательстве коротко и понятно", прикрепила книгу к посту.
Книжку то я прочитала, но все равно продолжаю надеется, что текст продумает дизайнер😁

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

#саморазвитие

Как навести порядок в требованиях?

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

Но я знаю как можно стараться поддерживать порядок в требованиях☝️:

1. Если сейчас у вас на проекте много документации и она частично актуальная или неполная, то не пытайтесь спасти ее. Это аналог попытки вычерпывать воду из дырявой лодки. А если проект с нуля, то сразу переходи к п.2))
2. Внедрите шаблон для описания требований к фиче.
Например, код фичи, описание проблемы и решения, BPMN, макеты, User Story + Use Case.. дальше опциально
3. 1 фича = 1 статья/документ.
Если фича меняется или дополняется, то актуализируйте имеющуюся статью/документ, а не создавайте новый.
4. Структурируйте репозиторий для хранения статей/доков. Сделайте структуру по разделами или модулям приложения для быстрой навигации по требованиям.

А теперь самое сложное🫣

5. Устраняйте технический долг по п.1 в рамках доработок. Т.е. если нужно внести правки в имеющийся функционал, а требования по нему неактуальные или "плохие", то напиши полноценную статью по текущей работе фичи + доработки по шаблону из п.2. Таким образом, мы выливаем воду из лодки, в которой уже нет дырок.
6. Если по фиче одна статья/документ согласно п.3, то как отследить изменения требований?
Нужна система контроля версий. Ноу хау инструмент для отслеживания изменений требований - GitLab😁, который все чаще начинает использоваться для ведения документации. Ну и в Яндекс.Вики, Confluence... тоже есть поддержка этого функционала.

Самое сложное в введении документации все вышеописанное применять😉
Если знаете варианты получше, то делитесь в комментах 👏

#саморазвитие

В ожидании концерта на ИТ-пикнике от Тинькофф🤘
Жду жду жду.. главного айтишника Антоху МС🥰