Channel: Системный сдвиг
Больше видео хороших и разных про ИИ!
Я стараюсь мониторить широкую картину в части ИИ — а что в мире вообще происходит, где есть реальные прорывы, куда идут деньги и как устроены бизнес-модели. Вот тут отличное видео от MTS StartUp Hub — они вообще активно развивают стартапную тему, ну а какой сейчас стартап без ИИ.
Что я для себя использую как критерий адекватности: отсутствие разговоров, как ИИ всё перевернёт и на сколько десятков процентов увеличит мировой ВВП. Если реально на вещи смотреть — пока радикальных изменений не наблюдается. И вот у ребят из MTS StartUp Hub звучат оценки 1.1—1.8% — значит, можно дальше слушать 😏
Обратите внимание — в середине видео мелькает слайд от Tracxn со стартапами и бизнес-моделями, он свежий, от января 2025, что тоже интересно.
ИИ-инструменты разработки и создания ПО там среди уже подтвержденных бизнес-моделей, а меня это интересует лично, есть у меня замысел усиления системных аналитиков и проектировщиков софта при помощи ИИ (с применением методик, которым я учу 😎 ), поэтому тут внимательно смотрю на решения и инвестиции. С ними же связано управление знаниями об архитектуре и проектах, и интеллектуальном ИИ-поиске по этим базам. Тут тоже есть инвестиции, значит — верное направление.
В общем, за какие-то 17 минут клёвый срез актуальной ситуации, полезно. Ну и основные мысли на карточках.
Я стараюсь мониторить широкую картину в части ИИ — а что в мире вообще происходит, где есть реальные прорывы, куда идут деньги и как устроены бизнес-модели. Вот тут отличное видео от MTS StartUp Hub — они вообще активно развивают стартапную тему, ну а какой сейчас стартап без ИИ.
Что я для себя использую как критерий адекватности: отсутствие разговоров, как ИИ всё перевернёт и на сколько десятков процентов увеличит мировой ВВП. Если реально на вещи смотреть — пока радикальных изменений не наблюдается. И вот у ребят из MTS StartUp Hub звучат оценки 1.1—1.8% — значит, можно дальше слушать 😏
Обратите внимание — в середине видео мелькает слайд от Tracxn со стартапами и бизнес-моделями, он свежий, от января 2025, что тоже интересно.
ИИ-инструменты разработки и создания ПО там среди уже подтвержденных бизнес-моделей, а меня это интересует лично, есть у меня замысел усиления системных аналитиков и проектировщиков софта при помощи ИИ (с применением методик, которым я учу 😎 ), поэтому тут внимательно смотрю на решения и инвестиции. С ними же связано управление знаниями об архитектуре и проектах, и интеллектуальном ИИ-поиске по этим базам. Тут тоже есть инвестиции, значит — верное направление.
В общем, за какие-то 17 минут клёвый срез актуальной ситуации, полезно. Ну и основные мысли на карточках.
Как разобраться с JSON?
Регулярно на тренинге по проектированию интеграций у некоторых участников возникают проблемы с описанием примера данных в JSON. Вроде бы простой формат, но и тут встречается непонимание.
Если вы можете представить свои данные в таблице — в JSON их перенести просто: названия колонок становятся ключами, а значения полей — значениями в JSON. Была таблица с полями 'Id', 'Name', 'Surname', 'BirthDate', стал JSON:
Это для одной строки. Несколько строк превращаются в массив объектов. Записи из подчиненных таблиц становятся вложенными объектами или массивами. В целом, это выглядит как преобразование таблицы в набор вертикальных списков.
Но всё становится сложнее, если мы берём несколько связанных таблиц. Часто просят уточнить: ведь структуры данных, которые мы передаём в API, не должны 1:1 соответствовать структуре БД? Правильный ответ — конечно нет, ведь мы можем задавать к этим данным разные вопросы! API — даже если это просто get — это про вопрос, который мы задаем серверу и на который получаем ответ.
Рассмотрим такую структуру данных: студенты, курсы и записи на курс (нам нужна промежуточная таблица, чтобы "расшить" отношение "многие-ко-многим" — один студент может быть записан на несколько курсов, на один курс записаны многие студенты).
К этим данным мы можем задавать разные вопросы:
— дай информацию по одному студенту;
— дай список студентов;
— дай список всех курсов;
— дай список студентов, записанных на определенный курс;
— на какие курсы записаны студенты из одной группы и т.д.
Для каждого ответа может быть свой JSON, за какую ниточку потянем — то и вытянем. Про что спрашиваем, что будет корнем? Идём от студентов, от их записей на курсы, или от самих курсов. Структура JSON в разных ответах будет разной.
Мне показалось, что это слишком просто для поста, поэтому давайте ещё посмотрим на более сложные случаи.
Например, HATEOAS. HATEOAS — Hypermedia As The Engine Of Application State — без которого REST не настоящий. В случае HATEOAS ответ должен содержать ссылки на связанные понятия, и размер JSON растет.
Тут есть несколько соглашений — как именно эти ссылки передавать. На карточке показан один из вариантов.
Есть несколько попыток привести элементы HATEOAS к единой структуре:
🔸HAL (Hypertext application language, c 2016 существует в виде драфта стандарта, но некоторыми используется);
🔹HAL-FORMS от Майка Амундсена, добавляющий "шаблоны" — в каждом ответе мы будем получать кроме ссылок ещё и полную модель переходов между состояниями, ссылки для переходов и даже схемы ответов;
🔸JSON-LD (JSON Linked Data, JSON для связанных данных);
🔹JSON:API — наверное, самый навороченный формат, включающий в себя данные, связанные ссылки, встроенные данные связанных объектов, пагинацию, метаданные и массив ошибок.
Эти форматы — не такая уж экзотика. HAL-FORMS поддерживает популярный java-фреймворк Spring. Ссылки в формате HAL возвращает API Яндекс.Диска. JSON:API встроен в ядро CMS Drupal.
Ну а чтобы разбираться в разных структурах данных, очень хорошо изучить базу — реляционную алгебру и моделирование, нормальные формы, вот это всё. Внезапно они для интеграций тоже нужны.
Регулярно на тренинге по проектированию интеграций у некоторых участников возникают проблемы с описанием примера данных в JSON. Вроде бы простой формат, но и тут встречается непонимание.
Если вы можете представить свои данные в таблице — в JSON их перенести просто: названия колонок становятся ключами, а значения полей — значениями в JSON. Была таблица с полями 'Id', 'Name', 'Surname', 'BirthDate', стал JSON:
{ "id": 12345,
"name": "Константин",
"surname": "Константинопольский",
"birthdate": "1990-04-14"
}Это для одной строки. Несколько строк превращаются в массив объектов. Записи из подчиненных таблиц становятся вложенными объектами или массивами. В целом, это выглядит как преобразование таблицы в набор вертикальных списков.
Но всё становится сложнее, если мы берём несколько связанных таблиц. Часто просят уточнить: ведь структуры данных, которые мы передаём в API, не должны 1:1 соответствовать структуре БД? Правильный ответ — конечно нет, ведь мы можем задавать к этим данным разные вопросы! API — даже если это просто get — это про вопрос, который мы задаем серверу и на который получаем ответ.
Рассмотрим такую структуру данных: студенты, курсы и записи на курс (нам нужна промежуточная таблица, чтобы "расшить" отношение "многие-ко-многим" — один студент может быть записан на несколько курсов, на один курс записаны многие студенты).
К этим данным мы можем задавать разные вопросы:
— дай информацию по одному студенту;
— дай список студентов;
— дай список всех курсов;
— дай список студентов, записанных на определенный курс;
— на какие курсы записаны студенты из одной группы и т.д.
Для каждого ответа может быть свой JSON, за какую ниточку потянем — то и вытянем. Про что спрашиваем, что будет корнем? Идём от студентов, от их записей на курсы, или от самих курсов. Структура JSON в разных ответах будет разной.
Мне показалось, что это слишком просто для поста, поэтому давайте ещё посмотрим на более сложные случаи.
Например, HATEOAS. HATEOAS — Hypermedia As The Engine Of Application State — без которого REST не настоящий. В случае HATEOAS ответ должен содержать ссылки на связанные понятия, и размер JSON растет.
Тут есть несколько соглашений — как именно эти ссылки передавать. На карточке показан один из вариантов.
Есть несколько попыток привести элементы HATEOAS к единой структуре:
🔸HAL (Hypertext application language, c 2016 существует в виде драфта стандарта, но некоторыми используется);
🔹HAL-FORMS от Майка Амундсена, добавляющий "шаблоны" — в каждом ответе мы будем получать кроме ссылок ещё и полную модель переходов между состояниями, ссылки для переходов и даже схемы ответов;
🔸JSON-LD (JSON Linked Data, JSON для связанных данных);
🔹JSON:API — наверное, самый навороченный формат, включающий в себя данные, связанные ссылки, встроенные данные связанных объектов, пагинацию, метаданные и массив ошибок.
Эти форматы — не такая уж экзотика. HAL-FORMS поддерживает популярный java-фреймворк Spring. Ссылки в формате HAL возвращает API Яндекс.Диска. JSON:API встроен в ядро CMS Drupal.
Ну а чтобы разбираться в разных структурах данных, очень хорошо изучить базу — реляционную алгебру и моделирование, нормальные формы, вот это всё. Внезапно они для интеграций тоже нужны.
Вообще я хотел серьезный пост написать про математику, которая помогает в интеграциях, но потом вспомнил — какое сегодня число и какой день недели, и понял, что никто толком не работает, и умная тема не зайдет.
Поэтому ловите комикс про Agile: https://www.comicagile.net/ (с подзаголовком "когда agile сталкивается с реальностью").
Перевел несколько стрипов специально для вас!
Поэтому ловите комикс про Agile: https://www.comicagile.net/ (с подзаголовком "когда agile сталкивается с реальностью").
Перевел несколько стрипов специально для вас!
Или вот хардкорный пост.
В языках С и С++ есть такой тип данных — указатель. Это тип переменной, которая хранит типизированный адрес — ссылку на какое-то место в памяти, где _на самом_ деле находится значение. Например, int* хранит ссылку на какую-то область памяти, содержимое которой программа интерпретирует как целое число. Бывают ситуации посложнее — указатели на экземпляры классов или указатели на функции. В C и C++ указатели используются повсеместно, есть специальная арифметика указателей, и с ними же связаны основные ошибки времени исполнения, эксплойты и утечки памяти.
Концепция указателя является основной для программистов. В институте это хорошо видно — кто не смог понять указатели, как правило, быстро отсеиваются, как непригодные для программирования. Ну или быстро переориентируется на Python, Javascript и другие языки, в которых указатели глубоко спрятаны, чтобы не пугать нормальных людей.
Долгое время считалось, что указатели как концепт придумал в 1964 Гарольд "Бад" Лоусон (у нас известен как автор книги "Путешествие по системному ландшафту" — введения в системную инженерию).
На самом деле, первой идею указателя придумала советская и украинская программистка Катерина Ющенко: ещё в 1955 году она создала "Адресный язык программирования" — один из самых первых языков высокого уровня. В Фортране и Алголе 60 ничего похожего не было. Язык был известен только в СССР, поэтому Лоусон "переизобрел" указатели для PL/I.
Катерина Ющенко же была автором одного из первых учебников по программированию, а потом долго занималась теоретическим программированием — особой школой программирования в СССР, сильно связанной с математическим обоснованием программ и научными исследованиями. Получила несколько государственных премий и звание члена-корреспондента Национальной академии наук Украины (в 1979).
И вот что я хочу сказать, и говорю каждый год (2024, 2023) — вклад женщин в нашу индустрию неоценим! Без вас никакого ИТ бы не было, вот что! Самые крутые штуки — первые программы вообще, компиляторы, указатели, оболочку командной строки, электронные почтовые ящики, технологии сетевого роутинга, DNS и так далее. Всё это очень хардкорные вещи, и глупо считать, что в нашей профессии может быть какая-то разница по гендерному признаку. Кстати, среди бизнес- и системных аналитиков дисбаланс минимален, судя по аудитории конференций и тренингов.
В общем, спасибо вам за всё, и с праздником равноправия! Ну и весны, конечно.💐 🌸 🌷
В языках С и С++ есть такой тип данных — указатель. Это тип переменной, которая хранит типизированный адрес — ссылку на какое-то место в памяти, где _на самом_ деле находится значение. Например, int* хранит ссылку на какую-то область памяти, содержимое которой программа интерпретирует как целое число. Бывают ситуации посложнее — указатели на экземпляры классов или указатели на функции. В C и C++ указатели используются повсеместно, есть специальная арифметика указателей, и с ними же связаны основные ошибки времени исполнения, эксплойты и утечки памяти.
Концепция указателя является основной для программистов. В институте это хорошо видно — кто не смог понять указатели, как правило, быстро отсеиваются, как непригодные для программирования. Ну или быстро переориентируется на Python, Javascript и другие языки, в которых указатели глубоко спрятаны, чтобы не пугать нормальных людей.
Долгое время считалось, что указатели как концепт придумал в 1964 Гарольд "Бад" Лоусон (у нас известен как автор книги "Путешествие по системному ландшафту" — введения в системную инженерию).
На самом деле, первой идею указателя придумала советская и украинская программистка Катерина Ющенко: ещё в 1955 году она создала "Адресный язык программирования" — один из самых первых языков высокого уровня. В Фортране и Алголе 60 ничего похожего не было. Язык был известен только в СССР, поэтому Лоусон "переизобрел" указатели для PL/I.
Катерина Ющенко же была автором одного из первых учебников по программированию, а потом долго занималась теоретическим программированием — особой школой программирования в СССР, сильно связанной с математическим обоснованием программ и научными исследованиями. Получила несколько государственных премий и звание члена-корреспондента Национальной академии наук Украины (в 1979).
И вот что я хочу сказать, и говорю каждый год (2024, 2023) — вклад женщин в нашу индустрию неоценим! Без вас никакого ИТ бы не было, вот что! Самые крутые штуки — первые программы вообще, компиляторы, указатели, оболочку командной строки, электронные почтовые ящики, технологии сетевого роутинга, DNS и так далее. Всё это очень хардкорные вещи, и глупо считать, что в нашей профессии может быть какая-то разница по гендерному признаку. Кстати, среди бизнес- и системных аналитиков дисбаланс минимален, судя по аудитории конференций и тренингов.
В общем, спасибо вам за всё, и с праздником равноправия! Ну и весны, конечно.
Please open Telegram to view this post
VIEW IN TELEGRAM
Про математику в системном анализе и проектировании.
Я вообще топлю за инженерные методы в разработке, в частности — за расчеты. Вы, наверное, могли заметить. Используются математические методы в анализе и проектировании нечасто. Тем ценнее ситуации, когда их можно применить, причем с очевидной пользой.
Рассмотрим такую задачу: мы проектируем интеграцию или API бэкенда, и хотим оценить пиковую нагрузку. Допустим, у нас есть 1000 пользователей, и сценарий их работы такой, что каждый из них за час делает примерно 10 запросов к системе в случайное время. Какой RPS (число запросов в секунду) должен выдерживать сервер?
Если просто 1000*10/(60*60) — число пользователей на число операций деленое на число секунд в одном часе — получится 2.78 запросов/сек.
Но, очевидно, запросы от разных пользователей могут совпадать по времени. Для моделирования такой ситуации нужно использовать пуассоновский процесс, а точнее — распределение Пуассона.
Оно задается жутковатой формулой вероятности:
P(k)=λˆk*eˆ-λ/k!
(да, лямбда в степени k, умноженное на e в степени -λ, деленое на k факториал),
где λ — среднее количество событий за промежуток времени, k — интересующее нас количество событий, P(k) — вероятность того, что k событий произойдут в одну секунду.
В нашем примере λ = 2.78, а k можно разные подставлять:
P(5) = 0.086
P(6) = 0.04
P(7) = 0.016
Для нашего количества событий (10000) эти вероятности очень велики, например, RPS=7 у нас будет 57 раз за час!
А вот P(13) = 0.00001, то есть 1 раз в час. Значит, можно рассчитывать на RPS=13.
Формулу Пуассона можно использовать только для случайных обращений! Если у вас процесс устроен как-то регулярно — нужно использовать анализ сценариев. Например, когда все побежали в сервис после получения оповещения. Или когда в конце часа/дня обязательно нужно что-то сделать (отметиться, отправить коммит), или например все побежали сдавать домашку за 5 минут до дедлайна — тогда процесс не случайный, и нужно анализировать именно эти пики.
Ну а вероятности по формуле Пуассона можно посчитать в одном из калькуляторов, например: https://stattrek.com/online-calculator/poisson (здесь x это k, а λ названа μ), или в Экселе через функцию POISSON.
Применяйте инженерные методы в системном анализе!
Я вообще топлю за инженерные методы в разработке, в частности — за расчеты. Вы, наверное, могли заметить. Используются математические методы в анализе и проектировании нечасто. Тем ценнее ситуации, когда их можно применить, причем с очевидной пользой.
Рассмотрим такую задачу: мы проектируем интеграцию или API бэкенда, и хотим оценить пиковую нагрузку. Допустим, у нас есть 1000 пользователей, и сценарий их работы такой, что каждый из них за час делает примерно 10 запросов к системе в случайное время. Какой RPS (число запросов в секунду) должен выдерживать сервер?
Если просто 1000*10/(60*60) — число пользователей на число операций деленое на число секунд в одном часе — получится 2.78 запросов/сек.
Но, очевидно, запросы от разных пользователей могут совпадать по времени. Для моделирования такой ситуации нужно использовать пуассоновский процесс, а точнее — распределение Пуассона.
Оно задается жутковатой формулой вероятности:
P(k)=λˆk*eˆ-λ/k!
(да, лямбда в степени k, умноженное на e в степени -λ, деленое на k факториал),
где λ — среднее количество событий за промежуток времени, k — интересующее нас количество событий, P(k) — вероятность того, что k событий произойдут в одну секунду.
В нашем примере λ = 2.78, а k можно разные подставлять:
P(5) = 0.086
P(6) = 0.04
P(7) = 0.016
Для нашего количества событий (10000) эти вероятности очень велики, например, RPS=7 у нас будет 57 раз за час!
А вот P(13) = 0.00001, то есть 1 раз в час. Значит, можно рассчитывать на RPS=13.
Формулу Пуассона можно использовать только для случайных обращений! Если у вас процесс устроен как-то регулярно — нужно использовать анализ сценариев. Например, когда все побежали в сервис после получения оповещения. Или когда в конце часа/дня обязательно нужно что-то сделать (отметиться, отправить коммит), или например все побежали сдавать домашку за 5 минут до дедлайна — тогда процесс не случайный, и нужно анализировать именно эти пики.
Ну а вероятности по формуле Пуассона можно посчитать в одном из калькуляторов, например: https://stattrek.com/online-calculator/poisson (здесь x это k, а λ названа μ), или в Экселе через функцию POISSON.
Применяйте инженерные методы в системном анализе!
36 лет назад в этот день, а может быть в предыдущий, инженер Европейского центра ядерных исследований Тим Бернерс-Ли, занимавшийся высокоскоростной шиной FASTBUS для сбора информации с датчиков микрочастиц и разработкой технологий RPC для неё, представил своему руководителю Майку Сендаллу "Предложение по управлению информацией".
Проблемой, которую предлагал решить автор, являлась потеря информации в ЦЕРНе. Номинально у Центра была вертикальная иерархическая структура, но на самом деле в реальной работе всё было очень переплетено, и люди образовывали скорее временную "паутину" связей, которая к тому же постоянно менялась. Информация об этих связях нигде не хранилась — ну, разве что, в каких-то редких случайных письмах, а в основном — передавалась в коридорных разговорах.
Часто это приводило к тому, что две соседние лаборатории работали над дублирующими друг друга проектами, а разобраться в том, кто использует конкретную установку или датчик, и чей эксперимент слетит, если их немного перенастроить — не представлялось возможным. А когда что-то ломалось, требовалось просто детективное расследование причин и технических деталей.
Примеры типичных вопросов, которые постоянно возникали:
- Где используется этот модуль?
- Кто написал этот код? Где он работает?
- Какие документы есть по этой концепции?
- Какие лаборатории участвуют в этом проекте?
- Какие системы зависят от этого сервиса?
- Какие документы ссылаются на этот?
Предлагалось сделать перелинкованную информационную систему, в которой бы хранилась информация о:
- Людях
- Программных модулях
- Группах людей
- Проектах
- Концепциях
- Документах
- Типах оборудования
- Конкретные экземпляры оборудования
а связи имели бы типы:
- A "зависит от" B
- A "часть" B
- A "сделал" B
- A "ссылается на" B
- A "использует" B
- A "является примером" B
и т.п.
Вся система должна обладать следующими свойствами:
- поддерживать удаленный доступ
- поддерживать разные типы клиентов
- быть децентрализованной
- предоставлять доступ к информации из существующих БД в виде перелинкованных данных
- разделять общедоступные и частные ссылки
- показывать текст (в первой версии)
- иметь встроенные средства анализа данных (разных срезов данных и ссылок, поиск пропусков и т.п.)
- поддерживать "живые" ссылки, данные по которым могут меняться
Это всё должно было помочь хранить актуальную информацию по проектам, быстро извлекать нужные документы и вести учет личных навыков людей (по привязкам людей к проектам, софту и оборудованию, с которым они работали или которое создавали).
По оценкам Тима Бернерса-Ли, первая версия такой системы могла бы быть создана двумя людьми примерно за 6-12 месяцев. Заодно можно было бы попробовать новый способ разработки — объектно-ориентированный.
Майк Сендалл поставил резолюцию "Расплывчато, но любопытно" и дал добро на эксперимент. Они взяли свежий компьютер NeXT Cube, только что выпущенный новой компанией Стива Джобса, которого выгнали из Apple, и через год правда сделали эту систему. Что из этого вышло, вы знаете — мы в эту систему каждый день заходим, посмотреть на котиков.
Ну а у меня вчера тоже был день рождения, буду считать себя астральным близнецом Веба, правда у нас разница в 10 лет 😹
Проблемой, которую предлагал решить автор, являлась потеря информации в ЦЕРНе. Номинально у Центра была вертикальная иерархическая структура, но на самом деле в реальной работе всё было очень переплетено, и люди образовывали скорее временную "паутину" связей, которая к тому же постоянно менялась. Информация об этих связях нигде не хранилась — ну, разве что, в каких-то редких случайных письмах, а в основном — передавалась в коридорных разговорах.
Часто это приводило к тому, что две соседние лаборатории работали над дублирующими друг друга проектами, а разобраться в том, кто использует конкретную установку или датчик, и чей эксперимент слетит, если их немного перенастроить — не представлялось возможным. А когда что-то ломалось, требовалось просто детективное расследование причин и технических деталей.
Примеры типичных вопросов, которые постоянно возникали:
- Где используется этот модуль?
- Кто написал этот код? Где он работает?
- Какие документы есть по этой концепции?
- Какие лаборатории участвуют в этом проекте?
- Какие системы зависят от этого сервиса?
- Какие документы ссылаются на этот?
Предлагалось сделать перелинкованную информационную систему, в которой бы хранилась информация о:
- Людях
- Программных модулях
- Группах людей
- Проектах
- Концепциях
- Документах
- Типах оборудования
- Конкретные экземпляры оборудования
а связи имели бы типы:
- A "зависит от" B
- A "часть" B
- A "сделал" B
- A "ссылается на" B
- A "использует" B
- A "является примером" B
и т.п.
Вся система должна обладать следующими свойствами:
- поддерживать удаленный доступ
- поддерживать разные типы клиентов
- быть децентрализованной
- предоставлять доступ к информации из существующих БД в виде перелинкованных данных
- разделять общедоступные и частные ссылки
- показывать текст (в первой версии)
- иметь встроенные средства анализа данных (разных срезов данных и ссылок, поиск пропусков и т.п.)
- поддерживать "живые" ссылки, данные по которым могут меняться
Это всё должно было помочь хранить актуальную информацию по проектам, быстро извлекать нужные документы и вести учет личных навыков людей (по привязкам людей к проектам, софту и оборудованию, с которым они работали или которое создавали).
По оценкам Тима Бернерса-Ли, первая версия такой системы могла бы быть создана двумя людьми примерно за 6-12 месяцев. Заодно можно было бы попробовать новый способ разработки — объектно-ориентированный.
Майк Сендалл поставил резолюцию "Расплывчато, но любопытно" и дал добро на эксперимент. Они взяли свежий компьютер NeXT Cube, только что выпущенный новой компанией Стива Джобса, которого выгнали из Apple, и через год правда сделали эту систему. Что из этого вышло, вы знаете — мы в эту систему каждый день заходим, посмотреть на котиков.
Ну а у меня вчера тоже был день рождения, буду считать себя астральным близнецом Веба, правда у нас разница в 10 лет 😹
О, вот это самое крутое выступление за последние несколько лет, которое я слышал на конференциях! Зал был битком, там видно. И ещё это интерактив!
Сама тема вообще не специфичная для аналитика — это в чистом виде практикум по противодействию манипуляторам на работе. А может быть, как раз для аналитиков будет актуально — у нас вечно не совсем четко определены границы рабочих обязанностей, поэтому навешать лишнего забесплатно — это у нас постоянно.
В видео даны очень простые (а главное — точно работающие!) техники. Вот только применить их сложно, нужно специально регулярно тренироваться. Шпаргалку что ли себе написать 😂
Сама тема вообще не специфичная для аналитика — это в чистом виде практикум по противодействию манипуляторам на работе. А может быть, как раз для аналитиков будет актуально — у нас вечно не совсем четко определены границы рабочих обязанностей, поэтому навешать лишнего забесплатно — это у нас постоянно.
В видео даны очень простые (а главное — точно работающие!) техники. Вот только применить их сложно, нужно специально регулярно тренироваться. Шпаргалку что ли себе написать 😂
Forwarded from Flow — конференция про системный и бизнес-анализ
#видеозаписи
Сегодня открываем запись, где первый интересный тезис звучит ещё до начала доклада: «Интроверту полезно обучаться коммуникации, потому что эффективнее общаешься, тем быстрее сможешь закончить разговор перейти к работе».
YouTube | VK Видео
Скачать презентацию с сайта Flow
Сегодня открываем запись, где первый интересный тезис звучит ещё до начала доклада: «Интроверту полезно обучаться коммуникации, потому что эффективнее общаешься, тем быстрее сможешь закончить разговор перейти к работе».
YouTube | VK Видео
Скачать презентацию с сайта Flow
Накатал сегодня мощный пост про цифровую трансформацию, скопирую сюда тоже. Не то чтобы аналитиков часто спрашивают про ЦТ (что, на самом деле, странно), но вдруг кому-то придётся этим заниматься. Вот, знайте, как оно должно выглядеть.
Задело меня то, что многие говорят о недостаточной определенности понятия цифровой трансформации. Вроде бы все хотят, но никто толком не знает, что это такое и как узнать, что оно у тебя есть (или нет).
Я не понимаю всех этих разговоров про неопределенность понятия цифровой трансформации. Вероятно, их ведут те, кто ни разу в глаза не видел трансформированной организации. Мне повезло, я видел (я и ускорение поставки софта в 6-10 раз видел, как обещает Сазерленд, мне вообще повезло).
Так вот, признак цифровой трансформации в организации - это рефлекторное движение каждого сотрудника, столкнувшегося с какой-то проблемой, к написанию кода, решающего эту проблему, или иным способом внесения изменения в цифровую систему, на которой работает организация. Ну, просто это первое, что в голову приходит.
В этом смысле у нас организации бывают образовательно трансформированные (решение любой проблемы = послать сотрудников на обучение, это практически все школы так работают), или бихевиористически-трансформированные (решение любой проблемы = изменение KPI), или маркетингово-трансформированные (решение любой проблемы = поменять маркетинг/продажи).
Конечно, это требует определенной инфраструктуры.
Во-первых, организация должна работать на основе ИТ-системы. Ну без этого никак, к сожалению. Можно установить тонны компьютеров, но если нет единой системы, в которую они объединены - нет носителя деятельности.
Во-вторых, эта ИТ-система должна быть легко модернизируема, расширяема и перестраиваема. Поэтому agile (быстрая поставка), ИИ (программирование без программирования) и открытые системы.
В-третьих, люди должны уметь программировать, создавать и изменять ИТ-системы. Не отдельные люди, которые где-то там в ИТ-департаменте, а все, хотя бы до уровня начальников отделов. В той организации, которую я считаю примером, так и было - начальник операционного управления программист, начальник клиентского - программист, и так далее. Хотя сама организация работала в сфере финансов. И половина сотрудников - в чистом виде ИТ: технологи, разработчки, тестировщики, эксплуатация. Если нужны данные - БД открыты, можно вытащить. Если нужно что-то автоматизировать - есть точки расширения и API, на которые можно повесить скрипты. Если нужно хранить информацию внутри подразделения - создается база данных, а не тысячи экселек или текстовых документов. Если какая-то операция повторяется более трёх раз - она автоматизируется. Вот это - цифровая трансформация! Если у вас не так, значит, у вас что угодно, только не ЦТ.
Да, есть проблемы - где же нам взять столько программистов, да чтобы они работали не программистами. Это разговоры в пользу бедных. Это примерно соответствует вопросу 100-130-летней давности - а где же нам взять столько грамотных людей. Ну академик Ершов ещё в 1981 сказал, что программирование - это вторая грамотность. Вот. Ищите и нанимайте грамотных людей. Без этого никак.
Всем ли нужна цифровая трансформация? Наверное, нет, издержки довольно высоки. Но тогда и не надо делать вид, что вы её хотите, и в стратегические программы вписывать под видом ЦТ закупку новых компьютеров.
Задело меня то, что многие говорят о недостаточной определенности понятия цифровой трансформации. Вроде бы все хотят, но никто толком не знает, что это такое и как узнать, что оно у тебя есть (или нет).
Я не понимаю всех этих разговоров про неопределенность понятия цифровой трансформации. Вероятно, их ведут те, кто ни разу в глаза не видел трансформированной организации. Мне повезло, я видел (я и ускорение поставки софта в 6-10 раз видел, как обещает Сазерленд, мне вообще повезло).
Так вот, признак цифровой трансформации в организации - это рефлекторное движение каждого сотрудника, столкнувшегося с какой-то проблемой, к написанию кода, решающего эту проблему, или иным способом внесения изменения в цифровую систему, на которой работает организация. Ну, просто это первое, что в голову приходит.
В этом смысле у нас организации бывают образовательно трансформированные (решение любой проблемы = послать сотрудников на обучение, это практически все школы так работают), или бихевиористически-трансформированные (решение любой проблемы = изменение KPI), или маркетингово-трансформированные (решение любой проблемы = поменять маркетинг/продажи).
Конечно, это требует определенной инфраструктуры.
Во-первых, организация должна работать на основе ИТ-системы. Ну без этого никак, к сожалению. Можно установить тонны компьютеров, но если нет единой системы, в которую они объединены - нет носителя деятельности.
Во-вторых, эта ИТ-система должна быть легко модернизируема, расширяема и перестраиваема. Поэтому agile (быстрая поставка), ИИ (программирование без программирования) и открытые системы.
В-третьих, люди должны уметь программировать, создавать и изменять ИТ-системы. Не отдельные люди, которые где-то там в ИТ-департаменте, а все, хотя бы до уровня начальников отделов. В той организации, которую я считаю примером, так и было - начальник операционного управления программист, начальник клиентского - программист, и так далее. Хотя сама организация работала в сфере финансов. И половина сотрудников - в чистом виде ИТ: технологи, разработчки, тестировщики, эксплуатация. Если нужны данные - БД открыты, можно вытащить. Если нужно что-то автоматизировать - есть точки расширения и API, на которые можно повесить скрипты. Если нужно хранить информацию внутри подразделения - создается база данных, а не тысячи экселек или текстовых документов. Если какая-то операция повторяется более трёх раз - она автоматизируется. Вот это - цифровая трансформация! Если у вас не так, значит, у вас что угодно, только не ЦТ.
Да, есть проблемы - где же нам взять столько программистов, да чтобы они работали не программистами. Это разговоры в пользу бедных. Это примерно соответствует вопросу 100-130-летней давности - а где же нам взять столько грамотных людей. Ну академик Ершов ещё в 1981 сказал, что программирование - это вторая грамотность. Вот. Ищите и нанимайте грамотных людей. Без этого никак.
Всем ли нужна цифровая трансформация? Наверное, нет, издержки довольно высоки. Но тогда и не надо делать вид, что вы её хотите, и в стратегические программы вписывать под видом ЦТ закупку новых компьютеров.
Я очень люблю, когда мне участники тренингов задают разные дополнительные вопросы, пусть даже косвенно относящиеся к теме. (Кстати, не только участники тренингов — вы тоже можете меня спрашивать, например в чате к этому каналу).
Вот, например, вопрос про лучшие практики построения админок. На удивление, толковых публикаций на эту тему мало, в основном либо пустые SEO-тексты, либо реклама своих фреймворков/шаблонов. И пишут чаще всего про дизайн, а не про функции.
К хорошим (но очень коротким!) относятся рекомендации от дизайнеров британских правительственных сервисов:
https://designnotes.blog.gov.uk/2015/09/25/design-principles-for-admin-interfaces/ , но это редкость, да и мало там инсайтов.
Поэтому я взял на себя смелость собрать несколько идей и принципов, с которыми лично сталкивался. Надеюсь, будет вам полезно, если вы занимаетесь админками. Не значит, что вам все эти практики нужны, но просто знайте про них, вдруг пригодятся.
Итак, что я узнал про админки за 25 лет:
— Общий обзор: вытащите на главную страницу админки несколько самых актуальных показателей, последних событий и алертов, чтобы сразу было понятно, что в системе происходит и за что браться в первую очередь;
— Админы — разные. Дайте им возможность настроить админку лично для себя. Скорее всего, ваши админы выполняют разные задачи, поэтому хорошо бы предусмотреть виджеты и возможность вытащить на первую страницу разные данные и действия;
— Разные и многоуровневые права доступа, а не один админ со всеми правами. Админы бывают разные, и в больших системах доступ админов может быть очень гранулировано нарезан — как по доступу к разным типам данных и разным действиям, так и по содержанию данных. Например, по категориям клиентов, или как у меня было на учебной платформе: админ учебных групп отдельного вуза, админ одного курса, админ вуза с доступом ко всем курсам, админ всех студентов, админ всех курсов, админ всей системы. Только на назначение прав доступа три роли несовмещаемые должны быть, в идеале: один создает группы с правами, другой заводит пользователей, третий назначает пользователей в группы по идентификаторам. Чтобы один админ не мог создать супер-пользователя.
— Журналирование всех действий админа (в том числе на просмотр, фильтры и поиск; в том числе — с оповещениями более старшего админа о подозрительных действиях);
— Поиск, фильтры и сортировка (в админке бывают большие объемы данных);
— Серьезные подтверждения для опасных необратимых действий (не кнопка "Да, продожить", а в виде ручного ввода длинной строки текста, "Я понимаю, что я собираюсь удалить бэкап базы данных, и это действие невозможно отменить" или согласия старшего админа);
— Возможность отменить действия. Вообще сохранение истории и возможность просмотра предыдущих состояний (и связей!) объекта.
— "Мягкое удаление" везде, где возможно (если это не противоречит регуляторным требованиям). Следите также за каскадным удалением, оно опасно!
— Функции для пакетных операций! Когда можно выделить несколько элементов и с ними что-то сделать одним действием.
— Инлайн-редактирование прямо в строке таблицы. Часто бывает трудно реализовать чисто технически, но в некоторых случаях сильно упрощает работу.
— Связки всего со всем и переходы — когда можно легко из одного объекта в другой связанный провалиться, или перейти от общего к деталям (drill down) и вернуться обратно.
— Подсветка тревожных и подозрительных событий (когда они ещё не стали сбоем и проблемой). Например,
— Принцип "один экран — одно действие" в админках не работает. Там наоборот — лучше побольше контекстных действий уместить на экране.
— Ширина экрана и плотность информации. Используйте экран по полной! В админках не очень нужен дизайнерский "воздух", чаще важнее число отображаемых элементов.
— Адрес админки. Должен быть неочевидным! Никаких /admin и тому подобного. Ещё можно ограничить IP-адреса, с которых можно заходить в админку.
Как-то так, что сходу вспомнилось. Если есть ещё идеи, или вы сами с чем-то сталкивались — пишите в комментарии!
Вот, например, вопрос про лучшие практики построения админок. На удивление, толковых публикаций на эту тему мало, в основном либо пустые SEO-тексты, либо реклама своих фреймворков/шаблонов. И пишут чаще всего про дизайн, а не про функции.
К хорошим (но очень коротким!) относятся рекомендации от дизайнеров британских правительственных сервисов:
https://designnotes.blog.gov.uk/2015/09/25/design-principles-for-admin-interfaces/ , но это редкость, да и мало там инсайтов.
Поэтому я взял на себя смелость собрать несколько идей и принципов, с которыми лично сталкивался. Надеюсь, будет вам полезно, если вы занимаетесь админками. Не значит, что вам все эти практики нужны, но просто знайте про них, вдруг пригодятся.
Итак, что я узнал про админки за 25 лет:
— Общий обзор: вытащите на главную страницу админки несколько самых актуальных показателей, последних событий и алертов, чтобы сразу было понятно, что в системе происходит и за что браться в первую очередь;
— Админы — разные. Дайте им возможность настроить админку лично для себя. Скорее всего, ваши админы выполняют разные задачи, поэтому хорошо бы предусмотреть виджеты и возможность вытащить на первую страницу разные данные и действия;
— Разные и многоуровневые права доступа, а не один админ со всеми правами. Админы бывают разные, и в больших системах доступ админов может быть очень гранулировано нарезан — как по доступу к разным типам данных и разным действиям, так и по содержанию данных. Например, по категориям клиентов, или как у меня было на учебной платформе: админ учебных групп отдельного вуза, админ одного курса, админ вуза с доступом ко всем курсам, админ всех студентов, админ всех курсов, админ всей системы. Только на назначение прав доступа три роли несовмещаемые должны быть, в идеале: один создает группы с правами, другой заводит пользователей, третий назначает пользователей в группы по идентификаторам. Чтобы один админ не мог создать супер-пользователя.
— Журналирование всех действий админа (в том числе на просмотр, фильтры и поиск; в том числе — с оповещениями более старшего админа о подозрительных действиях);
— Поиск, фильтры и сортировка (в админке бывают большие объемы данных);
— Серьезные подтверждения для опасных необратимых действий (не кнопка "Да, продожить", а в виде ручного ввода длинной строки текста, "Я понимаю, что я собираюсь удалить бэкап базы данных, и это действие невозможно отменить" или согласия старшего админа);
— Возможность отменить действия. Вообще сохранение истории и возможность просмотра предыдущих состояний (и связей!) объекта.
— "Мягкое удаление" везде, где возможно (если это не противоречит регуляторным требованиям). Следите также за каскадным удалением, оно опасно!
— Функции для пакетных операций! Когда можно выделить несколько элементов и с ними что-то сделать одним действием.
— Инлайн-редактирование прямо в строке таблицы. Часто бывает трудно реализовать чисто технически, но в некоторых случаях сильно упрощает работу.
— Связки всего со всем и переходы — когда можно легко из одного объекта в другой связанный провалиться, или перейти от общего к деталям (drill down) и вернуться обратно.
— Подсветка тревожных и подозрительных событий (когда они ещё не стали сбоем и проблемой). Например,
— Принцип "один экран — одно действие" в админках не работает. Там наоборот — лучше побольше контекстных действий уместить на экране.
— Ширина экрана и плотность информации. Используйте экран по полной! В админках не очень нужен дизайнерский "воздух", чаще важнее число отображаемых элементов.
— Адрес админки. Должен быть неочевидным! Никаких /admin и тому подобного. Ещё можно ограничить IP-адреса, с которых можно заходить в админку.
Как-то так, что сходу вспомнилось. Если есть ещё идеи, или вы сами с чем-то сталкивались — пишите в комментарии!
HTML Embed Code: