Как только проект выходит за рамки одного модуля — начинается знакомое: агент делает «что-то похожее», но не то. Поведение дрейфует от сессии к сессии. Дефекты просачиваются в production, потому что никто не проверял на интеграции. Разработчик тратит больше времени на правки, чем сэкономил на генерации. Это не проблема модели — это проблема процесса. Именно его и решает Agentic Agile — подход, который адаптирует Agile-принципы для команд, где рядом с людьми работают ИИ-агенты.

• Промпт — задание, не процесс: без бэклога, критериев готовности и ревью-гейтов агент дрейфует
• Документация (CLAUDE.md, AGENTS.md, STYLE.md) — интерфейс между человеком и агентом, а не README для людей
• Тикет с acceptance criteria — контракт выполнения: агент работает против спецификации, а не открытого промпта
• Governance с первого дня: CI/CD, линтер и автотесты — первый тикет в бэклоге, не последний
• Ретроспектива с агентом: анализ git-логов и PR-комментариев помогает найти, где процесс ломается

Почему промпт не масштабируется

Prompt-driven development отлично работает на ограниченных задачах: написать функцию, отрефакторить модуль, сгенерировать тест. Это задачи с чётко ограниченным выводом. Но как только проект разрастается до нескольких модулей, внешних зависимостей и поведенческих контрактов — система ломается предсказуемым образом.

• Нет бэклога — работа обнаруживается в процессе реализации, а не планируется заранее
• Нет понятия «готово» — сессия заканчивается, когда разработчик доволен, а не когда выполнен контракт
• Нет поэтапной доставки — всё делается сразу, без возможности остановиться и переориентировать
• Нет governance — ограничения безопасности и правила валидации добавляются в конце, если добавляются вообще

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

Плохая система победит хорошего человека — или агента — в любое время.

Документация как интерфейс между людьми и агентами

Agentic Agile предлагает простой ответ на вопрос «как агент узнаёт, как у вас принято»: задокументировать. Не для людей, а для агентов. Разница в том, что документы должны быть машиночитаемыми: структурированными, актуальными и привязанными к триггерам изменений.

Типичный набор файлов в репозитории, использующем эту методологию:

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

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

Агент как участник команды, а не инструмент

Большинство команд относятся к ИИ-агентам как к инструменту: выбрать модель, написать промпт, настроить параметры, получить продукт. Agentic Agile предлагает другую модель: агент — это полноправный участник команды. Каждое его действие — это действие разработки с теми же последствиями для кодовой базы, что и человеческий коммит.

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

Та же инженерная дисциплина, которая не позволяет человеческим командам выкатывать сломанное ПО, применима и к командам «человек + агент»: структурированное планирование, чёткие acceptance criteria, инкрементальная доставка и ревью-гейты.

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

Тикеты со спецификацией вместо открытых промптов

Главный практический инструмент методологии — это issue в системе задач с жёсткой структурой. Не «добавь авторизацию», а полноценный контракт с несколькими обязательными секциями.

Шаблон agentic story включает:

• Summary — одно предложение: что именно доставляет эта история
• Scope — явный список файлов, которых касается история (предотвращает конфликты при параллельной работе агентов)
• Acceptance Criteria — конкретные, проверяемые условия, которые должны выполняться по завершении
• Negative Constraints — что история явно НЕ делает (предотвращает scope creep)
• File Ownership — карта владельца каждого файла в этой волне (critical для multi-agent parallelism)

Ключевая идея: агент работает против спецификации, а не открытого промпта. Условие завершения — не «хватит» или «мне нравится», а «контракт выполнен». Это устраняет «good enough» culture, которая иначе просачивается в каждую агентную сессию.

Волновое планирование для параллельной работы

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

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

В секции File Ownership тикета явно прописано: этот файл принадлежит данной истории в данной волне. Никакая другая история в той же волне не должна его касаться. Это не договорённость — это часть спецификации.

Governance с первого дня, а не в конце

Самая дорогостоящая ошибка при agentic-разработке — отложить governance на потом. Governance в этом контексте — это система контрольных гейтов: ограничения безопасности, правила валидации, обязательные ревью и автотесты. «Сначала поймём, что строим, потом добавим гардрейлы» — в человеческой разработке это спорно, в агентной — катастрофично. Агенты принимают решения на скорости выполнения, и без явных ограничений они успевают нарушить архитектурные инварианты или создать уязвимости задолго до того, как человек это заметит. Microsoft столкнулась с этим в собственном проекте: CI-пайплайн не был первой историей в бэклоге, и к моменту его добавления уже накопились проблемы, основанные на допущениях, которые никто не проверял. Это потребовало вернуться и переделать несколько фич.

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

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

• Ограничения безопасности — это acceptance criteria в тикетах, не отдельная фаза
• Ревью-гейты стоят между волнами выполнения, не в конце проекта
• CI/CD, линтер и автотесты — первая история, которую реализует команда
• Ревью «найди всё плохое» (adversarial code review) на каждой волне — агент специально проверяет свой код на уязвимости и несоответствие контрактам, а не просто убеждается, что «всё работает»

Ретроспектива с агентом

После нескольких волн разработки команда Microsoft ввела ретроспективный процесс: агент анализирует файлы сессий, git-логи, PR-комментарии и другие данные, ищет паттерны сбоев и формулирует конкретные рекомендации по процессу. Например: «в волне 3 у нас было 4 конфликта по файлу X — в следующей волне разбить его на два отдельных владельца» или «acceptance criteria в 6 историях не были проверяемы автотестами — нужен шаблон с обязательным полем test_coverage».

Это замыкает петлю: агент не только выполняет работу, но и участвует в анализе качества процесса. Закрытые тикеты и PR-комментарии становятся исторической базой для последующих итераций — что было сделано и почему. Новые требования фиксируются в новых тикетах с явными связями parent-child, а паттерны улучшений переходят в обновлённые context-файлы (CLAUDE.md, AGENTS.md), которые агент читает на следующей сессии.

Как начать: пошаговый план

Методология переносима: Microsoft проверила её на нескольких несвязанных проектах разных доменов. Паттерны (spec-first бэклог, поэтапное планирование, context-файлы для агентов) работают без привязки к конкретному стеку или модели.

1. Скопируйте agentic-agile-template — там готовые шаблоны тикетов, context-файлы и стартовая структура бэклога
2. Создайте context-файлы для агентов: CLAUDE.md / AGENTS.md / copilot-instructions.md с описанием проекта, стиля кода и процесса
3. Составьте высокоуровневые тикеты для основных capabilities проекта — включая отдельный тикет на CI/CD и автотесты
4. Попросите агента отсортировать и сгруппировать тикеты по волнам, учитывая зависимости и конфликты файлов
5. Возьмите первый тикет, уточните его structure по шаблону agentic story (scope, acceptance criteria, negative constraints)
6. Запустите агента с явной инструкцией: работать только по спецификации в тикете, никакой работы без associated issue
7. После каждой волны — ревью-гейт: интеграция, CI, проверка инвариантов
8. После нескольких волн — ретроспектива: попросите агента найти паттерны сбоев в логах

Выводы

Идея Agentic Agile не нова по сути — это фундаментальное наблюдение Agile, применённое к новой модели коллаборации. Что Agile обнаружил для человеческих команд, Agentic Agile обнаруживает для команд «человек + агент»: итерация, контракты и рефлексия предотвращают одни и те же классы проблем.

Сдвиг принципиальный: вместо «пусть агент разберётся» — «определи контракт, ограничь выполнение, валидируй результат». Это не ограничение агента, а уважение к скорости, с которой он принимает решения.

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

Полный манифест, шаблоны тикетов и context-файлы для агентов: microsoft/agentic-agile-template на GitHub. Оригинальная статья: Agentic Agile: Why Agent Development Needs Agile, Not Just Prompts.

Эта методология — не просто набор митингов, а Философия. Разбираемся подробно в этом материале.

Что такое Agile: суть подхода

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

В отличие от традиционных методов управления, где всё планируется на годы вперед, Agile предполагает работу короткими циклами — итерациями длиной в две-три недели.

Каждая итерация включает полный цикл разработки:

• анализ,
• проектирование,
• кодирование,
• тестирование,
• выкладку рабочей версии продукта.

После завершения итерации команда анализирует результаты и применяет выводы в следующем цикле.

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

Как появился Agile: краткая история

До начала 2000-х в разработке ПО доминировал водопадный (Waterfall) метод. Проект разбивался на последовательные этапы: сначала полностью собирались требования, затем черёд проектирования, потом разработка, после — тестирование и только в самом конце — внедрение. Вернуться назад и что-то изменить было практически невозможно, ну или очень и очень сложно.

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

В феврале 2001 года в штате Юта (США) собрались 17 разработчиков, которые создали Agile-манифест — документ, заложивший основу современного гибкого подхода к разработке. Манифест до сих пор доступен в открытом виде на сайте agilemanifesto.org.

Ценности и принципы Agile-манифеста

Манифест построен вокруг четырёх ключевых ценностей:

Люди и взаимодействие важнее процессов и инструментов. Никакой таск-трекер не заменит нормальную коммуникацию в команде.

Работающий продукт важнее исчерпывающей документации. Лучше рабочий прототип, чем 200 страниц спецификаций.

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

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

Помимо ценностей, манифест содержит 12 принципов. Вот ключевые из них:

• Удовлетворенность клиента — главный приоритет.
• Изменения в требованиях приветствуются на любом этапе.
• Работающее ПО выпускается часто — раз в 2-4 недели.
• Бизнес и разработчики работают вместе ежедневно.
• Команда мотивирована и имеет условия для эффективной работы.
• Личное общение — лучший способ передачи информации.
• Работающий продукт — главная мера прогресса.
• Простота и минимизация лишней работы обязательны.
• Лучшие решения рождаются в самоорганизующихся командах.
• Регулярная рефлексия и адаптация процессов необходимы.

Структура Agile-команды: кто есть кто

Важная особенность Agile — отказ от жёсткой иерархии. Здесь нет традиционных начальников. Есть роли, которые участники берут на себя для достижения общей цели.

Product Owner (Владелец продукта) — формулирует видение продукта, управляет бэклогом задач и расставляет приоритеты. Именно он решает, что войдёт в следующий спринт, а что подождёт.

Scrum Master/Agile Coach — не менеджер в классическом понимании. Его задача — помогать команде следовать выбранному процессу, устранять препятствия (блокеры) и фасилитировать встречи, чтобы каждый понял позицию другого.

Разработчики — те, кто непосредственно создаёт продукт. Это могут быть backend, frontend, mobile-разработчики, DevOps-инженеры — в зависимости от специфики проекта.

UX/UI дизайнеры — проектируют пользовательский опыт и визуальную составляющую продукта.

QA-инженеры — обеспечивают качество продукта, находят и документируют баги.

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

Ключевой момент: в Agile-команде все равноправны. Разработчик может и должен оспаривать решения Product Owner’а, если видит технические риски.

Agile vs Waterfall: в чем разница

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

Типичная структура Waterfall-проекта выглядит так:

1. Сбор и анализ требований — детальное изучение всех требований к продукту.
2. Проектирование — создание архитектуры и дизайна системы.
3. Разработка (кодирование) — написание кода по готовым спецификациям.
4. Тестирование — проверка работоспособности всего продукта.
5. Внедрение — установка и запуск системы у клиента.
6. Поддержка — исправление найденных проблем.

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

Сравним два подхода по ключевым параметрам:

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

Преимущества и недостатки Agile

Разберем преимущества и недостатки подхода.

Плюсы

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

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

Гибкие дедлайны. Сроки планируются с учётом возможных изменений и задержек, что снижает стресс команды.

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

Меньше бюрократии. Фокус на работающем продукте, а не на документации и отчетах.

Минусы

Непредсказуемость результата. Финальный продукт может существенно отличаться от первоначальной задумки. Для клиентов с жестким ТЗ это может быть проблемой.

Требовательность к коммуникации. Постоянное взаимодействие с заказчиком обязательно. Если клиент недоступен, Agile не работает.

Сложный онбординг. Ввести нового человека в проект непросто — требуется время на погружение в контекст и командные практики.

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

Где применяется Agile в 2025 году

Изначально Agile создавался для разработки ПО, но сегодня его принципы используются далеко за пределами IT.

1. Разработка ПО и цифровых продуктов — классическое применение. Короткие спринты позволяют быстро тестировать гипотезы и выпускать рабочие версии каждые 2-4 недели.

2. Финтех и банкинг — разработка мобильных приложений, интернет-банкинга, систем автоматизации. Agile помогает банкам быстрее выводить на рынок новые продукты: от кредитных карт до страховых сервисов.

3. Маркетинг и диджитал — запуск рекламных кампаний за дни вместо недель, A/B-тестирование гипотез, мгновенная корректировка стратегий на основе данных.

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

5. Производство и логистика — оптимизация процессов, работа с поставщиками, управление складскими запасами через принципы Lean.

В 2025 году Agile — это уже не конкурентное преимущество, а базовая компетенция для любой команды, работающей в условиях неопределённости.

Когда стоит использовать Agile

Agile имеет смысл, если:

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

Agile не подходит, если:

• Требования жестко зафиксированы. Например, в проектах с регуляторными ограничениями или госконтрактах.
• Нужна многократная репликация. Если вы строите пять одинаковых зданий, Agile даст вам пять уникальных зданий.
• Заказчик не может участвовать. Agile требует постоянной обратной связи. Если клиент недоступен — метод не работает.

Философия, методология или фреймворк?

Важно понимать разницу между этими терминами:

Философия (Agile) отвечает на вопрос «Что важно?». Можно назвать это системой ценностей и принципов из манифеста — про людей, изменения и работающий продукт.

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

Фреймворк отвечает на вопрос «Как конкретно выполнить задачу?». Так называют набор инструментов, церемоний и артефактов для организации проекта.

Таким образом, Agile — философия. А Scrum, Kanban, XP — это фреймворки, построенные на принципах Agile.

Популярные Agile-фреймворки

Scrum — самый распространенный фреймворк. Работа делится на спринты, есть четкие роли (Product Owner, Scrum Master, команда) и церемонии (планирование, дейли, ревью, ретроспектива). Подходит для команд, разрабатывающих продукты с регулярными релизами.

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

Extreme Programming (XP) — фокус на технических практиках: парное программирование, TDD (разработка через тестирование), рефакторинг, непрерывная интеграция. Подходит для команд, где критично качество кода.

Lean — принципы бережливого производства, адаптированные для разработки. Основная идея — устранение потерь (ожидания, переделки, лишних фич). Подходит для оптимизации процессов и работы со стартапами.

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

Как внедрить Agile: практические рекомендации

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

Шаг 1. Начните с малого

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

Шаг 2. Получите поддержку руководства

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

Шаг 3. Обучите команду

Недостаточно сказать «теперь работаем по Agile». Проведите тренинги, пригласите опытного Agile-коуча, изучите практики выбранного фреймворка.

Шаг 4. Не требуйте мгновенных результатов

Первые 3-6 месяцев — это период адаптации. Производительность может даже просесть. Это нормально.

Шаг 5. Фокусируйтесь на ценностях, а не на процессах

Не копируйте слепо практики других команд. Важно понять философию Agile и адаптировать ее под свой контекст.

Шаг 6. Используйте подходящие инструменты

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

Шаг 7. Проводите регулярные ретроспективы

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

Шаг 9. Измеряйте правильные метрики

Не количество закрытых задач, а ценность, доставленную клиенту. Скорость (velocity), cycle time, процент успешных релизов — вот на что стоит смотреть.

Заключение

В 2025 году Agile — это не модная аббревиатура для резюме, а необходимый навык для работы в условиях неопределенности. Рынки меняются быстро, технологии устаревают за месяцы, а пользовательские ожидания растут.

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

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

1. Minerva Knowledge — система управления знаниями полного цикла

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

Продукт включён в реестр российского ПО и работает с отечественными ОС, а поддержка осуществляется на русском языке. Для развёртывания есть два варианта: безопасное облако на выделенном сервере компании или on-premise установка на собственном оборудовании, чтобы вписаться в стандарты безопасности.

Как это выглядит на практике для разных ролей

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

• Для разработчика это, в первую очередь, среда для ведения технической документации, фиксации опыта и багов. Встроенные шаблоны помогают стандартизировать описание задач, а ИИ-помощник, который можно встроить в IDE или таск-трекер, ускоряет поиск ответов.
• QA-инженер использует систему для создания и хранения тест-планов, чек-листов и ведения отчётности. Важный момент — возможность сопоставлять дефекты с требованиями и документацией в одном месте.
• PM или тимлид получает инструменты для управления требованиями, визуализации прогресса через дашборды и планирования спринтов.
• Аналитик или дизайнер может хранить в системе результаты исследований, макеты, пользовательские сценарии и гайды по UX/UI.
• Сотрудник поддержки использует Minerva Knowledge для быстрого доступа к FAQ, инструкциям и шаблонам, а также для создания новых статей по итогам решения обращений.

Что интересного в Minerva Knowledge

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

Фокус на ИИ и доставке знаний

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

• Minerva Copilot: Это GenAI-ассистент, который встраивается в виде виджета в любую рабочую систему (CRM, Service Desk, таск-трекер, IDE). Он даёт рекомендации и генерирует ответы на основе корпоративной базы знаний.

• Гибридный поиск: Система сочетает несколько подходов к поиску: морфологический (по ключевым словам), семантический (по смыслу) и диалоговый ИИ-агент. Аналитика поведения пользователей помогает улучшать релевантность выдачи.

Знания + Обучение (LXP)

В продукт встроена собственная LXP-платформа Minerva Learn, в которой можно собирать полноценные учебные курсы из статей в базе знаний. Система поддерживает SCORM/Tin Can пакеты, в ней есть тестирование, геймификация (рейтинги, баллы, сертификаты) и детальная аналитика для контроля результатов. Удобно для онбординга и проверки знаний команды.

Minerva Learn также даёт возможность настраивать мини-тесты для конкретных групп пользователей в момент публикации контента в Minerva Knowledge. Сотрудник получает уведомление об изменениях в статье и может сразу закрепить новые знания с помощью опроса, не переключаясь между окнами.

Портал самообслуживания Minerva Portal

Полностью защищённый портал с документацией, основанный на знаниях сотрудников. Адаптируется под требования брендбука, находит информацию с помощью поисковой строки и GenAI-помощника.

Совместная работа и миграция

Совместный редактор поддерживает одновременную работу нескольких пользователей, комментирование и использование макросов для встраивания графиков, диаграмм Draw.io и PlantUML и контента из Figma, Miro или Google Docs.

Кроме того, компания делает особый упор на удобство переезда с западных систем. Minerva Knowledge позволяет автоматически переносить контент из Confluence, SharePoint, Notion и других сервисов, сохраняя структуру, вложенность и даже графику. В системе реализованы все востребованные макросы, есть собственная система управления требованиями.

Авторская методология Minerva Result

Компания помогает запустить процессы и культуру менеджмента знаний для повышения качества и актуальности статей. В итоге единый источник правды появляется не только у сотрудников, но и у GenAI-агентов, которые начинают выдавать корректные ответы в среднем в 94% случаев.

Технические детали и возможности

Что касается технических момент, Minerva Knowledge предлагает гибкость как в доступе, так и в развёртывании. Работать с системой можно через веб-интерфейс, десктопные и мобильные приложения. Для интеграции в текущие рабочие процессы можно интегрировать API и SDK, а также встраиваемый виджет Minerva Copilot.

Модель тарификации включает подписку, покупку лицензий и корпоративные тарифы. Поддержка пользователей происходит в нескольких каналах: через чат, e-mail, Telegram, а для крупных клиентов предусмотрен выделенный менеджер и SLA.

2. ПланФикс — сценарии на все случаи ИТ-команд

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

Система размещена на российских серверах, работает без VPN и интегрирована с локальными платёжными системами, телефонией и сервисами вроде 1С.

Как это выглядит на практике для разных ролей

• Для разработчика это пространство для работы с задачами, фиксации багов и тайм-трекинга. Вся коммуникация с коллегами или заказчиком сохраняется в контексте конкретной задачи, а документация по проекту хранится здесь же.
• QA-специалист может вести тест-кейсы и чек-листы, напрямую общаться с разработчиком или продактом и настраивать свои процессы тестирования.
• PM или тимлид использует ПланФикс для планирования. Можно начать с общей схемы продукта на «Диаграмме связей», декомпозировать её до конкретных задач и отслеживать прогресс через канбан-доски, календари загрузки и отчёты по затратам в разных разрезах.
• Для дизайнеров и аналитиков это место для версионного хранения макетов, обсуждения исследований и коммуникации с командой на нужных этапах.
• Бизнес и HR могут вести внутренние проекты (в том числе скрытые, с финансовой информацией), создавать базу знаний, вести учёт сотрудников и даже рассчитывать зарплаты на основе данных из тайм-трекинга.

Что понравилось в ПланФикс

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

За время тестирование нашли самые интересные фичи:

Продвинутые автоматические сценарии

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

Аналитика

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

Диаграмма связей

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

Настраиваемые планировщики

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

Ограничения и система тарификации доступны по ссылке. Для интеграций есть REST и XML API. Сервис доступен в вебе и через мобильные приложения. Поддержка отвечает в чате из самого ПланФикса, МП, по email, в Telegram и VK. Также у сервиса есть активное сообщество на форуме и в Telegram, обширная база знаний и видеоуроки.

3. Kaiten — все рабочие процессы на одном экране

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

Сервис размещён на российских серверах (Tier 3), соответствует ФЗ-152 и входит в реестр отечественного ПО. Для компаний с жёсткой политикой безопасности есть on-premise версия. Оплата в рублях, работает без VPN.

Как это выглядит на практике для разных ролей

• Для разработчиков Kaiten — это удобный трекер с WIP-лимитами, прогнозированием сроков по Lead/Cycle Time и сквозной связкой с репозиториями, PR и CI/CD без необходимости дублировать статусы вручную.
• QA-специалист получает стандартизированную приёмку по чек-листам и критериям готовности (DoR/DoD), управляет дефектами в едином потоке с задачами разработки и отслеживает SLA на исправление багов.
• PM или тимлид использует Kaiten для поддержания ритма поставки без ручного администрирования. Автоматические правила не дают пропустить важный этап, а готовые Agile-отчёты помогают находить узкие места и планировать ресурсы с помощью диаграммы Ганта.
• Продакт-менеджер выстраивает сквозную трассировку от стратегии до бэклога и реализации. Встроенный User Story Mapping позволяет создавать дорожные карты, а система сама собирает метрики по срокам и статусам для принятия продуктовых решений на основе данных.
• Бизнес-лидеры (CEO/CTO) получают единую панель управления компанией, которая даёт прозрачность по всему портфелю проектов без лишнего микроменеджмента.

Что понравилось в Kaiten

Главная особенность — фокус на Agile-практиках из коробки, без необходимости долгой настройки и установки плагинов.

За время знакомства с системой выделили несколько интересных моментов:

Визуализация связанных процессов

Есть возможность видеть на одном экране несколько досок (например, дизайн, разработка, маркетинг) и отслеживать, как задачи перетекают между командами. При этом система позволяет создавать неограниченное количество рабочих пространств и досок внутри них.

Проработанная диаграмма Ганта

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

Agile-метрики без костылей

Система сама строит контрольные графики, CFD (Cumulative Flow Diagram) и рассчитывает Lead/Cycle time.

Документы и База знаний

Можно создать собственную базу знаний, где команда будет хранить и редактировать документы, не выходя из Kaiten.

Бесшовная миграция

Для команд, которые переезжают с Jira, Trello, Notion или Asana, есть автоматический импорт задач и истории.

Интеграции

В Kaiten доступны открытый API, SDK и широкий набор интеграций — это позволяет настраивать систему под конкретные рабочие процессы и автоматизировать рутину. Можно разработать свои дополнения, а из готового набора сразу доступны связки с GitHub, GitLab, Telegram, Slack, календарями и более чем 50 приложениями через Zapier.

Тарифы и стоимость

Тарифная система устроена по принципу «тариф + набор модулей».

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

• Платные тарифы («Старт», «Стандарт», «Бизнес», «Корпорация») стартуют от 185 рублей и различаются количеством доступных модулей и числом пользователей: «Стандарт» включает 2 модуля, «Бизнес» — 6 модулей. «Корпорация» — полный набор модулей. Количество пользователей ограничено купленными лицензиями, но ограничений по объёму хранимых данных нет ни на одном из тарифов.

Для компаний со сложными требованиями к инфраструктуре и безопасности есть on-premise версия на тарифе «Корпорация» с возможностью бессрочной покупки лицензии.

