Business | System analyst

Как проходит техническое собеседование в IT ⏳ 6 мин | 🟤⚪️⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA

Разработчик больше не обязан выполнять каждую задачу вручную. Но сможет ли ИИ-агент действительно помочь в работе? ИИ-агенты уже умеют анализировать код, работать с инструментами, искать ошибки и выполнять последовательность действий. Но важно понимать, какие задачи им можно доверить, где они действительно экономят время и как сохранить контроль над результатом. На открытом уроке 19 октября в 20:00 МСК в преддверие старта курса «Разработка ИИ-агентов» разберем, как создавать и применять агентов в реальной разработке. Вы узнаете, какие задачи можно делегировать ИИ-агентам, как они работают с кодовой базой и внешними системами, где помогают ускорить процессы, а где требуется участие разработчика. Урок будет полезен разработчикам, техническим специалистам и тимлидам, которые хотят использовать возможности ИИ не только для генерации кода. Откройте новый подход к разработке. Регистрируйтесь на открытый урок: https://clck.ru/3WTtyo Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Микросервисы — это не просто набор отдельных сервисов. Важно понимать, где живёт бизнес-логика и как не превратить архитектуру в сложную систему зависимостей. 🔥22 октября в 19:00 МСК на открытом уроке разберём основы проектирования бизнес-логики в микросервисной архитектуре: как декомпозировать логику по сервисам, какие паттерны использовать и как избежать хаоса при росте приложения. Поговорим о Shared Kernel, API Composition и Saga, разберём, где должна находиться логика в сервисе, API-шлюзе или общем слое, а также рассмотрим ошибки при проектировании и кейсы декомпозиции сложной бизнес-логики. Урок проходит в преддверии старта курса «Микросервисная архитектура» и будет полезен backend- и fullstack-разработчикам, архитекторам ПО и системным аналитикам. ⏰Зарегистрируйтесь и разберите основы проектирования бизнес-логики в микросервисной архитектуре: https://clck.ru/3WTtpB Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Вклад системного аналитика оценивают не по качеству постановки задач разработчикам. А как тогда? ⏳ 10 мин | 🟤🟤⚪️ Перейти |

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

Салют! Расскажите как у вас дела с поиском работы и с прохождением собесов? Рынок сейчас странный — одни говорят, что вакансий нет, другие вышли за месяц. Хочу понять как дела у вас и понять интересна ли данная тема)) Где вы сейчас находитесь? Ставьте реакции, если: 🙈 - Отправляю резюме — тишина Отклики уходят в пустоту, даже автоответа нет 🥲 - Резюме не проходит — до собеса не доходит HR смотрит и не зовёт, или отказ без объяснений 🤔 - Дохожу до собеса, но заваливаю техническое Со звонком/HR всё ок, а дальше не идёт. Провал либо на техническом, либо на финальном. 👍 - Прошёл(а) без больших проблем Процесс был адекватным, вышел(а) / оффер получил(а) 👌 - Пока не ищу Работа есть, в поиск не выходил(а) Если есть чем поделиться, то го в комментарии 👇))

