Перевел для вас чеклист по диаграммам от автора C4 model. В принципе, ничего необычного, всё понятно. Как всегда, из всего чеклиста не срабатывает обычно 1-2 пункта, но они как раз могут всё испортить.

Я вот про себя отметил, что я точно слишком вольно отношусь к размерам элементов, и часто без объяснений делаю их разными. И группировку элементов не всегда объясняю. И иногда оставляю связи без подписей, что уж тут.

В общем, даже если вы рисуете неформальные диаграммы из квадратиков и стрелочек, это не означает, что в них не должно быть семантики и могут быть пропуски. Ничего нет хуже фотки доски полугодовой давности, на которой часть стрелок зелёная, а часть синяя, и уже никто не помнит, что это означало...

Вопросы чеклиста:

Общие
У диаграммы есть заголовок?
Понятно, к какому типу относится диаграмма, что она показывает?
Понятен ли уровень и скоуп диаграммы?
У диаграммы есть легенда / расшифровка обозначений?

Элементы
У каждого элемента есть название?
Понятен ли тип каждого элемента (уровень абстракции)?
Понятно, что делает каждый элемент?
Понятна ли технология, связанная с элементом? (если применимо на данном уровне абстракции)
Понятен ли смысл всех аббревиатур и сокращений?
Понятен ли смысл всех цветов элементов?
Понятен ли смысл всех форм элементов?
Понятен ли смысл всех иконок?
Понятен ли смысл линий границ элементов? (сплошная, пунктирная…)
Понятен ли смысл размеров элементов?
Понятен ли смысл группировки элементов?

Связи и отношения
У каждой лини есть подпись, объясняющая смысл связи?
Для каждой связи понятна технология, при помощи которой эта связь реализуется? (например, протокол; если применимо на данном уровне абстракции)
Понятен ли смысл всех аббревиатур и сокращений на диаграмме?
Понятен ли смысл всех цветов элементов?
Понятен ли смысл всех типов стрелок?
Понятен ли смысл всех типов линий? (сплошная, пунктирная…)

Их же прилагаю в виде файла, пользуйтесь!

Как из аналитика перейти в менеджеры продукта, и стоит ли?

На ЛАФе в кулуарах возник такой вопрос: мол, многие теперь позиционируют себя в качестве менеджеров продуктов, а не аналитиков. Ну, Дима Безуглый давно толкает тему, что аналитики не нужны, что это признак культуры плановой работы, и нужно переходить к продуктовой. А мы обсуждали — как перейти, и что нужно для перехода.

И я в разговоре озвучил вот такую штуку — про мой переход из аналитиков в продакты, и что там по-другому. Всё началось с запроса на разработку ТЗ. Как это обычно бывает, ребятам долго не согласовывали проект и бюджет, а когда согласовали — времени-то до запуска осталось 7 месяцев. И никто не знает, что делать. То есть, всё понятно, некоторое общее видение есть, но что конкретно делать — неясно. И даже нет документа, который можно было бы потенциальным подрядчикам отдать на оценку. Собственно, сначала я написал этот документ. И поприсутствовал на встречал с подрядчиками, что привело меня в ужас — они вообще ничего не понимали и собирались делать что-то несусветное. Вот тут начался мой дрейф в сторону продакта. В ТЗ ведь обычно не пишут стратегию (в том числе технологическую), не приводят дорожную карту развития на годы вперед, планы по масштабированию и всякие такие вещи, которые показывают развитие системы в динамике в широком временном диапазоне. А подрядчики, когда оценивают ТЗ, мыслят в проектной логике: сможем ли мы сделать нечто, что сможем формально сдать в качестве результата (хотя бы даже через суд)?

То есть, для подрядчика любой проект по определению уже закончен, главное под этот конец подтащить что-то. Для продакта конец разработки — это только начало жизни продукта! После запуска хоть в каком-то виде только и начинается всё самое интересное. В идеале, это интересное потом не заканчивается никогда. Работа над продуктом — бесконечный процесс, а никакой не проект.

Так как мне лично было интересно, чтобы такой продукт возник и состоялся (а это была MOOC-платформа российских вузов), я предложил всё это безобразие взять на себя, и в итоге мы запустились ровно в срок (1 сентября; первая встреча по ТЗ была в феврале) и в итоге платформа с нулевым маркетинговым бюджетом набрала более миллиона пользователей. Из аналитика-автора ТЗ я перешел в роль, отвечающую за реализацию этого ТЗ, включая набор команды и подрядчиков, координацию, контроль работ, ну и обеспечение выполнения всего, что дальше после ТЗ идёт — разработку UX, сценариев, требований к контенту и т.д. Роль не зря называется "менеджер", потому что вы уже не просто проектируете, а управляете людьми, бюджетами, объемом функциональности и качеством, в общем, всем, кроме сроков, потому что они были зафиксированы. Типичный death march по Йордону.

И вот тут проявилось второе отличие в точке зрения (первое — продукт это не проект, его нельзя "выполнить"). Приоритеты. В книгах по системному и особенно бизнес-анализу много пишут про определение приоритетов требований. Ну, когда вы пытаетесь успеть в срок, приоритеты меняются очень быстро, зафиксировать их крайне сложно. Смена приоритетов и разбивка историй (сценариев, пользовательских требований) на более простые части — ваши главные инструменты. Аналитик к такому не привык — ну, один раз как-то приоритеты задали, если вообще про них думали, и ладненько.

Но главное — это приоритет самих аналитических работ. Я стал заказывать работы по анализу, и испытал шок — со стороны заказчика всё выглядит совсем иначе! Аналитик без дополнительного управления начнет с чего? Правильно, с начала процесса. Ну, с регистрации, личного кабинета и всякого такого. Но как продакту, мне совсем не нужно! Там всё понятно, и риски минимальны.

Мне-то аналитик нужен зачем? Чтобы проработать наиболее непонятные и рискованные места! Где может быть взрывной рост сложности в функциях или в их реализации. Где вообще непонятно, как функции должны работать. Где ключевые функции, без которых и запускаться-то смысла нет. Вот это мне, пожалуйста, в первую очередь прокопайте. У многих аналитиков это вызывает ступор или отторжение. Нет, давайте начнем сначала. А если мы тщательно проработаем середину процесса, а про начало вообще не будем знать? Нет, так нельзя. Так же не будет работать! Давайте начнем с начала. В итоге получается как на картинке с лошадью — голова детально проработана, а дальше времени не хватило. А меня-то как продакта, это с самого начала жгло — я же знаю, что времени всё равно не будет, да и ладно. Нужно главное успеть, неглавное выкинуть. Это кардинально отличается от опыта и ценностей аналитика! Переход в другую роль не просто про название, он про ценности.

Книга "Эра милосердия" братьев Вайнеров, по которой снят фильм "Место встречи изменить нельзя", внезапно начинается с точного описания ощущений стажера-аналитика, попавшего в новую команду на идущий полным ходом проект:

Я не обижался, что они разговаривают так, словно на моем венском стуле с  нелепыми рахитичными ножками сидит манекен,  а  не  Шарапов —  их  новый сотрудник и  товарищ.  Я понимал,  что здесь не просто уголовный розыск,  а самое пекло его — отдел борьбы с  бандитизмом —  и в этом милом учреждении некому,  да  и  некогда заниматься со  мной розыскным ликбезом.

Но в  душе оседала досадливая горечь и  неловкость от  самой ситуации,  в  которой мне была  отведена  роль  школяра,  пропустившего весь  учебный  год  и  теперь бестолково  и  непонятно  хлопающего  ушами,  тогда  как  мои  прилежные  и трудолюбивые товарищи уже приступили к  решению задач повышенной сложности.

И  от  этого я  бессознательно контролировал все  их  слова и  предложения, пытаясь  найти  хоть  малейшую неувязку в  рассуждениях и  опрометчивость в выводах.  Но  не  мог:  детали операции,  которую они  сейчас так увлеченно обсуждали,  мне  были  неизвестны,  спрашивать я  не  хотел,  и  только  из отдельных фраз,  реплик, вопросов и ответов вырисовывался смысл задачи под названием "внедрение в банду".

Собственно, Шарапов потом очень правильно себя ведёт: выбирает из своего опыта релевантные ситуации, скиллы и реакции. Почти всегда это не прямое совпадение, но иногда очень полезное в новом деле: "А  я  командовал штрафной  ротой  и  повидал  таких  уркаганов,  какие Векшину, наверное, и не снились, и потому свободно владел блатным жаргоном", всякое такое.

Какие навыки, полученные в другой области, могут быть у начинающего аналитика?

* Представление о предметной области, если вы в ней работали — глубже, чем у любого аналитика, который только начинает разбираться в этой области — владение языком, понятиями, знание структуры деятельности и ограничений.

* Навыки написания текстов, если вы профессионально этим занимались, особенно структурированных: отчетов по научным работам, заявок на гранты, договоров, аналитических записок, экспертиз (один из моих успешных стажеров был, например, по первой работе судебным экспертом).

* Способность четко ставить задачи и учитывать непонимание, которое может возникнуть у исполнителя — ну, это из любой руководящей роли, хоть бы даже вожатым в детском лагере.

