Звоните аналитику
53 subscribers
20 photos
3 videos
1 link
Здесь о том, как аналитик помогает бизнесу получать ценность от системы после внедрения.
Когда нужен результат - звоните аналитику.
Download Telegram
Кстати, сегодня - Международный день бизнес-аналитика!
Того самого человека, который задаёт по 100 «а зачем?» в день и пытается не сойти с ума от информации, которая копится у него в голове. 😄
С праздником, коллеги! Пусть ваши заказчики отвечают на уточнения как можно быстрее, а требования - не противоречат сами себе 💪
❤5🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
#МинуткаЮмора
То самое чувство, когда любимый заказчик написал что-то приятное после того, как ты им помог решить ошибку в системе 😁
🤣5❤2
Небольшая пауза (целых 10 дней) - чтобы собрать мысли, систематизировать опыт и… запустить новую мини-серию постов 👀

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

Скоро первый пост - будет полезно 💪
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6❤2
Стартую новую мини-серию постов про один из самых сложных моментов в жизни аналитиков - передачу проектов и заказчиков.

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

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

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

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

А пока что, в комментариях, поделитесь своими болями при работе с заказчиками? Что вас сильно триггерит? 🙈
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Почему передача проекта - это всегда риск?

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

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

Передача - всегда риск. Но это риск управляемый.
Эта мини-серия постов про то, как сделать переход мягким и без “а нам это никто не говорил”.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4
This media is not supported in your browser
VIEW IN TELEGRAM
😁 Когда аналитика спрашивают: какую информацию по заказчику ты будешь передавать другой команде?
🤣5
Внедрение vs сопровождение: две разные вселенные

Есть два параллельных мира:

🧱 Мир внедрения
Заказчик вовлечен, ходит на созвоны, готов обсуждать, что поменять и где подвинуть.
У всех ощущение: “мы вместе делаем что-то новое”. (Да, так не всегда. Есть сложные заказчики, к которым надо найти подход).

🛠 Мир сопровождения
Заказчик хочет, чтобы все работало как обычно:
быстро, как было, без сюрпризов и желательно вчера.

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

Важно проговаривать это и команде, и самому заказчику:
контекст меняется 〰️ ожидания меняются 〰️ значит, должен меняться и подход к взаимодействию.

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

❓ А вы как думаете, передача между проектами (с внедрения на сопровождение) - больше про процессы или про людей?
❤3❤‍🔥3
📋 Чек-лист передачи проекта на сопровождение

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

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

❓А какой пункт вы бы ещё добавили в этот список?
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤5
Ошибки, которые ломают передачу ⛓️‍💥

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

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

Передача - это не задача просто “сделать красиво”, это задача “сделать честно”.
Честно передавать проект - значит говорить и о хорошем, о плохом и о сложном.
Это экономит нервы, время команды и бюджет заказчика (лучше эти деньги потратить на развитие системы, чем на то, чтобы разбираться, что там у них вообще происходит)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3💯2
Как быстро войти в хату проект без боли и не выбирать между двух стульев😂

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

Главная ошибка новичков - пытаться разобраться во всём сразу.
Главная сила - уметь выделить основное и отбросить шум.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4
🧩 Как сказать заказчику, что аналитик/команда меняется - и не потерять доверие

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

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

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

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

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

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

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

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

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

▪️ А вам когда-нибудь передавали проект так, что хотелось сказать «спасибо», а не «за что мне это»?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤1
🧠 Думаешь, анализируешь логично? Возможно, ты уже в ловушке.

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

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

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

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

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

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

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

ПРОЙТИ ТЕСТ
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥5👍3
🎭 Типы заказчиков и в какие ловушки они нас загоняют

Если честно: многие аналитические ловушки - не “наши”, а провоцируются стилем общения заказчика.

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

Вот четыре распространённых типа 👇

🌀 1. Хаотичный заказчик

— прыгает с темы на тему
— “давайте пока сделаем вот это… а ещё вот то… и вот тут допишем”
— задачи - иллюзия, требований нет

Ловушка, в которую он загоняет аналитика:
→ Сверхобобщение (“ладно, сделаем, там разберёмся”).
→ Затыкание дыр вместо анализа.

Как выйти:
Фиксировать всё письменно и замыкать каждую мысль в рамку.

🧊 2. Холодный заказчик

— всё по делу
— эмоций ноль
— требования сухие и часто неполные
— ждать инициативы не стоит

Ловушка:
→ Чтение мыслей (“он ожидает, что я сам пойму”).
→ Проецирование (“раз он молчит - значит всё ок”).

Как выйти:
Проверять понимание вслух. При нуле эмоций “согласен” ≠ “утвердил”.

🔥 3. Импульсивный заказчик

— быстро загорается
— меняет решения на ходу
— любит “давайте попробуем”
— нажимает на скорость

Ловушка:
→ Эффект ложной срочности: делаешь не то, что важно, а то, что громко.

Как выйти:
Показывать стоимость изменений. И давать выбор в цифрах, не в эмоциях.

🧩 4. Контролирующий заказчик

— проверяет каждую мелочь
— сомневается везде
— хочет отчётов, подтверждений, ограничений
— любит вопрос “а точно?”

Ловушка:
→ Доказательная зависимость - объяснять всё бесконечно.
→ Уход в микродетали.

Как выйти:
Сразу формировать пакет “контрольных точек”: что, зачем, к чему идём.

🎯 Главное понять

Каждый тип заказчика вызывает свою ловушку.
И сила аналитика — не в том, чтобы бороться с заказчиком,
а в том, чтобы видеть паттерн
и управлять реакцией, вместо того чтобы в неё падать.
❤5👍4🔥2❤‍🔥1
🧠 Почему аналитику нельзя отвечать на вопросы моментально

(и как объяснить это заказчику без конфликтов)

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

Вот почему быстрые реакции - это ловушка:

1️⃣ Моментальный ответ = опора на догадки

Аналитик - не поисковик.
У нас нет встроенной базы данных со всеми зависимостями.
Любой вопрос - это пазл: откуда берётся, на что влияет, что затронет.

2️⃣ Быстрые ответы формируют ложные ожидания

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

3️⃣ Спонтанный ответ = риск переписать полсистемы

Обычно самые лёгкие ответы - самые дорогие.

4️⃣ Аналитик отвечает не на вопрос, а на последствие

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


🧘 Как объяснить заказчику, что на подумать нужно время

Даю готовые формулировки, чтобы не выглядеть тормозящим:

✔️ «Чтобы не дать ошибочную оценку, я зафиксирую вопрос и вернусь с точным ответом через N минут/часов»


Так ты ставишь рамку и показываешь ответственность.

✔️ «Мне важно понять контекст, чтобы не запустить цепочку дорогих изменений»


Всегда работает - никто не хочет дорогих изменений.

✔️ «Мне нужно свериться с процессами/ограничениями, чтобы не дать вам неверную информацию»


Аккуратно перекладывает фокус на качество, а не на скорость.

✔️ «Лучше потратить 10 минут на анализ, чем 10 часов на переделку»


Идеальная фраза. Без агрессии, но с логикой.


🧩 Главная идея

Аналитик - не про скорость реакции.
Аналитик - про осознанные решения.


И чем взрослее команда и заказчик, тем больше они это ценят.

Вы сами чаще берёте паузу или пытаетесь ответить сразу?
❤7👍2
🎯 Почему сопровождение в проектных системах - это отдельная профессия

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

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

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

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

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

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

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

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

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

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

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



❓ Какая роль у вас ближе по факту: аналитик сопровождения или всё-таки L2?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7✍2👍2
👀 Сопровождение глазами аналитика: что мы делаем каждый день

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

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

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

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

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

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

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

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

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

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

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

❓А теперь вопрос-затравка на следующий пост:
Что из этого списка у вас чаще всего недооценивают?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6
Что чаще всего недооценивают в работе аналитика 🤯

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

❓Какой из этих пунктов у тебя «отъедает» больше всего энергии?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6😘2🔥1
🎄 С наступающим Новым годом, коллеги-аналитики и все, кто живёт в сложных системах

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

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

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

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

С Новым годом.
Пусть системы будут устойчивыми, а вы - в ресурсе 🍷
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7
Про НДС, дедлайны и почему прод лучше не трогать под Новый год 🎄⚠️

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

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

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

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

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

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

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

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

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

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

❓ Вопрос к вам:
А на вас как-то отразились изменения в законодательстве?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6
Честно: иногда просто нет сил

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

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

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

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

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

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

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

❓ Вопрос напоследок:
А ты сейчас больше про «разгоняться» или про «чуть притормозить»?
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤7💯3🔥2
Как понять, что система «поплыла», даже если формально всё работает?

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

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

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

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

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

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

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

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

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

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

В следующем посте разберем как аналитик может остановить деградацию системы ✋
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4❤‍🔥3