Поддержка и обучение

Kaiten доступен через веб и мобильные приложения, для enterprise — on-premise версия на Docker.

Поддержка включает базу знаний, техподдержку и команду customer success для сопровождения клиентов. Для on-premise версии — выделенная поддержка и внедрение под ключ.

Для обучения есть онлайн-курс по Kaiten, разборы кейсов, консалтинг и корпоративное обучение команд. Планируется запуск AI-ассистента для автоматизации сопровождения.

Что в итоге

Все три сервиса работают без VPN, размещены в России и могут заменить западные инструменты — но решают разные задачи.

Minerva Knowledge сфокусирована на управлении корпоративными знаниями с упором на ИИ-ассистентов и обучение. Плюс встроенная LXP для онбординга и автоматическая миграция из Confluence.

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

Kaiten — про визуализацию и Agile из коробки. Если вам нужны связанные доски команд на одном экране, встроенные метрики и быстрый старт без долгих конфигураций.

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

Я проанализировала около 50 предложений от ведущих образовательных платформ, чтобы составить рейтинг из топ-10 самых эффективных курсов, а также добавить 12 коротких программ для точечного погружения и 15 бесплатных курсов для старта. Этот обзор поможет вам выбрать идеальное обучение по Agile и Scrum, независимо от вашего уровня и опыта.

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

ТОП-10 лучших курсов Agile и Scrum в 2026 году

1. Управление по Agile: Scrum, Kanban, Lean от Нетологии — полный цикл управления проектами: от создания канбан-досок и применения Lean-подхода до анализа эффективности и оптимизации рабочих процессов.
2. Agile: Scrum и Kanban в работе над продуктом от Skillbox.ru — системное понимание гибкой разработки с разбором архитектуры Scrum, инструментов Kanban и методик проектного управления.
3. Agile: от основ до скрам-мастера от Нетологии — инструменты для старта в роли скрам-мастера с отработкой навыков на Agile, Scrum, Kanban и Lean.
4. Agile: методология проектного управления от MBA — практические навыки проектного планирования и реализации с изучением методов целеполагания и управления ресурсами.
5. Agile, Scrum, Kanban от MBS — подходы к формированию задач для снижения затрат на проекты и инструментарий продуктового анализа.
6. Agile Project Manager от OTUS.ru — перспективы участия в Agile-трансформациях с освоением адаптации методологий под бизнес-задачи.
7. Agile в командах от Контур.Школы — базовые принципы гибких подходов с практическими умениями работы по Scrum и Kanban.
8. AGILE & SCRUM: теория и практика внедрения в бизнес от Знанио — системное изложение Scrum с разбором рабочих стратегий и тактических приемов.
9. Agile-методологии в управлении проектами от City Business School — Agile-подход с акцентом на принципы и практические инструменты управления проектами.
10. Методология Agile от Lectera.com — практическое применение Agile-управления и SCRUM-методик с изучением механизмов проектного управления.

Обучение Scrum и Agile — это маст-хэв не только для управленцев. Разработчики начинают видеть логику процессов, а дизайнеры и маркетологи — наконец-то находить общий язык с командой. Для тех, кто в начале пути или планирует сменить поле деятельности, это знание станет вашим козырем, серьезно повышающим шансы на интересную работу.

Онлайн-курсы Agile и Scrum

1. Управление по Agile: Scrum, Kanban, Lean | Нетология

Используйте промокод kursfinder, чтобы получить скидку 7%

Применить промокод>>>

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

• Стоимость: 40 400 рублей
• Длительность: 4 месяца
• Формат обучения: видеолекции, практические задания и вебинары
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• руководителям отделов и подразделений, а также тим-лидам;
• специалистам по управлению проектами и продуктами;
• владельцам компаний и стартапов.

Преимущества:

• помощь в подборе подходящего формата обучения;
• бесплатная вводная консультация с экспертом;
• индивидуальные рекомендации по развитию карьеры;
• удобная мобильная платформа для занятий;
• полный доступ к материалам без интернета;
• персональные напоминания о дедлайнах смен;
• детальная обратная связь по заданиям;
• возможность получить налоговый вычет 13%;
• организация корпоративного обучения для коллектива;
• гарантия возврата средств при несоответствии ожиданий;
• начисление баллов Плюса при оплате через Яндекс Пэй.

Недостатки:

• не обнаружено.

Программа обучения:

• Основы менеджмента и гибких методологий
• Продуктовая разработка и мышление
• Фреймворк Scrum и его практическое применение
• Принципы Lean и Kanban
• Лидерство в Agile-командах
• Комбинация различных методик управления
• Дипломный проект по внедрению Agile

Ознакомиться с полной программой >>>

2. Agile: Scrum и Kanban в работе над продуктом | Skillbox.ru

Используйте промокод kursfinder, чтобы получить скидку 50%

Применить промокод>>>

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

• Стоимость: 44 532 рублей
• Длительность: 1 месяц
• Формат обучения: видеокейсы, практика
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• тем, кто стремится освоить профессию скрам-мастера;
• руководителям проектов;
• начинающим;
• владельцам бизнеса.

Преимущества:

• консультация по выбору профессии с подарком и бесплатными модулями;
• практика с проверкой и комментариями от экспертов;
• постоянный доступ к материалам и будущим обновлениям;
• бесплатная индивидуальная консультация перед стартом;
• дополнительная скидка при полной оплате;
• оперативная техническая поддержка.

Недостатки:

• ограниченное количество мест на курс.

Программа обучения:

• Фреймворки Agile и их особенности
• Артефакты Scrum и их назначение
• Распределение ролей и зон ответственности в Scrum
• Основные события Scrum-процесса
• Практика проведения Product Backlog Refinement
• Организация и проведение ретроспектив
• Компетенции для успешного создания продукта
• Запуск и мониторинг производственных метрик
• Метод Kanban для оптимизации командной работы
• Инструменты для управления распределенными командами
• Итоговый проект по внедрению Scrum или Kanban

Ознакомиться с полной программой >>>

3. Agile: от основ до скрам-мастера | Нетология

Используйте промокод kursfinder, чтобы получить скидку 7%

Применить промокод>>>

Эта программа готовит к роли скрам-мастера, давая инструменты для управления проектами. В основе курса — отработка навыков на методологиях Agile, Scrum, Kanban и Lean. Вы научитесь применять Agile на практике, проводить скрам-ивенты и управлять бэклогом, настраивать процессы через канбан-доски, сокращать издержки Lean-методами, работать в условиях неопределенности, оценивать задачи и выстраивать командное взаимодействие. Финальной частью обучения станет формирование умения ставить продуктовые цели и запускать новые скрам-команды.

• Стоимость: 90 700 рублей
• Длительность: 6 месяцев
• Формат обучения: лекции, вебинары, воркшопы, практика, бизнес-игра
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• начинающим скрам-мастерам;
• менеджерам продукта или проекта;
• тимлидам, руководителям и HR;
• тем, кто ищет работу в IT-компаниях.

Преимущества:

• персональная консультация и скидка;
• поддержка в подготовке к сертификации PSM I;
• доступ к материалам в личном кабинете и мобильном приложении без интернета;
• гибкий график с вечерними занятиями для совмещения с работой;
• возможность корпоративного обучения и адаптации программы;
• поддержка карьерного роста и помощь в трудоустройстве.

Недостатки:

• встречаются сбои в мобильном приложении.

Программа обучения:

• Менеджмент и основы Agile
• Продуктовая разработка и формирование продуктового мышления
• Применение Scrum в управлении продуктом и проектами
• Методологии Lean и Kanban
• Agile-лидерство и управление командой
• Комбинирование различных подходов на практике
• Роль и обязанности скрам-мастера
• Взаимодействие скрам-мастера с командой разработки
• Работа скрам-мастера с владельцем продукта
• Интеграция скрам-мастера в организационную структуру
• Подготовка к сертификации скрам-мастера

Ознакомиться с полной программой >>>

4. Agile: методология проектного управления | MBA

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

• Стоимость: 55 608 рублей
• Длительность: 1 месяц
• Формат обучения: дистанционно, вебинары, практические задания
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• руководителям и менеджерам;
• предпринимателям и бизнесменам.

Преимущества:

• обратная связь от преподавателей по всем заданиям;
• поддержка кураторов на протяжении всего обучения;
• бесплатная консультация по программе перед стартом;
• спикеры-эксперты с опытом в российских и международных компаниях;
• возврат 13% от стоимости обучения через налоговый вычет;
• практическая составляющая: 70% занятий построены на реальных рабочих задачах;
• трудоустройство: 65% выпускников находят работу в течение трех месяцев.

Недостатки:

• задержки ответов технической поддержки.

Программа обучения:

• Планирование проектов: от постановки целей до контроля результатов
• Организация рабочих процессов с применением современных инструментов
• Контроль выполнения проектов на всех этапах жизненного цикла
• Освоение гибких методологий Agile, Scrum и Kanban
• Управление проектами в условиях цифровой трансформации
• Инструменты для эффективной работы в цифровой среде
• Адаптация классических подходов к современным реалиям

Ознакомиться с полной программой >>>

5. Agile, Scrum, Kanban | MBS

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

• Стоимость: 39 510 рублей
• Длительность: 2 дня
• Формат обучения: очно или онлайн, практические задания
• Сертификат: удостоверение о повышении квалификации или Сертификат Moscow Business School

Кому подойдет:

• product-менеджерам;
• руководителям проектных групп;
• внедренческим консультантам;
• топ-менеджерам;
• специалистам в сфере HR, развития бизнеса и стратегического планирования.

Преимущества:

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

Недостатки:

• не подойдет новичкам.

Программа обучения:

• Фреймворки и методологии создания продукта
• Менеджмент стартапов на основе Agile, Scrum и Kanban
• Продуктовая разработка по принципам Agile, Scrum и Kanban
• Практики управления командами и повышения их эффективности
• Инструментарий Lean Startup для развития продуктов в Agile-среде
• Методология Customer Development: путь от идеи до продукта
• Современные методы исследования рынка и пользователей
• Инструменты проверки гипотез и получения практических инсайтов

Ознакомиться с полной программой >>>

6. Agile Project Manager | OTUS.ru

Программа открывает перспективы не только для позиций скрам-мастера или проект-менеджера, но и позволяет участвовать в комплексных Agile-трансформациях, работая на пересечении продуктовых, технических и бизнес-направлений. Ученики освоят выбор и адаптацию Agile, Scrum, Kanban, Waterfall под конкретные бизнес-задачи, разрешение конфликтов, ведение переговоров и предоставление конструктивной обратной связи. Также совершат оптимизацию процессов и приоритизацию задач в соответствии со стратегическими целями, защиту проектных решений на уровне топ-менеджмента.

• Стоимость: 116 000 рублей
• Длительность: 5 месяцев
• Формат обучения: интерактивные вебинары, практика, домашняя работа, кейс-задания, теоретическая часть
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• проект-менеджерам и product-менеджерам из ИТ;
• руководителям команд или департаментов;
• руководителям, проект-менеджерам и другим управленцам не из ИТ;
• программистам, аналитикам, тестировщикам;
• другим заинтересованным специалистам не из ИТ.

Преимущества:

• практический подход с решением реальных рабочих задач;
• преподаватели с опытом реализации проектов в области;
• модули по разным аспектам управления для комплексного взгляда;
• компенсация до 13% стоимости обучения через налоговый вычет;
• доступ к сообществу выпускников для нетворкинга и обмена опытом;
• перспективы трудоустройства в компаниях, применяющих Agile-подход.

Недостатки:

• необходимо ждать начала обучения.

Программа обучения:

• Проектный и продуктовый подход: особенности и ключевые отличия
• Стратегия постепенных улучшений существующих процессов
• Методология радикальных преобразований в бизнес-процессах
• Управление организационными изменениями на разных этапах
• Инструментарий современного руководителя проектов
• Технические аспекты в управлении проектами и продуктами
• Развитие гибких навыков для карьерного роста
• Проектная работа для закрепления полученных знаний

Ознакомиться с полной программой >>>

7. Agile в командах | Контур.Школа

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

• Стоимость: 7 900 рублей
• Длительность: меньше 2 месяцев
• Формат обучения: лонгриды и дополнительные материалы, тестирования
• Сертификат: сертификат установленного образца

Кому подойдет:

• тимлидам в IT;
• разработчикам;
• тестировщикам;
• новичкам.

Преимущества:

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

Недостатки:

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

Программа обучения:

• Agile-подход: его суть и бизнес-выгода для компаний
• Роль Scrum-мастера: зона ответственности и влияние на команду
• Влияние Agile на мотивацию и удовольствие от работы
• Антипаттерны Agile-команд: типичные ошибки и их решение

Ознакомиться с полной программой >>>

8. AGILE & SCRUM: теория и практика внедрения в бизнес | Знанио

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

• Стоимость: 299 рублей
• Длительность: от 1 дня
• Формат обучения: текстовые и видеоматериалы, практика
• Сертификат: сертификат установленного образца

Кому подойдет:

• руководителям;
• новичкам.

Преимущества:

• процесс обучения без посещения учебного центра и почтовой пересылки документов;
• обучение и документы от официальных лицензированных учебных организаций;
• документы установленного образца от котируемых образовательных учреждений;
• теоретические и практические знания от признанных специалистов-практиков;
• старт обучения сразу после оплаты и сжатые сроки освоения программы;
• снижение цены на 10% при нахождении аналогичного курса дешевле;
• возможность рассрочки, корпоративной оплаты или налогового вычета;
• возврат полной стоимости при несоответствии курса ожиданиям.

Недостатки:

• сжатое обучение.

Программа обучения:

• Agile INTRO
• Введение
• Сравнение
• SCRUM
• AGILE
• Внедрение
• Выводы

Ознакомиться с полной программой >>>

9. Agile-методологии в управлении проектами | City Business School

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

• Стоимость: 19 990 рублей
• Длительность: 21 день
• Формат обучения: видеоматериалы, тренажеры, тестирования
• Сертификат: сертификат установленного образца

Кому подойдет:

• менеджерам проектов;
• руководителям любого уровня.

Преимущества:

• готовые инструкции по внедрению agile-методов в работу;
• карьерный рост в ролях скрам-мастера или проджект-менеджера;
• гибкий график без фиксированных сроков сдачи;
• бессрочный доступ ко всем видео и материалам курса.

Недостатки:

• редкие проверки заданий куратором.

Программа обучения:

• Введение в основные agile-фреймворки: Scrum, Kanban, XP, Lean
• Базовые понятия и принципы гибкой методологии
• История создания и эволюции agile-подхода
• Сильные и слабые стороны agile для бизнеса
• Scrum-методология: принципы, артефакты и события
• Kanban-метод: визуализация, лимиты и управление потоком
• Сравнение Scrum и Kanban: критерии выбора подхода
• Agile-трансформация: этапы внедрения в проекты

Ознакомиться с полной программой >>>

10. Методология Agile | Lectera.com

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

• Стоимость: 3 650 рублей
• Длительность: 10,6 часов
• Формат обучения: видео, кейсы, практика, тестирования
• Сертификат: сертификат установленного образца

Кому подойдет:

• менеджерам;
• разработчикам;
• тестировщикам;
• новичкам;
• руководителям.

Преимущества:

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

Недостатки:

• программа дает базовые знания, но нет углубления в узкие темы.

Программа обучения:

• Ключевые аспекты управления проектами
• Применение Agile-методов в повседневных задачах
• Внедрение скрам в рабочие процессы команды
• Быстрое тестирование бизнес-идей и гипотез
• Развитие лидерских качеств и навыков
• Анализ продуктивности работы команды
• Основные понятия и термины Agile
• Стратегии эффективного планирования спринта
• Проведение ежедневных скрам-собраний
• Задачи и цели ретроспективы спринта

Ознакомиться с полной программой >>>

Еще 17 дополнительных курсов Agile и Scrum

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

• Интенсив Agile от Академии BELHARD. Участники интенсива освоят гибкие методологии разработки программного обеспечения с акцентом на их базовые принципы и ценностные ориентиры. Они изучат инструменты управления проектами и рисками, а также методы адаптации подходов под специфические условия. По окончании курса слушатели смогут целенаправленно улучшать коммуникационные процессы внутри команды и с заказчиками.
• Product Management: гибкие подходы Agile (Scrum), Lean и DevOps от УЦ Специалист. В рамках программы слушатели осваивают ключевые аспекты продукт-менеджмента и гибких подходов к разработке. Они изучат методы анализа рынка и конкурентной среды, управления продуктными требованиями и функциональностью. Особое внимание уделяется практическому применению Agile, Scrum, Lean и DevOps методологий в управлении продуктом.
• Agile - Scrum Foundation 1 от УЦ Специалист. Обучение построено на практическом применении Scrum через создание нового продукта в команде. Участники получат непосредственный опыт работы по данной методологии и оценят ее преимущества. Под руководством наставника они освоят инновационные подходы к решению проектных задач.
• Agile - Scrum Foundation 2 от УЦ Специалист. Программа знакомит с передовыми мировыми практиками разработки программного обеспечения, доказавшими эффективность. Основной акцент сделан на практических занятиях в формате ролевых игр с активным участием слушателей.
• Professional Scrum Master от Scrum.ru. Курс направлен на освоение принципов и методов эффективного управления проектами в Scrum. Выпускники получат инструменты для повышения результативности команд и достижения проектных целей.
• Agile Fundamentals Certification от ICAgile. Данная программа позволяет не только пройти обучение, но и получить международную сертификацию по основам Agile. Участники курса формируют глубокое понимание принципов гибкой методологии и immediately применяют полученные знания на практике через серию практических упражнений и разбор реальных кейсов.
• Agile и Scrum от ScrumTrek. В рамках этого обучения участники осваивают не только теорию, но и проходят полный цикл сертификации. Курс охватывает практическое применение различных гибких методологий разработки, включая Scrum, Kanban и XP. Особое внимание уделяется развитию навыков управления командой, анализа проектных показателей, а также техникам планирования и организации эффективного рабочего процесса.
• Agile и управление проектами от Mike Pritula. Эта программа предлагает комплексное изучение ключевых концепций и инструментов Agile-подхода. Слушатели детально разбирают такие аспекты как управление проектными рисками, построение эффективной коммуникации, обеспечение качества продукции и адаптацию к изменениям. Все теоретические модули подкрепляются практическими заданиями, которые можно immediately применять в реальной работе.
• Professional Scrum Master I: курс и симулятор от PmClub. Professional Scrum Master (PSM I) — профессиональный сертификат от scrum.org, которым обладают более 360 000 cкрам-мастеров по всему миру. Входных требований у PSM I нет, поэтому сертификат можно получить, даже если нет опыта работы скрам-мастером.
• Управление проектами по Agile от Rocket. Программа фокусируется на практическом применении Agile в управлении проектами. Слушатели учатся выстраивать рабочие процессы, распределять роли в команде, проводить все типы скрам-мероприятий: планирование спринтов, ежедневные стендапы, обзоры результатов и ретроспективы. Каждый модуль содержит практические задания для закрепления навыков.
• SAFe® Release Train Engineering от Agile LAB. Этот курс знакомит с принципами масштабирования Agile в больших организациях через методологию Scaled Agile Framework. Участники осваивают техники планирования и управления выпусками продуктов, а также инструменты эффективного взаимодействия со всеми заинтересованными сторонами проекта. Программа включает множество практических примеров из реальных проектов.
• Agile.Scrum от центра Андрея Плетнева. Практико-ориентированный курс, где участники учатся работать в скрам-команде, распределять задачи, проводить ежедневные встречи, планировать спринты и анализировать их результаты. Отдельные модули посвящены управлению проектными рисками и методам адаптации к изменениям в процессе разработки.
• Базовый Agile от ScrumTrek. Программа предназначена для начинающих и представляет собой первый этап международной сертификации ICAgile. Курс дает фундаментальное понимание Agile-методологии и prepares участников к дальнейшему профессиональному развитию в этом направлении. После завершения выдается сертификат ICAgile ICP.
• Методология Scrum от PM Exspert. Интенсивный трехдневный курс teaches эффективному сочетанию классического проектного управления по PMBOK® с гибкостью Scrum. Участники получают не только теоретические знания, но и практический опыт применения скрам-методологии в симуляции реального проекта.
• Agile и Scrum от Scrum Alliance. Программа Certified Scrum Master позволяет глубоко освоить ключевые концепции скрам-методологии. Обучение помогает улучшить коммуникационные процессы внутри команды и между командами, а также дает инструменты для проведения организационных изменений независимо от текущей роли в компании.
• Применение гибких технологий от Академии Айти. Курс помогает понять важность системного подхода в управлении разработкой IT-решений. Участники знакомятся с методологией Kanban, изучают техники визуализации рабочих процессов и инструменты управления ресурсами. Особое внимание уделяется практическому применению полученных знаний.
• Agile Project Management от Onagile Academy. Программа позволяет сравнить подходы к созданию команд в классическом проектном управлении и Agile-среде. Участники изучают методы подбора участников проекта, формирования эффективных рабочих групп и инструменты управления распределенными командами. Курс содержит множество кейсов из реальной практики.

Бесплатные курсы Agile и Scrum

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

1. Изучаем основы управления проектами по Agile за 3 дня от Skillbox. Если вам проще учиться короткими рывками — этот интенсив идеален. За три дня вы не только разберетесь в основах, но и сразу примените их в реалистичных рабочих ситуациях. Преподаватели-практики будут комментировать ваши решения — как если бы вы работали в настоящей команде.
2. Что такое Agile и зачем он нужен бизнесу от Нетологии. Этот курс — для тех, кто хочет понять саму суть гибких подходов. Вы узнаете, почему компании переходят на Agile, как это меняет работу команд, и какие роли появляются в процессе. Все объясняют на конкретных примерах, без заумных терминов.
3. Гибкое управление: как помочь бизнесу в условиях неопределенности от ScrumTrek. Отличный вариант для тех, кто работает в быстро меняющейся среде. Курс учит не просто следовать методологии, а гибко подстраиваться под обстоятельства — как раз то, что нужно в современном бизнесе.
4. Бесплатный мини-курс: Agile, Scrum, Kanban от Product Lab. Если хотите за один присест разобраться в трех основных подходах — вам сюда. Вс разложено по полочкам: что выбрать для ваших задач, как организовать команду и как управлять процессом от идеи до результата.
5. Agile. Вводный курс от Stepik. Для тех, кто любит учиться в своем темпе. Материалы доступны круглосуточно, можно возвращаться к сложным темам снова и снова. Отлично подходит для знакомства с темой.
6. Agile Product Owner Career Guide от Udemy. Мечтаете о роли владельца продукта? Этот курс покажет вам изнутри, что это за работа. Авторы делятся реальными вопросами с собеседований из крупных компаний — такая информация бесценна для тех, кто планирует карьерный рост.
7. Agile Project Management от Coursera. Для основательных людей, которые хотят разобраться до мелочей. Здесь вы поймете не только как работать по Scrum, но и почему именно так нужно работать. Отлично подходит для будущих скрам-мастеров и тех, кто хочет научиться вести команду через сложные проекты.

Бесплатные видеоуроки Agile и Scrum

Если вам нужна более гибкая и наглядная форма занятий, обратите внимание на подборку бесплатных курсов по Agile и Scrum в формате видеоуроков. Они позволяют изучать материал в удобном темпе, возвращаясь к сложным моментам. Этот вариант идеален для визуалов и тех, у кого нет возможности привязываться к жесткому учебному графику.

1. Весь СКРАМ за 14 минут от Dmitry Blinov. Автор обозревает такие темы, как PO, Developers, SM, продукт, Sprint, Backlog, инкремент, Daily, демо, ретро и так далее.
2. Что такое Agile? Scrum VS Kanban ДЛЯ НОВИЧКОВ от GeekBrains. СМ помощью полезного видеоурока вы с автором погрузитесь в историю и узнаете, как создавался Agile. Также вам расскажут про Scrum и Kanban — методы, по которым работают многие компании.
3. Что такое AGILE и SCRUM? от Noukash. В этом видео автор обозревает данные системы. Просмотр будет полезен всем, кто метит на карьеру в IT — специалистам и студентам.
4. Agile и Scrum на пальцах от АйТиБорода. В этом видео автор постарался простыми словами рассказать о гибких методологиях разработки программного обеспечения.
5. Рождение Scrum-команды от ScrumTrek. В своем докладе на AgileDays Елена поделилась несколькими важными выводами, которые помогли выстроить грамотную систему построения успешной Scrum-команды.
6. Agile & Scrum – знакомство и легкое погружение от ITVDN. В видео затрагивается отличие проектов, ориентированных на выпуск четкого объема работ в определенный срок, и реальностью. Выпуск будет полезен разработчикам и тестировщикам, работающим в Agile & Scrum, тимлидам и менеджерам, бизнес-аналитикам и другим специалистам, желающим лучше понять суть Agile подходов.
7. Гибкие методологии. Agile, Scrum, Kanban, Lean, Экстремальное программирование от Аспро Cloud. В некоторых отраслях важно подстраиваться под ситуацию. И в этом видео вы как раз рассмотрите семейство гибких методологий.
8. Кейсы применения Agile от ScrumTrek. Вводный вебинар курса Certified Agile Professional Online, на котором вы разберете кейсы применения Agile.

