Business Analyst Storyteller Telegram Channel Link

🧵 Запускаю серию про SQL. Часть 1 — работа с данными: создаем, наполняем, достаем, меняем, удаляемНу что, сердечки под постом набрали, значит делаем серию про SQL. Серия коротких разборов: от «что это вообще» до вещей, на которых спотыкаются все. Каждый пост закрывает одну тему, к нему — карточки-шпаргалки, которые можно сохранить и держать под рукой. Посты будут появляться каждые несколько дней. 🤍Сначала коротко — зачем это.SQL — язык, на котором мы разговариваем с базой данных напрямую. Почти все, чем мы пользуемся, хранит данные в таблицах: клиенты, заказы, платежи. SQL — способ попросить у базы ровно то, что нужно, или что-то в неё положить. Нужно это всем, кто работает с данными: аналитикам, разработчикам, тестировщикам, продактам. Главная ценность — самостоятельность: сам достал, сам поправил, никого не дергая, ну и, конечно, это супер полезно, если вы фуллстэк аналитик или системный, и вам надо описать ТЗ, разобраться в каком-то вопросе и т.д.А логика работы с данными простая, как в жизни: сначала создаем таблицу → кладем данные → достаем их обратно → при необходимости меняем или удаляем. Пройдем весь цикл в этом посте. 1. Создаем таблицу — CREATE TABLE. Описываем, какие столбцы будут и какого типа данные:CREATE TABLE clients (id INT PRIMARY KEY,name VARCHAR(100),city VARCHAR(100))INT PRIMARY KEY — это первичный ключ, уникальный идентификатор строки. По нему мы однозначно отличаем одну запись от другой: он не может повторяться и не может быть пустым (обычно это id). А чтобы база присваивала этот id сама, по порядку (1, 2, 3…), используют авто-инкремент: SERIAL в PostgreSQL или AUTO_INCREMENT в MySQL — тогда id вручную можно не указывать.VARCHAR(100) — текст до 100 символов. Таблица пока пустая — есть только «каркас». Весь перечень типов данных для описания легко гуглится, в карточке указала основные, "ходовые" типы.2. Кладем данные — INSERT:INSERT INTO clients (id, name, city)VALUES (1, 'Анна', 'Москва')Можно добавить сразу несколько строк, перечислив их через запятую.3. Достаем данные — SELECT. Главная команда чтения. Говорит базе: «покажи мне вот это».Все столбцы — через звездочку:SELECT * FROM clientsТолько нужные — перечисляем:SELECT name, city FROM clientsИ сразу заводим привычку — алиасы: даем столбцу понятное имя через AS:SELECT name AS имя, city AS город FROM clientsТеперь колонки называются «имя» и «город», а не name и city. Мелочь, а когда столбцов много или появятся функции — спасает читаемость.4. Меняем — UPDATE:UPDATE clients SET city = 'Казань' WHERE id = 15. Удаляем — DELETE:DELETE FROM clients WHERE id = 1⚠️ Самое важное правило этого поста: у UPDATE и DELETE почти всегда должен быть WHERE. Без него вы измените или удалите СРАЗУ ВСЮ таблицу. Это классическая и очень болезненная ошибка — запомните сразу.Ещё бывают временные таблицы (CREATE TEMP TABLE ...) — такие же, но живут только до конца вашей сессии, удобно для промежуточных расчёеов. Это уже на будущее.Вот и вся база: вы умеете создать таблицу, наполнить её, достать данные и поправить. В следующей части — как доставать не всё подряд, а по условию (WHERE): больше, глубже и с примерами.👇 Карточки к посту сохраните — это вся суть в нескольких картинках. А в комментах скажите: вы совсем новичок в SQL или листаете как напоминалку? Подстрою глубину следующих частей.#SQL #шпаргалка