* Навыки интервьюирования и активного слушания: журналистика, психология, социология, продажи, техподдержка, любые занятия, связанные с оказанием услуг.

* Навыки презентации и аргументации — в том числе из дискуссионных клубов и даже КВН.

* Прослеживание взаимосвязей и последствий решений, фонмирование общей картины: конструирование, стратегирование, отчасти медицина.

Специфические навыки, которые не знаю, откуда взять: свободный переход по разным уровням абстракций и понимание, на каком уровне сейчас оперируешь. Сюда же: получение выводов путем формальных логических преобразований разных уровней абстракций. Где такому можно научиться?

Формальные графические языки, схемы: у нас их много, а где ещё?

Понимание устройства программных систем и процесса их разработки/обслуживания. Это совсем специфично, но это просто изучить, при желании. Только время нужно.

А что вам помогало из предыдущего опыта?

Не знаю, на какой теории основано моделирование процессов (если знаете — напишите!), но у нас в СССР были многочисленные разработки в области теории деятельности, целая научная школа (как пишет Википедия, "разноплановые эклектические исследования"), восходящая к Выготскому, Рубинштейну и Леонтьеву.

Одна из основных идей: трехчастная структура деятельности — деятельность, действие, операция. Такое разделение, мне кажется, очень полезно для анализа. Каждый раз нужно за собой следить — о чем мы сейчас говорим? О деятельности, о действиях или об операциях? На уровне действий есть смысл, который задаёт деятельность (в разной деятельности у одних действий может быть разный смысл и разная цель). А вот на уровне операций цели нет — человек уже не задумывается, зачем он каждую операцию производит. Операции — это всякие "нажимает на кнопку", "вводит текст", "выбирает опцию", так часто встречающиеся в сценариях юскейсов. Без указания цели юскейса все они смысла не имеют. Впрочем, частая ошибка — когда и из названия юскейса нельзя догадаться о его цели, и весь кейс превращается в одну операцию.

Например, так бывает, когда юскейсы повторяют операции CRUD — вообще непонятно, какая может быть цель у этих кейсов, из них можно сложить любую деятельность. А какая деятельность и как их них складывается — так нигде и не написано.

Кроме уровней, в этой схеме есть интересное различение внешних и внутренних действий. Аналитика, как правило, интересуют только внешние, которые может зафиксировать система. А вот когда мы проектируем интерфейс — нас очень волнует, что происходит внутри у пользователя. Что он знает? Чего он хочет? Что чувствует? Что понимает? Как принимает решения? Внутренние действия. Всего этого не будет в сценарии, написанном аналитиком, и в этом конфликт — вроде, и там, и там сценарии, а аналитические сценарии проектировщикам не подходят. Человеко-центрированная школа проектирования интерфейсов (Human-centered Interaction Design, HCI) теорию деятельности как раз изучает и использует, и даже говорят об Activity-Сentered Design — деятельностно-ориентированном дизайне.

На верхнем уровне теория подсказывает, что есть ещё мотивы и цели. С этим, на удивление, аналитики тоже редко разбираются. Выявлять и фиксировать истинные цели стейкхолдеров — да кто этим вообще занимается? Это только в книжках и на курсах бывает. Интересно, что в ArchiMate есть слой мотивации, где как раз разложено даже подробнее: стейкхолдеры, ценности, драйверы, оценки, цели, результаты, принципы и ограничения. И даже смысл. Можно очень подробно всю конструкцию выстроить — что над кем довлеет (драйвер), кто как это оценивает, и кто чего в связи с этим хочет (цели и результаты). Не знаю, правда, для какой это роли инструмент — видимо, для Enterprise Architect. Интересно было бы посмотреть на реальный пример диаграммы этого слоя.

Внимание! Воскресный пост с долей юмора. Что нужно делать в отпуске на даче? Правильно, читать всякие старые книги, которые сюда свезли, чтобы не занимали места в городе. В этом году протащило меня по детективам, и вот что интересно: как отличались реальные методы работы сыщиков и те, что в художественной литературе описаны.

В литературе же как: детектив логическим путём выводит из наблюдений всю картину — дедукция там, то сё. Анализ и синтез в чистом виде: выявить разрозненные факты и составить непротиворечивую модель преступления. В книжках она оказывается, конечно, единственно верной. Основные навыки:
* наблюдение, а также выделение важного и понимание — где какие следы можно искать;
* представление о "жизненном цикле" преступления: что было до, что было во время, какие стадии и фазы проходило, что было после;
* закон сохранения: ничего ни из чего не появляется и никуда не исчезает;
* внимание к таймингу и последовательности действий;
* опросы свидетелей ("В каждом, даже самом безнадежном на первый взгляд деле, всегда найдется человечек, который что–то видел, что-то слышал, что-то знает").

