#капитаночевидность #аналитик #системныйанализ #бизнесанализ
#инструменты #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

#custdev #мысливслух #инструменты #аналитик #productmanager

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

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

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

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

Мне на самом деле очень жаль, что про кастдев как про инструмент аналитика не говорят. Либо говорят с позиции, а так ли это? Действительно ли аналитику нужен кастдев? Хотя по сути искусство правильно задавать вопросы, очень нужно, чтобы заказчик:
👉1. Дошел до своей проблемы сам
👉2. Дошёл до решения этой проблемы также сам.

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

Другие мои заметки про Customer Development можно почитать по #custdev

#фактичность #коучинг #капитаночевидность #мысливслух #инструменты #softskills #мойопыт #мышление

Про фактичность
Я немного снова про коучинг, тренерство, преподавание, менторство, ужас как много модных слов))) Но в основе многого лежит фактичность.

В моей жизни очень много интерпретаций, моих, семьи, друзей, ну и т.д. И это всё примешано с эмоциями.

В какой-то момент я просто говорю, так всё, хватит эмоций!! Давай говорить фактами.
И эти факты могут быть следующие:
✅Образование
✅Опыт работы
✅Сделанные пооекты
✅Изученные инструменты
✅Полученные деньги
✅Отзывы клиентов
✅Реально сделанные вещи

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

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

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

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

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

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

Но я и до обучения коучинга использовала фактичность в менторских сессиях и преподавание)))

#мысливслух #рассуждения #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, собирает целый комплекс знаний.