Прошло две недели на новом проекте. И что теперь? Салют! В прошлый раз разобрали как войти в проект - первые дни, первые разговоры, первые договорённости. Сегодня про то что происходит дальше. Потому что после двух недель эйфория от нового места проходит - и начинается настоящая работа. Примерно на третьей неделе наступает "провал" Это нормально - но мало кто об этом предупреждает. В первые две недели всё понятно: знакомишься, изучаешь, задаёшь вопросы. Все помогают и объясняют. Потом негласно ожидается что ты уже "вошла" и должна работать самостоятельно. А вопросов стало только больше - и задавать их уже неловко. Не переставайте задавать вопросы. Просто меняйте формулировку. Не "объясните как это работает", а "я понимаю это вот так - правильно?" Разница небольшая, воспринимается совсем иначе. Подводные камни которые вылезают после двух недель 1️⃣ Неформальные лидеры В любой команде есть люди которые формально не принимают решения - но фактически влияют на всё. Первые два месяца уходят на то, чтобы понять реальную карту влияния. Это не политика ради политики - это понимание как реально работает система вокруг вас. 2️⃣ Накопленный долг. Начинают всплывать вещи которые "так исторически сложилось". Не бросайтесь это чинить сразу — сначала поймите почему оно такое. За кривым процессом иногда стоит причина которая не очевидна снаружи. 3️⃣ "У нас так не принято". Спросите почему. Если конкретная причина — принимаем к сведению. Если "ну, просто так сложилось" — это не ограничение, это привычка. С привычками можно работать — но аккуратно и не с наскока. Как понять что ты на своём месте Обычно это чувствуется к концу третьего-четвёртого месяца. ➕ Хорошие признаки: к вам приходят с вопросами сами, на встречах вы уже не просто слушаете, начинаете видеть проблемы чуть раньше чем они становятся кризисом. ➖Тревожные признаки: через три месяца не понимаете кто реально принимает решения, чувствуете что вас терпят но не слышат, каждый день ощущение что делаете что-то не то. Второй список — не приговор. Но сигнал что нужно поговорить с руководителем напрямую. Лучше неловкий разговор сейчас, чем полгода в тумане. Про новых людей — и почему их не нужно бояться Страх новых людей — это почти всегда страх оценки. Кажется что все вокруг давно знают как тут всё устроено и только ты не в курсе. Большинство людей на проекте тоже не уверены что всё понимают правильно. Просто не показывают. Что помогает: запомните что важно каждому человеку — люди чувствуют когда их слышат и открываются. Найдите одного союзника который готов объяснить неформальные правила игры. Не пытайтесь понравиться всем сразу — это невозможно и выглядит неестественно. Как понять проект по-настоящему Настоящее понимание приходит когда вы первый раз сами нашли противоречие которое никто не замечал, провели сложную встречу где мнения расходились и вышли с результатом, разобрались почему что-то пошло не так — без помощи. Это не случается за две недели. Но именно это делает вас частью проекта, а не гостем на нём. Дискомфорт первых месяцев — это не сигнал, что вы не на своём месте. Это сигнал что вы растёте. Если было полезно, ставьте реакции 👇 Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

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

Первые две недели на новом проекте — что делать чтобы не облажаться Салют! Помню своё первое погружение в большой незнакомый проект. Меня посадили, дали доступы к куче систем, скинули ссылку на Confluence где было триста страниц документации и сказали "изучай". Я изучала. Честно. Три дня читала документы и к концу понимала примерно столько же сколько в начале — потому что читала не то и не в том порядке. С тех пор у меня есть своя система первых двух недель. Делюсь. День 1-2. Сначала люди, потом документы Главная ошибка новичков — и моя в том числе — начинать с документации. Документы врут. Не специально — просто устаревают, не обновляются, описывают как должно быть а не как есть. Первое что делаю на новом проекте — прошу пятнадцать минут с каждым ключевым человеком. Не полноценное интервью, просто познакомиться и задать три вопроса:

— Чем занимаетесь на проекте?
— Что сейчас самое болезненное?
— Без чего проект точно не взлетит?

За два дня таких разговоров получаю картину которую из документов не вытащить за неделю. И сразу понимаю кто реально влияет на решения, а кто формально в списке стейкхолдеров. День 3-5. Разобраться в предметной области — но не глубоко Не пытаюсь стать экспертом за неделю. Цель другая — понять достаточно чтобы задавать осмысленные вопросы и не выглядеть человеком с другой планеты на встречах. Что помогает: — Попросить кого-то из команды объяснить процесс "как будто я первый раз это слышу". Люди любят объяснять — и в процессе сами замечают что некоторые вещи объяснить сложно — Найти самый главный объект системы — заказ, пациент, договор, заявка — и понять его жизненный цикл. Вокруг него обычно строится всё остальное — Посмотреть на схему базы данных если есть доступ. Там видно реальную архитектуру, а не ту которую нарисовали в презентации День 5-7. Найти где болит прямо сейчас На каждом проекте есть что-то что горит, раздражает или давно висит нерешённым. Найти это — значит быстро стать полезной. Не жду пока мне скажут. Спрашиваю напрямую: "Что сейчас мешает команде работать быстрее?" или "Есть что-то что давно хотели разобрать но руки не доходили?" Иногда это маленькая задача которую можно закрыть за день. Но закрытая маленькая задача в первую неделю — это огромный кредит доверия на старте. День 7-10. Картина целиком К этому моменту уже есть кусочки пазла от разных людей. Время собрать их вместе. Рисую для себя — не для документации, просто для понимания: — Кто главные участники процесса и как они связаны — Как выглядит основной сценарий от начала до конца — Где стыки между системами или командами — там обычно и прячутся проблемы Этот набросок показываю кому-то из команды и прошу покритиковать. "Я правильно понимаю как это работает?" — один из самых продуктивных вопросов в первые две недели. День 10-14. Договориться как будем работать К концу второй недели уже понятно с кем предстоит работать плотнее всего. Самое время договориться о правилах — не потому что я люблю бюрократию, а потому что потом договариваться сложнее. Как фиксируем требования. Кто финальный ЛПР по спорным вопросам. Как обрабатываем изменения. Где живёт документация. Пять минут такого разговора в начале экономят часы разборок потом. Чего точно не стоит делать в первые две недели — Предлагать "а вот у нас на прошлом проекте было лучше". Даже если правда. Особенно если правда — Брать на себя задачи раньше чем понял контекст — переделывать дороже чем сделать позже но правильно — Молчать когда что-то непонятно. Вопросы в первые две недели воспринимаются как норма. Через месяц — уже нет Первые две недели задают тон всему проекту. Не потому что за это время нужно всё узнать и всё сделать. А потому что именно тогда формируется первое впечатление — и репутация которую потом долго менять. Если было полезно, ставьте реакции Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

Хочу понять, кто застал эпоху перехода на ИИ в работе ИТ

Системный анализ тогда и сейчас — профессия изменилась, но не так как все думают Когда я начинала работать аналитиком, основным инструментом был Word, согласование шло по почте, а UML-диаграммы рисовались в Visio и распечатывались на встречи. Серьёзно — распечатывались, потому что показать экран было не так просто. Сейчас Miro, Confluence, Figma, Notion, и ИИ который за минуту генерирует структуру документа. Всё изменилось — и при этом самое главное осталось ровно таким же. Что изменилось реально 🏎️ Скорость. Раньше на подготовку документа уходили дни. Сейчас черновик можно собрать за час — ИИ помогает со структурой, шаблонами, формулировками. Это не хорошо и не плохо — это просто новая реальность. Но она повысила ожидания: если раньше "неделя на ТЗ" было нормой, сейчас заказчик удивляется почему так долго. 👩‍💻 Инструменты совместной работы. Event Storming в Miro с командой из трёх городов — это обычная история. Пять лет назад это было экзотикой. Удалёнка изменила не только где мы работаем, но и как договариваемся и фиксируем решения. ✅ Доступность информации. Раньше чтобы разобраться в незнакомой предметной области нужно было найти эксперта или перечитать гору документов. Сейчас можно за вечер получить базовое понимание любой отрасли. Порог входа в новую предметную область сильно снизился. 🤔 Размытие ролей. Граница между аналитиком, продактом и проектным менеджером стала тоньше. Всё чаще аналитик занимается и приоритизацией бэклога, и работой с метриками, и фасилитацией стратегических сессий. Это расширяет возможности — и добавляет неопределённости. Что не изменилось — и это важно понимать 👥 Люди не изменились. Заказчики всё так же не могут сформулировать что хотят. Разработчики всё так же хотят чёткие требования. Конфликты интересов всё так же нужно разруливать вручную. ИИ не научился вытаскивать из технолога знания которые он сам не осознаёт. Не умеет почувствовать что заказчик говорит одно а имеет в виду другое. Не может выстроить доверие с командой которая сопротивляется изменениям. Всё что связано с людьми — осталось нашим. И судя по тому что я вижу — останется ещё долго. Что изменилось во мне как в аналитике Раньше я тратила много времени на оформление. Красивые таблицы, выверенные формулировки, идеальная структура документа. Сейчас это делает ИИ быстрее и не хуже. Освободившееся время ушло туда где ИИ не помогает: глубже разбираться в предметной области, больше времени на живое общение с заказчиком, думать о последствиях решений а не только об их оформлении. Не знаю хорошо это или плохо — но точно интереснее. Про страх который был и прошёл Помню как несколько лет назад в профессиональных чатах активно обсуждали: "нас заменят". ИИ напишет требования, сгенерирует документацию, проведёт анализ. Частично это случилось — рутинная часть работы действительно автоматизировалась. Но профессия не исчезла. Она стала другой. Аналитик который умеет работать с ИИ как с инструментом — стал продуктивнее. Аналитик который умеет только это — стал уязвимее. Потому что инструменты меняются каждый год, а умение думать и работать с людьми — нет. Двенадцать лет назад я не могла представить, что буду обсуждать требования в онлайн-доске с командой из разных городов и проверять черновики с помощью ИИ. Через двенадцать лет профессия снова будет другой — и это скорее интересно чем страшно. Как вы ощущаете изменения в профессии — что стало лучше, что потерялось? Пишите в комментариях 👇 Если было полезно, ставьте реакции Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

