Ого, меня тут 2 месяца не было 🙈
Зато новости и приколы накопились, которыми поделиться можно!
Сегодня постараюсь начать писать обо всем (но не обещаю😃).

🎤 В июне буду выступать на ЛАФ 2026

Это первая новость, про которую хотел рассказать ещё вчера!

13–14 июня выступаю с докладом на конференции ЛАФ 2026 на тему:

«Сопровождение ≠ поддержка. Как аналитик помогает бизнесу получать ценность от системы после внедрения»

И если честно - для меня это немного больше, чем просто доклад 🙂

Ровно год назад я был на ЛАФ как обычный участник:
сидел в зале, слушал спикеров, записывал мысли и смотрел на людей, которые выступают на сцене.

И именно тогда впервые поймал себя на мысли: «А ведь я тоже хочу здесь выступить»
Тогда это казалось чем-то очень далёким 😄

А сейчас я уже сам готовлю доклад для этой конференции.

И если вдруг будете на ЛАФ - буду рад увидеться и пообщаться!

P.S.: На картинке то, как по версии ИИ я выступаю на конференции 😂

Чему сопровождение учит лучше внедрения

Когда я только начинал работать в сопровождении, мне казалось, что основная работа аналитика - решать инциденты, согласовывать изменения и общаться с заказчиками.

Но со временем пришло другое понимание.

Сопровождение учит тому, чему невозможно научиться на внедрении.
Оно учит видеть последствия решений.

Во время внедрения мы работаем с будущим.
Проектируем процессы.
Продумываем архитектуру.
Принимаем решения.

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

Именно здесь становится видно:

🧩 Какие решения действительно были удачными.
⚠️ Какие временные решения неожиданно стали постоянными.
📚 Какие недокументированные изменения превратились в проблему.
🏗 Какие архитектурные компромиссы начинают мешать развитию системы.

—————————————————

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

Наверное, именно поэтому аналитики сопровождения часто становятся осторожнее.
Потому что они уже видели, как решения стареют.

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

—————————————————

Для меня одна из главных ценностей сопровождения именно в этом.
Оно показывает не только то, как создавать решения.
Оно показывает, как потом с ними жить.

🤔 Сталкивались ли вы с моментами, когда решения в ваших проектах спустя время оказались очень дорогими по последствиям?

🎤 ЛАФ 2026: от участника до спикера за один год

Пришло время рассказать о том, как прошел для меня ЛАФ 2026 (будет много текста, запаситесь терпением😃)

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

Именно тогда появилась мысль:

💭 «А ведь однажды я тоже хочу выступить здесь со своим докладом».

А в прошлые выходные я уже сам стоял перед аудиторией и рассказывал про тему, которой занимаюсь последние несколько лет:

«Сопровождение ≠ поддержка. Как аналитик помогает бизнесу получать ценность от системы после внедрения»

⸻⸻⸻⸻⸻

Перед выступлением было ОЧЕНЬ волнительно.

Настолько, что во время выступления голос заметно дрожал 🙈

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

Причём большинство вопросов были не про теорию, а про практику:

🧩 Как устроено сопровождение у нас?
🧩 Как мы действуем в сложных ситуациях?

Для меня это стало подтверждением того, что тема действительно интересна и востребована.

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

⸻⸻⸻⸻⸻

Ещё один интересный момент.

Когда я был участником, я концентрировался на содержании докладов:

📚 что рассказывают
📚 какие идеи можно забрать себе
📚 какие практики попробовать

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

⸻⸻⸻⸻⸻

Главный вывод после ЛАФ 2026:

🚀 хочу выступать ещё.

Этот опыт показал мне, что знаний и практики уже достаточно, чтобы делиться ими с профессиональным сообществом.
А значит, дальше нужно прокачивать следующий навык - ораторское мастерство.

⸻⸻⸻⸻⸻

И если бы я мог вернуться на прошлогодний ЛАФ и дать себе один совет, он был бы таким:

👉 Слушай не только о чём говорят, но и смотри, как об этом говорят.

Спасибо всем, кто пришёл на доклад, задавал вопросы и участвовал в обсуждении 🤝

📊 Как расставлять приоритеты в бэклоге: 3 рабочих способа

«Просто расставьте приоритеты» - звучит легко, пока не открываешь список из огромного количества задач, где всё «важно» и «горит».

