Flow🤯

Завершилась конференция для бизнес и системных аналитиков Flow 2023🤘
Гибридный формат: 4-5 сентября онлайн, 11-12 офлайн. Офлайн параллельно работали 3 зала, и если одновременно шли интересные 2-3 доклада, то можно не париться, все записи доступны в личном кабинете.

Разные направления докладов по аналитике: UX, Documentation, Business processes, Integrations (1 доклад, 1 воркшоп. Вот это несерьезно😤), Team&Career, Architecture, Data&ML, Tools, General и Requirements

Больше всего мне понравился доклад Юрия Куприянова, директора школы системного анализа и проектирования Systems.Education 🥰
Он поднял вопрос "Где граница требований и проектных решений?".
Дело в том, что аналитик искажает "хотелки" заказчиков проектным решением и доносит по большей части "свои" требования до разработки, таким образом отдаляет разработчиков от бизнес-ценности.
Кажется, что банальная мысль, я тоже не могу не проектировать, когда пишу требования.
Идеальное решение «убить» аналитиков, чтобы избавиться от плохих проектных решений.
А куда нам аналитикам деваться? Становиться координаторами (проджектами/продактами) или начинать писать код. В разработке идеально быть универсальным бойцом, который сам собирает требования, проектирует и пишет код.

Еще Юрий поделился ресурсами:
▪️По UX проектированию тонкая книга и курс, конечно же с его школы
▪️По проектированию БД и анализу данных собрание материалов в вики
▪️По интеграциям собрание материалов в вики

В самое сердце на поражение были доклады по архитектуре:
▫️Про C4 model. Архитектор из Тинька доступно показал, как рисовать каждый тип диаграмм C4: контекста, контейнеров, компонентов, кода. И порекомендовал лучшие инструменты для "начертательной геометрии" IcePanel и Structurizr
▫️Про ArhiMate. Эту нотацию упоминали практически в каждом докладе этого направления. Чем полезен ArhiMate аналитику можно почитать по ссылке
▫️Независимый российско-австралийский исследователь доказал, что все фреймворки корпоративной архитектуры (TOGAF, Zachman и т.д.) не работают, а являются маркетинговым ходом консалтинговых компаний.
▫️Эксперт из Сбера рассказал о новом подходе документирования требований и описания проектных решений через YAML в DocHub.

Остальные доклады мне не зашли. Либо непонятна проблема, либо просто и очевидно, либо Data&ML.

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

📣Топ 5 книг для аналитиков

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

1. Вигерс Карл, Битти Джой. Разработка требований к программному обеспечению - библия аналитиков по введению документации и оформлению требований. Про типы требований, про разработку сценариев, примеры оформления требований в гибкой разработке и водопадной модели, про управление изменениями требований и даже про тестирование требований.

2. BABOK Руководство к своду знаний по бизнес-анализу - формат словаря по бизнес-анализу. Хорошо и кратко описаны общие понятия, компетенции аналитиков и методики сбора требований. Целых 50 техник по сбору и анализу бизнес-процессов. Интервью - это самая распространенная и полезная техника, но достаточно сложная. В книге за 2 странички написали, как эффективно подготовиться и провести интервью.

3. Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя - обучающая книга языку UML. Аналитик общается не только с бизнесом, но и с разработкой. Книга предназначена для всех ИТ специалистов, чтобы проектировать на одном языке, описывать архитектуру приложения, интеграции и функциональность системы. Для аналитика важно уметь читать и рисовать 5 типов UML диаграмм: use case, state, sequence, activity, class.

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

4. Роберт Фитцпатрик. Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут? - я уже сказала, что интервью очень важно. Надо уметь правильно задавать вопросы и вытягивать "боли" заказчика/пользователей. В этой тонкой книге описаны кейсы правильных и неправильных вопросов на интервью.

5. Джефф Паттон Пользовательские истории. Искусство гибкой разработки ПО - это книга про User Story Mapping. Методология помогает систематизировать, декомпозировать функциональность. Аналитик может описать всю функциональность системы через User Story, сложить их в карту, затем согласовывать и приоритизировать функционал с бизнесом и с разработкой через эту карту.

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

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

Конфликты аналитика и проджекта/продакта

Вторая тема из опроса, которая оказалась интересной. Наверное, из-за слова «конфликты»😃

Предыстория: тема появилась не потому что у меня богатый опыт взаимодействия в проджектами/продактами, а потому что в одном из аналитических каналов проводили опрос «Бывают ли у вас конфликты с PM?»

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

Что им делить?🤔

1. Границы
Нужно четкое зонирование работ аналитика и управленца. Например, одна из обязанностей аналитиков: помогать разработчику понять бизнес-ценность продукта и обсуждать идеи реализации. Чем не задачи проджекта/продакта?
Выполнение одних и тех же работ = сталкивание лбами и создание конкуренции.. Конфликт

2. Экспертный авторитет
Наше поколение в целом про отсутствие авторитетов. Наше уважение нужно завоевать. И чтобы аналитик «подчинился»..
Проджекту/продакту нужно брать ответственность за проект, за принятые решения, за аналитиков, признавать ошибки, быстро адаптироваться, обладать стратегическим виденьем и богатым профессиональным опытом.

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

3. Лидерство как soft skills
Как говорил один из моих руководителей «Hard skills аналитика это soft skills» и «70% работы аналитика это коммуникации». Аналитики это софтовые ребята.
А могут ли быть у менеджера проекта/продукта навыки коммуникаций хуже? Если хуже, то это конфликт. Потому что аналитик будет действовать в обход управленца, который не может договориться. Будет сам взаимодействовать со стейкхолдерами, планировать работы с командой и в конечном счете станет «неформальным» руководителем проекта/продукта.

💡Красивое решение: сделать одного человека проджектом/продактом и главным аналитиком. Аналитики ходят под проджектом согласно классической структуре и значит проджект это ведущий аналитик с навыками управления проектом и разработкой.

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

в продолжении поста выше.. я подготовила свое виденье эволюции аналитиков👨‍💻

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

Сегодня день системного аналитика👏

Аналитики, с праздником!
Желаю интересных развивающих задач, адекватных стейкхолдеров, софтовых разработчиков и высокой зарплаты🥂