📊От основ и внедрения ИИ в аналитическую работу до защиты реального проекта за 136 часов обучения на курсе «Бизнес-аналитик в ИТ». 🎁 Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам! 1⃣28 сентября, 20:00 мск — «Инструменты ИИ в работе бизнес-аналитика»: разберём, какие ИИ-инструменты применяют в сборе требований и анализе данных, покажем примеры промптов и границы между пользой и риском. 2⃣15 октября, 20:00 мск — «Цели и метрики как одно целое»: разберём связь целей и метрик, инструменты для их согласования и почему ошибки в целях обесценивают даже точные метрики. 3⃣22 октября, 20:00 мск — «Управление изменениями требований»: обсудим, как выстроить процесс управления требованиями, чтобы изменения не разваливали скоуп проекта, и как держать реестр требований в порядке. Записывайтесь ➡ https://clck.ru/3W67dz Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

«Подождём модель поумнее» — не самая грамотная стратегия работы с ИИ, и вот почему Салют! Досмотрела выпуск подкаста «Доверительный интервал» про ИИ в аналитике — там прозвучала мысль, которую я бы распечатала и повесила над монитором каждому, кто мыслит так: «вот выйдет суперумная модель — тогда и начну юзать ИИ». По факту работать со слабыми моделями полезно: на них оттачивается главный навык — чётко объяснять контекст. Если этого навыка нет, умная модель не спасёт. Слабая на плохом контексте просто ошибётся — и ты это заметишь. Умная ошибётся красиво и уверенно — так, что ты ей поверишь.  🧐Поэтому контекст — это не «написать промпт подлиннее» Важно не просто формулировать задачу, а формализировать сам контекст. Это тоже затронули в подкасте — и вот как это выглядит на практике в Яндексе:  1️⃣ База знаний аналитики. Описанные данные, метаданные, методологии расчёта метрик, уже построенные дашборды. Первые ~70% базы наполнила команда внедрения, дальше аналитики сами докидывают свои скиллы и контекст. То есть это живой репозиторий, а не вики, которую один раз написали и забыли. 2️⃣ Golden Set и канонические SQL-запросы. Эталонные запросы и каталог метрик, на которые агент опирается, а не выдумывает с нуля. По сути — ответ на главную боль: «модель написала SQL, который выглядит рабочим, но считает метрику не по нашей методологии». 3️⃣ «Спека» как продукт. В подкасте это сформулировано так: «продукт не финальный, а спека» — то есть результатом работы становится единый документ, описывающий, что нужно от агента. Не дашборд сам по себе, а спецификация, по которой агент его соберёт — сегодня, завтра и после того, как ты ушла в отпуск. 4️⃣ Инфраструктура подключения. Единый интерфейс, который через MCP цепляется к внутреннему репозиторию, трекеру и вики — и новому сотруднику команда «learn» просто устанавливает весь набор скиллов разом. Онбординг аналитика в контекст команды стал скриптом, а не тремя месяцами расспросов коллег. ❗️ Что из этого следует лично для нас Умение работать с агентом — это скилл выписать из своей головы то, что ты держал там годами: какие данные брать, по какой методологии считать, где лежит описанная таблица, а где — бизнес-договорённость, о которой знают два человека в команде. Знакомо? Это ровно то же самое, что ставить задачу джуну или подрядчику. С людьми мы понимаем: «ну он же не телепат, ему надо объяснить». А от модели многие почему-то ждут подобной магии. А вы уже описываете контекст для инструментов — или всё ещё держите его в голове?

