​​#мирвокруг #митап #бизнесанализ #системныйанализ

Встреча Аналитиков

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

https://moscoa-events.timepad.ru/event/1021224/

#митап #мирвокруг #системныйанализ #бизнесанализ

Ещё раз напоминаю, что сегодня аналитики Москвы собираются пообщаться на тему фокапов, которые возникают в работе аналитика. Ссылка на регистрацию и адрес антикафе в посте выше. Я буду!

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

#митап #системныйанализ #бизнесанализ

Спасибо, что мои подписчики мне напоминают о регулярных митапах Аналитиков Москвы.
Приглашаю вас сегодня присоединиться к беседе. Вот ссылка на встречу: https://moscoa-events.timepad.ru/event/1048769/
Я сегодня буду)))

#реклама #системныйанализ #бизнесанализ #митап

Немного порекламирую группу "Аналитики Москвы". Каждые 2 недели, мы проводим встречи по обмену опытом. Если у вас есть темы и что-то наболело, то у вас есть шанс высказаться)))

Темы и планы обсуждаем вот тут @moscoa
Следующая встреча на следующей неделе в четверг 12.09.2019
Welcome!)

#митап #бизнесанализ #системныйанализ #реклама

Сегодня очередная встреча "Аналитиков Москвы". Приходите! Встречи проходят каждые 2 недели по четвергам и они открытые. Темы и расписание можно узнать в канале @moscow_analyst

Темы на сегодня:
1. Конфликты
2. Облако знаний аналитика или план обучения начинающего.

Начало в 19:00, адрес:
м. Чистые пруды, Архангельский переулок, 7
Time club "Убежище"

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

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

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

Так и со словарем, если ты аналитик, то ты такая «заноза», что копаешь и роешь дальше вглубь. И это нормально, это работа аналитика. При этом если говорить о подходе DDD (Domain Driven Design) проектирования программного обеспечения, который призван увеличить качество продукта на выходе, то там применяются шаблоны и в основе лежит общий единый язык команды.

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

Что могу добавить от себя:
1. Не бойтесь быть глупыми и переспрашивать всех о терминах. Это нормально и слова имеют несколько значений. Если я скажу вам «ручка» и усмехнусь, то вы вообразите что-то своё, дверная ручка, шариковая ручка, перьевая, или человеческая (почему-то подумала о даме с собачкой))).
2. Фиксируйте термины и обновляйте их. Любой язык живой, вы сами это можете видеть на примере русского языка. Такое количество новых слов за последние 5 лет прилетели к нам из разных областей, что бывает очень сложно понять человека.
3. Пишите проще, короче, легче. Тут у меня несколько рекомендаций. Говорите больше, читайте книги и читайте вслух, то что вы пишите. Часто бывает так, что ко мне приходит аналитик, отдаёт ТЗ, я его сажаю рядом и начинаю читать фразу. Он сам морщится, улыбается и уходит исправлять. Просто люди ленятся и не перечитывают, то что пишут.
4. Язык даёт возможность быстрого вхождения в предметную область новым сотрудникам или тем, кто долго отсутствовал.
5. Объясняйте термины коллегам, чтобы у всех была единая картина в голове.

Если дальше идти по DDD, то единый язык взаимосвязан с контекстом. Тут нужно понимать, что команда может заниматься какой-то только частью предметной области, или же вовсе придумать свой язык и в контексте проекта это отлично работает, но за границами имеет другой смысл. Снова скажу про рану, которая зажила, но есть. Я встречала команды, которые говорили мне, ну у нас постановка это use case, а бизнес говорил у нас user story или что-то типа. И те и другие были неправы, было нечто между и неформализованное. А мне это жутко резало слух. Вцелом можно назвать требование, постановка задачи на разработку, таск, эпик, стори, да как угодно, в каждом контексте своё, но ниточка общего прослеживается, что-то несформулированное, что команда получает на разработку. И тут только настойчивость аналитика может очертить это нечто, объяснениями и терминами, и постоянными исправлениями команды можно приучить к общему языку. Процесс непростой, долгий, но игра стоит свеч.

​​#мысливслух #бизнесанализ

Про внедрение изменений в БП компаний

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

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

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

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

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

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

Всё это очень схоже с типами покупателей новых продуктов, когда есть новаторы (2,5% кто сразу покупает продукт), последователи (13,5% кто купил сразу же, как только кто-то уже купил), раннее большинство (34% покупателей) и позднее большинство (34% покупателей), консерваторы (те кто покупает товар позже всех 16%).

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

#мирвокруг #аналитик #материалы #бизнесанализ #системныйанализ #рекомендую #теория

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

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

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

Я нашла ссылку выступления Ольги и решила с вами поделиться.

https://analystdays.ru/ru/talk/58370

#капитаночевидность #аналитик #системныйанализ #бизнесанализ
#инструменты #userstory #usecase

Вернёмся к #теория
Избитая всеми тема, какой подход лучше выбрать в фиксирование требований User Story или Use Cases.

Мало того, что многие не различают эти понятия, так ещё и не думают, а что лучше? Такое впечатление, что User Story это некая мода, поэтому не поддается анализу и логике их применение.

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

В России постоянно всё из крайности в крайность. Но водку пьём, то торты едим. Точнее, то ТЗ на 100 страниц по ГОСТу канцелярским языком пишем, то на полстраницы User Story. Ни то, ни другое не даёт картины проекта. А ещё есть и противники UML. Я наоборот топлю за проектирование и описание функционала, как многослойного "торта" по диаграммам разного уровня детализации. Чтобы всегда можно было вернуться на тот уровень, который необходим.

