Системный сдвиг

Сегодня расскажу про каналы своих подписчиков, как и обещал в посте про 5000. Каналы все классные! Никита Харичкин ведёт канал Analyst Boost и сообщество по PlantUML. В канале — отчеты о конференциях, инсайты о работе аналитика и архитектора и полезные прихватки по работе с PlantUML. Вы, например, знали, что вместо activate/deactivate в диаграмме последовательности можно писать ++/--? Я вот тоже нет. Дмитрий в канале DevFM пишет для Python разработчиков, но не только! Есть интересные посты про проведение ретро, про дизайн-документы от Google, про управление командой и коммуникации, а особенно мне понравились посты про всякие маааленькие нюансы: как лучше всего хранить в БД номера телефонов? Чем заменить cron, если нужно очень хитрое расписание? Какой тип данных выбрать для хранения строк — char, varchar или text? Обычные повседневные вопросы, которые оказываются не совсем простыми. Канал "Пасека аналитика": жизнь и карьера аналитика, рефлексия опыта и безвозмездное менторство (!). Ловите момент. Архитектура проектов на Unity. Хардкорный канал! Если вы думаете, Unity — это какая-то ерунда про игры, то вы больше так не думайте — Алексей пишет про программную инженерию в самом серьезном понимании. А посты про когнитивную сложность программ — просто моё почтение! Ещё один хардкорный канал: Лабораторные информационные менеджмент-системы и аккредитацию лабораторий. Метрология, стандарты, валидация ПО, управление качеством. Серьезные дела. Пошел читать ГОСТ ISO 17025. Канал Валентина Заботина "Аналитик маминой подруги" — про работу и карьеру в системном анализе, а главное — про денюжки, деньгушечки, откровенно и честно. Всегда интересно. Вот такие у меня классные подписчики! Желаю всем нам роста и успехов! И не стесняйтесь писать о себе и о том, что вам интересно!

Когда говоришь о продуктовом подходе, у аналитиков бывает отторжение: ну, это про всякие магазины / приложения, а у нас — внутренняя автоматизация, нам это всё ни к чему. У нашего пользователя нет выбора — использовать наш продукт или не использовать. На ЛАФ была отличная заявка на доклад про метрики внутренних продуктов, жаль, автор снял доклад. Надеюсь, ещё где-нибудь расскажет. Идея там была в том, что хорошо бы к своим внутренним системам тоже относиться, как к продуктам, и на их метрики смотреть. В конце концов, даже внутри компании часто есть выбор — пользоваться вашей системой или потихоньку её саботировать. Или всё делать в удобной эксельке, а вашу систему потом вносить для отчетности. И экономический смысл во внутренних продуктах бывает: в сокращении времени, увеличении скорости прохода или производительности бизнес-процесса, да и про удовлетворенность спросить не помешает. Вот метрика удовлетворенности как раз может быть очень важна для внутренних продуктов: да, работники обязаны пользоваться вашей системой, но при её использовании они мучаются или кайфуют? Как мы знаем, есть классические метрики 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. Как мы можем улучшить систему для вас? У этих вопросов нет модной аббревиатуры, но как хотелось бы, чтобы пользователям регулярно задавали именно их.

