#мысливслух #рассуждения #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, собирает целый комплекс знаний.
Почему аналитики плохо пишут 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, собирает целый комплекс знаний.
Telegram
Записки ИТ специалиста
#капитаночевидность #аналитик #системныйанализ #бизнесанализ
#инструменты #userstory #usecase
Вернёмся к #теория
Избитая всеми тема, какой подход лучше выбрать в фиксирование требований User Story или Use Cases.
Мало того, что многие не различают эти…
#инструменты #userstory #usecase
Вернёмся к #теория
Избитая всеми тема, какой подход лучше выбрать в фиксирование требований User Story или Use Cases.
Мало того, что многие не различают эти…
#системныйанализ #usecases #выводы #мойопыт #моемнение #замечено
Цель в use cases
Тема про use cases и системный уровень их написания оказалась животрепешущей. И на эту тему ко мне пришли ещё подписчики, чему я очень рада)))
Итак, давайте ещё соберём информацию.
Евгений Галактионов https://t.me/systemspodhod
правильно описал, то что проблема часто заключается в понимание цели. А зачем вообще use case и что он делает?
Это очень видно, когда на пользовательском уровне мы получаем набор use cases по crud.
Пользователь создаёт заявку, редактирует, читает, удаляет (или переводит в архив).
Но вот я диспетчер автобазы с автомониторингом, я вообще не мыслю такими понятиям! На кой ляд мне эти функции?
Бизнес пользователь думает о том, что ему Васю с Петей нужно отправить на линию да ещё так, чтобы они не слили бензин, доехали до места и сделали ремонт оборудования. То есть наш диспетчер Маша, хочет сформировать бригаду для выполнения запросы от жителей дома. И описать в ней ограничения, быстро согласовать и после проконтролировать выполнение.
Почувствовали разницу?
CRUD это прекрасно, спасает в любых обстоятельствах, но цели с точки зрения бизнеса, регламентов, должностных инструкций понятнее, важнее, что в свою очередь собирает функции в большие цепочки.
Уже классика жанра, когда разные команды делают разные функции, кнопочки, блоки на front-end, а работать с этим невозможно, потому что нет связи и пользовательских сценариев.
Но и на уровне межсистемного, межмодульного взаимодействия также часто никто не может рассказать, зачем одна система делает вычисления, кеширует данные и передаёт в другую? Кто-то был художником и так видел реализацию чего-то, для того чтобы ЧТО выполнить и получить?
А потом мы и получаем истории, про то, что мы не знаем кто этим пользуется, сейчас отключим и будем ждать, кто будет орать))))
Цель в use cases
Тема про use cases и системный уровень их написания оказалась животрепешущей. И на эту тему ко мне пришли ещё подписчики, чему я очень рада)))
Итак, давайте ещё соберём информацию.
Евгений Галактионов https://t.me/systemspodhod
правильно описал, то что проблема часто заключается в понимание цели. А зачем вообще use case и что он делает?
Это очень видно, когда на пользовательском уровне мы получаем набор use cases по crud.
Пользователь создаёт заявку, редактирует, читает, удаляет (или переводит в архив).
Но вот я диспетчер автобазы с автомониторингом, я вообще не мыслю такими понятиям! На кой ляд мне эти функции?
Бизнес пользователь думает о том, что ему Васю с Петей нужно отправить на линию да ещё так, чтобы они не слили бензин, доехали до места и сделали ремонт оборудования. То есть наш диспетчер Маша, хочет сформировать бригаду для выполнения запросы от жителей дома. И описать в ней ограничения, быстро согласовать и после проконтролировать выполнение.
Почувствовали разницу?
CRUD это прекрасно, спасает в любых обстоятельствах, но цели с точки зрения бизнеса, регламентов, должностных инструкций понятнее, важнее, что в свою очередь собирает функции в большие цепочки.
Уже классика жанра, когда разные команды делают разные функции, кнопочки, блоки на front-end, а работать с этим невозможно, потому что нет связи и пользовательских сценариев.
Но и на уровне межсистемного, межмодульного взаимодействия также часто никто не может рассказать, зачем одна система делает вычисления, кеширует данные и передаёт в другую? Кто-то был художником и так видел реализацию чего-то, для того чтобы ЧТО выполнить и получить?
А потом мы и получаем истории, про то, что мы не знаем кто этим пользуется, сейчас отключим и будем ждать, кто будет орать))))
Telegram
Системный подход
Канал про все, что связано с системным мышлением, теорией систем, прикладным системным анализом и применением в разных областях жизни, включая ИТ.
#мысливслух #пробренд #историиизжизни #замечено
Хотела начать с высказывания, что в СССР не было брендов, но потом поняла, что они были, но я всё таки опишу свои мысли.
ЦУМ и ГУМ до сих пор можно назвать брендом. Или часы, машины, определённых заводов.
Я как ребёнок СССР, потом 90-х, помню момент, когда в Москву навалили бренды и какая очередь была в макдональдс на Пушкинской. Помню как мама сказала, зачем они там стоят, ну еда и еда. И мне кажется это у меня от мамы, ну бренд и бренд.
И знаете я тут смотрела на фотографию одного европейского аэропорта и поймала, как раз себя на мысли, того, что мне неинтересно, когда везде, всё одинаково. Конечно понимаю, что в этом есть смысл. Но хочется самобытности, а не глобализации.
И вот смотрю я на фото, а там на втором этаже старбакс, внизу KFC, сбоку реклама, и я такая фу.
Вот потом вспомнила своё детское чувство, бренд???
Приходишь ты в универмаг, а там хлеб и хлеб, он из соседнего хлебзавода, по ГОСТу, молоко, сметана, яйца. Сметану набирают тебе в твою банку, яйца кладёшь в сеточку. Блин и никто не парился)) и не думали про эпидемию. И я так отчётливо помню, как тетинька продавщица набирала сметану в банку, для меня это было представление, у неё был огромный половник.
Да, потом уже дефецит, ад и очереди за товаром в 90-х. Ну и я тоже стояла в очереди, пока мама бегала по другим.
Но бренд? В том понимание, что сейчас был или нет?
И я люблю те города, где есть самобытность. Ты выходишь в центр города, а там товары этого города и страны, а не бренды, которые есть во всём мире. И вот тогда мой отдел мозга, отвечающий за интерес говорит даааа! Оно!
А когда всё по одному шаблону... Ну так себе... Да и вцелом я не особо падкая на бренды, хотя люблю всё очень добротное, функциональное, фундаментальное, чтобы надолго. Я готова платить за качество, и часто бренд должен быть равно качеству. Но по факту оно не так.
Папа мой в силу своего возраста до сих пор не понимает, почему молоко одного бренда дороже другого, а если это фермерские товары, то ему совсем непонятна цена. Ну молоко, и молоко. И папа так и продолжает брать самое дешёвое, а потом негодует почему качество плохое и кот не ест колбасу)))
Хотела начать с высказывания, что в СССР не было брендов, но потом поняла, что они были, но я всё таки опишу свои мысли.
ЦУМ и ГУМ до сих пор можно назвать брендом. Или часы, машины, определённых заводов.
Я как ребёнок СССР, потом 90-х, помню момент, когда в Москву навалили бренды и какая очередь была в макдональдс на Пушкинской. Помню как мама сказала, зачем они там стоят, ну еда и еда. И мне кажется это у меня от мамы, ну бренд и бренд.
И знаете я тут смотрела на фотографию одного европейского аэропорта и поймала, как раз себя на мысли, того, что мне неинтересно, когда везде, всё одинаково. Конечно понимаю, что в этом есть смысл. Но хочется самобытности, а не глобализации.
И вот смотрю я на фото, а там на втором этаже старбакс, внизу KFC, сбоку реклама, и я такая фу.
Вот потом вспомнила своё детское чувство, бренд???
Приходишь ты в универмаг, а там хлеб и хлеб, он из соседнего хлебзавода, по ГОСТу, молоко, сметана, яйца. Сметану набирают тебе в твою банку, яйца кладёшь в сеточку. Блин и никто не парился)) и не думали про эпидемию. И я так отчётливо помню, как тетинька продавщица набирала сметану в банку, для меня это было представление, у неё был огромный половник.
Да, потом уже дефецит, ад и очереди за товаром в 90-х. Ну и я тоже стояла в очереди, пока мама бегала по другим.
Но бренд? В том понимание, что сейчас был или нет?
И я люблю те города, где есть самобытность. Ты выходишь в центр города, а там товары этого города и страны, а не бренды, которые есть во всём мире. И вот тогда мой отдел мозга, отвечающий за интерес говорит даааа! Оно!
А когда всё по одному шаблону... Ну так себе... Да и вцелом я не особо падкая на бренды, хотя люблю всё очень добротное, функциональное, фундаментальное, чтобы надолго. Я готова платить за качество, и часто бренд должен быть равно качеству. Но по факту оно не так.
Папа мой в силу своего возраста до сих пор не понимает, почему молоко одного бренда дороже другого, а если это фермерские товары, то ему совсем непонятна цена. Ну молоко, и молоко. И папа так и продолжает брать самое дешёвое, а потом негодует почему качество плохое и кот не ест колбасу)))
Зрелость команды
У меня есть прекрасные друзья, которые работают в театрах. И я им благодарна за то, что они привили мне любовь к театру.
Один из моих любимых театров это РАМТ в Москве.
Художественный руководитель театра Алексей Бородин. Список его регалий настолько большой, что даже не буду пробовать их перечислять.
Если вы посмотрите на репертуар театра, то увидите очень разные спектакли, где тот или иной сложный для общества вопрос рассказывается простыми словами.
Есть спектакли, которые Алексей вынашивал годами даже десятилетиями. И как-то в одном интервью он сказал, что настало время, когда трупа театра доросла и готова для спектакля.
Эта мысль мне понравилась. Если послушать тренеров разных спортивных команд, они тоже могут сказать, или даже предсказать, что вот эта команда мировые лидеры или будут через пару лет.
К чему это я всё? А к тому, что командообразование в любом деле очень важная часть становления. И может быть так, что команда просто не готова к тем задачам, которые стоят перед ней.Другой вопрос, что команду никто не спрашивает. И мне иногда странно, что менеджеры или тим лиды это не видят, или не задаются этим вопросом.
У нас никто не говорит о том, что вот у меня 4 года до олимпиады и мне нужно собрать команду чемпионов. Или я хочу поставить сложный спектакль и мне нужны такие актёры, кто сможет показать, то что я хочу.
И действительно, годами, даже десятилетиями к этому идут.
А у нас к сожалению, когда такие лидеры появляются, показывают крутые результаты за несколько лет, и потом исчезают, или их съедает политика. Я считаю, что это отдельное искусство лидера, видеть, а на что способна команда, как наработать, тот опыт, знания, компетенции, чтобы поставить на сцене, что-то действительно серьёзное.
Чуда не бывает, бывает путь, опыт и вложенные средства, силы в желаемый результат. Одно время именно команды с лидером стали ценны, дримтим. Если я не права, то расскажите о своём опыте, но на моём опыте, мало кто смотрит именно на то, чтобы сохранить команду. Важнее бизнес цель от менеджера, который хочет показать результат руководству, а кто и как это будет делать...
#мысливслух #командообразование #зрелость #мирвокруг #замечено
У меня есть прекрасные друзья, которые работают в театрах. И я им благодарна за то, что они привили мне любовь к театру.
Один из моих любимых театров это РАМТ в Москве.
Художественный руководитель театра Алексей Бородин. Список его регалий настолько большой, что даже не буду пробовать их перечислять.
Если вы посмотрите на репертуар театра, то увидите очень разные спектакли, где тот или иной сложный для общества вопрос рассказывается простыми словами.
Есть спектакли, которые Алексей вынашивал годами даже десятилетиями. И как-то в одном интервью он сказал, что настало время, когда трупа театра доросла и готова для спектакля.
Эта мысль мне понравилась. Если послушать тренеров разных спортивных команд, они тоже могут сказать, или даже предсказать, что вот эта команда мировые лидеры или будут через пару лет.
К чему это я всё? А к тому, что командообразование в любом деле очень важная часть становления. И может быть так, что команда просто не готова к тем задачам, которые стоят перед ней.
У нас никто не говорит о том, что вот у меня 4 года до олимпиады и мне нужно собрать команду чемпионов. Или я хочу поставить сложный спектакль и мне нужны такие актёры, кто сможет показать, то что я хочу.
И действительно, годами, даже десятилетиями к этому идут.
А у нас к сожалению, когда такие лидеры появляются, показывают крутые результаты за несколько лет, и потом исчезают, или их съедает политика. Я считаю, что это отдельное искусство лидера, видеть, а на что способна команда, как наработать, тот опыт, знания, компетенции, чтобы поставить на сцене, что-то действительно серьёзное.
Чуда не бывает, бывает путь, опыт и вложенные средства, силы в желаемый результат. Одно время именно команды с лидером стали ценны, дримтим. Если я не права, то расскажите о своём опыте, но на моём опыте, мало кто смотрит именно на то, чтобы сохранить команду. Важнее бизнес цель от менеджера, который хочет показать результат руководству, а кто и как это будет делать...
#мысливслух #командообразование #зрелость #мирвокруг #замечено