Решение в бизнес-анализе VS в системном анализе
Очень часто я писала, про то, что системный аналитик формирует и формулирует требования и не стоит обсуждать с заказчиком решения. В ТЗ описывается решение на языке требований.
Но при этом мы упускаем из виду решение в бизнес-анализе, которое не равно решению в системном анализе. И тут картина совсем другая, наоборот с бизнес заказчиком мы обсуждаем бизнес решение, чтобы как можно раньше выявить ограничения, риски и понять возможность реализации бизнес решения, оценить по концепции бюджет сроки проекта.
Часто аналитики, да и вцелом айтишники мыслят только решениями в ИТ системах, в коде, но бизнес решение может быть не завязано на автоматизацию.
Например, у нас кофейня, и наш бариста проводит оплату мимо кассы. Что мы можем сделать?
Можем написать "вам не дали чек, сообщите нам, и получите кофе за наш счёт", можно поставить камеру, как элемент контроля. Или сделать оплату только безналичную. Может ещё какие-то варианты...
То есть бизнес решение - это набор процедур, которые описывают как мы будем реорганизовывать деятельность.
В результате бизнес анализа, мы принимаем решение, что из текущей деятельности:
👉оставляем,
👉от чего возможно откажемся,
👉что делегируем,
👉что поручим роботам (тут как раз может быть ИТ-решение).
Бизнес аналитик - анализирует как выстроена деятельность, между кем и кем она разделена, как выстроены отношения между участниками деятельности, и нужны ли нам технические инструменты (ИТ решения), и под какие функции.
Возвращаясь в кофейню. Бизнес решение нашей проблемы может завершиться просто вывеской, что мы вернём деньги, а техническое решение, это сбор информации обо всех стаканчиках, сбор статистики и анализ, может анализ видео с камер, например с помощью ИИ, возможно это перебор и дорого и не нужно. Вопрос объёма, а если бы берём в расчёт огромную сеть фастфуда, то уже сложное и дорогое ИТ-решение может себя окупить.
#бизнесрешение #бизнесанализ
Очень часто я писала, про то, что системный аналитик формирует и формулирует требования и не стоит обсуждать с заказчиком решения. В ТЗ описывается решение на языке требований.
Но при этом мы упускаем из виду решение в бизнес-анализе, которое не равно решению в системном анализе. И тут картина совсем другая, наоборот с бизнес заказчиком мы обсуждаем бизнес решение, чтобы как можно раньше выявить ограничения, риски и понять возможность реализации бизнес решения, оценить по концепции бюджет сроки проекта.
Часто аналитики, да и вцелом айтишники мыслят только решениями в ИТ системах, в коде, но бизнес решение может быть не завязано на автоматизацию.
Например, у нас кофейня, и наш бариста проводит оплату мимо кассы. Что мы можем сделать?
Можем написать "вам не дали чек, сообщите нам, и получите кофе за наш счёт", можно поставить камеру, как элемент контроля. Или сделать оплату только безналичную. Может ещё какие-то варианты...
То есть бизнес решение - это набор процедур, которые описывают как мы будем реорганизовывать деятельность.
В результате бизнес анализа, мы принимаем решение, что из текущей деятельности:
👉оставляем,
👉от чего возможно откажемся,
👉что делегируем,
👉что поручим роботам (тут как раз может быть ИТ-решение).
Бизнес аналитик - анализирует как выстроена деятельность, между кем и кем она разделена, как выстроены отношения между участниками деятельности, и нужны ли нам технические инструменты (ИТ решения), и под какие функции.
Возвращаясь в кофейню. Бизнес решение нашей проблемы может завершиться просто вывеской, что мы вернём деньги, а техническое решение, это сбор информации обо всех стаканчиках, сбор статистики и анализ, может анализ видео с камер, например с помощью ИИ, возможно это перебор и дорого и не нужно. Вопрос объёма, а если бы берём в расчёт огромную сеть фастфуда, то уже сложное и дорогое ИТ-решение может себя окупить.
#бизнесрешение #бизнесанализ
👍2
Forwarded from Сорока пишет | Об ИТ и менеджменте
ПЕРЕНОС!!!
Друзья! Либо у меня окривели руки, либо с выкаткой нового функционала VK Video сломали запуск трансляций. Ставлю на второе, ибо уже даже и по инструкции сделал – всё равно не работает.
А нет трансляции – нет эфира.
В общем, переносим наш с Наташей Косиновой сегодняшний эфир про житиё аналитическое тяжкое предположительно на четверг, 26 марта, 18:00. Предположительно, так как вдруг не Вконтактике и не РКН, а отрицательная прямота моих рук? Но к четвергу и её исправим, ежели что – не впервой.
На таймпаде дату/время тоже поправил, как заработает VK Video – ещё раз вышлю напоминалочку.
Сорри за инконвиниенс.
👉 Об ИТ и менеджменте. Подписываемся и пересылаем друзьям
Друзья! Либо у меня окривели руки, либо с выкаткой нового функционала VK Video сломали запуск трансляций. Ставлю на второе, ибо уже даже и по инструкции сделал – всё равно не работает.
А нет трансляции – нет эфира.
В общем, переносим наш с Наташей Косиновой сегодняшний эфир про житиё аналитическое тяжкое предположительно на четверг, 26 марта, 18:00. Предположительно, так как вдруг не Вконтактике и не РКН, а отрицательная прямота моих рук? Но к четвергу и её исправим, ежели что – не впервой.
На таймпаде дату/время тоже поправил, как заработает VK Video – ещё раз вышлю напоминалочку.
Сорри за инконвиниенс.
👉 Об ИТ и менеджменте. Подписываемся и пересылаем друзьям
👍3
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских аналитиков, был написан коллективный чек-лист "Интеграции". Попытка как раз хоть как-то себе облегчить жизнь)))
Когда-то я им уже делилась и снова предоставляю вашему вниманию.
--------------------------
1. Определить системы, участвующие в обмене
2. Описать потоки данных
3. Понять наличие гарантированной доставки данных
4. Описать регламент взаимодействия систем:
• передаваемые данные
• частота передачи
• расписание
• система-инициатор обмена
5. Описать формат передачи данных:
• Названия атрибутов
• Тип, длина
• Обязательность
• Кодировка
6. Зафиксировать маппинг данных из формата системы-источника в формат системы-приёмника.
7. Понять в какой системе хранятся мастер-данные по объектам.
8. Выявить необходимость преобразования/проверки на актуальность/обогащения данных.
9. Зафиксировать протоколы обмена данными.
10. Понять ограничения платформы/канала интеграции.
11. Нефункциональные требования:
• Выявить требования к скорости обработки и передачи данных.
• Понять необходимость шифрования данных.
• Оценить объем передаваемых данных.
• Понять наличие ограничений на уровне регулятора (152 ФЗ, PCI DSS).
12. Описать интеграционный сценарий взаимодействия.
13. Понять способ взаимодействия – синхронное/асинхронное.
14. Описать механизм обработки ошибок.
15. Выявить требования к настройкам, администрированию, мониторинг, логирование, квотирование.
--------------------------
Чек-листы это конечно хорошо, но они показывают нам линейный список скорее как "не забыть", а в большинстве случаев важен процесс проектирования, как технология. То есть понимание разветвленного алгоритма действий, потому что аналитик не действует последовательно, появляются вводные и приходится возвращаться к артефактам и переделывать.
В этот день год назад 23.03.2025 я писала, о том как нагородили интеграционный огород)
#интеграция #чеклист
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👍3🔥3
Вчера у нас в комментариях завязался интересный разговор про требования к качеству данных.
Зачем вообще нужно качество данных и как это относится к интеграции?
Интеграция, это прослойка, перекладчик, набор процедур можно сказать, чтобы создать единое информационное пространство для поддержания бизнес-процессов. И тут важно понимать, с кем и как мы интегрируемся. Это как ворота с охранником, у него есть правила и регламент и он их придерживается))
Я собирала #грехианалитика и один из них звучал, как - "положиться на других", "довериться партнерам по интеграции".
Я как-то встретилась с подобным мышлением аналитиков, когда внешняя система по отношению к нашему айти ландшафту рассматривается, как эталон, и рассуждения - вроде как они уже всё за нас продумали и мы просто берем готовое и завязываемся на их решение.
Вот мы интегрируемся с большим и страшным, например Газпромом, и там не дураки же работают, возьмем по объектам их идентификаторы и просто сохраним у себя. Да, мы сохраним у себя их информацию, но логику и целостность данных будем выстраивать сами у себя.
✅1. Во первых, не забываем принципы СОА архитектуры, что все сервисы независимы друг от друга, и смотрят друг на друга как на черный ящик. Микросервисы это ребёнок СОА архитектуры.
✅2. Нам нужна гибкость решения, масштабирования. Сегодня наш партнер по интеграции Газпром, а завтра нет. На практике у меня за год сторонний сервис сменился 3 раза! Нам нужна независимая логика работы нашей внутренней кухни, без завязок на внешнее.
✅3. Очень важная вещь, о которой многие не думают. Это юридическая составляющая работы с данными. К сожалению, многие аналитики и вцелом айтишники не очень сильны в юридических нюансах (я сама такая же), но не стоит забывать, что работая с данными мы можем быть ограничены законами, регламентами. И если какая-то произойдёт, простите, жопа, придут разбираться на низкий уровень решения. И тут очень глупо говорить о том, что нууууу мы же завязали решение на нашего соседа по парте. А сосед скажет, у меня то всё хорошо, а это уже ваша зона ответственности.
#интеграция #качестводанных
В этот день год назад 24.03.2025 рассказывала почему в режиме стартапа мы нагородили интеграционный огород, который фонит более 10 лет
24.03.2024 я писала про названия систем, и откуда они берутся)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍3🏆1
Как я проектирую интеграцию.
Расскажу именно свой процесс, он чаще всего не имеет чёткой последовательности, и как только прилетают новые вводные приходится возвращаться к артефактам, что-то менять, дополнять, создавать, но я опишу его по шагам (+ см. чек-лист):
✅1.Первое с чего я начинаю, я собираю всю информацию. Всё подряд. Скидываю всё вмесие. Собираю спецификации, если есть бизнес требования, бизнес процессы, архитектуру, окружение и изучаю. Не каждому подойдёт такой первый пункт, потому что с большим объёмом информации без структуры сложно. И можно упасть на дно. И тем более сложно выстроить свой вижен по разным уровням абстракции.
✅2.Дальше, я рисую диаграмму компонентов uml, фактически это третий уровень в C4. Мне важно понимать, кто какие интерфейсы предоставляет, а кто использует и какие технологии у нас есть, как мы передаём данные. Тоже до неё может быть ещё несколько других диаграмм и циклов изучения. Можно начинать с DFD, или первого уровня С4.
✅3.Изучаю API, если они есть, то замечательно. Я могу визуализировать API в виде диаграммы, я её называю "точки интеграции", пытаюсь понять сервисы API, кто за что отвечает. Подёргать, посмотреть, что в реальности есть, как работает.
✅4.Понимая процесс, сразу рисую sequence диаграмму. Не все могут сходу нарисовать sequence, это нормально. И можно брать дополнительные инструменты, которые шаг за шагом помогут сделать срез информации.
✅5.Описываю диаграмму статусов объектов, которые участвуют в информационном обмене. Опять же тут уже у голове должны быть процессы. И модель предметки, которую тоже можно нарисовать, если сложно сходу выделить объекты, по которым идёт информационный обмен.
✅6.Изучаю, как ошибки, описанные в API нужно обработать, как администрировать интеграцию.
✅7.Возвращаюсь к sequence и дорабатываю. На самом деле к sequence я могу возвращаться много раз)) это ключевой артефакт и в него я могу добавить моменты, связанные с работой с мастер-данными, с гарантированной доставкой, параметрами настройки интеграционного слоя. И конечно учитываю, как сценарий влияет на жизненный цикл объекта, какие статусы меняются и какие обновления, синхронизации данных необходимы. Как раз поддерживаю требуемое качество данных с помощью процессов в слое интеграции.
✅8.Перехожу к маппингу данных. Чаще всего я описываю, как заполнять поля сервиса из API, который мы например вызываем, по каким правилам происходит преобразование данных, где берем значения из настроек. Добавляю обязательно примеры реальных данных.
✅9.Если требуется, отдельно описываю алгоритм работы интеграционного модуля (если у нас шинная интеграция, например), в виде обычной активити диаграммы.
✅10.Перехожу к НФТ. Сюда относится безопасность, производительность, масштабирование, администрирование. Если есть числовые данные, указываю, если нет, пытаюсь посчитать и согласовать с разработкой.
✅11.Отдельно описываю логирование, мониторинг, квотирование. И могут быть различные специфичные требования от администратора, которому должна быть доступна возможность управлять всем этим богатством, и правильно реагировать на индиценты.
✅12.В дополнение всегда прикладываю спецификацию API, примеры реальных данных, явки и пароли тестовых стендов.
Очень кратко описала процесс, опуская детали.
Сегодня с 19:00 до 21:00 по Москве, на мастер-классе по интеграции мы пойдём по процессу проектирования интеграции, как по технологичному процессу.
❗Мероприятие платное, чтобы оставить заявку на участие, пишите мне в личку слово "Интеграция".
#системныйаналитик #интеграция #системныйанализ #мойопыт #выводы #анонс
Расскажу именно свой процесс, он чаще всего не имеет чёткой последовательности, и как только прилетают новые вводные приходится возвращаться к артефактам, что-то менять, дополнять, создавать, но я опишу его по шагам (+ см. чек-лист):
✅1.Первое с чего я начинаю, я собираю всю информацию. Всё подряд. Скидываю всё вмесие. Собираю спецификации, если есть бизнес требования, бизнес процессы, архитектуру, окружение и изучаю. Не каждому подойдёт такой первый пункт, потому что с большим объёмом информации без структуры сложно. И можно упасть на дно. И тем более сложно выстроить свой вижен по разным уровням абстракции.
✅2.Дальше, я рисую диаграмму компонентов uml, фактически это третий уровень в C4. Мне важно понимать, кто какие интерфейсы предоставляет, а кто использует и какие технологии у нас есть, как мы передаём данные. Тоже до неё может быть ещё несколько других диаграмм и циклов изучения. Можно начинать с DFD, или первого уровня С4.
✅3.Изучаю API, если они есть, то замечательно. Я могу визуализировать API в виде диаграммы, я её называю "точки интеграции", пытаюсь понять сервисы API, кто за что отвечает. Подёргать, посмотреть, что в реальности есть, как работает.
✅4.Понимая процесс, сразу рисую sequence диаграмму. Не все могут сходу нарисовать sequence, это нормально. И можно брать дополнительные инструменты, которые шаг за шагом помогут сделать срез информации.
✅5.Описываю диаграмму статусов объектов, которые участвуют в информационном обмене. Опять же тут уже у голове должны быть процессы. И модель предметки, которую тоже можно нарисовать, если сложно сходу выделить объекты, по которым идёт информационный обмен.
✅6.Изучаю, как ошибки, описанные в API нужно обработать, как администрировать интеграцию.
✅7.Возвращаюсь к sequence и дорабатываю. На самом деле к sequence я могу возвращаться много раз)) это ключевой артефакт и в него я могу добавить моменты, связанные с работой с мастер-данными, с гарантированной доставкой, параметрами настройки интеграционного слоя. И конечно учитываю, как сценарий влияет на жизненный цикл объекта, какие статусы меняются и какие обновления, синхронизации данных необходимы. Как раз поддерживаю требуемое качество данных с помощью процессов в слое интеграции.
✅8.Перехожу к маппингу данных. Чаще всего я описываю, как заполнять поля сервиса из API, который мы например вызываем, по каким правилам происходит преобразование данных, где берем значения из настроек. Добавляю обязательно примеры реальных данных.
✅9.Если требуется, отдельно описываю алгоритм работы интеграционного модуля (если у нас шинная интеграция, например), в виде обычной активити диаграммы.
✅10.Перехожу к НФТ. Сюда относится безопасность, производительность, масштабирование, администрирование. Если есть числовые данные, указываю, если нет, пытаюсь посчитать и согласовать с разработкой.
✅11.Отдельно описываю логирование, мониторинг, квотирование. И могут быть различные специфичные требования от администратора, которому должна быть доступна возможность управлять всем этим богатством, и правильно реагировать на индиценты.
✅12.В дополнение всегда прикладываю спецификацию API, примеры реальных данных, явки и пароли тестовых стендов.
Очень кратко описала процесс, опуская детали.
Сегодня с 19:00 до 21:00 по Москве, на мастер-классе по интеграции мы пойдём по процессу проектирования интеграции, как по технологичному процессу.
❗Мероприятие платное, чтобы оставить заявку на участие, пишите мне в личку слово "Интеграция".
#системныйаналитик #интеграция #системныйанализ #мойопыт #выводы #анонс
🔥7👍5
Эх... Очень хотелось красиво, по взрослому провести прямой эфир, но сервисы нас подводят 🙈
Forwarded from Сорока пишет | Об ИТ и менеджменте
Галя, у нас отмена перенос
Небольшая жизненная история вам про дефекты – должен же я как-то оправдаться, что эфир с Наташей Косиновой переносится.
Захожу я на прошлой неделе к себе на канал в VK Video, чтобы запланировать трансляцию для нашей с Наташей беседы, а там меня встречает большая плашка:
Как будто уже понятно, чем закончится, да? Ручное тестирование всего функционала по пользовательским сценариям нонеча ж не в моде: зачем, когдаразработчики иишница все unit-тестами обвешала?..
Короче, выныриваю обратно в нашу реальность после часов трёх экспериментов (бывших тестировщиков не бывает!) с чисткой куки, различными браузерами, множеством программ для видеотрансляций и даже после детального выполнения инструкции «как запустить трансляцию» от вконтактика с пониманием что нет, не показалось:
конкретный функционал трансляции в VK Video сломан.
Ну а дальше – моя борьба:
1. Попытка прорваться через бота поддержки и достучаться до живого человека. 40 минут. Но полновесных, с непрерывным общением с ботом сорока минут.
2. Написание полноценного баг-репорта и попытка заставить живого человека его осознать, а не выхватывать знакомое слово и не предлагать не имеющее отношения к теме решение. 2 часа.
3. Выслушивание «да не может быть!» и проведение пользовательского тестирования под руководством живого человека с той стороны ещё раз, с прикладыванием скриншотов и записанных видео – 3 дня. В целом, понять сотрудника поддержки можно – я бы тоже не поверил, даже прочитав подробнейший баг-репорт, что его автор всё это уже проделывал.
4. Лицезрение текста «хм, какой интересный кейс, будем смотреть» в чате поддержки без каких-то иных телодвижений с их стороны – 2 дня.
Ну и со вчера – вот:
То, что поддержка отдыхает в выходные – отдельная история: вторая неделя моей борьбы пошла.
В общем, от кармы нахождения критической ошибки в каком-то публичном сервисе (со мной регулярно такое, раз в год примерно) и отыгрывания роли бесплатный QA Lead на удалёнке – не уйти.
❗️Не пренебрегайте ручными тестированием, дамы и господа ❗️
О дате/времени эфира напишем с Наташей дополнительно.
👉 Об ИТ и менеджменте. Подписываемся и пересылаем друзьям
Небольшая жизненная история вам про дефекты – должен же я как-то оправдаться, что эфир с Наташей Косиновой переносится.
Захожу я на прошлой неделе к себе на канал в VK Video, чтобы запланировать трансляцию для нашей с Наташей беседы, а там меня встречает большая плашка:
ура! Мы тут много нового сделали в функционале трансляций. И вот то, и вот так, а ещё гляньте на это и оцените фишечку!..
Как будто уже понятно, чем закончится, да? Ручное тестирование всего функционала по пользовательским сценариям нонеча ж не в моде: зачем, когда
Короче, выныриваю обратно в нашу реальность после часов трёх экспериментов (бывших тестировщиков не бывает!) с чисткой куки, различными браузерами, множеством программ для видеотрансляций и даже после детального выполнения инструкции «как запустить трансляцию» от вконтактика с пониманием что нет, не показалось:
конкретный функционал трансляции в VK Video сломан.
Ну а дальше – моя борьба:
1. Попытка прорваться через бота поддержки и достучаться до живого человека. 40 минут. Но полновесных, с непрерывным общением с ботом сорока минут.
2. Написание полноценного баг-репорта и попытка заставить живого человека его осознать, а не выхватывать знакомое слово и не предлагать не имеющее отношения к теме решение. 2 часа.
3. Выслушивание «да не может быть!» и проведение пользовательского тестирования под руководством живого человека с той стороны ещё раз, с прикладыванием скриншотов и записанных видео – 3 дня. В целом, понять сотрудника поддержки можно – я бы тоже не поверил, даже прочитав подробнейший баг-репорт, что его автор всё это уже проделывал.
4. Лицезрение текста «хм, какой интересный кейс, будем смотреть» в чате поддержки без каких-то иных телодвижений с их стороны – 2 дня.
Ну и со вчера – вот:
Прошу прощения за длительное ожидание. Нас буквально завалило лавиной вопросов.
Ваше обращение передано разработчикам — они уже занимаются этим вопросом.
Надеемся, решение найдётся в кратчайшие сроки. Однако иногда устранение неполадок занимает больше времени, чем хотелось бы. Благодарим вас за терпение и понимание!
Как только появятся новости, вы сразу получите уведомление в этом диалоге.
То, что поддержка отдыхает в выходные – отдельная история: вторая неделя моей борьбы пошла.
В общем, от кармы нахождения критической ошибки в каком-то публичном сервисе (со мной регулярно такое, раз в год примерно) и отыгрывания роли бесплатный QA Lead на удалёнке – не уйти.
❗️Не пренебрегайте ручными тестированием, дамы и господа ❗️
О дате/времени эфира напишем с Наташей дополнительно.
👉 Об ИТ и менеджменте. Подписываемся и пересылаем друзьям
❤2
🌡Давно я так не болела.
Накрыло знатно.
И пока болела, вспоминала все свои героические подвиги на проектах.
Я говорю про те самые моменты, когда не можешь, а надо. Точнее болеешь, но на больничном пытаешься дописать ТЗ, поставить ещё одну постановку в разработку, кого-то проконсультировать. Менеджер звонит и говорит надо, и вот ты чувствуешь себя нужным, незаменимым, а ещё чувство ответственности давит. И что? Да кому это всё надо было! Только менеджеру, но он даже апельсинов не купил)
Не работать во время болезни меня научил один случай. Когда я с температурой из себя выдавливала макеты, ТЗ, а потом когда вылечилась посмотрела на всё "трезвым" взглядом. Всё можно было выбрасывать в помойку. Количество ошибок зашкаливало. Тем более в больном состоянии один макет это оооооогромный труд в несколько часов, а вот в обычном режиме, раз, два и готово.
Скажу банальность, но за подвиги не платят. Точнее даже плачу я, своим здоровьем. Режим работы и отдыха, а тем более болезни и восстановления нужно соблюдать. Больной сотрудник не нужен, как вцелом больной человек.
Как у вас дела обстоят с подвигами?
Даёте себе слабину?
Накрыло знатно.
И пока болела, вспоминала все свои героические подвиги на проектах.
Я говорю про те самые моменты, когда не можешь, а надо. Точнее болеешь, но на больничном пытаешься дописать ТЗ, поставить ещё одну постановку в разработку, кого-то проконсультировать. Менеджер звонит и говорит надо, и вот ты чувствуешь себя нужным, незаменимым, а ещё чувство ответственности давит. И что? Да кому это всё надо было! Только менеджеру, но он даже апельсинов не купил)
Не работать во время болезни меня научил один случай. Когда я с температурой из себя выдавливала макеты, ТЗ, а потом когда вылечилась посмотрела на всё "трезвым" взглядом. Всё можно было выбрасывать в помойку. Количество ошибок зашкаливало. Тем более в больном состоянии один макет это оооооогромный труд в несколько часов, а вот в обычном режиме, раз, два и готово.
Скажу банальность, но за подвиги не платят. Точнее даже плачу я, своим здоровьем. Режим работы и отдыха, а тем более болезни и восстановления нужно соблюдать. Больной сотрудник не нужен, как вцелом больной человек.
Как у вас дела обстоят с подвигами?
Даёте себе слабину?
❤15👍10
Подкаст, дающий инсайты.
За последние несколько дней так часто цитировала Евгения Черешнева из подкаста Телекоммуналка, что поняла, стоит поделиться с вами.
Отличный разговор умных людей, и слушая сам становишься чуточку умнее. А где-то появляются новый нейронные связи.
Несколько выводов, некоторые из них #капитаночевидность
✔️ 1.Взломать можно всё! Везде есть дыры, и нет таких огромных бюджетов, чтобы эти дыры латать. Тем более с текущей мировой политикой никто не договориться о совместном развитии технологий.
✔️ 2.ИИ конечно все пихают, но бизнес не особо понимает выгоды, что вцелом понятно. В итоге выхлоп минимальный. Тут от себя скажу, что поиск и перебор данных в науке с помощью ИИ конечно даёт "вау эффект" и результат. Как и ИИ в кибербезопасности.
✔️ 3.Кажется, что ИИ это что-то новое в части развития технологий, но по сути мы уже видели как Microsoft открывал доступ и давал возможности создавать приложения под свою ОС, что позволило проанализировать потребность пользователей и создать пакет офисных приложений. Так и сейчас есть доступ ко всем ИИ, но в какой-то момент, произойдёт анализ потребностей и будут создаваться платные сервисы под конкретные потребности.
✔️ 4.Дата центры это критическая инфраструктура, которая требует серьёзной защиты. Строительство объектов энергетики должно происходить совместно со строительством дата центров, что вцелом логично.
✔️ 5.Что очень отозвалось моему сердцу, это необходимость культуры инноваций, творчества. Инноваторы в корпорациях скорее аномалия, часто нет возможностей и среды, в компании. Плюс директивный процесс губит всё на корню, как и перекупка или отбор продуктов у основателей.
✔️ 6.Проблема данных на которых строятся языковые модели. И конечно проблема качества этих данных. От себя отмечу, что ИИ уже выглядит как новый этап автоматизации. Но раньше, если мы говорили, что автоматизируя хаос, мы получаем автоматизированный хаос, то теперь ещё ИИ на основе этого хаоса.
✔️ 7.Утечка данных через ИИ. Мне кажется я пароноик, но каждый раз мне кажется, что я отдаю всё куда-то, как в черную дыру)) конечно ИИ меня не просит передать координаты чего либо, но полное доверие людей ИИ, что ты говоришь как будто с человеком, вполне может привести к утечке критичных данных. И тут как всегда безопасность должна отлавливать подобные кейсы, я думаю совсем скоро, если уже не сейчас, в корпорациях будет стоять фильтр, который анализирует какая информация уходит в ИИ.
Информации в подкасте больше, но я выделила, что именно меня задело.
За последние несколько дней так часто цитировала Евгения Черешнева из подкаста Телекоммуналка, что поняла, стоит поделиться с вами.
Отличный разговор умных людей, и слушая сам становишься чуточку умнее. А где-то появляются новый нейронные связи.
Несколько выводов, некоторые из них #капитаночевидность
Информации в подкасте больше, но я выделила, что именно меня задело.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍2
Буду дублировать посты также на страницу в VK, раз такие у нас нестабильные времена.
✔️ Подписывайтесь
https://m.vk.com/sup.expert
Из телеги не ухожу, пока есть возможность буду здесь. Таки дела...
https://m.vk.com/sup.expert
Из телеги не ухожу, пока есть возможность буду здесь. Таки дела...
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤1
Старт курса интеграции, 11 гибкий поток! 🚀
Уже практически середина апреля и наконец-то я с🔝 новостями, мы запускаем курс интеграции! Сразу скажу, что возможно следующего такого большого запуска не будет, так что те кто давно откладывал, но хотел, приходите.
✔️ Гибкий формат участия. Это означает, что вы можете выбирать на какие занятия приходить, нужна ли вам лекция или практика, или вы что-то хотите изучать блоком, а не всё подряд. 2 месяца для курса - это длительный срок и такой марафон не всем подходит, поэтому мы предлагаем вам точечно выбирать нужные именно вам темы и идти в своём темпе.
✔️ Новое время
Многие жаловались на время проведения курса, на этот раз все занятия будут проходить вечерами с 19 до 21 по Москве.
График - четверг лекция, во вторник практика, так и остаётся, но майские праздники вносят коррективы.
🔄 Также мы обновили начинку и пригласили Зою Маттис провести занятия в части проектирования интеграций с помощью ИИ!
➕ Мы добавили архитектурную кату-игру по выбору интеграционного решения, которая будет ближе к концу курса.
❗️ Старт первого занятия состоится уже в этот четверг 16 апреля с 19 до 21 по Москве, с вводной лекции про концептуальное проектирование, и использование диаграмм С4 на практике.
👉Подробнее про курс, расписание, цену можно почитать на нашем Лендинге, где также можно оставить заявку на участие.
По любым вопросам пишите ниже или мне в личку‼️
Уже практически середина апреля и наконец-то я с
Многие жаловались на время проведения курса, на этот раз все занятия будут проходить вечерами с 19 до 21 по Москве.
График - четверг лекция, во вторник практика, так и остаётся, но майские праздники вносят коррективы.
👉Подробнее про курс, расписание, цену можно почитать на нашем Лендинге, где также можно оставить заявку на участие.
По любым вопросам пишите ниже или мне в личку
Please open Telegram to view this post
VIEW IN TELEGRAM
sup.expert
Курс по системной интеграции
🔥5
Расписание занятий по курсу интеграции. Вы можете выбрать любое занятие и посетить только его.
‼️ Подробнее на сайте
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
Нельзя просто так взять и спроектировать концепт
Завтра мы стартуем курс интеграции, как раз с концептуального проектирования.
Вроде бы, уровень концепта, это просто вид сверху, но он даётся сложно начинающим аналитикам.
Недостаточно опыта, нет нужной насмотренности структуры компаний, предприятий, бизнеса.
Навык мыслить верхнеуровнево концепциями это не так просто! При этом проще даже стартовать с деталей, а потом их объединять в концепт.
Хотя казалось бы, на верхнем уровне очень простые инструменты, можно взять кубики и стрелочки, набросать.
Аналитик, он в какой-то степени решатель, исследователь, проектировщик. И вот этого верхнеуровневого обзора иногда не хватает. Я даже часто слышу, что это уже не аналитик, а системный архитектор. Хотя мне непонятно, как аналитик может работать с какой либо системой, не понимая её место в организации и айти ландшафте.
Почему так происходит❓:
✅1.Опыт, практика, насмотренность. Всё таки не зря архитекторы это люди с опытом, прошедшие определённый путь и видавшие всякое.
✅2.Когнитивные искажения - мозгу сложно, мы не чувствуем контроль над задачей. А если нет контроля, нет уверенности, поэтому хочется уйти в анализ деталей, чтобы понять, а как же оно работает? И вернуть себе контроль. Возможно, потом, спустя время, возврат к концепту можно сделать безболезненно.
✅3.Ответственность - многие аналитики с синдромом самозванца. Всё таки ИТ-специалист прошёл путь учёбы в институте, набивания шишек, кучи отборов, собеседований. Институт, это конечно прекрасно, но это определённая уязвимая позиция ученика, когда ты под и из такой позиции брать ответственность очень сложно. И ты всегда проходишь кастинг и пытаешься соответствовать.
✅ 4. Высокая степень неопределённости, которая требует исследования и погружения, а также взгляда сеньора, что где-то подобное уже увидел, и это тоже нормально.
И вот мы получаем итог, что спроектировать на уровне концепта - это задача для аналитиков, или ИТ-специалистов на опыте #капитаночевидность
Проектирование - это процесс, и он нелинейный, хочется получить чек-лист и идти по нему, но по сути проектирование это витки рефлексии, осмысления, согласования, проб и ошибок.
Проектирование - это гибкий навык с жёстким фундаментом, когда у нас есть нотации, диаграммы, инструменты, но чтобы в них уложить информацию нам нужны рассуждения, которые дают выводы и их мы визуализируем.
✔️ Хотите попрактиковаться в проектирование концептов, приходите на лекцию (уже завтра 16 апреля) и/или практику по DFD, C4 (21 апреля).
✔️ Почитать подробнее про курс интеграции, посмотреть расписание, оставить заявку на участие можно на сайте.
А вы, на своих проектах делаете артефакты на уровне концепта бизнеса (бизнес-модель, карта бизнес-процессов) или системы (С4)❓
#концепция #проектирование #правдажизни #мойопыт
Завтра мы стартуем курс интеграции, как раз с концептуального проектирования.
Вроде бы, уровень концепта, это просто вид сверху, но он даётся сложно начинающим аналитикам.
Недостаточно опыта, нет нужной насмотренности структуры компаний, предприятий, бизнеса.
Навык мыслить верхнеуровнево концепциями это не так просто! При этом проще даже стартовать с деталей, а потом их объединять в концепт.
Хотя казалось бы, на верхнем уровне очень простые инструменты, можно взять кубики и стрелочки, набросать.
Аналитик, он в какой-то степени решатель, исследователь, проектировщик. И вот этого верхнеуровневого обзора иногда не хватает. Я даже часто слышу, что это уже не аналитик, а системный архитектор. Хотя мне непонятно, как аналитик может работать с какой либо системой, не понимая её место в организации и айти ландшафте.
Почему так происходит❓:
✅1.Опыт, практика, насмотренность. Всё таки не зря архитекторы это люди с опытом, прошедшие определённый путь и видавшие всякое.
✅2.Когнитивные искажения - мозгу сложно, мы не чувствуем контроль над задачей. А если нет контроля, нет уверенности, поэтому хочется уйти в анализ деталей, чтобы понять, а как же оно работает? И вернуть себе контроль. Возможно, потом, спустя время, возврат к концепту можно сделать безболезненно.
✅3.Ответственность - многие аналитики с синдромом самозванца. Всё таки ИТ-специалист прошёл путь учёбы в институте, набивания шишек, кучи отборов, собеседований. Институт, это конечно прекрасно, но это определённая уязвимая позиция ученика, когда ты под и из такой позиции брать ответственность очень сложно. И ты всегда проходишь кастинг и пытаешься соответствовать.
✅ 4. Высокая степень неопределённости, которая требует исследования и погружения, а также взгляда сеньора, что где-то подобное уже увидел, и это тоже нормально.
И вот мы получаем итог, что спроектировать на уровне концепта - это задача для аналитиков, или ИТ-специалистов на опыте #капитаночевидность
Проектирование - это процесс, и он нелинейный, хочется получить чек-лист и идти по нему, но по сути проектирование это витки рефлексии, осмысления, согласования, проб и ошибок.
Проектирование - это гибкий навык с жёстким фундаментом, когда у нас есть нотации, диаграммы, инструменты, но чтобы в них уложить информацию нам нужны рассуждения, которые дают выводы и их мы визуализируем.
А вы, на своих проектах делаете артефакты на уровне концепта бизнеса (бизнес-модель, карта бизнес-процессов) или системы (С4)
#концепция #проектирование #правдажизни #мойопыт
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤2🔥1
Проблемы концепций
Обсуждая С4, в комментариях, Юра, спасибо ему❤️, затронул сразу несколько тем и болей.
✔️ 1.Бизнес не понимает зачем им бизнес-модель и расчёт экономической эффективности.
Что тут скажешь. Если бизнес не умеет считать свои же деньги, то в какой-то момент жизнь заставит) И тут вечная проблема, а стоит ли мне доносить до бизнеса и переубеждать? Если мы говорим в рамках С4, и говорим про системный контекст или про бизнес концепт нашего проекта, то тут я бы сказала, что где-то бизнес мы сами развиваем. Опять же у меня нет вводных, кто, когда, почему и зачем. Но если вы сеньорный аналитик, то вполне нормальная задача рассказать и показать выгоду для бизнеса, от того, что у них будет концепт. Поработать консультантом для бизнеса.
Без понимания единой картины и работы компании, как системы, управлять развитием и изменениями затруднительно, потому что как раз нет субъекта управления. Задача убедить бизнес, это всегда задача со звездочной, и вопрос, а нужно ли оно вам? Тут и вопрос компетенции, и развития, и конечно сложного процесса переговоров, а это рост. Плохая идея пытаться кого либо перевоспитать, но призывать к реальности, фактам вполне себе работает. С другой стороны когда показываешь на своём примере, сам понимаешь как нужно и так делаешь, то остальные подтягиваются. Разные у меня были случаи на практике. И тут вопрос доверия, коммуникации и выстраивания отношений. А там где доверие, там уже больше возможностей.
Если говорить про бизнес эффективность, то тут исследование проблемы и работа бизнес-аналитика по BACCM, поможет ничего не забыть и снова построить систему. А если мы говорим про поставку, то эффект от поставки нужно понимать, чтобы разработать и сдать продукт. Про это у нас есть соответствующие тренинги "Китайская ручка" и "Большая стирка", будет такой запрос проведём открытый тренинг) пишите, если вам интересны подобные направления.
✔️ 2.Проблемы, когда контекст нарезан на команды, нет единого центра. Тут дело не в С4, по сути в С4 ничего нового нет, просто DFD, функциональную архитектуру и диаграмму компонентов из UML, Саймон Браун уложил в единый инструмент.
То, что нет владельца единого, и единой картины, это сплошь и рядом, и тут не С4 виноват, а отчасти Agile, Scrum и микросервисы. Одно с другим нам говорит работайте в команде, и делите контексты между команд. Но вот проблемы с синхронизацией этих команд я вижу очень часто. С одной стороны, это может быть политическая ситуация, и сознательный выбор устройства, так проще, несколько центров управления и нет одного кого-то. А с другой стороны, исторически сложилось. Не было архитектора, и человека кто бы опять же вёл управление. Когда с таким сталкиваешься, понимаешь, что непаханное поле, и можно начать частями синхронизацию. Как только появляется звено над командами, всё работает и с микросервисами и Agile, Scrum, так что вопрос применения и выстраивания внутренних процессов.
Подведу итог, что С4 инструмент, почему так много вокруг него обсуждений, потому что это средство начать коммуникации и синхронизации между участниками. А когда бизнес видит С4, он начинает понимать границы проекта, и на что деньги уходят.
И как Андрей Корниенко сказал, можно уже торговаться и добавлять или исключать системы из проекта, управлять scope.
👀 Про С4, Андрей отличное видео делал, рекомендую к просмотру.❗️
#c4 #концепция #системныйанализ #проблемы #мысливслух
Обсуждая С4, в комментариях, Юра, спасибо ему❤️, затронул сразу несколько тем и болей.
Что тут скажешь. Если бизнес не умеет считать свои же деньги, то в какой-то момент жизнь заставит) И тут вечная проблема, а стоит ли мне доносить до бизнеса и переубеждать? Если мы говорим в рамках С4, и говорим про системный контекст или про бизнес концепт нашего проекта, то тут я бы сказала, что где-то бизнес мы сами развиваем. Опять же у меня нет вводных, кто, когда, почему и зачем. Но если вы сеньорный аналитик, то вполне нормальная задача рассказать и показать выгоду для бизнеса, от того, что у них будет концепт. Поработать консультантом для бизнеса.
Без понимания единой картины и работы компании, как системы, управлять развитием и изменениями затруднительно, потому что как раз нет субъекта управления. Задача убедить бизнес, это всегда задача со звездочной, и вопрос, а нужно ли оно вам? Тут и вопрос компетенции, и развития, и конечно сложного процесса переговоров, а это рост. Плохая идея пытаться кого либо перевоспитать, но призывать к реальности, фактам вполне себе работает. С другой стороны когда показываешь на своём примере, сам понимаешь как нужно и так делаешь, то остальные подтягиваются. Разные у меня были случаи на практике. И тут вопрос доверия, коммуникации и выстраивания отношений. А там где доверие, там уже больше возможностей.
Если говорить про бизнес эффективность, то тут исследование проблемы и работа бизнес-аналитика по BACCM, поможет ничего не забыть и снова построить систему. А если мы говорим про поставку, то эффект от поставки нужно понимать, чтобы разработать и сдать продукт. Про это у нас есть соответствующие тренинги "Китайская ручка" и "Большая стирка", будет такой запрос проведём открытый тренинг) пишите, если вам интересны подобные направления.
То, что нет владельца единого, и единой картины, это сплошь и рядом, и тут не С4 виноват, а отчасти Agile, Scrum и микросервисы. Одно с другим нам говорит работайте в команде, и делите контексты между команд. Но вот проблемы с синхронизацией этих команд я вижу очень часто. С одной стороны, это может быть политическая ситуация, и сознательный выбор устройства, так проще, несколько центров управления и нет одного кого-то. А с другой стороны, исторически сложилось. Не было архитектора, и человека кто бы опять же вёл управление. Когда с таким сталкиваешься, понимаешь, что непаханное поле, и можно начать частями синхронизацию. Как только появляется звено над командами, всё работает и с микросервисами и Agile, Scrum, так что вопрос применения и выстраивания внутренних процессов.
Подведу итог, что С4 инструмент, почему так много вокруг него обсуждений, потому что это средство начать коммуникации и синхронизации между участниками. А когда бизнес видит С4, он начинает понимать границы проекта, и на что деньги уходят.
И как Андрей Корниенко сказал, можно уже торговаться и добавлять или исключать системы из проекта, управлять scope.
#c4 #концепция #системныйанализ #проблемы #мысливслух
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤3🔥1
Что-то пошло не так...
Одна из подстав на проектах, это когда внезапно меняется команда заказчика.
У моей команды анализа такое было. И вдруг никто, ничего согласовать не может/не хочет. Ещё хуже когда на стороне заказчика есть, кто-то обиженный, но не принимающий решения. И вот тоже происходит вдруг, и человек становится заинтересованной стороной номер 1.
Мне когда-то рассказали, как на стороне заказчика, мужчина женился на дочке директора и начал топить проект.
А мы тут с вами про айти, ИИ, технологии)) Но люди есть люди, и они оказывают самое большое влияние. Даже мимо проходящая уборщица. Такая вот уборщица мыла пол и специально ударила мне по пальцам ног. Я хромала. Чего только в офисах не происходит)))
Какие у вас были случаи внезапной смены курса проекта и изменения, которые перевернули всё с ног на голову.
Делитесь историями📣
Одна из подстав на проектах, это когда внезапно меняется команда заказчика.
У моей команды анализа такое было. И вдруг никто, ничего согласовать не может/не хочет. Ещё хуже когда на стороне заказчика есть, кто-то обиженный, но не принимающий решения. И вот тоже происходит вдруг, и человек становится заинтересованной стороной номер 1.
Мне когда-то рассказали, как на стороне заказчика, мужчина женился на дочке директора и начал топить проект.
А мы тут с вами про айти, ИИ, технологии)) Но люди есть люди, и они оказывают самое большое влияние. Даже мимо проходящая уборщица. Такая вот уборщица мыла пол и специально ударила мне по пальцам ног. Я хромала. Чего только в офисах не происходит)))
Какие у вас были случаи внезапной смены курса проекта и изменения, которые перевернули всё с ног на голову.
Делитесь историями
Please open Telegram to view this post
VIEW IN TELEGRAM
😱6❤2😁2👍1
Какие диаграммы вы чаще всего формируете в постановке задачи на разработку? (можно выбрать несколько вариантов ответа) ✅
Anonymous Poll
41%
BPMN стараюсь соблюдать правила нотации
72%
UML, sequence, с опорой на нотацию
32%
Создаю авторские диаграммы вне правил
10%
Использую бизнес, продуктовые инструменты CJM, Canvas и др.
16%
Зачем картинки, пишу текст! 😎
1%
Ничего из перечисленного, ответ напишу в комментариях
18%
С4, Archimate, работаю с архитектурой
❤2🔥1
Продолжаю разбирать интервью аналитиков для моей диссертации в магистратуре. И ответы про нотации и выбор их по % совпадает с ответами в опросе выше. 32% - делают авторские диаграммы.
Хотела порассуждать на тему ЗА и ПРОТИВ отсебятины.
Опять же, я пишу #моемнение
Итак, пункты❌ ПРОТИВ такого подхода:
1.Аргумент часто мне приводят такой, что разработка и бизнес не понимают диаграммы. Тут хочется сказать, что разработка сама проектирует решения, и для меня странно, просто удивительно, почему один из инструментов проектирования обесценивается. Потому что тот же UML, как показали годы, средство для проектирования и лучше ничего не придумали. То что бизнес не понимает, так нужно брать нотации бизнеса. Если и этого не понимают, то страшно выходить на проекты....
2.Нотация - это всё таки не просто элементы и правила, как их соединить вместе. У нотации есть фундамент. Математико-логический, да, сети Петри, графы, но и описание как обеспечить выполнение функции. По сути нужно поставку задачи разбить на пункты (ответить на вопросы): куда вводятся данные, куда и как передаются, как обрабатываются, где хранятся, куда выводятся. То есть нотация нам даёт рамки, чтобы сделать то, что необходимо, это как чек-лист. Кто работал с EPC или IDEF, я думаю замечали, что всё примерно про одно и то же, и собранную информацию, нужно разложить по пунктам: вход, выход, работа, управление, кто выполняет, с помощью чего.
3.Нотация, это опора. Даже если всё забыл, нотация сама подскажет, что и как оформить. Для этого и была создана. И аргумент, что это трудно и ваще, старье какое-то. Да, трудно! А вы думали в сказку попали) Насчёт старья, нет понятия, старое или новое к таким вещам, как нотация, также как в технологиях, есть целесообразность применения в конкретном случае.
4.Нотация - это общая вещь и везде плюс, минус одинаковая, это общий язык с помощью которого мы передаём сложную информацию в команду. И зная как говорить на этом языке, мы друг друга начинаем понимать, и понимать однозначно и одинаково. Мы же не говорим, давайте выкинем английский, и сделаем что-то своё. Эсперанто было и где оно?)
Может показаться, что я ярый сторонник нотаций и никогда не рисовала, что-то своё) Рисовала конечно, когда надо было сдавать проект, а заказчик ничего не понимает. Но я всё таки за то, чтобы заказчик рос вместе с командой.
Теперь список✔️ ЗА авторские диаграммы:
1.Самый большой плюс это закрыть непонимание заказчика, но тут большой риск, что больше никто не поймёт, что вы там придумали.
2.Уменьшаем градус ответственности и стресс. И то неуверена, что отсебятина даст свободу)
Больше не могу придумать, добавьте сами)))
Буду дальше топить за нотации.
Выкинуть, обесценить нотации очень просто. И мне такое поведение показывает сопротивление или непонимание основ, фундамента. Я сама сопротивляюсь новому, но когда сопротивление проходит, приходит результат.
Приведу пример, я рисую, и каждый раз пытаюсь понять, изучить процесс, методологию, что и как делать, чтобы точно получился результат. И чтобы этот результат был гарантировано повторяем! Да, можно рисовать наивные рисунки, как Пиросмани, но хочется же как Шишкин рисовать природу. А если я замахиваюсь на такое, то и изучать мне нужно больше, и практиковаться.
Плюс когда художник знает фундамент и академизм, он потом в рамках этого академизма грамотно ломать. Что например делал Пикассо, который действительно много учился и умел рисовать!
Так и мы с вами, набиваем руку с визуализацией графов, изучаем правила, чтобы потом могли создать своё. И чётко объяснить правила почему так, что обознает квадратик, а что такое стрелочка.
И почему ваша авторская диаграмма, например, лучше блок-схемы?
#мысливслух #нотации #основы #рассуждения #запротив
Хотела порассуждать на тему ЗА и ПРОТИВ отсебятины.
Опять же, я пишу #моемнение
Итак, пункты
1.Аргумент часто мне приводят такой, что разработка и бизнес не понимают диаграммы. Тут хочется сказать, что разработка сама проектирует решения, и для меня странно, просто удивительно, почему один из инструментов проектирования обесценивается. Потому что тот же UML, как показали годы, средство для проектирования и лучше ничего не придумали. То что бизнес не понимает, так нужно брать нотации бизнеса. Если и этого не понимают, то страшно выходить на проекты....
2.Нотация - это всё таки не просто элементы и правила, как их соединить вместе. У нотации есть фундамент. Математико-логический, да, сети Петри, графы, но и описание как обеспечить выполнение функции. По сути нужно поставку задачи разбить на пункты (ответить на вопросы): куда вводятся данные, куда и как передаются, как обрабатываются, где хранятся, куда выводятся. То есть нотация нам даёт рамки, чтобы сделать то, что необходимо, это как чек-лист. Кто работал с EPC или IDEF, я думаю замечали, что всё примерно про одно и то же, и собранную информацию, нужно разложить по пунктам: вход, выход, работа, управление, кто выполняет, с помощью чего.
3.Нотация, это опора. Даже если всё забыл, нотация сама подскажет, что и как оформить. Для этого и была создана. И аргумент, что это трудно и ваще, старье какое-то. Да, трудно! А вы думали в сказку попали) Насчёт старья, нет понятия, старое или новое к таким вещам, как нотация, также как в технологиях, есть целесообразность применения в конкретном случае.
4.Нотация - это общая вещь и везде плюс, минус одинаковая, это общий язык с помощью которого мы передаём сложную информацию в команду. И зная как говорить на этом языке, мы друг друга начинаем понимать, и понимать однозначно и одинаково. Мы же не говорим, давайте выкинем английский, и сделаем что-то своё. Эсперанто было и где оно?)
Может показаться, что я ярый сторонник нотаций и никогда не рисовала, что-то своё) Рисовала конечно, когда надо было сдавать проект, а заказчик ничего не понимает. Но я всё таки за то, чтобы заказчик рос вместе с командой.
Теперь список
1.Самый большой плюс это закрыть непонимание заказчика, но тут большой риск, что больше никто не поймёт, что вы там придумали.
2.Уменьшаем градус ответственности и стресс. И то неуверена, что отсебятина даст свободу)
Больше не могу придумать, добавьте сами)))
Буду дальше топить за нотации.
Выкинуть, обесценить нотации очень просто. И мне такое поведение показывает сопротивление или непонимание основ, фундамента. Я сама сопротивляюсь новому, но когда сопротивление проходит, приходит результат.
Приведу пример, я рисую, и каждый раз пытаюсь понять, изучить процесс, методологию, что и как делать, чтобы точно получился результат. И чтобы этот результат был гарантировано повторяем! Да, можно рисовать наивные рисунки, как Пиросмани, но хочется же как Шишкин рисовать природу. А если я замахиваюсь на такое, то и изучать мне нужно больше, и практиковаться.
Плюс когда художник знает фундамент и академизм, он потом в рамках этого академизма грамотно ломать. Что например делал Пикассо, который действительно много учился и умел рисовать!
Так и мы с вами, набиваем руку с визуализацией графов, изучаем правила, чтобы потом могли создать своё. И чётко объяснить правила почему так, что обознает квадратик, а что такое стрелочка.
И почему ваша авторская диаграмма, например, лучше блок-схемы?
#мысливслух #нотации #основы #рассуждения #запротив
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4❤1👍1
Сегодня 2 блок курса интеграции - Use Cases, предметка, диаграмма статусов
Продолжаем курс интеграции, сегодня стартует второй блок, лекция. Будем разбирать use cases - как ключевой инструмент проектирования интеграций и всё, что в помощь сценариям взаимодействия стоит проанализировать. Ведь именно в сценариях у нас участвуют объекты предметной области. Поэтому будем говорить про онтологическое моделирование, и state machine. А также про то, что сценарий можно спроектировать на разном уровне будем - пользовательском, функциональном, системном.
В этот раз курс у нас с гибким посещением, потому что, возможно, это последний наш поток, нет уверенности в завтрашнем дне и в том, что в таком составе и объёме мы ещё раз будем читать курс. Возможно, разобьём на мастер-классы, тренинги, но это уже будет другая история....
По use cases, онтологии, state machine, будет домашнее задание, которое будем интерактивно проверять в следующий вторник 28 апреля.✔️ Приходите!
📌 Подборнее про курс, расписание читайте на сайте.
Продолжаем курс интеграции, сегодня стартует второй блок, лекция. Будем разбирать use cases - как ключевой инструмент проектирования интеграций и всё, что в помощь сценариям взаимодействия стоит проанализировать. Ведь именно в сценариях у нас участвуют объекты предметной области. Поэтому будем говорить про онтологическое моделирование, и state machine. А также про то, что сценарий можно спроектировать на разном уровне будем - пользовательском, функциональном, системном.
В этот раз курс у нас с гибким посещением, потому что, возможно, это последний наш поток, нет уверенности в завтрашнем дне и в том, что в таком составе и объёме мы ещё раз будем читать курс. Возможно, разобьём на мастер-классы, тренинги, но это уже будет другая история....
По use cases, онтологии, state machine, будет домашнее задание, которое будем интерактивно проверять в следующий вторник 28 апреля.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥1
Forwarded from Сорока пишет | Об ИТ и менеджменте
Прямой эфир! Или чем заняться в воскресенье
Друзья! Вконтактик совершенно официально починил свой грёбаный дефект, мы с Наташей совершенно официально разгребли все свои форс-мажоры, вы совершенно официально не едете на дачу в предстоящие выходные:
дождь и холод по прогнозу, можете сами на Яндекс.Погоде посмотреть.
Поэтому...
В это воскресенье, 26 апреля, в 11:00 (всё для того, чтобы вы успели выспаться) погрузимся во внутреннюю кухню проектов: поговорим о том, как правильно выстроить работу аналитиков на проекте и каких ошибок нужно избегать.
Совместный эфир Тараса Сороки – эксперта по управлению ИТ и цифровой трансформацией, ведущего канала Сорока пишет | Об ИТ и менеджменте и Наташи Косиновой – эксперта в системном и бизнес-анализе, автора тренингов для аналитиков и ведущей канала Наташа Косинова. Варю айти СУП.
C толком, с чувством, с расстановкой пройдёмся по всем граблям, по которым ходят проектные команды в своём взаимодействии с аналитиками:
👉 отсутствие аналитика! Руководитель проекта пишет ТЗ самостоятельно;
👉 хороший руководитель проекта с точки зрения аналитика – какой он?
👉 аналитик – товарищ руководителя проекта или заноза у него в ж?… Роль аналитика на проекте;
👉 коммуникация с разработкой. Что делать, если разработка воспринимает аналитика в штыки?
👉 коммуникация с заказчиком и управление скоупом проекта. Впихиваем невпихуемое – роль и боль аналитика в этой активности;
👉 управление рисками проекта – командная работа аналитика или РП;
👉 смена стейкхолдера. Переписывать ТЗ полностью, или, может, обойдётся?
Ну и Наташа ещё всякими модными инсайтами из мира аналитики поделится. Подключайтесь, будет познавательно. Запись потом тоже будет, no worries.
З. Ы. Чтобы тем, кто уже регистрировался на Timepad, не пришлось делать это вновь, я даю прямую ссылку на трансляцию: на этот раз неприятный дефект я обнаружил на таймпаде – бывших тестировщиков не бывает 😂
З.З.Ы. Картинку для трансляции завтра поставлю, чтобы всё по красоте.
👉 Об ИТ и менеджменте. Подписываемся и пересылаем друзьям
Друзья! Вконтактик совершенно официально починил свой грёбаный дефект, мы с Наташей совершенно официально разгребли все свои форс-мажоры, вы совершенно официально не едете на дачу в предстоящие выходные:
дождь и холод по прогнозу, можете сами на Яндекс.Погоде посмотреть.
Поэтому...
В это воскресенье, 26 апреля, в 11:00 (всё для того, чтобы вы успели выспаться) погрузимся во внутреннюю кухню проектов: поговорим о том, как правильно выстроить работу аналитиков на проекте и каких ошибок нужно избегать.
Совместный эфир Тараса Сороки – эксперта по управлению ИТ и цифровой трансформацией, ведущего канала Сорока пишет | Об ИТ и менеджменте и Наташи Косиновой – эксперта в системном и бизнес-анализе, автора тренингов для аналитиков и ведущей канала Наташа Косинова. Варю айти СУП.
C толком, с чувством, с расстановкой пройдёмся по всем граблям, по которым ходят проектные команды в своём взаимодействии с аналитиками:
👉 отсутствие аналитика! Руководитель проекта пишет ТЗ самостоятельно;
👉 хороший руководитель проекта с точки зрения аналитика – какой он?
👉 аналитик – товарищ руководителя проекта или заноза у него в ж?… Роль аналитика на проекте;
👉 коммуникация с разработкой. Что делать, если разработка воспринимает аналитика в штыки?
👉 коммуникация с заказчиком и управление скоупом проекта. Впихиваем невпихуемое – роль и боль аналитика в этой активности;
👉 управление рисками проекта – командная работа аналитика или РП;
👉 смена стейкхолдера. Переписывать ТЗ полностью, или, может, обойдётся?
Ну и Наташа ещё всякими модными инсайтами из мира аналитики поделится. Подключайтесь, будет познавательно. Запись потом тоже будет, no worries.
З. Ы. Чтобы тем, кто уже регистрировался на Timepad, не пришлось делать это вновь, я даю прямую ссылку на трансляцию: на этот раз неприятный дефект я обнаружил на таймпаде – бывших тестировщиков не бывает 😂
З.З.Ы. Картинку для трансляции завтра поставлю, чтобы всё по красоте.
👉 Об ИТ и менеджменте. Подписываемся и пересылаем друзьям
🎉4👍2
Forwarded from Сорока пишет | Об ИТ и менеджменте
Just a friendly reminder: прямой эфир
Напоминалочка: уже через час, в 11:00 проведём с Наташей Косиновой – экспертом в системном и бизнес-анализе, автором тренингов для аналитиков и ведущей канала Наташа Косинова. Варю айти СУП прямой эфир на тему:
аналитик на проекте: руководство по эксплуатации.
Погрузимся во внутреннюю кухню проектов: поговорим о том, как правильно выстроить работу аналитиков на проекте и каких ошибок нужно избегать, чтобы потом не было мучительно больно.
Подключайтесь, будет познавательно. Запись тоже выложим, no worries.
👉 Об ИТ и менеджменте. Подписываемся и рекомендуем друзьям
Напоминалочка: уже через час, в 11:00 проведём с Наташей Косиновой – экспертом в системном и бизнес-анализе, автором тренингов для аналитиков и ведущей канала Наташа Косинова. Варю айти СУП прямой эфир на тему:
аналитик на проекте: руководство по эксплуатации.
Погрузимся во внутреннюю кухню проектов: поговорим о том, как правильно выстроить работу аналитиков на проекте и каких ошибок нужно избегать, чтобы потом не было мучительно больно.
Подключайтесь, будет познавательно. Запись тоже выложим, no worries.
👉 Об ИТ и менеджменте. Подписываемся и рекомендуем друзьям
🔥1