Это всё ооочень похоже на работу аналитика по обследованию деятельности и выявлению процессов: любой процесс оставляет след, нужно знать, где искать. У каждого дела и у каждой системы есть жизненный цикл, нужно думать о всей цепочке, а не только о моменте непосредственного использования. Никакая информация не берется из ниоткуда и не исчезает никуда. Системы и люди действуют последовательно, у каждого дела есть время начала и длительность, ничего не происходит "мгновенно".

Про опросы свидетелей известно, что а) "Все лгут" и б) "Умей внимательно слушать человека и старайся подвинуть его к разговору о нём самом. С первого мига проявляй к человеку искренний интерес". В общем, как в книге "Спроси маму": не спрашивай человека про систему, спрашивай про его задачи и проблемы.

Интересно, что в воспоминаниях реальных сыщиков — например, у Франсуа Видока и Ивана Дмитриевича Путилина — метод описан совсем другой: в основном это переодевание и проникновение в места нахождения преступников или организация провокаций. С точки зрения методов анализа и выявления требований, это называется "включенное наблюдение" или даже "ролевые игры". Близко к этому находятся натурные модели (Видок, в частности, ввел понятие и практику "следственного эксперимента").

А сборка в единую логику всех фактов и пересборка при вновь открывшихся обстоятельствах мне очень напомнило положения книги Криса Партриджа "Business Objects: Re-engineering for Re-use" (BORO) — если встречается новая ситуация в бизнес-задаче или новый частный случай, не влезающий в имеющуюся в ИТ-системе модель — нужно перестроить модель, сделав её более универсальной (а не пытаться вставить новый случай в формате костыля и воркэраунда сбоку — в конце концов запутаешься в этих воркэраундах). BORO изначально про объектное и ER-моделирование, но те же положения актуальны для архитектуры.

В общем, не могу никак отключиться и перестать сравнивать методы и находить аналогии. Но позаимствовать-то есть что!

В выступлении Димы Безуглого на ЛАФ (посвященного, как обычно, переходу к продуктовому мышлению и переходу задач аналитиков к разработчикам) мне больше всего понравился вопрос из зала: а как же разделение труда, ведь по экономическим законам для повышения производительности каждый работник должен стать специалистом в своем деле, а смежные операции отдать другим. Почему же тогда не усугубляется разделение на аналитиков разных видов и разработчиков, а наоборот — исключение и объединение ролей? (если, конечно, такой эффект действительно наблюдается).

Вопрос интересный и заслуживает отдельного исследования, а не коротокого ответа.

Во-первых, разделение труда в разработке явно есть — как внутри отрасли, так и внутри отдельных компаний. Интересны примеры отраслевого разделения труда — когда часть работы может быть легко заказана у другой компании. Это мы видим повсеместно в части эксплуатации, очень часто — в дизайне, в создании документации, иногда — в тестировании. Очень редко встречается аутсорсинг системного или бизнес-анализа (а вот аутстаффинг бывает чаще), и почти никогда — аутсорсинг архитектуры.

Вот что есть всегда и в любой разработке — разделение труда между авторами библиотек и фреймворков, и авторами конечных решений. Это в чистом виде разделение труда, сюда же можно добавить производителей средств производства: языков, редакторов, средств отладки и мониторинга и т.п.

Так что с разделением труда в разработке всё в порядке. Местами.

Улавливаете точки, в которых промежуточные рабочие продукты могут быть легко переданы? Там, где они формальны и имеют хорошую изоляцию абстракций. Дизайнер передаёт разработчику макет — он формален, его реализацию легко проверить, и он абстрактен — дизайнеру не нужно пояснять, как именно сверстать и запрограммировать код, чтобы на выходе получилась именно эта картинка. Инженерам по эксплуатции не нужно знать — как именно написан код (только его внешние зависимости, в лучшем случае) и что он вообще делает. Тестировщикам не обязательно знать внутреннее устройство программы, чтобы её протестировать.

С аналитиками это тоже срабатывает, если результат формализован. Если на выходе у вас спека в сваггере — вашу работу можно вычленить и отделить от разработки. Наверное.

Вся проблема в протечке абстракций. Они текут и у дизайнеров, и у девопсов, и у QA. Но у аналитиков это просто дырявый зонт. "Закон дырявых абстракций" говорит, что любая нетривиальная абстракция дырява, то есть не может игнорировать способ реализации.

А системные аналитики находятся очень близко к реализации, и граница абстракции вообще начинает плыть. Извечный вопрос: что давать на вход разработчикам? Не слишком абстрактно, чтобы для них вообще было понятно, что делать; и не слишком конкретно, чтобы они не говорили "а на самом деле удобнее и правильнее сделать не так а вот так".

Поэтому в этом месте разделение труда противоестественно, материал сопротивляется.

Этот пост во многом для тех, кто проектирует процессы и определяет шаблоны рабочих продуктов. Проверьте себя: какой уровень абстракции вы выдерживаете в документах? Какие аспекты реализации вы не учитываете? Это в СА  не так естественно происходит, как в других областях, поэтому стоит зафиксировать в явном виде: до какого уровня ещё имеет смысл прописывать, а где уже изолируемся от реализации.

Какие формализмы вводим? Хинт: чем их больше, тем легче изолироваться и разделять труд. Формальный текст всегда лучше, чем свободный текст, а ещё лучше — формальная таблица или диаграмма. DSL  с проверяемым синтаксисом — ещё лучше. OpenAPI, TypeSpec — вот такие штуки. Vanessa Automation для 1С. Я даже видел, как в некоторых проектах сначала придумывают DSL, а потом все требования и спецификации фиксируют на нём — высокий класс. В принципе, DDD тоже про это отчасти.

Одним из последних проектов у меня была проработка требований и проектных решений системы по построению управленческой отчетности.

Работа шла с нуля, поэтому набор артефактов получился вот такой:

1. Требования к бизнесу: что бизнес должен делать с точки зрения государственных органов, владельца, клиентов и подрядчиков. Систем здесь нет, это самый абстрактный уровень. Тут выявляем роли, которые отвечают за выполнение требований. Обычно это топы.

2. Мотивации и цепочка создания ценности. В этот раз не делал, но вообще нужно, и хорошо моделируется через Strategy Layer и Motivation Layer в Archimate™. Поток ценности — это вернеуровневый процесс компании + бизнес-возможности (capability). Мотивация показывает, кому и почему нужен этот проект и эта отчетность. Требования к бизнесу транслируются обычно в драйверы, управляющие мотивацией.

3. Бизнес-требования. Из мотивации ролей становятся видны бизнес-требования. Мы их записывали в виде юзер-сторей, но с добавлением: какое решение я, как роль, должен принять по этому значению или изменению этого показателя, какие действия я буду совершать? Это одна из самых трудных частей, потому что требует глубокой рефлексии от стейкхолдера, а то обычно получается "мне нужно видеть число продаж, чтобы скорректировать продажи" — понятно, что "скорректировать" здесь просто наукообразный синоним "ну, что-то с ними сделать". Что именно сделать — неплохо бы всё-таки выяснить, может, нужно дополнительные показатели вывести для принятия решения.

4. Реестр показателей. Это ключевой артефакт. Берем названия показателей из бизнес-требований, уточняем — как именно нам показатель нужно отображать:
— в абсолютных числах?
— в долях/процентах? (от чего?)
— как среднее?
— в сравнении (с чем?)
— в динамике?
— выбросы? (значительные отклонения)

В каких разрезах нас интересует каждый показатель? Тут мы выявляем структуру бизнеса, то, что называется основными данными и справочниками. Реестр показателей мы будем обогащать дополнительной информацией.

5. Добавляем в реестр, во-первых, владельцев показателя (из потока ценности) и связанные БТ. Во-вторых — систему-источник, в которой этот показатель впервые появляется. Потом добавим конкретное поле в конкретной таблице, или формулу расчета. Как правило, здесь возникают интересные вопросы, у нас, например, был вопрос — какой датой учитывать платеж для управленческих целей.

Здесь развилка: в одном направлении прорабатываем системы, в другом — состав и визуал отчетов/дэшбордов/оповещений. Начинаем с самого важного, для этого просим стейкхолдеров расставить приоритеты показателям.

6а. Раз мы добрались до систем, и нам нужен их реестр — с указанием, для каких данных это первоисточник. Также нам понадобится диаграмма потоков данных или sequence. Заодно здесь выявляем ручной перенос данных и всякие эксельки, на которых всё держится. Потом посмотрим, откуда удобнее брать данные для наполнения отчетов.

6б. Рисуем отчеты, как бы они могли выглядеть в идеале, без привязки к конкретному инструменту. Тут мы можем объединить показатели, которые раньше разделили, поэтому отчетов может получиться меньше.

В реестре отчетов для каждого указываем:
— назначение (для чего он);
— связь с бизнес-требованиями;
— основной объект, от которого строится отчет;
— вид отчета (плоская таблица или сводная);
— поля таблицы (для сводной — по вертикали и по горизонтали + формулы показателей на пересечении);
— агрегаты под строками (сумма, среднее и т.п.)
— возможные группировки;
— куда можно провалиться из строки отчета (drill down);
— откуда брать данные;
— какие справочники и какие основные данные в отчете используются;
— внешний вид отчета (мы моделировали в Google Sheets).

Отсюда начинается встречное движение — что и как мы хотим показать, и что позволяет сделать выбранный инструмент.

Про системный анализ, выбор архитектуры и инструментов напишу в следующей части, пост и так получился огромный.

Проектирование системы управленческой отчетности, часть 2.

Итак, у нас есть реестр систем и набор показателей, которые нам нужно выводить.

Теперь нужно понять, как это лучше сделать. Вариантов три:
— вытащить все данные из всех систем в отдельное аналитическое хранилище, нормализовать и уже к нему прикрутить любую систему построения отчетности;
— выбрать систему, в которой уже есть большинство данных и средства для построения отчетов (в данном случае это был, например, Битрикс24), и попробовать втащить туда недостающие данные;
— "размазать" отчеты по системам: если данные есть в одной системе, и там же можно построить отчет — строим там. Если нужны данные из двух систем, которые ими не обмениваются сейчас — вытаскиваем данные в отдельное хранилище и строим отчет там.

Решения отличаются по скорости реализации и по системности: можно быстро нашлепать отчетов в тех системах, где данные уже есть, но этим не очень удобно пользоваться; можно выстроить нормальную систему ETL, аналитическое хранилище и дэшборды.

Напомню, что у нас было две развилки: анализ существующих систем (а) и анализ абстрактных требований к отчетам (б). Идём по ним так:

7б. На основе реестра отчетов и их макетов формируем требования к системе построения отчетности — для последующего выбора. Просто функциональные требования к системе.

7а. Смотрим, какие есть возможности систем-источников (отдельный документ): внешние API, в том числе вебхуки; какие можно делать выгрузки (в Excel, CSV, 1С), можно ли добраться до БД. Описываем все варианты интерфейсов, для каждого указываем нюансы использования и состав данных, имеющиеся ошибки. Например, Битрикс24 в вебхуках отдает только ID изменившегося объекта, но не говорит, что именно изменилось. А в выгрузке он запросто может отдать две строки для одной сделки, в которых будут одинаковые идентификаторы, одинаковые идентификаторы товара, но разные названия и разная стоимость. Вот все такие штуки мы фиксируем в ещё одном документе:

8. Недостающая информация и проблемы. У нас могут быть проблемы надежности выгрузки, недостаток данных, разные идентификаторы, дублирование или склеивание записей, отсутствие идентификаторов, дублирование идентификаторов; разный формат вводимых вручную идентификаторов; нерегулярность учетной модели (когда сделка фактически завершена, но в системе это не отражается, "все и так знают"); неоднозначность источника данных: одна и та же информация может быть записана в разных полях (для такого типа сделки смотри число товаров в этом поле, а для другого — в этом поле не смотри, там бред, смотри в дополнительной таблице, или признак оплаты, который может быть отмечен в четырех разных полях); значимая информация в комментариях в произвольном формате; в принципе отсутствие в электронном виде информации или классификаторов; нарушенная ссылочная целостность — и наверняка я забыл ещё множество других проблем с качеством данных. Без приведения в порядок структуры и содержания данных никакую достоверную отчетность мы не соберем.

9. Поэтому имеет смысл построить эталонную концептуальную модель данных бизнеса — инфологическую, то есть без опоры на какую-либо технологию. Сделать из неё базу данных и попробовать наполнить её реальными данными из бизнеса — узнаем много интересного. Физическая модель может быть в итоге совсем другой — Data Vault, или анкорной, или ещё какой.

10. Выбираем системы для построения отчетов (дэшбордов), в том числе встроенные в имеющиеся системы (к Битриксу, скажем, недавно прикрутили несколько урезанный Apache Superset), пытаемся в них собрать нужные нам отчеты и опытным путем проверить возможность реализации требований из п 7б. Заодно проверяем на дружелюбие к пользователю и понятность.

Результаты оцениваем, и принимаем решение по архитектуре (вытаскивать всё в отдельное хранилище, или наоборот — втаскивать недостающую информацию в систему, где уже есть большинство данных). Тут может понадобиться ещё одна диаграмма мотивации — теперь уже для выбора архитектуры. Одновременно нужно выработать набор решений и действий по устранению проблем в данных (как организационных, так и технических).

Вот такой обширный список работ, наверняка не совсем полный, но я не видел такого развернутого алгоритма. На последнем ЛАФе Александр Чавалах давал мастер-класс по этой теме, наверняка тоже приводил алгоритм, к сожалению, я на МК не попал, надеюсь на запись. Пока выглядит так, что задача несколько сложнее обычных публикаций в стиле "выберите адекватный показатель и способ его визуализации".