Что такое Agile и Scrum и в чем их основные отличия

Agile — это, по сути, просто здравый смысл, оформленный в принципы. Представьте, что вы делаете ремонт квартиры. Если вы заранее, на год вперед, распишете, какого цвета будут обои 15 октября, и будете слепо следовать этому плану, это не будет Agile. Скорее всего, за это время ваши предпочтения изменятся, появятся новые материалы, а сосед сверху затопит вас, и часть работы придется переделывать.

Agile — это когда вы решили делать ремонт поэтапно. Сначала — кухня. Сделали, пожили, поняли, что розетки надо было расположить иначе, а вытяжку — посильнее. Внесли изменения, когда приступили к ремонту ванной. Потом — гостиная. Вы постоянно сверяетесь с реальностью, а не с устаревшим планом. Главная идея Agile — признать, что мир меняется, и настаивать на неподобающем плане — это глупо. Вместо этого лучше показывать результат, получать feedback и гибко адаптировать курс. Это не методология, а скорее набор убеждений о том, как лучше работать.

Scrum — это уже конкретная методология, которая помогает воплотить эти убеждения в жизнь. Если Agile — это философия «ремонт лучше делать поэтапно», то Scrum — это конкретный график с чёткими ролями и действиями.

В Scrum работа делится на короткие отрезки, обычно по 1-2 недели, называемые спринтами. В начале каждого спринта команда договаривается: «Что мы можем реально сделать за эти две недели?» Они берут задачи из общего списка пожеланий, называемого бэклогом, и обещают завершить выбранный кусок к установленной дате.

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

В конце спринта происходят два важных события. Сначала команда показывает готовый результат заказчику или пользователям и спрашивает: «Вам то, что получилось? Как двигаться дальше?» Затем команда проводит встречу без начальства, чтобы обсудить: «Как улучшить наш процесс? Что пошло не так? Может, мы взяли на себя слишком много задач или часто отвлекались?» Эта встреча называется ретроспективой и необходима для постоянного улучшения работы команды.

В Scrum есть чёткие роли: Владелец Продукта (отвечает за «что» делать, представляет интересы заказчика), Scrum-мастер (следит за процессом, помогает команде работать по правилам Scrum, устраняет препятствия) и Команда разработки (делает работу).

Как понять, что команде пора пробовать Agile-подходы

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

Когда непонятно, что в итоге получится и доволен ли заказчик

Вы несколько месяцев упорно трудились, сдали проект, а заказчик смотрит на результат и говорит: «Ну, это не совсем то, что я хотел»? Или вы сами в процессе понимаете, что создаете что-то бессмысленное, но останавливаться уже поздно. Это классическая ловушка долгосрочного планирования без обратной связи. Agile предлагает показывать результаты работы часто — например, раз в одну-две недели. Это позволяет быстро понять, туда ли вы движетесь, и вовремя скорректировать курс, пока не потратили полгода на не тот продукт.

Когда команда теряет мотивацию и тонет в рутине

Если ваши сотрудники чувствуют себя винтиками в большой машине, не видят цели своей работы и завалены бессмысленными отчетами, пришло время что-то менять. Agile, и в частности Scrum, делают процесс работы прозрачным для всех. Каждый член команды видит общую цель, понимает, какой вклад он вносит, и может напрямую влиять на организацию своей работы. Короткие циклы, четкие цели на каждый спринт и регулярные обсуждения «как нам улучшить наш процесс» (ретроспективы) возвращают людям ощущение осмысленности и контроля, а это — лучший мотиватор.

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

Это, пожалуй, самый коварный сценарий. Команда работает как часы, соблюдает все сроки, выполняет KPI, но итоговый продукт оказывается посредственным, неинновационным или не находит отклика у пользователей. Это сигнал, что вы оптимизировали процесс ради процесса, забыв о главном — ценности для конечного потребителя. Agile заставляет постоянно задавать себе вопрос: «Делаем ли мы то, что действительно нужно людям?» Работа короткими циклами с регулярной демонстрацией результатов помогает сверяться с реальностью и не позволяет надолго уходить в «автономное плавание», отрываясь от потребностей рынка.

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

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

1. WEEEK

WEEEK — цифровая платформа для управления проектами, командами и бизнес-процессами без хаоса из отдельных инструментов. Сервис подходит для разных команд: от разработки и дизайна до маркетинга и HR. Прогеры используют WEEEK, чтобы выстраивать процессы по спринтам или в канбане, объединять задачи, документацию и аналитику в одном месте, автоматизировать рутину и концентрироваться на продукте.

Технические возможности

Внутри WEEEK пять основных модулей: Задачи, База знаний, CRM, Пользователи и Аналитика. Это позволяет организовать весь рабочий процесс в одном пространстве — от постановки задач до анализа результатов. Команды могут выстраивать индивидуальную методологию работы, вести техническую документацию (в том числе разграничивать доступ к ней), получать уведомления о задачах в Telegram и главное, не переключаться между кучей сторонних инструментов.

Есть интеграции с Google Таблицами, Документами, Miro, Figma, Airtable и календарями (Google, Яндекс, Apple). В разработке — доступ к GitHub и GitLab, с возможностью привязки коммитов к задачам и созданием pull/merge request прямо из интерфейса. Для автоматизации предусмотрен открытый API.

Разработчики и кросс-функциональные digital-команды используют WEEEK, чтобы синхронизировать процессы, делить задачи между проектами и сохранять прозрачность в работе. Среди пользователей — Karma agency, Stayfitt, SBoard и отдел маркетинга Золотого Яблока. Команды отмечают удобный интерфейс, гибкую настройку прав, возможность быстрого запуска проектов и постоянную поддержку от разработчиков.

Тарифы

• Для команд до 5 человек WEEEK доступен бесплатно;
• Тариф Lite — от 199 ₽ в месяц (до 10 участников);
• Pro — от 399 ₽ (без ограничения по числу участников), есть бесплатный пробный период на 14 дней;
• Business — от 450 ₽ (для масштабных задач и процессов).

Действуют и специальные условия: для студентов и преподавателей доступ бесплатный; для стартапов и НКО — скидка 50%.

2. Kaiten

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

Технические возможности

Сервис предлагает продвинутые инструменты для организации рабочего процесса: канбан-доски, таймлайны, календари, таблицы, учёт рабочего времени, визуальные сигналы и WIP-лимиты. Полноценная поддержка Scrum включает работу со спринтами, аналитикой и гибкой настройкой рабочих пространств.

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

Kaiten работает в облаке и как on-premise решение. Все данные хранятся на российских серверах, соответствующих стандарту Tier 3. Сервис входит в реестр отечественного ПО и сертифицирован Минцифры РФ.

Команды разработки используют Kaiten для построения процессов по Agile-методологиям, автоматизации отчётности, централизованной работы с задачами и документацией. Сервис также подходит маркетологам, продуктовым командам, HR-специалистам и руководителям отделов, которые стремятся сократить количество инструментов в ежедневной работе и повысить прозрачность процессов.

Тарифы

Kaiten предлагает гибкую систему тарифов:

• Free — бесплатно и бессрочно, с базовыми функциями для работы. Подходит небольшим командам без ограничений по количеству участников.
• Standard — от 420 ₽/мес. на пользователя. Включает 2 любых дополнительных модуля, поддержку и расширенные возможности досок.
• PRO — от 560 ₽/мес. на пользователя. Доступно до 6 модулей и расширенная настройка рабочих пространств.
• Enterprise — по индивидуальной цене. Включает все функции, возможность установки на собственный сервер, настройку под ключ и обучение команды.

Пробный период — 14 дней. Доступны все функции без привязки банковской карты.

3. Яндекс Трекер

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

Технические возможности

Трекер адаптируется под любые процессы: в нём есть доски задач, спринты, эпики, диаграммы Ганта и портфели проектов. Сервис поддерживает гибкие методологии управления (Agile, Scrum, Kanban), а также каскадные модели (Waterfall). Сценарии автоматизации позволяют создавать задачи по расписанию, менять их параметры по триггерам, назначать исполнителей и напоминать о сроках.

Инструмент интегрируется с другими сервисами через открытый API и входит в состав Яндекс 360 — экосистемы корпоративных решений. Трекер также можно подключать отдельно, без привязки к полному пакету 360.

Все данные хранятся на серверах в России, система внесена в реестр отечественного ПО и соответствует требованиям законодательства по защите информации.

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

Для миграции из других систем предусмотрены собственные инструменты переноса данных. Управление доступом можно организовать через Active Directory, SAML и систему единого входа (SSO).

Тарифы

Яндекс Трекер доступен как часть бизнес-пакетов Яндекс 360:

• Минимальный — от 569 ₽/мес. на пользователя. Включает 100 ГБ на Диске, видеовстречи до 100 человек, нейрофильтр в Почте, онлайн-доски и конспекты встреч с YandexGPT.
• Основной — от 779 ₽/мес. на пользователя. 1 ТБ на Диске, до 300 участников на встречах, архив писем, SSO и все функции минимального пакета.
• Продвинутый — от 1539 ₽/мес. на пользователя. Расширенный пакет: 3 ТБ на Диске, до 500 участников на встречах, трансляции, усиленные функции безопасности.

Также можно подключить Трекер отдельно — за 440 ₽/мес. за пользователя — с дополнительными сервисами Яндекс Вики и Формами.

Трекер доступен в веб-версии и мобильных приложениях (iOS, Android, HarmonyOS). Некоторые функции — например, создание досок и проектов, доступны только на десктопе.

4. Projecto

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

Технические возможности

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

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

Документооборот настраивается гибко: можно создавать карточки, шаблоны, согласовывать и доводить документы до сотрудников. Модуль «Контакты» помогает управлять структурой компании, отслеживать кадровые изменения, синхронизироваться с CardDAV и 1С. Мгновенный поиск по всей системе ускоряет работу с задачами, файлами и комментариями.

Все данные хранятся на российских серверах, система внесена в реестр отечественного ПО и соответствует требованиям ФЗ-152 и GDPR. Соединение осуществляется только по HTTPS, база данных резервируется каждый час.

Сценарии использования

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

Тарифы

Стоимость зависит от числа пользователей и периода оплаты:

• 1–100 пользователей — 400₽ за пользователя при оплате от 30-91 дней, 320₽ за пользователя в месяц при оплате за год.
• 101–200 пользователей — 380₽ за пользователя при оплате от 30-91 дней, 304₽ за пользователя в месяц при оплате за год.
• 201–1000 пользователей — 360₽ за пользователя при оплате от 30-91 дней, 288₽ за пользователя в месяц при оплате за год.
• Более 1000 пользователей — условия обсуждаются индивидуально.

Projecto предлагает безопасную и стабильную работу (аптайм 99,98%), регулярное резервное копирование данных и возможность экспорта из Jira, Trello, Asana.

5. Мегаплан

Мегаплан — российская CRM-система и платформа для управления задачами, проектами и командной работой. Сервис объединяет всё, что нужно для продуктивности: планы, цели, отчёты, аналитику, корпоративную базу знаний и инструменты для коммуникации.

Технические возможности

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

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

Сценарии использования

Мегаплан подходит как для распределённых команд, которым важно совместно вести проекты, так и для компаний, выстраивающих воронку продаж и клиентский сервис. Разработчики используют систему в Agile-подходе, отделы продаж — для работы с клиентами, а HR и руководители — для настройки внутренних процессов и адаптации сотрудников. Встроенная база знаний ускоряет онбординг и снижает потери при переходе задач между командами.

Тарифы

Мегаплан предлагает несколько тарифов, которые можно адаптировать под задачи конкретной команды:

• Совместная работа+ — 454 ₽/мес. за сотрудника при оплате на год. Подходит для команд, которым не нужна CRM. Включает управление задачами, проектами, базу знаний, календари, отчёты и интеграции через API.
• CRM: Лайт — 629 ₽/мес. за сотрудника при оплате на год. Добавляется база клиентов и возможность вести работу по контактам и компаниям.
• CRM: Клиенты и продажи+ — 769 ₽/мес. за сотрудника при оплате на год. Включает воронку продаж, интеграцию с 1С, ведение заказов, послепродажное обслуживание и CRM-инструменты.
• CRM: Бизнес — 1 049 ₽/мес. за сотрудника при оплате на год. Максимальный пакет: автоматизация бизнес-процессов, склад, расширенные функции CRM и задач.

Все тарифы включают 2 ТБ хранилища, видеозвонки, отчёты, магазин приложений и доступ к API. Доступна бесплатная полная версия на 14 дней.

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

Спрос на таких специалистов продолжает расти. Средняя зарплата проджект-менеджера в России в 2025 году составляет около 147 000 руб., при этом сеньоры могут получать до 240 тыс. Для продактов цифры еще выше — опытные специалисты в крупных IT-компаниях зарабатывают от 300 000 руб.

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

1. Академия Softline: «Управление проектами в области ИТ»

Академия Softline предлагает актуальный курс в рамках обширной обучающей программы для повышения квалификации. Программа разработана практиками из крупных IT-компаний и охватывает все аспекты работы с проектом.

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

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

Уникальность программы

Курс отличается синтезом мировых стандартов: PMBoK и ITIL интегрированы с гибкими методологиями (Agile, Scrum, Kanban). Такой подход учит адаптировать инструменты под специфику конкретных задач, а не просто следовать шаблонам.

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

Преимущества:

• практическая направленность: 70% времени посвящено работе с реальными кейсами;
• гибкие методики для ИТ-среды: от классического Waterfall до гибридных моделей;
• поддержка наставников с опытом в Сбере, Яндексе и других топовых компаниях.

Что получают выпускники

После защиты итогового проекта участники получают удостоверение повышении квалификации государственного образца и готовое портфолио с реализованным кейсом. Карьерный центр помогает с трудоустройством: студенты 2024 года получили офферы от партнеров (Сбер, МТС, VK) в течение 3 месяцев после завершения курса.

Стоимость и условия

Полная цена программы — 80 000 рублей. Доступна рассрочка на 4 месяца (20 000 руб./мес). Для корпоративных клиентов действуют скидки до 15% при обучении групп от 3 человек.

2. Компьютерная Академия ТОП: «Проджект-менеджер в IT»

Компьютерная Академия ТОП уже несколько лет готовит сильных проджектов для IT-индустрии. Курс подходит тем, кто хочет научиться управлять проектами в условиях неопределенности — именно с этим сталкивается большинство новичков.

Курс длится 10 месяцев и доступен в двух форматах: очном (в 200+ филиалах по России) или онлайн с живыми вебинарами. В отличие от многих программ, здесь нет записанных уроков — все занятия проходят в режиме реального времени с преподавателями-практиками. Каждую группу курирует действующий проджект из IT-индустрии, который дает каждому участнику обратную связь и разбирает ошибки на практике.

Уникальность программы

Живое обучение в малых группах (до 15 человек), где студенты отрабатывают навыки на 12 реальных кейсах — от запуска мобильных приложений до управления релизами SaaS. Например, один из проектов имитирует работу с заказчиком из банковского сектора, где нужно согласовать требования и сроки под жесткими ограничениями бюджета.

Программа обновляется каждые 6 месяцев с учетом запросов работодателей. В 2025 году добавлен модуль по гибридным методологиям (Agile-Waterfall) для госпроектов и FinTech.

Помимо Jira и Trello, студенты осваивают специализированные решения для IT-команд — Axure RP для прототипирования и MS Project для сложных диаграмм Ганта.

Преимущества:

• стажировка у партнеров (VK, Сбер, Тинькофф) после успешной защиты дипломного проекта;
• доступ к закрытому чату выпускников с вакансиями от 500+ компаний;
• сертификация PMI CAPM® включена в стоимость.

Что получают выпускники

По данным академии, до 80%студентов трудоустраиваются в течение нескольких месяцев после выпуска.

В портфолио входят:

• 4 завершенных учебных проекта с метриками эффективности (например, сокращение сроков на 15-20% в симуляциях);
• готовые артефакты: устав проекта, реестр рисков, отчеты по Scrum-спринтам;
• государственный диплом о профессиональной переподготовке и международный сертификат.

Стоимость и условия

• онлайн: 4 590 руб./мес (рассрочка на 10 месяцев);
• очно: 17 910 руб./мес (скидка 15% при оплате за год);
• корпоративное обучение: индивидуальный расчет для групп от 5 человек.

3. ProductStar: «Профессия Продакт-менеджер»

Курс от ProductStar подойдет как новичкам, так и тем, кто уже работает в IT, но хочет перейти в продукт.

Особенности программы:

• 8 месяцев обучения с упором на практику;
• 3 специализации на выбор: B2C, B2B или стартапы;
• работа с Figma, Miro, Amplitude, SQL;
• кейсы от партнеров: Яндекс, МТС;
• подготовка к реальным собеседованиям.

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

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

4. Академия Softline: «Управление проектами по разработке программных продуктов»

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

Формат обучения и особенности курса

Курс длится 252 академических часа и реализуется в мультиформатном режиме:

• Живые вебинары с разбором кейсов и домашних заданий от экспертов-практиков.
• Самостоятельная работа на обучающей платформе с доступом к записям и шаблонам документов.
• 80% практики. Симуляции переговоров с заказчиками, разработка проектной документации (устав проекта, реестр рисков, отчеты), защита итогового проекта перед комиссией с обратной связью.

У курса Академии Softline гибкий подход к методологиям управления проектами. В отличие от стандартных программ, здесь учат не просто следовать шаблонам Waterfall или Agile, а адаптировать их под специфику российского IT-рынка.

Особое внимание уделяется работе в сложных условиях — например, управлению изменениями требований, частыми релизами и MVP. Студенты разбирают полный цикл разработки ПО: от архитектурных решений до интеграции с устаревшими системами (legacy), что особенно актуально для разработки новых программных продуктов.

Практическая направленность — еще одна особенность программы. Все теоретические знания сразу применяются в реальных кейсах от партнеров (Сбер, VK, МТС), включая разработку мобильных приложений и SaaS-платформ. Участники осваивают профессиональные инструменты: Jira для трекинга задач, MS Project для построения сложных диаграмм Ганта и Confluence для ведения проектной документации.

Преподаватели курса — действующие проджект-менеджеры с опытом в международных компаниях. Они делают акцент на технических аспектах управления: понимании жизненного цикла разработки ПО (SDLC), базовых принципах DevOps и особенностях работы с API. Это позволяет выпускникам говорить на одном языке с разработчиками и грамотно ставить технические задачи.

Результаты выпускников

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

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

Стоимость и условия

• полная цена: 156 000 руб.;
• рассрочка: 13 000 руб./мес × 12 месяцев;
• корпоративное обучение: индивидуальный расчет для групп от 5 человек.

5. Нетология: «Продуктовый менеджер»

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

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

Обучение длится 8 месяцев и включает 104 урока в формате видеолекций, практических заданий и живых вебинаров. Студенты работают над собственным продуктом, проходя все стадии разработки: от формирования гипотез до запуска MVP и анализа первых метрик. Каждый модуль завершается практическим заданием, которое проверяют кураторы — действующие продакт-менеджеры из Mail.ru Group, Avito и других компаний.

Основные темы:

• Анализ рынка и целевой аудитории — методы CustDev, построение CJM (Customer Journey Map), выявление Jobs To Be Done (JTBD).
• Продуктовая аналитика — работа с метриками AARRR и HEART, настройка дашбордов, проведение A/B-тестов.
• Финансовое моделирование — расчет юнит-экономики, стратегии монетизации, оценка рентабельности продукта.
• Управление продуктом — создание роадмапа, приоритизация фич, работа с бэклогом и командой разработки.

Что отличает курс:

• Практическая направленность. 70% времени посвящено работе с реальными кейсами, включая задачи от партнеров Нетологии.
• Карьерный модуль. Помощь в составлении резюме, подготовка к собеседованиям, разбор переговоров о зарплате.
• Гибкий график. Возможность изучать материалы в удобное время, совмещая обучение с работой.

Что получают выпускники

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

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

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

Стоимость

Полная цена: 158 160 руб. (доступна рассрочка — 4 393 руб./мес). В рамках корпоративного обучения площадка предлагает индивидуальный расчет для групп.

6. SkillFactory: «Проджект-менеджер в IT»

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

Курс SkillFactory предназначен для тех, кто хочет освоить управление IT-проектами с нуля или систематизировать имеющийся опыт. Программа сочетает теорию с практикой: студенты изучают методологии (Agile, Scrum, Waterfall) и сразу применяют их в реальных кейсах, таких как разработка мобильного приложения или внедрение CRM-системы.

Формат обучения

• Онлайн-вебинары с разбором кейсов от преподавателей-практиков (например, Павла Максимова, который руководил запуском eSIM в России).
• 3 проекта в портфолио: планирование приложения по Agile, внедрение софта для call-центра по Waterfall, дипломная работа — сервис для видео-найма персонала.
• Поддержка наставников, включая персональные консультации и проверку заданий.

Ключевые навыки

Курс фокусируется на практических инструментах:

• работа с Jira, Trello, MS Project для планирования;
• управление бюджетом и рисками;
• проведение ретроспектив и дэйли-митингов (коротких ежедневных собраний команды);
• подготовка документации (уставы проектов, реестры рисков).

Трудоустройство

Выпускники получают доступ к вакансиям партнеров SkillFactory и помощь в составлении резюме. По данным портала hh.ru, средняя зарплата junior-проджекта после курса составляет 95 000–120 000 руб.

Стоимость

Полная цена: 87 000 руб. (доступна рассрочка — 7 250 руб./мес). Включен бонусный курс по нейросетям.

7. GoPractice: «Профессия: Продакт-менеджер»

Программа длится 11 месяцев и предназначена для специалистов, планирующих переход в продакт-менеджмент из смежных ролей (аналитики, маркетологи, проджекты).

Обучение включает пять ступеней:

1. Анализ траекторий перехода в профессию.
2. Освоение основ продакт-менеджмента через кейсы.
3. Работа с симулятором управления продуктом.
4. Дипломный проект.
5. Подготовка к трудоустройству.

Занятия проходят онлайн с гибким графиком. Каждую группу курируют менторы из компаний (Яндекс, Avito, Ozon), которые проводят приветственные звонки и консультируют по заданиям.

Программа

Курс охватывает:

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

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

Результаты

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

Стоимость

Полная цена: 219 900 руб., рассрочка: 18 325 руб./мес × 12 мес.

Как выбрать курс и начать карьеру

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

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

Это исследование мы подготовили совместно с Proglib. У них есть много книг и лекций, видеоуроков и советов, чтобы прокачать свои знания в IT.

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

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

Портрет рынка: кто ищет работу?

Чтобы увидеть портрет IT-рынка, посмотрим на цифры.

Сегодня больше половины разработчиков, которые активно работу, — это джуны. В основном им 18–34 года, чаще 25–34, и почти все они веб-разработчики: фронтенд, бэкенд, фуллстек. Среди используемых языков программирования лидируют JavaScript и TypeScript, за ними идут Python, Java и C#. Джуны часто меняют работу каждые 6–12 месяцев, не задерживаясь в компаниях из-за низкой зарплаты, отсутствия роста или токсичной среды.

Из каждого утюга рассказывают, что IT это «деньги, свобода, удалёнка». И все эти люди бегут на ютуб, курсы, к менторам, в школы и университеты. И вот приблизительно по 100 человек каждый месяц заканчивают курсы и «выкатываются» на рынок. А компаниям джуны в таком объеме не нужны. В 2025 году и миддлы в таком объеме не нужны. Бизнес сдерживается за счёт денег, отсюда и замедленный рост. Резюмируя, много обещаний, мало «реальности»».

На мидл-уровень приходится около трети рынка. Это тоже, в основном, веб, мобильная разработка и софт, с теми же популярными языками: JavaScript, Python, Java, PHP, C#. Мидлы стабильнее: они работают в компаниях по 1,5–3 года, но уходят по тем же причинам — деньги, отсутствие развития, токсичная атмосфера.