Сходила на StormClub#2 про бизнес-способности (или Capability Map) — и вынесла оттуда один тезис, с которым внутренне не согласна. В пятницу была на шторм-клубе, тема — Capability Map (карта бизнес-способностей). К сожалению, опоздала на первый доклад Андрея Коптелова 🙈 но успела на второй — от эксперта из Альфа-Банка Юрия Завьялова. И, кажется, не зря: во-первых, вынесла пару мыслей, которыми хочу поделиться, а во-вторых… выиграла халат за хороший вопрос 😄 (очень приятно).Про сам вопрос скажу отдельно, потому что он про то, что меня давно занимает. Я спросила, какими метриками "обвешивается" Capability Map — как измерять зрелость и эффективность самих способностей, степень их автоматизации, покрытие численностью и оргструктурой. Тема мне близкая: в проекте, где я с этим работала, мы закладывали много метрик под карту, но, честно, реализовать все так и не успели. Так что для меня это до сих пор открытый и живой вопрос.Пара наблюдений из доклада:Capability Map — это отдельный срез, не процессы. Отдельный взгляд на компанию «что она умеет», который можно связать с процессами, но путать их не стоит. Классический тезис — что это инструмент для крупных компаний, для управления сложностью, а среднему бизнесу не очень-то нужен. В целом соглашусь… но с оговоркой: мне кажется, в части средних компаний это тоже может отлично зайти. Не так однозначно.А теперь то, ради чего я и затеяла этот пост. На докладе прозвучал новый термин — «прикладной процесс», и я на нем триггернулась, и судя по тому, что про него (термин) было неколько вопросов из зала, триггернулась не только я.Как я поняла спикера: бизнес-процесс — это чистая бизнес-логика, там нет и не должно быть ничего про техническую реализацию. А то, как это технически реализовано, выносится в отдельный слой — «прикладной процесс». В теории логично и красиво: не смешивать «что» и «как».Но на практике я много раз сталкивалась с обратным. Моим заказчикам (в лице руководителей, бизнеса, коллег-архитекторов и тд) как раз очень хотелось видеть больше технической информации прямо в процессе — потому что потребители бизнес-процессов на самом деле не только бизнес-команды. Их читают и айтишники: разработка, аналитики, тестировщики. И когда техническая реализация вынесена куда-то в отдельный слой, на стыке начинается «а посмотри вот в том документе» — и теряется цельная картина.То есть теоретически разделять чисто — правильно. А практически чистота часто оборачивается тем, что ни одному из потребителей процесс не дает полной картины.Вот тут мне правда интересно ваше мнение 👇Как вы для себя разделяете бизнес-процесс и техническую реализацию? Держите строго отдельно — или сознательно подмешиваете тех.детали в процесс, потому что его все равно читают IT-команды? И встречали ли вы термин «прикладной процесс» — прижился он у вас или нет?Кстати, если тема Capability Map вам близка — у меня есть про это отдельная статья, оставлю ссылку 👉 https://stormbpmn.com/blog/bpm/zachem-sozdavat-karty-business-competenchii И напоследок, лично 🤍 На клубе встретила свою подписчицу — и так тепло пообщались. Каждый раз кайфую от таких живых встреч. Поэтому если мы вдруг пересекаемся на каком-то мероприятии — не стесняйтесь, подходите: с вопросом, с мыслью или просто сказать привет. Живое общение — это топ. А если вы ходите куда-то, где есть нетворкинг, — обязательно им занимайтесь, это правда работает.

«Выбор без выбора» — это еще выбор? Воскресный разговор о карьере, свободе и цене слова «нет»Под постом про руководителей у нас с Вовой (Вова, спасибо за этот разговор 🙏) развернулся спор, который я не могу выкинуть из головы. Он не про РП. Он про то, как мы вообще строим карьеру — и чем за нее платим. Тащу его сюда (разговор, не Вову), потому что, кажется, он про каждого из нас.Началось с простого. Я сказала вещь, в которую верю по опыту: если работаешь в крупной компании и хочешь расти, то политика, подковерные игры и интриги — это выбор без выбора. Хочешь не хочешь — будешь втянут. Компаний, где этого нет, исчезающе мало.И тут Вова ответил так, что меня зацепило:«Выбор без выбора — это не выбор. Это несвобода. Есть три ценные вещи: здоровье, время, свобода. Первые две невосполнимы. А свобода — это возможность сказать „нет“.»Красиво. И правда красиво. Но я не смогла согласиться до конца.Потому что да, ты можешь сказать «нет». Формально свобода есть всегда. Но у этого «нет» есть цена: либо ты остаешься без роста внутри компании, либо идешь искать другую компанию. А на новом месте — снова та же рулетка: политики там может быть не меньше, а проверить это на собесе почти нереально. То есть свобода сказать «нет» есть, но она не бесплатная, и она не гарантирует, что за дверью будет лучше.Это и есть, по-моему, честная картина взрослой карьеры: свобода есть всегда, но она всегда с ценником. И «несвобода» — это часто не отсутствие выбора, а нежелание платить его цену. Что, кстати, тоже нормально — не за все стоит платить.А потом Вова сказал вторую вещь, которая перевернула для меня весь спор:«Вертикальная карьера и рост дохода — это „где, сколько и когда“. Это мишень, а не цель. Мишень можно поменять, не меняя цели.»Мы ведь и правда годами можем путать мишень с целью. Нам показали одну лестницу — специалист, лид, руководитель, директор — и мы лезем по ней, даже не спросив себя: а это вообще моя лестница? Или я карабкаюсь по ней просто потому, что ее приставили к стене раньше, чем я успел подумать, чего хочу на самом деле?Цель — это то, что ты правда хочешь: влиять, расти как профи, жить и зарабатывать так, как тебе надо, иметь свободу. А «стать руководителем» — это всего лишь одна из мишеней, в которую ты решил, что цель зашита. Но мишеней-то много. И если в эту конкретную не попадаешь — из-за политики, рынка, отсутствия вакансии — это не провал цели. Это повод сменить мишень.Тогда и «выбор без выбора» перестает быть ловушкой. Ты не обязан продавливаться вверх по одной-единственной лестнице ценой нервов, здоровья и той самой свободы. Можно целиться иначе — в глубину экспертизы, в горизонталь, в другой формат, — и прийти к той же цели другим путем.Не хочу искать того, кто полностью прав из нас, по-моему, правда всегда где-то посередине: свобода реальна, но платная. А несвобода часто начинается там, где мы перепутали чужую мишень со своей целью — и полезли по не своей лестнице, забыв спросить зачем.Воскресенье — хорошее время об этом подумать. 😊То, к чему вы сейчас идёте в карьере, — это ваша цель? Или мишень, которую вам когда-то показали пальцем?И для тех, кто уже стоял на этой развилке: вам приходилось говорить «нет» и платить его цену? Не пожалели?

«Ну ты же руководитель проекта!»Под прошлым постом про руководителей проектов вы накидали столько классных тем, что мне одного поста мало — буду раскрывать их по очереди. Впереди отдельно про карьеру, про то, как выбирать компанию, и много чего еще. Но начну с прямого запроса.Для сначала — одна мысль, которая для меня связывает все это воедино:Умение договариваться — это и есть главный руководительский скилл. Не раздавать приказы, а находить общий знаменатель между людьми, у которых разные интересы. И нигде это не проверяется так жестко, как в матрице. Поэтому вопрос Ивана — он на самом деле именно про это.А вопрос вот в чем. Матричная структура: в проекте у РП есть разработчики, тестировщики, аналитики, DevOps, дизайнеры — но никто из них ему не подчиняется. У каждого свой тимлид или ресурсный менеджер, со своими приоритетами и своим распределением людей. А за сроки и результат проекта спрашивают с РП. Классическая ответственность без полномочий. И коронный аргумент, которым на РП сваливают вообще все, даже сами тимлиды (а лучше сказать - частенько тимлиды): «ну ты же руководитель проекта».Тема больная и очень частая — в IT матрица скорее норма, чем исключение. Давайте разбираться.Для начала, матрица — это не баг, это осознанный размен.Компания сознательно жертвует единоначалием ради гибкости: один сильный бэкендер шарится между тремя проектами, экспертиза не простаивает, людей не держат в простое под один проект. Цена этого размена — та самая «ответственность без полномочий». Поэтому первое, что важно принять: если вы ждете, что в матрице вам дадут прямую власть над командой, вы ждете напрасно. Её там нет by design. Работать придется влиянием, а не приказом. И это отдельный навык.Но влияние — не значит бесправие. И вот где, на мой взгляд, проходят границы.За что реально отвечает РП:За то, что можно делать без формальной власти над людьми. Видеть и держать картину целиком. Планировать и вести график. Подсвечивать риски заранее. Координировать стыки между командами — тот самый момент, где бэк ждет фронт, фронт ждет аналитику, и т.д. Эскалировать вовремя. Держать заказчика в курсе. По сути РП отвечает за процесс и прозрачность, а не за то, что конкретный разработчик сел и написал код.За что РП отвечать не должен (но постоянно заставляют):За то, что решается только властью над ресурсом. Кого из своих людей и на сколько процентов выделит тимлид. Какие у команды приоритеты на спринт. Будет ли разработчик сегодня делать твою задачу или его перекинули на прод-инцидент в соседнем проекте. Это зона тимлида / ресурсного менеджера — потому что люди его, и рычаг у него.И вот тут ключевой сдвиг. Когда прилетает «ну ты же РП», правильный ответ — не тащить все на себя и не огрызаться, а вернуть вопрос туда, где реально лежит рычаг: «Да, я отвечаю за то, чтобы этот вопрос не потерялся и был решен. Но решение — за тобой как за владельцем ресурса. Моя задача — подсветить: если разработчика не выделят до четверга, срок проекта едет вот сюда. Фиксируем?»Ответственность за эскалацию и прозрачность — на РП. Ответственность за решение по ресурсу — на том, у кого власть над этим ресурсом. Смешивать эти две вещи и есть корень всей несправедливости.

И еще один момент, который решает почти все, — кому все эти люди подчиняются наверху.По моему опыту, работа идет заметно легче, когда проектный офис и команда разработки в итоге сходятся на одном руководителе. Условно: есть один руководитель, и под ним и проектный офис, и разработка (важно: этот руководитель над ними сразу, а не в конце пищевой цепи). Тогда у РП и у тимлида, по сути, один общий начальник — а значит, у них общая цель, и они реально в одной лодке. Конфликт приоритетов есть всегда, но его есть кому разрулить, и обе стороны это понимают.А вот когда проектный офис сидит в одном крыле и репортит одному человеку, а разработка — в другом крыле и другому, вот тут начинается настоящая боль. У РП и тимлида разные начальники, разные KPI, разные интересы — и договориться становится в разы сложнее, потому что общего «арбитра» над ними просто нет, или он так высоко, что до него не достучаться.Это, кстати, полезно понимать еще на собеседовании: спросите, кому подчиняется проектный офис и кому — команды. По ответу вы много поймете о том, во что ввязываетесь.А теперь то, о чём чаще всего забывают, — что должна дать сама компания.Потому что без этого даже гениальный РП в матрице будет биться головой о стену. Хороший РП возможен, только если компания дала ему хотя бы часть из этого:— поддержку сверху. Чтобы спонсор проекта или заказчик прямо сказал командам: «этот человек ведет проект, его запросы — в приоритете, это не по желанию». Без этого РП для тимлидов — просто еще один голос в чате.— работающий канал эскалации. Не «написать в пустоту», а живой путь наверх, где конфликт приоритетов между проектами реально разруливают, а не оставляют висеть.— голос в оценке людей. Чтобы фидбэк РП о человеке, который работал в его проекте, реально доходил до тимлида и что-то значил. Если разработчик знает, что твое слово о нем будет услышано, — и отношение к твоим задачам другое.— понятные правила, кто на сколько занят между проектами и продуктовой работой, а не «кто громче крикнул».Если компания этого не дала — проблема не в том, что РП плохой (ну или не только в этом). Проблема в том, что роль устроена как ловушка: спросить можно, а инструментов нет.

За что я люблю удаленкуНа прошлой неделе по личным обстоятельствам почти всю неделю проработала удаленно — и в очередной раз вспомнила, за что же я так люблю этот формат.Оговорюсь сразу: я человек супер-социальный. Люблю общение, люблю коллег, люблю движ в офисе, реально кайфую от живых обсуждений. Но за два года гибрида я честно могу признаться (раньше кстати я думала иначе, я считала гибрид идеальным форматом): удаленка мне все-таки ближе. И вот почему.На удаленке я успеваю все. За эту неделю я и полноценно поработала, и спортом позанималась, и на тренировки по сквош сходила, и домашние дела разгребла, и поесть приготовила, и погуляла, и с друзьями встретилась, и на визу для грядущего отпуска подалась. Продуктивность — и рабочая, и личная — просто на другом уровне, когда не тратишь два часа в день на дорогу и не выпадаешь каждые пятнадцать минут на «а можно на секундочку», «а на обед во сколько», «а может по кофейку?».Но успела я не только это. Успела ещё и поучиться — и вот к этому хочу перейти отдельно.В новой роли на проекте мне сейчас приходится много заниматься анализом, в том числе системным, руками. И я решила подтянуть SQL — освежить, углубить, довести до автоматизма.И раз уж взялась — сразу поделюсь находкой. 🎓Я занималась на тренажере по SQL на Stepik — и мне очень зашло. Это именно практический тренажер без километровой теории: ты не читаешь, ты сразу пишешь запросы и решаешь задачи. Идеально заходит тем, кто в теме в целом, но хочет прокачать именно живую, практикующую базу. Не «выучить с нуля по учебнику», а «набить руку».Ссылку оставляю здесь 👉 Интерактивный тренажер по SQLИ вот что. Пока я все это осваивала заново, у меня накопилось много практических штук, которыми хочется поделиться: приемы, разборы реальных примеров, типичные ошибки аналитиков в запросах, то, что реально пригождается в работе.Но заводить целую серию имеет смысл, только если она вам правда нужна. Поэтому предлагаю честную сделку 🤝Хотите серию практических постов про SQL для аналитиков — с примерами и разборами? Ставьте ❤️ под этим постом. Наберем 30 — запускаю серию.А в комментариях расскажите, что именно было бы полезно разобрать?

Хороших руководителей проектов почти не осталось. И я, кажется, понимаю почему.Про РП вообще много говорили всегда — и, честно, чаще в плохом ключе. Что это человек, на котором все вымещают злость: и заказчик, и команда. Что быть хорошим руководителем проекта тяжело.И это правда. По-настоящему хороших РП — единицы. Я знаю людей, которым за всю карьеру ни разу не посчастливилось поработать с толковым руководителем проекта, который реально грамотно ведет команду. Ни разу, представляете?Но я хочу сказать про другое. Не про то, что им тяжело. А про то, что очень многие из них просто не понимают, в чем вообще их роль.Откуда это взялось, у меня есть версия. Жирные годы в ИТ, о которых я уже вспоминала в прошлом посте. Дефицит кадров, дикий спрос на управленцев, люди росли в должностях быстрее, чем росли их навыки. Вчера специалист — сегодня уже «руководитель проекта», а управлять-то никто не научил. И вот результат: куча людей на позиции РП, которые не умеют видеть риски, не умеют их подсвечивать и не очень понимают, что делать руками.Разберу на конкретных признаках. Вот что, на мой взгляд, отличает РП, с которым тяжело, от того, с которым команда выживает и побеждает.1. Он думает, что его работа — «создавать атмосферу».Терпеть этого не могу. Есть тип руководителей, которые решили, что их главная задача — всех веселить, подбадривать и шутить. И вот команда захлебывается, выгорает, открытым текстом просит: покажи план, объясни, куда мы движемся, дай понять, что происходит. А в ответ — несмешные шуточки и «ребят, ну мы же команда, прорвемся» 🙃Атмосфера — это следствие того, что люди понимают, куда идут и что их ведут. А не замена этому. Хорошая атмосфера не спасет команду без плана. Плохая шутка в момент аврала — вообще кроме негатива ничего не вызывает. 2. Он не умеет подсвечивать риски — и молчит там, где надо говорить.Вот пример, который я вижу постоянно. В команду заводят нового человека (как временный доп ресурс). Хороший РП сразу проговаривает наверх: онбординг займет столько-то, быстро не будет, потому что человеку надо освоить и специфику нашей системы, и бизнес-домен, и — если он раньше мало работал системным аналитиком — саму профессию. Это риск, и его надо назвать вслух заранее.Плохой РП молчит. А потом, когда сроки поехали, для всех это «внезапно». Хотя ничего внезапного не было — просто риск никто не подсветил.3. У него не хватает смелости говорить с высшим руководством (они именно так и называют руководителей - высшее руководство 😁).И это, наверное, главное. Настоящая работа РП — иметь мужество донести наверх неудобное. Что сроки нереальные. Что ресурсов не хватает. Что рисков вот столько. А не кивать начальству и перекладывать давление обратно на команду, засунув собственную позицию куда подальше.Хороший руководитель проекта — это щит между командой и хаосом сверху. Плохой — это воронка, которая весь хаос сверху сливает вниз на команду. И самое грустное: людей первого типа — единицы, а второго, к сожалению, большинство.Жду вас в комментариях 👇Вам за карьеру попадался по-настоящему хороший руководитель проекта? Что он делал такого, чего не делают остальные? И с какими «клоунами-затейниками» сталкивались вы 😅

Небольшой апдейт для тех, кто потерял 🙌 У меня сменился проект, а вместе с ним — даже роль. Те, кто был на нашей личной встрече, помнят, с какими трудностями я боролась на прошлом проекте (в канале я про это так подробно не рассказывала — решила оставить только для очного обсуждения). Сейчас я в другом проекте, и даже в другой роли, но в той же компании. Пока не решила, буду ли разворачивать эту историю здесь — посмотрим.Но суть вот в чем. В этот момент нестабильности — между «одно закончилось, другое еще толком не началось» — у меня впервые за долго появилось время просто поднять голову и осмотреться. Не то чтобы я вышла искать работу. Скорее решила посмотреть, что вообще сейчас происходит на рынке: почитать вакансии, поговорить с рекрутерами, сходить на пару собеседований — чисто разведка.И вот что я там увидела. Оно меня, честно, немного напрягает.Тема сейчас живая как никогда. В куче компаний снова волны сокращений. Зарплаты в IT как будто уже длительное время ползут вниз (скажите мне, что это не так, и я ошибаюсь, пожалуйста 🥲). Даже на текущем проекте я вижу, что часть ребят держится за место не потому, что горят им, а потому что снаружи страшно. И это грустно.Но зацепило меня другое.Складывается стойкое ощущение: рынку все меньше нужны руководители и все больше — люди, которые умеют работать руками.Рекрутеры цепляются за реальный опыт: бизнес-анализ, системный анализ, архитектура — что ты умеешь делать сам, своими руками. А управленческий опыт как будто уходит на второй план. Как будто руководителей уже достаточно, и рынок наелся.И тут я разрываюсь.С одной стороны — меня это где-то даже радует. Помните, как было в жирные годы? Руководителей было больше, чем тех, кто реально делает работу. Каждый второй — «лид», «хед», «менеджер чего-нибудь». Так что откат к хардам — это по-своему здоровое отрезвление.Но с другой — маятник улетел в другую крайность. И вот доказательство. Прикладываю реальные требования к руководителю группы системного анализа, в которых нет НИ ОДНОГО пункта про управление людьми. Ноль. Руководитель — а руководить, судя по вакансии, не надо 🤷‍♀️Я много лет топила за soft skills и продолжаю топить — для руководителя это критично (кстати, скоро будет отдельный пост про непутевых руководителей, накипело). Но то, что я вижу на рынке сейчас, — это перегиб в обратную сторону. Из одной крайности в другую, минуя здоровую середину.Расскажите, что видите вы 👇Если вы руководитель или метите на руководящую позицию — как ощущается рынок с вашей стороны? Реально ли сместился фокус на харды, или это только моя оптика? И сталкивались ли вы с такими вакансиями-загадками, где «руководитель», а руководить как будто не надо?

Новости короткой строкой— пропала на месяц и, кажется, никто не заметил, отличный тест на важность 😅— была в отпуске, впервые за долго выдохнула по-настоящему (фото оттуда). Черногория прекрасна, конечно— встретилась с вами вживую на бранче — очень получилось душевно, встреча из категории "приятно вспомнить" 🤗— последняя неделя летаААА, как так быстро оно промчалось— на работе туманно: меняется проект, и пока непонятно, куда все вырулит— зато освободилось время под выступления и всякие сторонние штуки, о которых давно думала— вокруг один ИИ, ИИ, ИИ — то ли будущее, то ли все просто громко нервничают— возвращаюсь в сквош после месяца отдыха, а в воскресенье уже турнир 🙃— в воскресенье пробежала 10 км по Садовому, зачем — не знаю, но горжусь собой— бензин почти все, но вы держитесь — и знаете что — уже хочется Новый год. Прямо чтоб елка, итоги и «с чистого листа»А вы там тут как? Чем жили этот месяц?

Мы умеем документировать что угодно, кроме собственных результатовРасскажу, с чего для меня это началось.Несколько лет назад у меня был 1:1 (а-ля ревью). Руководитель спросил простую вещь: «Расскажи, что ты сделала за последние полгода». И я поплыла. Помнила, что было тяжело, что задерживалась, что вытащила пару горящих историй. А вот что конкретно — не могла собрать. В голове был туман из «ну, работала, помогала, участвовала». В итоге я описала свое полугодие так, будто мимо проходила и иногда подавала инструменты.Смешно вот что. На той же неделе я три дня выпытывала у стейкхолдера, что он на самом деле имел в виду под «сделайте нормально». И применительно к проекту все получилось сделать четко: распиала требования, метрики, собрала бизнес-эффект и защитила решение перед скептиками. То есть чужую ценность я умела вытаскивать на свет, а вот свою — не смогла назвать даже наедине с собой.С тех пор мне кажется, что: обесценивание — это не скромность. Это плохо собранные требования к самому себе.Откуда оно беретсяМы фиксируем чужой результат по фактам, а свой — по ощущениям. Чужое: «он закрыл интеграцию, вот пруф». Свое: «да ничего особенного, любой бы справился». И проблема в том, что по ощущениям всегда выходит «ничего особенного» — потому что для вас ваша работа прозрачна. Вы же видели, как получалась каждая деталь, знаете, где схалтурили, где повезло, где подсмотрели решение. Изнутри любой результат выглядит как набор мелких понятных шагов. «Магия» видна только снаружи, тому, кто не видел кухню.Плюс, аналитики — люди контекста. Мы привыкли говорить «мы командой», «в рамках проекта», «удалось добиться» — безличными конструкциями, где субъект растворен. Это профессиональная деформация: в документации так и надо. Но когда вы тем же языком говорите о себе, вы буквально вычеркиваете себя из собственных достижений грамматически. «Удалось сократить сроки» — а кем удалось-то? Узнали свои фразы на собесах?😁Что с этим делать по-аналитическиХорошая новость: если проблема в том, что вы плохо собрали требования к себе, — значит, это чинится теми же навыками, которыми вы чините чужие проекты.Первое. Отделяйте факт от эмоции. «Кажется, я неплохо поработал» — это не данные, это самочувствие. «Сократил согласование требований с трех недель до одной» — данные. Присвоить результат = перевести его из ощущения в факт, желательно с цифрой или до/после. Если цифры нет — ищите наблюдаемое изменение: раньше на этот процесс уходило два человека, теперь один; раньше требования переделывали дважды, теперь принимают с первого раза. Факт — это то, что заметил бы сторонний наблюдатель. Ощущение — то, что чувствуете только вы.Второе. Ищите свой вклад в общем. «Команда запустила продукт» — правда, но для вас бесполезная, потому что там нет вас. Задайте себе вопрос как аналитик, который ищет критический путь: что развалилось бы конкретно без меня? Не «я был полезен вообще», а «вот эта часть держалась на мне, и если бы меня убрать, здесь была бы дыра». Это не весь проект — это ваш кусок. Но названный честно и в первом лице. «Я собрала требования, на которых потом строили всю интеграцию» — вот это ваш результат, а не «участвовала в проекте по интеграции».Третье. Ведите свой changelog. Самый скучный и самый работающий прием, который я почему-то забросила 😂, но сейчас возвращаю. Раз в неделю, в пятницу, одна-две строчки: что я сделал и что из этого получилось. Не для отчета и не для начальника, а для себя. Сначала это может занимать какое-то время и немного подбешивать, потом будет достаточно пяти минут на то. чтобы все сформулировать и записать.По итогу через пару месяце у вас доказательная база, которой у никогда не было. С этими фактами и к собеседованию готовиться проще, и и разговору о повышении, да и с внутренним критиком/самозванцем, или кто там у вас, проще договариваться. Разница в позиции колоссальная.

И еще в пользу того, чтобы записывать: память, врет системно и в невыгодную сторону — плохое помнится ярче хорошего, это устройство психики, а не ваш личный дефект. Записи не врут. Поэтому дневник побед — это не про самолюбование, это про то, чтобы иметь честные данные о себе, а не искаженные.И главноеПрисвоить результат — это не «начать себя хвалить» и не «накручивать значимость». Это перестать быть единственным человеком, к чьей работе вы применяете двойные стандарты. К чужой — факты, метрики, признание вклада. К своей — «да ладно, ерунда, любой бы смог».Любой бы не смог. Вы смогли. Просто вы, как хороший аналитик, слишком хорошо видите кухню и поэтому не верите в блюдо.А вы как — фиксируете свои победы или они растворяются к вечеру пятницы? 👀

Живая встреча за бранчем — про работу, застревания и то, что реально мешает растиНесколько месяцев назад я запускала опрос — спасибо всем, кто ответил 🤍 Я перечитала каждый ответ по несколько раз, и там оказалось много честного.Вот что я увидела. Почти все вы — практикующие аналитики, не новички. И при этом в графе «с какими задачами сталкиваетесь» написано: «я карьерный тупик». «Карьерное выгорание». «Хочется больше технической подкованности». «Найти работу, которая будет драйвить». «Хаос: все ставят задачи всем, ничего хорошего».Это не то, что решается прохождением курсов, обучениями. Это то, что решается разговором с людьми, которые в том же самом.Еще в опросе почти все написали, что хотели бы разборы реальных кейсов и живое общение. Ну так давайте и сделаем.👥 ФорматМаксимум 10 человек — чтобы каждый успел сказать и быть услышанным.Без микрофонов, презентаций и лекций. Я не буду выступать. Сядем, познакомимся, и дальше — разбираем ваши реальные ситуации: кто на чем застрял, кто что уже пробовал, что сработало, а что нет. Я модерирую и делюсь тем, что видела на своем пути.🌿 О чём поговорим— где вы сейчас застряли и почему привычные способы не помогают— карьерный потолок: что делать, когда ты вроде вырос, а расти некуда— как работать со стейкхолдерами, когда все хотят разного и вчера— как перестать обесценивать свои результаты (мне этот вопрос задали в опросе, и он меня зацепил)— и все, что вы принесете — тем интереснее, чем конкретнееЯ хочу, чтобы каждый ушел не с вдохновением, а с одной понятной мыслью, что делать в понедельник.📍 Где и когда02 августа, ориентировочно в 14:00Кафе в центре Москвы. Точную точку отправлю тем, кто запишется.💬 УсловияСтоимость — только ваш бранч. Никаких билетов, никакой монетизации.Приходить можно с любым уровнем и в любом состоянии — «мне нечего рассказать» не работает, вопрос уже достаточный вклад.Если чувствуешь отклик — напиши мне в л/с @GaLina_KorenevskayaБуду очень рада увидеться 🤗

Про курс для студентовВ одном из прошлых постов я обещала рассказать про преподавание. Рассказываю — и это, пожалуй, самая теплая история моего полугодия 🤍Начну с признания/открытия: мне очень нравится учить. И, кажется, у меня неплохо получается. Но надо также сказать, что реального опыта преподавания для студентов у меня не было. Совсем. Одно дело выступать на конференции 40 минут, или обучать своих сотрудников, другое — вести курс у студентов, которые придут к тебе снова, и снова, и снова, и будут ждать, что ты знаешь, что делаешь. Надеюсь мне удалось такое впечатление у них создать 😂Как я в это ввязаласьНа курс «Анализ бизнес-процессов» для студентов iSpring очень долго искали преподавателя. Долго. И когда наконец нашли меня, до сесии оставалось буквально чуть больше, чем полтора месяца.Полтора месяца — чтобы прочитать весь курс. И это еще полбеды. Главное: не было ничего готового. Ни программы, ни материалов, ни заданий. Все пришлось продумывать самой — от структуры и логики курса до каждой лекции, каждой практики, каждого задания и того, как их проверять.Я, конечно, честно оценила объем работы. Я ж аналитик. И, конечно, где-то просчиталась 😂 Но где? 🤔Лекции читала до 21:00. Каждые выходные ездила на очные занятия. Материалы доделывала между всем остальным. И знаете что? Получилось супер.А вот главное открытие — это студенты 🥰Я почему-то ждала обычную студенческую историю. А получила ребят, которые одновременно работают и учатся. Это, простите, совсем другой уровень взрослости.Они приходят на занятие после рабочего дня. Задают вопросы не «а что будет на зачете», а «а как это применить у нас на проекте». Спорят по делу. Впитывают как губки — реально, ты только начинаешь тему, а они уже дотягиваются до следующей.Огромные трудяги. И это заряжает так, что усталость куда-то девается сама.Отдельно скажу вот что: эта история совсем не про деньги. От слова совсем. Она про то, как ты стоишь перед людьми, которые пришли за знанием, и понимаешь, что тебе есть что им дать. И что тебе это невероятно нравится.Так что да — мне очень нравится выступать и учить. Готовиться — по-прежнему нет 😂 но это уже другая история.А у вас был опыт преподавания? Или, может, наоборот — учились, совмещая с работой? Расскажите, как оно 🤍

Что я поняла, собеседуя аналитиков с зарубежного рынкаЯ тут собеседовала аналитиков из-за рубежа — в основном ребят из Индии и с Ближнего Востока (детали под NDA, так что без имен и явок, только про ощущения). И вот несколько мыслей, которые не дают мне покоя 🙈Инсайт первый: мне НЕ казалось, что наши резюме немного перегруженныеОткрываю российское резюме — и это, простите, роман. Опыт с 2008-го. Каждая обязанность расписана так, будто человек защищает диссертацию: «осуществлял сбор и формализацию требований путем проведения интервью со стейкхолдерами в количестве…». Семь листов. Отдельным блоком хобби. Иногда — фото. Однажды видела резюме, где раздел «о себе» был длиннее, чем весь мой опыт работы.И ты сидишь, листаешь этот эпос, пытаясь найти главное: а что человек-то умеет? Где-то на пятой странице, между «стрессоустойчивость» и «умею работать в команде» можешь что-то найти.А теперь их резюме. Одна страница. МАКСИМУМ две. И там — всё. Сертификаты, достижения, навыки, стек. За 20 секунд ты понимаешь, кто перед тобой и чего он стоит. Ничего не потеряно, ничего лишнего. Я открыла первое такое и поймала себя на дурацкой мысли: «а где остальное?..» А остального нет. Потому что не нужно.И это оказался не формат. Это майндсет. Умение уместить себя на одном листе так, чтобы за тебя все сказали факты, а не количество страниц — это отдельный навык, которому у нас как будто нигде не учат. Мы наоборот растем в убеждении, что чем больше мы напишем, чем подробнее, тем серьезнее получится. Но это же не так, уже после второй страницы хочется закрыть резюме...Инсайт второй, который удивил меня сильнее всего: BPMNНаша родная, самая ходовая нотация. У нас без нее аналитик — не аналитик: это первое, что спрашивают, первое, что просят показать, must-have в любой вакансии на описание процессов.А там? Как будто нет ее. Мировой стандарт, между прочим — и при этом реально мало кто с ним работал вживую.И я проверяла это не на каких-то заковыристых кейсах. Вопросы были — проще некуда. Чем отличается один элемент от другого. Когда использовать какой шлюз. Где событие, а где задача, и почему. Базовая база, которую у нас знает любой джун после первого курса.И вот тут становилось все понятно. Люди плавали на элементарном. Кто-то честно признавался, что работал с сильно упрощенной нотацией — «рисовали блок-схемы, как получалось». Знают, что BPMN существует, слышали название — а настоящего опыта моделирования просто нет.У нас BPMN — базовая гигиена профессии. А там — почти экзотика. И дело, разумеется, не в людях: дело в разных школах подготовки и в том, что на этих рынках просто иначе устроен спрос на нотации. Хотя стандарт один и тот же на весь мир. Оказывается, «мировой стандарт» и «стандарт, которым реально владеют» — это две очень разные истории, и география решает больше, чем кажется.Да, AI в их резюме тоже видно. Причесанные гладкие формулировки — сразу считываются. Но давайте честно: у нас сейчас ровно то же самое, сплошь и рядом. Так что тут мы, наконец, сравнялись 😂С тех пор смотрю на свое резюме (оно у меня тоже то еще увлекательное чтиво 😂) и думаю: а можно ли меня уместить на одном листе? Конечно, можно. Просто у нас так не принято что ли.Сколько листов в вашем резюме — признавайтесь? А с BPMN как — база или экзотика? 🤍

Знаете это чувство, когда открываешь свой же канал и думаешь: «о, а этот человек неплохо писал, куда он делся?» Вот это про меня последние месяцы 🙈Я честно собиралась вести канал. И честно не вела. Но не потому что нечего было сказать — а потому что жизнь набрала такой темп, что на «сесть и сформулировать» просто не оставалось ресурса. Зато накопилось, чем поделиться. Давайте по-честному подведем итоги полугодия — и то, чем горжусь, и то, что провалила.Что получилось 🔥— Завершила многострадальный проект. Тот самый, что тянулся целый год. Были моменты, когда казалось, что он не закончится никогда. Но он закончился — и научил меня большему, чем любой гладкий проект. Уроки из него я уже частично разбирала здесь, так что вы в курсе, какой это был опыт.— Набирала команду англоязычных аналитиков. И это, скажу я вам, совсем другой майндсет. Другой подход к резюме, другая логика интервью, другие ожидания. Отдельная тема, к которой хочу вернуться подробнее — если вам интересно.— Преподавала. Вела курс «Анализ бизнес-процессов» для студентов iSpring. Читала лекции до 21:00, каждые выходные ездила на очные занятия — и получилось супер. И это история получилась совсем не про деньги. Это про что-то другое, и оно того стоило. Тоже поделюсь подробнее.— И ещё преподавала. Неожиданное предложение от Сбер Университета — поучаствовать в обучении их корпоративного клиента. Отличное завершение полугодия. Главный вывод: мне очень нравится выступать. Готовиться — нет 😂 но это уже совсем другая история. Так что зовите меня на выступления, я серьезно.— Спорт. Пока есть силы — участвую в забегах и очень много живу сквошем: кемпы, турниры, тренировки. Неимоверно кайфую, хоть физически иногда бывает тяжело.Что не получилось— Вести канал (ну вы заметили 🙃)— Куча планов, связанных с каналом и комьюнити, тоже мимо (но из хороших новосьей - есть полгода, чтобы наверстать)— Хотела больше выступать на конференциях — но тут компенсировала преподаванием, так что вышли в ноль— Не успеваю читать— Даже рутина с сериалами на английском страдаетИ главное. Я сильно чувствую перегруз. Эти выходные — первые за не знаю сколько месяцев, когда я не работала, никуда не летела (последние 6 недель я летелела куда-то каждую неделю, в Шереметьево была чаще, чем дома), не участвовала в спортивных ивентах. Просто жила. И знаете что? WHOOP всё равно показал recovery 59 😱😭Как жить жизнь-то, не подскажете? 🤍

Продолжая тему выводов из проекта, который вымотал мне все нервы подсветил мне много инсайтов про внутрянку управления проектами, хочу поделиться еще одним выводм: Кажется, самая дорогая ошибка в больших проектах — это не техническая ошибка.А надежда.В моем проекте, на самом деле довольно рано появились тревожные сигналы:— перенос тестовой миграции,— размытые статусы,— отсутствие инструкций,— постоянное «ещё немного времени».Но я не эскалировала это наверх вовремя.Не потому что «скрывала».Не потому что «не понимала риски».А потому что искренне надеялась, что мы сейчас ещё чуть-чуть дожмем — и все выправится. Думаю еще наложилось и то, что для меня это был проект в компании, и по сути не хотелось портить отношения с коллегами эскалациями.Очень опасное состояние для любого project manager.Потому что в этот момент тебе кажется:— ну не хочется поднимать панику раньше времени;— ну команда работает;— ну люди стараются;— ну сейчас ещё пару дней;— ну мы почти у цели.И вот это «почти» может длиться очень долго.А потом наступает момент, когда проблемы уже невозможно компенсировать усилиями отдельных людей.И тогда эскалация все равно случается.Только уже:— в условиях горящих сроков,— эмоционального перегрева,— недоверия,— давления сверху,— и коллективного вопроса:«А почему мы узнаем об этом сейчас?»И вот это, наверное, был один из самых неприятных управленческих уроков для меня.Потому что хорошее управление — это не про создание ощущения, что все спокойно.Это про своевременную прозрачность.Даже если новости плохие.Особенно если новости плохие.Сейчас я гораздо раньше начинаю проговаривать риски.Не когда «все совсем плохо».А когда вижу устойчивый паттерн:— сроки начинают плыть,— нет проверяемого результата,— появляются неизвестные,— команда избегает конкретики,— тесты переносятся,— нет end-to-end картины.Потому что ранняя эскалация создает дискомфорт.Поздняя эскалация создаёт кризис.И это две очень разные цены.