Стартовали Winter Analytical Weekend! Максим Цепков ведёт текстовую трансляцию впечатлений от докладов в своём канале: https://news.1rj.ru/str/mtsepkov
Telegram
Максим Цепков
Автор @MaximTsepkov, сайт http://mtsepkov.org - менеджмент самоуправления, soft skill модели, конференции.
Forwarded from Максим Цепков (Maxim Tsepkov)
Сегодня - на http://waw-conf.ru мой доклад - открывающий, о будущам общества, ИТ и аналитиков. Презентация - у меня на сайте https://mtsepkov.org/Future-WAW
Forwarded from Максим Цепков (Maxim Tsepkov)
#wawconf Алишер Умаров. Аналитик 2.0 - Шестирукий Шива или как выжить в современных реалиях с ИИ.
Основной тезис: ИИ может стать помощником: переписывать текст в заданном формате, например, OpenAI; разбираться в коде или настройках конфигураций, писать SQL-запросы, рисовать диаграммы и так далее.
Это несложно, и сильно повышает производительность, есть замеры. До 70% на шаблонных задачах. 50 в среднем экономии. Быстрое кросс-ревью. Ускорение *3 при неполной или отсутствующей документации: проект начинался, сделали как-то поговори об этом с разработчиками и узнай... Как оценивал эффективность? У него было несколько команд, в разных областях. Была оценка, плюс опыт аудита - для этого у него была моделька для оценки артефактов. И он оценивал изменения в работе команды до и после.
В конце Байкин добавил кейс. Нужно было разобраться с HR. Попросил ИИ написать типовые процессы, детализировать, придумать KPI. Послал, HR-директор оценил: о, какие хорошие!
И в ответ Алишер добавил использование: прослушай встречу 2 часа, расскажи что важное. Потом спросить про пояснения. Провалидируй требования.
Что нужно для этого? Главное - надо уметь ставить техническую задачу, чтобы понял ИИ. Он не домысливает, вернее, часто домысливает неверно. Очевидная вещь в SQL - синтаксис, ограничения, что хотите. Русский язык технически сложен, сложнее английского или испанского, там много ловушек неоднозначности - надо разжевывать, писать структурно. Это полезно не только для ИИ.
Риски ИИ известны: невалидированные результаты, неправильная постановка задачи, ограниченность данных обучения (ChatGPT знает состояние 21 года).
Зачем это надо? Аналитик может стать core-участникам команды.
Во всех вакансиях пишут полотенца текста, по которым аналитик должен понимать вообще все. Почему работодатель требует все это? Потому что часто источник требований - имеющаяся система. Посмотреть на базу данных, посмотреть на формы, код и так далее. И это надо уметь. Можно с помощью ИИ - и он реально поможет.
А вот умение говорить со всеми интересантами - это пока самому, отдельная компетенция.
Как делать, чтобы не утекало? Сбер и ВТБ - стали делать свои модельки. Еще можно обезличивать - как датасеты, ТЗ тоже можно обезличивать. И можно обезличивать код, если его надо прочитать. Еще можно договориться, что поднимаем в своем контуре.
Основной тезис: ИИ может стать помощником: переписывать текст в заданном формате, например, OpenAI; разбираться в коде или настройках конфигураций, писать SQL-запросы, рисовать диаграммы и так далее.
Это несложно, и сильно повышает производительность, есть замеры. До 70% на шаблонных задачах. 50 в среднем экономии. Быстрое кросс-ревью. Ускорение *3 при неполной или отсутствующей документации: проект начинался, сделали как-то поговори об этом с разработчиками и узнай... Как оценивал эффективность? У него было несколько команд, в разных областях. Была оценка, плюс опыт аудита - для этого у него была моделька для оценки артефактов. И он оценивал изменения в работе команды до и после.
В конце Байкин добавил кейс. Нужно было разобраться с HR. Попросил ИИ написать типовые процессы, детализировать, придумать KPI. Послал, HR-директор оценил: о, какие хорошие!
И в ответ Алишер добавил использование: прослушай встречу 2 часа, расскажи что важное. Потом спросить про пояснения. Провалидируй требования.
Что нужно для этого? Главное - надо уметь ставить техническую задачу, чтобы понял ИИ. Он не домысливает, вернее, часто домысливает неверно. Очевидная вещь в SQL - синтаксис, ограничения, что хотите. Русский язык технически сложен, сложнее английского или испанского, там много ловушек неоднозначности - надо разжевывать, писать структурно. Это полезно не только для ИИ.
Риски ИИ известны: невалидированные результаты, неправильная постановка задачи, ограниченность данных обучения (ChatGPT знает состояние 21 года).
Зачем это надо? Аналитик может стать core-участникам команды.
Во всех вакансиях пишут полотенца текста, по которым аналитик должен понимать вообще все. Почему работодатель требует все это? Потому что часто источник требований - имеющаяся система. Посмотреть на базу данных, посмотреть на формы, код и так далее. И это надо уметь. Можно с помощью ИИ - и он реально поможет.
А вот умение говорить со всеми интересантами - это пока самому, отдельная компетенция.
Как делать, чтобы не утекало? Сбер и ВТБ - стали делать свои модельки. Еще можно обезличивать - как датасеты, ТЗ тоже можно обезличивать. И можно обезличивать код, если его надо прочитать. Еще можно договориться, что поднимаем в своем контуре.
👍14
Зимние аналитические выходные (WAW-conf) получились, и, кажется, получились огненными!
Давно я не слышал столько восторженных отзывов. И докладчики, и программа, и мастер-классы, и дискуссии, и кулуары, и афтепати, и, конечно, участники — всё сложилось, как пазл, несмотря на отдельные косяки и шероховатости.
Очень мощная и заряженная движуха получилась, с нетворкингом, горящими глазами и вдохновением, как минимум, до лета.
В общем, первый запуск прошёл отлично, настоящий праздник среди зимы
❄️🔥 🎆
Давно я не слышал столько восторженных отзывов. И докладчики, и программа, и мастер-классы, и дискуссии, и кулуары, и афтепати, и, конечно, участники — всё сложилось, как пазл, несмотря на отдельные косяки и шероховатости.
Очень мощная и заряженная движуха получилась, с нетворкингом, горящими глазами и вдохновением, как минимум, до лета.
В общем, первый запуск прошёл отлично, настоящий праздник среди зимы
❄️
Please open Telegram to view this post
VIEW IN TELEGRAM
👏13👍2🔥2🥰2
На WAW я проводил мастер-класс по проектированию процесса разработки при помощи карт состояний Essence.
Карты состояний можно использовать для разных задач, например — выяснения текущего состояния проекта или синхронизации понимания в команде.
Мы пробовали спроектировать процесс сначала по вехам (то есть, в какие моменты мы останавливаемся и принимаем решение — идём дальше или нет?), потом в деталях: какие артефакты нам нужны и какие дела нужно сделать, чтобы прийти к этой вехе.
У двух команд ситуации отличались. В первом кейсе была веб-студия, заказное ПО. Во втором — внутренняя разработка или даже выбор готового решения.
И вот вроде делать в любом проекте нужно одно и то же: выявить стейкхолдеров; понять, что им нужно; зафиксировать; продумать решение; сделать его; а для этого — собрать команду и выполнить работу.
Это как раз объекты ядра из Essence: стейкхолдер, потребность, требования, система, работа, команда, технология работы. Так называемые Альфы. За состоянием чего нужно следить в любом проекте.
Но вот группировка и временные промежутки между разными состояниями ключевых альф в каждом проекте разные.
Так произошло и у нас на МК: у веб-студии процесс получился равномерный, это видно на флипчарте — сначала пресейл, потом ТЗ и дизайн, потом собираем команду и начинаем разрабатывать, потом сдаем и запускаем. Такой почти классический водопад.
Для внутренней разработки карточки сгруппированы по-другому: чтобы вообще что-то начать делать с системой, нужно сначала понять потребности. Поэтому состояния альф "стейкхолдеры" и "потребность" сгруппированы в начале проекта, потом идут требования, а потом — выбор системы из тех, что есть на рынке, или уж своя разработка.
Мы не дошли до альф команды и работы, там интересно — команду нужно было бы пересобирать после выбора: делать своё или брать готовое, то есть начальные состояния команды были бы где-то в середине.
Получилось довольно наглядно, и это всего лишь за один час! А за день можно и весь процесс спроектировать.
Карты состояний можно использовать для разных задач, например — выяснения текущего состояния проекта или синхронизации понимания в команде.
Мы пробовали спроектировать процесс сначала по вехам (то есть, в какие моменты мы останавливаемся и принимаем решение — идём дальше или нет?), потом в деталях: какие артефакты нам нужны и какие дела нужно сделать, чтобы прийти к этой вехе.
У двух команд ситуации отличались. В первом кейсе была веб-студия, заказное ПО. Во втором — внутренняя разработка или даже выбор готового решения.
И вот вроде делать в любом проекте нужно одно и то же: выявить стейкхолдеров; понять, что им нужно; зафиксировать; продумать решение; сделать его; а для этого — собрать команду и выполнить работу.
Это как раз объекты ядра из Essence: стейкхолдер, потребность, требования, система, работа, команда, технология работы. Так называемые Альфы. За состоянием чего нужно следить в любом проекте.
Но вот группировка и временные промежутки между разными состояниями ключевых альф в каждом проекте разные.
Так произошло и у нас на МК: у веб-студии процесс получился равномерный, это видно на флипчарте — сначала пресейл, потом ТЗ и дизайн, потом собираем команду и начинаем разрабатывать, потом сдаем и запускаем. Такой почти классический водопад.
Для внутренней разработки карточки сгруппированы по-другому: чтобы вообще что-то начать делать с системой, нужно сначала понять потребности. Поэтому состояния альф "стейкхолдеры" и "потребность" сгруппированы в начале проекта, потом идут требования, а потом — выбор системы из тех, что есть на рынке, или уж своя разработка.
Мы не дошли до альф команды и работы, там интересно — команду нужно было бы пересобирать после выбора: делать своё или брать готовое, то есть начальные состояния команды были бы где-то в середине.
Получилось довольно наглядно, и это всего лишь за один час! А за день можно и весь процесс спроектировать.
👍24
Конец зимы получается очень горячим! 🔥
Не успел опомниться от Winter Analytical Weekend, а скоро уже и весенний Flow, где я эксперт и член ПК.
Программа Flow готова уже на 100%, это будет интенсив в онлайне 12 марта, и будет много докладов про самые практические вещи в работе аналитика: про требования, интеграции и архитектуру. Ну и про ИИ, куда же теперь без него!
Часть программы уже на сайте, а цена более чем демократичная.
Вероятно, я там буду в качестве эксперта представлять некоторые доклады, а может даже и вести дискуссию в главной студии. Хороший подарок прямо к моему дню рождения!🎁
А ещё лично меня можно увидеть в марте на классическом курсе-боевике "Системный анализ. Разработка требований в ИТ-проектах" от школы системного анализа и проектирования Systems.Education.
Курс, на самом деле, просто ставит голову системного аналитика на место и даёт четкий и последовательный план работы над проектом требований к новой системе. Как писать требования, когда применять use cases, как думать про НФТ и зачем нужна контекстная диаграмма и модель предметной области — всё расскажу. Идёт уже больше 10 лет, практически живая легенда, а не курс! Буду вести его очно в Москве 21-23 марта.
А в апреле будет его сиквел: разработка проекта интеграции, для опытных аналитиков — "Основы проектирования интеграций ИТ-систем". Тут мы разбираемся с интеграциями систем во всех видах, от обмена файлами до брокеров сообщений, и, конечно, особенно подробно с проектированием REST API. Это уже апрель, тоже очно в Москве, с 4 по 6.
Потом я до лета ухожу в отпуск, и буду работать только точечно с людьми, которые у меня консультируются и проходят менторинг (есть и такая опция!)
А ещё в ближайшее время будет запускается несколько курсов от хороших друзей, о чем напишу на неделе, не переключайтесь! 📺👀
Не успел опомниться от Winter Analytical Weekend, а скоро уже и весенний Flow, где я эксперт и член ПК.
Программа Flow готова уже на 100%, это будет интенсив в онлайне 12 марта, и будет много докладов про самые практические вещи в работе аналитика: про требования, интеграции и архитектуру. Ну и про ИИ, куда же теперь без него!
Часть программы уже на сайте, а цена более чем демократичная.
Вероятно, я там буду в качестве эксперта представлять некоторые доклады, а может даже и вести дискуссию в главной студии. Хороший подарок прямо к моему дню рождения!
А ещё лично меня можно увидеть в марте на классическом курсе-боевике "Системный анализ. Разработка требований в ИТ-проектах" от школы системного анализа и проектирования Systems.Education.
Курс, на самом деле, просто ставит голову системного аналитика на место и даёт четкий и последовательный план работы над проектом требований к новой системе. Как писать требования, когда применять use cases, как думать про НФТ и зачем нужна контекстная диаграмма и модель предметной области — всё расскажу. Идёт уже больше 10 лет, практически живая легенда, а не курс! Буду вести его очно в Москве 21-23 марта.
А в апреле будет его сиквел: разработка проекта интеграции, для опытных аналитиков — "Основы проектирования интеграций ИТ-систем". Тут мы разбираемся с интеграциями систем во всех видах, от обмена файлами до брокеров сообщений, и, конечно, особенно подробно с проектированием REST API. Это уже апрель, тоже очно в Москве, с 4 по 6.
Потом я до лета ухожу в отпуск, и буду работать только точечно с людьми, которые у меня консультируются и проходят менторинг (есть и такая опция!)
А ещё в ближайшее время будет запускается несколько курсов от хороших друзей, о чем напишу на неделе, не переключайтесь! 📺
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15
Продолжу про чек-листы из Essence (из ГОСТ 57195).
Я, когда не забываю, обязательно включаю формулировки из них в план проекта. Эти чек-листы "капитанские", но, как любой чек-лист, почти всегда выполняются, но если вдруг один пункт не выполняется — это окупает все предыдущие разы.
Вот, например, чек-листы к "Требованиям":
Состояние "Сформулированы":
✅ Первоначальная группа заинтересованных сторон согласна, что система должна быть произведена.
✅ Заинтересованные стороны, которые будут использовать новую систему, идентифицированы.
✅ Заинтересованные стороны, которые профинансируют начальную работу по созданию новой системы, идентифицированы.
✅ Существует очевидная возможность, которую реализует новая система.
Тут вроде всё очевидно, нужно понять — что делаем, зачем, кто будет пользоваться и кто оплатит.
Состояние "Требования ограничены":
✅ Заинтересованные стороны, вовлеченные в разработку новой системы, идентифицированы.
✅ Заинтересованные стороны согласны с назначением новой системы.
✅ Определено, что будет считаться положительным эффектом от внедрения новой системы.
✅ Заинтересованные стороны имеют одинаковое понимание пределов предлагаемого решения.
✅ Технология описания требований согласована.
✅ Механизмы управления требованиями есть в наличии.
✅ Приоритезационная схема ясна.
✅ Ограничения определены и приняты во внимание.
✅ Допущения ясно сформулированы.
Вот тут уже начинаются проблемы. Положительный эффект? Далеко не в каждом проекте удается зафиксировать. Пределы решения? (Можно ещё перевести, как границы). Не всегда фиксируют. Да ещё чтобы все их поняли?
Технология описания. То есть, мы в каком виде требования формулируем? User story? JTBD? Классические ФТ?
Механизмы управления требованиями? Это вообще что?
и т.д.
Конечно, можно прожить и без этого. Тут как с дефектами: само по себе наличие дефектов в системе ещё не означает, что это дефект проявится. То, что вы не поставили галочку в чек-листе, ещё не значит, что проект обязательно провалится. Но это риск. В стандарте этого нет, но к каждому пункту можно приписать набор рисков, которые могут сработать, если это состояние не достигнуто.
Отсутствие приоритезационной схемы может повлечь впихивание в продукт функций по принципу "приоритет у того, кто громче кричит". Отсутствие механизмов управления приводит к проблемам с устаревшими требованиями и соотнесением релизов с набором требований.
Про непроговоренные со стейкхолдерами пределы, допущения и ограничения даже не буду говорить, не люблю ужастики.
В общем, всё это может не выстрелить, но в какой-то момент — особенно когда вы руководите системным анализом не одном проекте, а, скажем, в пяти-шести.
Я так в один момент обнаружил, что у меня в проекте есть в каком-то виде все 30 процессов, описанных в ISO 12207, и за всеми нужно приглядывать, и хорошо бы их как-то разложить на людей, а не контролировать каждый самому. Первый признак инженерной деятельности — систематизация.
Возвращаясь к чек-листам: замечательные пункты
✅ Происхождение требований ясно.
✅ Обоснование требований ясно.
Вот тут, боюсь, 80% проектов и срежется. Откуда вообще эти требования взялись? Ну, это же "по умолчанию". Это "система так требует". "Эти требования мы всегда вписываем". "Нам на курсах сказали, что так надо". "Это было в примере". "Заказчик сказал, что это нужно обязательно". Нет, я понимаю, что никогда нет времени разбираться с этим, потому что и так часов мало. Но тогда какие риски мы принимаем и не учитываем?
Я, когда не забываю, обязательно включаю формулировки из них в план проекта. Эти чек-листы "капитанские", но, как любой чек-лист, почти всегда выполняются, но если вдруг один пункт не выполняется — это окупает все предыдущие разы.
Вот, например, чек-листы к "Требованиям":
Состояние "Сформулированы":
✅ Первоначальная группа заинтересованных сторон согласна, что система должна быть произведена.
✅ Заинтересованные стороны, которые будут использовать новую систему, идентифицированы.
✅ Заинтересованные стороны, которые профинансируют начальную работу по созданию новой системы, идентифицированы.
✅ Существует очевидная возможность, которую реализует новая система.
Тут вроде всё очевидно, нужно понять — что делаем, зачем, кто будет пользоваться и кто оплатит.
Состояние "Требования ограничены":
✅ Заинтересованные стороны, вовлеченные в разработку новой системы, идентифицированы.
✅ Заинтересованные стороны согласны с назначением новой системы.
✅ Определено, что будет считаться положительным эффектом от внедрения новой системы.
✅ Заинтересованные стороны имеют одинаковое понимание пределов предлагаемого решения.
✅ Технология описания требований согласована.
✅ Механизмы управления требованиями есть в наличии.
✅ Приоритезационная схема ясна.
✅ Ограничения определены и приняты во внимание.
✅ Допущения ясно сформулированы.
Вот тут уже начинаются проблемы. Положительный эффект? Далеко не в каждом проекте удается зафиксировать. Пределы решения? (Можно ещё перевести, как границы). Не всегда фиксируют. Да ещё чтобы все их поняли?
Технология описания. То есть, мы в каком виде требования формулируем? User story? JTBD? Классические ФТ?
Механизмы управления требованиями? Это вообще что?
и т.д.
Конечно, можно прожить и без этого. Тут как с дефектами: само по себе наличие дефектов в системе ещё не означает, что это дефект проявится. То, что вы не поставили галочку в чек-листе, ещё не значит, что проект обязательно провалится. Но это риск. В стандарте этого нет, но к каждому пункту можно приписать набор рисков, которые могут сработать, если это состояние не достигнуто.
Отсутствие приоритезационной схемы может повлечь впихивание в продукт функций по принципу "приоритет у того, кто громче кричит". Отсутствие механизмов управления приводит к проблемам с устаревшими требованиями и соотнесением релизов с набором требований.
Про непроговоренные со стейкхолдерами пределы, допущения и ограничения даже не буду говорить, не люблю ужастики.
В общем, всё это может не выстрелить, но в какой-то момент — особенно когда вы руководите системным анализом не одном проекте, а, скажем, в пяти-шести.
Я так в один момент обнаружил, что у меня в проекте есть в каком-то виде все 30 процессов, описанных в ISO 12207, и за всеми нужно приглядывать, и хорошо бы их как-то разложить на людей, а не контролировать каждый самому. Первый признак инженерной деятельности — систематизация.
Возвращаясь к чек-листам: замечательные пункты
✅ Происхождение требований ясно.
✅ Обоснование требований ясно.
Вот тут, боюсь, 80% проектов и срежется. Откуда вообще эти требования взялись? Ну, это же "по умолчанию". Это "система так требует". "Эти требования мы всегда вписываем". "Нам на курсах сказали, что так надо". "Это было в примере". "Заказчик сказал, что это нужно обязательно". Нет, я понимаю, что никогда нет времени разбираться с этим, потому что и так часов мало. Но тогда какие риски мы принимаем и не учитываем?
👍17❤3
На WAW много говорили о развитии системных аналитиков и возможном карьерном пути.
Почему-то считается, что следующий шаг в карьере для СА — это архитектор (развитие технической экспертизы и навыков проектирования) или продакт-менеджер (развитие в сторону бизнес-потребностей, выявления и представления интересов пользователей, когда их очень много, и с каждым не поговоришь).
Между этими направлениями есть Technical Product Manager, человек, отвечающий за стратегию технологического развития продукта (такой продвинутый в технике Product Owner), в отличие от PMа, который больше про продуктовые метрики и маркетинг. Да, менеджеры продуктов тоже постоянно находятся в поисках себя и самоопределении.
Но был также доклад Бориса Вольфсона, который описал ещё одно направление развития: стратегический консалтинг. Это разработка и имплементация не просто технической стратегии, а бизнесовой. И у опытного фулл-стек аналитика есть все качества для этого:
🔸умение прослеживать связи от бизнес-показателей до конкретных процессов;
🔸 учёт многих факторов и точек зрения;
🔸 умение организовать и фасилитировать продуктивные встречи;
🔸 навык упаковки идей в компактную форму с отточенными формулировками;
🔸 навык проектирования метрик для процессов;
🔸 навык убеждения :)
🔸 и одно из самых важных: навык говорить "нет" и отказываться от лишних фич, а в случае стратегии — о лишних продуктов, рынков и направлений, т.к. стратегия — это про фокусировку.
Я не очень-то думал в эту сторону, хотя сам занимался построением стратегии и проведением стратегических сессий! И знаю людей, которые тоже выходят на разработку стратегии, находясь на высоких позициях в анализе.
Борис, со своей стороны, считает, что системность подхода и внимательность к деталям — это то, что может очень здорово помочь топам, т.к. они зачастую этими качествами не обладают. И это тоже правда, у них там другое — смелость, харизма, политическое чутье, умение воспользоваться шансом, а вот проработка детальных стратегий, на удивление, не всегда сильная сторона.
В докладе был предложен конкретный фреймворк (мы же любим фреймворки!):
Playing-to-Win.
Модель из 5 частей:
Winning Aspiration — наше стремление, зачем вообще существует эта организация или команда?
Where to play — где мы играем? Что является нашим рынком и как его описать? И куда мы точно не идём.
How to win — как мы выигрываем? Что мы конкретно делаем, чтобы выиграть? В чём наше "нечестное преимущество"? И чего мы точно не делаем?
Capabilities — какие способности должны быть у компании, чтобы сыграть так, как мы спланировали? Что компания должна уметь делать? Можно оформить это в виде Activity System Map, которую предложил Портер.
Management System — и наконец, как всё это управляется?
Ответы на эти 5 вопросов и составляют стратегию, а книге (ну конечно, есть книга! Playing to Win: How Strategy Really Works, Roger Martin, Alan G. Lafley, 2013) описан в деталях воркшоп по разработке стратегии.
А Борис, со своей стороны, разработал "6-страничник" для описания стратегии, основанный на этом подходе.
Так что, если выдаётся возможность, старайтесь участвовать в разработке стратегии для вашей компании, это очень увлекательно и полезно! :)
Почему-то считается, что следующий шаг в карьере для СА — это архитектор (развитие технической экспертизы и навыков проектирования) или продакт-менеджер (развитие в сторону бизнес-потребностей, выявления и представления интересов пользователей, когда их очень много, и с каждым не поговоришь).
Между этими направлениями есть Technical Product Manager, человек, отвечающий за стратегию технологического развития продукта (такой продвинутый в технике Product Owner), в отличие от PMа, который больше про продуктовые метрики и маркетинг. Да, менеджеры продуктов тоже постоянно находятся в поисках себя и самоопределении.
Но был также доклад Бориса Вольфсона, который описал ещё одно направление развития: стратегический консалтинг. Это разработка и имплементация не просто технической стратегии, а бизнесовой. И у опытного фулл-стек аналитика есть все качества для этого:
🔸умение прослеживать связи от бизнес-показателей до конкретных процессов;
🔸 учёт многих факторов и точек зрения;
🔸 умение организовать и фасилитировать продуктивные встречи;
🔸 навык упаковки идей в компактную форму с отточенными формулировками;
🔸 навык проектирования метрик для процессов;
🔸 навык убеждения :)
🔸 и одно из самых важных: навык говорить "нет" и отказываться от лишних фич, а в случае стратегии — о лишних продуктов, рынков и направлений, т.к. стратегия — это про фокусировку.
Я не очень-то думал в эту сторону, хотя сам занимался построением стратегии и проведением стратегических сессий! И знаю людей, которые тоже выходят на разработку стратегии, находясь на высоких позициях в анализе.
Борис, со своей стороны, считает, что системность подхода и внимательность к деталям — это то, что может очень здорово помочь топам, т.к. они зачастую этими качествами не обладают. И это тоже правда, у них там другое — смелость, харизма, политическое чутье, умение воспользоваться шансом, а вот проработка детальных стратегий, на удивление, не всегда сильная сторона.
В докладе был предложен конкретный фреймворк (мы же любим фреймворки!):
Playing-to-Win.
Модель из 5 частей:
Winning Aspiration — наше стремление, зачем вообще существует эта организация или команда?
Where to play — где мы играем? Что является нашим рынком и как его описать? И куда мы точно не идём.
How to win — как мы выигрываем? Что мы конкретно делаем, чтобы выиграть? В чём наше "нечестное преимущество"? И чего мы точно не делаем?
Capabilities — какие способности должны быть у компании, чтобы сыграть так, как мы спланировали? Что компания должна уметь делать? Можно оформить это в виде Activity System Map, которую предложил Портер.
Management System — и наконец, как всё это управляется?
Ответы на эти 5 вопросов и составляют стратегию, а книге (ну конечно, есть книга! Playing to Win: How Strategy Really Works, Roger Martin, Alan G. Lafley, 2013) описан в деталях воркшоп по разработке стратегии.
А Борис, со своей стороны, разработал "6-страничник" для описания стратегии, основанный на этом подходе.
Так что, если выдаётся возможность, старайтесь участвовать в разработке стратегии для вашей компании, это очень увлекательно и полезно! :)
👍14🔥3❤2😁1
Фреймворк Playing-to-Win и пример Activity System Map.
Интересно также, что стратегические сессии компании проводят часто по множеству различных причин, но только не для того, чтобы разработать стратегию и следовать ей 🤷🏼♂️
А ещё — будьте тут аккуратны! — несколько раз я сталкивался с тем, что участвовал в разработке стратегии, но после этого не только не получал предложения реализовать её, а даже наоборот — получал настойчивое предложение покинуть компанию. При этом стратегия дальше реализовывалась как раз во многом по моим предложениям. Люди по-разному относятся к тем, кто приносит им неожиданные идеи и заставляет взглянуть на себя честно, и часто правда их возмущает (самый одиозный случай был с одним крупным бизнесменом, который считал, что хочет развивать образование и предпринимательство, а на самом деле хотел стать celebrity. Что мы с PR-директором ему и написали в стратегии, после чего тут же были уволены, но дальше он именно в эту сторону и начал работать).
Интересно также, что стратегические сессии компании проводят часто по множеству различных причин, но только не для того, чтобы разработать стратегию и следовать ей 🤷🏼♂️
А ещё — будьте тут аккуратны! — несколько раз я сталкивался с тем, что участвовал в разработке стратегии, но после этого не только не получал предложения реализовать её, а даже наоборот — получал настойчивое предложение покинуть компанию. При этом стратегия дальше реализовывалась как раз во многом по моим предложениям. Люди по-разному относятся к тем, кто приносит им неожиданные идеи и заставляет взглянуть на себя честно, и часто правда их возмущает (самый одиозный случай был с одним крупным бизнесменом, который считал, что хочет развивать образование и предпринимательство, а на самом деле хотел стать celebrity. Что мы с PR-директором ему и написали в стратегии, после чего тут же были уволены, но дальше он именно в эту сторону и начал работать).
🔥6👍1🎄1
Иии у нас очередной запуск курса Ветчинкина по микросервисам!
(напоминаю, что это лучший☝🏻 курс по микросервисам на русском языке)
Учитывая критику предыдущего объявления, я провел собственное исследование и выяснил, что на HH требование знания микросервисов в вакансиях системных аналитиков встречается примерно в каждой десятой вакансии, зато зарплаты по таким вакансиям начинаются сразу от 180 тыс., а в среднем таким аналитикам обещают 260 тыс.
Ну и даже если компания не выставляет таких вакансий, всё равно в тайне мечтает перейти на микросервисы :) Например, довольно часто вижу запрос на каталогизацию и описание мкиросервисов ("дайте шаблон описания микросервиса"), эту работу обычно поручают аналитику.
И лучшего варианта разобраться с микросервисами, чем курс Кирилла, нет.
Заодно можно погрузиться в задачи архитектора, если вы планируете расти в эту сторону — можно, скажем, удивиться (спойлер!) что архитектор, например, очень много времени уделяет формированию команд и распространению знаний между командами.
(вместе с ограничением знаний между командами). Это неочевидно — снаружи кажется, что архитекторы в основном продумывают технические аспекты, но кроме CAP-теоремы, в разработке работают законы Брукса и Конвея:
А вы читали классическую книгу по управлению программными проектами Брукса "Мифический человеко-месяц"? Вот ту, откуда пришли фразы "серебряной пули не существует", "эффект второй системы", расчет сложности ПО (создание хорошо отлаженного и документированного программного продукта с внешними интеграциями обходится в 9 раз дороже, чем просто "запрогать это"), и тезисы типа "планируйте выбросить первую версию" (термин MVP тогда ещё не изобрели) и "сценарий взаимодействия обычно разрабатывают не перед, а после реализации". Очень любопытно, уже в 1975 всё было понятно про нашу индустрию. Микросервисы — как раз один из возможных ответов на эти вызовы.
Закон Конвея:
Есть и обратный закон Конвея: структура системы определяет структуру организации.
Так что микросервисы и архитектура, на удивление, очень сильно связана с организацией команд и управлением знаниями.
(напоминаю, что это лучший☝🏻 курс по микросервисам на русском языке)
Учитывая критику предыдущего объявления, я провел собственное исследование и выяснил, что на HH требование знания микросервисов в вакансиях системных аналитиков встречается примерно в каждой десятой вакансии, зато зарплаты по таким вакансиям начинаются сразу от 180 тыс., а в среднем таким аналитикам обещают 260 тыс.
Ну и даже если компания не выставляет таких вакансий, всё равно в тайне мечтает перейти на микросервисы :) Например, довольно часто вижу запрос на каталогизацию и описание мкиросервисов ("дайте шаблон описания микросервиса"), эту работу обычно поручают аналитику.
И лучшего варианта разобраться с микросервисами, чем курс Кирилла, нет.
Заодно можно погрузиться в задачи архитектора, если вы планируете расти в эту сторону — можно, скажем, удивиться (спойлер!) что архитектор, например, очень много времени уделяет формированию команд и распространению знаний между командами.
(вместе с ограничением знаний между командами). Это неочевидно — снаружи кажется, что архитекторы в основном продумывают технические аспекты, но кроме CAP-теоремы, в разработке работают законы Брукса и Конвея:
«Добавляя людских ресурсов, мы задерживаем окончание программного проекта» (Брукс, 1975).
А вы читали классическую книгу по управлению программными проектами Брукса "Мифический человеко-месяц"? Вот ту, откуда пришли фразы "серебряной пули не существует", "эффект второй системы", расчет сложности ПО (создание хорошо отлаженного и документированного программного продукта с внешними интеграциями обходится в 9 раз дороже, чем просто "запрогать это"), и тезисы типа "планируйте выбросить первую версию" (термин MVP тогда ещё не изобрели) и "сценарий взаимодействия обычно разрабатывают не перед, а после реализации". Очень любопытно, уже в 1975 всё было понятно про нашу индустрию. Микросервисы — как раз один из возможных ответов на эти вызовы.
Закон Конвея:
Организации, проектирующие системы, создают программные структуры, повторяющие структуру коммуникации, сложившуюся в этих организациях
(Конвей, 1968)
Есть и обратный закон Конвея: структура системы определяет структуру организации.
Так что микросервисы и архитектура, на удивление, очень сильно связана с организацией команд и управлением знаниями.
👍12🔥2
Забавное применение ChatGPT: пользовательское тестирование требований.
Как известно, пока пользователь не увидит систему, он не может сказать, что ему ещё нужно.
Чтобы не разрабатывать систему, можно попросить ChatGPT эмулировать работу системы, описанной требованиями.
То есть, даём ChatGPT набор требований (тут мы будем ограничены длиной промпта или двух), а потом просим его отвечать — может ли система, описанная этими требованиями, выполнить действия, которые пользователь формирует на своём языке. Можно представителя пользователя рядом посадить и предложить представить типичные ситуации, а ИИ будет говорить — можно ли это сделать при описанных требованиях. В общем, похоже на текстовую RPG 😀
Промпт:
Как вариант, можно попросить описать с точностью до экранов:
ChatGPT Plus — со встроенным DALL-E — может сразу генерировать изображения экранов (ну, с подписями будет не очень, тут либо визуальное расположение, либо подписи).
Отсюда: https://arxiv.org/abs/2303.07839 ChatGPT Prompt Patterns for Improving Code Quality, Refactoring, Requirements Elicitation, and Software Design. Jules White, Sam Hays, Quchen Fu, Jesse Spencer-Smith, Douglas C. Schmidt
Также там описаны промпты для выявления неоднозначностей в требованиях (что может быть понято двусмысленно),
симулятор API, генерация примеров для API, подсказка по возможным вариантам архитектуры и анализ запросов на изменения (насколько сложно будет реализовать новую функцию).
Как известно, пока пользователь не увидит систему, он не может сказать, что ему ещё нужно.
Чтобы не разрабатывать систему, можно попросить ChatGPT эмулировать работу системы, описанной требованиями.
То есть, даём ChatGPT набор требований (тут мы будем ограничены длиной промпта или двух), а потом просим его отвечать — может ли система, описанная этими требованиями, выполнить действия, которые пользователь формирует на своём языке. Можно представителя пользователя рядом посадить и предложить представить типичные ситуации, а ИИ будет говорить — можно ли это сделать при описанных требованиях. В общем, похоже на текстовую RPG 😀
Промпт:
Now, I want you to act as this system. Use the requirements to guide your behavior. I am going to say, I want to do X, and you will tell me if X is possible given the requirements. If X is possible, provide a step-by-step set of instructions on how I would accomplish it and provide additional details that would help implement the requirement. If I can’t do X based on the requirements, write the missing requirements to make it possible as user stories.
Как вариант, можно попросить описать с точностью до экранов:
Now, I want you to act as this system in a textbased simulator of the system. Use the requirements to guide your behavior. You will describe the user interface for the system, based on the requirements, and what I can do on each screen. I am going to say, I want to do X, and you will tell me if X is possible given the requirements and the current screen. If X is possible, provide a step-by-step set of instructions how I would accomplish it and provide additional details that would help implement the requirement.
If I can’t do X based on the requirements, write the missing requirements to make it possible as user stories. Whenever the state of the user interface changes, update the user on what they are looking at.
Tell me what I am looking at in the system and ask me what I want to do.
ChatGPT Plus — со встроенным DALL-E — может сразу генерировать изображения экранов (ну, с подписями будет не очень, тут либо визуальное расположение, либо подписи).
Отсюда: https://arxiv.org/abs/2303.07839 ChatGPT Prompt Patterns for Improving Code Quality, Refactoring, Requirements Elicitation, and Software Design. Jules White, Sam Hays, Quchen Fu, Jesse Spencer-Smith, Douglas C. Schmidt
Также там описаны промпты для выявления неоднозначностей в требованиях (что может быть понято двусмысленно),
симулятор API, генерация примеров для API, подсказка по возможным вариантам архитектуры и анализ запросов на изменения (насколько сложно будет реализовать новую функцию).
👍22🔥3❤2
Postman, кроме того, что производит инструмент для тестирования API, ещё собирает лучшие практики проектирования.
Для этого у них есть отдельная команда Postman Open Technologies, которая также собирает информацию о стандартах, отраслевых форматах и спецификациях, открытых API.
Каталог практик и паттернов оформлен как рабочее пространство Postman: https://www.postman.com/postman/workspace/postman-open-technologies-openapi-governance-templates/overview (открывается прямо в Postman!)
Смысл каталога в том, чтобы не придумывать каждый раз "как мы будем возвращать сумму платежа" или "как будем делать пагинацию", а брать готовое решение.
На текущий момент там описаны следующие паттерны:
🔸 Форматы данных:
🔹Коды стран (ISO 3166)
🔹Коды валют (ISO 4217)
🔹Дата, время и временные промежутки (ISO 8601)
🔹Числа с десятичными дробями
🔹Кастомные заголовки HTTP
🔹Расширенное описание ошибки (RFC 9457 - кстати, очень хороший формат для передачи смысла ошибки HTTP)
🔸Управление кэшированием:
🔹Параметр Cache-control
🔹Параметр Etag
🔹Параметр Expires
🔸Фильтрация:
🔹Параметры поискового запроса
🔹Точное соответствие
🔹Диапазон значений поля
🔹Выбор полей для ответа
🔸Пагинация:
🔹Заголовки page and per_page (rfc 5988)
🔹Курсор / NextRecordKey
🔹Параметры Limit и Offset
🔸Сортировка:
🔹По одному полю - параметры sort_by, sort_order
🔹По нескольким полям
🔸Версионирование:
🔹На уровне URL API
🔹На уровне отдельного ресурса
🔹Через заголовок Accept-Version
🔹Через заголовок Accept
🔸Информация:
🔹Контакты разработчиков
🔹Лицензия
🔹Условия использования
🔹Заголовок Sunset (предупреждение, что ресурс станет недоступным в определенное время)
Набор паттернов интересный, я, например, про RFC 9457, версионирование на уровне ресурсов и Sunset header раньше не слышал.
Для этого у них есть отдельная команда Postman Open Technologies, которая также собирает информацию о стандартах, отраслевых форматах и спецификациях, открытых API.
Каталог практик и паттернов оформлен как рабочее пространство Postman: https://www.postman.com/postman/workspace/postman-open-technologies-openapi-governance-templates/overview (открывается прямо в Postman!)
Смысл каталога в том, чтобы не придумывать каждый раз "как мы будем возвращать сумму платежа" или "как будем делать пагинацию", а брать готовое решение.
На текущий момент там описаны следующие паттерны:
🔸 Форматы данных:
🔹Коды стран (ISO 3166)
🔹Коды валют (ISO 4217)
🔹Дата, время и временные промежутки (ISO 8601)
🔹Числа с десятичными дробями
🔹Кастомные заголовки HTTP
🔹Расширенное описание ошибки (RFC 9457 - кстати, очень хороший формат для передачи смысла ошибки HTTP)
🔸Управление кэшированием:
🔹Параметр Cache-control
🔹Параметр Etag
🔹Параметр Expires
🔸Фильтрация:
🔹Параметры поискового запроса
🔹Точное соответствие
🔹Диапазон значений поля
🔹Выбор полей для ответа
🔸Пагинация:
🔹Заголовки page and per_page (rfc 5988)
🔹Курсор / NextRecordKey
🔹Параметры Limit и Offset
🔸Сортировка:
🔹По одному полю - параметры sort_by, sort_order
🔹По нескольким полям
🔸Версионирование:
🔹На уровне URL API
🔹На уровне отдельного ресурса
🔹Через заголовок Accept-Version
🔹Через заголовок Accept
🔸Информация:
🔹Контакты разработчиков
🔹Лицензия
🔹Условия использования
🔹Заголовок Sunset (предупреждение, что ресурс станет недоступным в определенное время)
Набор паттернов интересный, я, например, про RFC 9457, версионирование на уровне ресурсов и Sunset header раньше не слышал.
👍33🔥9❤4
Я в последнее время много писал про сложные темы, а между тем обнаружил, что на русском языке нет простого объяснения про запросы, представления, хранимые процедуры и пользовательские функции.
То есть, можно Википедию почитать, можно посмотреть (довольно занудные) видео-лекции для программистов, а вот так чтобы на пальцах объяснили — не нашел.
Отсюда два вопроса:
1) Попадалось ли вам простое объяснение этих тем? Вот чтобы для начинающего системного аналитика, с целью разобраться в этих материях.
2) Нужно ли вам самим или вашим сотрудникам такое объяснение? Ставьте лайк, если да.
Ну интересно послушать — как вы сами разобрались с этой темой, или что вам интересно про неё узнать, если ещё не разобрались. Пишите в комментариях
👇👇👇
То есть, можно Википедию почитать, можно посмотреть (довольно занудные) видео-лекции для программистов, а вот так чтобы на пальцах объяснили — не нашел.
Отсюда два вопроса:
1) Попадалось ли вам простое объяснение этих тем? Вот чтобы для начинающего системного аналитика, с целью разобраться в этих материях.
2) Нужно ли вам самим или вашим сотрудникам такое объяснение? Ставьте лайк, если да.
Ну интересно послушать — как вы сами разобрались с этой темой, или что вам интересно про неё узнать, если ещё не разобрались. Пишите в комментариях
👇👇👇
👍66❤10🔥3
tables_views_sp.pdf
281.5 KB
В общем, я вижу, интерес к теме хранимых процедур есть, поэтому я сделал небольшую презентацию с объяснением совсем базовых вещей.
Держите, пользуйтесь, задавайте вопросы!
Держите, пользуйтесь, задавайте вопросы!
❤40🔥32❤🔥9👍6
Продолжу тему нефункциональных требований, или показателей качества.
Давно хотел завести гонзо-обзоры стандартов, относящихся к ИТ.
Сегодня — про ISO 25000, System and Software Quality Requirements and Evaluation, SQuaRE (по-английски — что-то типа "скучный, занудный, не модный"). У нас его эквивалент — ГОСТ Р ИСО 25000:2021, свеженький, введен в апреле 2022 г. (Там серия: управление качеством, модели качества, измерение качества, требования к качеству, оценка качества. Можно надолго погрузиться)
Возможно, вы слышали про стандарт управления качеством ISO 9000. Так вот ISO 25000 плюет на ISO 9000 и отстраивается от него, хотя оба говорят про качество. Отстройка такая: 9000 — это про качество процессов, а 25000 — про качество систем и программной продукции. Это в стандартах сплошь и рядом, например, про качество данных у нас есть два стандарта.
Собственно, качество данных — одна из моделей качества, которую вводит ISO 25000. Ещё качество при использовании и качество продукта. Само понятие качества определяется как степень удовлетворения системой заявленных и подразумеваемых потребностей различных заинтересованных сторон.
Модель качества определяет характеристики, которые нас могут интересовать, и их показатели (что можно измерить). Вот, например, качество в использовании. Об этом часто говорят, как о юзабилити/UX, но посмотрите, что нам тут рекомендуют измерять:
➡️ Результативность
⭐️ Выполненные задачи (% задач, которые выполняются правильно без посторонней помощи)
⭐️ Достигнутые цели (% целей, которые достигаются правильно без посторонней помощи)
⭐️ Ошибки в задаче (Количество ошибок, допущенных пользователем во время выполнения задачи)
⭐️ Задачи с ошибками (% задач, в которых пользователь допустил ошибки)
⭐️ Интенсивность ошибок задачи (% пользователей, совершающих ошибку при выполнении задачи)
➡️ Эффективность
⭐️ Время выполнения задачи
⭐️ Эффективность затраченного времени (число достигнутых целей / время работы пользователя)
⭐️ Экономическая эффективность (стоимость выполнения задач / количество достигнутых целей)
⭐️ Коэффициент полезного времени (время, затраченное на выполнение задачи за вычетом времени, потраченного на получение помощи или помощь; времени на восстановление после ошибок; времени на неэффективный поиск)
⭐️ Ненужные действия
⭐️ Последствия усталости (Снижение производительности после непрерывной работы)
➡️ Удовлетворенность
⭐️ Полезность
⭐️ Удовлетворенность функциями (по опросам пользователей)
⭐️ Дискреционное использование (% потенциальных пользователей, решивших использовать систему или функцию, от всех, кто мог бы использовать эту функцию).
⭐️ Использование функций (% пользователей системы, использующих функцию).
⭐️ Доля жалующихся пользователей (% от всех активных пользователей).
⭐️ Доля жалоб пользователей на функцию (% относительно числа всех пользователей этой функции).
Подхарактеристики, которые измеряются по опросникам:
Доверие
Удовольствие
Комфорт
➡️ Свобода от рисков
Снижение экономических рисков - а вот тут, внезапно, не UX, а расчет окупаемости и возврата инвестиций! Рентабельность, время окупаемости, экономическая эффективность, преимущества внедрения ИТ(по сравнению с другими способами решения задачи!), выручка от клиента, доля ошибок с экономическими последствиями.
➡️ Покрытие контекста
⭐️ Полнота контекста (Доля предполагаемых контекстов использования, в которых продукт или система могут использоваться с приемлемым удобством использования и риском)
⭐️ Гибкость: степень, в которой продукт может использоваться в дополнительных контекстах без модификаций
⭐️ Простота, с которой продукт может быть изменен в соответствии с дополнительными требованиями пользователя
⭐️ Независимость от специальных знаний и навыков пользователя.
Вот такие характеристики качества в использовании. Интересно, сколько из них рассматривают аналитики или UX-дизайнеры.
Возможно, это не их вопросы, но чьи?..
Давно хотел завести гонзо-обзоры стандартов, относящихся к ИТ.
Сегодня — про ISO 25000, System and Software Quality Requirements and Evaluation, SQuaRE (по-английски — что-то типа "скучный, занудный, не модный"). У нас его эквивалент — ГОСТ Р ИСО 25000:2021, свеженький, введен в апреле 2022 г. (Там серия: управление качеством, модели качества, измерение качества, требования к качеству, оценка качества. Можно надолго погрузиться)
Возможно, вы слышали про стандарт управления качеством ISO 9000. Так вот ISO 25000 плюет на ISO 9000 и отстраивается от него, хотя оба говорят про качество. Отстройка такая: 9000 — это про качество процессов, а 25000 — про качество систем и программной продукции. Это в стандартах сплошь и рядом, например, про качество данных у нас есть два стандарта.
Собственно, качество данных — одна из моделей качества, которую вводит ISO 25000. Ещё качество при использовании и качество продукта. Само понятие качества определяется как степень удовлетворения системой заявленных и подразумеваемых потребностей различных заинтересованных сторон.
Модель качества определяет характеристики, которые нас могут интересовать, и их показатели (что можно измерить). Вот, например, качество в использовании. Об этом часто говорят, как о юзабилити/UX, но посмотрите, что нам тут рекомендуют измерять:
⭐️ Выполненные задачи (% задач, которые выполняются правильно без посторонней помощи)
⭐️ Достигнутые цели (% целей, которые достигаются правильно без посторонней помощи)
⭐️ Ошибки в задаче (Количество ошибок, допущенных пользователем во время выполнения задачи)
⭐️ Задачи с ошибками (% задач, в которых пользователь допустил ошибки)
⭐️ Интенсивность ошибок задачи (% пользователей, совершающих ошибку при выполнении задачи)
⭐️ Время выполнения задачи
⭐️ Эффективность затраченного времени (число достигнутых целей / время работы пользователя)
⭐️ Экономическая эффективность (стоимость выполнения задач / количество достигнутых целей)
⭐️ Коэффициент полезного времени (время, затраченное на выполнение задачи за вычетом времени, потраченного на получение помощи или помощь; времени на восстановление после ошибок; времени на неэффективный поиск)
⭐️ Ненужные действия
⭐️ Последствия усталости (Снижение производительности после непрерывной работы)
⭐️ Полезность
⭐️ Удовлетворенность функциями (по опросам пользователей)
⭐️ Дискреционное использование (% потенциальных пользователей, решивших использовать систему или функцию, от всех, кто мог бы использовать эту функцию).
⭐️ Использование функций (% пользователей системы, использующих функцию).
⭐️ Доля жалующихся пользователей (% от всех активных пользователей).
⭐️ Доля жалоб пользователей на функцию (% относительно числа всех пользователей этой функции).
Подхарактеристики, которые измеряются по опросникам:
Доверие
Удовольствие
Комфорт
Снижение экономических рисков - а вот тут, внезапно, не UX, а расчет окупаемости и возврата инвестиций! Рентабельность, время окупаемости, экономическая эффективность, преимущества внедрения ИТ(по сравнению с другими способами решения задачи!), выручка от клиента, доля ошибок с экономическими последствиями.
⭐️ Полнота контекста (Доля предполагаемых контекстов использования, в которых продукт или система могут использоваться с приемлемым удобством использования и риском)
⭐️ Гибкость: степень, в которой продукт может использоваться в дополнительных контекстах без модификаций
⭐️ Простота, с которой продукт может быть изменен в соответствии с дополнительными требованиями пользователя
⭐️ Независимость от специальных знаний и навыков пользователя.
Вот такие характеристики качества в использовании. Интересно, сколько из них рассматривают аналитики или UX-дизайнеры.
Возможно, это не их вопросы, но чьи?..
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13👍7🔥1
Часть программы Flow, по традиции , будет доступна бесплатно (после регистрации). Билеты и так не дорогие, но топовые доклады — точнее, доклад и два обсуждения — и вовсе бесплатно:
"Удобство использования" есть ещё в модели качества продукта.
Хотите оценить качество программного продукта или сравнить два продукта между собой? На это тоже есть ГОСТ! ГОСТ Р ИСО/МЭК 25023-2021, можете ссылаться.
Также можно использовать этот набор показателей при постановке задач на проектирование интерфейсов и создание документации/справки/онбординга/обучающих материалов.
Вот что в части удобства использования можно измерить:
➡️ Достаточность описания (для определения пригодности — подойдет ли нам этот продукт для решения наших задач?):
⭐️ Полнота описания — какая часть сценариев описана в документации? (" — А для чего эта кнопка? — Да никто не знает")
⭐️ Демонстрационное покрытие — какая часть сценариев имеет наглядную демонстрацию, чтобы можно было определить их пригодность?
➡️ Обучаемость:
⭐️ Полнота руководства пользователя — какая часть сценариев описана в справке или документации в такой степени, чтобы пользователь мог ими воспользоваться? Тут, кстати, в стандарте говорится не только о документации, но и о соответствии концептуальной модели системы ментальной модели пользователя(!) это, по сути, практически DDD: как пользователь представляет себе предметный домен, и как этот домен отражен в системе и её интерфейсах.
⭐️ Приведение значений по умолчанию — какая часть полей ввода данных, имеющие значения по умолчанию, автоматически заполняются этими значениями? (добавлю тут от себя — какая часть полей ввода содержит описание форматов и примеры заполнения?)
⭐️ Понятность сообщений об ошибках — какая часть сообщений об ошибках предоставляет информацию о причинах возникновения ошибки и методах ее устранения?
⭐️ Самоописательность пользовательского интерфейса — какая часть элементов интерфейса, с которыми взаимодействует пользователь в ходе выполнения операций, позволяет выполнить данные операции без дополнительного обучения и подготовки?
➡️ Эксплуатационная пригодность:
⭐️ Эксплуатационная согласованность: в какой степени поведение системы постоянно в ходе выполнения группы схожих операций? (например, насколько похоже реализованы функции оплаты картой или оплатой по СБП? насколько похоже по логике и поведению добавление сообщения в общий форум всего курса и комментирование одного видео/задания из курса? и т.д.)
⭐️ Корректность сообщений — какая часть сообщений, получаемых от системы, имеет корректный результат или приводит инструкции пользователю?
⭐️ Функциональная настраиваемость — какую часть функций и процедур пользователь может настроить для своего удобства? (настройка которых может быть полезна. Например, сохранить какие-то шаблоны, значения по умолчанию, убрать ненужные шаги).
⭐️ Настраиваемость интерфейса — какую часть элементов интерфейса пользователь может настроить? (для которых это имеет смысл — например, скрыть неиспользуемые элементы интерфейса).
⭐️ Возможность мониторинга — какие состояния могут быть отслежены во время эксплуатации?
⭐️ Возможность отмены действий — какая часть сценариев использования предусматривает отмену или изменение?
⭐️ Понятность категоризации информации — в какой степени организация информации, используемая в программном продукте или системе, понятна пользователям и удобна для решения ими своих задач? Измеряется как число структур данных, понятных пользователю, к общему числу структур данных в продукте. Опять про DDD, да?
⭐️ Постоянство представления — одинаковые элементы данных схожим образом представлены в разных местах продукта.
⭐️ Поддержка устройств ввода
➡️ Защита от пользовательских ошибок:
⭐️ Защита — число действий, обрабатываемых с целью защиты от ошибок ввода
⭐️ Коррекция — число ошибок, по которым предлагается корректный вариант ("возможно, вы имели в виду ...")
➡️ Доступность:
⭐️ Доступность для пользователей с ограниченными возможностями
⭐️ Языковая поддержка
И, наконец, та-дам!
➡️ Эстетичность представления пользовательского интерфейса. "Чтобы было красиво"
Измеряется, вы не поверите, просто как отношение эстетически приятных интерфейсов ко всем имеющимся в продукте 🤷🏼♂️🤡👩🏻🎨
Хотите оценить качество программного продукта или сравнить два продукта между собой? На это тоже есть ГОСТ! ГОСТ Р ИСО/МЭК 25023-2021, можете ссылаться.
Также можно использовать этот набор показателей при постановке задач на проектирование интерфейсов и создание документации/справки/онбординга/обучающих материалов.
Вот что в части удобства использования можно измерить:
⭐️ Полнота описания — какая часть сценариев описана в документации? (" — А для чего эта кнопка? — Да никто не знает")
⭐️ Демонстрационное покрытие — какая часть сценариев имеет наглядную демонстрацию, чтобы можно было определить их пригодность?
⭐️ Полнота руководства пользователя — какая часть сценариев описана в справке или документации в такой степени, чтобы пользователь мог ими воспользоваться? Тут, кстати, в стандарте говорится не только о документации, но и о соответствии концептуальной модели системы ментальной модели пользователя(!) это, по сути, практически DDD: как пользователь представляет себе предметный домен, и как этот домен отражен в системе и её интерфейсах.
⭐️ Приведение значений по умолчанию — какая часть полей ввода данных, имеющие значения по умолчанию, автоматически заполняются этими значениями? (добавлю тут от себя — какая часть полей ввода содержит описание форматов и примеры заполнения?)
⭐️ Понятность сообщений об ошибках — какая часть сообщений об ошибках предоставляет информацию о причинах возникновения ошибки и методах ее устранения?
⭐️ Самоописательность пользовательского интерфейса — какая часть элементов интерфейса, с которыми взаимодействует пользователь в ходе выполнения операций, позволяет выполнить данные операции без дополнительного обучения и подготовки?
⭐️ Эксплуатационная согласованность: в какой степени поведение системы постоянно в ходе выполнения группы схожих операций? (например, насколько похоже реализованы функции оплаты картой или оплатой по СБП? насколько похоже по логике и поведению добавление сообщения в общий форум всего курса и комментирование одного видео/задания из курса? и т.д.)
⭐️ Корректность сообщений — какая часть сообщений, получаемых от системы, имеет корректный результат или приводит инструкции пользователю?
⭐️ Функциональная настраиваемость — какую часть функций и процедур пользователь может настроить для своего удобства? (настройка которых может быть полезна. Например, сохранить какие-то шаблоны, значения по умолчанию, убрать ненужные шаги).
⭐️ Настраиваемость интерфейса — какую часть элементов интерфейса пользователь может настроить? (для которых это имеет смысл — например, скрыть неиспользуемые элементы интерфейса).
⭐️ Возможность мониторинга — какие состояния могут быть отслежены во время эксплуатации?
⭐️ Возможность отмены действий — какая часть сценариев использования предусматривает отмену или изменение?
⭐️ Понятность категоризации информации — в какой степени организация информации, используемая в программном продукте или системе, понятна пользователям и удобна для решения ими своих задач? Измеряется как число структур данных, понятных пользователю, к общему числу структур данных в продукте. Опять про DDD, да?
⭐️ Постоянство представления — одинаковые элементы данных схожим образом представлены в разных местах продукта.
⭐️ Поддержка устройств ввода
⭐️ Защита — число действий, обрабатываемых с целью защиты от ошибок ввода
⭐️ Коррекция — число ошибок, по которым предлагается корректный вариант ("возможно, вы имели в виду ...")
⭐️ Доступность для пользователей с ограниченными возможностями
⭐️ Языковая поддержка
И, наконец, та-дам!
Измеряется, вы не поверите, просто как отношение эстетически приятных интерфейсов ко всем имеющимся в продукте 🤷🏼♂️🤡👩🏻🎨
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🥱2❤1🔥1
8 марта вновь вспоминаем всех женщин, стоявших у истоков ИТ: придумавших первые языки программирования, компилятор, доменную систему имен, базовые алгоритмы сетевого обмена и т.д.
И, конечно, Аду Лавлейс. Хотя её и считают первым программистом, сама она называла себя Аналитиком:
И, помимо остальных заслуг, Аде принадлежит идея, что счётные машины могут не только щелкать цифрами — они могут в виде цифр представлять и другие объекты реального мира, устанавливать связи между ними, вычислять логические закономерности и это радикально изменит науку и обшество. В качестве примеров она приводила музыку и изображения в цифровом виде (а кино тогда ещё не изобрели).
В общем, действовала, как настоящий аналитик: думала о применении аналитических машин для полезных дел в разных областях, а не только о том, какой бы прикольный код написать.
Чего в этот день всем и желаю! И спасибо дорогим женщинам за ключевой вклад в ИТ и приземеление абстрактных идей на решение реальных проблем.
С праздником! Процветания и независимости! И побольше радости! 💐🌺🌸🌷🪻
И, конечно, Аду Лавлейс. Хотя её и считают первым программистом, сама она называла себя Аналитиком:
I am in good spirits; for I hope another year will make me really something of an Analyst. The more I study, the more insatiable do I feel my genius for it to be.
I do not believe that my father was (or ever could have been) such a Poet as I shall be an Analyst, (& Metaphysician); for with me the two go together indissolubly.
И, помимо остальных заслуг, Аде принадлежит идея, что счётные машины могут не только щелкать цифрами — они могут в виде цифр представлять и другие объекты реального мира, устанавливать связи между ними, вычислять логические закономерности и это радикально изменит науку и обшество. В качестве примеров она приводила музыку и изображения в цифровом виде (а кино тогда ещё не изобрели).
В общем, действовала, как настоящий аналитик: думала о применении аналитических машин для полезных дел в разных областях, а не только о том, какой бы прикольный код написать.
Чего в этот день всем и желаю! И спасибо дорогим женщинам за ключевой вклад в ИТ и приземеление абстрактных идей на решение реальных проблем.
С праздником! Процветания и независимости! И побольше радости! 💐🌺🌸🌷🪻
🔥40👍5🎉2
Представьте себе, что у вас под рукой в любой момент есть база данных, в которой есть гарантировано актуальная информация обо всех системах в организации:
✅ что за система, какие бизнес-сервисы она поддерживает (реестр бизнес-сервисов у вас тоже есть актуальный!)
✅ с какими смежными системами взаимодействует:
➡️ какие API выставляет
➡️ по каким API обращается
➡️ в какие топики очереди сообщений пишет, какие читает
✅ к каким базам данных есть доступ у системы, и какие бизнес-объекты в ней учитываются или изменяются
✅ где развернуты экземпляры системы, кто имеет доступ к ним
✅ какая команда какие системы разрабатывает, кто участвует и участвовал в разработке, кто за что отвечает (кто владелец, кто архитектор и т.д.)
Кроме того, у вас есть реестр бизнес-сервисов, то есть продуктов и услуг компании, и про каждый продукт известно:
➡️ из каких услуг он складывается
➡️ на какую аудиторию он ориентирован
➡️ через какие каналы предоставляется услуга
➡️ какие отделы внутри компании оказывают услугу
Соответственно, всё это связано друг с другом, и вы можете делать к базе произвольные запросы. Например:
❓ какие зависимости есть у системы (что нужно проверить, если вы хотите внести изменения, или переписать систему)
❓ какие клиенты есть у системы и
❓ какие сейчас есть потоки данных (например, чтобы отправлять какую-то дополнительную информацию)
❓ кто работает или работал над какой системой, кого спросить или позвать на встречу
❓ какие системы поддерживают какие бизнес-услуги, кто ими пользуется?
и так далее.
Была бы такая база полезна? Сколько бы это времени вам сэкономило?
Я, честно говоря, когда впервые увидел такую штуку, был в полном восхищении. А увидел я её на отборе докладов на Flow: это выступление Романа Цирульникова из ЮMoney. Надеюсь, сегодня вы его тоже посмотрели, называется скромно: "Модель архитектуры предприятия на графе".
Конечно, технологически поддерживать такую базу непросто, и требует определенного уровня зрелости процессов развертывания: всё на скриптах, под контролем и As Code -- чтобы потом по этому коду можно было всё собрать.
Но результат выглядит потрясающе. Кажется, где-то здесь лежит будущее системного анализа (или его погибель, смотря как вы настроены).
Я вот настроен в целом позитивно: мне сегодня исполняетсястрашно сказать, сколько , я на это наше ИТ смотрю уже больше 25 лет, и надеюсь, что увижу ещё много чудес впереди. Чего и вам желаю!
Осваивайте новые технологии! А я пошел тортик есть🎂
✅ что за система, какие бизнес-сервисы она поддерживает (реестр бизнес-сервисов у вас тоже есть актуальный!)
✅ с какими смежными системами взаимодействует:
➡️ какие API выставляет
➡️ по каким API обращается
➡️ в какие топики очереди сообщений пишет, какие читает
✅ к каким базам данных есть доступ у системы, и какие бизнес-объекты в ней учитываются или изменяются
✅ где развернуты экземпляры системы, кто имеет доступ к ним
✅ какая команда какие системы разрабатывает, кто участвует и участвовал в разработке, кто за что отвечает (кто владелец, кто архитектор и т.д.)
Кроме того, у вас есть реестр бизнес-сервисов, то есть продуктов и услуг компании, и про каждый продукт известно:
➡️ из каких услуг он складывается
➡️ на какую аудиторию он ориентирован
➡️ через какие каналы предоставляется услуга
➡️ какие отделы внутри компании оказывают услугу
Соответственно, всё это связано друг с другом, и вы можете делать к базе произвольные запросы. Например:
❓ какие зависимости есть у системы (что нужно проверить, если вы хотите внести изменения, или переписать систему)
❓ какие клиенты есть у системы и
❓ какие сейчас есть потоки данных (например, чтобы отправлять какую-то дополнительную информацию)
❓ кто работает или работал над какой системой, кого спросить или позвать на встречу
❓ какие системы поддерживают какие бизнес-услуги, кто ими пользуется?
и так далее.
Была бы такая база полезна? Сколько бы это времени вам сэкономило?
Я, честно говоря, когда впервые увидел такую штуку, был в полном восхищении. А увидел я её на отборе докладов на Flow: это выступление Романа Цирульникова из ЮMoney. Надеюсь, сегодня вы его тоже посмотрели, называется скромно: "Модель архитектуры предприятия на графе".
Конечно, технологически поддерживать такую базу непросто, и требует определенного уровня зрелости процессов развертывания: всё на скриптах, под контролем и As Code -- чтобы потом по этому коду можно было всё собрать.
Но результат выглядит потрясающе. Кажется, где-то здесь лежит будущее системного анализа (или его погибель, смотря как вы настроены).
Я вот настроен в целом позитивно: мне сегодня исполняется
Осваивайте новые технологии! А я пошел тортик есть
Please open Telegram to view this post
VIEW IN TELEGRAM
🍾33👍9🔥8🎉5❤2