Синьоров среди соискателей меньше всего — около 15% (из числа респондентов). Это специалисты с опытом 5+ лет, работающие с привычным стеком (JS/TS, Python, Java, C#). Они меняют работу реже, раз в 2–4 года, и обычно уходят, если задачи становятся неинтересными, а процессы — плохими.

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

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

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

1. Джуны без практики и поддержки

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

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

Конкуренция среди новичков высокая, а рынок перегрет выпускниками курсов и онлайн-программ. Это приводит к тому, что некоторые пытаются обойти систему: «Накрутил на HH 3 года опыта, прошёл собес с GPT», — рассказывает один из респондентов. Но в реальных условиях накрутка опыта, скорее всего, не прокатит:

Дмитрий Борцов не рекомендует крутить опыт (только если ты не джун), а советует работать над хардами и резюме: «Если опыта достаточно для поиска работы — лучше поработать над хардами и составом резюме, чем над накруткой опыта, и потом решать проблемы с тем, «откуда» он взялся и почему его нет в трудовой. Если мы говорим про конкуренцию с джунами, то тут, к сожалению, да, придётся минимальные фильтры проходить, т.к. на рынке просто не существует такого объема вакансий».

Сергей Филичкин считает, что накручивать опыт можно, но при определенных условиях: «Оптимальное количество лет — 2-4 (зависит от конкретной ситуации). Правильно это делать нужно тогда, когда ты реально соответствуешь уровню, который написал в резюме. Для этого нужно усердно готовиться, знать все фишки рынка, понимать, что и как тебя будут спрашивать и еще кучу нюансов. Не нужно делать это в тех случаях, когда ты вообще не понимаешь, что написал в резюме и твой уровень реально не соответствует заявленному».

Анна Гагарина, как рекрутер с большим стажем, делится, что легко распознать человека, который накручивал опыт: «Нанимающие менеджеры знают, что опыт может быть ненастоящим. У меня есть заказчик, который берёт джунов только если они признаются, что опыт фейковый. Если компания готова нанимать джунов, она это делает. Если нет, фейковый опыт сложно подтвердить на техническом интервью, при проверке рекомендаций и бэкграунд-чеке (особенно в международных компаниях). Но некоторым везёт! С джунами мы проходили отбор, показывая учебные и личные проекты».

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

2. Специалисты с устаревшим стеком

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

Современные вакансии требуют знания cloud-инфраструктуры, CI/CD, Kubernetes, ИИ-инструментов, а в реальности многие разработчики продолжают работать на jQuery, устаревших версиях Java или PHP — просто потому, что так устроен их текущий проект. Когда приходит время менять работу, оказывается, что рынок ушёл далеко вперёд. Но как понять, что твой стек устарел?

Эксперты не могут найти однозначного ответа на вопрос, но рекомендуют всегда держать ухо в остро:

Всё зависит от вашего карьерного трека. Если планируете работать в растущих индустриях — AI/ML, HPC, Robotics, Physical AI — сразу смотрите в будущее и выбирайте те навыки, которые востребованы сейчас. Нет смысла совершенствовать то, что завтра вам не понадобится. И начинайте готовиться к переходу заранее. Если у вас есть карьерный план, то контролировать свой скилсет проще.

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

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

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

3. Разработчики без soft skills и адаптивности

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

Ценные кадры в ряде случаев увольняются из-за «конфликтов с руководством» и «отсутствия контакта с новым менеджером». Отдельный сигнал — сопротивление изменениям в команде и раздражение из-за Agile-терминов: «Если бы меня засыпали модными терминами, я бы ушёл», — признался один из респондентов.

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

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

4. Кандидаты с завышенными зарплатными ожиданиями

Многие работодатели сталкиваются с перекосом между запросами и квалификацией кандидатов. В исследовании сразу несколько HR-ов упомянули это как проблему: «завышенные ожидания зп», «малый объём знаний, но запрос в ₽ огромный». Такой разрыв часто становится стоп-фактором на этапе резюме — до собеседования дело даже не доходит. Но как понять, зарплатные что ожидания слегка (или не слегка) завышены?

Самый правильный и главный способ показать кандидату, что его зарплатные ожидания завышены — собеседование с t-shaped секцией. Сейчас тренд на широкие сайд знания. Без них ты скоро будешь просто не востребован. Соответственно, если вы ищите senior frontend разработчика и к вам приходит кандидат, который ни разу не трогал nginx за 7 лет стажа, то ему будет очень легко объяснить, почему его ожидания в 550 тысяч на руки не соответствуют вашим ожиданиям от позиции senior. Кнопочки красить может бОльшая часть рынка. А вот делать что-то интересное и сложное — только senior’ы, которых единицы. Станьте им и будете востребованы.

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

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

На ситуацию накладывается и то, что требования ужесточают. Компании всё реже готовы брать специалистов «на вырост» и хотят видеть людей, способных закрыть задачу с того дня, как она поступит. Отсюда и дополнительный барьер: тем, кто не может показать уверенный mid/senior-уровень по ключевым стекам, но рассчитывает на высокий оффер, становится всё труднее пробиться.

Ещё одна тенденция — усиленный запрос на мультискилловость. Разработчики, способные совмещать фуллстек, DevOps и cloud-компетенции, на рынке выигрывают. А те, кто может предложить только узкую экспертизу без бизнес-ориентации, проигрывают даже на фоне менее опытных, но гибких специалистов.

5. Специалисты на 100% удалёнку в гибридную эпоху

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

Даже высококвалифицированные разработчики сталкиваются с ограниченным числом предложений при условии «только remote». В то же время работодатели всё чаще требуют присутствия в офисе 2–3 дня в неделю, даже если раньше позиция была полностью удалённой. Это создаёт дополнительный фильтр: часть специалистов не готова к офисному возвращению и продолжает искать только удалённые вакансии, которых становится меньше.

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

Ещё один фактор — конкуренция с локальными кандидатами в крупных городах. Несмотря на онлайн-формат собеседований, многие компании стали отдавать предпочтение тем, кто живёт в столице или готов к релокации.

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

Зачем айтишники сравнивают зарплаты — и что это меняет в поиске работы

В IT-среде обсуждение зарплат до сих пор выглядит как табу — хотя всё чаще именно эта тема становится точкой напряжения в команде. Кто-то случайно увидел чужой оффер, кто-то получил информацию впрямую — и теперь сложно не сравнивать. Особенно, если вы делаете примерно одно и то же, но коллега получает на 30% больше. В таких ситуациях легко обидеться, почувствовать несправедливость и уйти в себя. Или в телеграм-чаты. Но что делать осознанно и прагматично?

Что точно не стоит делать

1. Выносить претензию на эмоциях

Разговор о деньгах требует спокойного тона и ясных аргументов. Резкие формулировки или отсылки на других коллег могут поставить руководителя в оборонительную позицию и испортить коммуникацию.

Эксперты выделяют форматы прозрачности компенсаций, которые реально снижают текучку:

Заранее обсуждать рост зарплаты и бонусов

• Руководитель не всемогущ, есть годовой бюджет с заложенными зарплатами, и любые изменения требуют согласований.
• Лучшее время обсуждать повышение — сентябрь-октябрь, чтобы заложить изменения в бюджет следующего года.
• Если нужно повышение срочно, можно фокусироваться на бонусах и бенефитах, их проще изменить вне бюджета.

Прозрачные зарплаты и понятная система премирования

• Открытые диапазоны и ясные принципы выплат помогают сотрудникам понимать, за что и как можно получить повышение.
• Если повышают одному, другим должно быть понятно, почему и что нужно сделать, чтобы получить такой же рост.
• Такой подход снижает недовольство и текучку, когда бизнес не стремится экономить на сотрудниках каждую копейку, а строит эффективную и «честную» систему оплаты.

2. Сравнивать себя с другими напрямую

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

3. Формулировать требования без обоснования

Фраза «я хочу больше» сама по себе — не аргумент. Повышение зарплаты обосновано, когда есть факты: вырос уровень ответственности, изменилась зона влияния, появились новые компетенции.

Но какие данные о своей работе должен собрать разработчик за квартал, чтобы обосновать +30 % к зарплате без «я хочу больше»?

Как минимум, оценить что конкретно сделал разработчик (прямо выписать свои реальные достижения), подсветить моменты, где он проявлял инициативу и что дало заметное преимущество в том или ином виде. Если есть возможность принести цифры — это будет еще лучше.

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

Что делать вместо этого

Соберите рыночные ориентиры

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

Оцените динамику своей роли

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

Разберите свои реальные зоны влияния

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

Назначьте разговор о росте заранее

Подготовьтесь к 1:1 или перформанс-ревью. Аргументы типа «меня недооценивают» работают слабо, а вот фокус на развитии и чёткий план — наоборот. Например: «Я проанализировал рынок, вижу, что по моей роли в среднем платят столько-то. Вот что я уже делаю и что могу взять дополнительно. Можем обсудить возможность пересмотра компенсации через N месяцев при достижении этих результатов?»

Параллельно исследуйте рынок

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

Что делать, если не удаётся найти работу 3–6 месяцев? Эксперты дают чек-лист:

1. Сначала стратегия — потом действия

Определите:

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

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

2. Выясните, где узкое место

Дмитрий Борцов подчеркивает: «Нет контактов с HR’ами? Или валите техсобес? Или просмотров мало? В зависимости от ответа — начинайте читать план с нужного пункта». Он рекомендует:

• откорректировать резюме с ментором, HR или с помощью AI;
• изучить, как работают автофильтры, и убрать свои «красные флаги»;
• тестировать разные форматы коммуникации, фиксировать конверсию;
• записывать техсобесы и делать разборы для исправления ошибок.

3. Используйте менторство и комьюнити

Сергей Филичкин делится: «Самому бывает трудно выйти из привычного круга действий. Ментор может помочь сменить угол зрения и начать действовать по-новому». Ведь у менторов есть программы, ученики, опыт, успешные кейсы трудоустройства. Очевидно они знают о рынке больше.

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

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

Ну а если вы давно в поиске работы, собрали топовые лайфхаки, которые помогут.

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

Hard

Наш хардовый трек — для тех, кто в проде с закрытыми глазами. API First, компонентные и контрактные тесты, мониторинг и SRE. Обсудим реальные кейсы нашего банка и как мы создаём системы, которые работают стабильно и эффективно.

Как внедрить API First в сложную финтех-инфраструктуру с учетом legacy-систем? Разберем, почему стандарт AsyncAPI не всегда подходит для крупных систем, как мы адаптировали его под наши реалии и разработали собственные инструменты.

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

Head of profession QA Кристина Клигер поделится, как через развитие команды тестирования можно быстро доставлять фичи до клиентов и радовать бизнес.

Глава центра развития ИТ-мониторинга Валентин Лебедев раскроет секреты превращения мониторинга в сервис. Живет ли OpenSource в крупных предприятиях?

Soft

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

СТО Виктор Цветков и Head of profession SA Юлия Григорьева расскажут, какие способы внедрения изменений существуют по степени мягкости. Почему важно учитывать корпоративную культуру при работе с изменениями. Далее поговорим про неотъемлемую часть — обучение команды и работе с их сопротивлением новым практикам. Поделимся нашими лайфхаками и секретами.

Head of Profession Вадим Ваганов объяснит, зачем коммитить в main несколько раз на дню. Спойлер: чем чаще релизишься, тем меньше ошибок.

Техлид Роман Олеск поделится лайфхаками для успешного роста ваших инженеров. Расскажем о матрице инженерных ролей и компетенций, а также о персональных треках развития сотрудников.

Экспозона

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

16 стендов объединят вместе ИТ-направления в нашем банке:

Data Science, RPA, Искусственный интеллект, Инновации, Database, Backend, QA, DevOps, Frontend, Мобильная разработка iOS и Android, Product Design, Кибербезопасность, Business Analysis, System Analysis, IT Recruitment и Agile.

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

Нетворкинг

После официальной части мероприятия приглашаем остаться и продолжить общение в неформальной обстановке. С нас космические угощения и напитки!

Как закоммититься

Вход по мультипаспорту:)

Торопись, количество мест ограничено!

До встречи на GPB CONF!

А тут можно узнать больше о наших проектах.

Вместе с Артемом Геташвили и Анастасией Редченковой, менторами Solvery, мы собрали ТОП-10 самых раздражающих вещей, которые сводят программистов с ума.

Почему разработчики так часто жалуются?

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

Миф о том, что разработчики просто «пишут код»

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

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

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

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

Иногда они не дают спать, есть и нормально жить. Бывают простые баги, которые раскапываешь и чинишь за пару часов, а бывает, что ты на неделю-две уходишь в нее с головой. Если видите в 2 часа ночи где-нибудь человека на кухне с ноутбуком, кофе и красными глазами — это точно программист.

Почему раздражение — это нормально? (Но как не довести себя до выгорания?)

Работа программиста — постоянное решение проблем. А где проблемы, там и стресс. Однако раздражение само по себе — еще не катастрофа. Оно становится проблемой, только если переходит в хроническое состояние.

Как понять, что раздражение не угрожает вашему психическому здоровью?

Здоровое раздражение:

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

Выгорание:

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

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

Реальные причины, которые взрывают разработчикам мозг

Вместе с экспертами определили топ-10 вещей, которые выводят из себя даже самых стойких разработчиков.

Нереалистичные сроки

Что бесит?

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

Как бороться?

• Аргументировать реалистичные оценки сроков.
• Документировать риски и объяснять, почему спешка ухудшает результат.
• Использовать Agile и регулярные переоценки задач.

Постоянные прерывания и невозможность сконцентрироваться

Что бесит?

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

Как бороться?

• Блокировать время для глубокой работы.
• Устанавливать «тихие часы» в команде.
• Использовать методы Pomodoro, ALPEN, GTD и прочие.
• В офисе советую работать в наушниках с шумоподавлением.

Технический долг

Что бесит?

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

Как бороться?

• Внедрить правило в команде по обязательному рефакторингу каждый спринт (примерно 10–20% времени будет хватить на улучшение кодовой базы).
• Проводить код-ревью и следить за чистотой кода.
• Объяснять руководству, почему технический долг замедляет разработку.

Размытые и постоянно меняющиеся требования

Что бесит?

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

Как бороться?

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

Плохая документация

Что бесит?

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

Как бороться?

• Создавать и поддерживать актуальную документацию.
• Следовать стандартам оформления документации.
• Автоматизировать процесс обновления документации (например, Swagger).

Культура переработок

Что бесит?

В IT нередко ожидают, что ты будешь работать сверхурочно, чинить баги в продакшене ночью и быть на связи 24/7. Это ведет к выгоранию и снижению мотивации.

Как бороться?

• Четко устанавливать границы рабочего времени.
  
• Искать компании, где соблюдаются нормы трудового кодекса.
• Говорить «нет» переработкам, если это не форс-мажор.

Проблемы с зависимостями в проекте

Что бесит?

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

Как бороться?

• Фиксировать версии зависимостей.
• Использовать инструменты автоматической проверки совместимости.
• Регулярно обновлять пакеты, чтобы не копить проблемы.

Недооцененность работы разработчика

Что бесит?

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

Как бороться?

• Показывать метрики и результаты работы.
• Объяснять технические решения простым языком.
• Искать признание среди коллег и в профессиональном сообществе.

Необходимость постоянно учить новые технологии

Что бесит?

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

Как бороться?

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

Ошибки, которые сложно отловить (дебаг и баги)

Что бесит?

Программа падает без понятной причины, баги воспроизводятся только «раз в 1000 запусков», а логи ничего не говорят.

Как бороться?

• Использовать системы логирования и мониторинга (например, Sentry, Datadog).
• Разрабатывать с учетом отладочности (например, писать больше тестов).
• Применять методы бэктрекинга, чтобы анализировать ошибки шаг за шагом.

Разработка — не только творчество, но и борьба с кучей раздражающих факторов. Однако понимание проблем и работа над их устранением помогают сделать жизнь программиста проще.

Какой из этих пунктов раздражает вас больше всего? Делитесь в комментариях!

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

YouGile

YouGile — российская система управления проектами с собственным мессенджером. Благодаря простоте интерфейса и возможностям для общения внедряется за пару часов.

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

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

Есть облачная и коробочная версии. Работать с YouGile можно на любых устройствах: веб-версия, приложения для Windows, macOS, Linux, Android и iOS.

Интеграции. Готовые интеграции, например, с Telegram или почтой, можно включить с помощью расширений. Тариф «Платформа» позволяет командам создавать свои интеграции с помощью инструментов low-code.

Поддержка.

— Каналы связи. Команда отвечает по почте или внутри системы. Средняя скорость ответа — 15 минут.

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

Безопасность. Отвечает всем требованиям безопасности, состоит в реестре отечественного ПО.

Стоимость. Бесплатно для 10 человек — с полным функционалом без ограничений. С 11-го оплата по 495 ₽ в месяц при оплате за год.

Полные условия тарифов по ссылке

Kickidler

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

Есть ещё отчёты по продуктивности: сколько времени сотрудник действительно работал, а сколько листал соцсети или просто сидел в простое. Причём никаких ручных замеров: система сама считает, кто опоздал, кто ушёл пораньше, а кто провёл день в мессенджерах.

Для работы с проектами в Kickidler тоже всё предусмотрено: учет времени по задачам, анализ загрузки команды и отчеты, которые помогут понять, где сотрудник перегружен, а где наоборот простаивает. Причем следить можно разными способами — кто-то ставит строгий режим с кнопкой «старт-стоп», а кто-то просто смотрит, как совпадает активность в программах с итогами дня.

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

Интеграции. Kickidler не имеет встроенных интеграций, но есть API для подключения к популярным сервисам — Битрикс24, amoCRM, Jira, Trello.

Поддержка.

— Каналы связи. Можно обратиться за помощью через telegram, whatsapp или по номеру телефона. Отвечают в пределах 15 минут.

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

Безопасность. Сервис соответствует требованиям защиты данных в Российской Федерации (152-ФЗ). Все данные хранятся на серверах в России.

Стоимость. Есть бесплатная версия для одного сотрудника — чтобы просто попробовать. Полноценный контроль начинается с тарифа от 200 ₽ в месяц, а максимальный набор функций с видеозаписями, кейлоггером и полным мониторингом стоит от 600 ₽ в месяц.

Полные условия тарифов по ссылке

Битрикс24

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

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

Чем выделяется. CoPilot — встроенный AI-помощник. Он работает прямо в CRM, задачах, чатах и помогает не отвлекаться на мелочи: придумает текст, расшифрует звонок или заполнит карточку сделки.

Собственный сервис для видео — тоже редкость. Главное же отличие в комплексности всей системы.

Интеграции. Zadarma, ЮKassa, Эвотор, АТОЛ, СДЭК. Через REST API можно подключать системы, которые не интегрированы изначально.

Поддержка.

— Каналы связи. Можно найти ответ на свой вопрос в большой базе данных или напрямую оператору. Отвечают в течение 20 минут.

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

Безопасность. Сервис соответствует требованиям защиты данных в Российской Федерации (152-ФЗ). Вся информация хранится в защищенном облаке с резервным копированием и историей изменений. Также предусмотрена настройка прав доступа — можно ограничить, кто видит или редактирует задачи, документы и сделки.

Стоимость. Есть бесплатный тариф с базовыми возможностями. Платные начинаются от 1 990 ₽ в месяц для небольших команд и доходят до 11 190 ₽, если нужна полная автоматизация процессов.

Полные условия тарифов по ссылке

ПланФикс

ПланФикс — система для управления задачами, проектами и бизнес-процессами. Здесь можно выстроить рабочее пространство и процессы с нуля, под любые задачи: от ведения проектов и переписок с клиентами до учета времени и аналитики.

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

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

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

Интеграции. Telegram, WhatsApp, ВКонтакте, Google Drive, OneDrive, 1С. Также доступны интеграции с сервисами рассылок и SMS. Есть API.

Поддержка.

— Каналы связи. Поддержка отвечает через тикеты в самом ПланФикс. Отвечают в течение 5-10 минут.

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

Безопасность. Planfix размещен в дата-центрах Европы, Северной Америки и Азии, соответствующих международным стандартам безопасности. Данные защищены шифрованием TLS 1.2, доступ ограничивается по IP, настраиваются права и 2FA. Система ведет логи изменений и создаёт резервные копии автоматически.

Стоимость. У ПланФикса есть бесплатный тариф, но он подойдет скорее для небольших задач и простых процессов. В нём ограничены фильтры, шаблоны, количество проектов и контактов, нет диаграммы Ганта, автоматизаций и работы со сделками.

Если нужен полноценный функционал, например, аналитика, расширенные сценарии, отчеты и больше интеграций, придётся переходить на платные тарифы. Цены начинаются от $8 в месяц за пользователя, а итоговая сумма зависит от числа сотрудников и выбранных возможностей. Для старта дают тестовый доступ на 30 дней, чтобы попробовать систему без ограничений.

Полные условия тарифов по ссылке

Мегаплан

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

Для продаж предусмотрены воронки, карточки клиентов и история взаимодействий. Есть учёт звонков, писем и напоминаний, возможность автоматизировать сделки и фиксировать результат через отчёты. Отдельно предусмотрены финансовые модули, складской учёт, документооборот и аналитика.

Чем выделяется. Если многие сервисы специализируются либо на проектах, либо на CRM, либо на учёте времени, то Мегаплан сочетает сразу все: проекты, задачи, CRM с воронками продаж, документооборот, учет звонков и писем, финансы и аналитику. Это удобно для бизнеса, который хочет вести и проекты, и клиентов в одной системе, без перескоков между разными инструментами.

Интеграции. Mango Office, UIS, Zadarma, 1С, Мой Склад, Roistat, SendPulse, DashaMail, JivoSite, Telegram, WhatsApp, CRM. Есть API.

Поддержка.

— Каналы связи. Поддержка работает через заявки, чат и документацию. Отвечают в течение 5-10 минут.

— База знаний и обучающие материалы. Есть подробная база знаний на официальном сайте.

Безопасность. Сервис соответствует требованиям 152-ФЗ, данные хранятся на серверах в России, поддерживается протокол HTTPS. Включен в реестр отечественного ПО. Для подключения электронной почты используется двухфакторная авторизация через пароли для приложения.

Стоимость. Бесплатного тарифа в Мегаплане нет, но можно воспользоваться пробным периодом на 14 дней.

Дальше — только платные подписки. Цена зависит от количества сотрудников и выбранного тарифа:

— от 11 900 ₽ в год за 3 пользователей на тарифе «Совместная работа» (если нужен только базовый функционал для задач и проектов),

— до 46 800 ₽ в год за 5 пользователей на тарифе «Клиенты и продажи+» (если важна CRM с воронкой продаж, задачами и интеграцией с 1С).

Отдельно можно купить коробочную версию для установки на сервер компании. Это дороже, зато система полностью под вашим контролем.

Полные условия тарифов по ссылке

Аспро.Cloud

Аспро.Cloud — российская облачная CRM для управления продажами, проектами, задачами и финансами. Сервис помогает держать весь рабочий процесс под контролем: от первой заявки до акта выполненных работ и закрытия сделки. Здесь удобно вести клиентов, формировать счета, следить за дедлайнами и считать прибыль по каждому проекту.

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

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

Интеграции. 1С, Tilda, DaData и Mango Office. Можно настроить автоматическую отправку счетов в бухгалтерию, принимать оплату через СБП и платежные системы.

Поддержка.

— Каналы связи. Поддержка работает чат на сайте, почту и в Telegram. Отвечают в течение 5-10 минут.

— База знаний и обучающие материалы. Есть блог с полезными материалами и отдельное обучение сотрудников компаний CRM внутри Аспро.Cloud.

Также можно получить онлайн-консультацию по всем инструментам Аспро.Cloud и сделать выбор — подходит ли система и какие бизнес-задачи сможет решить.

Безопасность. Сервис соответствует требованиям защиты данных в Российской Федерации (152-ФЗ). Весь трафик шифруется TLS.

Стоимость. Тарифы начинаются от 2090 ₽ в месяц за команду до 5 человек. Для старта есть бесплатный с базовыми возможностями и пробный период на 14 дней с полным функционалом.

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

Полные условия тарифов по ссылке

Pyrus

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

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

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

Чем выделяется. В Pyrus есть встроенный конструктор бизнес-процессов, который позволяет настроить любые процессы с маршрутами, формами, правилами и ролями — без привлечения программистов.

