Внимание! Воскресный пост с долей юмора. Что нужно делать в отпуске на даче? Правильно, читать всякие старые книги, которые сюда свезли, чтобы не занимали места в городе. В этом году протащило меня по детективам, и вот что интересно: как отличались реальные методы работы сыщиков и те, что в художественной литературе описаны.
В литературе же как: детектив логическим путём выводит из наблюдений всю картину — дедукция там, то сё. Анализ и синтез в чистом виде: выявить разрозненные факты и составить непротиворечивую модель преступления. В книжках она оказывается, конечно, единственно верной. Основные навыки:
* наблюдение, а также выделение важного и понимание — где какие следы можно искать;
* представление о "жизненном цикле" преступления: что было до, что было во время, какие стадии и фазы проходило, что было после;
* закон сохранения: ничего ни из чего не появляется и никуда не исчезает;
* внимание к таймингу и последовательности действий;
* опросы свидетелей ("В каждом, даже самом безнадежном на первый взгляд деле, всегда найдется человечек, который что–то видел, что-то слышал, что-то знает").
Это всё ооочень похоже на работу аналитика по обследованию деятельности и выявлению процессов: любой процесс оставляет след, нужно знать, где искать. У каждого дела и у каждой системы есть жизненный цикл, нужно думать о всей цепочке, а не только о моменте непосредственного использования. Никакая информация не берется из ниоткуда и не исчезает никуда. Системы и люди действуют последовательно, у каждого дела есть время начала и длительность, ничего не происходит "мгновенно".
Про опросы свидетелей известно, что а) "Все лгут" и б) "Умей внимательно слушать человека и старайся подвинуть его к разговору о нём самом. С первого мига проявляй к человеку искренний интерес". В общем, как в книге "Спроси маму": не спрашивай человека про систему, спрашивай про его задачи и проблемы.
Интересно, что в воспоминаниях реальных сыщиков — например, у Франсуа Видока и Ивана Дмитриевича Путилина — метод описан совсем другой: в основном это переодевание и проникновение в места нахождения преступников или организация провокаций. С точки зрения методов анализа и выявления требований, это называется "включенное наблюдение" или даже "ролевые игры". Близко к этому находятся натурные модели (Видок, в частности, ввел понятие и практику "следственного эксперимента").
А сборка в единую логику всех фактов и пересборка при вновь открывшихся обстоятельствах мне очень напомнило положения книги Криса Партриджа "Business Objects: Re-engineering for Re-use" (BORO) — если встречается новая ситуация в бизнес-задаче или новый частный случай, не влезающий в имеющуюся в ИТ-системе модель — нужно перестроить модель, сделав её более универсальной (а не пытаться вставить новый случай в формате костыля и воркэраунда сбоку — в конце концов запутаешься в этих воркэраундах). BORO изначально про объектное и ER-моделирование, но те же положения актуальны для архитектуры.
В общем, не могу никак отключиться и перестать сравнивать методы и находить аналогии. Но позаимствовать-то есть что!
В литературе же как: детектив логическим путём выводит из наблюдений всю картину — дедукция там, то сё. Анализ и синтез в чистом виде: выявить разрозненные факты и составить непротиворечивую модель преступления. В книжках она оказывается, конечно, единственно верной. Основные навыки:
* наблюдение, а также выделение важного и понимание — где какие следы можно искать;
* представление о "жизненном цикле" преступления: что было до, что было во время, какие стадии и фазы проходило, что было после;
* закон сохранения: ничего ни из чего не появляется и никуда не исчезает;
* внимание к таймингу и последовательности действий;
* опросы свидетелей ("В каждом, даже самом безнадежном на первый взгляд деле, всегда найдется человечек, который что–то видел, что-то слышал, что-то знает").
Это всё ооочень похоже на работу аналитика по обследованию деятельности и выявлению процессов: любой процесс оставляет след, нужно знать, где искать. У каждого дела и у каждой системы есть жизненный цикл, нужно думать о всей цепочке, а не только о моменте непосредственного использования. Никакая информация не берется из ниоткуда и не исчезает никуда. Системы и люди действуют последовательно, у каждого дела есть время начала и длительность, ничего не происходит "мгновенно".
Про опросы свидетелей известно, что а) "Все лгут" и б) "Умей внимательно слушать человека и старайся подвинуть его к разговору о нём самом. С первого мига проявляй к человеку искренний интерес". В общем, как в книге "Спроси маму": не спрашивай человека про систему, спрашивай про его задачи и проблемы.
Интересно, что в воспоминаниях реальных сыщиков — например, у Франсуа Видока и Ивана Дмитриевича Путилина — метод описан совсем другой: в основном это переодевание и проникновение в места нахождения преступников или организация провокаций. С точки зрения методов анализа и выявления требований, это называется "включенное наблюдение" или даже "ролевые игры". Близко к этому находятся натурные модели (Видок, в частности, ввел понятие и практику "следственного эксперимента").
А сборка в единую логику всех фактов и пересборка при вновь открывшихся обстоятельствах мне очень напомнило положения книги Криса Партриджа "Business Objects: Re-engineering for Re-use" (BORO) — если встречается новая ситуация в бизнес-задаче или новый частный случай, не влезающий в имеющуюся в ИТ-системе модель — нужно перестроить модель, сделав её более универсальной (а не пытаться вставить новый случай в формате костыля и воркэраунда сбоку — в конце концов запутаешься в этих воркэраундах). BORO изначально про объектное и ER-моделирование, но те же положения актуальны для архитектуры.
В общем, не могу никак отключиться и перестать сравнивать методы и находить аналогии. Но позаимствовать-то есть что!
👍27🔥13❤4😁2🤔1
В выступлении Димы Безуглого на ЛАФ (посвященного, как обычно, переходу к продуктовому мышлению и переходу задач аналитиков к разработчикам) мне больше всего понравился вопрос из зала: а как же разделение труда, ведь по экономическим законам для повышения производительности каждый работник должен стать специалистом в своем деле, а смежные операции отдать другим. Почему же тогда не усугубляется разделение на аналитиков разных видов и разработчиков, а наоборот — исключение и объединение ролей? (если, конечно, такой эффект действительно наблюдается).
Вопрос интересный и заслуживает отдельного исследования, а не коротокого ответа.
Во-первых, разделение труда в разработке явно есть — как внутри отрасли, так и внутри отдельных компаний. Интересны примеры отраслевого разделения труда — когда часть работы может быть легко заказана у другой компании. Это мы видим повсеместно в части эксплуатации, очень часто — в дизайне, в создании документации, иногда — в тестировании. Очень редко встречается аутсорсинг системного или бизнес-анализа (а вот аутстаффинг бывает чаще), и почти никогда — аутсорсинг архитектуры.
Вот что есть всегда и в любой разработке — разделение труда между авторами библиотек и фреймворков, и авторами конечных решений. Это в чистом виде разделение труда, сюда же можно добавить производителей средств производства: языков, редакторов, средств отладки и мониторинга и т.п.
Так что с разделением труда в разработке всё в порядке. Местами.
Улавливаете точки, в которых промежуточные рабочие продукты могут быть легко переданы? Там, где они формальны и имеют хорошую изоляцию абстракций. Дизайнер передаёт разработчику макет — он формален, его реализацию легко проверить, и он абстрактен — дизайнеру не нужно пояснять, как именно сверстать и запрограммировать код, чтобы на выходе получилась именно эта картинка. Инженерам по эксплуатции не нужно знать — как именно написан код (только его внешние зависимости, в лучшем случае) и что он вообще делает. Тестировщикам не обязательно знать внутреннее устройство программы, чтобы её протестировать.
С аналитиками это тоже срабатывает, если результат формализован. Если на выходе у вас спека в сваггере — вашу работу можно вычленить и отделить от разработки. Наверное.
Вся проблема в протечке абстракций. Они текут и у дизайнеров, и у девопсов, и у QA. Но у аналитиков это просто дырявый зонт. "Закон дырявых абстракций" говорит, что любая нетривиальная абстракция дырява, то есть не может игнорировать способ реализации.
А системные аналитики находятся очень близко к реализации, и граница абстракции вообще начинает плыть. Извечный вопрос: что давать на вход разработчикам? Не слишком абстрактно, чтобы для них вообще было понятно, что делать; и не слишком конкретно, чтобы они не говорили "а на самом деле удобнее и правильнее сделать не так а вот так".
Поэтому в этом месте разделение труда противоестественно, материал сопротивляется.
Этот пост во многом для тех, кто проектирует процессы и определяет шаблоны рабочих продуктов. Проверьте себя: какой уровень абстракции вы выдерживаете в документах? Какие аспекты реализации вы не учитываете? Это в СА не так естественно происходит, как в других областях, поэтому стоит зафиксировать в явном виде: до какого уровня ещё имеет смысл прописывать, а где уже изолируемся от реализации.
Какие формализмы вводим? Хинт: чем их больше, тем легче изолироваться и разделять труд. Формальный текст всегда лучше, чем свободный текст, а ещё лучше — формальная таблица или диаграмма. DSL с проверяемым синтаксисом — ещё лучше. OpenAPI, TypeSpec — вот такие штуки. Vanessa Automation для 1С. Я даже видел, как в некоторых проектах сначала придумывают DSL, а потом все требования и спецификации фиксируют на нём — высокий класс. В принципе, DDD тоже про это отчасти.
Вопрос интересный и заслуживает отдельного исследования, а не коротокого ответа.
Во-первых, разделение труда в разработке явно есть — как внутри отрасли, так и внутри отдельных компаний. Интересны примеры отраслевого разделения труда — когда часть работы может быть легко заказана у другой компании. Это мы видим повсеместно в части эксплуатации, очень часто — в дизайне, в создании документации, иногда — в тестировании. Очень редко встречается аутсорсинг системного или бизнес-анализа (а вот аутстаффинг бывает чаще), и почти никогда — аутсорсинг архитектуры.
Вот что есть всегда и в любой разработке — разделение труда между авторами библиотек и фреймворков, и авторами конечных решений. Это в чистом виде разделение труда, сюда же можно добавить производителей средств производства: языков, редакторов, средств отладки и мониторинга и т.п.
Так что с разделением труда в разработке всё в порядке. Местами.
Улавливаете точки, в которых промежуточные рабочие продукты могут быть легко переданы? Там, где они формальны и имеют хорошую изоляцию абстракций. Дизайнер передаёт разработчику макет — он формален, его реализацию легко проверить, и он абстрактен — дизайнеру не нужно пояснять, как именно сверстать и запрограммировать код, чтобы на выходе получилась именно эта картинка. Инженерам по эксплуатции не нужно знать — как именно написан код (только его внешние зависимости, в лучшем случае) и что он вообще делает. Тестировщикам не обязательно знать внутреннее устройство программы, чтобы её протестировать.
С аналитиками это тоже срабатывает, если результат формализован. Если на выходе у вас спека в сваггере — вашу работу можно вычленить и отделить от разработки. Наверное.
Вся проблема в протечке абстракций. Они текут и у дизайнеров, и у девопсов, и у QA. Но у аналитиков это просто дырявый зонт. "Закон дырявых абстракций" говорит, что любая нетривиальная абстракция дырява, то есть не может игнорировать способ реализации.
А системные аналитики находятся очень близко к реализации, и граница абстракции вообще начинает плыть. Извечный вопрос: что давать на вход разработчикам? Не слишком абстрактно, чтобы для них вообще было понятно, что делать; и не слишком конкретно, чтобы они не говорили "а на самом деле удобнее и правильнее сделать не так а вот так".
Поэтому в этом месте разделение труда противоестественно, материал сопротивляется.
Этот пост во многом для тех, кто проектирует процессы и определяет шаблоны рабочих продуктов. Проверьте себя: какой уровень абстракции вы выдерживаете в документах? Какие аспекты реализации вы не учитываете? Это в СА не так естественно происходит, как в других областях, поэтому стоит зафиксировать в явном виде: до какого уровня ещё имеет смысл прописывать, а где уже изолируемся от реализации.
Какие формализмы вводим? Хинт: чем их больше, тем легче изолироваться и разделять труд. Формальный текст всегда лучше, чем свободный текст, а ещё лучше — формальная таблица или диаграмма. DSL с проверяемым синтаксисом — ещё лучше. OpenAPI, TypeSpec — вот такие штуки. Vanessa Automation для 1С. Я даже видел, как в некоторых проектах сначала придумывают DSL, а потом все требования и спецификации фиксируют на нём — высокий класс. В принципе, DDD тоже про это отчасти.
🤔15👍9👏3❤2🔥2
Одним из последних проектов у меня была проработка требований и проектных решений системы по построению управленческой отчетности.
Работа шла с нуля, поэтому набор артефактов получился вот такой:
1. Требования к бизнесу: что бизнес должен делать с точки зрения государственных органов, владельца, клиентов и подрядчиков. Систем здесь нет, это самый абстрактный уровень. Тут выявляем роли, которые отвечают за выполнение требований. Обычно это топы.
2. Мотивации и цепочка создания ценности. В этот раз не делал, но вообще нужно, и хорошо моделируется через Strategy Layer и Motivation Layer в Archimate™. Поток ценности — это вернеуровневый процесс компании + бизнес-возможности (capability). Мотивация показывает, кому и почему нужен этот проект и эта отчетность. Требования к бизнесу транслируются обычно в драйверы, управляющие мотивацией.
3. Бизнес-требования. Из мотивации ролей становятся видны бизнес-требования. Мы их записывали в виде юзер-сторей, но с добавлением: какое решение я, как роль, должен принять по этому значению или изменению этого показателя, какие действия я буду совершать? Это одна из самых трудных частей, потому что требует глубокой рефлексии от стейкхолдера, а то обычно получается "мне нужно видеть число продаж, чтобы скорректировать продажи" — понятно, что "скорректировать" здесь просто наукообразный синоним "ну, что-то с ними сделать". Что именно сделать — неплохо бы всё-таки выяснить, может, нужно дополнительные показатели вывести для принятия решения.
4. Реестр показателей. Это ключевой артефакт. Берем названия показателей из бизнес-требований, уточняем — как именно нам показатель нужно отображать:
— в абсолютных числах?
— в долях/процентах? (от чего?)
— как среднее?
— в сравнении (с чем?)
— в динамике?
— выбросы? (значительные отклонения)
В каких разрезах нас интересует каждый показатель? Тут мы выявляем структуру бизнеса, то, что называется основными данными и справочниками. Реестр показателей мы будем обогащать дополнительной информацией.
5. Добавляем в реестр, во-первых, владельцев показателя (из потока ценности) и связанные БТ. Во-вторых — систему-источник, в которой этот показатель впервые появляется. Потом добавим конкретное поле в конкретной таблице, или формулу расчета. Как правило, здесь возникают интересные вопросы, у нас, например, был вопрос — какой датой учитывать платеж для управленческих целей.
Здесь развилка: в одном направлении прорабатываем системы, в другом — состав и визуал отчетов/дэшбордов/оповещений. Начинаем с самого важного, для этого просим стейкхолдеров расставить приоритеты показателям.
6а. Раз мы добрались до систем, и нам нужен их реестр — с указанием, для каких данных это первоисточник. Также нам понадобится диаграмма потоков данных или sequence. Заодно здесь выявляем ручной перенос данных и всякие эксельки, на которых всё держится. Потом посмотрим, откуда удобнее брать данные для наполнения отчетов.
6б. Рисуем отчеты, как бы они могли выглядеть в идеале, без привязки к конкретному инструменту. Тут мы можем объединить показатели, которые раньше разделили, поэтому отчетов может получиться меньше.
В реестре отчетов для каждого указываем:
— назначение (для чего он);
— связь с бизнес-требованиями;
— основной объект, от которого строится отчет;
— вид отчета (плоская таблица или сводная);
— поля таблицы (для сводной — по вертикали и по горизонтали + формулы показателей на пересечении);
— агрегаты под строками (сумма, среднее и т.п.)
— возможные группировки;
— куда можно провалиться из строки отчета (drill down);
— откуда брать данные;
— какие справочники и какие основные данные в отчете используются;
— внешний вид отчета (мы моделировали в Google Sheets).
Отсюда начинается встречное движение — что и как мы хотим показать, и что позволяет сделать выбранный инструмент.
Про системный анализ, выбор архитектуры и инструментов напишу в следующей части, пост и так получился огромный.
Работа шла с нуля, поэтому набор артефактов получился вот такой:
1. Требования к бизнесу: что бизнес должен делать с точки зрения государственных органов, владельца, клиентов и подрядчиков. Систем здесь нет, это самый абстрактный уровень. Тут выявляем роли, которые отвечают за выполнение требований. Обычно это топы.
2. Мотивации и цепочка создания ценности. В этот раз не делал, но вообще нужно, и хорошо моделируется через Strategy Layer и Motivation Layer в Archimate™. Поток ценности — это вернеуровневый процесс компании + бизнес-возможности (capability). Мотивация показывает, кому и почему нужен этот проект и эта отчетность. Требования к бизнесу транслируются обычно в драйверы, управляющие мотивацией.
3. Бизнес-требования. Из мотивации ролей становятся видны бизнес-требования. Мы их записывали в виде юзер-сторей, но с добавлением: какое решение я, как роль, должен принять по этому значению или изменению этого показателя, какие действия я буду совершать? Это одна из самых трудных частей, потому что требует глубокой рефлексии от стейкхолдера, а то обычно получается "мне нужно видеть число продаж, чтобы скорректировать продажи" — понятно, что "скорректировать" здесь просто наукообразный синоним "ну, что-то с ними сделать". Что именно сделать — неплохо бы всё-таки выяснить, может, нужно дополнительные показатели вывести для принятия решения.
4. Реестр показателей. Это ключевой артефакт. Берем названия показателей из бизнес-требований, уточняем — как именно нам показатель нужно отображать:
— в абсолютных числах?
— в долях/процентах? (от чего?)
— как среднее?
— в сравнении (с чем?)
— в динамике?
— выбросы? (значительные отклонения)
В каких разрезах нас интересует каждый показатель? Тут мы выявляем структуру бизнеса, то, что называется основными данными и справочниками. Реестр показателей мы будем обогащать дополнительной информацией.
5. Добавляем в реестр, во-первых, владельцев показателя (из потока ценности) и связанные БТ. Во-вторых — систему-источник, в которой этот показатель впервые появляется. Потом добавим конкретное поле в конкретной таблице, или формулу расчета. Как правило, здесь возникают интересные вопросы, у нас, например, был вопрос — какой датой учитывать платеж для управленческих целей.
Здесь развилка: в одном направлении прорабатываем системы, в другом — состав и визуал отчетов/дэшбордов/оповещений. Начинаем с самого важного, для этого просим стейкхолдеров расставить приоритеты показателям.
6а. Раз мы добрались до систем, и нам нужен их реестр — с указанием, для каких данных это первоисточник. Также нам понадобится диаграмма потоков данных или sequence. Заодно здесь выявляем ручной перенос данных и всякие эксельки, на которых всё держится. Потом посмотрим, откуда удобнее брать данные для наполнения отчетов.
6б. Рисуем отчеты, как бы они могли выглядеть в идеале, без привязки к конкретному инструменту. Тут мы можем объединить показатели, которые раньше разделили, поэтому отчетов может получиться меньше.
В реестре отчетов для каждого указываем:
— назначение (для чего он);
— связь с бизнес-требованиями;
— основной объект, от которого строится отчет;
— вид отчета (плоская таблица или сводная);
— поля таблицы (для сводной — по вертикали и по горизонтали + формулы показателей на пересечении);
— агрегаты под строками (сумма, среднее и т.п.)
— возможные группировки;
— куда можно провалиться из строки отчета (drill down);
— откуда брать данные;
— какие справочники и какие основные данные в отчете используются;
— внешний вид отчета (мы моделировали в Google Sheets).
Отсюда начинается встречное движение — что и как мы хотим показать, и что позволяет сделать выбранный инструмент.
Про системный анализ, выбор архитектуры и инструментов напишу в следующей части, пост и так получился огромный.
🔥26👍8❤2
Проектирование системы управленческой отчетности, часть 2.
Итак, у нас есть реестр систем и набор показателей, которые нам нужно выводить.
Теперь нужно понять, как это лучше сделать. Вариантов три:
— вытащить все данные из всех систем в отдельное аналитическое хранилище, нормализовать и уже к нему прикрутить любую систему построения отчетности;
— выбрать систему, в которой уже есть большинство данных и средства для построения отчетов (в данном случае это был, например, Битрикс24), и попробовать втащить туда недостающие данные;
— "размазать" отчеты по системам: если данные есть в одной системе, и там же можно построить отчет — строим там. Если нужны данные из двух систем, которые ими не обмениваются сейчас — вытаскиваем данные в отдельное хранилище и строим отчет там.
Решения отличаются по скорости реализации и по системности: можно быстро нашлепать отчетов в тех системах, где данные уже есть, но этим не очень удобно пользоваться; можно выстроить нормальную систему ETL, аналитическое хранилище и дэшборды.
Напомню, что у нас было две развилки: анализ существующих систем (а) и анализ абстрактных требований к отчетам (б). Идём по ним так:
7б. На основе реестра отчетов и их макетов формируем требования к системе построения отчетности — для последующего выбора. Просто функциональные требования к системе.
7а. Смотрим, какие есть возможности систем-источников (отдельный документ): внешние API, в том числе вебхуки; какие можно делать выгрузки (в Excel, CSV, 1С), можно ли добраться до БД. Описываем все варианты интерфейсов, для каждого указываем нюансы использования и состав данных, имеющиеся ошибки. Например, Битрикс24 в вебхуках отдает только ID изменившегося объекта, но не говорит, что именно изменилось. А в выгрузке он запросто может отдать две строки для одной сделки, в которых будут одинаковые идентификаторы, одинаковые идентификаторы товара, но разные названия и разная стоимость. Вот все такие штуки мы фиксируем в ещё одном документе:
8. Недостающая информация и проблемы. У нас могут быть проблемы надежности выгрузки, недостаток данных, разные идентификаторы, дублирование или склеивание записей, отсутствие идентификаторов, дублирование идентификаторов; разный формат вводимых вручную идентификаторов; нерегулярность учетной модели (когда сделка фактически завершена, но в системе это не отражается, "все и так знают"); неоднозначность источника данных: одна и та же информация может быть записана в разных полях (для такого типа сделки смотри число товаров в этом поле, а для другого — в этом поле не смотри, там бред, смотри в дополнительной таблице, или признак оплаты, который может быть отмечен в четырех разных полях); значимая информация в комментариях в произвольном формате; в принципе отсутствие в электронном виде информации или классификаторов; нарушенная ссылочная целостность — и наверняка я забыл ещё множество других проблем с качеством данных. Без приведения в порядок структуры и содержания данных никакую достоверную отчетность мы не соберем.
9. Поэтому имеет смысл построить эталонную концептуальную модель данных бизнеса — инфологическую, то есть без опоры на какую-либо технологию. Сделать из неё базу данных и попробовать наполнить её реальными данными из бизнеса — узнаем много интересного. Физическая модель может быть в итоге совсем другой — Data Vault, или анкорной, или ещё какой.
10. Выбираем системы для построения отчетов (дэшбордов), в том числе встроенные в имеющиеся системы (к Битриксу, скажем, недавно прикрутили несколько урезанный Apache Superset), пытаемся в них собрать нужные нам отчеты и опытным путем проверить возможность реализации требований из п 7б. Заодно проверяем на дружелюбие к пользователю и понятность.
Итак, у нас есть реестр систем и набор показателей, которые нам нужно выводить.
Теперь нужно понять, как это лучше сделать. Вариантов три:
— вытащить все данные из всех систем в отдельное аналитическое хранилище, нормализовать и уже к нему прикрутить любую систему построения отчетности;
— выбрать систему, в которой уже есть большинство данных и средства для построения отчетов (в данном случае это был, например, Битрикс24), и попробовать втащить туда недостающие данные;
— "размазать" отчеты по системам: если данные есть в одной системе, и там же можно построить отчет — строим там. Если нужны данные из двух систем, которые ими не обмениваются сейчас — вытаскиваем данные в отдельное хранилище и строим отчет там.
Решения отличаются по скорости реализации и по системности: можно быстро нашлепать отчетов в тех системах, где данные уже есть, но этим не очень удобно пользоваться; можно выстроить нормальную систему ETL, аналитическое хранилище и дэшборды.
Напомню, что у нас было две развилки: анализ существующих систем (а) и анализ абстрактных требований к отчетам (б). Идём по ним так:
7б. На основе реестра отчетов и их макетов формируем требования к системе построения отчетности — для последующего выбора. Просто функциональные требования к системе.
7а. Смотрим, какие есть возможности систем-источников (отдельный документ): внешние API, в том числе вебхуки; какие можно делать выгрузки (в Excel, CSV, 1С), можно ли добраться до БД. Описываем все варианты интерфейсов, для каждого указываем нюансы использования и состав данных, имеющиеся ошибки. Например, Битрикс24 в вебхуках отдает только ID изменившегося объекта, но не говорит, что именно изменилось. А в выгрузке он запросто может отдать две строки для одной сделки, в которых будут одинаковые идентификаторы, одинаковые идентификаторы товара, но разные названия и разная стоимость. Вот все такие штуки мы фиксируем в ещё одном документе:
8. Недостающая информация и проблемы. У нас могут быть проблемы надежности выгрузки, недостаток данных, разные идентификаторы, дублирование или склеивание записей, отсутствие идентификаторов, дублирование идентификаторов; разный формат вводимых вручную идентификаторов; нерегулярность учетной модели (когда сделка фактически завершена, но в системе это не отражается, "все и так знают"); неоднозначность источника данных: одна и та же информация может быть записана в разных полях (для такого типа сделки смотри число товаров в этом поле, а для другого — в этом поле не смотри, там бред, смотри в дополнительной таблице, или признак оплаты, который может быть отмечен в четырех разных полях); значимая информация в комментариях в произвольном формате; в принципе отсутствие в электронном виде информации или классификаторов; нарушенная ссылочная целостность — и наверняка я забыл ещё множество других проблем с качеством данных. Без приведения в порядок структуры и содержания данных никакую достоверную отчетность мы не соберем.
9. Поэтому имеет смысл построить эталонную концептуальную модель данных бизнеса — инфологическую, то есть без опоры на какую-либо технологию. Сделать из неё базу данных и попробовать наполнить её реальными данными из бизнеса — узнаем много интересного. Физическая модель может быть в итоге совсем другой — Data Vault, или анкорной, или ещё какой.
10. Выбираем системы для построения отчетов (дэшбордов), в том числе встроенные в имеющиеся системы (к Битриксу, скажем, недавно прикрутили несколько урезанный Apache Superset), пытаемся в них собрать нужные нам отчеты и опытным путем проверить возможность реализации требований из п 7б. Заодно проверяем на дружелюбие к пользователю и понятность.
👍12
Результаты оцениваем, и принимаем решение по архитектуре (вытаскивать всё в отдельное хранилище, или наоборот — втаскивать недостающую информацию в систему, где уже есть большинство данных). Тут может понадобиться ещё одна диаграмма мотивации — теперь уже для выбора архитектуры. Одновременно нужно выработать набор решений и действий по устранению проблем в данных (как организационных, так и технических).
Вот такой обширный список работ, наверняка не совсем полный, но я не видел такого развернутого алгоритма. На последнем ЛАФе Александр Чавалах давал мастер-класс по этой теме, наверняка тоже приводил алгоритм, к сожалению, я на МК не попал, надеюсь на запись. Пока выглядит так, что задача несколько сложнее обычных публикаций в стиле "выберите адекватный показатель и способ его визуализации".
Вот такой обширный список работ, наверняка не совсем полный, но я не видел такого развернутого алгоритма. На последнем ЛАФе Александр Чавалах давал мастер-класс по этой теме, наверняка тоже приводил алгоритм, к сожалению, я на МК не попал, надеюсь на запись. Пока выглядит так, что задача несколько сложнее обычных публикаций в стиле "выберите адекватный показатель и способ его визуализации".
👍14
Число подписчиков канала перевалило за 5000! Спасибо вам! 🙏🏻
Канал, который я завел для выкладки материалов к докладам, живет и развивается — благодаря вам! По вашим реакциям и комментариям я вижу востребованность того, о чем пишу, и это очень круто. Надеюсь, мои мысли, наблюдения и советы вам интересны, а осенью я собираюсь с новыми силами продолжить развивать свои основные темы: смысл работы аналитиков и других ролей в создании ПО, объяснение сложных концепций простыми словами, инструменты, подходы, чек-листы и прихватки в работе аналитика, неочевидные идеи и истории, и, конечно, использование ИИ в работе.
Не переключайтесь, у меня есть ещё много идей. Когда-то давно я был на конференции АИСТ, и в одном из докладов ребята рассказывали, как пытались проанализировать — чем отличаются посты популярных блогеров? Оказалось, что нельзя выделить какие-то общие критерии: ни особые темы, ни длину сообщений, ни употребляемые слова, ни наличие картинок в посте... Кроме одного — частоту постов. Когда я начинал вести канал, мне казалось, что писать-то особо не о чем. А сейчас я пишу посты почти каждый день, и темы для них не заканчиваются! Это удивительно и для меня самого, а вам, надеюсь, интересно.
Так что читайте, применяйте то, о чем я пишу, задавайте вопросы, а я буду продолжать радовать и удивлять вас.
Ну а в честь такого круглого числа хочу сделать вам подарок: я знаю, у многих есть свои каналы — напишите про них в комментариях к этому посту, а про самые интересные каналы я напишу отдельным постом со своими комментариями. Пусть и у вас будет праздник!
Канал, который я завел для выкладки материалов к докладам, живет и развивается — благодаря вам! По вашим реакциям и комментариям я вижу востребованность того, о чем пишу, и это очень круто. Надеюсь, мои мысли, наблюдения и советы вам интересны, а осенью я собираюсь с новыми силами продолжить развивать свои основные темы: смысл работы аналитиков и других ролей в создании ПО, объяснение сложных концепций простыми словами, инструменты, подходы, чек-листы и прихватки в работе аналитика, неочевидные идеи и истории, и, конечно, использование ИИ в работе.
Не переключайтесь, у меня есть ещё много идей. Когда-то давно я был на конференции АИСТ, и в одном из докладов ребята рассказывали, как пытались проанализировать — чем отличаются посты популярных блогеров? Оказалось, что нельзя выделить какие-то общие критерии: ни особые темы, ни длину сообщений, ни употребляемые слова, ни наличие картинок в посте... Кроме одного — частоту постов. Когда я начинал вести канал, мне казалось, что писать-то особо не о чем. А сейчас я пишу посты почти каждый день, и темы для них не заканчиваются! Это удивительно и для меня самого, а вам, надеюсь, интересно.
Так что читайте, применяйте то, о чем я пишу, задавайте вопросы, а я буду продолжать радовать и удивлять вас.
Ну а в честь такого круглого числа хочу сделать вам подарок: я знаю, у многих есть свои каналы — напишите про них в комментариях к этому посту, а про самые интересные каналы я напишу отдельным постом со своими комментариями. Пусть и у вас будет праздник!
❤37🎉19👏6👍2🤩1
На ЛАФ рассказывал про историю UML, про его взлеты и падения, и совсем чуть-чуть про исследование его актуальности.
На Flow буду рассказывать прицельно про результаты: https://flowconf.ru/talks/5a9403b9ba8c43609a30da8eab1897d2/
Уже можно сказать, что результаты расходятся с немецкими исследованиями 2014 и 2017 годов: в 2024 в РФ аналитики используют UML чаще; почти всегда рисуют формальные диаграммы; используют Use Case Diagram чаще, чем Class Diagram и всегда сохраняют созданные диаграммы для будущего использования или документации.
Не собираюсь в этом году как-то сильно поражать воображение слушателей, на мой взгляд, в программе есть много гораздо более сильных докладов. Честно говоря, работа в ПК оказывается довольно тяжёлой, даже не представляю, как справляются люди, которые в трёх конференциях в программных комитетах — это же как ещё одна работа!
В общем, встречаемся в Питере и в онлайне. Многим из вас, наверное, участие оплатит компания, ну а те, кто едет сам — пишите мне в личку, выдам промокод на скидку 25%! 🎫
На Flow буду рассказывать прицельно про результаты: https://flowconf.ru/talks/5a9403b9ba8c43609a30da8eab1897d2/
Уже можно сказать, что результаты расходятся с немецкими исследованиями 2014 и 2017 годов: в 2024 в РФ аналитики используют UML чаще; почти всегда рисуют формальные диаграммы; используют Use Case Diagram чаще, чем Class Diagram и всегда сохраняют созданные диаграммы для будущего использования или документации.
Не собираюсь в этом году как-то сильно поражать воображение слушателей, на мой взгляд, в программе есть много гораздо более сильных докладов. Честно говоря, работа в ПК оказывается довольно тяжёлой, даже не представляю, как справляются люди, которые в трёх конференциях в программных комитетах — это же как ещё одна работа!
В общем, встречаемся в Питере и в онлайне. Многим из вас, наверное, участие оплатит компания, ну а те, кто едет сам — пишите мне в личку, выдам промокод на скидку 25%! 🎫
Flow 2024 Autumn. Конференция по системному и бизнес-анализу
UML и другие графические нотации: что актуально в 2024 году? Исследование, мнения, практика | Доклад на Flow 2024 Autumn
Какие графические нотации использовать в 2024 году? Актуален ли еще UML? Что говорят сами аналитики об этом? Результаты исследования — в докладе.
👍4🔥3❤2
Тут в одном чате аналитиков с удивлением прочитал вопрос: аналитики, а вы занимаетесь сбором и фиксацией требований? От человека, который не очень давно аналитиком работает, на курсах его сбору требований учили, но на практике это ему не нужно.
И в ответ, от многих: нет, никакие требования не собираем, ничего такого не делаем. Ну так, поговорим, бывает, с пользователями, и пишем постановку.
Кто-то с гордостью(!) говорит, что ни требований никогда в глаза не видел, ни диаграмм никаких не рисовал никогда.
Это, конечно, требует корректировки учебных программ, если на самом деле так.
Поэтому опрос (следующим постом): а чем вы в повседневной работе занимаетесь?
И в ответ, от многих: нет, никакие требования не собираем, ничего такого не делаем. Ну так, поговорим, бывает, с пользователями, и пишем постановку.
Кто-то с гордостью(!) говорит, что ни требований никогда в глаза не видел, ни диаграмм никаких не рисовал никогда.
Это, конечно, требует корректировки учебных программ, если на самом деле так.
Поэтому опрос (следующим постом): а чем вы в повседневной работе занимаетесь?
😁3
Чем вы занимаетесь в повседневной работе, как аналитик?
Anonymous Poll
61%
Собираю требования со стейкхолдеров/пользователей
71%
Фиксирую требования
65%
Прорабатываю проектные решения
55%
Строю диаграммы
76%
Пишу документацию
34%
Проектирую архитектуру
46%
Проектирую API
2%
Ничего из этого (напишу в комментах)
7%
Делаю совсем другое (напишу в комментах)
👍4
Интересно — на первом месте ответ "Пишу документацию". Сформулировано, конечно, максимально общо, а что вы под этим подразумеваете?
На мой взгляд, документация — это когда уже зафиксированы решения, а может даже всё уже сделано. И тут возникает, мне кажется, ключевой вопрос: вы фиксируете в документации решения, принятые вами, или кем-то другим (тогда кем, что это за роль?).
И если другими — ваша задача просто зафиксировать/описать решения, или же так организовать всех, чтобы нужные решения были приняты, и приняты с учетом всех аспектов, нюансов и последствий? Я и в своей работе, и в процессе менторинга/консультаций постоянно встречаюсь с этой задачей аналитика: организовать пространство и процесс принятия решений. Всех собрать, всем дать полную картину (или нужные им части, например, по безопасности, НФТ или изменению нормативки), организовать процесс.
Кажется, это тоже невидимая работа (а работа эта непростая!), о которой молчат на курсах и которую не замечают и не ценят руководители. "Ну ты собери совещание, и всё решите там". Угу, чего там говорить, само всё произойдет.
На мой взгляд, документация — это когда уже зафиксированы решения, а может даже всё уже сделано. И тут возникает, мне кажется, ключевой вопрос: вы фиксируете в документации решения, принятые вами, или кем-то другим (тогда кем, что это за роль?).
И если другими — ваша задача просто зафиксировать/описать решения, или же так организовать всех, чтобы нужные решения были приняты, и приняты с учетом всех аспектов, нюансов и последствий? Я и в своей работе, и в процессе менторинга/консультаций постоянно встречаюсь с этой задачей аналитика: организовать пространство и процесс принятия решений. Всех собрать, всем дать полную картину (или нужные им части, например, по безопасности, НФТ или изменению нормативки), организовать процесс.
Кажется, это тоже невидимая работа (а работа эта непростая!), о которой молчат на курсах и которую не замечают и не ценят руководители. "Ну ты собери совещание, и всё решите там". Угу, чего там говорить, само всё произойдет.
👍15🔥5
В канале я пишу в основном про системный анализ и для аналитиков — так получилось, да и занимаюсь я в последнее время именно этим. Про управление продуктами, например, почти не пишу. Но много читаю, и есть каналы, которые раскрывают тему более чем исчерпывающе.
Например, я давно читаю канал Тиграна Басеяна Black Product Owner.
Материала там — хватит на целый курс по управлению продуктом. Вот, например, пост с разными картами компетенций продакта и инструментами их оценки.
А вот — серия постов про юнит-экономику простыми словами.
Или вот модель оценки зрелости продуктового управления — даже если вы не продакт, замените "управление продуктом" на "системный анализ", и оцените зрелость своей компании.
Ну и прекрасная серия постов про всякие штуки разных сервисов, разбор продуктовых кейсов под тегом #миниресерч — насмотренность и творческое заимствование очень важны для продакта.
В общем, рекомендую! Подписывайтесь, если тема управления продуктами вам интересна!
https://news.1rj.ru/str/blackproduct
Например, я давно читаю канал Тиграна Басеяна Black Product Owner.
Материала там — хватит на целый курс по управлению продуктом. Вот, например, пост с разными картами компетенций продакта и инструментами их оценки.
А вот — серия постов про юнит-экономику простыми словами.
Или вот модель оценки зрелости продуктового управления — даже если вы не продакт, замените "управление продуктом" на "системный анализ", и оцените зрелость своей компании.
Ну и прекрасная серия постов про всякие штуки разных сервисов, разбор продуктовых кейсов под тегом #миниресерч — насмотренность и творческое заимствование очень важны для продакта.
В общем, рекомендую! Подписывайтесь, если тема управления продуктами вам интересна!
https://news.1rj.ru/str/blackproduct
Telegram
Black product owner | Тигран Басеян о продакт менеджменте и стартапах
Руководитель МТС Линк Доски, ceo geekz.ru, преподаватель ВШЭ
Пишу о продакстве, менеджменте и стартапах
по поводу сотрудничества: @tintobro
вакансии: @black_vacancies #23VCV
РКН: https://www.gosuslugi.ru/snet/673f40aac577eb7c520d6ccf
Пишу о продакстве, менеджменте и стартапах
по поводу сотрудничества: @tintobro
вакансии: @black_vacancies #23VCV
РКН: https://www.gosuslugi.ru/snet/673f40aac577eb7c520d6ccf
👍10
Сам ещё раз перечитал про управление продуктами, и подумал, что есть такие области, про которые как-то нечасто вспоминают, но которые очень важны для продакта (а аналитики с ними либо вообще не сталкиваются, либо очень по касательной). Это вот что:
* Customer Development Inrerview. Совсем не то же самое, что интервью с пользователем по выяснению деталей бизнес-процесса и сбору требований. Тут вы обычно говорите с людьми, которым вообще ничего не надо, либо надо что-то совсем другое, либо они поддержат любую вашу идею, просто потому, что они хорошо к вам относятся. Главное отличие тут — ничего не спрашивать про продукт и вообще не говорить о нем. Классическая книга — “Спроси маму” Роба Фитцпатрика (она и аналитикам полезна).
* UX, а особенно — два аспекта: 1) что происходит в голове у пользователя, какая у него ментальная модель и какие чувства, и 2) тексты в интерфейсах. На удивление, это серая зона — тексты в интерфейсах не умеют писать ни дизайнеры, ни копирайтеры, ни уж тем более аналитики. Вообще это отдельная специальность — UX-редактор, но в РФ её практически нет. Тут могу порекомендовать Иру Моторину, её канал — https://news.1rj.ru/str/redachredach
* Legal Compliance & Ethics. Соблюдение регуляторных требований и этика. Сюда же — безопасность и защита пользовательских данных. Не знаю, что здесь порекомендовать, если знаете что-то стоящее — напишите в комментах. Это про юридическую обвязку, пользовательские соглашения, перс. данные, куки и т.п. Про этику вообще никто ничего нигде не рассказывает, только в обсуждениях скандалов и можно пощупать тему. Кстати, в BABOK есть раздел "Этика", кто его читал/помнит?
* Поддержка пользователей / Customer Success. Тоже серая зона, но по моему опыту, часто попадает в ведение продакта (потому что больше никому не надо). В любом случае, взаимодействие со службой поддержки — кладезь продуктовых кейсов и инсайтов.
* Метрики и аналитика — тут понятно, и это очень связано с юнит-экономикой.
* Ценообразование. Какую цену на продукт вообще поставить? Тут много материалов из институтских курсов по экономике/маркетингу, но они мало помогают. В каждом конкретном случае всё индивидуально.
* Маркетинг в разных видах ("а чем ваш продакт вообще отличается от хорошего маркетолога?"), а особенно — контентный маркетинг. Ваш продукт (и вы сами) — медиа, действуйте соответственно. Я тут читаю Катю Макарову https://news.1rj.ru/str/everythingpersonal и Линор Горалик https://news.1rj.ru/str/thecontentisthequeen
* Стратегия. Черт его знает, что это, но заниматься в какой-то момент приходится. В общем, это про то, что мы делаем и зачем, а чего мы точно делать не будем. Мне тут нравится подход Бориса Вольфсона, про который он рассказывал на WAW, а я писал https://news.1rj.ru/str/systemswing/315
Ещё продакту, а особенно CPO, хорошо бы разбираться в корпоративном управлении и политике, потому что он отвечает за успех продукта, а перед кем он отвечает? Перед владельцем или владельцами, которых в стартапе обычно несколько. Но это уже тема отдельного разговора.
* Customer Development Inrerview. Совсем не то же самое, что интервью с пользователем по выяснению деталей бизнес-процесса и сбору требований. Тут вы обычно говорите с людьми, которым вообще ничего не надо, либо надо что-то совсем другое, либо они поддержат любую вашу идею, просто потому, что они хорошо к вам относятся. Главное отличие тут — ничего не спрашивать про продукт и вообще не говорить о нем. Классическая книга — “Спроси маму” Роба Фитцпатрика (она и аналитикам полезна).
* UX, а особенно — два аспекта: 1) что происходит в голове у пользователя, какая у него ментальная модель и какие чувства, и 2) тексты в интерфейсах. На удивление, это серая зона — тексты в интерфейсах не умеют писать ни дизайнеры, ни копирайтеры, ни уж тем более аналитики. Вообще это отдельная специальность — UX-редактор, но в РФ её практически нет. Тут могу порекомендовать Иру Моторину, её канал — https://news.1rj.ru/str/redachredach
* Legal Compliance & Ethics. Соблюдение регуляторных требований и этика. Сюда же — безопасность и защита пользовательских данных. Не знаю, что здесь порекомендовать, если знаете что-то стоящее — напишите в комментах. Это про юридическую обвязку, пользовательские соглашения, перс. данные, куки и т.п. Про этику вообще никто ничего нигде не рассказывает, только в обсуждениях скандалов и можно пощупать тему. Кстати, в BABOK есть раздел "Этика", кто его читал/помнит?
* Поддержка пользователей / Customer Success. Тоже серая зона, но по моему опыту, часто попадает в ведение продакта (потому что больше никому не надо). В любом случае, взаимодействие со службой поддержки — кладезь продуктовых кейсов и инсайтов.
* Метрики и аналитика — тут понятно, и это очень связано с юнит-экономикой.
* Ценообразование. Какую цену на продукт вообще поставить? Тут много материалов из институтских курсов по экономике/маркетингу, но они мало помогают. В каждом конкретном случае всё индивидуально.
* Маркетинг в разных видах ("а чем ваш продакт вообще отличается от хорошего маркетолога?"), а особенно — контентный маркетинг. Ваш продукт (и вы сами) — медиа, действуйте соответственно. Я тут читаю Катю Макарову https://news.1rj.ru/str/everythingpersonal и Линор Горалик https://news.1rj.ru/str/thecontentisthequeen
* Стратегия. Черт его знает, что это, но заниматься в какой-то момент приходится. В общем, это про то, что мы делаем и зачем, а чего мы точно делать не будем. Мне тут нравится подход Бориса Вольфсона, про который он рассказывал на WAW, а я писал https://news.1rj.ru/str/systemswing/315
Ещё продакту, а особенно CPO, хорошо бы разбираться в корпоративном управлении и политике, потому что он отвечает за успех продукта, а перед кем он отвечает? Перед владельцем или владельцами, которых в стартапе обычно несколько. Но это уже тема отдельного разговора.
👍9🤡3❤2
Когда говоришь о продуктовом подходе, у аналитиков бывает отторжение: ну, это про всякие магазины / приложения, а у нас — внутренняя автоматизация, нам это всё ни к чему. У нашего пользователя нет выбора — использовать наш продукт или не использовать. На ЛАФ была отличная заявка на доклад про метрики внутренних продуктов, жаль, автор снял доклад. Надеюсь, ещё где-нибудь расскажет.
Идея там была в том, что хорошо бы к своим внутренним системам тоже относиться, как к продуктам, и на их метрики смотреть. В конце концов, даже внутри компании часто есть выбор — пользоваться вашей системой или потихоньку её саботировать. Или всё делать в удобной эксельке, а вашу систему потом вносить для отчетности. И экономический смысл во внутренних продуктах бывает: в сокращении времени, увеличении скорости прохода или производительности бизнес-процесса, да и про удовлетворенность спросить не помешает.
Вот метрика удовлетворенности как раз может быть очень важна для внутренних продуктов: да, работники обязаны пользоваться вашей системой, но при её использовании они мучаются или кайфуют? Как мы знаем, есть классические метрики NPS (Net Promoter Score) и CSAT/CSI (Customer Satisfaction Score/Index). Первую для внутренних продуктов применять немного бессмысленно ("Порекомендовали бы вы наш продукт своим друзьям?" — может и да, но как?). CSI лучше — поможет понять, как пользователь относится к вашей системе. Это такой опросник из двух частей: насколько вы удовлетворены каким-то аспектом работы системы (скоростью, удобством, поиском, созданием <чего-то> и т.п.)? И насколько важен для вас этот параметр?
Тут уже можно получить инсайты. Если в системе много пользователей, можно точечно спрашивать, насколько они удовлетворены конкретной функцией ("насколько вы довольны функцией поиска документа? Оцените по шкале от 1 до 5") — это CSAT. Так можно оценить каждую функцию отдельно. (Если пользователей у системы меньше 50 — проще с ними просто поговорить. Помним, что продуктовые методы начинают работать, когда мы физически не имеем возможности опросить каждого пользователя за разумное время).
Ещё для внутренних продуктов интересно спросить про усилия. Это будет CES — Customer Effort Score. Вопрос похож на CSAT, но немного другой: "насколько просто вам было найти документ? Оцените по шкале от 1 до 5, где 1 — очень сложно, а 5 — очень легко".
Но самая главная (на мой взгляд) метрика, говорящая об успешности системы, не имеет названия и мало где упоминается. Как одним вопросом понять, всё ли хорошо с вашим продуктом? Есть ли "product/market fit", за которым гоняются все стартаперы? Для них это вопрос выживания, для внутренних систем — вопрос капитала. Ваши пользователи — они за вас, или против?
Вот этот вопрос: "Что вы почувствуете, если больше не сможете пользоваться системой X?" С вариантами ответа: "Очень расстроюсь"; "Немного расстроюсь"; "Совсем не расстроюсь";
Простой вопрос, показывающий попадание системы в пользователя. Когда-то я сам набрел примерно на этот вопрос, но ответы были открытые, и звучали как "да я уже не представляю, как без этой системы работать", "это как третья рука", "а что, вы её только полгода назад запустили? Кажется, что я всегда в ней работал" — очень обнадеживает. Ну и можно косвенно судить по периодам планового отключения, когда нужно вернуться к альтернативам: "слава б-гу, наконец отключили это поделие", или "скорее включайте обратно, не можем без неё, это как в каменном веке!".
Я подсмотрел этот вопрос в статье создателя сервиса Superhuman, он описывает и референсные значения (40% и больше ответов "Очень расстроюсь" — у вас всё хорошо, более 60% — отлично), и следующие действия по улучшению показателя. И дополнительные вопросы:
1. Что вы почувствуете, если больше не сможете пользоваться системой?
2. Какие люди, как вам кажется, могут получить наибольшую пользу от системы?
3. Какую самую большую пользу вы получаете от использования системы?
4. Как мы можем улучшить систему для вас?
У этих вопросов нет модной аббревиатуры, но как хотелось бы, чтобы пользователям регулярно задавали именно их.
Идея там была в том, что хорошо бы к своим внутренним системам тоже относиться, как к продуктам, и на их метрики смотреть. В конце концов, даже внутри компании часто есть выбор — пользоваться вашей системой или потихоньку её саботировать. Или всё делать в удобной эксельке, а вашу систему потом вносить для отчетности. И экономический смысл во внутренних продуктах бывает: в сокращении времени, увеличении скорости прохода или производительности бизнес-процесса, да и про удовлетворенность спросить не помешает.
Вот метрика удовлетворенности как раз может быть очень важна для внутренних продуктов: да, работники обязаны пользоваться вашей системой, но при её использовании они мучаются или кайфуют? Как мы знаем, есть классические метрики NPS (Net Promoter Score) и CSAT/CSI (Customer Satisfaction Score/Index). Первую для внутренних продуктов применять немного бессмысленно ("Порекомендовали бы вы наш продукт своим друзьям?" — может и да, но как?). CSI лучше — поможет понять, как пользователь относится к вашей системе. Это такой опросник из двух частей: насколько вы удовлетворены каким-то аспектом работы системы (скоростью, удобством, поиском, созданием <чего-то> и т.п.)? И насколько важен для вас этот параметр?
Тут уже можно получить инсайты. Если в системе много пользователей, можно точечно спрашивать, насколько они удовлетворены конкретной функцией ("насколько вы довольны функцией поиска документа? Оцените по шкале от 1 до 5") — это CSAT. Так можно оценить каждую функцию отдельно. (Если пользователей у системы меньше 50 — проще с ними просто поговорить. Помним, что продуктовые методы начинают работать, когда мы физически не имеем возможности опросить каждого пользователя за разумное время).
Ещё для внутренних продуктов интересно спросить про усилия. Это будет CES — Customer Effort Score. Вопрос похож на CSAT, но немного другой: "насколько просто вам было найти документ? Оцените по шкале от 1 до 5, где 1 — очень сложно, а 5 — очень легко".
Но самая главная (на мой взгляд) метрика, говорящая об успешности системы, не имеет названия и мало где упоминается. Как одним вопросом понять, всё ли хорошо с вашим продуктом? Есть ли "product/market fit", за которым гоняются все стартаперы? Для них это вопрос выживания, для внутренних систем — вопрос капитала. Ваши пользователи — они за вас, или против?
Вот этот вопрос: "Что вы почувствуете, если больше не сможете пользоваться системой X?" С вариантами ответа: "Очень расстроюсь"; "Немного расстроюсь"; "Совсем не расстроюсь";
Простой вопрос, показывающий попадание системы в пользователя. Когда-то я сам набрел примерно на этот вопрос, но ответы были открытые, и звучали как "да я уже не представляю, как без этой системы работать", "это как третья рука", "а что, вы её только полгода назад запустили? Кажется, что я всегда в ней работал" — очень обнадеживает. Ну и можно косвенно судить по периодам планового отключения, когда нужно вернуться к альтернативам: "слава б-гу, наконец отключили это поделие", или "скорее включайте обратно, не можем без неё, это как в каменном веке!".
Я подсмотрел этот вопрос в статье создателя сервиса Superhuman, он описывает и референсные значения (40% и больше ответов "Очень расстроюсь" — у вас всё хорошо, более 60% — отлично), и следующие действия по улучшению показателя. И дополнительные вопросы:
1. Что вы почувствуете, если больше не сможете пользоваться системой?
2. Какие люди, как вам кажется, могут получить наибольшую пользу от системы?
3. Какую самую большую пользу вы получаете от использования системы?
4. Как мы можем улучшить систему для вас?
У этих вопросов нет модной аббревиатуры, но как хотелось бы, чтобы пользователям регулярно задавали именно их.
👍16🔥6🤡2❤🔥1
Сегодня расскажу про каналы своих подписчиков, как и обещал в посте про 5000. Каналы все классные!
Никита Харичкин ведёт канал Analyst Boost и сообщество по PlantUML. В канале — отчеты о конференциях, инсайты о работе аналитика и архитектора и полезные прихватки по работе с PlantUML. Вы, например, знали, что вместо activate/deactivate в диаграмме последовательности можно писать ++/--? Я вот тоже нет.
Дмитрий в канале DevFM пишет для Python разработчиков, но не только! Есть интересные посты про проведение ретро, про дизайн-документы от Google, про управление командой и коммуникации, а особенно мне понравились посты про всякие маааленькие нюансы: как лучше всего хранить в БД номера телефонов? Чем заменить cron, если нужно очень хитрое расписание? Какой тип данных выбрать для хранения строк — char, varchar или text? Обычные повседневные вопросы, которые оказываются не совсем простыми.
Канал "Пасека аналитика": жизнь и карьера аналитика, рефлексия опыта и безвозмездное менторство (!). Ловите момент.
Архитектура проектов на Unity. Хардкорный канал! Если вы думаете, Unity — это какая-то ерунда про игры, то вы больше так не думайте — Алексей пишет про программную инженерию в самом серьезном понимании. А посты про когнитивную сложность программ — просто моё почтение!
Ещё один хардкорный канал: Лабораторные информационные менеджмент-системы и аккредитацию лабораторий. Метрология, стандарты, валидация ПО, управление качеством. Серьезные дела. Пошел читать ГОСТ ISO 17025.
Канал Валентина Заботина "Аналитик маминой подруги" — про работу и карьеру в системном анализе, а главное — про денюжки, деньгушечки, откровенно и честно. Всегда интересно.
Вот такие у меня классные подписчики! Желаю всем нам роста и успехов! И не стесняйтесь писать о себе и о том, что вам интересно!
Никита Харичкин ведёт канал Analyst Boost и сообщество по PlantUML. В канале — отчеты о конференциях, инсайты о работе аналитика и архитектора и полезные прихватки по работе с PlantUML. Вы, например, знали, что вместо activate/deactivate в диаграмме последовательности можно писать ++/--? Я вот тоже нет.
Дмитрий в канале DevFM пишет для Python разработчиков, но не только! Есть интересные посты про проведение ретро, про дизайн-документы от Google, про управление командой и коммуникации, а особенно мне понравились посты про всякие маааленькие нюансы: как лучше всего хранить в БД номера телефонов? Чем заменить cron, если нужно очень хитрое расписание? Какой тип данных выбрать для хранения строк — char, varchar или text? Обычные повседневные вопросы, которые оказываются не совсем простыми.
Канал "Пасека аналитика": жизнь и карьера аналитика, рефлексия опыта и безвозмездное менторство (!). Ловите момент.
Архитектура проектов на Unity. Хардкорный канал! Если вы думаете, Unity — это какая-то ерунда про игры, то вы больше так не думайте — Алексей пишет про программную инженерию в самом серьезном понимании. А посты про когнитивную сложность программ — просто моё почтение!
Ещё один хардкорный канал: Лабораторные информационные менеджмент-системы и аккредитацию лабораторий. Метрология, стандарты, валидация ПО, управление качеством. Серьезные дела. Пошел читать ГОСТ ISO 17025.
Канал Валентина Заботина "Аналитик маминой подруги" — про работу и карьеру в системном анализе, а главное — про денюжки, деньгушечки, откровенно и честно. Всегда интересно.
Вот такие у меня классные подписчики! Желаю всем нам роста и успехов! И не стесняйтесь писать о себе и о том, что вам интересно!
🔥13❤6🥱3👍2🤡1
К вопросу, что мы делаем с требованиями. Я тут написал — "собираем", на что получил справедливое возражение, что нечего там собирать, нет их у стейкхолдеров, по крайне мере обоснованных и четко сформулированных. Не растут требования, как грибы — только возьми и собери.
Как сказать лучше? Выявляем? Ну, как будто они скрыты, а мы их делаем явными? Отчасти верно: когда мы исследуем предметный домен и структуру проблемы, мы выявляем объекты и действия, которые в них есть, но про которые специально не говорят, потому что не фокусируются на них. Ну а аналитики делают их явными, в этом смысле, наверное, выявляют. Про техники такого выявления я рассказывал и писал.
Ещё вариант: извлекаем. Это скорее про документы, где есть какие-то тексты про предметку и процессы, и в которых, при желании, требования можно увидеть.
Но, давайте будем честны: мы требования просто придумываем! Сами, или, если повезло — совместно со стейкхолдерами.
Можно этот процесс маскировать словом "разработка" требований (был и такой вариант). Или, чтобы совсем красиво звучало: co-development, или совсем по-модному co-design. И придумал это не Пол Ральф со своими статьями про контрпродуктивность идеи "сбора требований", а задолго до него.
Например, Клаус Пол (Klaus Pohl, один из основателей сертификации IREB) ещё в 2007 описал метод COSMOD-RE, где честно говорится: требования и архитектура системы разрабатываются в едином процессе co-development'а. И шаги "разработка целей и сценариев" и "разработка архитектуры" там на одном уровне (на самом деле это единый процесс).
Метод, по-видимому, плотно забыт, описания его еле гуглятся, а текстов статей и докладов нет в открытом доступе. Но можно посмотреть на несколько картинок.
COSMOD-RE задает 4 уровня:
1. Системы в целом;
2. Функциональной декомпозиции системы (разбивку на компоненты);
3. Распределение софтверных компонент по железу;
4. Уровень развертывания.
На каждом уровне происходит этот самый co-development требований и архитектуры, с уточнением деталей, а иногда и с возвратом на более высокий уровень и пересмотром принятых решений. Кажется, на русском про это говорят "прорабатываем требования и решения", или "разработка и анализ требований".
Любопытно (и полезно!), что здесь выделено 4 уровня, причем последние 2 захватывают хардвер. Аналитики же, даже системные, обычно в своих абстракциях далеки от размышлений — на чем всё это будет крутиться.
На курсе по проектированию интеграций часто вижу, как ломаются абстракции, когда мы начинаем говорить про Кафку, и выясняется, что это кластер и нужно думать про репликацию и вылет машин из кластера. Ну где, скажите, требования, а где кластеры. И хорошо, когда они объединены на одной картинке и в одном методе.
Как сказать лучше? Выявляем? Ну, как будто они скрыты, а мы их делаем явными? Отчасти верно: когда мы исследуем предметный домен и структуру проблемы, мы выявляем объекты и действия, которые в них есть, но про которые специально не говорят, потому что не фокусируются на них. Ну а аналитики делают их явными, в этом смысле, наверное, выявляют. Про техники такого выявления я рассказывал и писал.
Ещё вариант: извлекаем. Это скорее про документы, где есть какие-то тексты про предметку и процессы, и в которых, при желании, требования можно увидеть.
Но, давайте будем честны: мы требования просто придумываем! Сами, или, если повезло — совместно со стейкхолдерами.
Можно этот процесс маскировать словом "разработка" требований (был и такой вариант). Или, чтобы совсем красиво звучало: co-development, или совсем по-модному co-design. И придумал это не Пол Ральф со своими статьями про контрпродуктивность идеи "сбора требований", а задолго до него.
Например, Клаус Пол (Klaus Pohl, один из основателей сертификации IREB) ещё в 2007 описал метод COSMOD-RE, где честно говорится: требования и архитектура системы разрабатываются в едином процессе co-development'а. И шаги "разработка целей и сценариев" и "разработка архитектуры" там на одном уровне (на самом деле это единый процесс).
Метод, по-видимому, плотно забыт, описания его еле гуглятся, а текстов статей и докладов нет в открытом доступе. Но можно посмотреть на несколько картинок.
COSMOD-RE задает 4 уровня:
1. Системы в целом;
2. Функциональной декомпозиции системы (разбивку на компоненты);
3. Распределение софтверных компонент по железу;
4. Уровень развертывания.
На каждом уровне происходит этот самый co-development требований и архитектуры, с уточнением деталей, а иногда и с возвратом на более высокий уровень и пересмотром принятых решений. Кажется, на русском про это говорят "прорабатываем требования и решения", или "разработка и анализ требований".
Любопытно (и полезно!), что здесь выделено 4 уровня, причем последние 2 захватывают хардвер. Аналитики же, даже системные, обычно в своих абстракциях далеки от размышлений — на чем всё это будет крутиться.
На курсе по проектированию интеграций часто вижу, как ломаются абстракции, когда мы начинаем говорить про Кафку, и выясняется, что это кластер и нужно думать про репликацию и вылет машин из кластера. Ну где, скажите, требования, а где кластеры. И хорошо, когда они объединены на одной картинке и в одном методе.
❤12🔥12👍6
В английском всё это называется 'requirements elicitation', а оксфордский словарь говорит, что происхождение слова elicit — mid 17th century: from Latin elicit- ‘drawn out by trickery or magic’, “вытянутый обманом или магией". С этим определением я согласен 🧙♂
Почему не получается просто спросить про требования? В одной старой статье* приводится три категории проблем с требованиями:
⭐️ Проблема объема и границ:
— непонятно, где границы решения (где мы остановимся и чего не будем делать);
— лишние преждевременные детали (зависаем на них, не успеваем обсудить весь объем);
⭐️ Проблемы понимания:
— пользователи не до конца понимают, что им на самом деле нужно. Это они не специально, это проблема неосознаваемого знания (tacit knowledge);
— пользователи плохо понимают возможности и ограничения ИТ-систем (добавьте сюда привычку говорить не о проблемах, а сразу о решениях — и вы получите дилетантское мнение, если вовремя не вернете инициативу);
— аналитики и разработчики, в свою очередь, плохо разбираются в домене;
— аналитики и пользователи говорят на разных языках;
— "очевидная" информация пропускается, причём с обеих сторон;
— разные стейкхолдеры выдвигвают противоречащие требования;
— формулировки "требований" нечеткие и непроверяемые;
⭐️ Проблема изменения "требований":
— возможно, изменилась внешние условия и, соответственно, потребности;
— но, скорее всего, понимание возможностей системы и своих нужд растёт — то есть, вопрос в расширении знаний и осознанности. Сразу требовать полной осознанности от пользователя — слишком круто.
Приходится либо ждать, пока он дозреет, либо использовать обман и магию.
* Technical Report CMU/SEI-92-TR-012 ESC-TR-92-012, Issues in Requirements Elicitation, Michael G. Christel, Kyo C. Kang, 1992
Почему не получается просто спросить про требования? В одной старой статье* приводится три категории проблем с требованиями:
— непонятно, где границы решения (где мы остановимся и чего не будем делать);
— лишние преждевременные детали (зависаем на них, не успеваем обсудить весь объем);
— пользователи не до конца понимают, что им на самом деле нужно. Это они не специально, это проблема неосознаваемого знания (tacit knowledge);
— пользователи плохо понимают возможности и ограничения ИТ-систем (добавьте сюда привычку говорить не о проблемах, а сразу о решениях — и вы получите дилетантское мнение, если вовремя не вернете инициативу);
— аналитики и разработчики, в свою очередь, плохо разбираются в домене;
— аналитики и пользователи говорят на разных языках;
— "очевидная" информация пропускается, причём с обеих сторон;
— разные стейкхолдеры выдвигвают противоречащие требования;
— формулировки "требований" нечеткие и непроверяемые;
— возможно, изменилась внешние условия и, соответственно, потребности;
— но, скорее всего, понимание возможностей системы и своих нужд растёт — то есть, вопрос в расширении знаний и осознанности. Сразу требовать полной осознанности от пользователя — слишком круто.
Приходится либо ждать, пока он дозреет, либо использовать обман и магию.
* Technical Report CMU/SEI-92-TR-012 ESC-TR-92-012, Issues in Requirements Elicitation, Michael G. Christel, Kyo C. Kang, 1992
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👍3🔥3😁1
Майк Кон — сооснователь Scrum Alliance и эксперт в пользовательских историях — выделяет три категории требований:
➕ Известные (которые удалось "выявить", "собрать" или "разработать");
➕ Пропущенные (которые мы могли бы в принципе собрать, но как-то не получилось — мы не спросили, а пользователи про них не сказали);
➕ Эмерджентные — которые нельзя было предугадать заранее. Про них не знал ни аналитик, ни сам стейкхолдер — он понял, что ему это нужно, только когда увидел/начал пользоваться системой.
Ещё раз: это не то, что мы проглядели, это то, что мы в принципе не могли предугадать.
Это принципиальная разница между plan-driven и agile подходами, или даже взглядом на мир. В первом случае мы верим в рациональность, силу разума и познаваемость мира через точно построенные умозрительные схемы. То есть, в конечном счете, — в совершенство мира.
Во втором — верим, что мир в целом несовершенен, поведение людей иррационально, знания неполны, а модели дырявы. Но при этом мы не отказываемся от действий в этом несовершенном мире.
Вопрос подхода — это вопрос мировозрения, оптимизма и честного взгляда на обстоятельства. И, судя по тому, как каждый раз удивляются адепты рационалистского взгляда — в случае требований стоит признать, что есть требования, о которых никто не может подумать, пока не увидит работающую систему или хотя бы её прототип.
Самое интересное, добавляет Кон, — что эмерджентные требования могут оказаться как раз самыми нужными.
Отсюда идея — показывать хотя бы что-то, что может вызвать генерацию идей у пользователей. Поэтому первая версия интерфейсов — это не итоговый проект, это стимульный материал для выявления дополнительных требований, для запуска фантазии. И в плане нужно всегда отводить место на эти новые требования.
Ещё раз: это не то, что мы проглядели, это то, что мы в принципе не могли предугадать.
Это принципиальная разница между plan-driven и agile подходами, или даже взглядом на мир. В первом случае мы верим в рациональность, силу разума и познаваемость мира через точно построенные умозрительные схемы. То есть, в конечном счете, — в совершенство мира.
Во втором — верим, что мир в целом несовершенен, поведение людей иррационально, знания неполны, а модели дырявы. Но при этом мы не отказываемся от действий в этом несовершенном мире.
Вопрос подхода — это вопрос мировозрения, оптимизма и честного взгляда на обстоятельства. И, судя по тому, как каждый раз удивляются адепты рационалистского взгляда — в случае требований стоит признать, что есть требования, о которых никто не может подумать, пока не увидит работающую систему или хотя бы её прототип.
Самое интересное, добавляет Кон, — что эмерджентные требования могут оказаться как раз самыми нужными.
Отсюда идея — показывать хотя бы что-то, что может вызвать генерацию идей у пользователей. Поэтому первая версия интерфейсов — это не итоговый проект, это стимульный материал для выявления дополнительных требований, для запуска фантазии. И в плане нужно всегда отводить место на эти новые требования.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥32👍11❤1
Ещё одна идея от Майка Кона, которой у других не встречал: приоритизация задач по тому, что нового мы можем узнать, чему научиться.
Точнее, по трём параметрам:
1. Востребованность пользователями, это понятно.
2. Что нового мы сможем узнать? Это могут быть знания о поведении и предпочтениях пользователей или что-то о новой технологии.
3. Какой риск может быть снижен или устранен в результате реализации этой функции? Если мы видим риски, то лучше встретиться с ними как можно раньше.
И в бэклог спринта лучше всего брать задачи, продвигающие команду и заказчиков по всем трем признакам.
Точнее, по трём параметрам:
1. Востребованность пользователями, это понятно.
2. Что нового мы сможем узнать? Это могут быть знания о поведении и предпочтениях пользователей или что-то о новой технологии.
3. Какой риск может быть снижен или устранен в результате реализации этой функции? Если мы видим риски, то лучше встретиться с ними как можно раньше.
И в бэклог спринта лучше всего брать задачи, продвигающие команду и заказчиков по всем трем признакам.
🔥8👍1🤔1
Взгляд на работу с требованиями с точки зрения дисциплины управления знаниями (knowledge managemant, KM) оказался очень любопытным, и объясняющим некоторые вещи. Я-то, так вышло, работал с методами KM, и даже был когда-то членом экспертного совета премии Most Admired Knowledge Enterprise Russia, так что с темой знаком. А вот для аналитиков и архитекторов, на удивление, эта тема малоизвестна. Хотя разговор про архитектуру систем всегда затрагивает вопросы управления знаниями, это у меня один из главный инсайтов с курса про микросервисную архитектуру. Закон Конвея и разделение по командам тоже про управление знаниями — какие знания аккумулировать в команде, а какие выдавать наружу.
С точки зрения системного анализа, KM тоже много где проявляется: это и сбор знаний со стейкхолдеров (специально не пишу "требований", потому что правильнее — знаний о предметной области и проблемах, которые мы собираемся решить), и передача знаний в команду (очень часто аналитика называют "единым источником информации о системе", "координатором знаний о системе", а при этом управлению знаниями-то и не учат!).
Например, такая вещь, как модель SECI (или модель Nonaka-Takeuchi) объясняет, что для разных стадий работы со знаниями нужные разные методы. Модель вводит различение между неявными знаниями (tacit knowledge, существует только в головах или в навыках людей и часто даже не осознается) и явными, эксплицитными (explicit knowledge, существует в виде отчужденного артефакта: документа, описания, регламента, записей). Если бы все знания были эксплицитными, и задачи разработки требований бы не было, точнее, она была бы сугубо технической.
Модель SECI постулирует, что любое знание сначала возникает, как неявное, и передается через социальные взаимодействия: наблюдение, имитацию, практику под руководством. Такая передача знаний требует прямого взаимодействия. Формирующееся в результате знание тоже неявное. Это как раз и происходит в малых командах, отсюда и сопротивление ведению документации.
Потому что документация — это эксплицитное знание, и переход требует значительных усилий — экстернализации. Это то, чем часто занимается аналитик — экстернализирует неявные знания.
Экстернализированные знания становятся операбельными — с ними можно что-то сделать. Их проще передать от человека к человеку (хоть и с потерями). Их можно анализировать, из можно сочетать и комбинировать друг с другом, вырабатывать новые эксплицитные знания — в частности, из формального описания предметной области и проблемы выводить формальные требования к решению. Крайняя степень формализации знаний — это и есть программный код. Это зафиксированные и готовые к использованию знания, максимально оторванные от конкретного человека.
И вот тут возникает интересная вещь — круг замыкается, и происходит интернализация, переход от эксплицитных знаний к неявным. Готовая система становится элементом среды, в которой действуют люди, и способ, которым они решают свои задачи при помощи системы, нигде не зафиксирован. И на следующем витке вновь возникает задача извлечения, экстернализации знаний о реальной практике использования системы. Процесс входит в цикл.
(Картинка из статьи Germán Scalzo и Guillermo Fariñas, лицензия CC BY 4.0)
С точки зрения системного анализа, KM тоже много где проявляется: это и сбор знаний со стейкхолдеров (специально не пишу "требований", потому что правильнее — знаний о предметной области и проблемах, которые мы собираемся решить), и передача знаний в команду (очень часто аналитика называют "единым источником информации о системе", "координатором знаний о системе", а при этом управлению знаниями-то и не учат!).
Например, такая вещь, как модель SECI (или модель Nonaka-Takeuchi) объясняет, что для разных стадий работы со знаниями нужные разные методы. Модель вводит различение между неявными знаниями (tacit knowledge, существует только в головах или в навыках людей и часто даже не осознается) и явными, эксплицитными (explicit knowledge, существует в виде отчужденного артефакта: документа, описания, регламента, записей). Если бы все знания были эксплицитными, и задачи разработки требований бы не было, точнее, она была бы сугубо технической.
Модель SECI постулирует, что любое знание сначала возникает, как неявное, и передается через социальные взаимодействия: наблюдение, имитацию, практику под руководством. Такая передача знаний требует прямого взаимодействия. Формирующееся в результате знание тоже неявное. Это как раз и происходит в малых командах, отсюда и сопротивление ведению документации.
Потому что документация — это эксплицитное знание, и переход требует значительных усилий — экстернализации. Это то, чем часто занимается аналитик — экстернализирует неявные знания.
Экстернализированные знания становятся операбельными — с ними можно что-то сделать. Их проще передать от человека к человеку (хоть и с потерями). Их можно анализировать, из можно сочетать и комбинировать друг с другом, вырабатывать новые эксплицитные знания — в частности, из формального описания предметной области и проблемы выводить формальные требования к решению. Крайняя степень формализации знаний — это и есть программный код. Это зафиксированные и готовые к использованию знания, максимально оторванные от конкретного человека.
И вот тут возникает интересная вещь — круг замыкается, и происходит интернализация, переход от эксплицитных знаний к неявным. Готовая система становится элементом среды, в которой действуют люди, и способ, которым они решают свои задачи при помощи системы, нигде не зафиксирован. И на следующем витке вновь возникает задача извлечения, экстернализации знаний о реальной практике использования системы. Процесс входит в цикл.
(Картинка из статьи Germán Scalzo и Guillermo Fariñas, лицензия CC BY 4.0)
🔥25❤5👍4
Какая-то неделя рекомендаций каналов у меня получается. Вот тут ребята собрали папку каналов про agile, стратегию и системный анализ. Назвали, правда, «Гибкие технологии управления», но темы там шире. Всё про варианты развития аналитика: можно идти в организаторы процессов (читай — agile), можно в продакты или бизнес-партнеры, а там неизбежно придётся столкнуться со разработкой стратегии.
На большинство из них я сам подписан и читаю, так что могу уверенно рекомендовать.
Добавляйте папку, читайте каналы, набирайтесь новых идей!
https://news.1rj.ru/str/addlist/pB26PWfXrAFkMWYy
На большинство из них я сам подписан и читаю, так что могу уверенно рекомендовать.
Добавляйте папку, читайте каналы, набирайтесь новых идей!
https://news.1rj.ru/str/addlist/pB26PWfXrAFkMWYy
Telegram
Agile 🇷🇺
Ирина invites you to add the folder “Agile 🇷🇺”, which includes 12 chats.
👍3💩3🤮2🫡2👎1