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

Салют! Есть шутка в профессии: аналитика не любят ни бизнес ни разработка. Бизнес считает что ты на стороне IT и тормозишь. Разработка считает, что ты на стороне бизнеса и генеришь бесконечные хотелки. А ты стоишь посередине и пытаешься сделать так чтобы все были живы.
Я провела в этой позиции двенадцать лет. И да, первые несколько лет это реально выматывало. Потом поняла несколько вещей которые изменили отношение к этой роли.

Ты не переводчик. Ты модератор конфликта интересов

Долгое время я думала, что моя задача — переводить с языка бизнеса на язык разработки и обратно. Технически это так. Но если смотреть глубже — аналитик работает в точке где сталкиваются два мира с разными целями.
Бизнес хочет всё, быстро и желательно вчера. Разработка хочет чёткие требования, стабильный скоуп и время сделать нормально. Эти желания почти никогда не совпадают полностью.
Главная ловушка — пытаться угодить всем. Это невозможно. И попытка усидеть на двух стульях приводит к тому что не доверяют ни те ни другие.
Баланс который я нашла: моя лояльность не людям, а результату. Я на стороне проекта — не бизнеса и не разработки. Звучит просто, но внутри перестроиться непросто.

Что реально помогает
Не передавай требования — объясняй контекст

Худшее что может сделать аналитик — принести разработчику список требований без контекста. “Бизнес сказал сделать вот так.” Всё, ты стала почтальоном.
Разработчик должен понимать зачем это нужно, какую проблему решает, что будет если сделать иначе. Когда человек понимает зачем — он предлагает решения лучше тех что придумал бизнес. И это победа для всех.
Не ходи к разработке с сырыми требованиями
Прежде чем идти к команде я сама прохожусь по требованиям и задаю себе неудобные вопросы. Что будет если пользователь сделает вот так? А если данных нет? А если два пользователя одновременно? Какой сценарий если что-то пошло не так?
Лучше найти дыры самой, чем услышать их на разборе задач с командой. Разработка это запомнит — в хорошем смысле.
Когда бизнес и разработка конфликтуют — не исчезай
Самый плохой сценарий: бизнес и разработка начинают выяснять отношения, а аналитик тихонько выходит из чата. Я так делала. Казалось что конфликт не мой.
Мой. Потому что в основе почти любого конфликта между бизнесом и разработкой — неточные или противоречивые требования. Разруливать это всё равно придётся, только потом и с большими потерями.
Сейчас я захожу в такие конфликты первой. Не чтобы встать на чью-то сторону, а чтобы вытащить на поверхность в чём реальное расхождение. Часто оказывается что люди спорят об одном и том же просто разными словами.

Фиксируй решения принятые не тобой

Бизнес принял решение которое технически сомнительное. Разработка приняла архитектурное решение которое ограничивает функциональность. Ты была на встрече, слышала, высказала мнение — но решение не твоё.
Фиксируй письменно. Не чтобы потом сказать “я же говорила”. А чтобы когда через три месяца это аукнется — был контекст почему так получилось и кто был в курсе. Это защищает всех, не только тебя.

Не бери на себя ответственность за чужие решения

Это отдельный пункт потому что он про границы. Аналитик отвечает за качество требований и за то что все стороны правильно поняли друг друга. Аналитик не отвечает за бизнес-решения заказчика и за технические решения разработки.
Граница тонкая, но важная. Когда её нет — выгораешь быстро.

Про эмоциональную сторону — это тоже важно

Позиция между двумя огнями эмоционально затратная. Тебя могут обвинять с обеих сторон, иногда несправедливо. Бизнес говорит что не понимаешь их боль. Разработка говорит что приносишь нереализуемые хотелки.
Я долго принимала это на свой счёт. Потом поняла: большая часть этих претензий — не ко мне лично, а к позиции. Аналитик по определению находится в точке напряжения. Это не баг профессии, это фича.
Именно там где интересы сталкиваются — нужен человек который удерживает общую картину и не теряет голову. Не бизнес, не разработка. Аналитик.

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Зрелость управления данными: предлагаю простую методику оценки

⏳ 23 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Синдром самозванца в профессии аналитика — как я с этим жила

Салют! Расскажу про то, о чём в профессиональных каналах обычно не пишут. Не про инструменты, не про методологии. Про внутреннее состояние которое преследовало меня несколько лет и которое, как выяснилось, знакомо большинству аналитиков.

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

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

может я не на своём месте? Может настоящий аналитик должен всё это знать?

Спойлер: не должен. Но тогда я этого не понимала.

Характерные симптомы которые я у себя замечала:
— Боялась задавать “глупые” вопросы на встречах
— Переписывала письма по десять раз прежде чем отправить
— Когда что-то получалось хорошо - думала что просто повезло
— Когда что-то шло не так - была уверена что это только моя вина
— Сравнивала себя с коллегами и всегда была не в свою пользу

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

Что реально помогло

1️⃣ Разрешила себе не знать всего
Звучит банально. Но мне реально пришлось внутренне договориться с собой: я не обязана знать всё про архитектуру, про DevOps, про финансовую модель заказчика. Я обязана знать своё дело хорошо и уметь задавать правильные вопросы нужным людям.
“Не знаю, давайте разберёмся вместе” — это не слабость. Это профессиональная честность.

2️⃣ Начала вести список того что сделала хорошо
Не для резюме. Для себя. Буквально блокнот где я записывала: вот здесь я нашла противоречие в требованиях до того как оно стало проблемой. Вот здесь помогла разрулить конфликт между командами. Вот здесь заказчик сказал что это лучшая документация которую он видел.
Когда накрывало сомнениями — открывала и перечитывала. Работало.

3️⃣ Поговорила с коллегами
Оказалось что опытные аналитики которым я завидовала — чувствовали то же самое. Просто не говорили об этом вслух. Один разговор по душам с коллегой которая была в профессии семь лет снял с меня какое-то внутреннее напряжение которое я носила месяцами.
Мы все притворяемся что знаем больше чем знаем. Это нормально. Ненормально думать что ты одна такая.

4️⃣ Перестала сравнивать себя с чужими достижениями
Соцсети и профессиональные каналы показывают лучшее. Никто не пишет “сегодня я провалила встречу и не смогла ответить на половину вопросов”. Все пишут про успехи, про крутые проекты, про сертификаты.
Я сравнивала свою внутреннюю кухню с чужим парадным фасадом. Это заведомо проигрышная игра.

Что поняла спустя двенадцать лет

Синдром самозванца не исчезает полностью. Он просто меняет форму. Сейчас я могу провести сложнейшее интервью с производственниками, написать архитектурное описание интеграции, выступить перед советом директоров — и всё равно иногда поймаю себя на мысли “а вдруг я что-то важное упустила”.
Разница в том что раньше эта мысль меня парализовала. Теперь я её замечаю, киваю ей и иду делать своё дело.

❗️Если вы аналитик и узнали себя в этом тексте — вы не одни. И то что вы сомневаетесь в себе скорее всего означает что вы достаточно вдумчивы чтобы видеть собственные пробелы. Это не слабость. Это качество хорошего специалиста.

Если было полезно, ставьте реакции 😉

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Синдром самозванца у опытных — это уже не страх, это кое-что похуже

Салют! Когда говорят про синдром самозванца — обычно рисуют образ новичка который боится открыть рот на встрече. Узнала себя, подросла, прошло.
Но у опытных специалистов синдром самозванца не исчезает — он мутирует. Становится тише, незаметнее и от этого гораздо опаснее. Я поняла это когда поймала себя на нескольких привычках которые казались абсолютно нормальными. Оказалось — не очень.

Проявление 1. Гиперподготовка

Перед важной презентацией переделывала слайды до часа ночи. Не потому что они были плохими — потому что внутри сидел голос: “а вдруг спросят то что не предусмотрела?”
Гиперподготовка маскируется под профессионализм. На самом деле это тревога которая ищет контроль. И она съедает время и энергию которые можно было потратить на что-то реально важное.

Проявление 2. Присваивать успех команде, а провалы — себе

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

Проявление 3. Синдром “ещё одного курса”

“Вот пройду курс по архитектуре — тогда буду достаточно компетентна.” “Получу сертификат — тогда смогу претендовать на повышение.”
Я однажды посчитала: за два года прошла семь курсов. При этом несколько раз отказалась от интересных проектов потому что “ещё не готова”. Курсы были. Готовность не наступала — потому что дело было не в знаниях.

Проявление 4. Преуменьшение своей экспертизы

“Ну, я не эксперт конечно, но…” “Могу ошибаться, но…” “Это просто моё мнение…”
Когда человек с десятью годами опыта начинает каждый второй тезис с подобных оговорок — это уже не вежливость. Я ловила себя на этом постоянно. Внутри всё знала, снаружи звучала неуверенно. И люди считывали именно неуверенность, а не экспертизу.

Проявление 5. Избегание видимости

Не брать сложный проект — “там и без меня справятся”. Не предлагать идею — “наверное это всем очевидно”. Не откликаться на вакансию — “я не дотягиваю до всех требований”.
Это самое дорогостоящее проявление. Цена здесь вполне конкретная: проекты которые не взяла, идеи которые не высказала, карьерные шаги которые не сделала.

❗️Почему это сложнее лечится чем у новичков

У опытного специалиста все эти проявления выглядят как черты характера. Окружающие не видят проблемы — иногда даже хвалят: “такой ответственный человек”, “никогда не хвастается”. А внутри всё тот же голос который говорит что ты недостаточно хороша. Просто научившийся говорить тихо.

✅ Что с этим делать

Первый шаг — увидеть конкретные привычки, а не абстрактный диагноз.

Второй шаг — разделить тревогу и реальность. “Я недостаточно компетентна” — это ощущение. “Я десять лет успешно веду проекты” — это факт. Верить стоит факту.

Третий шаг — действовать не дожидаясь уверенности. Она не приходит до действия. Только после. Это контринтуитивно — но это правда которую я проверила на себе много раз.

Если было полезно, ставьте реакции 😉

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Как не захлебнуться в User Stories и не утопить в них команду

⏳ 11 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Когда документация заканчивается, системный аналитик начинает читать код

⏳ 28 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Аналитик, или Туда и Обратно: как мы стали «Google на минималках» в мире контейнерной оркестрации

⏳ 7 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

Токсичные заказчики — типы которые я встречала и как с ними выживать

Салют! За двенадцать лет я работала с самыми разными людьми. Большинство — нормальные, адекватные. Но были и другие. Те после встреч с которыми хочется закрыть ноутбук и уйти в огород.

Расскажу про типы которые встречались лично — и что реально помогало с каждым.

Тип 1. 🥸 “Я всё знаю лучше”

Приходит не с проблемой а с готовым решением. Любые вопросы воспринимает как некомпетентность. Альтернативы не рассматривает.
Самая большая ловушка — начать спорить. Не работает.

Что помогало: задавать вопросы через его же логику. Не “а вы рассматривали другой вариант?” а “помогите понять — если делаем вот так, что происходит когда пользователь делает вот это?” Пусть сам придёт к противоречию. Люди охотнее меняют мнение когда думают что додумались сами.

Тип 2. 😜“Согласую всё и сразу всё меняю”

На встрече кивает, подписывает протокол. Через три дня: “я подумал и хочу по-другому”.
Дело не в том что плохо объясняешь. Человек просто не умеет принимать решения в моменте.

Что помогало: давать фиксированное время на обдумывание до финального согласования — не просто “посмотрите”, а “посмотрите до пятницы 18:00, после фиксируем”. Без конкретного дедлайна некоторые не возвращаются вообще или возвращаются через месяц с полностью новым видением. Количество разворотов после подписания упало в разы.

Тип 3. ‼️ “Всё срочно и всё важно”

Любая задача с пометкой “срочно”. Письма в 23:00. Звонки в выходные. На вопрос о приоритетах: “всё приоритет”.
Главное что поняла: его срочность — это его тревога, не твоя реальность. Не значит игнорировать. Значит не заражаться паникой.

Что помогало: договорённости на берегу — рабочие часы, канал для действительно срочного, время ответа на обычные запросы. И обязательно зафиксировать письменно — иначе через неделю всё возвращается к режиму пожара как будто разговора не было. Большинство воспринимало с облегчением. Им самим нужна была структура — они просто не умели её создать.

Тип 4. 🤔 “Не знаю чего хочу но это не то”

Требования размытые, на прототип говорит “не то” — но объяснить что именно не может. Это не злой умысел — человек искренне не умеет формулировать.

Что помогало: показывать примеры из других проектов — “вот так бывает, вот так бывает, что ближе?” Итерации маленькими кусками вместо большого документа. И вопрос “покажите что вам нравится в других системах?” — иногда проще указать на чужое чем описать своё.

Тип 5. 🧐“Через мою голову”

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

Решение только одно — проговорить на старте и зафиксировать письменно: все задачи идут через аналитика. Не потому что хочу контролировать, а потому что иначе правая рука не знает что делает левая. Если не зафиксировать в начале — потом не введёшь.

✅ И про главное

За всеми этими типами стоит одна вещь: токсичность почти никогда не личная. За “я всё знаю лучше” — страх потерять контроль. За “всё срочно” — давление сверху. За “не знаю чего хочу” — неумение работать с абстракциями.
Понимание причины помогает выбрать правильный инструмент вместо того чтобы просто злиться. Злиться тоже можно — но после работы и не в рабочем чате 😄

Если было интересно, ставьте реакции, вам не сложно, мне приятно)))

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Токсичная команда — кто бывает токсичнее всего и как с этим жить

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

1️⃣“Разработчик который считает аналитика лишним звеном”

Классика жанра. Человек искренне убеждён что требования — это лишняя бюрократия и он сам прекрасно разберётся что нужно заказчику. Задачи берёт напрямую, документацию игнорирует, на встречи по требованиям приходит с видом “зачем я здесь”.

Самое неприятное — иногда он технически сильный специалист. И это делает его позицию в команде устойчивой.

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

2️⃣ “Коллега-аналитик который тянет одеяло”

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

Что помогало: фиксировать своё авторство письменно и своевременно. Отправила предложение — в письме, с датой. Провела анализ — задокументировала с именем. Не из паранойи, а как рабочая гигиена. И никогда не выяснять отношения публично — только один на один и спокойно.

3️⃣ “Саботажник”

Внешне лояльный, на встречах молчит или соглашается. А потом тихо делает всё чтобы изменения не прижились. Затягивает согласования, находит бесконечные причины почему “сейчас не время”, распускает слухи что проект бесполезный.

Это самый сложный тип — потому что его токсичность невидима. Формально не к чему придраться.

Что помогало: выяснить причину. Саботаж почти всегда про страх — потерять влияние, привычный процесс, статус. Один честный разговор тет-а-тет иногда решал больше чем месяц борьбы. Не всегда — но попробовать стоило всегда.

4️⃣ “Вечно негативный”

Любая идея встречает “это не сработает”. Любое решение — “мы уже пробовали, бесполезно”. Любое изменение — “опять за своё”.
Сам ничего не предлагает. Но чужие инициативы топит с завидной регулярностью.

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

Что помогало: не спорить на общих встречах. Задавать вопрос: “Хорошо, это не сработает — а что по-вашему сработает?” Переводить энергию скептицизма в конструктив. Иногда получалось — оказывалось что за вечным негативом прячется человек с реальным опытом и болью от прошлых неудачных проектов.

5️⃣ “Звезда”

Технически сильный, это знает и регулярно напоминает окружающим. Чужое мнение не интересно, на ревью документов снисходит — с видом одолжения. Если что-то идёт не так — виноваты все кроме него.

С такими людьми сложно потому что они часто правы технически. Это даёт им уверенность что можно не считаться с остальными.

Что помогало: апеллировать к их же логике. Не “ваш подход неправильный” а “помогите понять — вот этот сценарий ваш вариант покрывает?” Звёзды любят демонстрировать экспертизу — используйте это. Пусть объясняют. В процессе объяснения часто сами находили слабые места.

Кто токсичнее всего — если честно

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

А с какими токсиками работали вы? Или может кто-то ту сам токсик?

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Как повысить зарплату — когда просить и как аргументировать

Салют! Сегодня у нас тема, которую все хотят обсудить, но почему-то стесняются. Давайте без стеснения — потому что умение говорить о деньгах это такой же профессиональный навык как умение писать требования.

Я несколько раз просила повышения за карьеру. Один раз получила отказ. Остальные — да. Расскажу что работало и что нет.

‼️ Сначала про главную ошибку

Большинство аналитиков приходят на разговор о зарплате с одним аргументом: “я давно здесь работаю” или “я хорошо работаю”. Это не аргументы. Это фон.
Руководитель знает что вы давно работаете — он сам вас нанимал. И то что вы хорошо работаете — это ожидание, а не достижение.
Разговор о повышении это не разговор о том какой вы хороший человек. Это переговоры. И к ним нужно готовиться.

⏰ Когда просить — это важнее чем кажется

Есть моменты когда просить бессмысленно даже если вы объективно заслуживаете:
— Компания только что объявила об оптимизации расходов
— Проект провалился и все ещё разбирают последствия
— Руководитель сам под давлением и решает свои проблемы
— Конец квартала когда бюджеты уже распределены

И есть моменты когда шансы выше:
— Вы только что закрыли сложный проект с хорошим результатом
— Компания растёт и набирает людей — значит деньги есть
— Вам предложили интересную задачу которую явно хотят чтобы вы взяли
— Начало бюджетного цикла — когда руководитель ещё может заложить цифры

Момент имеет значение. Один и тот же разговор в разное время даёт разный результат.

✅ Как готовиться — конкретно
Соберите доказательную базу

Не ощущения - факты. Что конкретно вы сделали за последние полгода-год?
— Какие проекты закрыли и с каким результатом
— Где нашли проблему до того как она стала дорогой
— Где взяли на себя больше чем было в вашей зоне ответственности
— Что улучшили в процессах команды
Если вы никогда не вели такой список - начните прямо сейчас. Не для руководителя, для себя. Память избирательна, документы - нет.

📈 Изучите рынок

Это обязательный шаг который многие пропускают. Посмотрите hh.ru, Habr Career, телеграм-каналы с вакансиями — сколько платят аналитикам вашего уровня в вашем городе и формате работы.
Если рынок платит больше чем вы получаете — это аргумент. Спокойный, без угроз, но аргумент.

🔢 Сформулируйте конкретную цифру

Не “хотелось бы побольше”. Конкретная сумма или процент. Человек без конкретики воспринимается как неуверенный. Конкретика показывает что вы серьёзно подошли к вопросу.

Как строить разговор
Попросите отдельную встречу - не в конце случайного созвона и не в коридоре. Отдельное время показывает что тема важная.

Структура, которая работала у меня:
- Сначала контекст. Коротко - что вы сделали, какую ценность принесли. Не хвастовство, а напоминание фактов. Две-три минуты максимум.
- Потом запрос. Прямо и спокойно. “Я хочу обсудить пересмотр зарплаты. Я считаю справедливым уровень Х - вот почему.”
- Потом молчите. Это самое сложное. После того как назвали цифру — не заполняйте тишину. Дайте человеку ответить.

Что делать если говорят “не сейчас”
Не уходить с пустыми руками. Задайте два вопроса:
“Что должно произойти чтобы мы вернулись к этому разговору?”
“Когда мы можем к нему вернуться?”
Зафиксируйте ответы письменно - отправьте короткое письмо после встречи. “Договорились вернуться к вопросу в марте после закрытия проекта Х.” Это не давление - это уважение к договорённостям.
Если через обозначенный срок ничего не изменилось - возвращайтесь с этим письмом. Спокойно, без обид.

🧐 Про офферы со стороны

Реальный оффер от другой компании - самый сильный аргумент на переговорах о зарплате. Это рыночная оценка вас прямо сейчас.
Но здесь важна честность с собой: вы готовы уйти если не повысят? Если нет - не используйте оффер как шантаж. Блеф в переговорах о зарплате раскрывается - и доверие потом восстановить сложно.
Если готовы уйти - говорите прямо и спокойно. Не ультиматум, а факт: “Я получила предложение, оно интересное. Но я хочу остаться - давайте обсудим возможности.”

Если было полезно - ставьте реакции)

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Стоит ли писать ТЗ на разработку в 2026 году и зачем

«Мы не пишем ТЗ, — гордо сказал мне руководитель агентства. — Мы работаем только по Agile». Хочется порассуждать на тему того, нужно ли в 2026 году писать техническое задание на разработку информационного продукта и в каком виде. Или это все замшелые водопадные технологии, которые уже давно прогрессивным разработчикам и вайбкодерам никуда не уперлись.

⏳ 7 мин | 🟤⚪️⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA

ТЗ в 2026 году — писать или не писать?

Салют! Теперь я хочу поделиться своим мнением на счет ТЗ на разработку в наших реалиях.

Знаете что меня до сих пор удивляет? Каждый год кто-нибудь обязательно скажет что ТЗ умерло. Agile победил, итерации рулят, зачем писать документ который устареет через месяц.
А потом тот же человек приходит с горящими глазами: “мы сделали не то, заказчик недоволен, кто виноват непонятно”. И знаете что выясняется? Нигде ничего не зафиксировано.

🥺 Я через это прошла. И не один раз.

Почему ТЗ ругают — и в этом есть доля правды

Классическое ТЗ по ГОСТ — это больно. Двести страниц которые пишутся месяцами, согласовываются вечность и устаревают к моменту подписания. Я видела такие документы. Толстые, красивые, абсолютно мёртвые — потому что никто их не читал. Включая тех кто писал.
Но проблема не в самой идее фиксировать требования. Проблема в том что ТЗ превратили в ритуал вместо инструмента.

Где без фиксации становится по-настоящему больно

Расскажу один кейс. Проект без нормальной документации — команда договорилась устно, доверяли друг другу, торопились. Через три месяца разработки заказчик увидел результат и сказал “это не то что я имел в виду”. Разработчики показали переписку — там действительно было сказано именно так. Заказчик был уверен что имел в виду иначе.
Кто прав? Оба. И никто. Потому что нигде не было написано однозначно.
Переделки, потраченные деньги, испорченные отношения. Agile тут ни при чём — просто люди не зафиксировали договорённости.

Что писать в 2026 году — конкретно

Не ГОСТ. Но и не “разберёмся по ходу”.

Хорошая документация сегодня выглядит иначе:

- Короче. Ровно столько сколько нужно для однозначного понимания. Иногда десять страниц, иногда три. Объём не равно качество.
- Живее. Документ который обновляется по ходу проекта в Confluence или Notion лучше замороженного артефакта после подписания.
- Конкретнее. Не “система должна быть удобной” а “пользователь создаёт заявку за три шага”. Не “быстрая загрузка” а “страница открывается не дольше двух секунд”.
- С акцентом на главное. Бизнес-цель, ключевые сценарии, критерии готовности, ограничения. Остальное по необходимости.

Когда без серьёзного документа нельзя

Есть ситуации где я бы не взялась за проект без нормального ТЗ:

- Госпроекты и тендеры - там это требование закона
- Фиксированный бюджет и фиксированный скоуп - нет документа, нет защиты ни для кого
- Интеграции с внешними системами - без чёткой спецификации две команды сделают два разных API и удивятся почему не стыкуется
- Высокая цена ошибки - производство, медицина, финансы
Здесь ТЗ не бюрократия. Это единственный способ не потерять деньги и репутацию.

Когда можно обойтись малым

- Внутренний продукт с гибким скоупом и заказчиком который всегда на связи
- Небольшая доработка существующей системы
- Стартап где всё меняется быстро и документ устареет раньше чем его дочитают

Но даже здесь - ключевые договорённости фиксирую всегда. Хотя бы коротким письмом после встречи. Это занимает десять минут и сколько раз спасало - не пересчитать.

Мой честный ответ после двенадцати лет

ТЗ в классическом виде — да, уходит. Но потребность которую оно закрывает никуда не делась.
Людям нужна общая картина. Нужно понимать что строят, зачем, для кого и как поймут что сделали правильно. Нужна точка к которой можно вернуться когда начнутся споры — а они начнутся всегда.

Называйте как хотите — ТЗ, спецификация, product brief, просто нормальный документ. Суть одна: договорённости должны существовать не только в головах участников.
Потому что головы у всех разные. И каждая искренне уверена что всё помнит правильно.

Как у вас на проектах — пишете или обходитесь?
Если пишите, ставьте - 👌
Если обходитесь, ставьте - 🙈

Если нравится тема и пост, ставьте любую из реакций - 🔥♥️👍

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Как выстроить репутацию внутри компании — и почему это не про то, чтобы всем нравиться

Салют! Помню, как на третьем году работы мне сказали, что у меня “хорошая репутация в команде”. Я тогда искренне не понимала, что именно я делаю правильно. Просто работала.
Потом наблюдала, как коллеги с похожим опытом и знаниями получали разные результаты. Одних звали на интересные проекты, другие годами сидели на одном месте и недоумевали почему. Стала думать — в чём разница.
Вот что поняла.

🧐Репутация строится не на том, что вы знаете, а на том, как вы себя ведёте

Никто внутри компании не оценивает вас по знанию методологий. Оценивают по простым вещам — сказала, что сделает к среде, сделала к среде. Написала, что разберётся и напишет — разобралась и написала. Не знает ответа — говорит честно, вместо того чтобы тянуть время.

Предсказуемость — это валюта доверия. Накапливается медленно, тратится быстро.

Я это поняла, когда один раз подвела коллегу — не сильно, просто забыла передать важную информацию вовремя. Казалось бы, мелочь. Но именно это он вспомнил через полгода, когда меня рекомендовали на проект. Не со злым умыслом — просто так работает память на негативное.

✅Хорошая работа сама себя не продаёт

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

Аналитика — невидимая профессия. Конфликт, который вы предотвратили — никто не видел. Противоречие в требованиях, которое нашли до разработки — никто не оценил. Встреча, которая прошла гладко, потому что вы её хорошо подготовили — воспринимается как само собой разумеющееся.

Руководство видит проблемы — они громкие. Хорошую работу не видит — она тихая.

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

❌Кризис — лучший момент для репутации

Парадокс, который я поняла на собственном опыте: люди запоминают не то, как вы работаете, когда всё хорошо. Запоминают то, как вы ведёте себя, когда плохо.

У меня был проект, где мы просели по срокам. Частично моя недоработка — не докопалась до одного требования, которое потом вылезло и всё усложнило. Я пришла к руководителю сама, раньше чем он узнал из другого источника. С разбором того, что случилось, и с планом, как выправляем.

Было страшно. Но именно после того разговора отношение изменилось в лучшую сторону — не потому что всё было хорошо, а потому что я не спряталась.

Прятаться, когда плохо — худшее, что можно сделать для репутации. Все это замечают.

🤓Разработчики — недооценённый источник репутации

Мало кто думает об этом целенаправленно. А зря.

То, что разработчики говорят о вас между собой, расходится по компании быстрее любого официального фидбека. “С ней приятно работать — требования понятные, отвечает быстро, не пропадает, когда вопросы” — такая рекомендация стоит дорого.

Я однажды спросила разработчика напрямую: что в моих документах мешает работать? Он опешил — видимо, никто раньше не спрашивал. Потом рассказал несколько вещей, которые я поменяла и которые реально ускорили нашу совместную работу. И стал одним из тех, кто меня рекомендовал на следующий проект.

📈 Горизонтальные связи работают дольше, чем вертикальные