Это удобно для согласования документов, заявок, договоров, отпусков и других типовых задач, которые проходят через несколько этапов и участников. Есть встроенные решения для работы с договорами, службой поддержки, кадрами, задачами и счетами. Плюс интеграции с ERP, CRM, Active Directory, облачными хранилищами, а для сложных кейсов — API и поддержка кастомных скриптов.

Интеграции. Google Drive, Dropbox, Box, OneDrive, Telegram, WhatsApp. Также может синхронизировать данные с ERP и бухгалтерскими системами.

Поддержка.

— Каналы связи. Поддержка работает через Telegram-бота, Whats’up и сайт. Отвечают в течение 15 минут. Кстати, пользователи отмечают в отзывах, что поддержка не перекидывает заявки между специалистами, а решает вопросы на месте.

— База знаний и обучающие материалы. На сервисе помогают с обучением, настройками и внедрением системы в работу.

Безопасность. Сервис соответствует 152-ФЗ, данные хранятся в двух защищенных дата-центрах. В случае сбоя одного копия останется на втором. Трафик шифруется TLS, есть двухфакторная авторизация.

Стоимость. Стартапу с 15 сотрудниками хватит бесплатной версии, чтобы вести задачи, согласовывать документы и не потеряться в чатах. А если нужен Service Desk, учет договоров, кадровые заявки и аналитика — подключаются платные тарифы от 415 ₽ в месяц на пользователя.

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

Полные условия тарифов по ссылке

WEEEK

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

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

Чем выделяется. В сервис встроена виртуальная помощница Вика на базе Chat GPT. Она обучена на внутренней документации сервиса и помогает пользователям разбираться с настройками, интеграциями и типовыми вопросами. Благодаря ей не нужно тратить время на поиск ответов в базе знаний или ждать отклика поддержки — Вика подскажет, как решить задачу прямо внутри интерфейса.

Интеграции. Telegram, Google, Яндекс и Apple календари, Trello, Jira и Asana. Есть API.

Поддержка.

— Каналы связи. В WEEEK доступны несколько каналов связи: команда отвечает через чат на сайте, Telegram и почту, в среднем за полчаса.

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

Безопасность. Сервис соответствует 152-ФЗ и GDPR, данные хранятся в России, защищены HTTPS. Есть 2FA для дополнительной безопасности.

Стоимость. У WEEEK есть бесплатная версия для небольших команд до 5 человек — она подойдёт для работы над простыми проектами без ограничений по времени. А для студентов и преподавателей сервис бесплатно предоставляет подписку PRO с расширенными возможностями.

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

Полные условия тарифов по ссылке

Shtab

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

Для планирования помогут разные режимы отображения: kanban, список, календарь, Матрица Эйзенхауэра, а для сосредоточенной работы пригодится Pomodoro-таймер — настроил интервалы, и трекер сам напомнит, когда пора отдохнуть.

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

Чтобы защитить сотрудников от утечек личной информации, в Shtab встроена нейросеть, которая автоматически проверяет скриншоты и замыливает (блюрит) чувствительные зоны, например, приватные сообщения в мессенджерах.

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

Интеграции. Jira, Trello, Asana, ClickUp, Модульбанк, Telegram. Есть API.

Поддержка.

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

— База знаний и обучающие материалы. Есть всё что нужно для старта работы: инструкции, видеоуроки и комьюнити в Telegram, где можно уточнить нюансы работы сервиса.

Безопасность. Shtab хранит данные в российских дата-центрах Selectel (Москва, Санкт-Петербург) и соответствует требованиям 152-ФЗ. Скриншоты автоматически проверяет нейросеть, а соединение защищено TLS 1.2 — как в банках. Команда 24/7 следит за безопасностью, проводит проверки и тесты.

Стоимость. Для небольших команд есть бесплатный тариф — до 5 человек и 5 проектов, с трекером времени без скриншотов и 1 ГБ хранилища. Если нужна расширенная аналитика, скриншоты и больше места под файлы, подойдут платные тарифы от 190 ₽ в месяц.

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

Полные условия тарифов по ссылке

Яндекс.Трекер

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

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

Чем выделяется. Есть живые задачи, которые обновляются прямо на странице без перезагрузки, напоминания и «призывы» коллег к задачам. Можно строить собственные очереди с нужными полями, настраивать статусы, правила переходов, права доступа и шаблоны процессов. Для визуального контроля подключаются дашборды с ключевыми показателями, а для сложных интеграций — API и работа через Яндекс ID, SSO или Active Directory.

Интеграции. Яндекс 360, Яндекс.Диск, Яндекс.Метрика и другие продукты Яндекса. Есть API.

Поддержка.

— Каналы связи. Поддержка отвечает через стандартные каналы Яндекса, помогает с настройками и переходом с других систем. Отвечают в течение 15 минут.

— База знаний и обучающие материалы. Есть сайт с документацией а также вводный вебинар про работу в Яндекс.Трекере.

Безопасность. Сервис соответствует требованиям защиты данных в Российской Федерации (152-ФЗ). Все данные размещены на серверах в России. Двухфакторная авторизация (2FA) реализована через внутренний сервис Яндекс ID.

Стоимость. Небольшой компании на 5 человек хватит бесплатного тарифа, чтобы организовать работу, а для среднего бизнеса есть тариф 400 ₽ в месяц за пользователя с расширенными возможностями.

Полные условия тарифов по ссылке

GanttPro

GanttPRO — облачный инструмент, который помогает планировать и контролировать проекты через классическую диаграмму Ганта. Сервис автоматически считает зависимости задач, критический путь, загрузку ресурсов и помогает наглядно управлять сроками и нагрузкой команды.

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

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

Интеграции. Jira Cloud, Slack, Google Диск. Есть API.

Поддержка.

— Каналы связи. Можно заполнить форму обратной связи на сайте, и менеджер свяжется в течение дня. ​Отвечают в течение 5-10 минут.

— База знаний и обучающие материалы. Есть отдельный учебный центр для всех клиентов с базой знаний. А для корпоративных клиентов на Enterprise-тарифе есть индивидуальное сопровождение, помощь в обучении команды и расширенные лимиты API.

Безопасность. Данные хранятся в частной сети Microsoft Azure (Западная Европа). Сервис поддерживает многофакторную авторизацию, резервное копирование, HTTPS и соответствует 152-ФЗ. 2FA можно включить в настройках.

Кому подойдет для работы. Если нужен строгий финансовый учёт с тарифами, договорами и автоматическим выставлением счетов — GanttPRO для этого не подойдёт. Но для классического проектного управления с фокусом на сроки, людей и план-фактный анализ — это удобный и понятный инструмент с готовыми шаблонами и аквапланированием.

Стоимость. Тарифы начинаются от $7,99 в месяц за пользователя, а протестировать функционал можно бесплатно в течение 14 дней.

Полные условия тарифов по ссылке

Kaiten

Kaiten — сервис, который помогает командам настроить работу по Kanban и Scrum, организовать задачи, следить за их статусом и анализировать результаты. Продукт разработан в России, размещён на российских серверах, что гарантирует стабильность работы и защиту от блокировок.

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

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

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

Интеграции. Telegram, Google Календарь, Outlook, Slack, GitHub, Jira, Trello, Google Формы, Яндекс Календарь. Есть API.

Поддержка.

— Каналы связи. Есть веб-форма на сайте, telegram-бот, куда можно отправлять вопросы по работе с системой. Отвечают в течение 5-10 минут.

— База знаний и обучающие материалы. Есть отдельный блог с полезными статьями и комьюнити в Telegram.

Безопасность. Соответствует 152-ФЗ, защищен по HTTPS, не собирает персональные данные. Для крупных компаний — On-Premise, индивидуальные тарифы и функции. Есть 2FA.

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

Если нужны расширенные возможности, можно выбрать один из платных тарифов: Standard (от 420 ₽ в месяц за пользователя) с двумя модулями на выбор, PRO (от 560 ₽) с шестью модулями или Enterprise с индивидуальной ценой для крупных компаний — с установкой на собственные серверы, кастомизацией, поддержкой и дополнительной разработкой под бизнес.

Полные условия тарифов по ссылке

LeaderTask

LeaderTask — российский таск-менеджер для личной и командной работы. Сервис помогает организовать задачи, проекты и поручения, вести учёт времени и подключать методы тайм-менеджмента вроде GTD, Pomodoro или Scrum. Особенно популярен у тех, кто ищет простой инструмент для планирования без сложных настроек и длительного обучения.

Чем выделяется. У LeaderTask есть функция, которая превращает письма в задачи автоматически. Просто пересылаете письмо на специальный адрес, и оно появляется в списке дел, без копипаста и ручного переноса.

Интеграции. Пока только с Telegram.

Поддержка.

— Каналы связи. Есть онлайн-чат на сайте и адрес электронной почты, куда можно написать за помощью. А также найти ответ на вопрос в в базе FAQ. Отвечают в течение 5-10 минут.

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

Безопасность. Данные хранятся в российских дата-центрах Cloud4Y (ISO 27001), бэкап — ежедневно. Есть офлайн-режим, защита паролем и 2FA.

Поддержка и безопасность. Стоимость. Для личного использования есть бесплатный тариф с ограничением на одно устройство, до 100 задач и трёх досок. Если нужна синхронизация и больше функций — подойдет тариф «Премиум» за 3199 ₽ в год. Для команд предусмотрен тариф «Бизнес» с поручениями, общими проектами, досками и историей изменений — от 4999 ₽ в год за пользователя.

Полные условия тарифов по ссылке

Easy Task

Easy Task — российская система для управления проектами, задачами и бизнес-процессами, которая помогает командам держать работу под контролем и видеть узкие места. Сервис фиксирует загрузку сотрудников, помогает выявить просрочки и наладить прозрачность процессов — от первых идей до выполнения задач. Easy Task работает в облаке, входит в реестр отечественного ПО и поддерживает работу с мобильных устройств, браузера и через Telegram-бота.

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

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

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

Интеграции. Пока только с Telegram.

Поддержка.

— Каналы связи. Можно обратиться за помощью по номеру телефона на официальном сайте. Отвечают в течение 5-10 минут ожидания на линии.

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

Безопасность. Соответствует требованиям защиты данных в Российской Федерации (152-ФЗ). Данные хранятся в российских дата-центрах. 2FA пока нет.

Стоимость. Для команд до 5 человек Easy Task доступен бесплатно без ограничений по времени. Если команда больше — можно протестировать систему 14 дней бесплатно, а затем выбрать подходящий тариф: от 49₽ в месяц за пользователя при годовой оплате. Повторюсь: модули оплачиваются отдельно, чтобы можно было платить только за нужные функции.

Полные условия тарифов по ссылке

ELMA365

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

Чем выделяется. Редактором бизнес-процессов. Можно настроить сценарии работы, автоматизировать переходы между этапами сделок, уведомления и задачи для смежных отделов. Например, подключить бухгалтерию для расчетов по заказу, производство для подготовки сметы, юристов для согласования договора — и всё это в одном процессе.

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

Интеграции. 1С, SAP, Oracle, MS Dynamics, Контур.Диадок.

Поддержка.

— Каналы связи. Можно обратиться за помощью через Telegram или электронную почту. Отвечают в течение 15-20 минут.

— База знаний и обучающие материалы. Есть база знаний по сервису ELMA365.

Безопасность. ELMA 365 доступен в браузере и мобильном приложении, в облаке и On-Premise. Соответствует 152-ФЗ, поддерживает ЭП. Есть 2FA через Telegram или почту.

Стоимость. Тестировать систему можно бесплатно 14 дней. Дальше тариф зависит от числа пользователей и варианта размещения:

— от 500 ₽ в месяц за пользователя (при облачной подписке);

— от 17 000 ₽ за пользователя (единовременно, при установке на сервер).

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

Полные условия тарифов по ссылке

Projecto

Projecto — российский сервис для управления проектами, задачами и документами в одном окне. Подходит для тех, кто устал переключаться между разными инструментами и хочет держать работу команды под контролем: от идей до готовых проектов. Работает в браузере, на Android, iOS и даже macOS, а вся информация синхронизируется между устройствами.

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

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

Интеграции. Zoom и почта — пока все.

Поддержка.

— Каналы связи. Можно написать через Telegram-бота или по электронной почте. Техподдержка отвечает в течение 10-20 минут.

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

Безопасность. Данные защищены, система соответствует требованиям 152-ФЗ. Также сам сервис состоит в реестре отечественного ПО. 2FA есть.

Стоимость. Цены зависят от срока подписки и количества пользователей:

— от 400 ₽ за человека в месяц при помесячной оплате;

— до 288 ₽ в месяц при оплате сразу на год (от 201 пользователя).

Для соло-работы есть тариф «Персональный» — 4 800 ₽ в год. Пробный период тоже предусмотрен.

Полные условия тарифов по ссылке

Moo.Team

Moo.Team — минималистичная по форме система для управления задачами. Сервис совмещает в себе таск-трекер, тайм-трекер, базу знаний, менеджер паролей и инструмент для ведения проектов.

Чем выделяется. Moo.Team сочетает управление проектами и задачи с мониторингом сайтов: интегрируется с сервисами по аналитике и SEO-оптимизации. Позволяет отслеживать состояние сайтов, анализировать трафик и выявлять проблемы в одном окне. Особенно полезно для веб-студий, SEO-специалистов и digital-агентств.

Кроме того, Moo.Team гибко подстраивается под самые разные команды — от юристов и HR-специалистов до разработчиков и креативных агентств.

Интеграции. Google Drive, Яндекс.Метрика, Яндекс.Вебмастер и Google Search Console, Telegram и почта.

Поддержка.

— Каналы связи. Связаться с техподдержкой Moo.Team можно через Telegram-бота или по электронной почте. Поддержка отвечает оперативно — обычно в течение 10–20 минут.

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

Безопасность. Данные защищены по 152-ФЗ, хранятся в дата-центрах с облачным дублированием. Есть 2FA и многофакторная аутентификация.

Стоимость. Тариф зависит от размера команды. Бесплатно можно работать до 3 человек и вести до 2 проектов с полным функционалом.

Базовый тариф на 10 человек стоит 990 ₽ в месяц, тарифы на 30 и 50 сотрудников — 2 990 ₽ и 4 990 ₽. Если пользователей больше, условия обсуждаются индивидуально. Хранилище данных и число проектов тоже растёт вместе с тарифом, а функционал остается одинаковым на всех уровнях.

Полные условия тарифов по ссылке

Dtrack

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

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

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

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

Поддержка.

— Каналы связи. Связаться с техподдержкой DTrack можно через Telegram-бота, Whats’up или по электронной почте. По скорости ответа информации нет.

— База знаний и обучающие материалы. Есть общая документация по сервису.

Безопасность. DTrack защищает данные по 152-ФЗ, передача — по HTTPS, хранение — в приватном облаке (СПб). 2FA пока нет.

Стоимость. У Dtrack всего два тарифа:

— Бесплатный: до 2 пользователей, 500 Мб хранилища и ограничение на размер файлов до 50 Мб.

— Платный: от 50 ₽ в месяц за пользователя, до 1000 человек в команде, 5 Гб на человека и увеличенный лимит на файлы до 200 Мб. Платный тариф подключается автоматически при добавлении третьего пользователя.

Полные условия тарифов по ссылке

Поделитесь в комментариях, какими сервисами для управления проектами пользуетесь:)

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

С чего все началось

На одном митапе по стандарту разработки нам с Head of Profession задали вопросы, которые зависли в воздухе, как нерешенный баг в коде: «А что за потребность все делать с помощью As Code? Какая от этого польза? Зачем число коммитящих в код?»

Мы, как архитекторы инженерной культуры, внедряем лучшие практики и подходы: Infrastructure as Code, API First, unit-тесты, компонентное тестирование, TBD (Trunk Based Development), GitOps, Doc As Cod. Мы дорабатываем пайплайны, как инженеры, собирающие сеть в подвале старого дата-центра. Мы создаем условия для Continuous Deployment с продуктовыми платформами, где blue-green deployment и canary deployment становятся порталами для перехода прода из одного состояния в другое.

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

В момент осознания вопроса я провалился на другой слой реальности, задумался об истории As Code и собрал этот текст из разбросанных по сети слепков. Эта статья — не руководство по Terraform или Kubernetes, а скорее практический взгляд на культуру As Code в масштабах крупной IT-компании.

Эволюция As Code: от истоков до современности

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

У появления этого подхода было несколько предпосылок:

1. Автоматизация и стандартизация. В 1990-х годах с развитием DevOps и agile-методологий возникла потребность в автоматизации процессов разработки и управления инфраструктурой. Новые задачи стали основой для появления подходов, где все описывается в виде кода.
2. Распространение систем контроля версий. В 2005 году появился Git, который стал инструментом для управления изменениями, что позволило хранить и версионировать не только код, но и документацию, конфигурации и архитектуры.

Корнями As Code уходит в 1970-е годы. Ранние инструменты, такие как Unix “Make” и PXE boot, заложили фундамент для автоматизации конфигураций. Позже они эволюционировали в современные подходы: Infrastructure as Code, Documentation as Code, GitOps и другие. Это подчеркивает, что As Code — не просто тренд, а естественное развитие технологий, которое упрощает управление сложными системами.

Почему все теперь в Git?

С развитием подхода As Code универсальным инструментом управления изменениями стал Git. Это произошло благодаря нескольким ключевым причинам.

• История изменений: Git хранит всю историю изменений, что позволяет отслеживать, кто, когда и что делал. Это критически важно для анализа и отката ошибок.
• Коллаборация: над проектом может работать несколько человек, и они не будут мешать друг другу.
• Прозрачность: все изменения видны, их можно обсудить, проверить и улучшить через механизмы pull/merge requests.
• Автоматизация: Git интегрируется с CI/CD — Continuous Integration / Continuous Deployment. Это позволяет автоматизировать тестирование, сборку и деплой. Работа в Git позволяет «все иметь под рукой» и упрощает создание систем поддержки и контроль стандартов ИТ-производства.
• Безопасность: Git позволяет контролировать доступ к коду и данным через ролевую модель и механизмы проверки изменений.

Как появился Git?

Git был создан в 2005 году как ответ на кризис в разработке ядра Linux. Ранее команда Linux использовала проприетарную систему контроля версий BitKeeper, но юридические споры лишили программистов этой возможности. Linux-сообщество осталось без инструмента для управления кодом. Существующие системы — например, CVS или Subversion — не подходили для масштабных проектов.

Линус Торвальдс, создатель Linux, решил разработать собственную систему, которая бы отвечала потребностям крупных проектов:

• была быстрой,
• поддерживала распределенную разработку,
• гарантировала сохранность данных (через хеши SHA-1).

Git был создан всего за 10 дней. Первая версия была настолько проста, что Торвальдс называл ее «игрушечной». При этом она уже решала ключевые задачи. Инструмент разработали с акцентом на децентрализацию: каждый разработчик имеет полную копию репозитория, что делает процесс гибким и устойчивым.

Создание Git — прекрасный пример проактивной позиции: если тебя что-то не устраивает, ты сам создаешь инструмент для решения задачи. Реагируешь на боль не нытьем, а делом, и оставляешь проблему позади. Этот инструмент родился из необходимости и стал революцией в мире разработки. Простота, скорость и распределенный подход сделали его незаменимым инструментом для команд любого масштаба.

Эволюция Git:

• 2005: первый релиз Git;
• 2008: появление GitHub, который популяризировал Git среди разработчиков;
• Сейчас: Git де-факто стал стандартом для контроля версий, который используют разработчики по всему миру.

Основные подходы As Code

Infrastructure as Code (IaC)

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

Когда мы слышим термин Infrastructure as Code, то обычно думаем о современных инструментах, таких как Chef, Ansible или Terraform. Однако сама идея управления инфраструктурой и конфигурациями через код уходит корнями в 1970-е годы. Уже тогда инженеры сталкивались с необходимостью автоматизировать управление парками машин, будь то физические или виртуальные системы.

Одним из первых инструментов, позволявших автоматизировать сборку и настройку программного обеспечения, был Unix “Make” (1976). Хотя Make не стал полноценным инструментом управления инфраструктурой, он заложил основы для автоматизации задач конфигурации. Следующим важным шагом к автоматизации стал PXE boot (1981). Он позволял загружать и настраивать по сети целые машины — это стало прообразом современных подходов к управлению инфраструктурой.

Хотя эти ранние инструменты не считаются полноценными решениями для управления инфраструктурой, они создали основу для современных подходов. Unix “Make” и PXE boot показали, что автоматизация конфигураций возможна и необходима, особенно с ростом сложности систем.

Как дальше складывалась эволюция IaC:

• 1990-е: следующий этап развития начался с появлением CFEngine (1993). Это был один из первых инструментов, позволявших управлять конфигурациями на множестве машин.
• 2000-е: с развитием облачных технологий и DevOps появились более мощные инструменты, такие как Puppet (2005) и Chef (2009). Они сделали управление через код отраслевым стандартом. 2010-е: Ansible (2012) и Terraform (2014) стали лидерами в области IaC. Они предложили более гибкие и мощные решения для управления облачной инфраструктурой.
• 2013: появился Docker, который произвел революцию в контейнеризации. Он обеспечил легкость в создании, развертывании и масштабировании приложений, а также упростил процессы управления инфраструктурой.
• 2014: Kubernetes предложил автоматизацию развертывания, масштабирования и управления контейнизированными приложениями.
• 2017: создан Pulumi, который позволил управлять ресурсами облачной инфраструктуры с использованием таких языков программирования, как Go, JavaScript, TypeScript, Python, Java, C# и YAML. Благодаря этому инструменту разработчики смогли быстрее интегрировать IaC в свои процессы и создавать более сложные сценарии для автоматизации.
• 2021: появился Brainboard, который значительно упростил разработку, визуализацию и управление инфраструктурой как кодом. Он предложил графический интерфейс для создания и изменения архитектуры облаков. Это помогло сделать IaC доступным не только для разработчиков, но и для более широкого круга пользователей, в том числе для аналитиков и проектировщиков.

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

Documentation as Code (Docs as Code)

Подход Docs as Code позволяет разрабатывать техническую документацию с помощью тех же инструментов, что и код. Документы создаются в формате, который легко версионировать и хранить в Git, — например, Markdown или AsciiDoc. Это дает значительные преимущества:

• актуальность — документация API или архитектуры хранится в репозитории рядом с кодом, благодаря чему всегда остается актуальной;
• версионирование — легко отслеживать изменения и возвращаться к предыдущим версиям;
• интеграция в процесс разработки — документация становится частью DevOps-практики и развивается в Git вместе с кодом.

Подход Docs as Code начал развиваться в 2000-х годах. В это время крупные компании, такие как Microsoft, начали использовать внутренние инструменты для генерации документации из исходного кода. Например, документация .NET Framework уже создавалась с помощью автоматизированных процессов.

В 2010-х годах термин Docs as Code был популяризирован. Тогда такие инструменты, как Markdown, AsciiDoc и Sphinx, стали широко использовать для создания и управления документацией в репозиториях Git.

Architecture as Code (AaC)

AaC позволяет описывать архитектуру системы в виде кода — например, с помощью DSL. Благодаря этому она становится понятной, проверяемой и легко изменяемой. С помощью таких инструментов, как Structurizr или PlantUML, можно генерировать архитектуры программного обеспечения в коде, чтобы интегрировать их в процессы разработки.

Подход Architecture as Code начал развиваться в 2010-х годах с появлением Structurizr (2014) и других инструментов. Сегодня AaC используют для описания в формате, который можно версионировать и тестировать. Например, C4-модель помогает разработчикам и архитекторам лучше понимать сложные системы.

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

Крупные технологические компании

• Microsoft использует C4-модель, чтобы документировать архитектуры своих облачных сервисов, таких как, допустим, Azure. Подход AaC помогает автоматизировать создание диаграмм и поддерживать документацию в актуальном состоянии.
• Внутренние команды Amazon Web Services используют C4-модели для описания архитектуры своих сервисов, а инструменты AaC помогают интегрировать эти описания в CI/CD-процессы.

Финансовые организации

Многие банки и финтех-компании используют C4-модели, чтобы документировать сложные распределенные системы. Например, ING и Goldman Sachs применяют AaC для автоматизации создания архитектурных диаграмм и проверки соответствия стандартам.

Консалтинговые и IT-компании

• Разработчик и поставщик программного обеспечения ThoughtWorks активно продвигает использование C4-модели и подхода Architecture as Code в своих проектах. Компания создает инструменты и практики для интеграции AaC в процессы разработки.
• Производитель программного обеспечения Red Hat использует C4-модели для документирования архитектуры своих решений, таких как OpenShift, и применяет AaC для автоматизации создания диаграмм.
• Также активно использует и применяет C4-модели X5 Tech — основной цифровой партнер торговых сетей и бизнесов X5 Group.