Вот три способа, которые реально работают. Не как единственно верный, а как разные инструменты под разные ситуации.

1. MoSCoW - раскладываем по важности

Берёте каждую задачу и решаете: без неё нельзя (Must), хорошо бы, но не критично (Should), можно сделать при наличии времени (Could), пока не делаем (Won’t).
Никакой математики - просто раскладываете по 4 корзинам.

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

Ловушка: соблазн запихнуть всё в «без неё нельзя». С этим приходится бороться отдельно, метод сам не спасает.

2. RICE - считаем по формуле

Берёте каждую задачу и оцениваете: скольких пользователей коснётся (Reach), насколько сильно повлияет (Impact), насколько вы уверены в своей оценке (Confidence), сколько сил уйдёт (Effort). Считаете и сравниваете числа.

Подходит, когда есть данные (статистика использования) и команда готова тратить время на оценку, а не решать на глаз.

Ловушка: если оценки занижать «на всякий случай» - метод превращается в красиво оформленное гадание.

3. Kano - делим доработки по типу ценности

Есть вещи, которые просто должны работать (их отсутствие бесит, а наличие не радует, - это базовые характеристики). Есть вещи, где чем больше - тем лучше (перформанс-характеристики). А есть то, чего не ждали, но за что скажут спасибо (восхищающие характеристики).

Подходит для вопроса «что вообще делать», а не «что делать быстрее». Для сопровождения актуально редко - там чаще уже понятно, что делать, вопрос только в очерёдности.

🧐 Как выбирать

Операционный бэклог сопровождения → MoSCoW.

Развитие продукта, есть данные → RICE.

Стратегические решения про продукт → Kano.

Можно и комбинировать: сначала разложить по MoSCoW, а внутри «Should have» - посчитать по RICE.

—————————————————

❓ Как расставляете приоритеты вы?

💬 «Мы же всё обсудили на созвоне»

Знакомая фраза?
Вот и мне знакома. И каждый раз, когда её слышу, внутри что-то ёкает - потому что дальше обычно начинается веселье.

Созвон закончился, все разошлись довольные: вроде договорились.
Проходит три недели. Разработчик показывает готовый результат - и тут выясняется, что заказчик имел в виду одно, аналитик услышал второе, а разработчик на всякий случай сделал так, как «показалось логичным».

И вот вы втроём сидите и пытаетесь вспомнить, кто что говорил 21 день назад.
Спойлер: никто не вспомнит точно. Память - не диктофон, она достраивает то, что «должно было быть сказано», а не то, что было сказано на самом деле.

И дело не в том, что кто-то невнимательный или недоговороспособный. Просто устная речь по умолчанию неточная, а мы почему-то ждём от неё точности письменного ТЗ.
Работает только одно: после созвона - текстом. Даже одна строчка «правильно понимаю, что…» в чат. Не потому что так положено, а потому что это единственный способ поймать расхождение сразу, а не через несколько недель.

Разговор - это черновик. Текст - это версия, с которой можно работать.

———————————————————

❓ А у вас как — фиксируете созвоны сразу, или тоже иногда «на память» надеетесь?

🎯 Три ошибки почти каждого аналитика в первый год

Есть ошибки, которые совершает не «невнимательный» или «неопытный» аналитик, а их совершает почти каждый, потому что они зашиты в саму логику входа в профессию.

Разбираем три самые частые.

1. Брать запрос заказчика как готовое требование

Заказчик говорит:

Сделайте отчёт с фильтром по дате.

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

Разница между «записать, что сказали» и «понять, зачем это нужно» - это разница между исполнителем и аналитиком.

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

2. Бояться сказать «нет» или «не сейчас»

Запрос прилетает - новичок берёт в работу. Прилетает ещё один - тоже берёт.
К концу недели пять параллельных задач, ни одна не сделана нормально, и объяснить заказчикам, почему так вышло, куда сложнее, чем было бы сразу сказать «беру в такую-то очередь».

Первый год часто держится на страхе разочаровать. Только это не помогает. Разочарование просто откладывается и становится больше.

3. Считать, что документация - это формальность «для галочки»

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

Что объединяет все три:

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

———————————————————

❓ Какую из трёх вы узнали в себе на старте или какая четвёртая просится в список?