Самый ценный специалист в ИТ и бизнесе Если разработчик пишет код, а тимлид управляет задачами, то кто решает, как вообще должна быть устроена компания и её ИТ-инфраструктура, чтобы бизнес достигал своих целей? Корпоративный архитектор. Он создаёт единый механизм, в котором ИТ, стратегия, процессы и данные не противоречат друг другу и приносят компании реальную прибыль. Отсюда — прямой выход на собственника и доход от 500 000 ₽ в месяц. Вырастите из технаря в стратега за 4 месяца на курсе «Корпоративный архитектор» от Академии Эдюсон. Это комплексная программа для смены роли — с упором на практику, работу с метриками и новыми инструментами. После курса вы сможете реально влиять на бизнес: • Спроектировать единую ИТ-архитектуру по международным стандартам (включая TOGAF и ArchiMate). • Интегрировать нейросети в процессы и автоматизировать работу компании. • Защищать ИТ-решения перед топами на языке денег — с упором на метрики, финансы, оргдизайн и стратегию. Также получите шаблоны и инструкции для решения задач + удостоверение о повышении квалификации в финале. Оставьте заявку с промокодом АРХИТЕКТОР — заберите курс с персональной скидкой. Реклама. ООО «ЭДЮСОН» ИНН 7729779476. erid: 2W5zFGNbRMT

Нотация C4: полный гайд по моделированию архитектуры с примерами, разбором ошибок и промптом для ИИ ⏳27 мин | 🟤🟤⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA

Салют! Что-то я немного выпала из телеграмной жизни, каюсь 😱 и возвращаюсь)) Сегодня погрузимся втему sql и я для вас собрала небольшую подборку на тему БД: - SQL для аналитика - SQL для начинающих: 10 запросов, которые нужно знать каждому аналитику - SQL в 2026 для аналитика (с чего начать, где учиться и что реально нужно знать) - Как изучить SQL за ночь или шпаргалка для системного аналитика - Проектирование БД и почему важен SQL для системного аналитика: гайд по улучшению качества требований - Вопросы по SQL для подготовки к собеседованию Источник: @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
WHERE o.status = 'active'
GROUP BY u.name
ORDER BY order_count DESC

Писать хранимые процедуры и оптимизировать запросы не нужно — это работа разработчика. ❓ Почему некоторые говорят что SQL им не нужен Либо они работают там где уже есть готовые дашборды — Power BI, Tableau, Metabase — и данные подготовлены заранее. Такое бывает. Либо просто привыкли по любому вопросу про данные идти к разработчику. И не замечают насколько от него зависят. Это не "SQL не нужен". Это "не пробовала разобраться сама". SQL делает аналитика самостоятельным. Не ждёшь пока кто-то найдёт время ответить — идёшь и смотришь сама. В нашей профессии это и есть ценность. Если было полезно, ставьте реакции Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

