Небольшая пауза (целых 10 дней) - чтобы собрать мысли, систематизировать опыт и… запустить новую мини-серию постов 👀

Будет про то, что меня сильно триггерит в последнее время: передача проекта с проекта внедрения на проект сопровождения (для процесса передачи заказчика от одного аналитика другому тоже релевантная тема).

Скоро первый пост - будет полезно 💪

Стартую новую мини-серию постов про один из самых сложных моментов в жизни аналитиков - передачу проектов и заказчиков.

Внедрение 🔜 сопровождение.
Старый аналитик 🔜 новый аналитик.

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

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

Будет практично, честно и по-настоящему аналитически.

А пока что, в комментариях, поделитесь своими болями при работе с заказчиками? Что вас сильно триггерит? 🙈

Почему передача проекта - это всегда риск?

Передача заказчика или смена аналитика - это тот момент, когда идеально выстроенные процессы могут внезапно поехать боком.
Не потому что кто-то плохой - просто при смене ломается всё, что держалось на личном опыте, негласных договорённостях и “мы уже все поняли друг друга”.

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

Передача - всегда риск. Но это риск управляемый.
Эта мини-серия постов про то, как сделать переход мягким и без “а нам это никто не говорил”.

📋 Чек-лист передачи проекта на сопровождение

Вот минимальный, но рабочий чек-лист того, что должен оставить после себя аналитик внедрения (помимо документации):
1️⃣ Контекст “почему так” - мотивация решений важнее формальных описаний.
2️⃣ Карта решений - что реализовано, что было отброшено и почему.
3️⃣ Зона неопределённостей - всё недоделанное, не согласованное, спорное.
4️⃣ Ключевые контакты - кто реально принимает решения, кто просто наблюдатель.
5️⃣ Особенности взаимодействия - стили общения, триггеры, табу, предпочтения.
6️⃣ История конфликтов и договорённостей - да, это тоже важно.

Документация - это хорошо.
Документация + живой контекст - это то, что позволяет передать проект на сопровождение без боли, страданий и ненужных последствий.

❓А какой пункт вы бы ещё добавили в этот список?

Ошибки, которые ломают передачу ⛓️‍💥

Давайте сегодня рассмотрим самые частые ошибки передачи проекта на сопровождение:

1️⃣ “Документация актуальна” - почти никогда. 🙅‍♂️
2️⃣ “Там всё понятно” - если так говорят, значит ничего не понятно. 🙅‍♂️
3️⃣ “Они сами разберутся” - нет, не разберутся, и придут к тебе спрашивать.❓
4️⃣ “Мы договорились устно” - значит, договорённости больше нет.🙅‍♂️
5️⃣ “Не будем грузить ненужным” - обычно это как раз то, что потом взрывается.🤯

Передача - это не задача просто “сделать красиво”, это задача “сделать честно”.
Честно передавать проект - значит говорить и о хорошем, о плохом и о сложном.
Это экономит нервы, время команды и бюджет заказчика (лучше эти деньги потратить на развитие системы, чем на то, чтобы разбираться, что там у них вообще происходит)

Как быстро войти в хату проект без боли и не выбирать между двух стульев😂

Если ты принимаешь проект от другого аналитика, вот короткий алгоритм, который спасает нервы:
1️⃣ Запросить картину мира - что работает, что болит, что ждут;
2️⃣ Понять историю решений - не “что сделали”, а “почему сделали именно так”;
3️⃣ Провести короткий разговор с заказчиком - чтобы услышать, что он считает важным;
4️⃣ Выявить зоны риска - устные договорённости, серые процессы, слабые места;
5️⃣ Сформировать план “входа” - от мелких задач к глубокому контексту.

Главная ошибка новичков - пытаться разобраться во всём сразу.
Главная сила - уметь выделить основное и отбросить шум.

🧩 Как сказать заказчику, что аналитик/команда меняется - и не потерять доверие

Сегодня завершаем серию постов про передачу проектов между проектами/командами/аналитиками этим постом.

Самая большая ошибка - просто сообщить:
«У нас смена аналитика, скоро познакомим».
Заказчик слышит совсем другое:
👉 «Потеряется контекст»
👉 «Опять всё объяснять»
👉 «Проект замедлится»

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

Что важно донести:

1️⃣ Мы не теряем контекст - мы им управляем
Передача не событие, а процесс.
Новый аналитик уже погружается: история решений, риски, договорённости - всё передано.

2️⃣ Это не замена, а усиление
Новый аналитик закрывает зоны, где раньше была нехватка внимания: интеграции, бизнес-процессы, документация.

3️⃣ Ответственность остаётся на нас
Команда не снимает ответственность.
Вы не начинаете «заново» - вы получаете более устойчивую модель работы.

🎯 Главный посыл:

Не «у нас смена аналитика»,
а «мы усиливаем проект и сохраняем всё, что уже ценное».

▪️ А вам когда-нибудь передавали проект так, что хотелось сказать «спасибо», а не «за что мне это»?

🧠 Думаешь, анализируешь логично? Возможно, ты уже в ловушке.

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

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

Вот что они могут делать с твоим мышлением:
🔹 Уверенность без фактов
🔹 Бесконечный сбор данных без решений
🔹 Игнорирование рисков
🔹 Или наоборот - паралич от количества вариантов

Да, мы все попадаем в эти ловушки.
Но большинство даже не замечает, в какую именно и почему.

👇 Я сделал короткий тест в Telegram - всего 4 вопроса.
Он покажет, в какую аналитическую ловушку ты попадаешь чаще всего, и главное - как выбраться.

📲 В конце ты получишь:
✔️ Твою ловушку
✔️ Почему ты в неё попадаешь
✔️ Что с этим делать на практике

Готов проверить своё мышление? 👇

ПРОЙТИ ТЕСТ

🎯 Почему сопровождение в проектных системах - это отдельная профессия

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

🟦 Продуктовая модель (SaaS, коробки, онлайн-продукты)

Один продукт - много клиентов.
Логика общая, изменения общие, ошибка у одного - исправление у всех.

В данном случае, сопровождением занимается сам продуктовая команда.

🟪 Проектная / кастомная модель (например СЭД)

Один продукт - но каждый клиент живёт в своём уникальном мире.
Внедрение выполняет прикладную разработку под каждого клиента ➡️ команда уходит на следующий проект ➡️остаётся система, которую нужно понимать, развивать и не ломать.

Здесь продуктовая команда не подходит, а команда внедрения уже на новом проекте.

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

И это уже не просто поддержка.

🧩 Суть в двух предложениях

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


❓ Какая роль у вас ближе по факту: аналитик сопровождения или всё-таки L2?

👀 Сопровождение глазами аналитика: что мы делаем каждый день

Мы с вами уже говорили, что про сопровождение часто думают так:
что-то сломалось → починили → закрыли обращение (он же тикет).

На практике всё сильно шире 👇

🛠 Гарантийная поддержка после внедрения
Когда система только вышла в прод, проведена ОПЭ, и она ещё «осваивается» в реальной жизни.

🚨 Инцидентная поддержка
Ошибки, сбои, странное поведение системы.
Важно не просто починить, а понять причину и последствия.

🔁 Запросы на изменение
Бизнес меняется → процессы меняются → система тоже должна меняться.

🧾 Запросы на обслуживание
Пользователи, роли, справочники, настройки, регламенты.
Рутина, без которой система просто не живёт.

🏗 Анализ и изменения архитектуры
Чтобы решение не превратилось в «лоскутное одеяло» через год.

⬆️ Обновления до новых версий
Не «поставили и забыли», а анализ влияния и адаптация под кастомизацию и процессы заказчика.

💬 Консультационная поддержка
Вопросы, сомнения, сценарии «а если мы сделаем вот так».

📌 Суть простая:
сопровождение - это не поддержка системы, а поддержка её ценности для бизнеса.

Если этим никто не управляет - система деградирует, даже если формально «работает».

❓А теперь вопрос-затравка на следующий пост:
Что из этого списка у вас чаще всего недооценивают?

Что чаще всего недооценивают в работе аналитика 🤯

Со стороны кажется, что аналитик - это:
📄 собрал требования
🗂 оформил
➡️ передал дальше

На практике - всё немного иначе.

Вот что почти всегда недооценивают (и во внедрении, и в сопровождении):

🗣 Перевод с «человеческого» на «системный»

Заказчик говорит словами.
Система живёт логикой.

