Системно о важном. Системный анализ, карьера, наставничество. Иногда душню — но по делу. Ведущий аналитик ТризТех (Positive Technologies), преподаватель ИТМО, к.т.н. https://tmarkina.taplink.ws/
🔄 Метод «сломаем — а там видно»: почему в ИТ это работает В жизни звучит странно. Сделать хуже, чтобы потом вернуть как было, это как в анекдоте «Заведи козу». В ИТ это называется revert, и это одна из главных «суперсилл» разработки. ❗️Речь не про «выкатил вслепую и молюсь». Речь про «выкатил, зная кнопку отката».
🧠 Как это работает на деле Вы меняете код, требования или конфигурацию. Новое решение казалось хорошим. На практике — всё сломалось. В обычном мире вы бы паниковали. В ИТ вы просто откатываетесь к предыдущей версии. Git, резервные копии, CI/CD позволяют сказать: «Окей, не взлетело. Вернём как было». Ущерб ограничен 10 минутами вместо недели даунтайма.
🎓 Живой пример Одна команда решила переписать старый модуль на новом фреймворке. Потратили месяц. Протестировали на стенде — всё было ок. Выкатили в прод. И поняли: стало хуже. Медленнее. Багов больше. Что сделали? Не стали героически доделывать ночами. Закатили revert за 10 минут. Старый модуль снова работал. Новый отправили на доработку. Потом разобрали ошибки, переписали аккуратно — и выкатили успешно.
⚠️ Но есть нюансы Revert работает отлично, НО не везде. ❌ Когда откат — не тривиален: ➖Миграции баз данных (особенно если удаляли колонки/таблицы) ➖Изменения публичных API, на которые уже подписались клиенты ➖Исправление багов, к которым успели привязаться другие системы В таких случаях revert может вернуть старые проблемы. Тут нужна двойная осторожность.
🚫 Без системы revert превращается в катастрофу Метод работает, только если вы можете быстро вернуть. Что для этого нужно: ✅ Нормальная система контроля версий (git) ✅ Автоматические бэкапы ✅ Культура, где revert — не позор, а норма ✅ Понимание границ метода (см. пункт выше) Если этого нет — «попробовать новое» превращается в недельную аварию.
🧠 А как же страх Многие боятся экспериментировать именно потому, что не знают, как откатить. Но если вы можете быстро вернуться назад — вы можете пробовать смелее. В ИТ это называется безопасная среда для экспериментов. И она строится вокруг простой идеи: «Сломать можно, если умеешь чинить или откатывать. Но сначала проверь, что откат вообще возможен».
🎓 Моё резюме Revert — это не глупость и не «костыль». Это нормальный рабочий инструмент, когда у вас есть система отката. Без системы — авантюра. С системой — разумный эксперимент. Git, бэкапы, понимание границ и смелость пробовать. Всё остальное — детали.
А вы часто откатываете свои решения? Или стараетесь довести до конца любой ценой?👇
🧨 Анализ — это вчера. Аналитика — это завтра. А результат у нас какой? Я уже говорила: я люблю душнить по терминам. Потому что за ними — деньги, сроки и карьера. Первая жертва — пара «анализ» и «аналитика». Кто-то думает, что это одно и то же. В резюме пишут «аналитика», чтобы звучать весомее. В жизни делают анализ и называют его аналитикой. Давайте по полочкам. Со словарями и без розовых очков.
🔍 Что там по сути Анализ (ἀνάλυσις) означает «разложение, расчленение». Анализ (по Далю и современным словарям) — разбор, разложение целого на составные части. Метод научного исследования. Изучаем, что сломалось и почему. Результат — диагноз. Аналитика (ἀναλυτική) — «искусство анализа». Аналитика (по словарю «Грамоты.ру») — деятельность по выполнению анализа; результаты проведённого анализа. Искусство рассуждения с прогнозом. Результат — рецепт. То есть анализ — это действие, аналитика — и деятельность, и результат.
⚡️ Так результат — это анализ или аналитика? Это зависит от того, что вы сделали с данными. 1️⃣ Просто разложили проблему, поняли причину → результат анализа. 2️⃣ Сформулировали прогноз и сказали «делаем так» → результат аналитики. Анализ 🟰 диагноз. Аналитика 🟰 рецепт.
💼 Почему я проверяю это на собеседовании Спрашиваю на собеседовании: «Чем вы занимались?» — Аналитикой. — Прогнозы строили? Модели? Сценарный анализ? — Нет, я данные разбирал и отчёт писал. Окей. Это анализ. Называйте вещи своими именами.
🎓 Моё резюме для вас Анализ 🟰 расчленили. Аналитика 🟰 придумали, что делать дальше. Анализ 🟰 прошлое. Аналитика 🟰 будущее. Анализ 🟰 диагноз. Аналитика 🟰 рецепт.
Что вы чаще делаете: ставите диагнозы или выписываете рецепты? 👇
«Собака сутулая»: как мем помогает диагностировать выученную беспомощность в команде
📖 Контекст. Фраза пошла из скандала на «Доме-2» (для меня это было открытие), но прочно осела в ИТ-фольклоре. Мне всегда было интересно его происхождение...
🔍 В чем суть антипаттерна «Собака сутулая» — это не про код, а про мета-состояние системы (команды или конкретного сотрудника). Это смесь: — Выученной беспомощности (Learned Helplessness), — Пассивной агрессии, — Технического долга, доведенного до абсурда. Три лика антипаттерна: ✅ Подавленный сотрудник. Соглашается на всё, не спорит, но горит в ноль. ✅ Скрытый саботажник. «Сутулится», делает вид, что старается, а сам тянет время. ✅ Легаси-код. Кривой, страшный, но работает («горбатый, как та собака»).
⚠️ Как лечить В отличие от классических антипаттернов, здесь нельзя просто «переписать модуль». Нужно снимать давление, возвращать команде чувство контроля и разрешать открыто говорить о проблемах.
Вывод: Если на ретроспективе кто-то сказал «у нас тут собака сутулая» — не смейтесь. Спрашивайте: кто или что ее таким сделало?
📚 Как учить hard skills, чтобы не выгореть Не думайте, если вы senior, то вам не надо ничему учиться, вспомнить как это делать - всегда полезно!
1️⃣ Берите один инструмент и доведите до простого «умею» Не хватайтесь за Python, SQL, Docker и Kubernetes одновременно. Выберите одно. Освойте базу. Сделайте маленький проект. Потом — следующее.
2️⃣ Учите через задачу, а не через «прочитать всё» Не «выучить SQL за 3 дня», а «написать запрос, который покажет топ-10 продаж за месяц». Результат → понимание.
3️⃣ 20 минут в день лучше, чем 5 часов в выходной Регулярность важнее интенсивности. Маленькие шаги не пугают и не убивают мотивацию.
4️⃣ Делайте проекты для себя Свой телеграм-бот, парсер расписания, аналитика расходов в Google Sheets. Бесплатно, безопасно, и портфолио растёт.
5️⃣ Просите обратную связь у тех, кто уже умеет Показали код или схему коллеге? Спросите: «Что здесь не так?». Исправили — навык прокачался. Не стесняйтесь.
🛠 Hard skills — это ваш инструмент. А не магия Потерпите ещё "прописные истины", я определяю объекты, чтобы потом в них углубиться Hard skills — это конкретные задачи, которые вы умеете делать.
🔴 Разработчик: писать на Python, работать с Git, знать SQL. 🟠 Тестировщик: составлять тест-кейсы, работать с Jira, понимать API. 🟡 Аналитик: рисовать BPMN, писать ТЗ, строить диаграммы. 🟢 DevOps: настраивать CI/CD, работать с Docker, поднимать серверы.
‼️Их главная особенность: их можно проверить.
Дали задание 👉 посмотрели результат. Справились ✅ навык есть. Не справились ❌ качаем дальше.
❗️И главное Hard skills без Soft skills — вы умеете, но не понимаете зачем и не можете договориться. Soft skills без Hard skills — вы отлично общаетесь, но делать нечего Вам в профессии.
Прокачивайте и то, и другое. Но если вы на старте — начинайте с hard. Их проще проверить, легче продать на собеседовании и быстрее получить первые «я это умею».
🐧 Git — 21 летний мерзавец, который захватил мир 7 апреля 2005 года Линус Торвальдс закоммитил первую версию Git. Ему потребовалось около двух недель. Название git на британском сленге означает «мерзавец». Сам Торвальдс пошутил: «Я эгоистичный ублюдок, поэтому называю проекты в честь себя. Сначала Linux, теперь git».
⚡️ Зачем его создали Разработчики ядра Linux использовали коммерческую систему BitKeeper. Бесплатно. Но с условием: никакого реверс-инжиниринга. Один из разработчиков Эндрю Триджелл попытался создать открытый клиент — и владелец BitKeeper отозвал лицензию. Linux-команда осталась без инструмента. Торвальдс сел и написал Git.
🔧 Почему Git выстрелил Главная идея: каждый разработчик имеет полную копию репозитория — можно работать офлайн, не бояться падения сервера. Альтернативы (CVS, SVN) были централизованными: один сервер упал — все встали. Сегодня Git занимает 85% рынка систем контроля версий.
🎭 Git нужен не только разработчикам 🟡 Аналитику — хранить версии ТЗ, требований и моделей. Увидеть, кто и когда изменил требования. Откатиться к старой версии, если заказчик передумал. 🟠 Тестировщику — синхронизировать автотесты, хранить тест-кейсы в коде, фиксировать баги вместе с разработкой. 🟢 DevOps'у — управлять конфигурациями, скриптами и инфраструктурой как кодом. 🔵 Проект-менеджеру — смотреть историю изменений документации, видеть, кто что делал, и контролировать версии артефактов. 🟣 Руководителю — проверять, как команда работает с версиями, и не терять артефакты проекта. Git — это не про код. Это про совместную работу над любыми текстовыми файлами (код, документация, настройки).
🎓 Что это значит для вас История Git учит: даже временный костыль может изменить мир, если он решает реальную боль.
А какой у вас любимый git-команда? У меня — git blame 😉
🤝 Soft skills: что прокачивать, чтобы расти В ИТ любят говорить про soft skills. Но часто под этим понимают «быть приятным человеком». На самом деле "мягкие навыки" — это конкретные инструменты, которые можно и нужно развивать.
Какие soft skills реально нужны (не пишите, что только аналитику): 1️⃣ Умение задавать вопросы Не просто «что? где? когда?», а: «А что будет, если...?», «А как мы это проверим?», «А кто за это отвечает?» Хорошие вопросы иногда важнее хороших ответов.
2️⃣ Навык письменной коммуникации В удалёнке 80% общения — текст. Если вы пишете длинно, путано или с ошибками — вас перестают читать. Короткие предложения, сценарии вместо функций, картинки вместо текста — это навык, который прокачивается.
3️⃣ Умение слушать Заказчик говорит «хочу понятный интерфейс». Вместо того чтобы спорить, спросите: «А что для вас "понятный"? Приведите пример». Услышать, что на самом деле нужно, — половина работы.
4️⃣ Управление ожиданиями Сказать «нет» или «это будет через месяц, а не через неделю» — нормально. Главное — сделать это до того, как срок сорван.
5️⃣ Эмпатия Поставить себя на место заказчика, разработчика, тестировщика. Понять, почему они спорят, и найти решение, которое устроит всех.
❗️Главное: Soft skills — это не «чтобы все любили». Это чтобы вас понимали, слышали и доверяли вам.
🔺Викинги В науке викинг — это скандинав, отправившийся в грабительский поход. Но термином стали называть всех скандинавов — включая тех, кто сидел дома и пахал землю. Историки спорят до сих пор.
🔺Киевская Русь Термин, который кажется естественным, создаёт политические споры: «была ли эта Русь российской, украинской или белорусской?» Хотя раннесредневековое государство — предок всех трёх народов. Как Империя франков не была ни Францией, ни Германией.
🔺Фашизм и нацизм Строго научно фашизм — это режим Муссолини. Но в массовом сознании термин закрепился за нацизмом Гитлера.
🔗 Нетворкинг в ИТ: не для «понтов», а чтобы работу делать
Многие думают: нетворкинг — это для менеджеров и продажников. А я — технический специалист, мне достаточно знать своё дело. Люблю нетворкинг, так я побывала на афтепати конференции, на которой не была... В ИТ без связей — можно. Но медленно, больно и скучно.
Нетворкинг нужен, чтобы: 1️⃣ Быстрее решать задачи Застряли на проблеме? Написали в чат — через час у вас есть решение. Без связей — два дня искать самому. 2️⃣ Узнавать о вакансиях первыми Хорошие места разбирают по знакомству, не дожидаясь публикации. 3️⃣ Не выгорать в одиночку Есть с кем поделиться трудностями и услышать «у меня тоже такое было, вот что помогло».
🪄Никакой магии. Просто работа и жизнь становятся легче, когда вы не один. Был ли у вас случай, когда знакомство в ИТ спасло проект или карьеру? 👇
❤️🩹 ИТ — это не только печеньки. Вот 7 причин не бросить вот это всё Все мечтают в ИТ, а курсы продают рай: высокие зарплаты, удалёнка, никакой рутины. Давайте без розовых очков.
1️⃣ Никогда не отключаешься по-настоящему Сообщение в 22:00 от заказчика: «Срочно…». Коллега из другого часового пояса в субботу утром. Без жёстких границ вы выдохнетесь за полгода. 2️⃣ Учиться постоянно — не для роста, а чтобы оставаться на месте Выучил стек — через два года он устарел. Выходные уходят на курсы и статьи. Иногда это кайф, чаще — рутина. 3️⃣ Вы работаете с людьми, а не с кодом Заказчик не знает, чего хочет. Разработчики спорят. Тестировщики находят косяки. Главная боль — коммуникация, а не технологии. 4️⃣ Глаза и спина страдают 10 часов за монитором — и вы вспомните этот пост. Плохое зрение, шея, сидячий образ жизни. Хорошее кресло и физкультура — не роскошь, а необходимость, чтобы выжить. 5️⃣ Высокая ответственность при неполной информации «Сделайте хорошо» — и всё. Вы добываете требования, переспрашиваете, перепроверяете. А если угадали не так — виноваты вы. 6️⃣ Выгорание — это реальность Дедлайны, смена требований, бесконечные доработки. ИТ — марафон. Если бежать спринт каждый день — долго не протянете. 7️⃣ Зарплата растёт не всегда Джунам сейчас тяжело. Конкуренция высокая. Это не значит «не иди в IT». Это значит «не верь обещаниям 300к за полгода».
Что делать с этим всем⁉️ Не бояться, а готовиться❗️ Минусы никуда не денутся. Но если вы готовы их терпеть — профессия даст вам очень много. ИТ — это не магия. Это работа. Хорошая, если заходить с открытыми глазами.
🤔 Аналитик, разработчик, тестировщик: как не ошибиться На собеседованиях я часто видела кандидатов, которые «пробовали и то, и это, и ещё немного верстали». За этим обычно стоит страх ошибиться с выбором. Давайте честно: три основные роли в разработке требуют разного склада ума. Есть ещё много не менее важных ролей,но мы пока посмотрим эти три. ☝️ Кто есть кто (Роль — Что нужно) Аналитик — Системно мыслить, любить общаться, писать понятно Разработчик — Любить алгоритмы, уметь концентрироваться, не бояться ошибок Тестировщик — Быть внимательным к деталям, любить искать неочевидное, не обижаться, когда ломают 🔍 Как проверить себя Попробуйте написать простой скрипт. Если процесс захватывает и вы готовы сидеть над ним часами — присмотритесь к разработке. Попробуйте найти ошибки в чужом коде или интерфейсе. Если видите то, что другие пропускают, и вам это даже нравится — присмотритесь к тестированию. Попробуйте объяснить сложную вещь простыми словами и нарисовать схему. Если получается и приносит удовольствие — вам к анализу. ‼️ Границы размыты. 🟡 Аналитик может писать SQL. 🔴 Разработчик — тестировать свой код. 🟠 Тестировщик — автоматизировать. Но базовый склад ума всё равно разный. Попробовать можно всё. Остаться стоит в том, где вам не нужен выходной после трёх часов работы. Какую роль пробовали первой? И совпало ли? 👇
🚫 Чем системный аналитик НЕ занимается (спойлер: многим)
На собеседованиях я часто слышу: «Я писал ТЗ, рисовал прототипы, тестировал готовые фичи, общался с заказчиками, иногда верстал…» Стоп❗️ Это уже три разные профессии или человек не понимает о чём говорит...
Системный аналитик ❌ Не UI/UX-дизайнер Да, мы участвуем в проектировании интерфейсов. Но рисовать кнопочки и подбирать отступы — не наша задача. Наша задача — описать, какие элементы управления нужны и зачем. ❌ Не тестировщик Мы можем проверить, соответствует ли реализация требованиям. Но прогонять регресс и писать тест-кейсы... ❌ Не разработчик Мы должны понимать архитектуру и уметь писать простые SQL-запросы. Но писать код за разработчиков... ❌ Не проект-менеджер Мы не ставим сроки по разработке фичи и не мотивируем команду. Мы отвечаем за содержание, а не за процесс. А что думаете Вы❓
Границы часто размываются, но важно понимать: если Вы делаете всё сразу — Вы не просто системный аналитик, Вы супермен! Описание других ролей в разработке в следующих постах
🔸 Рогатый Моисей Переводчик Библии спутал «лучи» с «рогами». Итог: 1000 лет христиане молились на пророка с рогами. Микеланджело сделал статую — тоже с рогами.
🔸 Остров-призрак Картографы услышали от испанцев слово «порос» (проливы) и нарисовали остров. 150 лет пираты искали землю, которой нет.
🔸 Физика или бомба Ферми назвал расщепление урана «новыми элементами». Мир потерял не один год на понимание ядерной реакции. Гитлер мог получить бомбу первым.
🔸 Сгоревший зонд NASA написало в ТЗ «сила». Инженеры поняли: одни — в ньютонах, другие — в фунтах. Миллионы долларов ушли в атмосферу Марса.
Одно слово = миллиарды, территории и рога на голове пророка.
🔝 Системный анализ — это не про анализ, а про мышление
Когда спрашивают, чем занимаются системные аналитики, я отвечаю коротко: «Системным анализом». В ответ — вежливое кивание и вопрос в глазах: «А что это вообще значит?» В учебниках пишут сложно: методология исследования сложных проблемных ситуаций. Слишком сложно о простом...
На самом деле системный анализ — это способ не заблудиться в сложном. Это когда: 🔸задача кажется огромной, а вы раскладываете её на куски 🔸заказчик говорит одно, а хочет другое — и вы это слышите 🔸все спорят, а вы рисуете схему — и спор заканчивается
Что внутри профессии: 🔹 Собирать требования (и не пропустить важное) 🔹 Строить модели (UML, BPMN, ER-диаграммы) 🔹 Договариваться между бизнесом и разработкой 🔹 Писать документацию так, чтобы её читали 🔹 Видеть систему целиком, даже когда все смотрят в детали
Системный анализ — это не про то, чтобы знать ответы. Это про то, чтобы задавать правильные вопросы. 🔜 В следующих постах разберём каждый инструмент отдельно.Если интересно — ставьте 🔥, чтобы не пропустить.
1931 год. Австрийский инженер Ойген Вюстер устал от того, что инженеры из разных стран не понимают друг друга. Чертежи, спецификации, переводы — вечная путаница. Он пишет книгу «Международная стандартизация речи в технике». Это считается рождением терминоведения.
В то же время в СССР инженер Дмитрий Лотте сталкивается с той же проблемой. На заводах одни детали называют по-разному. Техническую литературу переводят хаотично. Он начинает систематизировать терминологию — и закладывает основы отечественной школы.
Что они придумали ✅ Один термин = одно понятие ✅ Одно понятие = одно название ✅ Термин должен отражать суть ✅ Термин должен вписываться в систему
Сегодня в ИТ та же ситуация, что в технике 1930-х: проекты сложные, команды распределённые, языки смешанные. Только тогда это мешало строить заводы, а сегодня — строить карьеру.
Терминоведение — это не скучная лингвистика. Это наука, которая родилась из практических проблем инженеров.
Вот что она изучает: 🔹 Теоретическое — как вообще живут термины 🔹 Прикладное — как их упорядочивать и переводить 🔹 Историческое — откуда они взялись 🔹 Семасиологическое — что они значат 🔹 Когнитивное — как термины влияют на мышление
Для нас важнее всего прикладное. Это про: 🔸 устранение путаницы 🔸 унификацию 🔸 редактирование документации 🔸 перевод с языка на язык
Терминоведение — не про занудство. Это про скорость, точность и деньги.
В биологии класс насекомых по-латыни Insecta. Название дали из-за насечек на теле. В XVIII веке русские переводчики перевели *in-* как отрицание. Получилось «несекомое» — то, что нельзя сечь. 🪰 И это слово использовали! В журналах 1757 года писали: «О некоторых несекомых, кои полезны к крашению». 🪳
Потом язык сам всё исправил. Люди услышали в слове «насекомое» связь с «насечками» — и вариант закрепился.
Что это значит для нас В ИТ множество таких же "случайных" терминов: ❌ Функционал — математический термин, который используют неправильно, а также есть в сексологии ❌ Аналитика — путают с анализом ❌ Юзабилити — хотя есть русское «удобство»
Они стали нормой, но важно понимать где и как использовать эти термины. Знать их историю полезно — чтобы не попадать в ловушки и не показывать свой непрофессионализм.