Пока вы собираете требования в одиночку, кто-то уже руководит целой аналитической командой... Узнайте, как управлять командой системных аналитиков эффективно за 5 месяцев обучения вместе с OTUS на курсе «Системный аналитик. Управление командой» 🎁 Записывайтесь на 2 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам! 1️⃣ 8 сентября, 20:00 мск — «Системный аналитик и его ценность глазами компании»: разберём, как грамотная работа аналитика повышает эффективность команды и продукта, и почему бизнес готов платить за эту ценность. 2️⃣ 23 сентября, 20:00 мск — «Как проводить архитектурное ревью и находить риски до начала разработки»: научимся находить узкие места и точки отказа до старта разработки, чтобы архитектура не рассыпалась при запуске продукта. Записывайтесь ➡️ OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Как выстроить репутацию внутри компании — и почему это не про то, чтобы всем нравиться Салют! Помню, как на третьем году работы мне сказали, что у меня “хорошая репутация в команде”. Я тогда искренне не понимала, что именно я делаю правильно. Просто работала. Потом наблюдала, как коллеги с похожим опытом и знаниями получали разные результаты. Одних звали на интересные проекты, другие годами сидели на одном месте и недоумевали почему. Стала думать — в чём разница. Вот что поняла. 🧐Репутация строится не на том, что вы знаете, а на том, как вы себя ведёте Никто внутри компании не оценивает вас по знанию методологий. Оценивают по простым вещам — сказала, что сделает к среде, сделала к среде. Написала, что разберётся и напишет — разобралась и написала. Не знает ответа — говорит честно, вместо того чтобы тянуть время. Предсказуемость — это валюта доверия. Накапливается медленно, тратится быстро. Я это поняла, когда один раз подвела коллегу — не сильно, просто забыла передать важную информацию вовремя. Казалось бы, мелочь. Но именно это он вспомнил через полгода, когда меня рекомендовали на проект. Не со злым умыслом — просто так работает память на негативное. ✅Хорошая работа сама себя не продаёт Это было самым сложным для меня лично. Я из тех, кто считает, что результат говорит сам за себя. Оказалось — нет. Аналитика — невидимая профессия. Конфликт, который вы предотвратили — никто не видел. Противоречие в требованиях, которое нашли до разработки — никто не оценил. Встреча, которая прошла гладко, потому что вы её хорошо подготовили — воспринимается как само собой разумеющееся. Руководство видит проблемы — они громкие. Хорошую работу не видит — она тихая. Я не стала хвастаться. Но начала делать работу видимой: короткий статус по проекту раз в неделю без запроса, после закрытия этапа — два абзаца, что сделано и что это дало проекту. Маленькие вещи — но руководитель перестал узнавать о моей работе только тогда, когда что-то шло не так. ❌Кризис — лучший момент для репутации Парадокс, который я поняла на собственном опыте: люди запоминают не то, как вы работаете, когда всё хорошо. Запоминают то, как вы ведёте себя, когда плохо. У меня был проект, где мы просели по срокам. Частично моя недоработка — не докопалась до одного требования, которое потом вылезло и всё усложнило. Я пришла к руководителю сама, раньше чем он узнал из другого источника. С разбором того, что случилось, и с планом, как выправляем. Было страшно. Но именно после того разговора отношение изменилось в лучшую сторону — не потому что всё было хорошо, а потому что я не спряталась. Прятаться, когда плохо — худшее, что можно сделать для репутации. Все это замечают. 🤓Разработчики — недооценённый источник репутации Мало кто думает об этом целенаправленно. А зря. То, что разработчики говорят о вас между собой, расходится по компании быстрее любого официального фидбека. “С ней приятно работать — требования понятные, отвечает быстро, не пропадает, когда вопросы” — такая рекомендация стоит дорого. Я однажды спросила разработчика напрямую: что в моих документах мешает работать? Он опешил — видимо, никто раньше не спрашивал. Потом рассказал несколько вещей, которые я поменяла и которые реально ускорили нашу совместную работу. И стал одним из тех, кто меня рекомендовал на следующий проект. 📈 Горизонтальные связи работают дольше, чем вертикальные Руководители меняются. Компании реструктурируются. А люди, с которыми вы работали — уходят на другие проекты, в другие компании и берут с собой воспоминание о вас. Помогла коллеге разобраться со сложным заказчиком — запомнила. Поделилась шаблоном, который сэкономил время — запомнил. Поддержала новичка, который потерялся на первом проекте — не забудет. Это не расчёт. Просто так устроены отношения — люди помнят тех, кто им помог, когда было сложно. Репутация — это не проект с дедлайном и не список задач, которые нужно выполнить. Это то, как вы работаете каждый день — даже когда никто не смотрит. Особенно когда никто не смотрит. Если было полезно, ставьте реакции Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