"У нас нет времени" - вот что я постоянно слышу. Живя в Москве всю жизнь, могу сказать, что его никогда нет и оно есть всегда))) Опять же имхо, есть вещи без которых проект не сдвинуть, ну либо херак-херак и в продакшн. Тогда уже и о развитии сложно говорить и об системном анализе. Какие выводы делать по user story?

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

Именно отсюда я знала о User Story 2.0, как раз когда появляется прослойка Use Cases и на них мапятся User Story. Вот так применяешь и то и другое и даже не знаешь, что это уже 2.0)))) Все когда-нибудь приходят к такой схеме работы с требованиями.

https://analystdays.ru/ru/talk/71737

Коллеги, спасибо за вопросы и внимание к моему докладу на CodeFest 2022! Как будет видео запись выложу тут всю информацию. Презентацию попросили. Выкладываю.

#пирамидаартефактом #бизнесанализ #системныйанализ #шаблоныартефактов

#мысливслух #рассуждения #usecases #мойопыт #менторство #замечено #выводы #системныйанализ

Почему аналитики плохо пишут use cases?

Очень часто на курсах по интеграции в ШСА, да и не только, на менторстве тоже, и на собеседованиях встречается общая проблема по use cases. Аналитики плохо пишут сценарии вариантов использования.

👉1.Во первых, есть аналитики, кто не делает различий между use cases и user story. Вместо того, чтобы спрашивать аналитиков различие между Soap и Rest, на собеседование, лучше спросить различие между use cases и user story.
👉2.Во вторых, сценарии, как техника, используются на разных уровнях абстракции и не только аналитиками, но и тестировщиками, проектировщиками интерфейсов, продактами, да всеми)) Удобно.
👉3.Действительно, на системном или на уровне проектирования взаимодействия систем, мало кто из аналитиков грамотно может описать use cases. Это уже уровень архитектора, проектировщика, разработчика. Но он часто необходим на проектах, особенно если речь едет об интеграции.
👉4.Часто идёт ещё и смешение понятий функция и сценарий использования. Хотя use case вполне можно считать спецификацией функции.
👉5.Ну и плюс очень часто мы стараемся оперировать каноничным подходом, который был у Коберна (по крайней мере я всех к нему отправляю). И ещё пытаемся смаппить use cases и user story, я об этом писала, аж в 2020 году, что есть такое понятие как use cases 2.0 - https://t.me/start_in_IT/257

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

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

Выводы у меня следующие:
✅1.Высокоуровневые, на уровне бизнеса и взаимодействия пользователь - система, аналитики вполне отлично справляются.
✅2.Если аналитик не имеет базы, фундамента, плохо пишет алгоритмы, блок-схемы, то и сценарии также идут плохо. Везде в основе теория графов, сети Петри.
✅3.Сюда же я отнесу абстрактное мышление, это прям бич. Переключаться с одного уровня на другой самая большая проблема. Сложно понять где мы находимся, и где наши границы и рамки описания сценариев.
✅4.Сценарии на уровне взаимодействия модулей, систем требует знаний словаря данных, модели данных, что кому передаёт, как, в каком формате, по каким протоколам, синхронно, асинхронно, или файлами, или голубиной почтой.
✅5.Плюс сценарий не панацея и часто его нужно дополнять описанием алгоритмов, функций, а это математика. И я опять возвращаюсь к базовым, фундаментальным знаниям.
✅6.И ещё сюда добавлю обзор архитектурных решений. Потому что нужно хотя бы на пальцах понимать, как выстроено решение, к которому мы пишем уже на системном уровне требования, а точнее проектируем на языке требований, функций, что объединяет в себе целый комплекс знаний.

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

Проект не нужен заказчику.

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

Уже года 4, я провожу оценку аналитиков в виде игры по сбору требований. Игра у меня родилась из большого количества собеседований, доклада Ольги Азимбаевой (можно почитать и посмотреть тут https://t.me/start_in_IT/233 ) и моего опыта.
Я имитирую типичного заказчика, погружаю аналитика в его обычную среду "сбора требований и общения с заказчиком". Цель выявить основные Паттерны поведения аналитика, посмотреть какие вопросы он задаёт заказчику, как собирает требования, какие требования, на что обращает внимание, насколько идёт за заказчиком и тем решением, которое ему приносит заказчик.

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

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

Очень сложный вопрос. У меня нет однозначного ответа. Тут скорее, как в личной жизни, когда ты видишь, что в отношениях идёт обман, и один паразитирует за счёт другого. Что делать? Часто говорить бесполезно. Да и кто ты такой, чтобы это говорить? Этот опыт нужно получить.

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

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

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

Вспомнила ещё книгу "Русская модель управления" ( https://t.me/start_in_IT/176 ), когда я вижу какие-то очень странные, по-моему мнению движения, реализации, я начинаю спрашивать "почему так?" Вспоминаю книгу и отвечаю, аааа вот почему.

В такой ситуации, кто-то переживает, а кто-то просто рутинно работает и не обращает внимание на вопрос "зачем всё это нужно?" Я просто делаю своё дело. Нет тут правильных ответов. Главное вернуть себе управление собой, своими целями и сделать вывод для себя, даже если он будет звучать как "я просто зарабатываю тут деньги и стараюсь не включаться глубоко в происходящее". И это тоже нормально.

Всегда есть выбор, даже если кажется, что его нет)

Презентация моего выступления #uicdev2024 #бизнесанализ #доклад #анализ