Сам ещё раз перечитал про управление продуктами, и подумал, что есть такие области, про которые как-то нечасто вспоминают, но которые очень важны для продакта (а аналитики с ними либо вообще не сталкиваются, либо очень по касательной). Это вот что: * Customer Development Inrerview. Совсем не то же самое, что интервью с пользователем по выяснению деталей бизнес-процесса и сбору требований. Тут вы обычно говорите с людьми, которым вообще ничего не надо, либо надо что-то совсем другое, либо они поддержат любую вашу идею, просто потому, что они хорошо к вам относятся. Главное отличие тут — ничего не спрашивать про продукт и вообще не говорить о нем. Классическая книга — “Спроси маму” Роба Фитцпатрика (она и аналитикам полезна). * UX, а особенно — два аспекта: 1) что происходит в голове у пользователя, какая у него ментальная модель и какие чувства, и 2) тексты в интерфейсах. На удивление, это серая зона — тексты в интерфейсах не умеют писать ни дизайнеры, ни копирайтеры, ни уж тем более аналитики. Вообще это отдельная специальность — UX-редактор, но в РФ её практически нет. Тут могу порекомендовать Иру Моторину, её канал — https://t.me/redachredach * Legal Compliance & Ethics. Соблюдение регуляторных требований и этика. Сюда же — безопасность и защита пользовательских данных. Не знаю, что здесь порекомендовать, если знаете что-то стоящее — напишите в комментах. Это про юридическую обвязку, пользовательские соглашения, перс. данные, куки и т.п. Про этику вообще никто ничего нигде не рассказывает, только в обсуждениях скандалов и можно пощупать тему. Кстати, в BABOK есть раздел "Этика", кто его читал/помнит? * Поддержка пользователей / Customer Success. Тоже серая зона, но по моему опыту, часто попадает в ведение продакта (потому что больше никому не надо). В любом случае, взаимодействие со службой поддержки — кладезь продуктовых кейсов и инсайтов. * Метрики и аналитика — тут понятно, и это очень связано с юнит-экономикой. * Ценообразование. Какую цену на продукт вообще поставить? Тут много материалов из институтских курсов по экономике/маркетингу, но они мало помогают. В каждом конкретном случае всё индивидуально. * Маркетинг в разных видах ("а чем ваш продакт вообще отличается от хорошего маркетолога?"), а особенно — контентный маркетинг. Ваш продукт (и вы сами) — медиа, действуйте соответственно. Я тут читаю Катю Макарову https://t.me/everythingpersonal и Линор Горалик https://t.me/thecontentisthequeen * Стратегия. Черт его знает, что это, но заниматься в какой-то момент приходится. В общем, это про то, что мы делаем и зачем, а чего мы точно делать не будем. Мне тут нравится подход Бориса Вольфсона, про который он рассказывал на WAW, а я писал https://t.me/systemswing/315 Ещё продакту, а особенно CPO, хорошо бы разбираться в корпоративном управлении и политике, потому что он отвечает за успех продукта, а перед кем он отвечает? Перед владельцем или владельцами, которых в стартапе обычно несколько. Но это уже тема отдельного разговора.

В канале я пишу в основном про системный анализ и для аналитиков — так получилось, да и занимаюсь я в последнее время именно этим. Про управление продуктами, например, почти не пишу. Но много читаю, и есть каналы, которые раскрывают тему более чем исчерпывающе. Например, я давно читаю канал Тиграна Басеяна Black Product Owner. Материала там — хватит на целый курс по управлению продуктом. Вот, например, пост с разными картами компетенций продакта и инструментами их оценки. А вот — серия постов про юнит-экономику простыми словами. Или вот модель оценки зрелости продуктового управления — даже если вы не продакт, замените "управление продуктом" на "системный анализ", и оцените зрелость своей компании. Ну и прекрасная серия постов про всякие штуки разных сервисов, разбор продуктовых кейсов под тегом #миниресерч — насмотренность и творческое заимствование очень важны для продакта. В общем, рекомендую! Подписывайтесь, если тема управления продуктами вам интересна! https://t.me/blackproduct

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

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

На ЛАФ рассказывал про историю UML, про его взлеты и падения, и совсем чуть-чуть про исследование его актуальности. На Flow буду рассказывать прицельно про результаты: https://flowconf.ru/talks/5a9403b9ba8c43609a30da8eab1897d2/ Уже можно сказать, что результаты расходятся с немецкими исследованиями 2014 и 2017 годов: в 2024 в РФ аналитики используют UML чаще; почти всегда рисуют формальные диаграммы; используют Use Case Diagram чаще, чем Class Diagram и всегда сохраняют созданные диаграммы для будущего использования или документации. Не собираюсь в этом году как-то сильно поражать воображение слушателей, на мой взгляд, в программе есть много гораздо более сильных докладов. Честно говоря, работа в ПК оказывается довольно тяжёлой, даже не представляю, как справляются люди, которые в трёх конференциях в программных комитетах — это же как ещё одна работа! В общем, встречаемся в Питере и в онлайне. Многим из вас, наверное, участие оплатит компания, ну а те, кто едет сам — пишите мне в личку, выдам промокод на скидку 25%! 🎫

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

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

Проектирование системы управленческой отчетности, часть 2. Итак, у нас есть реестр систем и набор показателей, которые нам нужно выводить. Теперь нужно понять, как это лучше сделать. Вариантов три: — вытащить все данные из всех систем в отдельное аналитическое хранилище, нормализовать и уже к нему прикрутить любую систему построения отчетности; — выбрать систему, в которой уже есть большинство данных и средства для построения отчетов (в данном случае это был, например, Битрикс24), и попробовать втащить туда недостающие данные; — "размазать" отчеты по системам: если данные есть в одной системе, и там же можно построить отчет — строим там. Если нужны данные из двух систем, которые ими не обмениваются сейчас — вытаскиваем данные в отдельное хранилище и строим отчет там. Решения отличаются по скорости реализации и по системности: можно быстро нашлепать отчетов в тех системах, где данные уже есть, но этим не очень удобно пользоваться; можно выстроить нормальную систему ETL, аналитическое хранилище и дэшборды. Напомню, что у нас было две развилки: анализ существующих систем (а) и анализ абстрактных требований к отчетам (б). Идём по ним так: 7б. На основе реестра отчетов и их макетов формируем требования к системе построения отчетности — для последующего выбора. Просто функциональные требования к системе. 7а. Смотрим, какие есть возможности систем-источников (отдельный документ): внешние API, в том числе вебхуки; какие можно делать выгрузки (в Excel, CSV, 1С), можно ли добраться до БД. Описываем все варианты интерфейсов, для каждого указываем нюансы использования и состав данных, имеющиеся ошибки. Например, Битрикс24 в вебхуках отдает только ID изменившегося объекта, но не говорит, что именно изменилось. А в выгрузке он запросто может отдать две строки для одной сделки, в которых будут одинаковые идентификаторы, одинаковые идентификаторы товара, но разные названия и разная стоимость. Вот все такие штуки мы фиксируем в ещё одном документе: 8. Недостающая информация и проблемы. У нас могут быть проблемы надежности выгрузки, недостаток данных, разные идентификаторы, дублирование или склеивание записей, отсутствие идентификаторов, дублирование идентификаторов; разный формат вводимых вручную идентификаторов; нерегулярность учетной модели (когда сделка фактически завершена, но в системе это не отражается, "все и так знают"); неоднозначность источника данных: одна и та же информация может быть записана в разных полях (для такого типа сделки смотри число товаров в этом поле, а для другого — в этом поле не смотри, там бред, смотри в дополнительной таблице, или признак оплаты, который может быть отмечен в четырех разных полях); значимая информация в комментариях в произвольном формате; в принципе отсутствие в электронном виде информации или классификаторов; нарушенная ссылочная целостность — и наверняка я забыл ещё множество других проблем с качеством данных. Без приведения в порядок структуры и содержания данных никакую достоверную отчетность мы не соберем. 9. Поэтому имеет смысл построить эталонную концептуальную модель данных бизнеса — инфологическую, то есть без опоры на какую-либо технологию. Сделать из неё базу данных и попробовать наполнить её реальными данными из бизнеса — узнаем много интересного. Физическая модель может быть в итоге совсем другой — Data Vault, или анкорной, или ещё какой. 10. Выбираем системы для построения отчетов (дэшбордов), в том числе встроенные в имеющиеся системы (к Битриксу, скажем, недавно прикрутили несколько урезанный Apache Superset), пытаемся в них собрать нужные нам отчеты и опытным путем проверить возможность реализации требований из п 7б. Заодно проверяем на дружелюбие к пользователю и понятность.

Одним из последних проектов у меня была проработка требований и проектных решений системы по построению управленческой отчетности. Работа шла с нуля, поэтому набор артефактов получился вот такой: 1. Требования к бизнесу: что бизнес должен делать с точки зрения государственных органов, владельца, клиентов и подрядчиков. Систем здесь нет, это самый абстрактный уровень. Тут выявляем роли, которые отвечают за выполнение требований. Обычно это топы. 2. Мотивации и цепочка создания ценности. В этот раз не делал, но вообще нужно, и хорошо моделируется через Strategy Layer и Motivation Layer в Archimate™. Поток ценности — это вернеуровневый процесс компании + бизнес-возможности (capability). Мотивация показывает, кому и почему нужен этот проект и эта отчетность. Требования к бизнесу транслируются обычно в драйверы, управляющие мотивацией. 3. Бизнес-требования. Из мотивации ролей становятся видны бизнес-требования. Мы их записывали в виде юзер-сторей, но с добавлением: какое решение я, как роль, должен принять по этому значению или изменению этого показателя, какие действия я буду совершать? Это одна из самых трудных частей, потому что требует глубокой рефлексии от стейкхолдера, а то обычно получается "мне нужно видеть число продаж, чтобы скорректировать продажи" — понятно, что "скорректировать" здесь просто наукообразный синоним "ну, что-то с ними сделать". Что именно сделать — неплохо бы всё-таки выяснить, может, нужно дополнительные показатели вывести для принятия решения. 4. Реестр показателей. Это ключевой артефакт. Берем названия показателей из бизнес-требований, уточняем — как именно нам показатель нужно отображать: — в абсолютных числах? — в долях/процентах? (от чего?) — как среднее? — в сравнении (с чем?) — в динамике? — выбросы? (значительные отклонения) В каких разрезах нас интересует каждый показатель? Тут мы выявляем структуру бизнеса, то, что называется основными данными и справочниками. Реестр показателей мы будем обогащать дополнительной информацией. 5. Добавляем в реестр, во-первых, владельцев показателя (из потока ценности) и связанные БТ. Во-вторых — систему-источник, в которой этот показатель впервые появляется. Потом добавим конкретное поле в конкретной таблице, или формулу расчета. Как правило, здесь возникают интересные вопросы, у нас, например, был вопрос — какой датой учитывать платеж для управленческих целей. Здесь развилка: в одном направлении прорабатываем системы, в другом — состав и визуал отчетов/дэшбордов/оповещений. Начинаем с самого важного, для этого просим стейкхолдеров расставить приоритеты показателям. 6а. Раз мы добрались до систем, и нам нужен их реестр — с указанием, для каких данных это первоисточник. Также нам понадобится диаграмма потоков данных или sequence. Заодно здесь выявляем ручной перенос данных и всякие эксельки, на которых всё держится. Потом посмотрим, откуда удобнее брать данные для наполнения отчетов. 6б. Рисуем отчеты, как бы они могли выглядеть в идеале, без привязки к конкретному инструменту. Тут мы можем объединить показатели, которые раньше разделили, поэтому отчетов может получиться меньше. В реестре отчетов для каждого указываем: — назначение (для чего он); — связь с бизнес-требованиями; — основной объект, от которого строится отчет; — вид отчета (плоская таблица или сводная); — поля таблицы (для сводной — по вертикали и по горизонтали + формулы показателей на пересечении); — агрегаты под строками (сумма, среднее и т.п.) — возможные группировки; — куда можно провалиться из строки отчета (drill down); — откуда брать данные; — какие справочники и какие основные данные в отчете используются; — внешний вид отчета (мы моделировали в Google Sheets). Отсюда начинается встречное движение — что и как мы хотим показать, и что позволяет сделать выбранный инструмент. Про системный анализ, выбор архитектуры и инструментов напишу в следующей части, пост и так получился огромный.