Число подписчиков канала перевалило за 5000! Спасибо вам! 🙏🏻

Канал, который я завел для выкладки материалов к докладам, живет и развивается — благодаря вам! По вашим реакциям и комментариям я вижу востребованность того, о чем пишу, и это очень круто. Надеюсь, мои мысли, наблюдения и советы вам интересны, а осенью я собираюсь с новыми силами продолжить развивать свои основные темы: смысл работы аналитиков и других ролей в создании ПО, объяснение сложных концепций простыми словами, инструменты, подходы, чек-листы и прихватки в работе аналитика, неочевидные идеи и истории, и, конечно, использование ИИ в работе.

Не переключайтесь, у меня есть ещё много идей. Когда-то давно я был на конференции АИСТ, и в одном из докладов ребята рассказывали, как пытались проанализировать — чем отличаются посты популярных блогеров? Оказалось, что нельзя выделить какие-то общие критерии: ни особые темы, ни длину сообщений, ни употребляемые слова, ни наличие картинок в посте... Кроме одного — частоту постов. Когда я начинал вести канал, мне казалось, что писать-то особо не о чем. А сейчас я пишу посты почти каждый день, и темы для них не заканчиваются! Это удивительно и для меня самого, а вам, надеюсь, интересно.

Так что читайте, применяйте то, о чем я пишу, задавайте вопросы, а я буду продолжать радовать и удивлять вас.

Ну а в честь такого круглого числа хочу сделать вам подарок: я знаю, у многих есть свои каналы — напишите про них в комментариях к этому посту, а про самые интересные каналы я напишу отдельным постом со своими комментариями. Пусть и у вас будет праздник!

На ЛАФ рассказывал про историю UML, про его взлеты и падения, и совсем чуть-чуть про исследование его актуальности.

На Flow буду рассказывать прицельно про результаты: https://flowconf.ru/talks/5a9403b9ba8c43609a30da8eab1897d2/

Уже можно сказать, что результаты расходятся с немецкими исследованиями 2014 и 2017 годов: в 2024 в РФ аналитики используют UML чаще; почти всегда рисуют формальные диаграммы;  используют Use Case Diagram чаще, чем Class Diagram и всегда сохраняют созданные диаграммы для будущего использования или документации.

Не собираюсь в этом году как-то сильно поражать воображение слушателей, на мой взгляд, в программе есть много гораздо более сильных докладов. Честно говоря, работа в ПК оказывается довольно тяжёлой, даже не представляю, как справляются люди, которые в трёх конференциях в программных комитетах — это же как ещё одна работа!

В общем, встречаемся в Питере и в онлайне. Многим из вас, наверное, участие оплатит компания, ну а те, кто едет сам — пишите мне в личку, выдам промокод на скидку 25%! 🎫

Тут в одном чате аналитиков с удивлением прочитал вопрос: аналитики, а вы занимаетесь сбором и фиксацией требований? От человека, который не очень давно аналитиком работает, на курсах его сбору требований учили, но на практике это ему не нужно.

И в ответ, от многих: нет, никакие требования не собираем, ничего такого не делаем. Ну так, поговорим, бывает, с пользователями, и пишем постановку.

Кто-то с гордостью(!) говорит, что ни требований никогда в глаза не видел, ни диаграмм никаких не рисовал никогда.

Это, конечно, требует корректировки учебных программ, если на самом деле так.

Поэтому опрос (следующим постом): а чем вы в повседневной работе занимаетесь?

Интересно — на первом месте ответ "Пишу документацию". Сформулировано, конечно, максимально общо, а что вы под этим подразумеваете?

На мой взгляд, документация — это когда уже зафиксированы решения, а может даже всё уже сделано. И тут возникает, мне кажется, ключевой вопрос: вы фиксируете в документации решения, принятые вами, или кем-то другим (тогда кем, что это за роль?).

И если другими — ваша задача просто зафиксировать/описать решения, или же так организовать всех, чтобы нужные решения были приняты, и приняты с учетом всех аспектов, нюансов и последствий? Я и в своей работе, и в процессе менторинга/консультаций постоянно встречаюсь с этой задачей аналитика: организовать пространство и процесс принятия решений. Всех собрать, всем дать полную картину (или нужные им части, например, по безопасности, НФТ или изменению нормативки), организовать процесс.

Кажется, это тоже невидимая работа (а работа эта непростая!), о которой молчат на курсах и которую не замечают и не ценят руководители. "Ну ты собери совещание, и всё решите там". Угу, чего там говорить, само всё произойдет.

В канале я пишу в основном про системный анализ и для аналитиков — так получилось, да и занимаюсь я в последнее время именно этим. Про управление продуктами, например, почти не пишу. Но много читаю, и есть каналы, которые раскрывают тему более чем исчерпывающе.

Например, я давно читаю канал Тиграна Басеяна Black Product Owner.

Материала там — хватит на целый курс по управлению продуктом. Вот, например, пост с разными картами компетенций продакта и инструментами их оценки.

А вот — серия постов про юнит-экономику простыми словами.

Или вот модель оценки зрелости продуктового управления — даже если вы не продакт, замените "управление продуктом" на "системный анализ", и оцените зрелость своей компании.

Ну и прекрасная серия постов про всякие штуки разных сервисов, разбор продуктовых кейсов под тегом #миниресерч — насмотренность и творческое заимствование очень важны для продакта.

В общем, рекомендую! Подписывайтесь, если тема управления продуктами вам интересна!

https://news.1rj.ru/str/blackproduct

Сам ещё раз перечитал про управление продуктами, и подумал, что есть такие области, про которые как-то нечасто вспоминают, но которые очень важны для продакта (а аналитики с ними либо вообще не сталкиваются, либо очень по касательной). Это вот что:

* 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, хорошо бы разбираться в корпоративном управлении и политике, потому что он отвечает за успех продукта, а перед кем он отвечает? Перед владельцем или владельцами, которых в стартапе обычно несколько. Но это уже тема отдельного разговора.

Когда говоришь о продуктовом подходе, у аналитиков бывает отторжение: ну, это про всякие магазины / приложения, а у нас — внутренняя автоматизация, нам это всё ни к чему. У нашего пользователя нет выбора — использовать наш продукт или не использовать. На ЛАФ была отличная заявка на доклад про метрики внутренних продуктов, жаль, автор снял доклад. Надеюсь, ещё где-нибудь расскажет.

Идея там была в том, что хорошо бы к своим внутренним системам тоже относиться, как к продуктам, и на их метрики смотреть. В конце концов, даже внутри компании часто есть выбор — пользоваться вашей системой или потихоньку её саботировать. Или всё делать в удобной эксельке, а вашу систему потом вносить для отчетности. И экономический смысл во внутренних продуктах бывает: в сокращении времени, увеличении скорости прохода или производительности бизнес-процесса, да и про удовлетворенность спросить не помешает.

Вот метрика удовлетворенности как раз может быть очень важна для внутренних продуктов: да, работники обязаны пользоваться вашей системой, но при её использовании они мучаются или кайфуют? Как мы знаем, есть классические метрики 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. Как мы можем улучшить систему для вас?

У этих вопросов нет модной аббревиатуры, но как хотелось бы, чтобы пользователям регулярно задавали именно их.

Сегодня расскажу про каналы своих подписчиков, как и обещал в посте про 5000. Каналы все классные!

Никита Харичкин ведёт канал Analyst Boost и сообщество по PlantUML. В канале — отчеты о конференциях, инсайты о работе аналитика и архитектора и полезные прихватки по работе с PlantUML. Вы, например, знали, что вместо activate/deactivate в диаграмме последовательности можно писать ++/--? Я вот тоже нет.

Дмитрий в канале DevFM пишет для Python разработчиков, но не только! Есть интересные посты про проведение ретро, про дизайн-документы от Google, про управление командой и коммуникации, а особенно мне понравились посты про всякие маааленькие нюансы: как лучше всего хранить в БД номера телефонов? Чем заменить cron, если нужно очень хитрое расписание? Какой тип данных выбрать для хранения строк — char, varchar или text? Обычные повседневные вопросы, которые оказываются не совсем простыми.

Канал "Пасека аналитика": жизнь и карьера аналитика, рефлексия опыта и безвозмездное менторство (!). Ловите момент.

Архитектура проектов на Unity. Хардкорный канал! Если вы думаете, Unity — это какая-то ерунда про игры, то вы больше так не думайте — Алексей пишет про программную инженерию в самом серьезном понимании. А посты про когнитивную сложность программ — просто моё почтение!

Ещё один хардкорный канал: Лабораторные информационные менеджмент-системы и аккредитацию лабораторий. Метрология, стандарты, валидация ПО, управление качеством. Серьезные дела. Пошел читать ГОСТ ISO 17025.

Канал Валентина Заботина "Аналитик маминой подруги" — про работу и карьеру в системном анализе, а главное — про денюжки, деньгушечки, откровенно и честно. Всегда интересно.

Вот такие у меня классные подписчики! Желаю всем нам роста и успехов! И не стесняйтесь писать о себе и о том, что вам интересно!