Аналитик - переводчик между этими мирами:
▪️ожидания ↔️ ограничения
▪️желания ↔️ последствия
▪️«хочу» ↔️ «что реально получится»

⚖️ Работа с неопределённостью

Часто требований ещё не существует.
Есть ощущения, гипотезы, страхи и «давайте пока так».

И аналитик:
▪️формирует структуру из хаоса
▪️помогает принять решение
▪️берёт на себя ответственность за выбор

Это сильно выматывает - и почти никогда не видно со стороны.

🔄 Поддержание целостности решения

Каждая маленькая правка:
▪️влияет на процессы
▪️цепляет архитектуру

Недооценивают, что аналитик постоянно держит в голове всю систему, а не одну задачу.

😮‍💨 Эмоциональная нагрузка

Переговоры. Давление сроков. Конфликты интересов.
«Почему так долго?», «А раньше работало», «Вы же аналитик - разберитесь».

Это не soft skills «по желанию».
Это часть профессии.

💡 Поэтому аналитика нельзя мерить количеством документов или закрытых задач.
Его работа - в том, чтобы система в итоге работала и развивалась, а не просто была «сделана».

❓Какой из этих пунктов у тебя «отъедает» больше всего энергии?

🎄 С наступающим Новым годом, коллеги-аналитики и все, кто живёт в сложных системах

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

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

Пусть в новом году:
▪️требования будут формулироваться чуть яснее 🧩
▪️решений «на коленке» станет меньше ⚙️
▪️паузы на анализ будут восприниматься как сила, а не слабость 🧠
▪️а сопровождение наконец будут считать полноценной аналитической работой, а не «после внедрения само как-нибудь» ✨

Спасибо, что читаете, спорите, думаете и делитесь опытом.
Этот канал - про аналитику без глянца, и в следующем году будет ещё больше реальных кейсов, схем и разговоров «как есть».

С Новым годом.
Пусть системы будут устойчивыми, а вы - в ресурсе 🍷

Про НДС, дедлайны и почему прод лучше не трогать под Новый год 🎄⚠️

С 1 января в России вступили в силу новые ставки НДС.
И это тот случай, когда изменение в законе мгновенно превращается в изменение в IT-системах.

Особенно у тех, кто:
▪️обменивается первичными документами через сервисы ЭДО
▪️интегрирован с внешними площадками
▪️работает не «в вакууме», а в цепочке из нескольких систем

📌 Фактически у всех таких заказчиков:
🔹поменялись форматы документов
🔹обновились правила валидации
🔹потребовались изменения в расчётах
🔹сломалась обратная совместимость со старыми версиями

И всё это - в кратчайшие сроки.
Потому что с 1 января документы с «не той» ставкой просто не проходят.

Что это значит на практике 🧩
🔸обновления пришлось делать массово и синхронно
🔸правки касались не одного места, а всей цепочки: от БД до интеграций
🔸любое расхождение = ошибка у контрагента
🔸поддержка 1–2 линии тут бессильна - нужна аналитика в контексте конкретной системы

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

И главный вывод 👇

Обновления продуктива перед новогодними праздниками - плохая идея.

Почему:
▫️команда в отпуске или на минимальном составе
▫️бизнес не готов к сбоям
▫️откат делать некому
▫️а изменения часто всплывают уже на реальных данных

Но реальность такова, что законодательство не ждёт удобного момента.
И именно поэтому сопровождение - это не “поддержка”, а управление рисками.

❓ Вопрос к вам:
А на вас как-то отразились изменения в законодательстве?

Честно: иногда просто нет сил

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

Думаю состояние, знакомое многим в IT:
▪️ откладываешь простые задачи
▪️ сложно начать, даже когда понимаешь что делать
▪️ нет ощущения «втягивания» в работу
▪️ любое действие требует непропорционально много усилий

Мы привыкли:
➖ держать темп
➖ быть постоянно включёнными
➖ быстро думать и быстро отвечать

Это не выгорание «по учебнику». Скорее накопленная усталость и перегруз головы.

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

❕Я возвращаюсь в канал без резких стартов.
Дальше снова будут посты про аналитику, сопровождение и реальные кейсы.
Просто в нормальном, человеческом ритме.

Иногда лучший способ остаться в форме - вовремя дать себе паузу.

❓ Вопрос напоследок:
А ты сейчас больше про «разгоняться» или про «чуть притормозить»?

Как понять, что система «поплыла», даже если формально всё работает?

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

Но аналитик уже чувствует: что-то не так.

Вот несколько признаков, что система начала деградировать, даже если внешне всё «зелёное» 👇

🧩 Каждое новое изменение обсуждается дольше, чем реализуется
Потому что никто уже до конца не понимает, на что это повлияет.

🩼 Появляются “временные решения”, которые остаются навсегда
Костыль для одного кейса → зависимость для всей системы.

🧠 Знания о системе живут в головах, а не в документации
И каждый уход человека - это риск.

💣 Любое обновление вызывает страх
Не потому что сложно, а потому что последствия непредсказуемы.

🌀 Похожие запросы каждый раз решаются по-разному
Потому что целостной логики уже нет.

Самое опасное здесь то, что:
❗ система может работать так месяцами и даже годами, медленно теряя управляемость.

И чаще всего это не техническая проблема.
Это проблема отсутствия аналитического контроля и архитектурного мышления в сопровождении.

В следующем посте разберем как аналитик может остановить деградацию системы ✋

📣 Как аналитик может остановить деградацию системы, не ломая всё сразу?

Деградация системы почти никогда не выглядит как авария.
Чаще она маскируется под «рабочее состояние»:
функциональность есть, пользователи привыкли, бизнес живёт дальше.

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

Переписывать систему целиком в этот момент уже поздно.
И именно здесь появляется реальная зона ответственности аналитика.

1️⃣ Зафиксировать реальное состояние системы, а не проектное

Первое, что делает аналитик, - перестаёт опираться на документацию «как должно быть».
Он описывает:
• как система реально используется
• какие бизнес-правила фактически работают
• где логика дублируется или противоречит сама себе

Это не аудит ради аудита.
Это восстановление фактической модели системы.

2️⃣ Выделить точки деградации, а не «всё плохое сразу»

Важно понимать:
не всякая сложность - проблема.

Аналитик отделяет допустимую сложность от деградации, которая создаёт риски

Критерии простые:
• рост стоимости изменений
• рост числа ошибок
• зависимость от конкретных людей
• страх перед обновлениями

Если хотя бы два пункта совпадают - это зона внимания.

3️⃣ Перевести технический долг из абстракции в управляемые решения

«Технический долг» сам по себе ничего не значит.
Пока он не:
• привязан к конкретным рискам
• описан в терминах последствий
• встроен в приоритеты изменений

Аналитик помогает сформулировать долг так, чтобы им можно было управлять, а не просто бояться.

4️⃣ Встраивать улучшения в поток обычных изменений

Самая частая ошибка - ждать отдельного проекта на «разбор полётов».

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

Маленькие шаги стабилизируют систему лучше любых революций.

5️⃣ Работать с ожиданиями, а не с иллюзией идеала

Аналитик не обещает «сделать красиво».
Он объясняет:
• какие риски снимаются
• какие остаются
• почему некоторые решения - компромисс

Это снижает давление «давайте быстро и идеально» и возвращает контроль над системой.

6️⃣ Удерживать целостность как постоянную задачу

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

Эта работа редко видна, но именно она делает систему устойчивой.

❗️Итог

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

И в сложных, кастомных системах это часто самая ценная работа, которую вообще можно сделать.

Куда я пропал и что происходило 🤔

В канале было тихо.
Причём дольше, чем планировал (аж с 6 февраля)😅

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

Последние недели были в режиме:
🔥 работа
🧠 мысли
📉 посты - «потом»

За это время:
— плотно занимался проектами
— готовил материалы и подавался на конференции для аналитиков
— выступал с докладом на гильдии аналитиков Directum (напишу отдельный пост про это)

И вот интересный момент 👇

Когда начинаешь готовить доклад, вдруг понимаешь, сколько всего ты делаешь в работе «на автомате»…
и даже не считаешь это чем-то сложным.

А потом пытаешься это объяснить - и такой: «так, а это вообще как словами описать?» 😄

В какой-то момент ловишь себя на мысли:
аналитика - это не про требования. И даже не про системы.

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

В общем, я вернулся 🙂
Дальше снова будут посты про аналитику, сопровождение и реальные кейсы.
Материала накопилось нормально.