Policy as Code

Этот подход позволяет описывать политики и управлять ими, например безопасностью или доступом. Policy as Code дает возможность автоматизировать проверку на всех этапах жизненного цикла ПО и обеспечить compliance — соответствие требованиям.

Подход Policy as Code стал популярным с появлением таких инструментов, как Open Policy Agent (OPA) и Hashicorp Sentinel. Они позволили описывать политики безопасности и compliance в виде кода, что стало особенно востребованным в облачных средах.

GitOps

GitOps — подход, в котором Git становится единым источником истины для управления инфраструктурой и приложениями. Они описываются в коде — например, с помощью Kubernetes manifests — а все изменения автоматически применяются через CI/CD.

Концепцию GitOps в 2017 году формализовала компания Weaveworks, этот подход дает несколько преимуществ:

• прозрачность — все изменения видны в Git;
• автоматизация — процессы деплоя и обновления автоматизированы;
• безопасность — изменения проходят код-ревью и тестирование.

GitSecOps

GitSecOps — расширение GitOps с акцентом на безопасность, которое стало развиваться в 2020-х годах. С помощью этого инструмента можно интегрировать безопасность в процесс разработки и эксплуатации через код, он позволяет внедрить в CI/CD инструменты статического анализа кода (SAST) и анализа зависимостей (SCA).

Преимущества этого подхода:

• раннее выявление уязвимостей;
• автоматизация проверок безопасности;
• соответствие стандартам — например, GDPR или HIPAA.

Будущее с As Code

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

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

Footnotes:

• Everything as Code Explained

• Write the Docs Guide: Docs as Code

• Understanding Docs as Code

• The Origins of Infrastructure as Code

• Canary Deployment Strategies

• AWS Whitepaper: Blue-Green Deployments

Об истории DevOps

Методология DevOps появилась благодаря популярности Agile. Ее основная черта — гибкость разработки, дающая ряд преимуществ командам IT. После интенсивного внедрения agile-подхода в разработке существенно увеличилась производительность. Однако при этом появились новые узкие места (bottlenecks) — тестирование и эксплуатация. Культура DevOps — это решение по интеграции участников процесса, ответственных за конечный результат, в общие команды. Это позволяет устранить подобные «бутылочные горлышки».

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

Методология DevOps — явление не такое уж молодое и вполне себе устоявшееся. Про него знают все, кому это может пригодиться. В России его внедрили уже везде, где только возможно, с разной степенью успешности. В гигантах типа Тинькофф, МТС, Сбер, Яндекс, ВК и других этот подход был изучен буквально под микроскопом.

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

Чем отличается DevOps России и Европы

Из основных пунктов можно выделить четыре:

Структура управления

DevOps подразумевает, что в команде собраны все участники, ответственные за продукт, — разработчики, администраторы, тестировщики. Этот подход объединяет ранее независимые команды (отделы, департаменты), делегируя им общую ответственностью за результат. До этого она (ответственность) размывалась между командами, у каждой из которых были свои приоритеты и KPI, что существенно замедляло развитие продукта или сервиса.

Бизнес традиционно имеет вертикальную структуру управления с четкой иерархией. В России это происходит по умолчанию, в то время как на Западе — наоборот. С внедрением DevOps-подхода команды, помимо большей свободы, получают больше ответственности за разрабатываемый сервис.

Например, на Западе тимлид — самый опытный эксперт-разработчик команды, но с крайне ограниченными руководящими полномочиями. В его задачи входит больше менторство, нежели управление. Команда считается самоуправляемой, а дискуссии, обсуждения, голосования и летучки (дейлики) передаются не тим-лиду, а scrum-мастеру или agile-коучу. В команде нет единого центра силы: техническую экспертизу составляет один эксперт, организационную — другой.

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

Язык

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

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

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

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

Инклюзивность

Отличие частично вытекает из предыдущего пункта. За границей состав команд может включать людей из разных стран, имеющих свою культуру и мировоззрение. Для западных компаний это важно — они гордятся толерантностью и инклюзивностью. Эти качества становятся частью как внутренней культуры компании, так и саморекламы и PR. Например, принадлежность кандидата к тому или иному полу или его самоидентификация могут стать преимуществом при найме. В России инклюзивность, как характеристика бизнеса, не важна и на нее не делается упор. У нас команды строятся, в основном, из соотечественников или жителей ближайших стран, владеющих русским языком. Это ограничивает культурное разнообразие. При этом явным приоритетом соискателя в глазах компании выступает именно его профессионализм.

Инфраструктура

В Европе и в США DevOps ориентирован на облачные решения. В России тренд тоже прослеживается, но предпочтение пока отдается хостингам виртуальных или железных серверов. У этого есть несколько причин:

1. Российские облачные сервисы менее развиты в сравнении с Западом.
2. Утилиты для работы с облаками для российских провайдеров имеют ограничения. Например, Terraform был заблокирован для пользователей из России. Конечно, ограничения можно обойти, однако это не добавляет подобным инструментам популярности в нашей стране.
3. Российский бизнес относится с недоверием к внешним провайдерам. Наиболее чувствительная информация хранится и обрабатывается во внутреннем контуре, используя необходимые решения on-premise. Запад в этом случае сильно ориентирован на аутсорс внутренних процессов и задач — бухгалтерии, маркетинга.
4. Использование облачных сервисов позволяет передать вовне отдел эксплуатации. Это позволяет разработчикам большую часть вопросов администрирования решать программными методами.

Особенности страны и менталитета, доступность инструментов во многом определяют предпочтения команд в России и Европе. Так, например, россияне предпочитают виртуальные серверы, в то время как на Западе приоритет — облачный Kubernetes. В России Ansible более популярен, чем Helm, на Западе — наоборот.

Еще одно отличие заключается в функционале DevOps-инженера. В России специалисты чуть больше Ops, за рубежом — более Dev.

Что общего в DevOps России и Европы

Сейчас некоторые инструменты DevOps, используемые в работе, стали недоступны для россиян по известным причинам. Если какой-то продукт уходит с рынка, то зачастую в России его довольно быстро, тем или иным способом, пытаются заместить. При этом решение открытое, и его легко могут использовать специалисты из России. Несмотря на то, что это другие инструменты, они идентичны, но с некоторыми мелкими нюансами.

На текущий момент есть острая нехватка аналогов Slack (с его мощными интеграциями и сервисами), публичных сервисов типа GitHub/Gitlab/Bitbucket. Они обязательно появятся, по этим направлениям уже есть наработки.

Аналогами западных облачных сервисов выступают Yandex Cloud, VK Cloud, Selectel и другие. Уверенное большинство отечественных компаний мигрировало туда, несмотря на довольно высокую стоимость и ограниченное количество решений. Подобный переход возможен, и это указывает на определенную зрелость IT в целом и DevOps в частности.

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

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

Шаг 1. Определяем цели и мотивацию

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

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

• Готов ли я к кардинальной смене профиля деятельности психологически и физически?
• Нацелен ли на развитие команды и компании в целом?
• Готов ли серьезно работать над собой, развивать новые навыки, менять подход к решению проблем?

Если на большинство вопросов ответ положительный, и при этом вы уверены в своих силах и обладаете необходимым запасом свободного времени и энергии, вам определенно стоит попробовать.

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

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

Какие качества развивать для перехода в менеджмент:

• Эмоциональный интеллект — управлять своими эмоциями и понимать команду.
• Умение работать с неопределенностью — теперь хаос и нестабильность станут частью вашей работы.
• Стратегическое мышление — фокус на общей картине, а не на отдельных задачах.
• Стрессоустойчивость и самоконтроль — слова и действия менеджера влияют на команду, и важно не разрушить её.
• Бизнес-подход — умение работать с ресурсами и добиваться результата, а не просто выполнять задачи.
  

Шаг 2. Развиваем навыки

Как правило, на позицию управленца претендуют сотрудники, которые уже освоили hard skills и хотят двигаться дальше. В сфере ИТ-менеджмента база — знание процессов разработки и понимание общей архитектуры.

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

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

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

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

Рассмотрим ключевые софты, которые стоит развить.

Коммуникация

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

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

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

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

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

Как преодолеть барьеры в общении?

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

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

Ответственность

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

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

Мы используем гибкие методологии, но главный принцип – давать людям то, что им нужно. Заказчику – уверенность в результате. Ему не интересны технические детали вроде новых микросервисов и покрытых тестами API, ему важно понимать, какую бизнес-ценность это несет. Если изменение неочевидно, важно объяснить его эффект: например, шаблон микросервиса ускорит будущие разработки, а e2e-тесты снизят риски багов.

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

Пунктуальность

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

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

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

Проактивность

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

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

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

Другие навыки и умения

Помимо перечисленного, менеджеру нужно прокачать следующие способности:

• Оценивать задачи по уровню сложности. Необходимо понимать, сколько времени займет выполнение, справится ли с ней один специалист или ему потребуется помощь. Понимаете специфики поможет узнать, не тянет ли исполнитель время и не запрашивает ли слишком высокую цену за свою работу.
• Просчитывать риски. Рабочий процесс редко идет как по маслу. Специалисты могут заболеть, облениться, уволиться. Закладывайте сроки с учетом задержек в исполнении, особенно если задачи нетиповые.
• Уметь контролировать эмоции. Менеджер, который выходит из себя по поводу и без не способен эффективно управлять. Научиться спокойствию непросто, но это ценный навык, который идет на пользу всему рабочему процессу.
• Делегировать. Фигура высшего пилотажа — умение распределять задачи таким образом, чтобы все сотрудники развивали свой потенциал и выдавали максимальный результат. Самому руководителю стоит сосредоточиться на стратегическом развитии.

Шаг 3. Обучаемся менеджменту

Должности тимлида придется учиться с нуля. В управлении важны сроки и результат, а не стремление к совершенству. Руководитель отвечает не только за свои, но и за чужие ошибки. Давить на подчиненных авторитетом, которого еще нет, не получится. В лучшем случае давление станет взаимным со стороны команды. Так можно «доруководиться» до саботажа.

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

Это примерный список для ориентира:

• «Эффективный руководитель» — Питер Друкер. Книга рассказывает о том, как и чем должен заниматься руководитель, какие правила соблюдать, чтобы добиваться результата в любом деле.
• «45 татуировок менеджера» — Максим Батырев. В формате жизненных историй и конфликтных ситуаций рассказывает о том, как сформировать характер и личность руководителя.
• «Привычка работать вместе» — Твайла Тарп. Опыт успешной коммуникации в команде на примерах из разных сфер.
• «Пять пороков команды» — Патрик Ленсиони. Книга о том, как преодолеть недоверие, безответственность и безразличие к результату работы.
• «Мотивация» — Макс Эггерт. Ценный справочник, полный советов и инструментов, необходимых в работе менеджера.
• «Карьера менеджера IT-проекта» — Гэйл Лакман Макдауэлл и Джеки Баваро. Практическое руководство по ведению проектов и подготовке к собеседованию на позицию ИТ-менеджера.

Полезными будут и онлайн-курсы и тренинги по менеджменту. В числе самых известных — Agile Project Management, интенсив-тренинг для начинающих руководителей. Методология Agile — эффективный подход к реализации проектов с планированием, разбивкой на этапы и активным сотрудничеством всех участников.

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

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

Шаг 4. Переходим на желаемую должность

Советуем следовать конкретному плану:

1. Установите сроки. Переход в менеджеры — дело не одного дня. Процесс займет несколько месяцев, при этом форсировать события точно не стоит.
2. Согласуйте переход в менеджеры с руководством компании. Если в вашей фирме не заинтересованы в подобной инициативе, поищите вакансии в других организациях. В целом хорошие управленцы в ИТ-отрасли нужны всегда.
3. Определите свои сильные и слабые стороны. Подумайте, что можно сделать, чтобы нивелировать недостатки и выработать качества, без которых руководителю не обойтись.
4. Найдите ментора из числа опытных управленцев вашей компании. Научитесь у него всему, что он знает, особенно в плане взаимодействия с исполнителями и руководством.
5. Договоритесь о собеседовании на позицию менеджера. Если вы действуете внутри компании, вести беседу будет гораздо проще. Помните главное: собеседование — не экзамен, работодатель не делает вам одолжений, а тоже заинтересован в ответственных и активных работниках.

Не стоит при переходе занимать позицию джуна (новичка без опыта). У вас уже есть навыки работы в ИТ, вы знаете, как создаются продукты, знакомы со спецификой и нюансами. Называйте себя мидлом и позиционируйте соответствующим образом.

Шаг 5. Работаем над вызовами

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

• Длительные согласования. Чем больше заинтересованных в проекте сторон (стейкхолдеров), тем сложнее. Готовьте документы, инструкции и самого клиента заранее. Все, что нужно предоставить с вашей стороны, должно быть предоставлено. Помогайте заказчику всем, чем можете, и будьте на связи, чтобы в любой момент ответить на вопросы.
• Частые переносы встреч. Клиенты бывают занятыми и иногда откладывают встречи. Проблему можно решить только одним способом — договориться, выбрав нужные слова, и вежливый, но решительный тон.
• Предложение от заказчика переделать функционал. То есть по сути обнулить результат уже проделанной работы. Задача менеджера в такой ситуации — оценить целесообразность решения. Возможно клиент руководствуется пользовательским опытом, но может быть и так, что это его сугубо личное мнение. В последнем случае придется собрать фактический материал и спокойно объяснить заказчику, с какими издержками придется столкнуться.

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

Эта история о том, как мы обнаружили, что «больше» не всегда значит «лучше», и как реорганизация команды помогла уложиться в сроки и повысить качество работы. Меня зовут Игорь Котов, я СТО стрима Ипотека, и в этой статье я поделюсь нашим опытом. Возможно, он будет полезен тем, кто ищет способы ускорить разработку без увеличения команды.

С чего мы начинали

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

• заполнение заявки онлайн с возможностью сохранять черновики;
• отслеживание статуса рассмотрения заявки;
• добавление созаемщиков;
• загрузку и обновление документов;
• доступ с любого устройства через авторизацию по номеру телефона.

На первый взгляд всё казалось несложным: к маю 2023 года мы собрали команду из более 20 человек. Это были опытные инженеры, знакомые с продуктом, новички, аналитики и тестировщики. Работа организовывалась по классическим agile-принципам: двухнедельные спринты, дейли, демо и ретро.

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

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

К сентябрю, когда мы всё-таки выпустили MVP, стало ясно: команда выгорела, а релиз в срок оказался под вопросом.

К какому решению пришли

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

Каждая получила чёткую зону ответственности и полный набор компетенций для автономной работы:

• Одна команда занялась функциями работы с созаемщиками.
• Вторая — модулем загрузки и обработки документов.
• Третья — анкеты заемщика.

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

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

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

Каких добились результатов

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

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

Как понять, что вашей команде нужно изменение

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

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

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

Следить за трендами — не просто «быть в курсе». Это умение смотреть в будущее, вовремя прокачивать навыки и браться за новые проекты. В этой статье мы собрали 11 ключевых трендов на 2025 год — рассмотрим их подробнее, а помогут в этом — Сергей Меньшов, ведущий специалист по Computer Vision (Nexign.com), ментор Solvery, и Антон Ширшаков, Product owner (Райффайзенбанк), ментор Solvery.

Глобальные тренды и направления

Взрывной рост данных и их обработка

К 2025 году объем данных, которые мы будем генерировать, обещает безумные масштабы. По прогнозам, в интернете окажется более 75 ммлрд IoT-устройств.

• Основы аналитики данных: SQL и Python с библиотеками Pandas, NumPy, Scikit-learn;
• Инструменты больших данных: Apache Spark, Hadoop, Google BigQuery;
• Базы данных: PostgreSQL, MongoDB, Cassandra;
• Визуализация: Tableau, Power BI, Matplotlib, Seaborn;
• Обработка потоковых данных: Kafka и облачные платформы для real-time обработки.

Автоматизация и ИИ

ИИ меняет все подряд: от производства автомобилей до обслуживания клиентов в чат-ботах. По прогнозам, к 2025 году объем рынка ИИ вырастет до 190 млрд долларов.

• Алгоритмы ML: от линейной регрессии до нейронных сетей;
• TensorFlow, PyTorch: библиотеки для быстрого обучения моделей;
• MLOps: интеграция и поддержка моделей в продакшне.
• OpenCV: компьютерное зрение и анализ видео;
• Hugging Face: NLP-модели для текста и чат-ботов.

Сейчас активно развивается технология OpenVINO от Интела. Она позволяет запускать нейросети на процессоре с высоким FPS — например, YOLOv8 дает 200 кадров в секунду.

Топовые технологии и навыки в 2025 году

Кибербезопасность

По данным исследования Cybersecurity Ventures, к 2025 году глобальный ущерб от киберпреступлений может превысить 10,5 трлн долларов в год.

1. Этичное хакерство (Penetration Testing): Kali Linux, Metasploit, Burp Suite, Nmap. Сертификат CEH.
2. Криптография: AES, RSA, SHA, OpenSSL, PGP.
3. Администрирование сетей: Wireshark, Snort, Splunk.
4. SIEM: Splunk, IBM QRadar, ArcSight.
5. Incident Response и Compliance (ISO 27001, GDPR, PCI DSS).

Облачные вычисления и архитектура

По данным Gartner, к 2025 году 95% новых цифровых рабочих нагрузок будут развернуты в облаках.

• Terraform: Infrastructure as Code;
• Ansible: автоматизация развертывания;
• Docker и Kubernetes: контейнеризация и оркестрация.

Full-Stack разработка

В 2025 году от Full-Stack разработчиков ожидается еще более широкий спектр навыков: от интеграции с блокчейн до девелопмента микросервисной архитектуры.

DevOps

В 2025 году DevOps продолжает расширять инструментарий, интегрируясь с AI/ML, облачными технологиями и DevSecOps.

Работа с блокчейн

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

• Solidity: язык для смарт-контрактов Ethereum;
• dApps: децентрализованные приложения;
• Основы криптографии: цифровые подписи, хеш-функции.
• Распределенные вычисления: системы без единой точки отказа.

Продвинутое управление продуктом

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

1. Непрерывное обучение и насмотренность: конференции, кейсы, смежные области.
2. Customer-centric: CJM, Jobs to Be Done.
3. Петли обратной связи: ретроспективы, 1-на-1, обзоры спринтов.
4. User story mapping, SPIDR, INVEST: декомпозиция задач.
5. Работа с данными: метрики, A/B-тестирование.

Работа с AR/VR технологиями

В 2025 году AR/VR продолжат находить применение в образовании, здравоохранении, маркетинге и игровой индустрии.

