Карьера в IT-индустрии

14 открытых уроков для бэкенд-разработчиков

Привет, Хабр. Делимся подборкой бесплатных уроков, которые скоро пройдут в Otus. Опытные практики проведут занятия онлайн — вы сможете узнать больше о формате обучения и задать вопросы экспертам. Выбирайте свою тему и присоединяйтесь.

• 24 февраля 20:00. «Работа с реляционными БД: от ADO.NET до EF Core». Записаться
  ^{Открытый вебинар курса «C# Developer. Professional»}

• 24 февраля 20:00. «Первые шаги в Java». Записаться
  ^{Открытый вебинар курса «QA Automation Engineer»}

• 24 февраля 20:00. «Создание микросервиса». Записаться
  ^{Открытый вебинар курса «Архитектура и шаблоны проектирования»}

• 25 февраля 20:00. «Знакомство с Rust. Первые шаги». Записаться
  ^{Открытый вебинар курса «Rust Developer. Basic»}

• 25 февраля 20:00. «Каналы Go без пробок и утечек». Записаться
  ^{Открытый вебинар курса «Golang Developer. Professional»}

• 25 февраля 20:00. «Разработка REST API на Laravel». Записаться
  ^{Открытый вебинар курса «Framework Laravel»}

• 26 февраля 20:00. «JDBC — ваш швейцарский нож для работы с данными». Записаться
  ^{Открытый вебинар курса «Java Developer. Professional»}

• 2 марта 20:00. «Изучаем Java с нуля на примере простой консольной игры». Записаться
  ^{Открытый вебинар курса «Java-разработчик»}

• 4 марта 20:00. «Саги vs распределённые транзакции: как моделировать рабочие потоки в распределённой архитектуре». Записаться
  ^{Открытый вебинар курса «Domain Driven Design и асинхронная архитектура»}

• 5 марта 20:00. «Знакомство с Kotlin: пишем первый код». Записаться
  ^{Открытый вебинар курса «Kotlin Developer. Basic»}

• 10 марта 20:00. «Реализация простого HTTP сервера на Java». Записаться
  ^{Открытый вебинар курса «Java-разработчик»} 

• 10 марта 20:00. «Дженерики в Go: от синтаксиса до смысла». Записаться
  ^{Открытый вебинар курса «Golang Developer. Professional»}

• 10 марта 20:00. «Мультитенантная архитектура в Laravel: как масштабировать проекты под десятки и сотни клиентов». Записаться
  ^{Открытый вебинар курса «Framework Laravel»}

• 11 марта 20:00. «Сообщения, которые не теряются: Брокеры против хаоса в Java». Записаться
  ^{Открытый вебинар курса «Java Developer. Professional»}

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

Интенсив для будущих AI‑тренеров с офером в Яндекс Крауд

AI-тренер — это специалист, который обучает нейросеть генерировать корректные, грамотные и релевантные запросам пользователя ответы.

Приглашаем на интенсив от экспертов Яндекса — и новичков, и тех, у кого уже есть опыт. Лучших позовём в команду, которая обучает нейросети Alice AI (Алиса, Яндекс, Поиск).

Набираем два потока:

• I поток: встречи пройдут 28 февраля и 1 марта. Успейте подать заявку и выполнить короткое тестовое до 25 февраля. 

• II поток: встречи пройдут 14 и 15 марта. Подать заявку и выполнить тестовое можно до 11 марта. 

Участие возможно только в одном потоке. Все встречи пройдут онлайн, по московскому времени. Каждый участник по завершении интенсива получит промокод на Яндекс Маркет номиналом 3000 рублей.

→ Подробнее по ссылке.

Представлен открытый и бесплатный фундаментальный курс по OpenClaw, включая весь материал на русском языке с полным описанием процессов установки, настройки, использования и полноценной кастомизации ИИ-бота под свои задачи.

Когда задача считается выполненной

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

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

Мы поговорили с коллегами и попросили их рассказать, в какой момент для них задача считается завершенной. Их ответы читайте ниже.

Настя, тестировщик:

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

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

Ваня, системный аналитик:

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

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

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

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

Олег, android-разработчик:

Задача выполнена, когда:

1. Функциональность реализована и проверена вручную — примерно так, как это сделал бы тестировщик, но без учета конкретных тест-кейсов.

2. Новое поведение решает цель задачи, а не просто повторяет постановку. Иногда по ходу работы находится вариант проще для разработки/поддержки или удобнее для пользователя — выбираю его. Фича должна закрывать потребность.

3. Пограничные случаи поведения (corner cases) проработаны и учтены. В постановке не всегда учитываются моменты, которые становятся заметны в коде. Например, что показать на мобильном клиенте при 500 ответе сервера или при долгой загрузке из-за задержки ответа сервера.

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

5. Новое поведение поддерживаемо и расширяемо: его сможет понять и продолжить другой разработчик.

Выбор вакансии: как я кинулась во всё — и это не дало результата.

Есть разработчики, у которых развитие идёт линейно и предсказуемо: верстальшик → джун фронтендер → мидл → мидл в сильной компании → сеньор/лид/уход в бэкенд

Красиво. Понятно. Логично.

Но у меня кривая черта развития сначала бэк на Java в закрытом предприятии. Потом фулстек в фудтехе: в основном Vue, но ещё и Go (и все сопутствующее), и CUBA Platform (lowcode на java, он же «Тезис»), и n8n.

Широко. Разнообразно. Интересно.

Как я начала откликаться - на всё, что блестит

И сейчас Когда я вышла на рынок, то сначала я откликалась на все что близко:

1. Frontend - Vue / React / Angular
   Ну фронт же. Есть мнение, что «не нужно учить конкретный фреймворк — важны принципы».

2. Go
   а почему бы нет? Знаю , умею , курсы закончены, писала на нем

3. Fullstack (Go или JDK + фронт)

4. N8N, автоматизаторы особенно с ИИ
   Интересно. Растущее направление.

5. Lowcode платформы CUBA, тезис, WebTutor - замаскированный под фронтенд Опыт есть. Почему не использовать?

И это фатал еrror

1. Ошибка №1. Переключение контекста
   Очень сложно переключать контекст и даже синтаксис языка - на первом собесе по TS я не смогла вспомнить синтаксис (на ум приходил только java, так как он изучался более долго и в закрытой среде, ирония: хоть я на нем и не пишу, но разбуди среди ночи - код напишу)

2. Ошибка №2. Рынок
   Рассматривать вакансии на Angular, React без опыта в продакшене - на данный момент наивно.
   
   Рынок перегрет:
   - Vue ~ 1000 откликов за неделю,
   - React - 4000 ,
   
   Неужели Арина (или тот кто читает эту статью) ты думаешь, что кто-то будет рассматривать ваше резюме со Vue? Каким бы в целом хорошим инженером вы не были. Рынок не покупает «в целом».

3. Ошибка №3. Fullstack со связкой Go + Vue или JDK + Vue
   Фуллстеки со связкой go или jdk - это бред вакансии, это карьерный тупик.
   - PHP + Vue - норм
   - Node + Vue - норм,
   но Go + Vue - это нонсенс, это только подработка для поддержания штанов. Чаще это небольшие команды, поддержка, нестабильные проекты.

4. Ошибка №4. n8n — нравится, но это уже не совсем разработка
   Автоматизация, интеграции, AI — это интересно. Но это больше аналитика и orchestration, чем классическая инженерия. Если хочешь быть разработчиком — нужно понимать, куда ты смещаешь фокус.

5. Ошибка №5. Low-code — карьерный тупик
   Проблем с окружением больше. Кода меньше. Рынок уже. Ты становишься зависимой от конкретной платформы. И выйти обратно в «чистую разработку» становится сложнее.

Мой Hotfix: Фокус

Я поняла, что на падающем рынке выживают либо "универсалы" c ИИ подбоком, либо эксперты

Моя новая стратегия:

• Vue 3 + TypeScript + Nuxt (как зона роста)

• n8n — как подработку и интересный дополнительный навык.

Иногда рост — это не добавить ещё стек. А убрать лишнее.

Представлен открытый проект Antigravity Awesome Skills: 864+ Agentic Skills for Claude Code, Gemini CLI, Cursor, Copilot & More с большим количеством навыков для ИИ‑агентов. Такая база помогает автоматизировать работу Claude Code, OpenCode, Gemini, Codex, Antigravity, Copilot, Cursor и других, включая райтинг, кодинг, аналитику, генерацию картинок и видео, создание презентаций, работу с таблицами, SEO, создание сайтов. Авторы проекта внедрили понятный поиск, настроить агентов можно без знания кода.

От джуна к сеньору в верификации: как расти

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

Алексей Ковалов, руководитель отдела модульной верификации YADRO, в статье рассказал, как на практике происходит рост от джуна до сеньора. И начинается все с базовых вещей. Команда Алексея использует принцип  «15–45»: 15 минут попробуй разобраться сам, но если за 45 не сдвинулся — иди к ментору. Самостоятельность важна, но умение вовремя эскалировать проблему — это уже признак зрелости.

Внутри статьи:

• почему «вечный мидл» — это не миф, а распространенный сценарий,

• как меняется тип задач при переходе между грейдами,

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

• как не утонуть в покрытии и научиться оценивать объем работы заранее.

Если откликается описанный подход к росту, сейчас хороший момент присоединиться к команде YADRO. Мы открыли Sprint Offer для RTL- и UVM-инженеров. Подать заявку можно до 22 февраля. 

Инженеры занимаются fabless-разработкой микропроцессоров на базе RISC-V — полным циклом от собственного процессорного IP до системного ПО. Работают с IP, SoC, беспроводными системами и высоконагруженными архитектурами.

Какие скилы будущего пора осваивать уже сейчас — расскажет лид UX-исследований!

На следующей неделе нас можно встретить не только в твоей ленте, но и на UX/UI Conf. Наш Research lead Настя Дюрягина выступит с докладом «Расти без инструкций: навыки, которые открывают новые роли и возможности для роста проектировщика». 

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

Когда: 28 февраля в 13:40 (поток «Тренды & Карьера»)
Где: Москва, 3-я ул.Ямского поля, 26а (и онлайн)

Больше информации о мероприятии найдешь здесь ;-)

Пользователь отправил своего ИИ-аватара на собеседование к ИИ-рекрутеру. В итоге они просто хвалили друг друга и одобряли очень долго, пока время не закончилось интервью с логом в 14 страниц.

Дизайнер Apple показал, как дизайн-студия Apple выглядит в реальности (дизайнеры работают не за Pro Display XDR или MacBook, а за мониторами LG) и в маркетинговых материалах (слева).

Во что я верю, когда меня спрашивают про карьеру в IT

Время сейчас такое... Мой знакомый разработчик (20 лет в профессии) года три назад еще и представить себе не мог, что будет целый год искать работу и не получит ни одного офера. Ну ок, там возраст, но он далеко не один в такой ситуации. Я так давно уже не верю в то, что кто-то обо мне позаботится, кроме самого себя. 

Похоже на то, что в следующие 3-4 года в айти произойдут большие изменения. Когда меня спрашивают, что сделать и как к этому подготовиться, в ответ я могу сказать лишь то, во что верю сам.

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

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

3. Проблемы не исчезают, они усложняются. Спрос на решения реальных проблем (безопасность, облачная инфраструктура, данные, плюс все человеческие потребности, хотелки, страхи) будет расти.

4. Довольно долго еще не будет одного ИИ-решения для всего, условного GPT-бога или GPT-джина.

5. Контроль важнее стабильности. Работа в найме это иллюзия безопасности, которую может разрушить один мейл от HR. Участие во владении продуктом это владение инструментом создания ценности, а не зависимость от чужого решения о твоей ценности.

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

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

8. Ставка это не хобби после работы, и не пет-проект между кофейней и спортзалом. Ставка это когда ты фигачишь так, как будто от этого зависит все твое будущее, пусть даже только пару-тройку дополнительных часов в день.

9. Человеку в одиночку гораздо сложнее построить устойчивый дом или компанию, чем команде людей. 

10. Выбирай команду не только по целям, но и по ценностям.

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

На рынке сейчас царит жуткая путаница между совершенно разными AI-QA-ролями.
Получилось так, что я прошла через все три роли.
Если вы планируете карьерный переход, то вот в чем разница между ними:

1️⃣ QA Engineer с инструментами ИИ
Цель: Эффективность.
Реальность: Вы тестируете традиционный детерминированный продукт. Вы просто используете ChatGPT для генерации тест-кейсов или Cursor/Claude Code для автоматизации. Это «вайб-кодинг» для старых добрых задач.

2️⃣ AI QA Engineer
Цель: Базовая проверка интеграции.
Реальность: Тестирование того, как чат с LLM работает внутри условной CRM-системы. Вы проверяете, вежлив ли бот и не «поехал» ли интерфейс. Вы всё ещё используете ассерты (asserts), просто с небольшим «привкусом» нейросетей.

3️⃣ ML Evaluation Engineer (Инженер по оценке ML-моделей)
Цель: Управление хаосом в недетерминированных моделях.
Реальность: Вы не используете ассерты; вы используете статистические метрики.
Инструменты: Фреймворки для оценки (например, LM Evaluation Harness), модули метрик на Python.

Почему третий вариант — это совсем другое:

• Вероятность > Детерминизм: Вы не проверяете, что . Вы проверяете, является ли показатель метрики 0.87 приемлемым для вашего конкретного сценария.

• Стоимость как метрика: В ML Eval затраты токенов так же важны, как задержка (latency). Если ваш агент «умный», но стоит $2 за запрос — вы провалили тест.

• Скорость решает всё: Здесь быстрая 7B-модель может выиграть у медленной 70B. Тестирование производительности здесь не «доп. опция», а база.

КОРОТКО
Традиционный QA = Поиск дефектов.
ML Evaluation = Измерение неопределенности.

36 демо-занятий недели: развиваем актуальные навыки в IT

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

16 февраля, понедельник:

• 20:00. Безопасность КИИ в 2026: обзор последних изменений требований и ответственности — Записаться

• 20:00. Реализация паттерна CQRS с использованием библиотеки MediatR и ASP.NET CORE — Записаться

• 20:00. Продвинутое структурирование промптов: как получать предсказуемый результат — Записаться

• 20:00. Roadmap внедрения DevSecOps. Роли, цели, сроки — Записаться

• 20:00. Тестирование в бэкенде — Записаться

• 20:00. Роль бизнес-аналитика в процессах тестирования и контроля качества — Записаться

• 20:00. Навыки продуктового аналитика в 2026 году — Записаться

• 20:00. Моки в автотестировании на python — Записаться

17 февраля, вторник:

• 18:00. Основы RAG и Fine-Tuning. Учим приложение отвечать на вопросы в контексте ваших документов — Записаться

• 20:00. Основы безопасности в Kubernetes — Записаться

• 20:00. Class Data Sharing и его перспективы — Записаться

• 20:00. Обзор фреймворков для создания агентов — Записаться

• 20:00. Стенды для нагрузочного тестирования — Записаться

• 20:00. Запуск Python-приложения в Docker: FastAPI и база данных — Записаться

• 20:00. AI для HR: меньше рутины, больше влияния — Записаться

• 20:00. Жалобная жалоба. Или как работать с недовольными клиентами — Записаться

• 20:00. Храним данные в приложении правильно, SwiftData — Записаться

• 20:00. Custom Hooks в React — как выносить логику и переиспользовать код — Записаться

18 февраля, среда:

• 18:00. Оркестрация data-pipelines с помощью Prefect — Записаться

• 20:00. Почему все переходят на Kotlin? Секреты успешной миграции с Java для бэкенд-разработчиков — Записаться

• 20:00. Lovable для Product Manager’а: от статичной картинки к кликабельному прототипу с логикой — Записаться

• 20:00. Паттерны системы декомпозиции на микросервисах — как проектировать масштабируемую архитектуру — Записаться

• 20:00. Поиск аномалий во временных рядах: за рамками трех сигм — Записаться

• 20:00. Знакомство с Vue.js: основы для начинающих — Записаться

• 20:00. Описываем Use Case на примере сервиса доставки — Записаться

• 20:00. Паттерны декомпозиции сервисов — Записаться

19 февраля, четверг:

• 20:00. DDoS-инцидент: как действует CISO — Записаться

• 20:00. С++ под капотом: что стоит за кодом, который мы пишем — Записаться

• 20:00. Rust: безопасная память без сборщика мусора — Записаться

• 20:00. Kafka без магии: практический разбор для питонистов — Записаться

• 20:00. 5 задач аналитики, с которыми поможет AI — Записаться

• 20:00. ИТ-конвейер 1С на EvaDev — Записаться

• 20:00. Многопоточность в Golang с нуля — Записаться

• 20:00. Способы обмена данными между приложением и драйвером — Записаться

• 20:00. Битрикс24 + MAX: разработка чат-ботов и автоматизация коммуникаций — Записаться

• 20:00. Находим баги онлайн — Записаться

Еще больше бесплатных уроков от преподавателей курсов можно посмотреть в календаре мероприятий.

Anthropic выпустила 6 бесплатных курсов по ИИ, включая 300 лекций, интерактивные квизы и сертификаты за прохождение:

• Работа с Claude API — ссылка.

• Введение в MCP — ссылка.

• Claude с Amazon Bedrock — ссылка.

• Claude с Google Cloud (Vertex) — ссылка.

• MCP для продвинутых — ссылка.

• Claude Code в действии — ссылка.

Открытый проект Internet Archive Downloader позволяет скачать книги, статьи, монографии и исследования с The Internet Archive. Позволяет загрузить: книги, сборники, статьи, монографии, исследования. Можно качать сразу несколько книг одновременно и вообще не терять в скорости. Простой и понятный интерфейс. Устанавливается за один клик — есть подробная инструкция. Работает локально на ПК.

Открытый проект Cheat-Sheets предоставляет учебны материалы для Python, Rust, Swift, JavaScript, Kotlin, Go, Git, и других проектов. Там есть все важнейшие концепции, правила, стили программирования, фреймворки, библиотеки и прочее. Внутри также курсы по Git, Docker, базам данных, а также алгоритмам. Все материалы разделили по уровням сложности, к каждой главе есть контрольные вопросы и десятки задач. Все концепции авторы объясняют на конкретных примерах и разжевывают до последней строчки кода.

13 бесплатных уроков по AI и ML в феврале

12 февраля:

• 20:00 — Почему AI уверенно врёт в аналитике и как его поймать. Записаться
  Открытый вебинар курса «AI для аналитики и работы с данными».

16 февраля:

• 20:00 — Продвинутое структурирование промптов: как получать предсказуемый результат. Записаться
  Открытый вебинар курса «Промпт-инжиниринг: внедрение ИИ в бизнес-процессы».

17 февраля:

• 18:00 — Основы RAG и Fine-Tuning. Учим приложение отвечать на вопросы в контексте ваших документов. Записаться
  Открытый вебинар курса «AI-агенты: продвинутое внедрение и использование».

• 20:00 — Обзор фреймворков для создания агентов. Записаться
  Открытый вебинар курса «AI-агенты: продвинутое внедрение и использование».

18 февраля:

• 18:00 — Оркестрация data-pipelines с помощью Prefect. Записаться
  Открытый вебинар курса «Data Engineer».

• 20:00 — Поиск аномалий во временных рядах: за рамками трех сигм. Записаться
  Открытый вебинар курса «Machine Learning. Advanced».

19 февраля:

• 20:00 — 5 задач аналитики, с которыми поможет AI. Записаться
  Открытый вебинар курса «AI для аналитики и работы с данными».

24 февраля:

• 20:00 — Извлечение признаков из временных рядов. Записаться
  Открытый вебинар курса «Machine Learning. Professional».

• 20:00 — Разработка 2026: эра агентов, MCP и программирования на уровне смыслов. Записаться
  Открытый вебинар курса «AI для разработчиков».

25 февраля:

• 20:00 — Data Drift в машинном обучении: почему модели деградируют в продакшене и как это контролировать. Записаться
  Открытый вебинар курса «MLOps».

• 20:00 — Как выглядит DWH в реальных компаниях: финтех, e-commerce, маркетплейсы. Записаться
  Открытый вебинар курса «Data Warehouse Analyst».

26 февраля:

• 18:00 — Локальное окружение для начинающего ML-инженера. Записаться
  Открытый вебинар курса «Machine Learning».

• 20:00 — Продвинутые техники RAG и введение в GraphRAG. Записаться
  Открытый вебинар курса «NLP. Advanced».

Мы уже рассказывали про бесплатную онлайн-предстажировку по виртуализации и импортонезависимым платформам на базе KVM для старта карьеры в крупной компании. А сегодня делимся открытыми ИТ-вакансиями «Росатома» для стажёров. Программы рассчитаны на студентов, выпускников без опыта и специалистов, которые хотят сменить сферу. 

Условия

— Занятость от 20 до 40 часов в неделю.

— Наставничество и обучение.

— Оплата труда.

— ДМС, вовлечённая команда и перспективы роста.

Вакансии

1. Москва. Стажёр аналитик-тестировщик. Подать заявку.

2. Москва. Стажёр по информационной безопасности. Подать заявку.

3. Нижний Новгород. Аналитик нормативно-справочной информации. Подать заявку.

4. Электросталь. Системный администратор. Подать заявку.

5. Ковров. Стажёр-аналитик. Подать заявку.

6. Северск. Инженер средств радиосвязи. Подать заявку.

7. Саров. Стажёр по информационной безопасности. Подать заявку.

Если хотите расти в ИТ — это реальный шанс начать карьеру.

Зима в разгаре, а мы нанимаем: новые вакансии в SSP SOFT

Кто мы и чем занимаемся? Лидеры («одни из», конечно) найма ИТ-специалистов на российском рынке — за прошлый год мы наняли 179 сотрудников, и уже в январе 2026 к нам присоединились 11 новых гуру!
Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.

У нас новый московский офис, который открылся в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удаленку из любой точки России.

Команда в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.

Самые горячие вакансии прямо сейчас:
(а всего их 11 на начало февраля 2026 - см. ссылку ниже на ХХ-ру)
1️⃣ Fullstack QA Engineer (Node.js)
2️⃣ Java-разработчик
3️⃣ Системный аналитик (ритейл)
4️⃣ Data Разработчик (Oracle, Greenplum)

Что предоставляет экосистема SSP SOFT:
✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины.
✅ Центр компетенций и личное менторство ускорят развитие до максимума.
✅ Офис, гибрид или фулл-удаленка? Есть все варианты.
✅ Время — ваш ресурс. Мы его уважаем.

Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашей HR Lead Алине (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».

Желаем всем хабровцам успешной карьеры в 2026 году 🚀)

«Яндекс Образование» запустило бесплатную программу обучения ИИ-робототехнике для школьников, причём без регистрации и без авторизации. Учебный курс включает бесплатную онлайн-платформу для программирования роботов. Выполняя задания в симуляторе с виртуальным роботом-доставщиком, школьники узнают, как автономные устройства ориентируются в пространстве, анализируют среду и самостоятельно принимают решения. Писать код не нужно — алгоритм собирается как конструктор из команд-блоков. Ещё к платформе можно подключить образовательные конструкторы Mindstorms EV3.

Бесплатный акселератор, неожиданные грабли и куча выпитых чашек кофе: как мы проверяли гипотезы в IT‑стартапе

Привет, Хабр!

Вы когда-нибудь задумывались, почему команда опытных разработчиков, дизайнеров и QA, годами делающая успешные продукты для других, не может так же легко запустить свой? Мы тоже думали, что знаем ответ. Оказалось, что нет.

Нас четверо: бэкенд, фронтенд, дизайнер и QA. Годами работали в аутсорсе, делали понятные продукты по четким ТЗ. А потом в один день задались вопросом: "А чего это мы всё делаем проекты другим? Пора попробовать своё".

В прошлом году мы залетели в акселератор Южного IT-Парка (бесплатный, что важно). Опыт был яркий: где-то больно, где-то смешно, а где-то мы просто осознали глубину своего заблуждения.

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

Ошибка №1: Наш "MVP" оказался "MIP" (Minimum Imaginable Product)

В аутсорсе мы привыкли, что продукт должен быть законченным, красивым и работать без косяков. Когда мы начали свой проект, мы по инерции спроектировали и начали разрабатывать то, что сами считали "минимально жизнеспособным продуктом".

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

Вывод: MVP - это не про ваш технический минимум. Это про максимум неопределенности, который вы готовы закрыть одной итерацией. Теперь наша первая задача для любой фичи - не накидать макетов, а сформулировать гипотезу и придумать самый дешёвый способ её проверить (часто это даже не код, а Landing Page, опрос или эмуляция процесса).

Ошибка №2: Мы недооценили силу еженедельных дедлайнов

Акселератор - это не про деньги (по крайней мере, в нашем случае). Это про дедлайны и сообщество.

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

Инсайт: Привычка "идеально доделать и потом показать" убивает скорость обучения. "Криво, но сейчас" стало нашим неофициальным девизом. Эти еженедельные отчёты заставляли нас постоянно задавать себе вопросы: «Что мы узнали на этой неделе? Какая гипотеза подтвердилась? Что будем пробовать дальше?».

Ошибка №3: Мы пытались работать "как раньше"

В коммерческой разработке роли четки, процессы отлажены. В стартапе это сломалось в первую же неделю.

Оказалось, что, например, бэкендеру нужно спорить о юзер-флоу, потому что от этого зависит архитектура. А всем вместе нужно каждый день решать, что делать прямо сейчас, потому что "долгосрочный план" меняется раз в неделю.

Инсайт: Стартап - это не проект, это режим работы, где все немножко product owner и немножко предприниматель. Наша привычка "делать свою часть идеально" часто мешала сделать "целое достаточно быстро".

И что в итоге? Стоило ли оно того?

Пока не знаем.

Заработали ли мы на пачку чипсов? Нет.
Кончился ли кофе? Да, много раз.
Получили ли мы то, за чем шли?

Абсолютно да.

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

Теперь, вооружённые этими (и парой других) шрамами, мы стартуем новый проект. С тем же энтузиазмом, но с меньшим количеством граблей (надеемся).

P.S. Если вы тоже думаете о своём продукте или уже на этом пути — делитесь в комментариях, с какими граблями столкнулись вы?

Привет, Хабр! Задали насущные вопросы про технологии и команду Александру Сырцову, Head of Frontend клиентского сайта Wildberries. Первая часть — здесь. А мы продолжаем.

Какое главное качество отличает хорошего фронтенд-разработчика в крупной команде?

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

Как выбрать правильный стек технологий для нового большого проекта?

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

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

Далее следует анализ бизнес-требований: нужен ли серверный рендеринг для SEO, какая требуется интерактивность, какие браузеры необходимо поддерживать. Если проект нужно запустить в сжатые сроки, критичным фактором становится совместимость с существующей инфраструктурой: будет ли выбранная технология работать с текущими CI/CD-процессами, мониторингом и бэкендом.

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

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

Какие методы применяют в твоей команде для поддержания высокопроизводительного фронтенда?

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

В продакшене — постоянно мониторим Core Web Vitals (LCP, FCP, CLS и другие) в реальном времени и на всех типах устройств. Мы не ориентируемся исключительно на показатели Lighthouse, поэтому особое внимание уделяем телеметрии с реальных пользовательских устройств.

Как ты мотивируешь команду оставаться креативной и находить нестандартные решения?

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

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

Ещё больше про технологии — в нашем телеграм-канале.

Привет, Хабр! Задали насущные вопросы про технологии и команду Александру Сырцову, Head of Frontend клиентского сайта Wildberries. Мини-интервью — ниже.

Какие самые большие мифы вокруг фронтенд-разработки тебе встречались?

Миф 1. Фронтенд обязательно должен быть «глупым». Получили данные — отрисовали, изменили — отправили обратно на сервер.

В масштабах маркетплейса Wildberries фронтенд, наоборот, должен быть «умным»: мы сознательно выносим часть бизнес-логики на устройства клиентов, чтобы снизить нагрузку на серверные мощности. При этом сами микросервисы стараемся упрощать.

На таких высоконагруженных проектах, как наш, фронтенд — это сложная инженерия: управление состоянием тысяч динамических элементов, оптимизация времени загрузки на медленных соединениях, построение архитектуры, которая масштабируется вместе с ростом бизнеса, а также прямое влияние на конверсию и Core Web Vitals.

Миф 2. Мобильная и десктопная версии могут сильно отличаться.

Для нас критически важна консистентность. Пользователь может начать покупку в приложении или мобильном браузере, а завершить её на десктопе. Поэтому единая логика, дизайн-система и API — это не nice to have, а обязательное требование.

Миф 3. Производительность фронтенда — это забота только фронтенд-разработчиков.

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

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

Какое самое необычное решение по оптимизации фронтенда тебе когда-либо приходилось применять?

Это была не моя идея, но эффект меня действительно удивил. В некоторых местах мы сознательно пошли против парадигмы SPA и стали заранее держать в DOM-дереве подготовленные в фоне части приложения. Смысл подхода в том, чтобы при переходе пользователя в раздел не начинать рендер с нуля, а как можно быстрее показать заготовленный контент.

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

Какие изменения произошли в экосистеме фронтенд-технологий за последнее десятилетие и как они повлияли на твою работу?

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

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

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

Вторая часть здесь.

Не смогли смириться с поражением - и к чему нас это привело. Как мы воскресили ИИ-помощника для поиска работы

Привет, Хабр.

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

Самый логичный вариант был простой:

«Ну ок, рынок поменялся, едем дальше».

Но мы решили иначе.

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

Так начался путь к OfferMate 2.0.

Главная мысль оказалась неожиданно простой:

Автоматизация должна быть не только быстрой, но и естественной.

Настоящий цифровой ассистент должен вести себя как человек:

• выбирать вакансии осмысленно;

• работать с паузами и приоритетами;

• не выглядеть как бот;

• и не ломаться при реальной нагрузке.

Именно вокруг этого принципа мы и пересобрали архитектуру продукта.

Что теперь умеет OfferMate 2.0

🤖 Отклики только на релевантные вакансии
Ассистент анализирует ваш опыт и требования работодателя и выбирает вакансии, которые действительно подходят, а не просто совпадают по ключевым словам.

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

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

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

🧩 Новые функции

• автоматическое прохождение онлайн-тестов;

• поддержка одновременных откликов с нескольких аккаунтов.

Про релиз

12 февраля в 12:00 мы открываем доступ к OfferMate 2.0.

Первая волна будет ограничена 50 пользователями, а доступ открыт на 3 дня.
Это осознанное ограничение - чтобы сохранить стабильность системы и быстро собрать качественную обратную связь.

Поучаствовать в тестировании в числе первых можно будет в нашем телеграм канале, в нём делимся всеми новостями проекта:

👉 https://t.me/offermatecrew

Буду рад вопросам и обсуждению в комментариях

35 открытых уроков недели

Привет, Хабр. Делимся подборкой бесплатных открытых уроков, которые пройдут на этой неделе в Otus. Опытные практики проведут занятия онлайн — сможете узнать больше о формате обучения и задать вопросы экспертам. Выбирайте свою тему и присоединяйтесь!

9 февраля, понедельник:

• 18:00 — Сингулярное разложение матрицы и ALS в теории рекомендательных систем

• 20:00 — Lock-free в C++: Без блокировок к высокой производительности

• 20:00 — Проектирование Data Vault по набору данных TPC-H с применением dbt и Trino

• 20:00 — AI-Driven архитектура приложений

• 20:00 — Бизнес-процессы в Битрикс24, написание своих кастомных действий

• 20:00 — Telegram-бот за 60 минут: получение данных из любого API и ответ пользователю

• 20:00 — Компетенции и личные навыки востребованного тимлида

• 20:00 — От проекта к портфелю: как управлять несколькими проектами?

10 февраля, вторник:

• 19:00 — Правильная разработка по GitFlow в 1С:EDT

• 19:00 — Архитектура как стратегия. Основные понятия современной корпоративной архитектуры

• 20:00 — Магия Lovable: Как создавать High-fidelity интерфейсы с помощью одного промпта

• 20:00 — Тестирование и валидация AI-агентов: от RAG-прототипа к управляемой интеллектуальной системе

• 20:00 — Wireshark 2/2: ищем узкие места

• 20:00 — Защита данных в .NET: шифрование, ключи и безопасность кода. От криптографии до защиты от OWASP Top-10

• 20:00 — Делаем по красоте: паттерны проектирования в Python-приложениях

• 20:00 — Техническое собеседование системного аналитика

• 20:00 — Docker Compose для тестировщика: легко о сложном

11 февраля, среда:

• 20:00 — Настройка CI/CD на практике с помощью Docker для ASP.NET-приложений

• 20:00 — Командный лидер в Agile: ключевые навыки PM в 2026 году

• 20:00 — LLM-риски в бизнес-процессах: галлюцинации, доверие и ответственность

• 20:00 — Как делать больше с меньшим: стратегии эффективности при дефиците бюджета

• 20:00 — Бот-сторож на Golang. Асинхронная верификация без паролей

• 20:00 — Жизненный цикл тестирования ПО (STLC - Software Testing Lifecycle)

12 февраля, четверг:

• 20:00 — Django + Telegram Bot: как связать веб-приложение и мессенджер

• 20:00 — Почему AI уверенно врёт в аналитике и как его поймать

• 20:00 — Безопасная многопоточность: пишем пул потоков

• 20:00 — Карьера HR Бизнес-партнера в 2026

16 февраля, понедельник:

• 20:00 — Безопасность КИИ в 2026: обзор последних изменений требований и ответственности

• 20:00 — Реализация паттерна CQRS с использованием библиотеки MediatR и ASP.NET CORE

• 20:00 — Продвинутое структурирование промптов: как получать предсказуемый результат

• 20:00 — Roadmap внедрения DevSecOps. Роли, цели, сроки

• 20:00 — Тестирование в бэкенде

• 20:00 — Роль бизнес-аналитика в процессах тестирования и контроля качества

• 20:00 — Навыки продуктового аналитика в 2026 году

• 20:00 — Моки в автотестировании на Python

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

Открытый проект ebook2audiobook превращает любую электронную книгу в полноценную аудиокнигу. Работает просто: закидываете epub, pdf или даже обычный txt и на выходе получаете готовый аудиофайл с главами, нормальной озвучкой и метаданными. Подойдёт, если не любите читать глазами, но хотите слушать книги в дороге или на тренировке. Работает локально на ПК и поддерживает множество языков и даже умеет клонировать голос. Можно озвучить книгу своим голосом или профессиональным диктором. Идеально для студентов, тех кто учит языки, или просто хочет слушать свои книги офлайн без подписок и облаков.

Обновлён учебный курс Welcome to the Python Programming Hub по Python с полного нуля до уровня продвинутого разработчика за 3 месяц. В репозитории сотни материалов для изучения Python, а также Data‑аналитики, машинного обучения, Data Science. Там есть вся база по Python с первых строчек кода до комплексного ООП, лямбда‑функций, замыканий и других сложных концепций языка. Изучение всех необходимых базовых библиотек, которые должен знать каждый уважающий себя разработчик на Python: JSON, Math, NumPy, Pandas, а также фреймворка Django. Материалы по всем актуальным и полезным API, машинному обучению, распознаванию речи, парсингу, компьютерному зрению, работе с изображениями и даже видео, алгоритмам и автоматизации процессов. Также даётся детальное представление о различных специализациях Python‑разработчиков, которые можно освоить и реализовать несколько пет‑проектов. В каждой главе представлены исчерпывающие примеры кода, картинки, объяснения, квизы и контрольные вопросы.

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

Маск считает, что резюме не главный ориентир. «Не смотрите на резюме — верьте своему впечатлению от общения», — советует Маск. Резюме может быть блестящим, но если спустя 20 минут разговора вау-эффекта от человека нет, стоит доверять разговору, а не бумаге. Маск добавил, что при найме важно обращать внимание на талант, драйв и надёжность. При этом он признал, что раньше недооценивал такое качество, как «доброта». «Хороший ли это человек? Можно ли ему доверять? Умный, талантливый, трудолюбивый? Если да — отраслевые знания можно добавить», — пояснил Маск.

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

Единственный способ заниматься творчеством и создавать хорошие игры, работая в большой компании, — обманывать работодателя. Об этом заявил японский геймдизайнер Кадзутака Кодака (Kazutaka Kodaka), разработавший франшизу Danganronpa.

«Притворяйся, что подчиняешься, но делай то, что хочешь. Используй компанию. Что ж, если что-то пойдет не так, то виноват будет тот, кто тебя нанял, лол»? — Кадзутака Кодака

В процессе тестирования верстки быстро становится понятно: один и тот же интерфейс может выглядеть аккуратно на макете, но разваливаться на практике. Чаще всего это проявляется в длине текста, переносах строк, состояниях элементов и отступах.

Рассказываем, на что обращаем внимание при проверке верстки и какие моменты проверяем в первую очередь.

1️⃣ С чего начинаем тестирование верстки?

При тестировании верстки мы сначала наполняем блоки разными текстовыми данными. Это сразу показывает, где интерфейс начинает ломаться. Дальше проверяем:

• максимально короткие значения — точка, пробел;

• максимально длинный текст, который можно ввести;

• соответствие ограничениям из постановки — например, максимально доступно 64 символа.

Если ограничений в ТЗ нет, смотрим, какой тип поля используется в базе данных. Часто это varchar(255), от этого и отталкиваемся при проверке.

2️⃣ Почему проверяем текст с пробелами и без?

Очень частый кейс: текст с пробелами красиво переносится, а без пробелов — вылезает за границы или ломает блок.

Иногда нам кажется, что пользователь так точно не напишет, но ничто не мешает ему назвать кнопку: «дезоксирибонуклеиноваякнопка». Поэтому проверяем с пробелами и без пробелов, а еще смотрим, как ведет себя перенос строк.

Для таких проверок удобно использовать максимально широкие буквы:

• для кириллицы — «Щ»;

• для латиницы — «W».

Это простой способ увидеть помещается ли текст, переносится ли он корректно на следующую строку и не вылезает ли за контейнер.

3️⃣ Что проверяем в макете?

Например, в макете Figma мы смотрим:

И, конечно, отступы между всеми элементами по вертикали и горизонтали.

4️⃣ Как проверяем реализацию?

В браузере используем стандартные DevTools: смотрим вкладку Elements + разделы Styles и Computed.

Computed удобнее — отображаются итоговые значения после применения всех CSS-правил: размер шрифта, высота строки, цвета, отступы.

Так проще напрямую сравнивать реализацию с макетом и не теряться в длинных CSS-цепочках.

5️⃣ Что важно знать о состояниях элементов?

Чаще всего это кнопки. В DevTools можно вручную включить состояния:

• :hover

• :active

• :focus

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

6️⃣ На что еще обращаем внимание?

Отступы могут быть реализованы через padding (внутренний) и margin (внешний).

Важно помнить, что высота текстового блока определяется line-height. Если высота строки отличается от макета — поплывут и расстояния между элементами, даже если padding и margin заданы верно.

7️⃣ Когда удобно считать руками, а когда — линейкой?

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

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

При этом в тестировании верстки почти всегда появляется вопрос баланса: где достаточно базовых проверок, а где уже начинается избыточный pixel perfect.

Интересно сравнить подходы: какие проверки верстки вы считаете обязательными в своей практике, а какие — избыточными? 

OpenAI запустила корпоративную платформу Frontier, которая упростит компаниям развёртывание ИИ-агентов. Это часть стратегии OpenAI по укреплению позиций на рынке автоматизации рабочих задач.

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

Как применять аналитические техники в реальных проектах

Привет, Хабр! С вами Диана, системный аналитик в АШАН ТЕХ. В прошлых постах я писала о том, как училась системному анализу, готовилась к собеседованиям и не выгорела в процессе.
Но после выхода на реальную работу возникает другой вопрос: как применять все эти знания не в учебном кейсе, а в живом проекте?

Короткий ответ — не так аккуратно, как в обучении.

Чем работа отличается от обучения

В обучении почти всегда есть понятное задание и ожидаемый результат.
В реальной работе даже при наличии бизнес-требований (БТ) всё может быть иначе: документ устарел, написан под старую логику или не отражает реальные пользовательские сценарии.

Поэтому аналитик чаще работает не «по документу», а с проблемой, которую ещё нужно правильно сформулировать.

С чего на самом деле начинается задача аналитика

Задача редко приходит в идеальном виде.

Обычно есть БТ, которое:

• требует актуализации;

• противоречит текущей логике системы;

• не учитывает ограничения или реальные сценарии.

Иногда аналитик сначала формулирует требования буквально для себя, чтобы разобраться, в чём вообще задача.

Дальше начинается обсуждение с бизнесом: целей, ожиданий, допущений. Иногда — сразу с несколькими стейкхолдерами.

Как я структурирую хаос

Когда информации много, а ясности мало, я делаю довольно простые вещи:

• фиксирую всё, что уже известно;

• выписываю вопросы и противоречия;

• уточняю цель и ограничения;

• формулирую рабочую версию требований.

Это не финал, а отправная точка для обсуждений и проверки гипотез.

Правила, которые мне сильно помогли на онбординге

Когда я только пришла в компанию и проходила онбординг, наставник поделился простыми, но очень практичными правилами. Со временем я поняла, что они применимы почти к любой задаче.

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

Ко всему нужно относиться критично. Даже если требование звучит логично, полезно задать вопрос: а зачем это? какую проблему решаем? что будет, если ничего не менять?

Всегда думать про альтернативные сценарии. Что пойдёт не так? А если пользователь сделает иначе? А если данные придут не в том виде? Эти вопросы часто экономят команде время на доработках.

Формирование ТЗ: «бизнес сказал» и «разработчик знает» — плохая основа

Сделать хорошее техническое задание (ТЗ), общаясь только с заказчиком, сложно.
 Но и ожидать «того самого разработчика, который всё знает», — плохая стратегия.

Такой подход:

• увеличивает время на задачу;,

• создаёт бутылочное горлышко;

• концентрирует знания в одной голове.

Гораздо эффективнее вовлекать разработчиков ещё на этапе формирования ТЗ.

Итог

Аналитика — это не шаблоны и диаграммы.

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

P.S.

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

Привет, коллеги-гоминиды!

Вышел я тут на рынок и понял: естественный отбор сломался, несите новый.

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

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

Недавно прилетел отказ с благодарностью за тестовое от DataLouna, которое я им не делал (принципиально не делаю уже довольно давно), да еще и с фидбеком для разработчика. Просто тряпка бреда от ChatGPT. То есть там просто лужа воды размером с А4 в духе: “Нам нужны разработчики которые могут проявлять инициативность в проектировании архитектурных решений, бла-бла-бла”. Может кого-то уберегу от потери времени, а может и нет.

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

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

В целом всё это выглядит не как найм, а как какой-то карго-культ: люди совершают ритуальные действия, не понимая их смысла.

Тем не менее есть и хорошие примеры, понравился процесс найма в Т-Банке например. Там все процессы налажены, без пафоса и корпоративной надменности. Прошёл техсобес, и как сказали вайтборд тоже прошёл, просто команды под меня сейчас нет. Но я знаю, что вайтборд откровенно завалил, и выступил отвратительно из-за отсутствия практики. Поэтому soft-reset вполне закономерен, тут всё по делу. Когда попросил фидбек — дали довольно быстро, без нейросетевых простыней, и подтвердили мои гипотезы о том, где я ошибся. Ничего, вернусь сильнее.

А у вас как? Часто встречаете HR-ов, которые путают виды и классы, или мне одному так везет? Делитесь своими самыми дикими случаями.

Ссылки на телегу и выпрашивания плюсиков не будет, тут просто истории из жизни и байт на комменты 🤓

Подборка бесплатных курсов для опытных и начинающих програмистов

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

• «Инженер облачных сервисов» — курс для специалистов с опытом, программа рассчитана на 70 часов или примерно месяц ежедневных занятий по 2 часа в день. Начните сейчас, а продолжить можно в своём темпе.

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

• «Подготовка к алгоритмическому собеседованию» — курс для специалистов с опытом. Для изучения теоретического материала понадобится 10 часов, время прохождения практики зависит от вашей подготовки. Знания из курса повысят ваши шансы на успешное прохождение собеседований. В курсе мы сфокусировались на том, что нужно для подготовки к интервью, а также поделились опытом разработчиков и подсветили много неочевидных моментов. А ещё собрали список материалов для самостоятельной подготовки.

• «Основы Go» — курс для тех, у кого есть опыт в программировании на других языках. Программа рассчитана на 30 часов или примерно 2 недели занятий по 2 часа в день. За это время вы научитесь читать и понимать код на Go, но чтобы создавать собственный код с нуля, уже придётся погрузиться в профессию глубже.

• «Основы Python-разработки» — обучение с нуля. За 20 часов поможем разобраться в бэкенд-разработке и начать писать код на Python — можно устроить марафон на выходных.

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

• «1С: программирование на русском» — обучение с нуля. Курс можно пройти за 45 минут: вечером после работы или на обеденном перерыве. Вы познакомитесь с одним из самых востребованных языков программирования, узнаете возможности 1C и примерите на себя роль 1С-разработчика. Если всё ещё думаете, что 1С — программа для бухгалтеров — это совсем не так.

→ Каталог бесплатных курсов

Открытый проект Go Katas поможет освоить язык программирования прямо Go. В репозитории решения есть сборник сотен ежедневных упражнений, чтобы довести навыки кодинга на Go до автоматизма, изучить конкурентность и Context, отработать Graceful Shutdown, а также защиту от утечек воркеров и правильный Fan-Out. Есть множество упражнений на Zero-Allocation парсинг, работу в sync.Pool и шардированные мапы.

Развитые софт-скилы для аналитика — +1000 к долгосрочному профессиональному успеху, ведь с ними преуспевать в работе будет проще. Благо софты, как и харды, всегда можно прокачать. 

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

Стратегическое мышление, или, иначе, helicopter view

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

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

Фасилитация встреч

Суть навыка в умении вести переговоры и выстраивать коммуникацию так, чтобы находить компромисс между конфликтующими сторонами. 

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

Понимание потребностей и выявление требований

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

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

Самоорганизация

Аналитику полезно уметь самостоятельно организовывать свой рабочий процесс: приоритизировать задачи и грамотно планировать день. 

Как развивать: пробовать декомпозировать свои задачи и разбивать сложные процессы на управляемые шаги. А еще не стоит пренебрегать этапом планирования личной эффективности и личной работы. 

Коммуникация и обмен информацией

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

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

QUBO как демонстрация разницы между математиком и инженером

QUBO (Quadratic unconstrained binary optimization) это метод поиска оптимального решения. В основе метода формулирование задачи в виде матрицы Q. Решение задачи - бинарный вектор x. Упрощено метод решения можно представить так:

xT * Q * x -> min

Суть решения задачи - определить такой бинарный вектор, при котором "энергия" минимальна. Код, который напишет математик, будет выглядеть примерно так:

int[] x = new int[size];
//...
for (int i = 0; i < size; i++)
{
    for (int j = 0; j < size; j++)
    {
        // Вычисление значения целевой функции: x^T * Q * x
        energy += x[i] * Q[i, j] * x[j];
    }
}

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

BitVector32 x = new();
//...			
for (var row = 0; row < size; row++)
{
    for (var column = 0; column < size; column++)
    {
        if (x[row] && x[column])
        {
            energy += Q[row, column];
        }
    }
}

Пример крайне простой, а потому наглядный. Спросите у LLM :-) В общем, математика и программирование - это не одно и то же.

Сооснователь LinkedIn Рид Хоффман заявил, что искусственный интеллект радикально меняет баланс сил в бизнесе и позволяет небольшим командам конкурировать с крупными организациями: «15 человек с ИИ могут конкурировать со 150 без него», поскольку технология существенно расширяет возможности сотрудников».

Хоффман отметил, что небольшие команды выигрывают за счёт общего контекста и более согласованной работы. «Малые команды имеют более чёткое общее понимание задач — то, что крупные организации не могут воспроизвести. ИИ усиливает этот эффект, потому что позволяет создавать системы, выявляющие закономерности внутри этого контекста», — добавил Хоффман.

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

Хоффман привёл пример использования ИИ-инструментов Codex и Claude Code для разработки переводчика на французский язык. ИИ-агент также предложил настроить переводческие пайплайны ещё для 68 языков. «То, что раньше было слишком дорогим или масштабным проектом, теперь можно легко начать прототипировать», — подчеркнул он.

Открытый учебный проект JavaScript Mastery — Complete Learning Path — это курс для изучения языка программирования JavaScript. Энтузиасты собрали более 500 учебных материалов — репозиторий заменяет буквально 4 года учёбы в университете. Есть вся база от определения переменных до ООП, замыканий и других сложных, но функциональных концепций. Сотни упражнений для повторения материалов и закрепления знаний. Примеры кода, визуализация всех концепций, каждый учебный пример авторы разжёвывают до последней строчки. В конце есть идеи пет‑проектов, чтобы закрепить знания. В проекте есть гайд для подготовки к собеседованиям со всеми актуальными вопросами.

45 бесплатных уроков февраля

2 февраля, понедельник:

• 20:00 — Практические подходы к переходу от монолита на микросервисы. Записаться

3 февраля, вторник:

• 19:00 — Коммуникация архитектора и принятие архитектурных решений в эпоху ИИ. Записаться

• 20:00 — Экономика и архитектура комплексной кибербезопасности компании. Записаться

• 20:00 — Kubernetes: «общение» с приложениями внутри кластера. Записаться

• 20:00 — Веб-приложения на Rust: как и зачем. Записаться

• 20:00 — Pydantic-settings для удобного конфигурирования приложения на примере FastAPI. Записаться

• 20:00 — Внутри Scrum: как работают мастер, владелец и команда. Записаться

• 20:00 — Примитивы синхронизации в Go. Записаться

• 20:00 — Чек-лист идеального A/B-теста. Записаться

• 20:00 — Как создавать решения и автоматизировать рутину в 2026 году: No-Code 2.0 и Pro-Code с AI. Записаться

4 февраля, среда:

• 19:00 — Разработка монолитного приложения со Spring. Записаться

• 20:00 — Kubernetes Multi-Tenancy: как изолировать команды в одном кластере с vCluster и Capsule. Записаться

• 20:00 — Eclipse Memory Analyzer (MAT): помощь в работе с heap. Записаться

• 20:00 — Подключение OpenAPI Swagger к Django-REST-Framework. Записаться

• 20:00 — Готовим процесс к автоматизации: от BPMN к данным и интерфейсам (на примере подготовки коммерческого предложения). Записаться

• 20:00 — Как тимлиду создавать процессы, которые работают и без него. Записаться

• 20:00 — Apache Camel в архитектуре решений бэкэнда. Записаться

5 февраля, четверг:

• 20:00 — Python и Web Scraping: Извлечение данных из интернета для анализа и автоматизации. Записаться

• 20:00 — Как обезвредить программный код. Расширяем кругозор. Записаться

• 20:00 — Уязвимость buffer overflow в ядре Windows. Записаться

• 20:00 — Измеряя — управляй. Метрики как важный инструмент Delivery Manager. Записаться

• 20:00 — Как бизнес-аналитик может улучшить систему через нефункциональные требования. Записаться

9 февраля, понедельник:

• 18:00 — Сингулярное разложение матрицы и ALS в теории рекомендательных систем. Записаться

• 20:00 — Lock-free в C++: Без блокировок к высокой производительности. Записаться

• 20:00 — Проектирование Data Vault по набору данных TPC-H с применением dbt и Trino. Записаться

• 20:00 — AI-Driven архитектура приложений. Записаться

• 20:00 — Бизнес-процессы в Битрикс24, написание своих кастомных действий. Записаться

• 20:00 — Telegram-бот за 60 минут: получение данных из любого API и ответ пользователю. Записаться

10 февраля, вторник:

• 19:00 — Правильная разработка по GitFlow в 1С:EDT. Записаться

• 19:00 — Архитектура как стратегия. Основные понятия современной корпоративной архитектуры. Записаться

• 20:00 — Магия Lovable: Как создавать High-fidelity интерфейсы с помощью одного промпта. Записаться

• 20:00 — Тестирование и валидация AI-агентов: от RAG-прототипа к управляемой интеллектуальной системе. Записаться

• 20:00 — Wireshark 2/2: ищем узкие места. Записаться

• 20:00 — Защита данных в .NET: шифрование, ключи и безопасность кода. От криптографии до защиты от OWASP Top-10. Записаться

• 20:00 — Делаем по красоте: паттерны проектирования в Python-приложениях. Записаться

• 20:00 — Техническое собеседование системного аналитика. Записаться

• 20:00 — Docker Compose для тестировщика: легко о сложном. Записаться

11 февраля, среда:

• 20:00 — Настройка CI/CD на практике с помощью Docker для ASP.NET-приложений. Записаться

• 20:00 — Командный лидер в Agile: ключевые навыки PM в 2026 году. Записаться

• 20:00 — LLM-риски в бизнес-процессах: галлюцинации, доверие и ответственность. Записаться

• 20:00 — Бот-сторож на Golang. Асинхронная верификация без паролей. Записаться

• 20:00 — Жизненный цикл тестирования ПО (STLC - Software Testing Lifecycle). Записаться

12 февраля, четверг:

• 20:00 — Django + Telegram Bot: как связать веб-приложение и мессенджер. Записаться

• 20:00 — Почему AI уверенно врёт в аналитике и как его поймать. Записаться

• 20:00 — Безопасная многопоточность: пишем пул потоков. Записаться