Руководители меняются. Компании реструктурируются. А люди, с которыми вы работали — уходят на другие проекты, в другие компании и берут с собой воспоминание о вас.

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

Это не расчёт. Просто так устроены отношения — люди помнят тех, кто им помог, когда было сложно.

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

Если было полезно, ставьте реакции

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

SQL на собеседованиях спрашивают все. Но зачем он аналитику на самом деле?

Салют! Когда я только пришла в профессию, SQL казался мне чем-то из мира разработчиков. Ну запросы и запросы, это же не моё. Я аналитик, я работаю с требованиями и людьми.

Потом был проект, где нужно было понять почему в отчёте расходятся цифры. Разработчик занят, дедлайн завтра, заказчик ждёт. Я открыла базу, написала запрос — и нашла проблему за двадцать минут сама.

После этого моё отношение к SQL изменилось навсегда.

🧐 Почему его спрашивают на каждом собеседовании

Не потому что аналитик будет писать сложные запросы каждый день. А потому что человек, который понимает SQL, понимает как устроены данные — связи между таблицами, почему один показатель может считаться по-разному в зависимости от того как написан запрос.

Это не про синтаксис. Это про понимание системы изнутри.

‼️ Где SQL реально нужен в работе (исходя из личного опыта)

1️⃣ Когда цифры не сходятся. Заказчик говорит пять тысяч пользователей, разработчик говорит три тысячи. Без SQL будете ждать пока кто-то найдёт время разобраться. С SQL — проверите сами за десять минут.

2️⃣ Когда хочешь понять как устроена система. Схема базы данных показывает всё — какие сущности есть, как они связаны, что главное а что вспомогательное. Я до сих пор начинаю знакомство с новой системой именно с этого.

3️⃣ Когда пишешь требования к данным. Понимая как хранятся данные, формулируешь точнее. Не "показывать историю заказов", а "выбирать заказы по userId, отсортированные по дате, исключая удалённые". Разработчику не нужно додумывать.

4️⃣ Когда принимаешь задачу. Разработчик говорит "всё сделано". Пишешь запрос и смотришь реальные данные — не через интерфейс который может скрывать проблемы, а напрямую.

✅ Какой уровень нужен аналитику (в основном мне хватало, но сложные задачи никто не отменял)

SELECT, WHERE, JOIN, GROUP BY, простые агрегаты — этот набор закрывает 80% задач. Остальное по ситуации.

Пример:

SELECT u.name, COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o 
    ON u.id = o.user_id
    AND o.status = 'active'
GROUP BY u.id, u.name
ORDER BY order_count DESC

Писать хранимые процедуры и оптимизировать запросы не нужно — это работа разработчика.

❓ Почему некоторые говорят что SQL им не нужен

Либо они работают там где уже есть готовые дашборды — Power BI, Tableau, Metabase — и данные подготовлены заранее. Такое бывает.

Либо просто привыкли по любому вопросу про данные идти к разработчику. И не замечают насколько от него зависят.
Это не "SQL не нужен". Это "не пробовала разобраться сама".

SQL делает аналитика самостоятельным. Не ждёшь пока кто-то найдёт время ответить — идёшь и смотришь сама. В нашей профессии это и есть ценность.

Если было полезно, ставьте реакции

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Салют! Что-то я немного выпала из телеграмной жизни, каюсь 😱 и возвращаюсь))

Сегодня погрузимся в тему sql и я для вас собрала небольшую подборку на тему БД:

- SQL для аналитика

- SQL для начинающих: 10 запросов, которые нужно знать каждому аналитику

- SQL в 2026 для аналитика (с чего начать, где учиться и что реально нужно знать)

- Как изучить SQL за ночь или шпаргалка для системного аналитика

- Проектирование БД и почему важен SQL для системного аналитика: гайд по улучшению качества требований

- Вопросы по SQL для подготовки к собеседованию

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

Нотация C4: полный гайд по моделированию архитектуры с примерами, разбором ошибок и промптом для ИИ

⏳27 мин | 🟤🟤⚪️

Перейти | @ba_and_sa

💙 BA|SA | 💬 BA|SA