• Unity (C#) и Unreal Engine (C++) — основные движки;
• Blender, Maya — 3D-моделирование;
• ARKit (iOS), ARCore (Android) — AR для мобильных приложений;
• VR-гарнитуры: Oculus Quest, HTC Vive, PlayStation VR.

2025 год станет временем быстрых перемен в IT. Главные тренды: ИИ, облака, кибербезопасность, аналитика данных, блокчейн. Участвуйте в проектах, создавайте что-то свое и постоянно учитесь новому.

Читайте также: Как стать программистом с нуля — полный гайд, Как стать AI-инженером в 2024 году.

По его мнению, основной проблемой является постоянное напряжение из-за бесконечной череды спринтов.

Постоянное напряжение без перерыва

Спринты создают ощущение непрерывного давления.

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

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

Принудительность процесса

Ард также отмечает, что в Scrum спринты навязываются команде: их длительность, структура и задачи предопределены.

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

Такая потеря автономии приводит к демотивации и дополнительному стрессу.

Недостаток времени на подготовку

Еще одна проблема, по мнению Арда, заключается в том, что спринты оставляют мало времени на полноценную подготовку.

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

Комбинация Scrum и Waterfall

Ард также отмечает, что в большинстве случаев Scrum совмещается с долгосрочными целями по модели Waterfall.

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

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

Только в условиях уважения к профессионализму команды можно создать эффективную и менее стрессовую среду разработки.

Однако новое исследование от RAND Corporation бросает вызов устоявшемуся мнению о том, что Agile универсально подходит для всех типов проектов, особенно для тех, которые связаны с искусственным интеллектом (ИИ).

Столкновение Agile с реальностью ИИ

Исследование, проведенное RAND для Минобороны США, включило интервью с 65 специалистами по данным и инженерами, имеющими более 5 лет опыта в создании ИИ и моделей машинного обучения.

Эти профессионалы отметили, что ИИ-проекты часто сталкиваются с уникальными проблемами, которые Agile, со всеми его преимуществами, не всегда способен эффективно решать.

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

В отличие от традиционной разработки ПО, где задачи и результаты могут быть достаточно предсказуемыми, в ИИ часто возникает необходимость пересматривать и корректировать подходы на лету.

Строгие требования Agile к планированию и структурированию могут ограничивать такую гибкость.

Когда гибкость оборачивается рутиной

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

Некоторые участники исследования заявили, что им приходилось бороться с «диктатом Agile», где соблюдение процессов становилось важнее, чем достижение реальных результатов.

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

Вывод: время переосмыслить Agile для ИИ?

Исследование RAND показывает, что Agile, несмотря на свою популярность, может редко соответствовать потребностям ИИ-проектов.

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

PRINCE2

PRINCE2 (Projects in Controlled Environments) — это методология управления проектами, разработанная в Великобритании в 1980-х годах (удивительно, что она до сих пор — британский стандарт). Предлагает структурированную схему ведения проектов различного масштаба и сложности. Основные принципы PRINCE2 заключаются в ориентации на бизнес-цели и поэтапное управление продуктом (stage-by-stage).

Процесс разработки по PRINCE2

Процесс разработки по методологии PRINCE2 состоит из семи взаимосвязанных этапов. Далее на примере конкретного проекта рассмотрим каждый.

Наш проект: Разработка нового модуля для корпоративной системы управления ресурсами (ERP).

1. Создаем проектный устав (Project Initiation Documentation):

• Цель проекта: Разработать новый модуль управления запасами для корпоративной ERP-системы.
• Руководитель проекта: Александр Иванов, менеджер проектов.
• Проектная группа: Ведущие разработчики, аналитик, тестировщик, представитель бизнес-подразделения.
• Структура управления: Руководитель проекта, Проектный комитет, Группа пользователей.

2. Планируем (Project Planning):

• Этапы проекта: Анализ требований, Проектирование, Разработка, Тестирование, Внедрение.
• Сроки: 4 месяца.
• Бюджет: 500 000 рублей.

3. Запускаем работу (Starting up a Project):

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

4. Управляем этапами проекта (Controlling a Stage):

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

5. Управляем продуктами проекта (Managing Product Delivery):

• Организуем командную работу по выполнению запланированных задач разработки.
• Осуществляем контроль качества промежуточных продуктов (архитектурный дизайн, прототипы, исходный код).

6. Управляем границами проекта (Managing Stage Boundaries):

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

7. Закрываем проект (Closing a Project):

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

Плюсы и минусы PRINCE2

Плюсы:

• Фокусируется на достижении бизнес-выгод и оправдании инвестиций в проект.
• Позволяет адаптировать методологию к специфике каждого проекта, что повышает её применимость в разных контекстах.
• Определяет ключевые роли, такие как Спонсор, Менеджер проекта и Команда управления проектом. Спонсор проекта отвечает за достижение бизнес-целей, а менеджер — за оперативное управление.

Минусы:

• Полное внедрение PRINCE2 требует значительных усилий по обучению персонала и перестройке организационных процессов. Компании, привыкшие к более гибким подходам, могут испытывать трудности при переходе на строгую методологию.
• Из-за большого количества документации и отчётности PRINCE2 может кажется излишне бюрократичной.
• Несмотря на возможность адаптации, модель всё же остаётся более жёсткой методологией по сравнению с Agile-подходами.
• PRINCE2 часто требует интеграции с другими методиками (например, со Scrum для разработки).

Для каких IT-проектов подходит PRINCE2

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

• Внедрение ERP, CRM и других корпоративных систем.
• Разработка критически важных информационных систем.
• Крупные интеграционные и миграционные проекты.
• Модернизация legacy-приложений и IT-инфраструктуры.
• Реализация ИТ-инициатив в госсекторе и крупных корпорациях.

DSDM

DSDM (Dynamic Systems Development Method) — это гибкая методология управления проектами, которая была разработана в 1994 году группой независимых консультантов. В отличие от традиционных каскадных подходов DSDM ориентирован на быструю разработку и итеративное улучшение продукта. Важно, чтобы при разработке проекта конечные пользователи были вовлечены во все этапы (так можно внести правки еще на первых стадиях).

Процесс разработки по DSDM

Процесс разработки заключается в итеративном (поэтапном и ориентированном на заказчика) и инкрементальном (последовательном) подходах к разработке. Ниже рассмотрим 7 этапов.

Наш проект: Разработка нового веб-приложения для учёта и анализа продаж в компании

1. Предисловие (Preproject):

• Определяем бизнес-требования к новому веб-приложению.
• Формируем кросс-функциональную команду проекта, включающую бизнес-представителей, разработчиков, тестировщиков и аналитиков.
• Утверждаем сроки, бюджет и приоритеты для реализации проекта.

2. Исследование (Feasibility Study):

• Проводим анализ технической реализуемости проекта.
• Определяем ограничения и допущения, которые могут повлиять на проект.
• Предварительно планируем высокоуровневый функционал системы.

3. Анализ бизнес-требований (Business Study):

• Определяем ключевые пользовательские истории и приоритеты их реализации.
• Согласуем критерии приёмки для каждой пользовательской истории.

4. Функциональное моделирование (Functional Model Iteration):

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

5. Разработка (Design and Build Iteration):

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

6. Внедрение (Implementation):

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

7. Пост-проектная оценка (Evaluation):

• Анализируем извлечённые уроки и рекомендации по улучшению процессов.
• Определяем дальнейшие шаги по развитию и совершенствованию системы.
• Готовим финальный отчёт о реализации проекта.

Плюсы и минусы DSDM

Плюсы:

• Модель фокусируется на быстром прототипировании и ранней реализации ключевого функционала продукта. Часто команды используют DSDM для создания MVP и его последующего итеративного улучшения.
• Метод предполагает тесное сотрудничество с конечными пользователями на всех этапах, что повышает качество и соответствие их потребностям.
• DSDM позволяет быстро реагировать на изменяющиеся требования и условия за счёт итеративного подхода.
• Подход предполагает регулярный анализ процессов и поощряет постоянное совершенствование.

Минусы:

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

Для каких IT-проектов подходит DSDM

DSDM идеально подходит для IT-проектов с высокой неопределенностью требований, быстро меняющимися условиями и необходимостью регулярно предоставлять работающий продукт. Примеры таких проектов:

• Разработка новых программных продуктов и мобильных приложений.
• Внедрение гибких информационных систем (CRM, ERP).
• Создание прототипов и MVP для валидации идей.
• Интеграционные и модернизационные IT-проекты.
• Разработка веб-сайтов и веб-приложений.

P3 Express (легче, чем P3M)

P3 Express (Principles, Practices, and Processes for Project Management) — это упрощенная и гибкая методология, разработанная специально для небольших, ограниченных по времени и бюджету команд.

В отличие от более сложных и формализованных подходов, таких как PMBOK или PRINCE2, P3 Express фокусируется на простоте, практичности и быстром получении результатов. Она предлагает базовый набор принципов, практик и процессов, которые можно легко адаптировать под конкретные нужды команды.

Процесс разработки по P3 Express

Процесс разработки IT-проекта по методу P3 Express заключается в гибком подходе, ориентированном на быстрое получение результата. Вместо длительной фазы проектирования, используются интенсивные циклы разработки и итеративной доработки. Основное внимание уделяется быстрой реализации базовых функций, а не детальной проработке полного функционала.

Наш проект: Разработка нового модуля для управления складскими запасами в корпоративной ERP-системе.

1. Инициация проекта (Initiate):

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

2. Планирование (Plan):

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

3. Реализация (Deliver):

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

4. Контроль (Monitor):

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

5. Завершение (Close):

• После реализации всех запланированных пользовательских историй проводим итоговое тестирование модуля.
• Успешно развертываем модуль в production-среде и передаем в эксплуатацию заказчику.

Плюсы и минусы P3 Express

Плюсы:

• P3 Express предлагает более упрощенный и практико-ориентированный подход по сравнению с полноценной P3M. P3 Express использует ключевые концепции P3M, но с меньшим количеством обязательных процессов и документации.
• За счет меньшей сложности и формализации модель проще и быстрее внедрять в крупные проекты. Компания может начать с пилотного запуска в одном из подразделений, а затем распространить на всю компанию.
• Более простая и гибкая природа методологии подразумевает меньшие затраты на внедрение и обучение персонала.

Минусы:

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

Для каких IT-проектов подходит P3 Express

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

• Разработка MVP.
• Внедрение/настройка небольших информационных систем.
• Миграция или интеграция IT-систем.
• Проекты по улучшению/оптимизации IT-процессов.
• Создание прототипов и экспериментальных решений.

Spiral

Спиральная модель (Spiral Model) — это итеративная методология разработки программного обеспечения, созданная Барри Боэмом в 1980-х годах. Важно помнить, что она уделяет особое внимание анализу и управлению рискам.

Процесс разработки по Спиральной модели

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

Наш проект: Разработка мобильного приложения для заказа такси.

1-й виток спирали: Анализ рисков

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

2-й виток спирали: Определение требований

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

3-й виток спирали: Разработка прототипа

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

4-й виток спирали: Планирование и разработка (здесь можно внедрить и другие методики по типу Scrum)

• На основе обновлённых требований составляем подробный план реализации проекта.
• Проводим поэтапную разработку приложения.
• После завершения каждого этапа определяем дальнейшие шаги.

5-й виток спирали: Оценка и принятие

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

Плюсы и минусы Спиральной модели

Плюсы:

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

Минусы:

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

Для каких IT-проектов подходит спиральная модель

Спиральная модель наиболее эффективна для крупных, сложных и рискованных IT-проектов, требующих тщательного планирования и контроля:

• Разработка критически важных информационных систем.
• Внедрение корпоративных приложений (ERP, CRM).
• Создание программных продуктов с высокой степенью инноваций и ориентацией на пользовательский опыт.
• Модернизация и интеграция устаревших IT-систем.
• Разработка встроенных систем и программного обеспечения.

Extreme Programming (XP)

Extreme Programming (XP) — это методология гибкой разработки программного обеспечения, созданная в 1990-х годах программистом Кентом Берком. Примечательно, что она вбирает лучшие практики Agile (здесь и поэтапная быстрая разработка через временные итерации, как в Scrum, и визуализация процесса, как в Kanban) и ориентирована только на digital-продукты.

Процесс разработки по XP

В основе XP лежит идея постоянного общения между командой разработчиков и заказчиком. Вместо классической «водопадной» модели, где требования собираются раз и навсегда, XP предполагает итеративный процесс.

Наш проект: приложение для заказа еды от сети ресторанов.

1. Планируем релиз:

• Совместно с заказчиком (владельцем ресторана) определяем основные функции приложения: возможность оформления заказа, просмотр меню, отслеживание статуса заказа, оплата.
• Формируем план работ на 3 итерации по 2 недели каждая.
• Определяем метрики: количество новых пользователей, средняя сумма заказа, время доставки.

2. Проводим итерации:

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

3. Разработка:

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

4. Интегрируем:

• Несколько раз в день интегрируем код в единую систему.
• Автоматизированные тесты запускаем после каждой интеграции.
• По мере реализации ключевых функций проводим приёмочное тестирование с участием заказчика.

5. Релиз:

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

6. Проводим ретроспективу

Плюсы и минусы XP

Плюсы:

• Модель ориентирована на быстрое реагирование на изменения требований заказчика. Короткие итерации, постоянная обратная связь и гибкое планирование позволяют оперативно вносить коррективы в продукт.
• XP предполагает тесное взаимодействие с заказчиком на всех этапах разработки. Регулярные демонстрации промежуточных релизов и приемочное тестирование помогают своевременно выявлять и исправлять недочёты.
• Один из ключевых принципов подхода — автоматизированные тесты ещё до написания самого кода. Это позволяет оперативно выявлять и исправлять ошибки.

Минусы:

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

Для каких IT-проектов подходит XP

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

• Интерактивные веб-сайты
• Интернет-магазины
• Веб-приложения с регулярными обновлениями
• Приложения для смартфонов и планшетов
• Мобильные игры
• Системы управления взаимоотношениями с клиентами (CRM)
• Прототипы и MVP

Выбор конкретной методологии, безусловно, зависит от команды. Но сегодня совсем не обязательно обращаться лишь к проверенным техникам — важно расширять горизонт планирования своих IT-продуктов.

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

Правило 80/20 — это про приоритизацию

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

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

Как это выглядит на практике

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

Как я решил проблему:

1. Изучил все таблицы и выяснил, что примерно 17% таблиц формируют основную нагрузку: к ним идет больше обращений, в них копится больше данных.
2. Поставил обработку этих таблиц в приоритет, перестроил алгоритм так, что сначала обрабатывались данные внутри этих таблиц, и только потом — в оставшихся, если хватало времени и ресурсов.
3. Проанализировал результат, увидел, что, обрабатывая эти 17% таблиц, мы решаем 80% всех вопросов. А 20% уже не критичны. В итоге эффективность процесса выросла.
4. Оставшиеся таблицы мы обрабатываем в свободное время.

Также, например, поступил Илон Макс, когда сократил 80% сотрудников штата Twitter, но при этом сохранил функциональность приложения.

Вопреки устоявшемуся мнению, принцип Парето подходит не всем

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

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

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

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

20% усилий могут вовсе не работать без оставшихся 80%

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

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

А еще в той же команде из двух человек снова заработает Закон Парето: один будет делать большую часть работы.

Зато мы можем в разумных пределах оптимизировать команду. Например, разбить 100% результата на всех членов и найти тех, кто не приносит никакого профита или всего 1–5%. То есть метод помогает не потому, что мы просто выкидываем восемь человек, а потому что выясняем, какие 2–3 из них приносят меньше результата и сокращаем их.

Метод Парето работает хорошо, когда вы в материале

Почему? Потому что человек, не знающий тему, не сможет верно отобрать и приоритизировать задачи: он просто не поймет, что действительно важно.

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

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

Что в итоге?

• Метод Парето действительно работает, но не как самостоятельный инструмент, а как один из шагов планирования. Его нужно применять аккуратно, обдумав, и использовать не как истину в последней инстанции, а как помощник для объективной работы.
• Не стоит бежать и оптимизировать все по принципу 80/20 — в некоторых ситуациях нам важно дать выбор или оптимизировать попросту нечего.
• 20% усилий могут и не принести особого результата без оставшихся 80%.
• Грамотно использовать принцип Парето можно, только если вы погрузились в тему (или попросили помощи у эксперта).

Кстати, 80/20, скорее всего, не будет. Будет 85/15, 75/25 и так далее.

Несколько лет назад Agile был в России редкостью. Про такой подход слышали и его применяли только в ИТ-разработке и банкинге. Сегодня в России работает уже немало Agile-коучей и Scrum-мастеров, а принципы гибкой философии распространяются и за пределами высокотехнологичных индустрий. Насколько может быть полезен Agile отечественному бизнесу, рассказывает Владимир Кац, Agile-коуч.

ПреимуществаAgile

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

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

ИТ и не только

Часто бизнес ошибочно полагает, что Agile коснётся только его ИТ-стороны, но это не так. Agile-трансформация предполагает изменение практически всех внутренних процессов компании. Начинаются преобразования обычно с продуктового департамента, а затем охватывают практически все аспекты работы, включая юридические и HR. В противном случае другие департаменты становятся обузой для Agile-команд и замедляют их работу. Поэтому первое, что необходимо сделать руководству при переходе на Agile — скорректировать структуру компании и их внутренние политики.

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

В некоторых случаях Agile — единственно возможный подход в команде. Например, если речь идёт о недавно появившемся продукте. На что именно направить усилия? Куда устремляется рынок? На эти вопросы поможет получить ответы Agile.

Кому подходитAgile

Agile успешно применяют в e-commerce, телекоммуникациях, легкой промышленности, фарме и многих других отраслях. В 2022 году 34% ИТ-компаний и финансовых организаций использовали Agile, говорится в исследовании ScrumTrek. При этом 6,5% компаний (практиковали такой подход) были из сферы торговли, 5% пришлось на телеком-компании, 4,7% — энергетика, 4,5% — промышленная отрасль.

Чек-лист:подходит ли Agile вашей компании

1. Компания работает в условиях высокой неопределенности: выход на новые рынки, создание инноваций, поиск новых продуктовых решений и др.
2. Предметная область бизнеса позволяет экспериментировать.
3. Команда готова к масштабным изменениям внутри: способна адаптироваться к новой корпоративной культуре и ценностям.
4. Руководство хочет принимать непосредственное участие в изменениях и готово выделить ресурсы для обучения сотрудников.

Как обучитьсотрудников работать по Agile

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

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

Поэтому стоит рассмотреть гибридный подход, который совмещает достоинства обоих вариантов: комбинировать записанные лекции, которые можно посмотреть в любое время, и групповые практические занятия с участием экспертов. При этом обучение не должно заканчивается прохождением курса. Идеально, если заключительная часть обучения — это менторство и индивидуальное наставничество. Например, Группа «Иннотех» запустила Школу Scrum-мастеров, чтобы обеспечить себя как организацию из тысяч разработчиков нужным количеством специалистов, которые выполняют критическую роль для организации эффективной работы Agile-команд.

Для этого Группа провела аудит, собрала все требования, предложения, блокеры и возражения от HR, IT и руководителей подразделений. На их основе методисты и эксперты спроектировали образовательный курс, куда вошли онлайн-занятия в формате самостоятельного обучения, практические вебинары с Agile-коучами, а также менторская программа.

Комбинируя разные активности, удалось перераспределить нагрузку Agile-коучей и направить часть их рабочего времени на менторство и индивидуальную работу со Scrum-мастерами. В результате получилось выделить до 100 часов в месяц на дополнительные консультации. Такое перераспределение в пользу менторства повысило эффективность работы коучей, выровняло учебный процесс и в целом подняло качество обучения на новый уровень. До перехода на гибридное обучение с менторской программой доля прошедших тестирование и успешно выполнивших первую рабочую задачу составляла 12%, а после она увеличилась до 100%. Количество выпускаемых ежемесячно Scrum-мастеров возросло с 25 до 50 человек.

Таким образом, обучение влияет на культуру и ценности компании. Принимая решение об Agile-трансформации, стоит заранее продумать образовательный процесс. Ведь правильно сформированное обучение увеличивает поддержку Agile-ценностей в компании, без которой даже лучшие инструменты и практики не дадут результата.

Что такое круг в Karma Framework

Основа Karma Framework — метод круговой организации. Его изобрели в 70-е годы прошлого века в Нидерландах. Согласно одному из его принципов, люди организуются в круги для выполнения общих целей.

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

Иерархия целей создаётся за счёт вложенности. Дочерние круги создаются родительским (корневым), их предназначение должно приводить к реализации предназначения корневого.

Предназначение корневого круга может звучать так: «Быть для бизнес-заказчиков лучшим ИТ, с которым те когда-либо работали или будут работать». А дочернего — «создать человечную и незаметную для пользователя эксплуатацию», без которой, как раз-таки, сложно быть лучшим ИТ.

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

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

Что такое роли в кругах

У каждого участника их может быть несколько: в одном круге человек — Java-разработчик, в другом — лидер сообщества бэкенд-разработки.

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

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

Как устроена репутация в KarmaFramework

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

Мы применяем подход, который называется репутация или карма. Он состоит из двух компонентов:

• обычных метрик, которые гарантируют стабильность измерений на длинных временных интервалах и возможность сравнивать себя с предыдущими периодами и бенчмарками по рынку;

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

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

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

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

Напряжения и ожидания в Karma Framework

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

Напряжение — это то, что побуждает нас двигаться

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

Например, у тестировщика есть потребность работать с тест-кейсами, связывать их с требованиями, формировать тест-сеты, покрывающие определённый функционал или интеграционное взаимодействие. Для этого можно использовать, например, Confluence, или сделать специальный тип тикета в Jira, но это решение нестабильное, всегда придётся что-то подстраивать. Эффективным вариантом будет специальный плагин к Jira. Потребность поставить его — и есть напряжение, потому что тестировщику для установки нужна помощь круга.

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

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

Как поступать с напряжением, возникающим между кругами

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

Это напряжение, направленное вовне. Мы предлагаем не коллегам, а подрядчику перевести работу по заявкам в нашу Jira.

Формулировка этого напряжения контрагенту и есть ожидание. Это скорее просьба сделать что-то для нас, выполнять её необязательно. Ведь для этого подрядчику сначала нужно проверить риски, не сломает ли это их процессы, хватит ли у них ресурсов, нет ли у них других задач. Если они готовы пойти навстречу, то дают обещание: «Через пару месяцев перейдём в вашу Jira». И вот обещание уже является обязательным. Нам остаётся просто мониторить его выполнение.

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

Почему мы выбрали именно самоорганизацию

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

Есть ещё одна интересная причина. С 2019 года, когда начался COVID, акцент на рынке труда сместился в сторону соискателя. Условия труда, социальный пакет, зарплаты в отрасли стали плюс-минус похожие. Стало важно, на какую компанию ты работаешь, что она делает, есть ли у неё цели, которые хочется разделять, посвящает ли она в них своих сотрудников. Это феномен Великой Перестановки, как его называет Райан Рослански. И Karma, или самоорганизация позволяют подключать людей к этим смыслам, делают компанию уникальной.

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

Как развернуть самоорганизацию в компании

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

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

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

Особенность нашей модели управления ИТ Karma Framework — большое количество самостоятельных практик, и для ее масштабирования мы собрали сильную команду единомышленников, которая стала мощным толчком к ее дальнейшему развитию.

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

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

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

Для успешной реализации ИТ-проектов компаниям важно быстро адаптироваться к изменяющимся условиям, иметь возможность оперативно обсуждать, принимать и отменять решения, а также быть открытыми для новых перспектив. Многим компаниям такие возможности открывают гибкие методологии, одной из особенностей которых являются смешанные команды, объединяющие аналитиков, дизайнеров, разработчиков, тестировщиков, имеющих возможность непрерывно взаимодействовать для решения рабочих вопросов. Однако зачастую роль каждого члена такой команды размывается, что может не только приносить дискомфорт участникам, но и негативно сказываться на ходе разработки. В данной статье затронем некоторые принципы Agile, рассмотрим спринт и роль тестировщика в нем.

Что такое Agile-методология

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

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

Роль тестировщика в Agile

Давайте рассмотрим спринт с его артефактами и попробуем определить роль тестировщика в нем.

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

Для многих команд актуально подключение специалистов по тестированию ближе к концу итерации разработки, так называемый TLD-подход — тестирование после разработки (англ. Test Last Development). Такая практика может привести к ряду проблем. Во-первых, недостаток времени для выполнения всех необходимых проверок и выявления потенциальных ошибок. Это может привести к тому, что некоторые дефекты останутся незамеченными и будут обнаружены уже после релиза продукта. Во-вторых, отсутствие планирования и недостаточная коммуникация между членами команды. В этом случае тестировщики не будут в полной мере понимать требования и ожидания заказчика, что приводит к неправильному выполнению тестовых сценариев и некорректной оценке качества продукта. Поэтому следует привлекать QA-специалиста к участию в проекте на всех этапах спринта, начиная с планирования и заканчивая демонстрацией и ретроспективой.

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

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

В течение спринта QA-специалист занимается автоматизацией тестирования компонентов системы. Автоматизация играет ключевую роль в Agile-разработке, позволяя команде быстро и эффективно проверять работоспособность функциональности после каждого изменения в коде. Хорошей практикой считается встраивание автоматизированных тестов в конвейер непрерывной интеграции CI. Это позволяет быстро проверить, не нарушила ли новая функциональность работу уже существующих компонентов системы. Автоматизированные тесты также помогают обнаруживать регрессионные ошибки, которые могут возникнуть при внесении изменений в код.

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

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

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

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

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

Заключение

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

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

В 2021 году я попал на B2C проект, использующий Scrum для построения процессов.

Задачи Kanban доски проходили следующие этапы:

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

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

Команду устраивал процесс работы. Задач было немного — работа шла по плану.

Проблемы проявились, когда на проекте поменялся Product Owner, который расчехлил водомет фич. Задач стало больше … Сильно больше.

Это привело к тому, что в колонке QA оказалось 40 задач и один тестировщик — я.

Задачи часто возвращались. Дедлайны воскрешались. Причины были следующие:

• Ожидаемый результат тестировщиков не совпадал с ожидаемым результатом разработчиков. Например, есть список со странами. В этом списке присутствует значение “Весь мир”. В требовании не было правила, описывающего логику работы данного пункта. Итог — можно было выбрать “Весь мир” и другие страны.
• Отсутствие подсказок пользователю. Например, есть валидация поля “Email пользователя” по следующей маске “символы@символы.домен”. Если указать несуществующий домен, то выводилась неинформативная ошибка, не указывающая пользователю причину этой ошибки.

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

Проблема

Наш процесс работы выглядел так:

1. Бизнес поставил задачу.
2. Аналитики и дизайнеры спроектировали систему.
3. Разработчики написали код.
4. Тестировщики проверили.

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

В итоге мы получаем следующие проблемы:

• Неравномерная работа тестировщиков: то задачи отсутствуют, то завал перед релизом.
• Требования, содержащие ошибки.
• Частые возвраты задач на предыдущие этапы.
• Низкое покрытие автотестами.

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

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

Главное — понять, что использование инструментов типа систем контроля воркфлоу, как Jira или TeamCity и проведение ежедневных дейли-митингов не делают нас Agile-командой. Agile-командой является та команда, каждый член которой понимает свою ответственность за качество продукта. Качество продукта определяет не только код. Качество продукта начинается с требований. А как проверить качество требований? Так же как и проверить качество кода — тестировать.

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

Необходимо привлекать тестировщиков на все этапы разработки продукта, начиная с бизнес-требований. Чем раньше найден баг, тем дешевле его устранение, так как время разработки сильно сокращается. Согласно исследованию “Национального института стандартов и технологий США” ситуация следующая:

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

Shift Left Testing предполагает использование автоматизации тестирования, непрерывная интеграция и непрерывное развертывание (CI/CD). С их помощью разработчики могут быстро выявлять дефекты и уязвимости в коде и устранять их до того, как они приведут к серьезным проблемам.

Кроме того, Shift Left Testing помогает улучшить коммуникацию между тестировщиками и другими членами команды разработки.

Решение

Сначала мы переработали процесс разработки и тестирования. Добавили новые этапы, учитывая наши проблемы:

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

В итоге у нас получился следующий процесс разработки:

Также мы пересмотрели стратегию автотестов. Автотесты должны запускаться не каждую ночь, а при релизе каждой задачи, чтобы получить максимальную выгоду от Shift Left Testing.

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

• Регулярный запуск заставляет людей реагировать на результаты. Если автотест падает, то скорее всего где-то есть баг, нуждающийся в исправлении.
• Благодаря регулярному прогону, можно отследить закономерности в падениях тестов. Ведь тесты бывают нестабильными.
• Автоматизация позволяет сократить время на проверку регресса, что поможет освободить время тестировщиков для новых задач.

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

• Пакет smoke-тестов проверяет критический путь пользователя и проверяет работу всех служб. Эти API-тесты и UI-тесты, которые запускаем при каждом деплое приложения.

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

• Полный пакет тестов направлен на проверку работы приложения в целом. Основная цель такого набора заключается в проверке корректности взаимодействия различных компонентов приложения, включая обращения к различным базам данных и другим сервисам. Большая часть этого набора составляют тесты пользовательского интерфейса (UI), так как они проверяют взаимодействие конечного пользователя с системой. Эти тесты запускаем каждую ночь.

Итог

Закончив внедрение нового процесса разработки было обнаружено:

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

Данный опыт позволил мне выделить главные принципы в работе тестировщика в Agile-команде:

• Сотрудничество с другими членами команды: Тестировщик должен активно сотрудничать с другими членами команды. Он должен принимать участие в планировании, обсуждении требований и определении приоритетов.

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

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

• Постоянное улучшение процесса: Тестировщик должен постоянно улучшать процесс тестирования и внедрять новые методы и инструменты для повышения качества продукта и ускорения процесса разработки.

При раннем тестировании необходимо уделить внимание правильному планированию, выбору тестовых сценариев и их автоматизации, а также внедрению средств непрерывной интеграции и непрерывной доставки (CI/CD).

Напоследок, хочу привести цитату из книги “Как тестируют в Google”:

“В итоге качество достигается предотвращением, а не выявлением багов…”

P.S. Кстати о книгах. Вот хорошие книжки для изучения темы:

1. Agile-тестирование. Обучающий курс для всей команды. Авторы: Джаннет Грегори и Лайза Криспин
2. Как тестируют в Google. Авторы: Уиттакер Д., Арбон Д., Каролло Д.
3. Экстремальное программирование. Разработка через тестирование. Автор: Кент Бек

Не судите строго — это мой первый опыт публикации. Спасибо за внимание!

1. Выявляем боли
2. Внедряем в «дурдом» DoD и DoR
3. Выстраиваем планирование
4. Правильно ставим задачи
5. Выделяем время на техдолг
6. Проводим ретроспективы
7. Слушаем пожелания команды
8. Сохраняем прозрачность
9. Повторяем лучшие практики

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

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

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

Выявляем боли

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

Если этого не сделать, то внешнее недовольство командой и внутренняя усталость IT-специалистов будут постоянно мешать работе. Когда нет коммуникации, то заказчик не понимает команду, а команда — заказчика.

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

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

Внедряем в «дурдом» DoD и DoR

Не стоит забывать наладить взаимодействие внутри команды. Одни из инструментов для решения этой задачи — DoD и DoR.

• Definition of Ready (критерии готовности к взятию в работу) — список условий к элементу бэклога, которые позволяют переместить его в работу или на следующий этап.
• Definition of Done (Определение готовности) — список условий к процессу и инкременту, которые указывают, что они могут получить статус «Готов».

При этом договариваться о DoD и DoR необходимо на всех этапах. Условно, бизнес-аналитики вместе с системными аналитиками определяют, что они выдают после бизнес-анализа. Системные аналитики договариваются с разработчиками по критериям выдачи техзадания. Разработчики вместе с тестировщиками решают, что важно и необходимо для понимания завершения этапа работы.

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

Выстраиваем планирование

Чрезвычайно важно выстроить процесс планирования. Нужно понять трудоёмкость команды и не брать задачи сверх возможностей. А ещё учитывать время на активности: дейли, планирование, ретроспективы, встречи с заказчиком и смежными участниками.

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

Обязательно закладывать риски и возможное съезжание графика. Если риск не сработает, то время не пропадёт даром — его можно использовать на следующую задачу, исправление дефекта, обучение и так далее.

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

Правильно ставим задачи

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

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

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

Выделяем время на техдолг

Заранее договориться с заказчиком, что требуется время на реализацию технического долга. Например, 60–70% времени берём на новые задачи, а в оставшееся — закрываем техдолг.

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

Проводим ретроспективы

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

Здесь важно показать пользу ретроспективы на собственном примере. Например, лиду взять на себя решение проблемы, выявленной на первом ретро. Если, естественно, найти решение ему по силам. На следующем собрании команды показать: была такая проблема, и мы её совместно решили.

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

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

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

Мне очень помогало, когда члены команды давали обратную связь — не стеснялись, не боялись. Это позволяло мне корректировать поведение и становиться лучше. Был кейс, когда один из сотрудников как-то сказал мне: «Знаешь, ты никогда не станешь таким классным руководителем, как у нас вот этот лид». Дальше, когда мы работали вместе, он вернулся с обратной связью и сказал: «Знаешь, я не встречал нигде такого классного хорошего лида». Это самая лучшая похвала, поэтому нужно давать связь руководителю. Лидеру же не принимать эту обратную связь в каком-то негативном ключе, например, «хотят меня подсидеть».

Более того, лиду стоит самому запрашивать обратную связь от команды: «Ребята, это вам заходит или не заходит, делать мне это или не делать?»

Слушаем пожелания команды

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

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

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

Но бывает и негативный опыт. Почитайте, почему Agile может не работать.

Сохраняем прозрачность

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

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

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

Повторяем лучшие практики

Внедряя эти принципы, важно смотреть, что работает, а что нет. Разбираться, почему не работает, а лучшие практики повторять. Не забывать подсвечивать достижения, даже если они небольшие, но не скатываться в политические лозунги: «Мы все здесь одна семья», «Мы команда», «Мы лучшие», «Мы — молодцы», «Команда мечты».

Меньше пафоса — больше адекватного общения. Мне кажется, отличный рецепт для эффективной работы.

1. Agile vs современный мир
2. О важности командной работы
3. Роли, неофициальные лидеры и условия
4. Выстраивание общения
5. Выгорание и снижение мотивации
6. Главный принцип создания эффективной команды

Agile vs современный мир

В теории внедрение Agile начинается с изучения манифеста с 12 принципами разработки. Кстати говоря, их придумали 17 человек, собравшихся в начале 2001 года в городе Сноуберд, штат Юта. Они были обеспокоены, что в разных компаниях по-разному представляют оптимальный процесс разработки программного обеспечения. Но один вывод был общим для всех: компании настолько сосредоточены на избыточном планировании и документировании циклов разработки ПО, что уже неспособны эффективно и вовремя решать задачи клиентов.

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

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

Методология даёт определённую свободу. Именно поэтому её так любят многие молодые специалисты. Но всё равно команде нужен такой «бесполезный» человек, как руководитель проекта. Он приземляет команду в желаниях по улучшению MVP и чётко блюдёт интересы заказчика. Мы в IT работаем в первую очередь на продукт, результат.

О важности командной работы

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

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

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

По итогу в команде организовался «самоназванный лидер», причём именно «самоназванный». Как выяснилось, по факту какими-то лидерскими качествами он и не обладал, всё, что делал: раздавал ЦУ и возмущался, если что-то было не так, как он считал нужным. Влезал в создаваемые рабочие процессы и вносил лишь сумятицу. Никого не напоминает?

Вдогонку пошли конфликты, наезды, поклёпы, полураспад команды, дотаскивание со скрипом того, что осталось. Результат — кое-как и кое-что вынесли в «прод», получили по 4 балла и разбежались, перекрестившись, что это закончилось.

В чём тут мораль? Да, наверное, в том, что правила, описание процессов и прочее — не главное в командной работе. Главное — это именно командная работа. Ответственность всей команды, а не одного конкретного её члена, помощь в сложных ситуациях и прочее. К сожалению, в реальности далеко не всегда так получается. И это печалит, потому что этому очень мало уделяют внимание.

Роли, неофициальные лидеры и условия

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

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

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

Выстраивание общения

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

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

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

Про топ-менеджмент сложно найти универсальные стратегии коммуникаций. Но точно могу сказать, как с ними не нужно общаться. Точно не нужно подключать их к темам из серии «в туалете закончилась туалетная бумага, мне не выдают ручку, почему мне выдали монитор 27″, а не 4К».

Выгорание и снижение мотивации

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

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

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

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

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

• с 9 до 18 — стандартный рабочий день в основном с акцентом на встречи, обязательные задачи и прочее;
• с 18 до 22 или 23 (по ситуации) — личная жизнь, дети, семья, друзья, уроки, посиделки;
• с 23 до 2 или 3 (по состоянию и критичности задач) работа над какой-то текучкой, которая, с одной стороны, не требует большого количества умственных затрат, а с другой — отнимает довольно много времени, и если её не делать, количество задач скопится до необозримых размеров.

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

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

Главный принцип создания эффективной команды

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

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

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

Положение дел до внедрения Agile-подходов

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

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

Почему выбрали Agile?

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

Поэтому мы решили познакомиться с другими информационными системами и фреймворками разработки. Изучили ряд самых популярных подходов (Waterfall, Agile, Lean) и систем (Jira, Hygger, Redmine). Остановились на Agile и Jira.

Agile подходил к гибкости нашего рынка: он меняется часто, важность доработки может измениться за ночь и необходимо, чтобы команда разработки быстро и безболезненно адаптировалась и выполняла задачи с минимальными потерями и без стресса. А Jira позволяла создавать необходимые для анализа работы отчёты и автоматизировать некоторые моменты. Обучение проходили в компании Scrumtrek.

Что, за чем и зачем внедряли?

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

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

Потом внедрили график выхода прошивок, чтобы у отделов техподдержки и продаж знали ориентировочные сроки выхода прошивок и понимали их содержание. А работу аналитика добавили практику User Story Mapping. Так появилось понимание порядка доработок и общая картинка перед глазами.

Дальше появилась матрица компетенций. — чтобы распределять дефекты между сотрудниками и устранять их быстрее. В результате отпали вопросы в стиле: «Кто и что будет делать?». По матрице же выбирали исполнителей для новинок.

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

Наконец, мы внедрили ретро, чтобы в конце каждого спринта обсуждать проблемы и оперативно решать их. А также ввели практику определения и выпуска MVP (Minimum Viable Product), чтобы клиент получал результат как можно скорее и применял в своей работе необходимый минимум.

Что изменилось после внедрения Agile-практик?

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

Также мы сократили количество проблемных мест в прошивках к минимуму. Сейчас критичные дефекты устранены. Вновь обнаруженные устраняем в течение 1-2 дней.

Мы научились эффективнее работать по спринтам. Благодаря графикам из Jira понимаем причины, почему не закрыли спринт. После внедрения решения три спринта были с положительной динамикой. А благодаря практике User Story Mapping ей ускорили процесс выхода нового функционала в GPS-трекерах без нагромождения всех «хотелок», оставляя в них только суть для отработки решения.

Наконец, PBR (Product Backlog Refinement) помог детальнее подойти к планированию и оценке сроков.

Что дальше?

Мы будем регулярнее применять Product Backlog Refinement, чтобы точнее планировать и устанавливать сроки. А также активнее использовать User Story Mapping для определения Minimum Viable Product.

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

Наконец, мы введём практику работы в парах для совместной работы над проектами.

Как тимлиду строить команду?

Определить размер

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

Определить состав

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

Быть готовым к потерям

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

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

ВАЖНО во избежание неконгруэнтности подбирать людей, близких команде по ценностям и взглядам на жизнь. Если есть потребность в создании команды для краткосрочного проекта и нет нужды в процессах её выстраивания, можно опереться только на компетенции членов. Но если команда нужна на долгосрочную перспективу, она должна быть синхронизирована по ценностям. Человек, который не вписывается в общую систему ценностей, в любом случае уйдёт. Рано или поздно.

Сделать акцент на коммуникациях

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

Какие навыки нужны тимлиду?

Soft skills

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

Так как речь идет о people-менеджменте, часто приходится сталкиваться с сомнениями людей, желанием больше зарабатывать, недостаточной мотивацией, необходимостью выстраивать/перестраивать коммуникации.

Hard skills

Хард скиллы важны, но не так принципиальны для тимлида. Как говорил Стив Джобс, «бессмысленно нанимать толковых людей и указывать им, что делать». Необходимо брать людей, чтобы они говорили, что делать. В идеале тимлид должен быть компетентным и обладать экспертными знаниями в процессах разработки. И понимать, как делается продукт. Вовсе необязательно знать все нюансы: это может быть верхнеуровневое понимание ситуации, но во всей её целостности, с учетом взаимосвязей и взаимовлияния отдельных элементов.

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

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

С какими задачами сталкивается тимлид и как их решать?

Научить команду самостоятельности

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

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

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

Сотрудничество со смежными командами

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

ВАЖНО в этом вопрос отталкиваться от оргструктуры организации. Согласно закону М.Конвея, она накладывает отпечаток на архитектуру программного решения. В зависимости от того, что является приоритетным для компании при разработке — оргструктура или архитектура — будут выстраиваться особые модели коммуникации. К примеру, у нас на проекте за определённые микросервисы отвечает конкретная команда, есть чёткие границы её ответственности при взаимодействии с другими командами. Это позволяет избегать дубляжа в функционале и полномочиях.

Определить внутренние правила игры

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

У нас две команды разработчиков. Обе работают по Scrum. Одна пишет сервис на C#, другая на Java. Сперва мы разбили зоны функциональности. А впоследствии фиксировали контракты, договаривались, как они будут выглядеть, расходились, и далее совместно фиксировали результат. Если говорить о внутрикомандной работе, то у нас преобладают горизонтальные взаимодействия. Коллеги приходят ко мне как к эксперту за советом, рекомендацией, но не за готовым решением.

А каким вы видите идеального тимлида?

Ещё не все понимают, что такое Agile и зачем он нужен

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

Большие компании тоже переходят на гибкие подходы при разработке

Удивительно, но многие банки уже работают по Agile. Например — Сбербанк, Райффайзенбанк, Банк Хоум Кредит.

Kanban работает и в распределённой команде

При этом важно проводить регулярные созвоны, а также организовать работу так, чтобы вся команда была на связи хотя бы 4 часа в сутки. Подробно рассказал Андрей Ребров, CTO & co-founder Scentbird. Презентация на Dropbox.

В России внедряют LeSS

Это специфичный метод, когда на несколько команд — только один владелец продукта. Метод подходит не всем, так как получается сложно балансировать между гибкостью и предсказуемостью. Плюс все команды должны уметь делать всё. Антон Бевзюк и Дмитрий Павлов рассказали про успешное внедрение LeSS в Додо Пицце. Ещё советуем вот эту статью Антона.

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

Для начала надо понять, осознанно ли человек мешает работе. Если да — поговорить с конфликтологом, перенанять и, если не помогло, удалять из команды. Если нет — ставить ему дедлайны чаще, а задачи конкретнее, также поможет настройка времени на отдых. Подробнее в презентации Agile Coach Анны Обуховой. Полистайте, может оказаться, что вы — неосознанный саботажник.

Принципы Agile можно применять не только при разработке ПО

Как пример — eduScrum, который внедряется в некоторых школах не только за границей, но и в России. Алексей Дерюшкин из Better Life Company рассказал, кто такой «учитель 21 века» и почему Agile так нужен в школах. Agile можно использовать и в личной жизни, например, чтобы быстрее закончить ремонт на кухне.

Не бойтесь скрещивать Scrum и Kanban или брать из каждого подхода понемногу

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

Все презентации и информацию о докладах можно найти на странице программы конференции.

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

Википедия описывает гибкую методологию разработки так:

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

Почему именно Agile?

TL;DR — чтобы подстраиваться под постоянно меняющиеся требования.

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

Более традиционные подходы вроде Waterfall (каскадная модель) диктуют тотальное планирование, когда вы ничего не можете сделать, если этого нет в плане.

В любом проекте, будь то программное обеспечение, маркетинговая кампания или рекрутинговая стратегия, появятся дополнительные возможности или поменяются требования. Особенно в случае с крупными проектами. Поэтому новые факторы приходится либо игнорировать (обычно неидеально), либо ужимать план, погружая работу в хаос. Так зачем тогда вообще планировать, правда?

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

Что такое Agile?

TL;DR — различные практики, которые помогут вам легче приспосабливаться и убеждать свою команду в том, что она всегда работает над чем-то важным.

Agile — способность меняться легко и быстро.

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

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

Пользовательские истории поставляются либо непрерывно, либо маленькими циклами, которые называются спринтами.

Как работает Agile?

TL;DR — Требования > План > Работа > Ревью > Повтор

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

Оцените каждый этап: по часам или по так называемым story point’ам (относительные оценки, которые выставляются в сравнении и отношении к другим историям). Есть вероятность, что результат будет несколько неточным и даст вам слабое представление о том, сколько времени займёт работа над проектом.

Установите приоритетность задач, самые важные — в начало очереди. Обычно в этой среде всё постоянно меняется, поэтому проверяйте приоритеты быстро и часто. Kanban очень реагирует на эту частоту. Scrum же основан на фиксированных циклах (спринтах), которые обычно длятся две недели.

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

Scrum vs Kanban

TL;DR — это два основных фреймворка для Agile.

Scrum

• Деление работы на части, которые называются спринтами (обычно в спринте две недели);
• Спринты планируются исходя из требований для этого конкретного момента времени;
• Относительная оценка времени выполнения работ;
• Ревью каждого спринта, чтобы понять, как он прошёл и что можно было бы улучшить;
• Фидбек по поставляемому продукту;
• Ежедневные собрания (очень короткие).

Kanban

• Еженедельные собрания;
• Непрерывная разработка;
• Визуализация процесса на доске;
• Решение сначала самых важных задач;
• Поэтапные улучшения.

Заключение

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

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

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

Какие методологии разработки применяются в различных IT-компаниях?

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

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

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

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

Как компания мы очень адаптивны, поэтому на каждом проекте используем оптимальные методологии. Для «коробочных» внедрений, где есть отработанные схемы, это обычно референтные (эталонные) подходы, учитывающие специфику конкретного решения, например, Oracle AIM.

Для разработки систем с нуля мы используем один из подходов гибкой (Agile) или водопадной (waterfall) разработки, либо их комбинации. Сам Agile не является чем-то революционным: он содержит ряд элементов, известных еще со времен артелей начала прошлого столетия и бригадного подряда с 80-х годов прошлого века. Так что многое новое — это хорошо забытое и перевнедренное старое.

Процесс вывода продукта на рынок и его непрерывного совершенствования традиционно основан на цикле непрерывного совершенствования качества Деминга (циклическое повторение этапов Plan-Do-Check-Act), ускоренного Scrum, дизайн-мышления и других современных техниках.

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

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

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

В компании NVIDIA представлен широкий спектр разнообразных активностей, касающихся разработки и исследований. Методология может варьироваться в зависимости от направления деятельности, команды или проекта. Однако большинство проектов по софтверной разработке подразумевает использование Agile и Continuous Integration.

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

1. Выбор правильной методологии ведения проекта. Это могут быть различные варианты гибкой разработки, водопадная модель или же их комбинации. А учитывая, что заказчик хочет иметь возможность внесения изменений на всех этапах разработки и как можно раньше получать работоспособные версии систем, в том числе и масштаба Enterprise, все большую популярность приобретает подход Scaled Agile.

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

1. Использование «унифицированной среды разработки» — совокупности специально подобранных и проинтегрированных между собой инструментов, необходимых для создания ПО (управление задачами, контроль версий, сервер непрерывной сборки, статические анализаторы кода для различных языков и т.д.), а также корпоративных практик и стандартов, которыми мы руководствуемся при разработке.

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

Также мы активно используем автоматизацию тестирования и практики DevOps.

У нас в SAP на этапе постановки задачи все более широко используется методология Design thinking. На этапе создания продукта часто можно видеть варианты Agile, причем иногда совмещенные с Waterfall-подходом.

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

Все начинается с менеджера продукта и менеджера программ — эти две роли, часто объединённые в одном человеке, отвечают за вопросы «какие проблемы решает наш продукт, для каких пользователей и как он это делает». Менеджер программ, по сути, отвечает за ежедневную коммуникацию и представление точки зрения пользователя в команде разработчиков, а также за создание спецификаций на продукт и его компонентов. Рабочие инструменты менеджера программ — система документооборота (например, confluence), системы change management, bug tracking вроде Jira, средства телекоммуникаций (как webex), средства прототипирования и создания «скетчей» интерфейсов, средства для сбора информации о существующих версиях продукта и о том, как его используют живые пользователи. Менеджер программ также выступает заказчиком для следующей роли — дизайнера.

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

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

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

Тестировщики и QA — это люди, которые ответственны за тестирование продукта (ручное или автоматическое) и за внедрение и выполнение методик, повышающих качество продукта, за отмашку «продукт готов к релизу».

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

Кроме того, в реальной жизни все может быть сложнее — есть эпизодические роли (возникающие на определенных этапах разработки), роли, которые хотя и не имеют прямого отношения к разработке — плотно с ней взаимодействуют (вроде маркетинга и sales engineering), роли, которые существуют только для определенных продуктов — например, профессиональные сервисы, появляются новые роли, которые становятся возможны благодаря развитию средств разработки и внедрения (вроде DevOps инженеров).

У нас применяется система СКРАМ с элементами Канбан. И в целом мы адаптируем все технологии, стараемся чтобы здравый смысл руководил. У нас вся компания разбита на команды до 10 человек, мы работаем кварталами и спринтами внутри них. На квартал существуют глобальные планы компании, например, запустить новый продукт, или провести техническую реформу (недавно мы переходили на микросервисы). К этим глобальным планам команды добавляют свои планы, которые возникают из идей внутри команды или от пожеланий пользователей. Мы стремимся делать то, что мы делаем, самым лучшим образом и у нас, как нам кажется, это получается.

Статья продолжает дополняться.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на admin@tproger.ru, мы расскажем, как это сделать.

Описанная в этой статье стратегия автоматизации тестирования предполагает модель постоянной поставки с несколькими командами, работающими по методологии Agile.

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

Краткое содержание

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

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

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

Обзор стратегии автоматизации тестирования

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

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

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

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

Регрессионное тестирование

Автоматические регрессионные тесты — основа стратегии автоматизации тестирования.

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

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

Такие тесты запускаются при каждом развёртывании приложения и могут содержать как API, так и GUI-тесты.

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

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

Эти пакеты должны запускаться в различных окружениях по мере необходимости и проверять, что поведение приложения остаётся неизменным вне зависимости от окружения. Такие тесты запускаются несколько раз в день и должны продолжаться не дольше 15-30 минут.

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

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

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

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

Стратегия автоматизации тестирования для нескольких Agile-команд

Автоматизированные unit-тесты

Автоматизация тестирования начинается на уровне unit-тестов. Эти тесты должны создаваться для каждой новой возможности, находящейся в разработке. Именно они ложатся в основу более широкой практики автоматизации вплоть до системных GUI-тестов. Разработчики обязаны убедиться в том, что для каждой новой функциональной возможности разработан полный набор надёжных unit-тестов, позволяющих проверить, что код работает как задумано и отвечает всем требованиям. Unit-тесты наиболее выгодны с точки зрения окупаемости, поскольку их недолго написать, легко поддерживать и изменять (благодаря тому, что нет зависимостей), так что если в коде есть ошибка, то разработчик быстро узнает о ней. Unit-тесты должны запускаться как на компьютере разработчика, так и в среде непрерывной интеграции.

Автоматическая интеграция / API-тесты или сервис-тесты

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

Сервис-тесты обычно запускаются на уровне API без вовлечения GUI-интерфейса, следовательно, тесты направлены на проверку функциональности в чистом виде, а поскольку тесты непосредственно обращаются к компонентам, они быстро проводятся и могут быть частью сборки. При необходимости тестирования взаимодействия с внешними сервисами, в случае, если внешние сервисы не доступны либо не могут гарантировать предоставление данных, отвечающих условиям тестирования, можно использовать эмуляторы внешних сервисов, например WireMock. API-тесты и/или сервис-тесты могут запускаться на компьютере разработчика или быть частью сборки, но если они начинают занимать длительное время, лучше запускать их в среде непрерывной интеграции. Для сервис-тестов можно использовать такие инструменты, как SoapUI.

Тесты приложения

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

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

Для проведения таких тестов в браузере можно использовать Selenium WebDriver. Этот инструмент является наиболее популярным для проведения автоматизированного тестирования в браузерах и предоставляет богатые возможности API для проведения сложных проверок.

Полные сценарные тесты

Автоматизированные GUI-тесты, которые запускаются для всей системы, используются как типичные пути пользователей или полные сценарии взаимодействия. Из-за проблем с этим типом тестов (описанных ниже) их количество лучше сократить до минимума. Полные сценарии включены в ночные регрессионные пакеты.

Инвертирование пирамиды автоматизации тестирования

В рамках стратегии автоматизации тестирования нам необходимо минимизировать количество автоматизированных тестов на уровне GUI.

Несмотря на то, что проведение автоматизированного GUI-тестирования даёт хорошие и значимые результаты с точки зрения симуляции пользовательского взаимодействия с приложением, оно имеет и ряд своих недостатков:

1. Хрупкость — для определения веб-элементов для взаимодействия тесты используют html-локаторы, поэтому как только меняется уникальный ID какого-либо элемента интерфейса, тесты перестают работать, а это влечёт за собой значительные расходы на поддержку.
2. Ограниченное тестирование — GUI может не позволить тестировщику полностью проверить функциональность,  поскольку он не всегда содержит все детали веб-ответа, необходимые для верификации.
3. Низкая скорость — поскольку тесты проводятся через GUI, время загрузки страницы существенно увеличивает общее время тестирования, и обратная связь разработчикам поступает значительно позже.
4. Наименьшая окупаемость — из-за всех проблем, перечисленных выше, GUI-тесты становятся наименее целесообразными с финансовой точки зрения.

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

За перевод выражаем благодарность международной IT-компании Noveo

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

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

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

Планировать полезно. Слепо следовать плану — глупо.

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

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

Сделать половину — не сделать ничего.

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

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

Планируйте реальность, а не пустую мечту.

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

Если вы не можете доверять людям, которых берете в свое дело, то вы явно нанимаете не тех, кого надо.

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

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

Спасибо издательству Манн, Иванов и Фербер за предоставленные цитаты.