ТЗ в 2026 году — писать или не писать? Салют! Теперь я хочу поделиться своим мнением на счет ТЗ на разработку в наших реалиях. Знаете что меня до сих пор удивляет? Каждый год кто-нибудь обязательно скажет что ТЗ умерло. Agile победил, итерации рулят, зачем писать документ который устареет через месяц. А потом тот же человек приходит с горящими глазами: “мы сделали не то, заказчик недоволен, кто виноват непонятно”. И знаете что выясняется? Нигде ничего не зафиксировано. 🥺 Я через это прошла. И не один раз. Почему ТЗ ругают — и в этом есть доля правды Классическое ТЗ по ГОСТ — это больно. Двести страниц которые пишутся месяцами, согласовываются вечность и устаревают к моменту подписания. Я видела такие документы. Толстые, красивые, абсолютно мёртвые — потому что никто их не читал. Включая тех кто писал. Но проблема не в самой идее фиксировать требования. Проблема в том что ТЗ превратили в ритуал вместо инструмента. Где без фиксации становится по-настоящему больно Расскажу один кейс. Проект без нормальной документации — команда договорилась устно, доверяли друг другу, торопились. Через три месяца разработки заказчик увидел результат и сказал “это не то что я имел в виду”. Разработчики показали переписку — там действительно было сказано именно так. Заказчик был уверен что имел в виду иначе. Кто прав? Оба. И никто. Потому что нигде не было написано однозначно. Переделки, потраченные деньги, испорченные отношения. Agile тут ни при чём — просто люди не зафиксировали договорённости. Что писать в 2026 году — конкретно

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

Хорошая документация сегодня выглядит иначе: - Короче. Ровно столько сколько нужно для однозначного понимания. Иногда десять страниц, иногда три. Объём не равно качество. - Живее. Документ который обновляется по ходу проекта в Confluence или Notion лучше замороженного артефакта после подписания. - Конкретнее. Не “система должна быть удобной” а “пользователь создаёт заявку за три шага”. Не “быстрая загрузка” а “страница открывается не дольше двух секунд”. - С акцентом на главное. Бизнес-цель, ключевые сценарии, критерии готовности, ограничения. Остальное по необходимости. Когда без серьёзного документа нельзя Есть ситуации где я бы не взялась за проект без нормального ТЗ: - Госпроекты и тендеры - там это требование закона - Фиксированный бюджет и фиксированный скоуп - нет документа, нет защиты ни для кого - Интеграции с внешними системами - без чёткой спецификации две команды сделают два разных API и удивятся почему не стыкуется - Высокая цена ошибки - производство, медицина, финансы Здесь ТЗ не бюрократия. Это единственный способ не потерять деньги и репутацию. Когда можно обойтись малым - Внутренний продукт с гибким скоупом и заказчиком который всегда на связи - Небольшая доработка существующей системы - Стартап где всё меняется быстро и документ устареет раньше чем его дочитают Но даже здесь - ключевые договорённости фиксирую всегда. Хотя бы коротким письмом после встречи. Это занимает десять минут и сколько раз спасало - не пересчитать. Мой честный ответ после двенадцати лет ТЗ в классическом виде — да, уходит. Но потребность которую оно закрывает никуда не делась. Людям нужна общая картина. Нужно понимать что строят, зачем, для кого и как поймут что сделали правильно. Нужна точка к которой можно вернуться когда начнутся споры — а они начнутся всегда. Называйте как хотите — ТЗ, спецификация, product brief, просто нормальный документ. Суть одна: договорённости должны существовать не только в головах участников. Потому что головы у всех разные. И каждая искренне уверена что всё помнит правильно. Как у вас на проектах — пишете или обходитесь? Если пишите, ставьте - 👌 Если обходитесь, ставьте - 🙈 Если нравится тема и пост, ставьте любую из реакций - 🔥♥️👍 Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA