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

Невозможно не реагировать на мировые новости и повестку. Вот, например, футбол. Я вообще не фанат, но чемпионат мира можно и посмотреть! И, конечно, извлечь для себя что-то полезное. Во-первых, можно смотреть на тактику разных команд. Кто как строит игру, у кого есть звезды, у кого вся команда более-менее ровная; как распределяются роли; насколько команда способна адаптироваться; кто как работает с риском; кто использует постоянно одни и те же схемы, а кто импровизирует по ситуации — всё наглядно видно. Можно интересные выводы сделать для себя. Исследования работы в группе же в основном из спорта пришли. И даже роль такую придумали: Agile Coach, то есть тренер. По идее, он должен всеми этими интересными вещами заниматься, а занимается обычно внедрением ритуалов. Эти задачи традиционно падают на менеджера или тимлида, получается "играющий тренер" — практика, от которой в спорте давно отошли, слишком высокая нагрузка. А про играющих менеджеров команд я и не слышал никогда. Да и тренер не совмещает роль с менеджером. В ИТ такое в порядке вещей, что немного странно, если подумать. У тренера национальной сборной, кстати, задача со звездочкой: сборная — это же проект, в который собраны участники из разных команд. И часто они выполняют не ту роль (играют не на тех позициях), что у себя в клубах, да и стратегия отличается. Но отдельная история, которая меня поразила именно в этом чемпионате, я раньше о ней не слышал — это причуды статистики, или "Top-right Messi". Оказывается, если строить разные статистические графики, на них неизменно далеко справа или справа-вверху (если график двумерный) оказывается Лионель Месси, капитан сборной Аргентины, чемпион и рекордсмен всего на свете, и — думаю, вполне заслуженно — считающийся лучшим футболистом за всю историю. Так вот, чтобы вы понимали — если построить график, например, распределения участия в голах за 90 минут матчей всех нападающих топ-5 футбольных лиг, Месси оказывается справа на расстоянии почти 6 среднеквадратичных отклонений от среднего. Возможно, вы слышали про метод Six Sigma. Вот эти сигмы — это и есть среднеквдратичные отклонения. А "6 сигм" означают, что качество вашей продукции настолько высокое, что брак практически не встречается. В диапазон 3 сигм попадает 99,73% всех величин. 6 сигм — это 99,9999998% вероятность. С точки зрения обеспечения качества, превышение — 0,0000002% — почти незначимая величина, 2 на миллиард (где вы возьмете 500 тысяч топовых нападающих?..) С точки зрения реальности — вот она, бегает по полю, эта величина, можем посмотреть своими глазами. На практике это означает, что статистически маловероятные события более вероятны, чем мы о них привыкли думать. Или что аналитики не вполне корректно используют кривую Гаусса в данном случае, а они её используют некорректно. Нормальное распределение имеет смысл в случаях, когда мы складываем большое количество однотипных случайных величин. Складываем мы их, потому что они не добавляют много, работают в разные стороны — то добавляют, то отнимают, и в сумме получаем нечто среднее в большинств случаев. Но многие процессы устроены иначе — они не складываются, а перемножаются, и обычно имеют разную природу. Это описывается словом "одновременно": в Месси одновременно сошлось множество маловероятных факторов (дефицит гормона роста в детстве, отличное пространственное мышление, бабушка заморочилась водить внука в футбольную школу в детстве и т.д. Ну и талант, конечно!). Каждый фактор может иметь не очень-то низкую вероятность, а вот сочетание 3-4-5 факторов легко дает те самые доли процента. Одно цепляется за другое, а не просто тасуется. В итоге получается не нормальное, а логнормальное или степенное распределение, которое математически сложно обсчитывать — например, у него во многих случаях нет среднего и конечной дисперсии, и на нем нельзя считать регрессию. А так хочется упростить! Но мир устроен сложнее.

Мы годами строили предсказуемые монолиты и микросервисы, но AI превратил PDLC в Дикий Запад, где старые паттерны проектирования больше не работают. Хватит делать вид, что ты контролируешь ситуацию, просто прикрываясь новой версией TOGAF. Приходи 1 июля на Arch.Meetup, где мы поговорим про архитектурный подход AI disrupt PDLC, и вместе со спикерами из Сбера, Вебпрактик и Газпром нефти будем учиться управлять этим хаосом, пока нейросети не начали проектировать системы вместо нас. 🔗Выбирай удобный формат и регистрируйся по ссылке   📍Встречаемся очно на Кутузовском 32, а ссылку для онлайн пришлем накануне.

Удивительно, но я оказывается не писал здесь про 6D's фреймворк: 6 'Ds' цифровизации. То есть, что нам цифровизация вообще дает? Это аналитический фреймворк Питера Диамандиса, показывающий, что происходит с вещами и процессами при цифровизации. Если мы говорим не просто об автоматизации какой-то деятельности, а о её цифровизации, по фреймворку можно проследить — что будет происходить дальше, если мы в какой-то процесс пустили цифру. Начинается всё с цифровизации, перевода данных в цифровую форму, digitized. Это дает базу для всех дальнейших эффектов: данные в цифровой форме можно универсальным образом и без искажений хранить / обрабатывать / передавать. Совмещать при этом данные из разных источников и разной природы (то, что когда-то называлось "мультимедиа"), добавлять интерактивность и изменять принципы и возможности обработки без изменения аппаратного слоя. Одновременно с этим исчезает отдельный носитель: происходит дематериализация. Физические вещи типа записных книжек, календарей, книг, видео и аудиодисков, бухгалтерских книг — всё втягивается в электронные устройства. Перейдя в цифровую форму, деятельность становится в десятки и сотни раз дешевле, а то и вообще бесплатным. Это демонетизация. Следующий эффект — обманчивость, deceptive. Точнее — обманчивая слабость. В начале цифровая технология всегда выглядит хуже альтернатив. Это всё ерунда какая-то, цифровые печать/фотография/журналистика/кино/учителя никогда не смогут заменить настоящих! Вспомните, как все смеялись над первыми произведениями генеративного ИИ. Экспоненциальный рост в начале выглядит сильно хуже линейного. Подрыв, disruptive — когда цифровая технология становится лучше, её уже не остановить, она начинает разрушать существующие способы выполнять ту же деятельность. Производители пленки и кнопочных телефонов, магазины DVD, и торговые центры разоряются или уходят на другие рынки; библиотеки, кинотеатры, отели и таксопарки чувствуют себя нехорошо и т.п. И всё это приводит к демократизации: то, что раньше могли себе позволить только крупные компании или богатые люди, теперь доступно вообще всем. Например, постановка и съемка видео, доступ к информации и товарам, возможность влиять на события и мнения. Эти 6 эффектов прослеживаются во многих случаях, и если мы говорим не об автоматизации, а о цифровизации — по ним можно отслеживать её эффект. Что исчезнет физически из мира? Что теперь могут делать ваши сотрудники и пользователи, что раньше было слишком дорого / недоступно / непредставимо? За что вы перестали платить? Какой отдел или какая роль больше не нужны? (были подорваны). Если ясных ответов на это нет, то это не цифровизация по сути, а некие ритуальные действия, возможно чисто демонстративные, как хвост у павлина.

Кусочек из продуктового управления. Для описания сути продуктов используются разные формулы. Част можно услышать формулу: "Мы верим, что..." 1. Мы верим, что [наше убеждение о мире, людях или индустрии]. 2. Поэтому мы создаем [наш продукт, услуга или решение]. 3. Чтобы помочь [указание на целевую аудиторию] [конкретная польза или изменение в жизни клиента]. Пример: «Мы верим, что знания можно использовать, только когда они подкреплены практикой. Поэтому во всех наших курсах участники делают много практической работы. Чтобы помочь аналитикам не просто получить информацию, а попробовать новый способ действия.» Но эта формула апеллирует к вере, что ставит нас немного в слабую позицию, а наших критиков заставляет играть роль Станиславского: "верю/не верю". Гораздо больше энергии несет другая формула, мне тут подсказали коллеги, занимающиеся социальными проектами. У них все жестче, не "мы верим", а "нас бесит": 1. Нас бесит, что [распространенная несправедливость, обман или глупость на рынке]. 2. Вместо этого должно быть [как выглядит идеальный, честный или удобный мир]. 3. Поэтому мы сделали [наш продукт или услугу], где все именно так. «Нас бесит, что в онлайн-курсах только записанные видео и тесты. Вместо этого всё обучение должно происходить через практику. Поэтому мы сделали курс, в котором 70% времени занимает практическая работа и разбор результатов» Если вдуматься, в точности подходит ко всем успешным продуктам: «Нас бесит, что и Интернете ничего не найти. Вместо этого должна быть одна страница, на которой есть все ответы. Поэтому мы сделали страницу, где можно ввести запрос и мгновенно получить ответ на любой вопрос» (тут, кстати, сразу понятно, почему ИИ убивает поиск — у них формула продукта одинаковая. «Нас бесит, что в популярных местах невозможно забронировать гостиницу в сезон. Вместо этого каждый хозяин свободной комнаты должен иметь возможность её быстро сдать. Поэтому мы сделали сервис краткосрочной аренды через Интернет» «Нас бесит, что чтобы посмотреть фильм вечером нужно идти в магазин и покупать/арендовать DVD. Вместо этого должна быть возможность посмотреть любой фильм через интернет. Поэтому мы сделали онлайн-стриминг» «Нас бесит, что чтобы показать фотки из поездок нужно собирать целую вечеринку у себя дома. Вместо все знакомы должны видеть фотку и реагировать на неё сразу, как она снята. Поэтому мы сделали соц.есть для размещения фотографий, делающий их сразу красивыми» «Нас бесит, что для доставки груза в космос используются одноразовые ракеты и это стоит дофига денег. Вместо этого разгонные ступени должны использоваться много раз. Поэтому мы сделали такое, что наш основатель стал первым в истории долларовым триллионером». В общем, продукт должен радикально что-то менять, и это что-то должно быть всем ненавистно. Прикиньте к своим продуктам, что вас, как авторов, бесит? Если непонятно, что бесит, то и продукт выходит слабый. Что нас такое всех бесило, что мы сделали портфолио школьника? У меня, честно говоря, нет ответа. Поэтому и продукт вышел так себе. То есть, он красивый, и внутри заложена концептуальная модель, которой я горжусь, но востребованность у него оставляет желать. Бывает, что непонятно решение или мало сторонников. Например, меня бесит, что цифровизация в школе сводится к показу презентаций на проекторе или доске,а вместо этого должна быть организована исследовательская игровая среда с заданиями разного уровня. Но я не знаю, что тут можно сделать, остальных-то это не бесит. В общем, не делайте ватных продуктов, радикализируйте свою формулу.

В продолжение предыдущего поста — зашел посмотреть, что сейчас делает Алистер Коберн. Он, конечно, делает! Написал в 2025 году книгу про связь User Story, Use Cases и User Story Maps. То, что я много раз рассказывал на тренингах, но в книгу не оформил, да даже и на конференциях ни разу не рассказывал, думал, это слишком просто. А вот нет, нужно говорить и писать! Впрочем, приятно чувствовать себя на одной волне с великими. Что он пишет: User Story — значимое для пользователя изменение в системе (показатель прогресса), что-то, что пользователь может увидеть и пощупать. Use Case — перечисление способов, которыми пользователь может достичь своей цели (или не достичь). Story map — раскладка карточек, где слева направо идёт процесс, а сверху вниз — приоритеты. Основные принципы: 1. Глаголы подразумевают продолжительное действие 2. Раскладывайте глаголы на более короткие (по продолжительности действия) глаголы 3. Управляйте точностью (precision — тут правильный перевод ближе к "сфокусированности", "кучности") 4. Раскладывайте (декомпозируйте) всё, не только глаголы 5. Пишите документы вместе, разработка + бизнес 6. Пишите с точки зрения пользователей 7. Пишите только потребности, а не энциклопедию всего 8. Жертвуйте совершенством ради читаемости Принципы декомпозиции: Для use cases: до уровня целей взаимодействия пользователя с системой (имеющих смысл, даже если системы нет, система — это просто один из вариантов реализации), в метафоре Коберна — до "уровня моря" Для User story — хоть до "уровня моллюсков", то есть почти бесконечно. Use case поставляет полное описание способов работы с системой, поэтому из него нарезаются единицы прироста пользы — user story. Каждая история представляет собой срез юскейса (slice). Story map объединяет user stories и use cases: верхняя строка — это успешные шаги одного большого сценария, который обеспечивает вся система (и одновременно — названия юскейсов более низкого уровня). Карточки в колонке — срезы юскейсов, варианты данных / каналов / интерфейсов, обработка ошибок. Вот такое мнение гуру. А в 2026 году он уже успел выпустить ещё одну книгу: "Упрощая проектирование программных продуктов: гениальность бюрократии". Говорит, архитектура программных систем должна строиться на двух принципах матерых бюрократов: * "Это не моя задача" * "Мне это не нужно знать" То есть, каждый модуль должен четко понимать, что не является его задачей, и не делать этого. И не интереоваться ничем, кроме своей узкой задачи. Говорит, особенно актуальны эти принципы в эпоху ИИ-агентов, когда каждый агент старается побольше сделать. Нет, нужно им прописывать личности бюрократов, которые делают только то, что положено, и не больше. И тайно всех окружающих ненавидят.

Описание вариантов использования — use cases — удивительно хорошо подходит для современных технологий создания ИТ-систем. Я имею в виду — создание через ИИ. Программистам всегда было сложно работать с юскейсами — они длинные, сложно структурированы, и оформлены скорее в логике пользователя, а не действий системы. Некий новый интерес к юскейсам возник в связи с описанием интеграций, для которых они хорошо подходят, но и там зачастую обходятся диаграммой последовательности. А вот в лице LLM мы находим благодарного читателя. Он читает быстро, и ему не лень перелопатить десяток сценариев. А польза несомненна — например, интерфейсы и клиентов на основе сценариев ИИ генерирует замечательно. В принципе, на основе сценариев много что можно создать — и структуру API, и модель данных, и для разбивки на микросервисы они очень помогают: отлично работают, как формализация Event Storming, и дальше удобно анализировать по ним потоки данных, границы сервисов и нагрузку. Писать самому сценарии тоже не нужно, пусть машина пишет, а мы поправим. И тут возникает ещё одна вещь, никогда ранее никем не виданная: fully dressed use case. У Коберна описана структура полного описания юскейса, примерно страницы на две. Мы же обычно в практике ограничиваемся коротким набором: * Код * Название * Действующие лица * Предусловия * Триггер * Постусловия * Шаги основного сценария * Альтернативы / Исключения / Расширения А можно ещё так много дописать! Вот смотрите, что у Коберна: * Действующие лица разделены на Главное действующее лицо и Второстепенных действующих лиц * Есть область действия (Scope): проект и система * Уровень (от бизнес-юскейса до взаимодействия модулей) * Стейкхолдеры и их интересы: кому нужен этот юскейс и в чем их интерес? * Минимальные гарантии: даже если юскейс не будет выполнен, что гарантируется? (в каком состоянии будет система) * Гарантии при успехе (отдельно) * Соответствие бизнес-правилам (ссылки на бизнес-правила) * Используемые технологии и форматы данных, их варианты * Приоритет * Целевой релиз * Частота использования * Ожидаемое время отклика / время выполнения * Каналы взаимодействия для главного действующего лица / второстепенных действующих лиц * Открытые вопросы А вот что ещё можно добавить: * Автор * Источник * Статус * Версия * Дата последнего изменения * Уровень архитектуры * Требования безопасности * Требования локализации / i18n * Требования к доступности (WCAG / ГОСТ Р 52872-2019) * Масштабируемость: число конкурирующих запросов * Нефункциональные требования (прочие) * Спецификация данных (словарь) для хранения / ввода / вывода * Интерфейсные решения / прототипы интерфейсов * Допущения и предположения * Ссылки на связанные требования * Рекомендации по тестированию Я таких юскейсов, оформленных по всей форме, пожалуй, и не видел ни разу. Ну, может быть раз-другой сам писал. но это очень утомительно, и их в итоге никто не читает. А вот машине всё равно — она и написать не затруднится, и прочитать не поленится. А самое главное — она же для себя пишет, и действительно может использовать всё написанное. А другая машина может проконтролировать, и тут чем детальнее описано, тем проще проконтролировать. На месте Коберна я бы сейчас активно продвигал какой-нибудь фреймворк для AI SDD на основе юскейсов.

При подготовке курса по инструментам ИИ для системных аналитиков в очередной раз задумался — а какова, всё-таки, роль человека при общении с ИИ? И вспомнил модель SECI by Nonaka & Takeuchi из области управления знаниями. Модель про явное и неявное знание. Tacit и Explicit. И четыре перехода: Неявное → Явное (артикуляция) Явное → Явное (рекомбинация) Явное → Неявное (интернализация) Неявное → Неявное (социализация) Это всё про процессы обмена и обогащения знаний среди людей. И где тут ИИ? Мне кажется, генеративный ИИ — отличный инструмент для работы в области артикуляции и рекомбинации. Вы получаете некий ответ от модели и сравниваете его со своими знаниями. Если знания оформлены явно — можно автоматизировать контроль: что вы сказали модели, то она и должна сделать. Но все знания не могут быть явными. Поэтому возникают ситуации "ах ты глупый чат, всё ты не так сделал!". Это последствия свободных рамок, не заданных ограничений в промпте. Всё, про что явным образом не было сказано, как делать, будет сделано как-то. Как получилось. Как делало большинство тех, чьи результаты сформировали обучающую выборку. И тут вы видите, что всё не так. Ну или что-то не так. Может быть, вы об этом и не думали заранее. Вы даже предположить не могли, что так можно. Ну это же "очевидно"! Например, что в названиях эндпоинтов API нужно использовать существительные. Это RESTful, ну камон. При этом, если сказать в явном виде — опирайся на принципы REST, на выходе получим что? Правильно, HATEOAS, это же самый главный принцип! Ну, "это же очевидно", что мы с HATEOAS не будем упарываться, нам бы немного похожее на REST API сделать, и хватит. То есть, каждый раз, когда ИИ выдает "что-то не то", это "не то", скорее всего, относится к неявным знаниям, к тому, что вы не задали модели в промпте — скорее всего, потому что это вам кажется "очевидным", зачем об этом думать-то отдельно? И когда вы жалуетесь, что "этот ИИ какую-то ерунду пишет" — скорее всего, его вывод не соответствует вашим неявным ожиданиям. Поэтому цикл работы с участием человека выглядит так: постановка задачи (явная) → рассмотрение результата и сравнение его с неявными знаниями → их артикуляция и фиксация в промпте. Выдача ИИ превращается в стимульный материал для экстериоризации неявных знаний. Я уже собирался нарисовать соответствующую картинку, когда нашел ровно такую же статью годовой давности. Умные люди пишут не посты в малоизвестный канал, а статьи в рецензируемые журналы. В общем, статья Human-AI-Collaboration SECI Model: The Knowledge Management Model of the Experts’ Tacit Knowledges with Augmented LLM-Based AI от авторов Akashi Matsumoto, Ryu Nishikawa & Chikako Morimoto (опять японцы, да?) https://doi.org/10.1007/978-981-97-6469-3_12 Они вводят модель HAC-SECI: Human-AI-Collaboration SECI и два цикла: цикл развития агента и цикл развития человека. В цикле развития человек проявляет свои знания в процессе оценивания ответа агента, а в цикле развития агента человек передает агенту в явном виде то, что понял и осознал при оценивании. Через некоторое время такого взаимного обучения, со складыванием новых выявленных правил в хранилище и подключение его как RAG, ответы агента начинают гораздо лучше удовлетворять человека. Фактически, постепенно создается его цифровая копия. Что при этом происходит с самими человеком, исследование не раскрывает.

Или совсем другой подход к моделированию: встроим редактор BPMN прямо в выдачу! Вообще одной из фишек последнего времени является генерация ответа в виде html-файла. В самом деле, на что нам это красноглазие с копированием какого-то кода из одного окна в другое. Ведь даже swagger нужен лишь для того, чтобы сформировать красивую интерактивную документацию API. И теперь мы можем генерировать такую же красивую и интерактивную документацию на любую тему. А в случае BPMN мы можем сгенерировать не только диаграмму, но и страницу со встроенным редактором. Как мы знаем, в выдаче LLM могут быть мелкие недочеты, которые проще поправить руками, чем убедить переделать ИИ. Поэтому строим такой воркфлоу: ИИ делает диаграмму, показывает нам сразу в редакторе и с кнопкой "Сохранить". Мы немного меняет диаграмму, как нам нужно, и сохраняем в файл .bpmn Возможно, так и будут выглядеть интерфейсы будущего (по заветам Джефа Раскина), когда редактор генерируется сразу под формат редактируемых данных. Причем, что удивительно, качество кода самой диаграммы становится лучше — возможно, это связано с внутренней проверкой кода, а может, просьба сгенерировать код активирует какие-то слои нейросети, позволяющие лучше работать и с файлами XML. Запрос при этом используется самый примитивный:

Опиши процесс согласования документов в крупной организации, организованной иерархически (управления, отделы, руководители и т.п.). Результат представь в виде модели бизнес-процесса в BPMN, размещенного на html-странице. Используй библиотеку bpmn.js

Результат, наконец-то, выглядит довольно прилично. А мелкие детали можно быстро поправить вручную. Главная магия — "Используй библиотеку bpmn.js". Вы знаете, сколько этих библиотек для js уже сделано? Хоть для моделирования бизнес-процессов, хоть для анимации, хоть для визуализации, хоть для 3D. Перспективы открываются ошеломительные.

Я тут боролся с генерацией ИИ-шкой BPMN-диаграмм, и всё равно сразу генерировать XML очень плохо получается. В итоге я вроде смог объяснить ИИ синтаксис Bpmn-sketch-miner.ai, и теперь он генерирует уже почти без ошибок (ну, иногда вставляет лишние пустые строки). В итоге, процесс получается такой: 1) Вставляем в промпт текстовое описание бизнес-процесса 2) Сгенерированный код вставляем в Bpmn-sketch-miner.ai 3) Исправляем ошибки, если есть 4) Доделываем до нужного нам результата 5) Экспортируем в формат bpmn, 6) Вставляем в Camund'у или ваш любимый редактор процессов, растаскиваем элементы, чтобы визуально было красиво. Конечно, не то чтобы идеальный результат получается — визуально так и вообще кривоватый — но для набросков сойдет, не зря же он sketch называется. Для обсуждения процессов можно и не перегружать в "настоящий" редактор, можно и картинки из Bpmn-sketch-miner показывать, ещё и править их сразу на ходу. В общем, буду рад обратной связи, хочется всё-таки генерировать модели процессов автоматически, а не рисовать вручную. Промпт здесь: https://raw.githubusercontent.com/yksi12/prompts/refs/heads/main/bpmn-sketch-prompt.md

Многие думают, что ADR — Architecture Decision Records — это про фиксацию решений. Вообще нет, это, в первую очередь, мощный инструмент для принятия решений. Если думать про это, только как про фиксацию, то вроде и пользы не так много — ну да, мы можем отследить, когда и какое решение было принято, бла-бла... Скучно. Это из области управления знаниями, которое очень трудно продается и про которое начинают думать, когда все остальные проблемы уже решены. А проблема — это как раз принятие решений, вот что у всех постоянно западает. И в ADR есть отличные механики для этого. Про них почему-то не всегда даже пишут, а это-то самое важное, что там есть. Вот смотрите: 1) Срок действия решения. Это то, что убивает все обсуждения и заставляет их длиться бесконечно. Люди бьются, как будто каждое решение принимается навсегда! Стоит только вбросить волшебную фразу "это только на следующие полгода" — как все затыки и противоречия чудесным образом снимаются. Ну, полгода уж мы как-нибудь потерпим! Конечно, тут крайне важно, чтобы это действительно были полгода, и чтобы у вас в принципе был процесс пересмотра решений. То есть, вот прямо в план вставлены регулярные встречи для анализа и пересмотра всех действующих ADR! Хотя бы раз в квартал, ну или с какой скоростью вы двигаетесь. Ну и гибкость архитектуры важна, чтобы мы действительно могли что-то через полгода малыми усилиями поменять, а не заливать всё бетоном навечно. Если этого нет, то и ADR-ы не нужны, действительно, зачем?.. 2) Триггеры для пересмотра. Решение может изменяться не по времени, а по значению какой-то метрики. "Это решение действует, пока объем передаваемых данных / частота обращения к API / время обработки сообщения / ... не превысит значение X". Разумеется, тут нужен механизм, автоматически отслеживающий этот показатель и напоминающий, что нужно бы ADR-то пересмотреть. 3) Обратимость решения. Если решение обратимо без последствий и разумными усилиями — его вообще обсуждать долго не нужно, нужно выбрать какой-то вариант, определить метрики и критерии успеха, и посмотреть, что будет. Если не получилось — вернуться назад. В культуре Amazon ("Day 1") это называется "two-way door": дверь, в которую можно и войти, и выйти. Если пристально посмотреть и создать правильную инфраструктуру, таких решений может быть гораздо больше, чем кажется! 4) Уровень уверенности. Если вы не уверены в решении, это НЕ означает, что его не нужно принимать. Это означает, что оно должно быть обратимым и измеримым. А ещё — записать в явном виде, какой информации нам не хватает для принятия решения, и какие риски мы рассматриваем. Ещё интересно, когда стоит вообще принимать решение. В последний момент, но не позже! (Last Responsible Moment). Решение, принятое слишком рано, может быть не самым оптимальным, потому что мы ещё многого не знаем. Это как раз связано с информацией из п.4. Ключевые вопросы: нам обязательно принимать это решение сейчас? Что нас заставляет это сделать? Можем ли мы что-то делать уже сейчас, не принимая пока это решение? Что позволит нам принять более взвешенное решение (если мы будем знать что?). В общем, ADR задает хорошую структуру для обсуждения и принятия решения. Если у вас к совещанию будут подготовлены варианты с описанием почему нам нужно принять это решение (драйвер), почему именно сейчас, что мы не можем сделать без этого решения, какие альтернативы мы рассмотрели, какие у них есть преимущества и недостатки, на какой срок / до каких условий мы принимаем это решение, обратимое ли оно (и какие усилия нужно будет предпринять для отката) — ваше обсуждение пройдет гораздо более эффективно.

Приглашаем на третий System Analysis Meetup SberHealth ❤️ Когда: 20 мая в 18:30 Где: онлайн На митапе поговорим о навыках и подходах, которые помогают расти системным аналитикам. Через доклады и реальные примеры рассмотрим, как создавать новые решения в работе, развивать архитектурное мышление и растить техническую экспертизу ⭐️ В программе: 🟣Ирина Облецова, старший системный аналитик, поделится, как разработала своё решение для оформления требований к мобильной разработке — диаграмму на стыке Figma и блок-схемы 🟣Мария Горгоц, старший системный аналитик, расскажет, что стоит знать аналитику, чтобы подружиться с архитектурными решениями и расти в архитектуре Приглашённый спикер: 🟡Виктория Кухтяева, эксперт по системному анализу и котикам, поделится, какие знания по кибербезопасности нужны для уверенной работы с разработкой и архитектурой, а также как закладывать требования безопасности в решения 🆕Круглый стол Обсудим, как системному аналитику перейти в архитекторы: реальные истории, рабочие практики и нужные навыки 🔜 Регистрация на митап и подробности

Рынок как будто начинает оттаивать, вот и митапы для аналитиков снова пошли, что не может не радовать!

Ещё один пост про руководителей и лидов. Конечно, хочется написать именно для руководителей аналитиков, но тут первичны навыки управления, а процесс зачастую вторичен. Вся специфика бизнес- и системного анализа заключается в поиске верного места для этой функции в общей логике создания ПО. Зачем мы это делаем? Для чего мы нужны? Какую ценность мы приносим? Что без нас будет работать хуже? А вот принципы руководства не очень сильно зависят от функции и сути деятельности, которой ты руководишь. Поэтому профессиональные управленцы довольно легко могут переходить из одной предметной области в другую, особенно если им хватает ума не залезать в конкретную технологию работы и не пытаться в ней что-то менять. Самый лучший вариант, конечно, на стыке: понимать и в управлении, и в технологии. Это такое же сильное сочетание, как понимание технологии и ИТ, или ИТ и бизнеса. Но я хотел написать про чистое управление. Я наконец дослушал курс "История бюрократии", и кое-что из него извлек. (Стоит заметить, что курс про государственное управление, и это, конечно, не то же самое, что управление организацией. Но это ещё одна метафора — организация, как государство. Кроме того, нужно учитывать, что государства у нас практически всегда начинают с персонального управления, это тоже накладывает определенную оптику). Итак, что мы можем полезного извлечь из уроков гос.управления (что прослеживается во многих государствах и системах): 1. Первое, что нужно сделать — перепись. Для государства это связано со сбором налогов, а для руководителя организации — с пониманием ресурсов, которыми он располагает. Я наблюдал несколько раз смену руководителей или объединение организаций, и опытные люди всегда начинают с этого. Что мы имеем? Что нам оставил предшественник? Ещё это очень важно, чтобы зафиксировать точку "0" — с чего мы стартуем, и отделить унаследованные косяки от наших собственных. Так что одним из результатов "переписи" должен быть список проблем, уже имеющихся на момент принятия вами руководства. 2. Второе — сохранение и опора на существующую организацию (в курсе — аристократию). Не надо ссориться, нужно встроить имеющихся людей в свою систему. Не свергать князей, а выдавать им ярлыки :) 3. Но если вы хотите что-то всерьез поменять — стройте параллельные управленческие структуры из новых людей. Какие-нибудь временные комитеты, комиссии, советы; отлично тут работают проекты. Главное — выдернуть людей из существующей структуры и наделить чрезвычайными полномочиями, лучше всего — максимально неопределенными!. Я работал на многих проектах в кризисе, и это то, что всегда делают антикризисные менеджеры — создают параллельные структуры со специальными полномочиями и подотчетностью первому лицу (или вообще совету директоров). Часто приводят с собой варягов, не связанных с организацией. В общем, преторианская гвардия и чиновники особых поручений. 4. Для остальных нужно установить понятные правила игры: что можно, что нельзя, и как решаются конфликты. Где правда? Древнерусские установления так и назывались — Правда. Обычно они отменяли всякую дичь типа кровной мести и вводили более гуманные порядки. 5. Люди, которых вы привлекаете, должны быть лично обязаны вам и зависеть от вашего успеха. Опять же, тут отлично подходят проекты (а процессы наоборот вредят). Если у вас есть процесс или функция, не дай б-г, владелец этого процесса — это как поместная аристократия, наделенная землей. Сядет на этот процесс или ресурс, и будет вести себя, как его хозяин. А если у вас постоянно временные проекты, и основные деньги исходят из оплаты этих проектов — проектами владеете вы, и можете рулить этим по своему усмотрению — начинать проекты, останавливать проекты, привлекать людей к проектам (или не привлекать, пусть сидят на голой зарплате). 6*. Для придания себе дополнительной власти можно опереться на людей и группировки, которым до этого не давали голоса. Рекомендации макиавеллианские, но это опыт поколений автократов. В демократии всё по-другому, а приведенный рецепт — это как раз инструкция по её демонтажу. Тут думайте сами — где вы и чего хотите.

Здесь мог быть остроумный кликбейт Но не будем тратить время. Приглашаем на последний поток программы Интеграция и архитектура систем для аналитиков, которую проведет Андрей Бураков (ex-NextWay). Кому полезно: • Хотите перейти в архитектуру, но задачи на работе не дают развиваться • Изучили кучу материалов про архитектуру и паттерны, но в голове осталась каша • Ищите работу, но пугают System Design секции Чему научитесь: • Осознанно использовать технологии интеграции: Message Brokers, REST, RPC, WebSockets, GraphQL • Выбирать подходящие хранилища данных (микро)сервисов: реляционные, NoSQL, NewSQL • Уместно использовать архитектурные паттерны, для обеспечения производительности, масштабируемости, отказоустойчивости систем • Разберетесь в инфраструктуре для деплоя и управления сервисами в промышленных средах: Docker, Kubernetes, Service Mesh 📆 13 мая — 21 июня, каждую среду и воскресенье 🔗 Смотрите подробности и регистрируйтесь на сайте Реклама. ИП Бураков Андрей Олегович ИНН 632133429581

Вынесу из комментов: я тут нашел хорошую таблицу, связывающую проектное и процессное управление. Это стандарт P3M3, часть PRINCE2. Почему-то многие считают, что проектное управление предшествует процессному. Продолжая предыдущий пост, зачастую организации пытаются перейти к проектному управлению от управления по поручениям. Ну а что: проект — это же просто набор поручений! (Задач). А процессы — это что-то сложное и непонятно. А потом, конечно, они спрашивают — а почему это у нас проекты как-то плохо запускаются? А завершаются ещё хуже?.. А потому что ваши проекты опираются на хаотическую деятельность, ad-hoc. Или, того хуже, на героическую. Когда каждый проект вытаскивают отдельные герои, в отсутствие ресурсов и поддержки. Главное, это же очень удобно — зачем налаживать управление, если каждый раз находятся герои, которые и так смогут. Культура постоянного подвига. (Если кому-то пришлось совершить подвиг, значит до этого кто-то другой плохо выполнил свою работу. Всегда!) Я тут критиковал процессный подход, но в случае проектной деятельности именно установленные процессы должны стать опорой для проектов. Нет процессов = нет стабильной и предсказуемой проектной деятельности. Если вы читали PMBoK — там исключительно процессы описываются, это стандарт в процессной логике. Обратите также внимание, с какого уровня начинается управление процессами. С 4-го, предпоследнего! До этого ничем управлять невозможно, можно только руководить (в смысле микроменеджмента). А системно оптимизировать процессы можно только на пятом уровне зрелости! У организации, как у человека, есть зона ближайшего развития. Вы не можете перейти от хаоса к оптимизации*, не пройдя промежуточные шаги! У меня когда-то один студент писал диплом по управлению требованиями, и вывел там ФОРМУЛУ: 5-2=3. Если организация находится на 2 уровне зрелости, и собирается оптимизировать управление требованиями, ей нужно пройти ещё три уровня. По-другому никак! Поэтому, пожалуйста, будьте осторожны со словом "оптимизировать", учитывайте промежуточные состояния. Возможно, сначала вам нужно будет разобраться с такими словами, как "определить", "внедрить" и "измерить". * впрочем, есть теория хаоса и понятие странных аттракторов, но это совсем другая математика (и картина мира) и другой способ управления. И ещё одна метафора организации, кстати.

Я тут немного учусь на "настоящего управленца" (бесит это слово, честно говоря), и вот что наблюдаю. Первое: мы с вами в пузыре. Мы привыкли, что в организациях есть процессное управление, ну или хотя бы представление о процессах. Или, например, есть представление об управлении знаниями (все наши вики и architecture as a code — это оно). Многие в курсе про качество и даже слышали про ISO 9000. То есть, мы с вами чаще всего работаем в компаниях, где всё это есть. Часто ещё и с заимствованными с запада практиками управления и опорой на стандарты. Я имею в виду банки, крупную промышленность, крупный ритейл, интернет-компании — многие из которых изначально создавались иностранцами, как Авито и Ламода. Иногда этот подход проникает даже в образовательные проекты типа Сириуса и Летово. Но масса организаций работают безо всяких процессов или проектов, а управление осуществляется путем поручений. То есть, работник сидит и ждет, когда ему что-то поручат делать. Поручили — делает, не поручили — сидит дальше. И выполняет не конкретный процесс, а поручение руководителя. Основной деятельностью в такой системе является получение поручений и документов сверху и расписывание их на исполнителей. Ну и контроль потом. Но много где нет и этого, а поручения выдаются устно, слабо контролируются, а процесс исполнения даже типовых поручений придумывается каждый раз заново. И вот тут второе: что делает руководитель в таких системах? Интересное дело: в основном работает с мотивацией. Потому что в процессах можно поставить KPI и измерять какие-то показатели, оптимизировать шаги. А если у вас управление по поручениям, то ваша основная метрика — своевременное исполнение. Точнее: 1) исполнение в принципе и 2) исполнение в срок. И тут нужно как-то людьми манипулировать, чтобы они всё это делали (а они обычно не хотят, потому что нет смысла — не видно какой-то великой цели, сплошное реагирование и тушение пожаров). Поэтому такой управленец постоянно изучает: кто же такие его работники и что как они реагируют на разные воздействия. То есть, постоянно их типирует. По разным психологическим и псевдопсихологическим тестам. По Герчикову, Белбину, Адизесу, DISC, MBTI, Big 5, уровень эмоционального интеллекта, стиль решения задач по Алану Роу и т.д. Заодно типирует среду в компании и отслеживает социальные связи: кто, с кем и зачем общается. А также — и вот тут я немного удивился — так же всё время типирует себя. То есть, получается, что человек знает очень много о себе: как он принимает решения, на что реагирует, в чем имеет сильные стороны, а где слаб. И то же самое знает про своих сотрудников и про своих контрагентов (или про своих руководителей). И, соответственно, умеет подобрать правильные подходы ко всем и в любой ситуации. Я писал про тетраграмматон Кулакова — это же та же схема: типирование + рекомендации лидеру, что делать (вставать в уравновешивающую позицию — если у вас в команде сплошные тролли и эльфы, вам нужно действовать, как гном, и строить продажи). Один мой знакомый постоянно именно этим занимается, причем тратит довольно большие деньги на серьезные коммерческие тесты (тестирует себя) и даже сертифицировался для проведения диагностики (чтобы исследовать свою команду), потом загоняет эту информацию в ИИ, вместе с описанием коллег и руководителей, и гоняет в ИИ до посинения сценарии развития событий, диалогов, реакций на возможные действия. Я немного скептически относился к такому развлечению, но, послушав с десяток действующих руководителей разных организаций — впрочем, в основном образовательных — уже стал думать, что что-то в этом есть. То есть, если вы руководитель или лид команды, вы должны постоянно этим заниматься — досконально знать себя, своих людей, окружающих людей, среду в вашей команде, среду в организации, и всё это постоянно учитывать (а часто ещё и менять). А не "выстраивать процессы", как часто говорят. Знаете ли вы себя и команду?

Ещё из актуального: в отличие от некоторых школ, которые считают нормальным в конце года просто оповестить смской учащихся и педагогов о закрытии одним днем и отправить всех в комиссию по банкротству в Делавэре, Systems.Education доводит все дела до конца. Завтра завершается последний поток трёхмесячного интенсива  Systems Analyst Bootcamp, и можно посетить открытое финальное демо. Там можно увидеть презентацию команд, оценить результаты и задать вопросы. И присмотреть себе аналитиков, если вам нужны в команду джуны+ / почти миддлы. Обучались они вот по этой программе. Порядок проведения демо - по ссылке. Финальное демо пройдёт в онлайн-формате 6 и 7  мая с 18:00 до 20:00 МСК Будем рады вашему присутствию! Запиcываться через @systemseducation

Раз уж я блогер, должен реагировать на хайповые темы. Даже и с запозданием. Ладно, я всё пропустил. Но всё равно, вот вам: группа Angine de Poitrine. Переводится как "Боль за грудиной" или "Стенокардия". Ребята умудрились в эпоху тотального нейрослопа сделать что-то настолько неожиданное, что никакой нейросети с самой высокой температурой не приснится. По форме это "экспериментальный микротоновый математический рок с элементами костюмированного перформанса". И это меня прямо вернуло на 25 лет назад, когда я активно программировал, и, конечно, делал это под музыку. Итак, неожиданный пост про фоновую музыку для работы. На созвонах фоновой музыки обычно не бывает. Хотя интересно было бы представить — вот ваш типичный созвон, какую бы музыку вы к нему подобрали?.. А когда мы сосредоточенно работаем над чем-то, будь то код, диаграмма или документ, музыка помогает или мешает? При программировании у меня почти всегда что-то играло на фоне. И почти всегда это было что-то хитрое с музыкальной точки зрения. И это не снобизм, а насущная необходимость! Прямые биты с размером 4/4 в сочетании с однообразной работой меня укачивают, и уже через короткое время я засыпаю, причем скорость не важна — монотонный хардкор или транс тоже усыпляют, если под них не танцевать или вести машину на высокой скорости (а если танцевать — вгоняют в тот самый транс). В общем, это всё не то — фоновая музыка должна не усыплять, а наоборот обострять чувства и стимулировать мозг. Поэтому мой набор для программирования в начале 2000-х был весьма диковат: Сергей Курехин, John Zorn, Les Hurlements d’Leo, Eläkeläiset, саундтрек "Бойцовского клуба", который The Dust Brothers, их последователи The Chemical Brothers и прочий брейк-бит, The Prodigy, Lemon Jelly, Эдуард Артемьев, Skanatra и т.д. Видите какую-нибудь логику? Я вот тоже сначала нет, а теперь понимаю: основное свойство — неожиданность. Неожиданность тут двух типов: музыкальная (необычные размеры, ломанный бит, сваливание чуть ли не в чистый шум — ой, это я ещё про japanoise забыл написать, Merzbow, Masonna, The Gerogerigegege — тоже было!), либо культурная — различные перепевки, каверы и прочая культурная мешанина. Ну и микротональная музыка Angine de Poitrine из этой же серии — микротоны, это же звуки с интервалами вне европейского равномерно темперированного строя, то есть ноты, которые "между" соседних клавиш на фортепьяно или "внутри" ладов на гитаре (у Khn de Poitrine на грифах гитары вдвое больше ладов, чем обычно). Чаще всего это звучит для нашего уха фальшиво, но тут всё получилось. Короче, тут чистая математика — нарезка диапазона частот на необычные ноты, и применение странных ритмических размеров, далеких от 4/4: 7/8, 11/8 и т.п. И даже если убрать микротоны, это математический рок, mathrock — рок со странными размерами и их сменой внутри одной композиции. А уж этого мат-рока очень много (особенно почему-то много японского мат-рока, даже с вокалом). И это у меня теперь будет базовой музыкой для фоновой работы, а то всё предыдущее я уже наизусть. В чем тут фишка? Это всё про дофаминовую стимуляцию. Дофамин — гормон радости ожидания нового. При программировании он и так вырабатывается, потому что ты ждешь, что оно заработает, а оно не работает, а потом как заработало! Выплеск дофамина. Главная фишка для выработки дофамина — неожиданность. Когда результат известен — награды не будет. Когда есть только шанс получить что-то интересное (или ещё более интересное!) — работает дофамин. Этот гормон стимулирует интерес и обучение. Но только в условиях безопасности, иначе он сразу перебивается адреналином! Дофаминовый транс или "состояние потока" заставляет программистов писать лучший код, а аналитиков — лучшие документы. Math-rock с неожиданными и меняющимися ритмами делает мозгу щекотно как раз за счет промахов в ожидании следующей ноты: думал, сейчас будет очередная доля? А нет! Получи выброс дофамина! Вот такой музыкальный биохакинг.

Мой менти столкнулся с проблемой, которую не знаю, как быстро решить. Возможно, вы тоже с таким встречались. По-английски называется "Игра принеси-мне-камень" (Bring me a rock), прием психологического насилия, когда человек просит принести камень, вы ему приносите, а он говорит — нет, это не такой камень. А какой нужен? Не знаю, ты принеси, посмотрю — скажу. Раньше в такую игру любили поиграть заказчики — "ой, ну тут что-то не то... а что не то, мы не знаем..." — но теперь мы столкнулись с игрой со стороны разработчиков. Выглядит так: ну, вы тут напридумывали, здорово, но мы так сделать не можем. Давайте как-нибудь по-другому. А как по-другому? Не знаем, вы же с пользователями общаетесь. Так мы точно не сможем сделать. Принесите камень, который нам подойдет. Есть множество статей на эту тему, с общим посылом: это игра, в которой единственный способ выиграть — не играть вообще. К сожалению, мы не можем выйти из игры и перестать работать с этой командой (ну, или можем — выход есть всегда, в том числе из компании). Остается что: 1) пытаться договориться с разработчиками и 2) эскалировать на руководителя. Эскалация сработает, если у вас в принципе выстроен механизм медиации, если руководители уделяют внимание психологической обстановке, пресекают буллинг и работают с установками работников. Вариант "договориться" — это если разработчики готовы договариваться. Исходим из того, что у всех нас одна общая цель, нет конкуренции между аналитиками и разработчиками, нет каких-то политических игр и подстав. Тут может быть всякое — аналитики и разработчики могут вообще подчиняться разным руководителям (я видел варианты, что даже разным C-level: аналитики — директору по технологиям, а разработчики — техническому, и их конкуренция транслируется до рядовых исполнителей), аналитики могут постоянно меняться и команде не понравился конкретный аналитик и т.д. Тут проблема не техническая, но парадоксальным образом иногда решение оптимальнее искать вне координат проблемы: если проблема политическая, то решение должно быть техническим, и наоборот. Это вообще полезное правило — неразрешимое противоречие в одной системе координат нужно решать в другом измерении. Допустим, у всех одна искренняя цель, но сделать мы так не можем. А как можем, мы сами не знаем. Тут нужно заметить, что фраза "мы так сделать не можем" очень часто означает "мы так делать не хотим, потому что..." и вот тут возможны варианты: * сделать можно, очень много переделывать, но на задачу отведено мало времени и есть риск что-то упустить * сделать можно, но это будет очередной костыль (архитектура уже давно не соответствует потребностям бизнеса, но времени и ресурсов на рефакторинг так же давно не выделялись) * сделать можно, но придется отказаться от готового компонента (и нести в дальнейшем риски и тратить ресурсы на развитие) * сделать можно, но это выглядит, как ультра-локальное изменение и частный случай, который больше нигде и никогда не получится использовать * сделать можно, но очевидное решение будет сильно нагружать бэк/фронт, или будет слишком медленным. Возможно, тут чисто математическая сложность. Всё это можно "вскрыть", если действовать осторожно и не идти на конфликт. И если разработчики готовы говорить откровенно, а не ты дурак, ничего не понимаешь, мы так и думали, аналитики бесполезны. Я бы пробовал просто потыкать палочкой все эти места. Это принципиально невозможно, или просто слишком много переделывать? В чем основная сложность? (Тут бы нужно локализовать проблемную зону, ну примените те же методы анализа, то есть рассечения на части, только уже системы. Проблема с фронтом, бэком или базой? Что сложнее всего поменять?). Это будет костыль? Чисто теоретически, можно это сделать костылем? У вас этот компонент самописный или готовый? Это прямо сейчас сложно сделать, или вы про будущую поддержку переживаете? Сколько по времени обойдется, если нормально сделать? А если закостылить? Ну и рассчитывал бы на сессию совместного проектирования. А вот цикл "вот вам постановка - мы так не можем" обычно ни к чему хорошему не приводит, только к выгоранию аналитика.

Для лидов-аналитиков контента почему-то мало, попробую разбавить. Будет пост для лидов. Основная забота лидов — конечно, отслеживать производительность. Одновременно поддерживать командный дух и вообще хорошее самочувствие (well-being). Для разработчиков есть много фреймворков для оценки и производительности, и самочувствия, и других факторов. Есть DORA, SPACE, DevEx, а самый новый, 2025 года, объединивший их все — DX Core 4 Я (с помощью ИИ) попробовал адаптировать DX Core 4 для системных аналитиков. Вот что получилось. Фреймворк состоит из четырех блоков: 1. Скорость 2. Эффективность 3. Качество 4. Влияние Скорость Главная метрика: производительность, объем поставок — сколько аналитических артефактов передается разработчикам в неделю / месяц (смотря какие у вас характерные скорости). Это общая метрика на подразделения / гильдии, ни в коем случае не персональная! Вторичные метрики: - Скорость прохождения требований: Сколько времени в среднем проходит от постановки задачи до передачи итогового артефакта разработчикам. Так как задачи бывают очень разного объема и их сложно сравнивать, тут можно ввести категоризацию по масштабу (но не сильно сложную, . - Скорость согласования требований со стейкхолдерами (среднее время полного цикла согласования) - Воспринимаемая скорость поставки (оценочно, как аналитикам кажется: быстро они сдают свои артефакты?) Эффективность Главная метрика комплексная: AXI, Analyst Experience Index, Индекс опыта аналитика Собираем индивидуальные оценки удовлетворенности от каждого аналитика по шкале от "Совершенно не удовлетворен" до "Вполне удовлетворен" Компоненты AXI: - Доступ к стейкхолдерам и экспертам предметной области - Качество имеющейся документации - Инструменты моделирования и анализа - Процессы ревью требований - Взаимодействие с другими командами и ролями - Ясность целей и задач бизнеса - Наличие времени на глубокую проработку (против контекстных переключений) - Процессы управления изменением требований - Доступ к данным для анализа Дополнительные метрики: - Время до 10-го сданного артефакта (для новых аналитиков) - Легкость сбора требований (субъективная) - Частота ухода ценных аналитиков из организации / команды Качество Ключевая метрика: уровень дефектов требований. Доля требований, потребовавших дополнительных уточнений или переделывания после передачи в разработку. Вторичные метрики: - Доля пропущенных требований (обнаруженных уже в процессе разработки/тестирования) - Удовлетворенность стейкхолдеров взаимодействием с аналитиками - Доля переделок в коде из-за ошибок анализа - Актуальность документации / архитектурных схем и т.п. Влияние (Импакт) Главная метрика: Доля времени, потраченная на принципиально новые функции (в отличии от времени на некоторое улучшение существующих функций или отработки дефектов) Дополнительные метрики: - Среднее соотношение времени на анализ и на разработку для одной единицы функциональности (пользовательской истории, фичи) - Ценность для бизнеса в пересчете на аналитика (очень сложно посчитать, тут если только вы считаете ROI конкретной фичи) - Соотношение выпущенных фичей (если у вас бывает, что аналитик работает "в стол") Как это применять: ну, в идеале, должна быть триангуляция, то есть получение объективных данных (из систем), субъективных (опросных), и взгляда с другой стороны (стейкхолдеры, разработчики). На практике можно для начала провести опрос, чтобы понять базовые значения, с которых стартуем. Вот ссылка на заготовку для опросов. Главное, нужно следовать нескольким правилам: 1. Это не оценка людей, это оценка процессов 2. Чинить нужно одну вещь за один раз (за квартал, например) 3. Метрики работают только вместе (чтобы не ухудшать одну метрику за счет других) Вот такой инструмент, как вам? Я бы с большим интересом поговорил про опыт внедрения!