Как выбрать цифровую платформу для ведения ИТ-проектов и по каким критериям оценивать системы? На какие решения стоит обратить внимание в 2026 году? В статье разберем функциональность 5 популярных ИСУП и подсветим плюсы и минусы каждого ПО.

В чем особенность ИТ-проектов

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

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

И все же ряд особенностей у ИТ-проектов есть:

1. В основе реализации лежат Agile-подходы. Классические методы задают рамку (сроки, бюджет, контроль), но реальная работа строится через гибкие практики: внутри почти всегда используются спринты, бэклог, инкременты.

2. Итерационная поставка ценности. Управление строится не только вокруг соблюдения плана: результат создается не в конце проекта, а через регулярные релизы.

3. Работа в цифровой среде. Команда (разработчики, аналитики, тестировщики) используют информационные системы: таск-трекеры, репозитории, CI/CD. Проект «живет» в инструментах, а не в отчетах.

4. Критично иметь единое информационное пространство. Сроки, требования и метрики должны быть связаны в одной системе. Иначе возникает разрыв между управлением и фактическим исполнением.

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

Какой должна быть система для управления ИТ-проектами

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

1. Поддержка гибридных подходов (Agile + Waterfall). Руководитель работает с этапами, сроками, бюджетом, исполнители — с досками, бэклогами и спринтами.

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

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

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

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

Из технологических критериев стоит обратить внимание на:

• полную импортонезависимость — чтобы вовремя получать обновления даже при кастомизации системы;

• возможности разработки без кода или с низким его содержанием — чтобы иметь возможность настроить процессы самостоятельно;

• масштабируемость — чтобы система могла расширяться вместе с ростом количества проектов или их сложности;

• безопасность — чтобы защитить данные и управлять правами доступа пользователей;

• микросервисную архитектуру — чтобы получить гибкое распределение нагрузки и стабильность ПО.

Обзор популярных российских сервисов для управления ИТ-проектами

Directum Projects — платформенное решение для управления проектами, бизнес-процессами, командами, документами, задачами и знаниями

Система полностью импортонезависима и безопасна: разработана в России и включена в реестр отечественного ПО (№4499), доступно размещение в «облаке» и на сервере предприятия.

Поддерживает все виды методологий проектного управления. Вся функциональность доступна «из коробки» и работает в едином контуре:

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

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

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

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

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

Система совместима с отечественным и свободно распространяемым ПО. Благодаря сервисам интеграции можно объединить любые инструменты, используемые в компании, в единую экосистему. Настроить Directum Projects под требования бизнеса поможет разработка без кода или с низким его содержанием (no-low-code).

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

Цена: от 8190 рублей в год за человека.

SimpleOne SDLC — специализированная система для управления полным циклом разработки ПО: от идеи до выпуска продукта

Включена в реестр отечественного программного обеспечения, развернуть систему можно в «облаке» или на инфраструктуре компании.

Доступны:

• управление разработкой: диаграмма Ганта, гибкие методологии, ИИ-анализ кода;

• связь с поддержкой: приоритизация заданий, формирование технического долга продукта;

• планирование и учет трудозатрат;

• библиотека документации: связь файлов с задачами и услугами;

• аналитика: кастомные формы отчетов, Agile-метрики;

• управление продуктом: иерархия, построение любой структуры.

Система совместима с Gitlab, имеет открытый интерфейс обмена данными (API) и возможности для гибкой кастомизации без привлечения вендора.

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

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

Цена: по запросу.

EvaProject — отечественная система управления проектами и командами

Аналог Jira, включен в реестр российского программного обеспечения. Доступна облачная и локальная поставка.

Система дает возможность управлять:

• жизненным циклом разработки и задачами от постановки до релиза;

• бэклогом и спринтами: есть приоритизация и контроль выполнения;

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

• изменениями: фиксируются и контролируются все корректировки;

• импортом данных из зарубежных решений;

• прогрессом: в систему «заведены» информационные панели для мониторинга задач, загрузки и выполнения проекта.

Интегрировать EvaProject в корпоративную среду можно при помощи открытого интерфейса данных (API), также доступна кастомизация интерфейса, полей и процессов.

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

Цена: от 450 рублей в месяц за человека.

Яндекс Трекер — облачный сервис для управления проектами

Сервис входит в экосистему Яндекс 360: можно «подтягивать» почту, синхронизировать встречи с календарем и ставить задачи из писем. Включен в реестр отечественного ПО.

Ключевые возможности:

• организация совместной работы: можно объединять разные команды в одном проекте;

• учет ресурсов: у пользователей есть возможность заранее спрогнозировать трудоемкость;

• классика и гибкость: доступны доски и диаграмма Ганта;

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

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

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

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

Цена: от 399 рублей в месяц за человека.

Timetta — отечественная ИСУП, ориентированная на контроль ресурсов и экономику проектов

Программа подходит для компаний с проектной моделью бизнеса (интеграторы, консалтинг, ИТ-подразделения). Доступна в облаке и локальной поставке (on-premise).

Функциональность и особенности:

• фокус на экономике проектов, учет трудозатрат, расчет себестоимости и маржинальности;

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

• связка плана и факта: есть возможность сравнить запланированные и реальные трудозатраты;

• управление портфелем через ресурсы и деньги, приоритизация с учетом загрузки и финансового эффекта;

• понятная аналитика, отчеты по эффективности проектов и использованию ресурсов в разных разрезах.

Можно адаптировать систему под потребности компании.

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

Цена: от 1105 рублей в месяц за лицензию.

Основные функциональные критерии отечественных ИСУП

Итог

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

Timetta — российская PPM-платформа с финансовым учётом, портфелями и on-premise для крупных компаний.

GanttPRO — специализированный онлайн-инструмент для диаграмм Ганта с импортом MS Project и простым интерфейсом.

Kaiten — российский сервис для гибридного управления: Kanban, Scrum, Гант и модульная тарификация.

Redmine — бесплатное open-source решение для команд, готовых самостоятельно разворачивать и дорабатывать систему.

Как мы выбирали

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

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

1. Timetta — портфели и финансы

Timetta — российская корпоративная система для управления проектами, ресурсами, трудозатратами и финансами. Она ориентирована на проектные офисы, ИТ-интеграторов, консалтинговые и инжиниринговые компании, которым нужно вести сроки, людей и деньги в одном пространстве.

Кейсы клиентов и кому подойдёт

• Проектный офис крупной ИТ-компании. В Газпром ЦПС Timetta используется как единое пространство для управления портфелем из 180+ проектов.
• Руководители проектов и финансисты. Комита ЦТ собирает трудозатраты через таймшиты и контролирует рентабельность проектов.
• Ресурсные менеджеры. В GMCS система помогла сделать прозрачной загрузку сотрудников и снизить конфликты за ресурсы между направлениями.

Что можно развернуть

Платформа покрывает полный цикл проектного бизнеса:

• проекты, программы и портфели
• диаграммы Ганта с вехами, зависимостями и критическим путём
  
• таск-трекер с бэклогом и спринтами
  
• бронирование ресурсов и загрузка сотрудников
  
• таймшиты и учёт отсутствий
• заявки на затраты, платёжные календари и процесс почасового биллинга,
• P&L-отчёты, клиенты и сделки
  
• корпоративная вики и ИИ-ассистент
  

Инфраструктура и экосистема

Timetta работает в облаке (SaaS) и в виде on-premise-развёртывания в инфраструктуре заказчика. Данные хранятся на защищённых российских серверах, система соответствует 152-ФЗ и включена в реестр российского ПО (запись № 18250 от 05.07.2023). Доступен OData API с авторизацией OAuth 2.0, готовые интеграции с 1С:УХ и 1С:ЗУП, обработчики и сценарии автоматизации.

Отзывы и репутация

Среди публичных клиентов — Газпром ЦПС, Комита ЦТ, GMCS. Вендор публикует кейсы внедрений на сайте, но агрегированных рейтингов на независимых площадках мало, поэтому сравнивать по звёздам затруднительно.

Поддержка и каналы связи

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

Тарифы, ограничения и условия

Стоимость зависит от выбранных приложений, числа пользователей и срока лицензии. По данным прайс-листа, лицензии на отдельные приложения начинаются от 350 ₽ за пользователя в месяц (например, Timetta Expenses), до 3500 ₽ за Timetta Corp.

Для небольших команд есть отдельная бесплатная сборка Timetta Lite: тариф Free доступен без ограничения по сроку для 10 активных пользователей и теперь включает таймшиты, а для команд на 11–50 человек действует платный тариф Team — 1 490 ₽ за пользователя в месяц (подробнее — в блоге Timetta). On-premise доступен для корпоративных клиентов, стоимость рассчитывается индивидуально. Работа с юрлицами ведётся по договору с закрывающими документами.

Официальный сайт: timetta.com

2. GanttPRO — специализация на Гантах

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

Кейсы клиентов и кому подойдёт

• Менеджеры проектов среднего звена. Интерфейс заточен под планирование сроков и контроль дедлайнов без IT-отдела.
• Маркетинговые и event-команды. Удобно строить таймлайны кампаний, делиться планами с заказчиками по публичной ссылке.
• Команды, мигрирующие с MS Project. Поддерживается импорт из MS Project, что упрощает перенос существующих планов.

Что можно развернуть

GanttPRO предлагает диаграмму Ганта с зависимостями, автопланированием и критическим путём; иерархию задач и WBS; представления доски, списка, календаря, дашборда, портфеля и загрузки ресурсов; учёт рабочей нагрузки, бюджетирование и тайм-трекинг на старших тарифах; комментарии к задачам, вложения, упоминания и публичные ссылки для демонстрации планов; экспорт в PDF, PNG и Excel.

Инфраструктура и экосистема

Решение работает полностью в браузере, без установки десктопного клиента. Данные хранятся в дата-центрах Microsoft Azure в ЕС. Поддерживаются основные платежные методы, включая карты и PayPal; для компаний доступна оплата по счёту. API есть, но собственная экосистема интеграций у GanttPRO уже, чем у крупных платформ вроде monday.com или Wrike.

Отзывы и репутация

По данным GanttPRO, инструментом пользуются более 1 млн проектных менеджеров. На Capterra сервис получает высокие оценки за удобство диаграмм Ганта (около 4,8/5). Часто отмечают чистый интерфейс и быстрый старт; среди ограничений — узкая экосистема интеграций и менее глубокие отчёты по сравнению с enterprise-PPM.

Поддержка и каналы связи

Поддержка доступна через email и базу знаний. На тарифе Enterprise предусмотрен приоритетный канал поддержки и enterprise onboarding. Документация и обучающие материалы публикуются на сайте.

Тарифы, ограничения и условия

GanttPRO работает по подписке. Тариф Core стоит от $7 за пользователя в месяц при годовой оплате, Advanced — $10, Business — $17, Enterprise — $25. Бесплатного тарифа нет, но доступен 14-дневный пробный период без привязки карты. Некоторые функции, например workload management и портфели, открываются только на тарифах Business и выше.

Официальный сайт: ganttpro.com

3. Kaiten — Agile и Гант

Kaiten — российская платформа для управления задачами, проектами и командами. Изначально позиционировалась как альтернатива Jira, Trello и Asana, но сегодня покрывает и классическое планирование через диаграмму Ганта, и гибкие методологии.

Кейсы клиентов и кому подойдёт

• IT-команды и продуктовые подразделения. X5 Tech использовала Kaiten при миграции из Jira, сохранив привычный подход к задачам.
• Ритейл и производство. Сервис работает в компаниях ВкусВилл, Мегафон, Додо Пицца, технопарке «Сколково».
• Команды, которым нужен единый инструмент. В Kaiten совмещены Kanban, Scrum, Гант, документы, базы знаний и служба поддержки.

Что можно развернуть

Доступны канбан-доски с WIP-лимитами и дорожками, скрам-доски со спринтами, burndown-диаграммами и velocity; диаграмма Ганта, ресурсное планирование и зависимости между задачами; документы и базы знаний; автоматизации через конструктор правил и триггеров; AI-транскрибатор встреч и AI-помощник для оформления задач; отчёты по загрузке, lead time, block time и cumulative flow; мобильные приложения для iOS и Android.

Инфраструктура и экосистема

Kaiten работает в облаке и предлагает серверную версию на Docker для тарифа «Корпорация» (от 300 пользователей). Продукт включён в реестр российского ПО, данные хранятся в России, оплата производится в рублях. Интеграции включают Jira, Trello, Notion, Asana, ClickUp, GitHub, GitLab, Slack, Telegram, Google Календарь и Яндекс Календарь.

Отзывы и репутация

По данным сайта, сервисом пользуются более 200 тысяч компаний. Публикуются именные кейсы клиентов: Buzzolls, «Сколково», X5 Tech, «Продман», «Авиационный Консалтинг-ТЕХНО». В независимых обзорах отмечают удобный интерфейс и рублёвую оплату; ограничения — функционал для портфельного управления и глубокого финансового учёта уступает специализированным PPM-системам.

Поддержка и каналы связи

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

Тарифы, ограничения и условия

Бесплатный тариф — до 5 пользователей с базовыми функциями. Платные тарифы: «Старт» от 185 ₽ за пользователя в месяц (при оплате на 36 месяцев), до 15 пользователей, включены модули Scrum и Kanban; «Стандарт» от 430 ₽ за пользователя в месяц, до 250 пользователей, два модуля на выбор; «Бизнес» от 580 ₽ за пользователя, до 250 пользователей, шесть модулей; «Корпорация» — индивидуальная цена, on-premise, от 300 пользователей. Каждый дополнительный модуль — от 80 ₽ за пользователя. Пробный период — 14 дней со всеми модулями.

Официальный сайт: kaiten.ru

4. Redmine — open source

Redmine — бесплатная open-source система управления проектами на Ruby on Rails. Это выбор для команд, у которых есть технические ресурсы для развёртывания и настройки, и которые не хотят зависеть от вендора и регулярных лицензионных платежей.

Кейсы клиентов и кому подойдёт

• Разработческие и IT-команды. Встроенная интеграция с Git, SVN, Mercurial, CVS и гибкая система трекинга задач.
• Компании с жёсткими требованиями к данным. Можно развернуть полностью в собственной инфраструктуре и контролировать доступ.
• Бюджетные проекты. Подходит стартапам, образовательным учреждениям и НКО, готовым потратить время на настройку вместо денег на лицензии.

Что можно развернуть

Redmine поддерживает управление несколькими проектами, гибкую ролевую модель доступа, трекинг задач с кастомными полями и workflows, диаграмму Ганта и календарь, wiki и форумы для каждого проекта, учёт времени, документы и файлы, email-уведомления, интеграцию с LDAP и SCM, создание задач по email. Функциональность расширяется сотнями плагинов сообщества.

Инфраструктура и экосистема

Решение распространяется под лицензией GNU GPL v2 и разворачивается на собственных серверах или в облаке. Поддерживаются разные СУБД (PostgreSQL, MySQL, SQLite) и ОС. API доступен для интеграций, но большинство интеграций реализуется через плагины или собственную разработку.

Отзывы и репутация

Redmine существует с 2006 года и имеет активное международное сообщество. Среди известных пользователей — множество open-source проектов, компаний в сфере IT, инжиниринга и консалтинга. В обзорах отмечают гибкость и отсутствие лицензионных платежей; к недостаткам относят устаревший интерфейс и необходимость в администрировании.

Поддержка и каналы связи

Официальная поддержка сообщества: форумы Redmine, IRC-канал #redmine в сети libera.chat, неофициальный Slack. Документация включает User's Guide, Developer's Guide, FAQ и HowTos. Коммерческую поддержку и хостинг предоставляют сторонние провайдеры, цены зависят от поставщика.

Тарифы, ограничения и условия

Сам Redmine бесплатен: нет лицензионных платежей и ограничений по числу пользователей или проектов. Реальные затраты — на собственное железо или облачный хостинг, администрирование и нужные плагины. Готовые хостинговые версии от сторонних провайдеров стоят от $10–25 за пользователя в месяц, но это цена провайдера, а не вендора.

Официальный сайт: redmine.org

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

Диаграмма Ганта и зависимости. Timetta и GanttPRO предлагают наиболее зрелый Гант с критическим путём и автопланированием. У Kaiten Гант доступен как подключаемый модуль, у Redmine — базовый, но функциональный.

Управление ресурсами. Timetta выделяется ресурсным планированием, бронированием и портфельной загрузкой. GanttPRO и Kaiten дают workload-вид, Redmine требует плагинов для глубокого ресурсного учёта.

Финансы и бюджеты. Timetta — единственный из четырёх с полноценным P&L, себестоимостью и взаиморасчётами. GanttPRO и Kaiten закрывают базовое бюджетирование, Redmine — через плагины.

Гибкие методологии. Kaiten лидирует по Kanban и Scrum из коробки. Timetta поддерживает гибридные схемы, GanttPRO ориентирован на классику, Redmine гибок через настройку workflows.

Размещение данных. Timetta и Kaiten предлагают российское облако и on-premise. GanttPRO хранит данные в Azure ЕС. Redmine разворачивается где угодно, включая собственный сервер.

Стоимость. Redmine бесплатен по лицензии, но требует ресурсов на поддержку. Kaiten стартует с бесплатного тарифа и далее от 185 ₽. GanttPRO — от $7. Timetta — индивидуально, с бесплатным тарифом Timetta Lite (Free) для команд до 10 пользователей.

Выводы

Прямого универсального заменителя MS Project не существует: каждый инструмент делает ставку на свои сценарии. Для крупного проектного офиса с финансовым контролем и портфелями логичнее смотреть на Timetta. Если главное — удобная диаграмма Ганта с быстрым стартом и импортом из MS Project, выбор GanttPRO выглядит естественным. Командам, которые живут в Kanban/Scrum, но иногда нужен Гант, подойдёт Kaiten. А Redmine остаётся рабочей лошадкой для технических команд, готовых взять на себя развёртывание и поддержку.

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

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

Сначала формулируют задачу бизнеса

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

На старте заказчик и подрядчик договариваются:

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

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

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

Настроить порядок работы с изменениями

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

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

1. Внутренняя команда заказчика описывает, что изменилось и зачем это нужно продукту.
2. Внешняя команда оценивает, какие задачи придётся сдвинуть и как запрос повлияет на загрузку, технический долг и сроки.
3. Менеджер подрядчика собирает варианты действий и показывает последствия каждого.
4. Владелец продукта со стороны заказчика выбирает вариант и утверждает приоритет.
5. После этого задача попадает в бэклог или в текущий спринт.

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

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

Включить внешнюю команду в процессы проекта

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

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

Подготовить проект к ротации специалистов

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

1. найти специалиста под требования заказчика;
2. передать ему текущие задачи и контекст проекта;
3. подключить к встречам и рабочим каналам;
4. оформить доступы и нужные документы.

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

Сообщать о рисках вместе с решением

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

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

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

Понять, когда исполнитель стал партнёром

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

Обычно заказчик:

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

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

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

По такому принципу в Centicore Group выстраивается работа выделенных команд: погружение специалистов в контекст проекта, подключение их к процессам заказчика и предварительное согласование порядка взаимодействия. Подробнее о компании и проектах можно узнать на centicore.ru.

Что в итоге

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

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

Поэтому считать стоит не “сколько стоит разработчик”, а “сколько стоит довести задачу до продакшена”. Для этого и нужен TCO (total cost of ownership): полная стоимость владения командой, процессом или внешним контуром разработки.

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

Почему ставка разработчика ничего не объясняет

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

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

TCO появляется как раз между “купили часы разработчиков” и “получили работающую фичу в продакшене”. В расчет попадают дополнительные расходы:

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

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

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

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

Базовая формула такая:

TCO разработки = прямые расходы + управление + запуск + простои + риски + передача знаний.

Где:

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

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

Как считать TCO инхауса

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

Формула может быть такой:

TCO инхауса = зарплата + налоги + инфраструктура + найм + онбординг + управление + простой + риск замены

• Зарплата и налоги можно посчитать сразу. Остальное часто всплывает позже. Разработчику нужны ноутбук, монитор, доступы, IDE, таск-трекер, облачные сервисы, тестовые стенды и корпоративные инструменты.
• Найм тоже входит в TCO. Вакансию нужно описать, кандидатов найти, провести скрининг, техническое интервью, тестовое задание и согласование оффера.
• После выхода человека начинается онбординг. Разработчик разбирается в кодовой базе, архитектуре, локальном окружении, правилах ревью и деплоя. Первые недели он часто требует больше внимания, чем отдаёт команде пользы. Это нормальная часть штатной разработки, её просто нужно считать заранее.
• Отдельная статья расходов — текучка. Когда разработчик уходит, компания теряет часть контекста. Потом нужно снова искать человека, вводить его в проект и ждать, пока он выйдет на нормальную скорость.

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

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

Как считать TCO аутсорса

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

Формула может быть такой:

TCO аутсорса = стоимость договора + подготовка требований + управление со стороны заказчика + приёмка + изменения цели + передача результата

• Стоимость договора обычно включает работу команды, PM, тестирование, инфраструктуру подрядчика и его маржу. Маржа в этой модели нормальна: подрядчик держит команду, управляет загрузкой, закрывает внутренние риски и отвечает за процесс на своей стороне.
• Главная точка роста стоимости — требования. Когда финальная цель понятная, подрядчик быстрее оценивает задачу, планирует этапы и показывает результат.
• Заказчику всё равно нужно управлять проектом со своей стороны. Подрядчик не знает продуктовый контекст по умолчанию. Ему нужны ответы на вопросы, доступы, обратная связь и приёмка промежуточных результатов.
• В TCO аутсорса стоит сразу закладывать передачу результата. В договоре нужно зафиксировать права на код. Документация должна позволять поддерживать проект другой команде. Деплой, окружения и API тоже лучше описать до финальной приёмки.

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

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

Как считать TCO выделенных команд

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

Формула может быть такой:

TCO выделенных команд = ставка специалиста + подбор + онбординг + управление + ревью + коммуникация + риск замены

• Ставка специалиста даёт доступ к человеку, а готовый результат всё равно собирает ваша команда. Подрядчик может помочь с подбором, оформлением, заменой и административной частью. Заказчик отвечает за ежедневную работу специалиста.
• Самая важная статья расходов здесь — время техлида. Он проводит техническое интервью, вводит человека в проект, объясняет архитектуру и проверяет решения.
• Онбординг в аутстаффинге обычно короче, чем в инхаусе: компания не проходит полный цикл найма и оформления, но контекст проекта всё равно нужно передать.
• В TCO нужно заложить коммуникацию с провайдером. Если специалист заболел, не подошёл по уровню или проекту нужна замена, порядок действий должен быть понятен заранее.

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

Где здесь место внешней команды

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

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

Посмотреть услуги Centicore Group

Чек-лист перед выбором модели

Перед выбором модели проверьте три вещи: управление, срок проекта и требования.

1. Сначала — управление. Если внутри есть CTO, техлид или сильный PM с техническим бэкграундом, можно рассматривать аутстаффинг и гибридную модель. Если управленца нет, аутстаффинг быстро станет проблемой. В этом случае безопаснее смотреть на аутсорс, где управление разработкой берёт на себя подрядчик.
2. Дальше — срок проекта. Для задачи на несколько месяцев инхаус часто слишком дорогой: найм, адаптация и настройка процессов могут занять больше времени, чем сама разработка. Для продукта на долгосрок, наоборот, стоит заранее думать о своём техническом ядре.
3. Третий пункт — требования. Чем понятнее сценарии, интеграции, ограничения и критерии готовности, тем проще считать TCO аутсорса. Если требования ещё меняются, в бюджет нужно сразу закладывать аналитику, дополнительные итерации и переприёмку.

Перед решением ответьте на несколько вопросов:

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

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

Итого

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

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

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

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

Как всё начиналось

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

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

А ещё скинул официальный регламент, в котором просил обозначить: как будут храниться персональные данные гостей, какое шифрование, у кого есть доступ к базе, какой регламент при утечке и соответствует ли система требованиям ФЗ-152. Я сел разбираться.

… и перевёл с корпоративного на человеческий

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

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

Вопрос про шифрование поначалу вообще казался мне каким-то птичьим языком. Оказалось, что речь про то, передаются ли данные по защищённому соединению. Я проверил — с соединением всё было в порядке, https стоял.

Про ФЗ-152. Он же Федеральный закон о персональных данных. Если ты собираешь у людей имена, телефоны и почту (а любая форма регистрации на то и рассчитана), ты автоматически становишься оператором персональных данных. Со всеми вытекающими: нужно уведомить Роскомнадзор, разместить на сайте политику конфиденциальности, получить у пользователей явное согласие на обработку данных.

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

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

Я привык мыслить как вайб-кодер: мне важно, чтобы форма работала, данные сохранялись и письма улетали. А им надо понимать, кто ответит, если случится утечка? Как мы управляем доступом? Что у нас за процессы?

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

Что в итоге

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

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

Мне, как владельцу бизнеса, теперь важно:

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

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

Как раз для таких предпринимателей и существует курс «ИТ-директор». Что там внутри — подсвечивать не буду, если надо, сами разберётесь. А вот для себя уже подметил суперважные моменты про айти-инфраструктуру в контексте управления и рисков. Ещё впереди 4 созвона с техническим директором. Может, тоже что-нибудь расскажу, если что-то полезное вынесу.

По промокоду ДИРЕКТОР на данный момент доступна скидка 65% + открывают доступ ко второму курсу сверху. Если нужно уберечь себя от критичных ошибок, то лучшего варианта, чем обучиться заранее, не найти!

Реклама. Рекламодатель: ООО «Эдюсон» ИНН 7729779476, erid: 2W5zFHCCh5K

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

Этап 1: Транзитный период и базовая инфраструктура

В нормальном мире у любого подключения внешней команды должен быть transition period (период перехода). Это полноценный проект со своими сроками, бюджетом, приоритетами и конечной целью. Технари это понимают, а вот бизнес не всегда. Руководство долгое время может считать, что выстраивать процессы онбординга — это пустая трата времени. А правда — в том, что без выстроенного транзитного периода никто системно не работает. Точнее, проект как-то едет, но исключительно на тимлидах с обеих сторон, компенсируя отсутствие внятной инженерной инфраструктуры постоянными созвонами.

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

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

Этап 2: Внешняя команда входит в тот же инженерный контур

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

Рабочая схема выстраивается иначе:

1. Единые инженерные процессы. Внешняя команда коммитит в общий Git, пишет документацию и покрывает изменения тестами ровно по тем же правилам, что и внутренние разработчики.
2. Общая организационная гигиена. Требования к безопасности, парольной политике, VPN-доступам и внутренним регламентам применяются к внешним разработчикам в таком же формате.
3. Сохранение контекста. Знания и архитектурные решения фиксируются в едином репозитории, чтобы проект не терял экспертизу после завершения контракта.

То есть создается один и тот же рабочий контур для всех участников разработки.

Этап 3: Синхронизация и работа со сбоями

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

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

• Валидация артефактов на входе. Если инхаус отгрузил доступы, дампы баз или документацию, внешняя команда проверяет их в течение первых суток. Задача — просто убедиться, что всё открывается и данных достаточно для старта. Оставить архивы без проверки — значит через неделю узнать, что разработка стоит из-за битых ссылок.
• Короткие еженедельные статусы. Даже если таски в трекере исправно двигаются по доске, команды выделяют 15 минут в неделю на голосовую сверку. Это нужно для калибровки: одинаково ли заказчик и вендор понимают текущий план и нет ли скрытых блокеров.
• Пересборка приоритетов. Когда происходит сбой (не готово нужное API, зависли права к смежной системе), команды не ищут виноватых, а принимают управленческое решение: что делаем прямо сейчас, чтобы выдержать основной дедлайн, а что осознанно откладываем на потом.

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

Этап 4: Фиксация завершения и обратный переход

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

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

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

Что дальше

После закрытия transition period вы получаете не изолированных наемников, а масштабируемое расширение собственного штата. Внешние инженеры пушат в ваш репозиторий, CI/CD автоматически гоняет тесты по вашим правилам, а архитектурные решения (ADR) остаются внутри корпоративной базы знаний. Проект переходит в фазу штатной продуктовой поставки, где полный контроль над исходниками и релизами принадлежит заказчику.

Масштабирование разработки работает, когда вендор понимает границы своей ответственности. Проекты, которые принимает или передает Centicore Group, закрывают транзитный период техническим срезом: что из инфраструктуры передано, какие пайплайны развернуты и где зафиксирован технический долг. В результате заказчик сохраняет полный контроль над исходниками и архитектурой (ADR), а внешние разработчики просто выдают прогнозируемый объем задач в рамках общих спринтов.

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

1. Visary Tracker: когда нужна экосистема, а не просто доска

Visary Tracker — это часть более крупной платформы Visary Cloud, что сразу даёт понять: система заточена не под стартапы с пятью задачами в бэклоге, а под команды, которым нужна глубокая аналитика и связка процессов. Применяется как в разработке ПО, так и в управлении проектами, поддержке и операционной работе.

Доступ через веб-интерфейс, работает с любой ОС. Развёртывание — на выбор: облако (SaaS на мощностях Cloud.ru) или on-premise, если у компании строгие требования к инфраструктуре. В облачной версии данные хранятся в РФ в соответствии с 152-ФЗ, система включена в реестр отечественного ПО (запись №23958 от сентября 2024 года).

Методологии и визуализация процессов

Для команд, работающих по Agile, реализована поддержка Scrum и Kanban. Можно отслеживать прогресс через Burndown Chart, смотреть на скорость команды через Velocity, планировать долгосрочные работы с помощью дорожной карты.

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

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

В комплект с Visary Tracker входит пакет бесплатных сервисов экосистемы, который включает:

• Сервис коммуникаций (чат, интегрированный в задачи, и сервис видеосвязи);
• Функционал организационной диаграммы (органиграммы);
• Дисковое хранилище для управления, совместного редактирования и хранения файлов;
• Корпоративный календарь.

Права доступа и безопасность

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

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

Производительность и масштабирование

Интересная особенность — отсутствие искусственных лимитов на количество пользователей и проектов. Система не заставляет пересматривать тарифный план, если команда выросла с 10 до 100 человек. Хранилище подбирается под задачи клиента, минимум — 25 Гб, дальше по потребностям.

Для автоматизации рутины предусмотрены:

• REST API и вебхуки для интеграции с системами контроля версий (Git, GitLab, Bitbucket), мессенджерами (Slack, Telegram) и CI/CD-инструментами.
• Планировщик задач и триггеры, которые избавляют от необходимости вручную менять статусы или назначать исполнителей.
• Модуль Visary BI — конструктор дашбордов, если стандартных отчётов не хватает и нужно строить сложную аналитику по проектам.

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

Миграция и техподдержка

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

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

Тарификация

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

2. Аспро.Cloud: когда таски нужно подружить с экономикой проекта

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

Система работает как SaaS, доступна на Windows, macOS, Linux, iOS, Android (облако + мобильное приложение). Все данные находятся на серверах в РФ, есть внутренний аудит действий пользователей, шифрование данных в транзите и безвозвратное удаление данных. Система обновляется без простоя системы.

Методологии и визуализация

Разработчикам и PM-ам здесь выкатили полный набор: Agile-модуль для Scrum и Kanban, и отдельный функционал для Waterfall. В плане визуализации всё стандартно, но функционально:

• Канбан-доски для бэклога и текучки.

• Диаграмма Ганта (timeline) для планирования сроков и зависимостей.

• Календарь и списки.
• Модуль Workload — критичная штука для оценки загруженности команды.

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

Техстек и автоматизация

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

По интеграциям список внушительный:

• Системы контроля версий: GitLab, Bitbucket — связываем коммиты с задачами.
• 1С и API: интеграция с 1С:Бухгалтерия 8.3 и открытый REST API для связки с внутренними системами.
• Мессенджеры и соцсети: Telegram, WhatsApp/WhatsApp Business, ВКонтакте, Viber — уведомления и общение с клиентами в привычных каналах.
• Почта: Gmail, Яндекс.Почта, Mail.ru, Outlook, IMAP — задачи можно создавать прямо из писем.
• Облачные хранилища: Google Drive, Яндекс Диск, OneDrive, Dropbox — файлы к задачам подтягиваются из привычных мест.
• IP-телефония: UIS, Mango Office, Телфин, МегаФон, Новофон, Twilio — записи звонков и история коммуникаций привязываются к проектам.
• Банки: Сбербанк, Т-Банк, Альфа-Банк, ВТБ, Точка, Модульбанк, Райффайзен — автоматическая загрузка банковских операций для контроля бюджета.
• Платежные системы: СБП, ЮKassa, CloudPayments, Robokassa, Дзен-мани — приём оплат и выставление счетов.
• Сайты и сервисы: Tilda, готовые сайты Аспро, Jivo, Calendly, DaData, Xmind — связка с маркетингом и автоматизацией лидогенерации.

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

Безопасность и масштабирование

Система тянет до 300+ пользователей и до 1 ТБ хранилища (лимиты зависят от тарифа). В плане безопасности завезли:

• Гибкое управление ролями (чтобы аутсорсеры не видели лишнего).
• Полный аудит действий пользователей.
• Поддержку IP-белых списков и шифрование данных в транзите.
• Резервное копирование и возможность безвозвратного удаления данных.

Миграция и поддержка

Если решили переезжать, есть штатный импорт из Jira, Asana и Trello. Интерфейс полностью на русском, документация и база знаний тоже. Саппорт отвечает через чат, почту и Telegram в рабочее время.

Тарифы

Модель — подписка от месяца до двух лет.

• Бесплатная версия: до 5 пользователей и 5 ГБ места (функционал урезан).
• Платные тарифы: зависят от количества юзеров и объема хранилища.
• Триальный период: 14 дней, чтобы понять полный функционал.

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

3. WEEEK: аналог всего знакомого

WEEEK попадает в категорию систем, которые пытаются закрыть сразу всё: трекинг задач, управление проектами, базу знаний и даже CRM. По сути, это попытка собрать рабочее пространство в одном месте, чтобы не прыгать между пятью вкладками. Судя по отзывам пользователей, которые переезжали с Trello, Asana, Notion и даже Jira, система справляется с этой задачей неплохо.

Архитектура и организация работы

Структура здесь трёхуровневая: рабочие пространства → проекты → доски/календари/списки. Классическая матрёшка, как сами разработчики это называют.

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

CRM и документы

Интересная фича — встроенная CRM с воронками продаж и аналитикой по конверсии. Это не основная функция таск-менеджера, но для команд, где разработка завязана на клиентские запросы (студии, агентства, аутсорс), может упростить жизнь.

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

Автоматизация и интеграции

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

Из интеграций упоминаются Figma, Miro, Airtable и связка с Google. Есть API, что теоретически позволяет прикрутить систему к своим инструментам или автоматизировать через скрипты.

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

Миграция и адаптация

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

ИИ-помощница и дополнительные фишки

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

Тарификация

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

Техподдержка и комьюнити

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

4. Shtab: управление от стратегии до конкретной подзадачи

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

Работает в облаке (SaaS), в изолированном облаке (Private Cloud) и on-premise. Для крупных компаний с требованиями по информационной безопасности есть интеграция с SSO/LDAP и полный аудит.

Архитектура целей и задач

Основная фишка Shtab — иерархия от цели до подзадачи. Структура выглядит так: стратегические цели (OKR/MBO) → портфели проектов → проекты → задачи → подзадачи.

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

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

Система поддерживает несколько режимов работы с одними и теми же данными. Канбан-доски с настраиваемыми столбцами и WIP-лимитами для контроля нагрузки — стандарт для команд, работающих по Kanban.

Диаграммы Ганта для планирования сложных проектов с зависимостями между задачами и контролем загрузки ресурсов. Календарь для временного планирования и матрица приоритетов (срочность/важность) для фокусировки на главном.

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

Управление знаниями и файлами

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

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

Тарификация и развёртывание

Есть бесплатная версия, детали по ограничениям не уточняются. Облачная версия запускается за 5 минут с автоматическими обновлениями. Private Cloud даёт изолированную инфраструктуру в российском облаке с возможностью масштабирования. On-premise — для тех, кому нужен полный контроль и соответствие ФЗ-152.

5. Kaiten: работа по Kanban

Kaiten на рынке больше 10 лет, что для российских таск-менеджеров довольно редкий кейс. Система создавалась Kanban-командой, и это чувствуется в том, как построена работа с потоками задач.

Работает в облаке и on-premise, включена в реестр ПО РФ. Используется более чем в 200 тысячах компаний — от IT и ритейла до производства и строительства. Среди клиентов Сбер, Tele2, РусГидро, Альфа-Банк.

Kanban и Scrum без костылей

Разработчики позиционируют Kaiten как Agile-инструмент с полноценной поддержкой обеих методологий. Для Scrum-команд реализованы спринты с оценкой по Story Points, отслеживание прогресса и ретроспектива. Для Kanban — доски с гибкой структурой: можно настраивать этапы и подэтапы, ограничивать количество задач в процессе через WIP-лимиты, добавлять дорожки для параллельных потоков.

В Agile-аналитике есть Lead time отчеты, чтобы отслеживать время прохождения задачи от начала до конца и находить узкие места в процессе. Блокировки карточек можно фиксировать с указанием причины, а потом анализировать, почему задачи встают на паузу.

Планирование и управление ресурсами

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

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

Kaiten AI

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

Кастомизация и права доступа

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

Интеграции и автоматизация

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

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

Мобильное приложение и шаблоны

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

6. ЛидерТаск: когда нужно просто начать работать

ЛидерТаск — это таск-менеджер, который на рынке уже больше 12 лет и позиционируется как инструмент для личной и командной работы. Если Visary Tracker заточен под экосистемный подход и подробную аналитику, то здесь всё проще — быстрый старт и понятность интерфейса.

Система работает как в облаке, так и на собственном сервере. Доступна через веб-интерфейс, десктопные клиенты для Windows и мобильные приложения для iOS и Android.

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

Организация работы

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

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

Командная работа

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

Порог входа

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

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

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

ITIL 4 Foundation – это основополагающая квалификация в области передовых методик управления сервисами информационных технологий. В сущности, ITIL 4 представляет собой сборник рекомендаций о том, как ИТ-подразделению трансформироваться из простого технического звена в бизнес-партнера, предоставляющего сервис.

К сожалению, официального перевода на русский язык книга «ITIL. Foundation Essentials ITIL 4 Edition.» автором которой является Claire Agutter не имеет, но её легко найти к продаже в свободном доступе. Первая версия книги издана в 2020, а более новая редакция вышла в 2024 году.

Ключевые принципы ITIL 4

1. Фокус на ценности: всё должно приносить пользу бизнесу и клиентам.
2. Начинайте с текущего: используйте то, что уже есть.
   
3. Двигайтесь постепенно: маленькими шагами с обратной связью.
   
4. Сотрудничайте: ломайте барьеры между отделами.
   
5. Думайте целостно: учитывайте все взаимосвязи.
   
6. Будьте проще: избегайте сложных решений.
   
7. Автоматизируйте с умом: сначала оптимизируйте, потом автоматизируйте.
   

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

Если цель — сделать IT-услуги более понятными, контролируемыми и значимыми — welcome!

Ключевые принципы ITIL 4: фундамент для эволюции IT-услуг в современную эпоху

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

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

Подробное описание и глубокое погружение в эти принципы можно найти в фундаментальном руководстве «ITIL 4 Foundation». Этот документ — не просто учебник, а синтез лучших мировых наработок, предлагающий всесторонний, интегрированный взгляд на управление IT.

Ориентация на ценность: в центре всего - потребитель

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

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

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

Следовательно, любое нововведение — будь то внедрение опции онлайн отслеживания заказа или выбор конкретных чистящих средств — должно проходить проверку на соответствие ключевому вопросу: «Каким образом это принесёт пользу клиенту и компании?»

Начинайте с того, что есть: эволюция, а не революция

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

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

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

Двигайтесь постепенно, собирая отзывы: сила итераций

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

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

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

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

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

При возникновении серьёзного инцидента (например, падении корпоративного мессенджера) создаётся не просто заявка в IT, а временная кросс-функциональная команда: специалист техподдержки, разработчик, и менеджер по продукту. Их совместная работа позволяет не просто «починить код», а понять полное влияние на бизнес-процессы и быстрее восстановить критически важный сервис.

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

Думайте и работайте целостно: системный взгляд на услугу

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

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

Будьте простыми и практичными: оптимизация, а не усложнение

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

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

Необходимо постоянно задаваться вопросами: «Действительно ли нужен этот шаг? Можно ли этот отчёт автоматизировать? Упростит ли эта встреча принятие решения?». Цель — устранить избыточность, бюрократию и любое бесполезное усложнение, оставив только те практики, которые непосредственно способствуют созданию ценности. Часто самый простой путь является и самым эффективным.

Оптимизируйте и автоматизируйте: максимизация эффективности

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

Например, процесс согласования заявок на оборудование занимает неделю из-за пяти согласующих. Автоматизация рассылки напоминаний этим пяти лицам не решит проблему. Сначала процесс оптимизируют: пересматривают и сокращают число согласующих до двух, чётко определяют их зоны ответственности. После этого автоматизируют маршрут заявки, что сокращает время согласования до одного дня.

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

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

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

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

Тест займет 3 минуты, но откроет то, о чем ты не подозревал годами...

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

А если захочешь полного очищения — билет на Проектную исповедь уже ждет тебя.

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

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

Что такое канбан-доска

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

В основе классической доски для проектов лежат три ключевых сущности:

• карточки, представляющие work items;
• колонки, отражающие этапы workflow;
• WIP-лимиты — ограничения на число задач в работе одновременно.

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

Зачем нужна канбан-доска

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

→ Pull-based система. В отличие от push-подхода, где задачи назначаются сверху, канбан позволяет команде самостоятельно вытягивать работу по мере готовности. Это снижает context switching и multitasking overhead.

→ Визуализация flow efficiency. Когда весь workflow на виду, моментально становятся заметны блокиеры, зависимости и неравномерное распределение нагрузки. Накопление карточек в определённой колонке — сигнал о необходимости вмешаться и что-то изменить.

→ Управление WIP (Work In Progress). Ограничение числа одновременных задач вынуждает команду сначала завершать начатое, прежде чем браться за новое. Исследования показывают, что снижение WIP часто ускоряет delivery, а не замедляет его.

→ Метрики для принятия решений. Канбан генерирует измеримые данные: cycle time (время от старта до завершения), lead time (от запроса до delivery), throughput (пропускная способность). Эти метрики позволяют прогнозировать сроки и оптимизировать процессы на основе фактов.

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

Как выбрать канбан-доску

При выборе подходящей kanban board для команды разработки обратите внимание на критические параметры:

1. Гибкость workflow. Проверьте, можно ли настроить произвольное количество колонок, создавать подколонки, настраивать swimlanes для разделения фич, багов и техдолга.
2. WIP-лимиты. Хорошие канбан-системы позволяют устанавливать ограничения на количество карточек в колонках. Ещё лучше, если можно настроить политики перехода между колонками (definition of done для каждого этапа).
3. Метрики и аналитика. Нужны не просто красивые графики, а конкретные канбан-метрики: cumulative flow diagram, cycle time distribution, throughput trends.
4. Масштабируемость. Доска должна оставаться понятной даже с тысячами карточек. Проверьте ограничения по количеству карточек, пользователей, проектов на разных тарифах.
5. API и расширяемость. API открывает возможности для автоматизации, создания custom дашбордов, интеграции с внутренними системами.
6. Локализация. Для российских компаний важно наличие в реестре отечественного ПО, возможность on-premise развёртывания.

На основе этих критериев мы собрали лучшие канбан-доски, проанализировали их преимущества и недостатки.

Обзор лучших канбан-досок

Kaiten

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

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

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

• Гибкая настройка канбан-досок.
• Возможность создавать неограниченное количество пространств и досок на них.
• Полноценные WIP-лимиты с визуальными индикаторами превышения.
• Свимлайны для детальной сегментации потоков работы.
• Продвинутая канбан-аналитика: CFD (Cumulative Flow Diagram), контрольные графики, спектральные диаграммы.
• Подколонки позволяют визуализировать внутренние этапы.
• Возможность размещения одной доски в нескольких пространствах — удобно для кросс-функциональной работы.
• Автоматизация на базе триггеров и условий по собственным сценариям пользователей.
• Диаграмма Ганта для команд, которым необходимо визуализировать таймлайн;
• Есть шаблоны для пользователей
• Интеграция с GitHub, GitLab для автоматического обновления статусов
• Дополнительные модули, которые оплачиваются отдельно.
• Бесплатный тариф для работы с базовым канбаном.

Недостатки:

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

Цена:

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

• бесплатный тариф с базовыми канбан-досками;
• Старт — от 185 ₽/мес за пользователя;
• Стандарт — от 430 ₽/мес за пользователя до 15 человек;
• Бизнес — от 580 ₽/мес за пользователя, 6 модулей на выбор.

Также есть отдельный тариф для корпораций — подойдет компаниям с командами 250+ сотрудников. Цена обговаривается индивидуально.

Teamly

Гибридная платформа, объединяющая канбан-доски с базой знаний в стиле Notion/Confluence. Teamly — это ставка на то, что документация и задачи должны жить вместе в едином пространстве.

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

• Умные таблицы с множественными представлениями: канбан, таблица, календарь, диаграмма Ганта, формы.
• Интегрированная база знаний с визуальным редактором.
• AI-ассистент, обученный на документах компании.
• Встроенный Draw.io для диаграмм прямо в статьях.
• Готовые шаблоны процессов для маркетинга, HR, техподдержки, IT.
• Связывание задач на канбан-доске со статьями в базе знаний.
• WebHooks и API для кастомных интеграций.
• Российская разработка с поддержкой OpenLDAP.

Недостатки:

• Канбан здесь скорее дополнение к базе знаний, а не основная функция.
• Нет специализированных канбан-метрик (CFD, cycle time analytics)
• WIP-лимиты и продвинутые канбан-практики не поддерживаются.
• База знаний доступна только на платных тарифах.

Цена: бесплатно до 5 редакторов с ограничениями. От 152 ₽/мес за участника на платных тарифах.

Yandex Tracker

Простое решение от Яндекса, плотно интегрированное с экосистемой Яндекс 360. Tracker позиционируется как замена Jira для российских компаний.

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

• Бесплатен для команд до пяти человек — даже с полным функционалом.
• Можно создавать до 2000 карточек на одной доске.
• Есть возможность для подключения диаграммы Ганта для команды.
• Гибкая система очередей и фильтров для организации канбан-досок
• Поддержка бэклогов и спринтов наряду с continuous flow канбаном.
• Шаблоны пространства, которая команда может настраивать под себя.
• Интеграция с Яндекс.Облаком, Диском, Почтой, Календарем.
• Дашборды с виджетами для визуализации метрик.
• Есть возможность для настройки дочерних/родительских
• On-premise вариант через Yandex Cloud.

Недостатки:

• Привязка к экосистеме Яндекс 360 — нельзя купить только Tracker.
• Канбан-визуализация менее интуитивна, чем у специализированных решений.
• Отсутствие специфичных канбан-метрик типа CFD.

Цена: бесплатно до 5 человек. Есть несколько тарифов:

• 569 ₽/мес за пользователя;
• 779 ₽/мес за пользователя;
• 1539 ₽/мес за пользователя.

Главное различие — в объеме хранилища данных, возможности совершать видеозвонки и числе пользователей.

Projecto

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

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

• Понятные канбан-доски с построением иерархии.
• Комбинация канбана и диаграмм Ганта в одном интерфейсе.
• Учет времени с интеграцией в карточки на доске.
• Есть понятные и кастомизированные отчеты для команд.
• Гибкие роли и права доступа для команды.
• Возможность просматривать лента новостей бизнеса внутри таск-трекера и объявления.
• Фильтрация карточек по статусу, срокам, исполнителям и другим параметрам.
• Российское ПО с хранением данных в РФ.

Недостатки:

• Не подойдёт для крупных компаний — лишь для небольших отделов в них.
• Ограниченная аналитика по канбан-метрикам.
• Мобильные приложения уступают веб-версии

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

• маленькие команды (1-100 чел.): 400 ₽/мес за пользователя.
• растущий бизнес (101-200 чел.): 380 ₽/мес.
• крупные компании (201-1000 чел.): 360 ₽/мес.
• корпорации (1000+ чел.): персональные условия.

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

YouGile

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

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

• Полностью бесплатный для маленьких команд.
• Быстрое внедрение — разработчики заявляют, что команду из ~5 человек можно полностью перевести на YouGile за час.
• Простая встроенная CRM и библиотека расширений — шаблонов, автоматизаций для специфичных процессов.
• Встроен корпоративный мессенджер — у каждой задачи есть отдельный чат.
• Множество дополнительных функций — чек-листы, напоминания, доски, роли, модули автоматизации.
• Кроссплатформенность — веб-версия, десктоп и мобильное приложение, работа онлайн и офлайн.

Недостатки:

• Хотя позиционируется универсально, проекты с тысячами задач и комплексными зависимостями ему даются не так хорошо, как специализированным enterprise-системам.
• Проще по функционалу, чем гиганты вроде Битрикс24 или Jira.

Цена:

Полностью бесплатно для команд до 10 человек без урезания функционала.

• Начиная с 11-го пользователя — лицензия 495 ₽/мес за человека.
• Коробочная версия для сервера — 849 ₽/мес за пользователя, включает приоритетную поддержку и возможность работы в закрытой сети.

Битрикс24

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

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

• Универсальность — канбан в едином пространстве с CRM, мессенджером, видеозвонками, документами, почтой.
• Можно визуализировать как проектные задачи, так и воронку продаж на досках.
• Мощная аналитика — инструменты для объективной оценки работы каждого сотрудника.
• Настройка автоматических действий с карточками на канбане при определенных условиях.
• Различные режимы визуализации — кроме канбана доступны Список, Гант, Календарь, Мой план, Сроки.
• Бесплатный тариф для неограниченного числа пользователей — небольшие команды могут работать бесплатно.
• Масштабируемость — подходит от стартапов до корпораций на 10 000 пользователей.
• Мобильное приложение — специально разработано для работы с задачами и канбан-досками.

Недостатки:

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

Цена:

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

Облачные тарифы:

• Базовый — 2490 ₽/мес (при оплате за год) для 5 пользователей;
• Стандартный — 6990 ₽/мес для 50 пользователей;
• Профессиональный — 13 990 ₽/мес для 100 пользователей (около 140 ₽ за пользователя);
• Энтерпрайз — от 33 990 ₽/мес для 250 пользователей.

TeamStorm

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

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

• Поддержка Kanban и Scrum из коробки
• Ресурсное планирование с учётом рабочих часов и отпусков
• Диаграмма Ганта для планирования зависимостей
• Адаптивная лента для управления бизнес-процессами
• Agile-отчёты для ретроспектив
• Бесплатный тариф без ограничений базового функционала
• Российская разработка

Недостатки:

• Молодой продукт с развивающейся feature base
• Нет WIP-лимитов и детальных канбан-метрик
• Ограниченная экосистема интеграций
• Небольшое комьюнити пользователей

Цена: Бесплатный тариф. От 420 ₽/мес на платных тарифах.

WEEEK

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

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

• Красивый и интуитивный интерфейс канбан-досок — команда может начать работу без обучения, все понятно на уровне интуиции.
• Быстрая адаптация — пользователи отмечают, что можно эффективно работать уже в первую неделю использования.
• Совмещение канбана с CRM-функциями — можно вести клиентскую базу и управлять продажами прямо на канбан-досках.
• Готовые шаблоны досок для разных сценариев — маркетинг, разработка, дизайн, позволяют быстро начать работу.
• Встроенная база знаний — можно хранить документацию и материалы рядом с задачами.
• Интеграции с популярными сервисами — календари (Google, Яндекс), мессенджеры, вебхуки и API для расширения.
• Гостевой доступ — можно бесплатно приглашать внешних участников для совместной работы на досках.

Недостатки:

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

Цена:

Бесплатно для команды до 5 человек с ограничением по числу проектов (7), досок и объему базы знаний.

• Lite (до 10 пользователей) от 159 ₽/мес за пользователя,
• Pro — 319 ₽/мес за пользователя,
• Business — 360 ₽/мес за пользователя.

На платных тарифах снимаются лимиты и добавляются расширенные функции.

Мегаплан

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

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

• Комплексная бизнес-платформа, где есть канбан, CRM, управление проектами, финансы, автоматизация, склад в одной системе.
• Можно визуализировать как проектные задачи, так и воронку продаж на досках.
• Есть возможность адаптировать систему под специфику компании без привлечения разработчиков.
• Мощная автоматизация — настройка бизнес-процессов через схемы, триггеры и роботов для рутинных операций.
• Есть огромное количество интеграций, около 100 сервисов, включая 1С, телефонию, мессенджеры, Яндекс.Метрику, конструкторы сайтов.
• Скрипты и контроль менеджеров — можно выстраивать алгоритмы общения с клиентами и полностью контролировать работу отдела продаж.
• Есть ведение доходов и расходов, контроль движения средств, счета и контрагенты прямо в системе.

Недостатки:

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

Цена:

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

Стоимость начинается от 329 ₽ за пользователя в месяц. Для малого и среднего бизнеса действует программа господдержки — облачная версия доступна со скидкой 50%. Точная стоимость рассчитывается индивидуально в зависимости от количества пользователей и выбранных модулей.

Pyrus

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

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

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

Недостатки:

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

Цена:

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

• Полнофункциональный облачный тариф — от 415 ₽/мес за пользователя.
• Коробочная версия для установки на собственных серверах — от 82 000 ₽/мес за компанию независимо от числа пользователей.

Заключение

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

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

Список разбит по категориям: от браузеров и гейминга до утилит безопасности и инструментов для продуктивности.

Неважно, опытный вы пользователь или новичок — здесь найдётся что-то полезное для каждого.

Браузеры

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

• Большинство пользователей: Chrome, Edge или Safari
• Защита приватности: Firefox, Brave, Ungoogled Chromium
• Опытные пользователи: Vivaldi
• Максимальная анонимность: Tor Browser

Google Chrome

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

Минус один, но существенный: Chrome прожорлив. Если у вас открыто больше десятка вкладок, он может съесть несколько гигабайт оперативной памяти. На компьютерах с 8 ГБ RAM и меньше это становится проблемой.

Mozilla Firefox

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

По скорости Firefox не уступает Chrome, а по потреблению памяти даже выигрывает. Библиотека расширений чуть меньше, чем у Chrome, но все основные инструменты доступны.

Microsoft Edge

Edge построен на том же движке Chromium, что и Chrome, но при этом лучше оптимизирован для Windows. Microsoft вложилась в производительность: браузер работает быстро, потребляет меньше ресурсов и отлично интегрируется с системой.

Особенно приятны функции вроде Collections (коллекции вкладок для организации исследований), режим чтения и встроенный скриншотер. Edge поддерживает все расширения Chrome, так что переход безболезненный.

Brave

Brave — это Chrome на стероидах приватности. Браузер блокирует рекламу и трекеры по умолчанию, что делает сёрфинг быстрее и безопаснее. При этом он полностью совместим с расширениями Chrome.

Есть интересная фишка: Brave Rewards позволяет зарабатывать криптовалюту за просмотр приватной рекламы (если захотите её включить). Спорная механика, но как опция — почему нет. Для тех, кто хочет Chrome без Google и с упором на приватность, Brave — отличный выбор.

Safari (только macOS)

Если у вас Mac, Safari заслуживает внимания. Это самый энергоэффективный браузер для macOS: на MacBook он даёт ощутимо больше автономности по сравнению с Chrome или Firefox. Интеграция с экосистемой Apple безупречна: Handoff, синхронизация через iCloud, Reading List, автозаполнение паролей.

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

Ungoogled Chromium

Для ультраосторожных Ungoogled Chromium удаляет всё отслеживание и сервисы Google — но вам придётся настраивать всё самостоятельно, так как в нём нет автообновлений или встроенной синхронизации.

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

Tor Browser

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

Vivaldi

Vivaldi — браузер мечты для тех, кто хочет полного контроля. Стекирование вкладок, тайлинг, кастомные горячие клавиши, встроенная почта и календарь, веб-панели — это полноценный десктопный опыт внутри браузера. Хотите боковую панель браузера, открывающую ваши заметки, RSS-ленты или любой нужный сайт? Vivaldi это умеет.

Arc

Наконец, Arc — когда-то новичок на рынке браузеров, нацеленный на переосмысление UX: замена традиционной панели вкладок на боковую панель, акцент на веб-приложениях, интегрированные разделённые виды и easels для заметок и доски. К сожалению, компания за Arc прекратила разработку, чтобы полностью переключиться на ИИ с новым браузером, который сейчас в закрытой бета-версии.

Управление паролями

• Лучший бесплатный выбор: Bitwarden
• Также отлично: 1Password, Dashlane, KeePass

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

Также не будем забывать о passkeys (ключах доступа). Если говорить практически, можно сказать, что passkeys объединяют концепцию пароля и двухфакторной аутентификации (2FA) в одно плавное действие, но гораздо безопаснее и гораздо менее раздражающе.

Bitwarden

Полностью опенсорсный, зашифрованный и щедрый даже в бесплатной версии. Вы получаете неограниченное количество паролей, синхронизацию между устройствами и приложения для всех платформ. Премиум ($10/год) добавляет безопасный обмен файлами и инструменты 2FA. Также есть доступные семейные и командные планы.

1Password

Премиум-решение с отполированным интерфейсом, сильной кроссплатформенной поддержкой и отличными функциями вроде Travel Mode (режим путешествий) и полной интеграцией passkeys.

Dashlane

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

KeePassXC

Отличная оффлайн-альтернатива, если хотите полного контроля и не против ручной синхронизации (или использования чего-то вроде Syncthing или Dropbox для синхронизации базы данных).

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

Продвинутые утилиты и дополнения к ОС

• Поиск + лаунчеры: Everything или Wox (Windows), Alfred или Raycast (macOS)
• Пакетные менеджеры: WinGet, Homebrew (macOS)
• Для пользователей Windows: PowerToys
• Для пользователей Mac: Rectangle
• История буфера обмена: ClipClip, Flycut (macOS)
• Скриншоты + аннотации: Monosnap

Winget

Официальный менеджер пакетов Microsoft, встроенный в Windows 10 и 11. Работает похоже на Chocolatey, но разработан и поддерживается Microsoft. Homebrew — самый популярный менеджер пакетов для macOS. Позволяет быстро устанавливать, обновлять и управлять приложениями и CLI-инструментами с помощью команд в терминале.

Everything

Что касается поиска, Everything остаётся золотым стандартом сверхбыстрого поиска по именам файлов в Windows. Он индексирует диски за секунды и выдаёт почти мгновенные результаты с минимальной нагрузкой на систему. Если нужен функционал шире базового поиска, Wox использует движок Everything и добавляет мощные возможности лаунчера: поиск файлов, запуск приложений, калькулятор, перевод текста и расширения через плагины. Получается более гибкий опыт в духе Spotlight для Windows.

Command Palette/Alfred/Raycast

В который раз Microsoft не смогла существенно улучшить встроенный поиск Windows, хотя Command Palette в PowerToys даёт неплохой компромисс для тех, кто не хочет ставить сторонние утилиты.

На macOS Alfred по-прежнему главный лаунчер и утилита поиска. Он быстрый, интуитивный и в бесплатной версии включает историю буфера и настраиваемые поиски; расширенная автоматизация и «воркфлоу» доступны в Powerpack.

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

Менеджеры буфера обмена

Они позволяют возвращаться к ранее скопированному — тексту, изображениям, ссылкам — и сильно ускоряют рутинные операции.

В Windows встроенная история буфера (Win + V) кое-как выручает, но продвинутым пользователям обычно хочется большего. В числе бесплатных рекомендаций — ClipClip для Windows и Flycut для macOS.

Когда речь о скриншотах и аннотациях, штатные инструменты macOS и Windows заметно выросли. Но многим всё равно удобнее сторонние решения. Нам по-прежнему нравится Monosnap за простоту и возможность мгновенно заливать снимки в облако для шаринга (и это бесплатно).

PowerToys — набор полезных утилит от Microsoft для продвинутых пользователей Windows, повышающих продуктивность и упрощающих рабочие процессы. Среди инструментов: FancyZones для продвинутого раскладывания окон, PowerRename для пакетного переименования, Keyboard Manager для ремапинга клавиш, универсальный color picker и другие.

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

Широко используемая альтернатива в Windows — FancyZones (часть PowerToys), предлагающая продвинутое управление окнами: настраиваемые сетки, зоны привязки и поддержку нескольких мониторов — поэтому это фаворит пауэр-пользователей на Windows.

Для рутины и создания проектов

• Бесплатные инструменты: FreeOffice, LibreOffice и WPS Office
• Microsoft Office за единовременную плату $49, Office 2024 — $129
• Заметки: Notion, OneNote, Obsidian
• Бесплатный PDF-редактор: PDFsam
• Почтовые клиенты: Thunderbird, eM Client

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

Microsoft Office остаётся отраслевым стандартом для профессиональной продуктивности. Подписка Microsoft 365 открывает доступ к Word, Excel, PowerPoint, Outlook и включает 1 ТБ облачного хранилища.

Среди бесплатных альтернатив LibreOffice — мощный open-source комплект с сильным сообществом (хотя интерфейс некоторым кажется старомодным). Если нужна внешне более майкрософтовская альтернатива, попробуйте FreeOffice или WPS Office Free — у них хорошая совместимость.

На macOS Pages, Numbers и Keynote предустановлены и более чем достаточны для большинства задач, особенно если вы в экосистеме Apple.

Знания и ведение заметок

Notion стал универсальной платформой организации: заметки, базы данных, to-do, управление проектами, создания совместных рабочих пространств. Если нужны более локальные заметки с синхронизацией между устройствами и поддержкой Markdown, Obsidian — любимец студентов и исследователей.

Для быстрых кроссплатформенных заметок OneNote — крепкий бесплатный вариант от Microsoft. В качестве альтернатив — Simplenote или open-source Joplin.

Если вы занимаетесь академической работой и научными статьями, Zotero — отличный open-source менеджер источников с интеграцией в браузер и совместными коллекциями. Milanote предлагает визуальный подход к заметкам и планированию — идеально для креативных пользователей.

Работа с PDF

Хотя Adobe Acrobat остаётся премиальным редактором PDF, бесплатные альтернативы вроде PDFsam позволяют без усилий объединять, разбивать, редактировать и поворачивать страницы.

Инструменты для дизайна и создания контента

Для дизайна два выделяющихся приложения хорошо дополняют набор продуктивности. Figma Desktop — совместная платформа интерфейс-дизайна, широко используемая UI/UX-дизайнерами и фронтенд-разработчиками. Десктоп-версия работает быстрее, чем браузер, и лучше интегрируется с ОС — это удобно для сложных дизайн-систем и коллаборации в реальном времени.

Canva с интуитивным drag-and-drop превосходно чувствует себя и как десктоп-приложение. Отлично подходит для быстрых графических материалов для соцсетей, маркетинга, постеров и презентаций. Благодаря тысячам шаблонов и совместной работе это фаворит как у профи, так и у новичков.

Почтовые клиенты

Если вы предпочитаете отдельный почтовый клиент, у eM Client много функций, бесплатный — до двух аккаунтов. Mozilla Thunderbird — мощная open-source альтернатива с удобной настраиваемостью, а Mailbird — вариант с упором на продуктивность для тех, кого не пугает подписка.

Инструменты разработчика

• Редакторы кода и текста: VS Code, Cursor, Sublime Text
• Система контроля версий: SourceTree, GitHub Desktop
• Контейнеры: Docker
• Локальные LLM: Ollama
• SFTP, загрузка файлов: WinSCP, Forklift

Для разработчиков Visual Studio Code — безусловный вариант. Бесплатный, лёгкий, но мощный, кроссплатформенный — тысячи расширений покрывают практически любой язык, фреймворк или инструмент. Набирающая популярность альтернатива — Cursor, редактор на базе VS Code с усиленной AI-помощью. Он подходит для связки с LLM: даёт inline-подсказки, генерирует код, рефакторит и позволяет редактировать кодовую базу.

При этом Sublime Text остаётся для скорости и простоты, а Notepad++ — отличный лёгкий редактор для быстрых правок в Windows.

Для Git графические клиенты SourceTree и SmartGit дают понятный интерфейс для управления репозиториями на GitHub, GitLab и не только. GitHub Desktop раньше был простоват и не слишком хорош, но сейчас существенно прибавил — всё ещё простой для работы, но в хорошем смысле.

Для локальных окружений, API-тестирования или терминального воркфлоу инструментов — пруд пруди. Например, Docker Desktop стал стандартом для тех, кто собирает и запускает контейнеризированные приложения на разных платформах. Он упрощает настройку окружений и держит систему чистой.

Ollama позволяет запускать большие языковые модели (LLM) локально с минимальной настройкой. Поддерживает модели вроде LLaMA, Mistral и другие open-weight альтернативы GPT, так что можно работать с ИИ прямо на своём компьютере без отправки данных в облако.

Если вы работаете с облачными хранилищами или SFTP, WinSCP (Windows) и ForkLift (macOS) — отличные клиенты с двухпанельным управлением файлами, синхронизацией и автоматизацией. На Mac также популярны Commander One и Transmit — у них есть встроенные подключения к удалённым и облачным путям.

Безопасность

И Windows, и macOS сегодня предлагают более чем достойную встроенную защиту. С защитой в реальном времени, интеграцией с файерволом и биометрией вроде Windows Hello и Touch ID. Для обычных пользователей, которые соблюдают гигиену безопасности: не скачивают сомнительное ПО, используют менеджеры паролей и включают 2FA — встроенной защиты часто хватает.

Для продвинутых пользователей есть дополнительные варианты.

Отличное первое дополнение — Malwarebytes. Это давний фаворит в обнаружении и удалении malware, adware и руткитов; бесплатная версия по-прежнему хороша для ручных сканов. В платной — защита в реальном времени без ощутимой просадки производительности.

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

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

Мы не поклонники установки антивирусов на каждый компьютер и не полностью в курсе, какие сейчас показывают лучшие результаты. Тем не менее, AV-Test давно и регулярно оценивает популярные решения, поэтому советуем смотреть их свежие отчёты. В текущем списке высокооценённых — Avast, BitDefender, ESET и другие; многие из них предлагают бесплатные версии для пробы.

Удалённый доступ и вспомогательные утилиты

RustDesk стал современным, ориентированным на приватность аналогом TeamViewer. Он с открытым исходным кодом, быстрый и работает кроссплатформенно.

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

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

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

Редактирование изображений и видео

• Профессиональный видеомонтаж: DaVinci Resolve
• Простой видеомонтаж: CapCut
• Редакторы изображений: GIMP, PhotoDemon, Pixelmator Pro
• Бесплатное улучшение изображений: Upscayl
• RAW-редактирование: RawTherapee
• Видеоконвертация: HandBrake

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

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

Для векторной графики — логотипы, иллюстрации — Inkscape является достойным open-source вариантом с полной поддержкой редактирования SVG. Krita — ещё один отличный бесплатный инструмент, особенно подходящий для цифровой живописи и художественного творчества.

Для редактирования RAW-фотографий, Darktable и RawTherapee — два высококлассных open-source аналога Adobe Lightroom. Их широко используют фотографы, которым нужна работа с изображениями без подписки.

Для простых GIF-анимаций ScreenToGif — удобная утилита, мгновенно записывающая область экрана и экспортирующая в GIF или другие форматы с оверлеями.

Среди платных фоторедакторов Adobe Photoshop остаётся лидером, но для macOS есть Pixelmator Pro — мощное приложение с разовой оплатой, а Affinity Photo предлагает профессиональные возможности по более доступной цене.

Видеомонтаж и конвертация

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

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

Для пользователей macOS iMovie предустановлен и остаётся надёжным вариантом для базовых видео. Если вам нужно просто конвертировать или сжимать видео в современные форматы, HandBrake — проверенное бесплатное решение с поддержкой и вариацией входных и выходных форматов.

Тем, кто ищет топовый профессиональный монтаж, подойдут Adobe Premiere Pro и Final Cut Pro, но там есть дорогая подписка и более высокий порог входа.

Коммуникации и совместная работа

• Для повседневной связи: WhatsApp, Messenger и Zoom, если у вас нет FaceTime
• Для приватности: Signal
• Для работы: Slack, Teams
• Для игр и общения: Discord

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

Для личной переписки WhatsApp и Facebook Messenger остаются самыми массовыми платформами по всему миру. У них есть десктопные клиенты и встроенное сквозное шифрование по умолчанию. Telegram также крайне популярен благодаря синхронизации между устройствами и поддержке крупных чатов. Пользователи Apple продолжают активно использовать iMessage для приватного, шифрованного общения в экосистеме Apple.

Из видеоконференций Zoom остаётся одним из лидеров для групповых звонков и онлайн-ивентов, предлагая локальные записи, демонстрацию экрана и комнаты (breakout rooms). Однако бесплатный тариф ограничивает 1:1 звонки 40 минутами, если не перейти на платный план. Zoom поддерживает сквозное шифрование, но при включении E2EE отключаются некоторые функции вроде облачной записи и комнат.

Google Meet — отличный браузерный аналог без необходимости установки, который заметно улучшился по качеству и удобству использования. Многие компании применяют Meet в ежедневной работе и гибридных форматах. Если ваша организация использует Microsoft 365, скорее всего, вы работаете в Microsoft Teams, который уже заменил Skype на корпоративном уровне. Teams поддерживает большие созвоны, обмен файлами и глубоко интегрирован с Office. Сквозное шифрование доступно, но только для 1:1 звонков.

FaceTime по-прежнему отличный для пользователей Apple, и благодаря новым обновлениям к звонку теперь могут присоединяться и пользователи Android/Windows по ссылке через браузер.

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

Для рабочих коммуникаций Slack и Teams продолжают использоваться в бизнес-среде. Бесплатный тариф Slack ограничивает историю 90 днями и звонки, но остаётся любимцем стартапов и малых команд благодаря интеграциям и ботам. Cisco Webex — также крепкий вариант, особенно популярен в корпоративной среде.

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

Для внутриигрового голосового чата TeamSpeak остаётся олдскульным достойным вариантом: можно использовать анонимно и получать полный контроль над сервером. Встроенный чат Steam лучше, чем раньше, и помогает в игровой координации, но большинство всё же выбирает Discord.

Гейминг, моддинг и стриминг

• Игровые платформы: Steam, Epic Games, EA App, Ubisoft, GOG
• Последние драйверы для GPU: Nvidia GeForce, AMD Radeon, Intel Arc
• Стриминг: OBS Studio

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

Не менее важно установить Epic Games Store. Хотя библиотека меньше, он регулярно раздаёт бесплатные игры, доступные любому с аккаунтом Epic. Это также must-have, если вы играете в Fortnite.

Помните: не все издатели размещают игры на Steam или Epic. Для тайтлов EA понадобится EA App (ранее Origin), для Ubisoft — Ubisoft Connect, для Blizzard/Activision — Battle.net, а GOG Galaxy не только предлагает DRM-free классику, но и может агрегировать игры из других лаунчеров.

Некоторые сверхпопулярные игры распространяются отдельно: Minecraft (через Minecraft.net или Microsoft Store), Roblox, League of Legends и Valorant (через лаунчер Riot Games). Если вы новичок и ищете что-то лёгкое, можно начать с free-to-play тайтлов или классики вроде Brutal Chess или GZDoom.

Если вы играете с геймпадом, Windows поддерживает Xbox-контроллеры из коробки. PlayStation-контроллеры теперь тоже отлично работают: Steam через Steam Input поддерживает DualShock 4 и DualSense практически во всех играх. При необходимости глубокой кастомизации можно использовать DS4Windows, но большинству хватает возможностей Steam.

Если вас интересует моддинг, хороший менеджер модов время в этой жизни:

• Mod Organizer 2 — лучший для RPG Bethesda (Skyrim, Fallout).
• Vortex (от Nexus Mods) — дружелюбный к новичкам и поддерживает широкий перечень игр.

Для записи геймплея или стриминга Nvidia ShadowPlay и AMD Radeon ReLive подходят для простых задач. Но для стриминга с вебкой, сценами, оверлеями или многосценовым продакшеном OBS Studio — безальтернативный лидер. Он бесплатный, open-source и подходит как новичкам, так и про-стримерам (Twitch, YouTube, Kick и т.д.). SignalRGB помогает синхронизировать весь RGB-зоопарк и задавать динамические эффекты.

Мониторинг железа и разгон

• Мониторинг: CPU-Z, HWMonitor, HWiNFO64
• Настройка и разгон: Afterburner, FanControl, ThrottleStop, SignalRGB

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

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

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

Чтобы проверить хранилище, CrystalDiskMark измеряет скорость чтения/записи SSD и HDD — это помогает понять, соответствует ли диск заявленным характеристикам. Глубже оценить здоровье накопителя можно в Hard Disk Sentinel, который анализирует SMART-данные, оценивает срок службы и предлагает ограниченный ремонт.

С точки зрения охлаждения, всё больше геймеров используют утилиты для настройки вентиляторов. FanControl — актуальный бесплатный фаворит: поддерживает сложные кривые оборотов, привязку к датчикам, и совместим с большинством современных материнских плат. На Mac одной из лучших утилит остаётся Macs Fan Control.

Для настройки видеокарт долгое время стандартом был MSI Afterburner — для разгона, настройки вентиляторов и мониторинга с RTSS-оверлеем. Однако из-за замедления обновлений многие сегодня используют встроенные утилиты от Nvidia (GeForce Experience/Control Panel) и AMD (Adrenalin Software).

Если вы меняете видеокарту или подозреваете проблемы с драйверами, обязательно используйте Display Driver Uninstaller (DDU) — он полностью очищает систему от старых драйверов перед переустановкой.

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

Тем, кто серьёзно подошёл к разгону CPU и GPU, пригодятся фирменные инструменты вроде Intel XTU (для Intel) и AMD Ryzen Master — они дают контроль над частотами, напряжениями и лимитами мощности.

Управление файлами

• Поиск больших файлов: SpaceSniffer, WizTree, Disk Drill (macOS)
• Поиск дубликатов: dupeGuru
• Архивы и ZIP: PeaZip, The Unarchiver
• Очистка: BCUninstaller, CCleaner Portable, AppCleaner (macOS)

Чтобы грамотно управлять файлами и освобождать место, нужно понимать, что именно занимает пространство. На Windows популярны WinDirStat и WizTree — быстрые бесплатные инструменты для визуализации диска. SpaceSniffer предоставляет динамическую схему.

На macOS — GrandPerspective и Disk Drill предлагают аналогичный функционал, а DaisyDisk — один из самых красивых платных вариантов с молниеносным сканированием.

Если дубликаты засоряют диск, dupeGuru (open-source) отлично справляется с поиском повторяющихся изображений и музыки, даже слегка изменённых.

Для пакетного переименования файлов (например, фоточек с камеры) существует гибкий Bulk Rename Utility. Если нужно что-то попроще: PowerRename из PowerToys (Windows) или встроенный инструмент в Finder (macOS) подходят большинству.

Встроенный File Explorer в Windows недавно получил вкладки и стал удобнее, но Files (open-source) — современная альтернатива с улучшенным UX. Кто-то ещё пользуется Total Commander или Directory Opus, благодаря расширяемости и скриптам, хотя новичкам они кажутся устаревшими. Для просмотра изображений по-прежнему незаменим IrfanView.

Для работы с архивами, если не устраивает встроенный ZIP-менеджер Windows, скачайте 7-Zip или PeaZip. На Mac лучшим бесплатным инструментом остаётся The Unarchiver.

Для очистки системы важно выбирать надёжные утилиты. На Windows, BCUninstaller (Bulk Crap Uninstaller) — один из самых проверенных для удаления программ и их хвостов. BleachBit и Wise Disk Cleaner — безопасные альтернативы CCleaner (лучше использовать Portable-версию, так как стационарная испортила репутацию). На Mac AppCleaner всё ещё любим за полное удаление приложений без мусора.

Если вы организуете большую библиотеку медиа, стоит взглянуть на open-source TagSpaces, позволяющий тегировать файлы локально, без облака.

Облачное хранилище и резервное копирование

• Простая синхронизация: Dropbox, Google Drive
• Фото между устройствами: Apple iCloud, Google Photos
• Приватность: pCloud, Proton Drive, Internxt
• Полные бэкапы: Backblaze, IDrive

Базовое облачное хранилище

Dropbox — один из самых простых в использовании, хотя бесплатных 2 ГБ мало.

Google Drive — 15 ГБ бесплатно, используется Gmail, Docs и Photos. Идеален для Android.

OneDrive — идёт в комплекте с Windows и Microsoft 365. 1 ТБ включён в большинство Office-планов. Хотя по скорости и интерфейсу уступает Dropbox/Google.

iCloud Drive — лучший выбор для пользователей Apple, глубокая интеграция с macOS/iOS. Бесплатно 5 ГБ, далее по планам до 2 ТБ.

Proton Drive — шифрованная альтернатива от создателей ProtonMail.

Фото и видео

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

На Windows мы часто рекомендуем Google Photos, который предлагает аналогичный набор функций и автоматизацию. Для пользователей Android — это стандарт по умолчанию. Да, раньше было безлимитно, теперь фото занимают общее место Google Drive (15 ГБ), которое быстро заканчивается.

Полные бэкапы

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

Backblaze — топ в этой категории: фиксированная цена (~$8/месяц за устройство), безлимитное хранилище, минимум настроек: установил и забыл.

IDrive — более контролируемый вариант, поддерживает несколько устройств, внешние диски и версионность файлов.

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

Профессионалам — Acronis Cyber Protect: клон дисков, анти-вымогатель, гибридное облако.

Для особо чувствительных данных

Если вы храните личные финансовые документы или медицинские сведения, стоит выбрать end-to-end решений.

pCloud предлагает клиентское шифрование (через платный «Crypto»). Даже при взломе аккаунта файлы не расшифруются без ключа.

Proton Drive — аналогичный подход, с прозрачностью open-source.

Прочие полезные инструменты, не вошедшие в другие разделы

Google Earth — для любителей карт и планировки.

qBittorrent — лучший torrent-клиент: чистый, без рекламы, с поиском. Альтернатива — легковесный Transmission или кастомизируемый Deluge.

iMazing — must-have для владельцев iPhone: резервные копии, экспорт медиа, проверка батареи, конвертация HEIC.

AirDroid — аналог для Android: управление файлам, уведомления, SMS с ПК.

Rufus — лидер по созданию загрузочных USB-дисков для Windows/Linux.

Open Shell — возвращает классическое меню «Пуск» в стиле Windows 7.

Stretchly — напоминает делать перерывы — полезно удалёнщикам и фрилансерам.

AutoHotkey — скриптовый движок для Windows: переназначение клавиш, макросы, автоматизация.

VPN: бесплатные — ProtonVPN, Windscribe, TunnelBear (с лимитом). Платные — ProtonVPN, NordVPN.

Calibre — лучшее бесплатное решение для чтения, организации и конвертации e-book (EPUB, MOBI, PDF и др.).

Заключение

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

Несколько советов напоследок:

1. Не захламляйте систему. Устанавливайте только то, что действительно используете. Чем меньше фоновых процессов — тем быстрее работает компьютер.
2. Следите за обновлениями. Большинство программ обновляются автоматически, но некоторые требуют ручного апдейта. Свежие версии — это не только новые функции, но и закрытые уязвимости.
3. Делайте резервные копии. Никакие утилиты не спасут от отказа жёсткого диска. Регулярный бэкап на внешний носитель или в облако — обязательная практика.
4. Экспериментируйте. Попробуйте несколько браузеров, редакторов, плееров. То, что подходит большинству, может не подойти именно вам.
5. Читайте отзывы. Перед установкой незнакомого приложения загляните на форумы или Reddit. Сообщество быстро выявляет проблемы и подводные камни.

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

Три истории о коде и ИИ

История первая: Магия автоматизации

Юрий, продуктовый аналитик, потратил 10 минут на диалог с Claude, чтобы создать скрипт для обработки CSV-файлов с данными пользователей. Раньше такая задача заняла бы у него день изучения документации pandas и отладки. Теперь он просто описал, что нужно: «Сгруппируй по регионам, посчитай среднюю выручку, сохрани в Excel». Получил рабочий код, запустил — всё работает идеально.

История вторая: Цена доверия

В июле 2025 года Джейсон Лемкин, основатель SaaStr и известный венчурный инвестор, проводил 12-дневный эксперимент с «vibe coding» на платформе Replit. На девятый день, несмотря на явное указание «НЕ ДЕЛАТЬ БОЛЬШЕ ИЗМЕНЕНИЙ без разрешения», ИИ-агент Replit удалил всю продакшн-базу данных.

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

История третья: Реальность внедрения

Команда разработки финтех-стартапа начала использовать GitHub Copilot полгода назад. Первые месяцы были болезненными: code review растянулись вдвое — нужно было проверять не только логику, но и безопасность автогенерированного кода. Несколько раз находили SQL-инъекции в предложенных запросах, один раз ИИ сгенерировал код с утечкой памяти.

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

Эти истории показывают весь спектр vibe coding — от магии до катастрофы. В чём же дело?

Где работает, где ломается

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

История Лемкина показывает обратную сторону. ИИ-агент Replit работал корректно несколько дней, выполнял задачи, помогал строить приложение. Но когда столкнулся с «пустыми запросами к базе» — ситуацией, не покрытой в его обучении, он «запаниковал» и принял катастрофическое решение. Хуже того, он проигнорировал явную команду остановиться и потом солгал о возможности восстановления. Подобные ловушки ждут везде, где ИИ сталкивается с неоднозначностью, где критична надёжность, где требуется следование строгим протоколам безопасности».

Причина различий не в «умности» ИИ, а в фундаментальных ограничениях, которые описал Салищев.

Математика против магического мышления

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

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

Салищев подчёркивает: проектирование без математики — это гадание. Но что это значит на практике? В реальности мы имеем дело не с единой «математикой», а с целым спектром строгости подходов.

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

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

Эволюция, а не революция

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

Сейчас мы переживаем первую волну — ИИ как продвинутый autocomplete. Он ускоряет генерацию типовых функций и классов, автоматизирует рутинные задачи, но риск скрытых ошибок остаётся высоким. В ближайшие 3-5 лет ожидается вторая волна: интеграция с формальными методами. ИИ научится автоматически генерировать спецификации из естественного языка, встроенный статический анализ станет нормой, системы CI/CD будут включать проверку ИИ-кода по умолчанию. ИИ превратится во «второго архитектора», но под контролем человека.

Третья волна через 5-10 лет может принести мета-проектирование: ИИ будет предлагать новые абстракции и паттерны, автоматически переводить требования в формальные спецификации, управлять сложными распределёнными системами. Среда разработки станет диалоговым интерфейсом с инженерной машиной.

Изменение профессиональных ролей

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

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

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

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

Команды будущего

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

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

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

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

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

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

Гибридный подход

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

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

Образование в новой эре

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

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

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

Риски и ограничения

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

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

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

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

Заключение: прагматичный оптимизм

Vibe coding — не панацея и не угроза, а мощный инструмент, который требует зрелого подхода. Как напоминает работа Салищева, сложные системы не терпят высокомерия. Фраза «да тут всё и так понятно, зачем математика?» — сигнал тревоги, независимо от того, говорит ли её человек или подразумевает ли её использование ИИ.

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

Те, кто научится эффективно сочетать возможности ИИ с фундаментальными знаниями, получат значительные преимущества. Те, кто понадеется только на «магию» vibe coding или, наоборот, будет её игнорировать, рискуют остаться позади.

Эпоха перемен уже началась. Время готовиться — сейчас.

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

1. YouGile CRM : простой способ управлять продажами и задачами

YouGile CRM — часть системы управления проектами YouGile. Здесь есть все для ведения продаж (CRM), управления задачами и коммуникацией. Это подходит небольшим командам, в которых менеджеры по продажам и разработчики работают в связке и нужно не переключаться между разными (и иногда лишними) инструментами.

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

Как решает задачи команд

Хранение базы клиентов и сделок

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

Автоматизация и напоминания

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

Работа в одном окне

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

Простая аналитика

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

Сценарии по ролям

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

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

Формат работы и интеграции

YouGile CRM — облачное решение. Доступно API для интеграций с ERP‑системами, маркетплейсами и онлайн‑кассами, есть мобильные приложения. Хранение данных локализовано в РФ, а сам продукт входит в реестр российского ПО.

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

Чем выделяется

• Минимальный порог входа. Создание воронки и приглашение команды занимают около 15 минут, поэтому внедрение не требует отдельного проекта.
• Единая среда для работы. CRM живёт в том же пространстве, что и таск‑трекер, календарь и мессенджер, что удобно техническим командам.
• Локализация под российский рынок. Интерфейс и поддержка — на русском, акцент на хранение данных в РФ.
• Возможность кастомизации под отрасль. Система подходит для торговли, услуг и производства: можно настроить поля и процессы под конкретные сценарии.

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

2. amoCRM: автофиксация лидов и воронки с digital-компонентом

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

Основной акцент — на автоматической фиксации заявок из разных каналов и работе с воронкой продаж.

Как это работает

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

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

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

Digital Pipeline и автоматизация

Отличительная функция — Digital Pipeline (диджитал воронка). Это модуль для автоматизации продвижения клиентов по воронке через онлайн-каналы. Вы можете настроить показ определенной рекламы в зависимости от этапа сделки, отправлять уведомления, отслеживать реакцию клиента на действия.

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

Триггеры и кастомизация

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

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

API развитый — 50 запросов в секунду на аккаунт (стандартно для систем такого уровня). Есть готовые расширения для интеграции с внешними сервисами, можно кастомизировать без навыков программирования через marketplace.

Для кого подходит

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

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

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

3. Аспро.Cloud — платформа для продаж, проектов и финансов

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

Что делает CRM‑модуль

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

Где применяется

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

Какие задачи закрывает:

• Работа с клиентами и продажами: ведение базы клиентов, несколько воронок, управление сделками, автоматические действия и напоминания, интеграции с почтой, телефонией и мессенджерами.
• Документооборот и финансы: формирование счетов и актов в пару кликов, контроль оплат, учет расходов и доходов, поддержка нескольких счетов и валют, план‑факт анализ.
• Проекты и задачи: контроль сроков, бюджета и загрузки команды, пять форматов для мониторинга (канбан, диаграмма Ганта, календарь, список, GTD‑планировщик), трекинг времени.
• Аналитика и контроль: отчеты по продажам, финансам, лидам и загруженности проектов и сотрудников.
• Командная работа: встроенные чаты, уведомления, комментарии, единое рабочее пространство, гибкие права доступа и гостевой режим для клиентов и подрядчиков.
• Склад и учет товаров: управление товарами и услугами, складской учет.
• Знания и обучение: база знаний для сотрудников и клиентов, хранение документации и инструкций, онбординг.
• Мобильность и интеграции: мобильные приложения для iOS и Android, API и готовые интеграции с телефонией, банками, облачными хранилищами, почтой, 1С, онлайн‑кассами, сайтами, мессенджерами и соцсетями.

Подходы и методология

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

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

• Руководитель контролирует сделки, получает отчеты, прогнозирует выручку и мониторит задачи на канбан‑доске или диаграмме Ганта.
• Менеджер по продажам работает с карточкой клиента, ведет историю взаимодействий, звонит через IP‑телефонию, формирует счета и коммерческие предложения.
• Маркетолог сегментирует базу, выгружает данные и анализирует эффективность каналов: причины отказов, работу менеджеров, этапы воронки.
• Служба поддержки получает обращения через мессенджеры и чат на сайте и ведет их в виде заявок по канбану.
• Владелец бизнеса видит единую картину по продажам, финансам и задачам в одном интерфейсе и может анализировать ключевые показатели.

Особенности и отличия

Интерфейс локализован под российский рынок. Данные хранятся на серверах в РФ, система входит в реестр отечественного ПО. Есть гибкая тарифная сетка: стоимость зависит от количества сотрудников, набора функционала и объема хранилища.

Можно кастомизировать интерфейс и инструменты под отраслевые сценарии.

Технические детали

Аспро.Cloud — облачное решение. Есть открытый API для интеграции с ERP, 1С, онлайн‑кассами, маркетплейсами. Сервис поддерживает собственные мобильные приложения для iOS и Android. Ограничения по числу пользователей и объему хранилища зависят от выбранного тарифа.

Управление и поддержка

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

4. Мегаплан: таск-менеджер с CRM и отраслевыми сценариями

Мегаплан позиционирует себя как систему управления бизнесом, а не классическую CRM. Основной акцент на управлении задачами и проектами с добавлением модуля для работы с клиентами. Разработка российская, на рынке с 2008 года, входит в реестр отечественного ПО.

Система заточена под малый и средний бизнес в производстве, строительстве, оптовых продажах и B2B-услугах. Есть готовые решения для 27 отраслей — от недвижимости до производства.

Как устроена архитектура

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

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

Интеграции: 1С (важный момент для компаний с бухгалтерией на 1С), телефония, WhatsApp, Telegram, почта. API доступен на всех тарифах, есть маркет готовых интеграций.

Отраслевые решения

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

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

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

Управление задачами и проектами

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

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

Бизнес-процессы и автоматизация

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

Шаблоны документов (счета, договоры, коммерческие предложения) заполняются автоматически из данных CRM-карточки. Это экономит время на рутинных операциях.

Отличие от триггерных систем вроде amoCRM: здесь автоматизация завязана не на digital-каналы, а на внутренние процессы — перемещение задач по этапам, назначение ответственных, формирование документов.

Облако vs коробка

Мегаплан предлагает два варианта размещения: облако (серверы компании в России) и коробочная версия (ваши серверы). Для коробки указано «скоро» — возможно, она в разработке или доступна по отдельному запросу.

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

Для кого подходит

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

Для B2B-услуг с проектной работой (консалтинг, разработка, маркетинг) система подходит за счет модуля управления проектами и задачами с привязкой к клиентам.

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

5. RetailCRM: омниканальная система для ecommerce с программой лояльности

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

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

Управление заказами и интеграции

Центральный модуль — обработка заказов из всех источников в едином окне. Система автоматически подтягивает заказы с сайта, маркетплейсов (Ozon, Wildberries, Яндекс.Маркет, AliExpress, Мегамаркет, Avito) и мессенджеров, создает карточку заказа с полной историей.

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

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

Работа с товарами

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

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

Мессенджеры и соцсети

Модуль «Чаты» (входит в тариф «Профессиональный») объединяет все диалоги в едином интерфейсе. Официальные интеграции с Instagram, WhatsApp, Telegram, Viber, Avito, ВКонтакте, Facebook, онлайн-консультант на сайте.

Заказы можно оформлять прямо в чате, не переключаясь между вкладками: выбор товара, расчет доставки, отправка ссылки на оплату, печать документов. Чаты автоматически конвертируются в заказы и переносятся в систему.

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

CRM-маркетинг и лояльность

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

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

AI-помощники

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

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

Аналитика

Полная воронка продаж с определением этапов, где «зависают» товары. Оценка эффективности работы менеджеров, unit-экономика, структура доходов и расходов, анализ маркетинговых коммуникаций и бюджета.

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

Для кого подходит

RetailCRM специализируется на ecommerce. Если вы продаете через интернет-магазин, маркетплейсы и соцсети одновременно — система решает задачу централизации всех заказов и коммуникаций.

Ограничения: система заточена под ecommerce и розничные продажи. Для B2B-услуг без товарных позиций или сложных производственных процессов она избыточна. Профессиональный тариф стартует с 3 пользователей — для совсем малого бизнеса (1-2 человека) это может быть дорого. Модуль чатов оплачивается отдельными лицензиями поверх основного тарифа.

Какую систему выбрать?

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

YouGile подходит небольшим командам до 10 человек, которым нужна бесплатная связка CRM + таск-трекер + мессенджер без дополнительных инструментов. Внедрение занимает 15 минут, система автоматически выводит дела на день, чтобы менеджеры не теряли клиентов.

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

Обе системы — российские разработки с хранением данных в РФ. Для малого бизнеса с простыми процессами достаточно YouGile, для компаний с несколькими отделами и сложным учетом — Аспро.Cloud даст больше контроля.

Я рассмотрела более 40 программ корпоративного обучения и выбрала 22 наиболее эффективные. В начале материала собрала ТОП-10 курсов, которые дают комплексное понимание корпоративного управления. Далее — подборка дополнитепльных программ, рассчитанных на развитие отдельных компетенций, и несколько бесплатных вариантов для самостоятельного изучения.

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

ТОП-10 лучших курсов корпоративного управления в 2026 году

1. Корпоративное управление от SF Education — курс, направленный на практическое понимание юридических и финансовых основ бизнеса.
2. Организация корпоративного обучения и технологии развития персонала от АНО «НИИДПО» — программа, посвященная построению системы корпоративного обучения и развитию HR-менеджмента.
3. Корпоративное управление и стратегическое развитие бизнеса от МИПО — программа MBA, объединяющая изучение корпоративного управления и стратегического планирования.
4. Корпоративное право от РШУ — повышение квалификации с разбором примеров, M&A-сделок и инструментов корпоративного управления.
5. Директор корпоративного управления от MBS — программа, ориентированная на подготовку управленцев высшего звена со знанием стратегии и финансов.
6. Корпоративный секретарь от РШУ — курс, раскрывающий практические аспекты правового сопровождения корпоративных структур.
7. Современные подходы к корпоративному управлению от MBS — программа MBA, развивающая стратегическое мышление и управленческие компетенции.
8. Руководитель: команда и бизнес-процессы от Нетологии — курс, помогающий выстраивать эффективные команды и управлять процессами.
9. Основы корпоративного управления от MBS — краткая программа для изучения базовых принципов корпоративного менеджмента.
10. MBA в области лидерства от Eduson Academy — курс, направленный на развитие лидерских качеств и управленческого потенциала.

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

Онлайн-курсы корпоративного управления

1. Корпоративное управление | SF Education

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

Получить скидку>>>

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

• Стоимость: от 612 руб. в месяц (рассрочка на 12 месяцев)
• Длительность: 3,5 часа
• Формат обучения: потоковый и асинхронный формат, видеолекции, практические задания, доступ к чату и материалам навсегда
• Сертификат: документ SF Education, подтверждающий освоение программы

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

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

• доступ к материалам навсегда;
• скидки и промокоды на обучение;
• можно пройти в удобное время;
• рассрочка без переплат;
• поддержка преподавателей и кураторов;
• практические кейсы из реального бизнеса;
• участие в программе Trade-In (экономия до 50%);
• подарочные подписки от партнеров;
• лицензия на образовательную деятельность;
• обучение у эксперта с 15-летним опытом;
• литература SF Education в подарок.

Недостатки:

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

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

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

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

2. Организация корпоративного обучения и технологии развития персонала | АНО «НИИДПО»

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

• Стоимость: 18 300 руб. (рассрочка 0% от 1 525 руб./мес. на 12 месяцев без первого взноса)
• Длительность: 12 недель (400 часов)
• Формат обучения: дистанционно, текстовые и видеоуроки, вебинары, тестирование, практические задания с проверкой и обратной связью от преподавателей, бессрочный доступ к материалам после завершения обучения
• Сертификат: диплом о профессиональной переподготовке установленного образца Московского института

Кому подойдет: специалистам по персоналу, HR-менеджерам, тренинг-менеджерам, руководителям подразделений, предпринимателям, работающим с командой и заинтересованным в развитии сотрудников

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

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

Недостатки:

• часть вебинаров проводится по расписанию, требующему обязательного присутствия онлайн.

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

• Управление персоналом как часть системы менеджмента
• Характеристика и структура персонала организации
• Методы и принципы кадрового менеджмента
• Организация адаптации и наставничества
• Работа с профессиональными стандартами
• Тренинги и методы обучения сотрудников
• Формирование кадрового резерва и карьерного маршрута
• Система повышения квалификации в организации

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

3. Корпоративное управление и стратегическое развитие бизнеса | Московский институт профессионального образования (МИПО)

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

• Стоимость: от 36900 руб. ( возможна рассрочка и налоговый вычет 13%)
• Длительность: 1 год 6 месяцев (2700 часов)
• Формат обучения: дистанционно с применением онлайн-вебинаров, разбором кейсов, видеоматериалов, тестированием и поддержкой персонального куратораСертификат: диплом MBA установленного образца, вносимый в Федеральный реестр сведений о документах об образовании (ФИС-ФРДО), с международным приложением Diploma Supplement

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

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

• диплом MBA, признаваемый в России и за рубежом;
• обучение без отрыва от работы;
• индивидуальный куратор на весь период программы;
• онлайн-вебинары и разборы реальных кейсов;
• доступ к лекциям и записям на весь срок обучения;
• преподаватели с опытом работы от 7 до 25 лет;
• возможность ускоренного обучения;
• международные эксперты с практическим опытом;
• оформление налогового вычета до 13% стоимости;
• возможность поступления в рассрочку без переплат.

Недостатки:

• большая учебная нагрузка (2700 часов);
• необходимы базовые знания в области менеджмента.

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

• Корпоративные стратегии
• Моделирование бизнес-процессов и реинжиниринг
• Управление путем делегирования полномочий и аутсорсинг
• Практика корпоративного управления
• Корпоративное право

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

4. Корпоративное право | РШУ

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

• Стоимость: 53 400 ₽ (рассрочка на 12 месяцев от 4 984 ₽)
• Длительность: 5 дней (40 академических часов, с 09:00 до 16:00)
• Формат обучения: очно, онлайн или в видеокурсе (вебинары, практические задания, анализ кейсов, доступ к записям на 30 дней, бессрочный доступ к материалам)
• Сертификат: удостоверение о повышении квалификации государственного образца, вносимое в ФРДО

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

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

• программа соответствует приказу Минобрнауки РФ №499м;
• удостоверение вносится в Федеральный реестр документов об образовании;
• обучение ведут практикующие юристы, адвокаты и эксперты корпоративного права;
• 70% практики и 30% теории в курсе;
• бессрочный доступ к учебным материалам;
• возможность выбора формата — очный, онлайн или видеокурс;
• обучение проходит на территории ВДНХ;
• детальный разбор реальных кейсов слушателей;
• персональная обратная связь от преподавателей;
• доступ к библиотеке подкастов и методическим материалам;
• корпоративные программы под задачи компаний.

Недостатки:

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

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

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

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

5. Директор корпоративного управления | Moscow Business School

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

• Стоимость: от 7 875 руб. в месяц (рассрочка на 24 месяца, возможна корпоративная форма обучения)
• Длительность: 10 месяцев
• Формат обучения: очно или онлайн (вебинары, кейсы, семинары, практические занятия, сопровождение куратора, доступ к библиотеке и записям вебинаров)
• Сертификат: диплом о профессиональной переподготовке и сертификат Moscow Business School установленного образца

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

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

• диплом о профессиональной переподготовке, соответствующий госстандартам;
• преподаватели с опытом работы от 5 до 25 лет;
• доступ к 100+ вебинарам и материалам в аудио- и текстовом формате;
• разбор кейсов с экспертами школы;
• участие в очных и онлайн-семинарах;
• карьерное консультирование и помощь в трудоустройстве;
• индивидуальный куратор на весь период обучения;
• гибкий формат — очно или онлайн;
• корпоративные сертификаты, признанные работодателями;
• безлимитный доступ к курсам школы;
• программа соответствует профстандартам Минтруда РФ;

Недостатки:

• очные занятия доступны не во всех городах.

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

• Повышение качества управления в корпоративных структурах
• Менеджмент
• Стратегический менеджмент
• Финансы в организации
• Управление человеческими ресурсами
• Операционный менеджмент
• Руководство и лидерство в организациях
• Экономическая среда бизнеса
• Нейросети для маркетинга
• Итоговый проект и карьерное консультирование

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

6. Корпоративный секретарь | Русская Школа Управления (РШУ)

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

• Стоимость: 47 400 руб. (рассрочка от 4 424 руб. в месяц)
• Длительность: 4 дня (32 академических часа, с 09:00 до 16:00)
• Формат обучения: онлайн, очно или в видеокурсе (вебинары, практические задания, кейсы, доступ к записям на 30 дней, бессрочный доступ к материалам в личном кабинете)
• Сертификат: удостоверение о повышении квалификации установленного государственного образца, внесенное в ФРДО

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

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

• программа соответствует Приказу Минобрнауки РФ № 499м;
• удостоверение вносится в Федеральный реестр документов об образовании;
• 70% практики и 30% теории;
• разбор реальных кейсов и ситуаций слушателей;
• доступ к записям и материалам после обучения;
• возможность обучения в гибком формате — очно, онлайн или по видеокурсу;
• преподаватели — практикующие юристы и адвокаты;
• обучение на территории ВДНХ;
• бессрочный доступ к обновляемой библиотеке подкастов;
• корпоративные программы под задачи компании;
• помощь в освоении цифровых инструментов документооборота;

Недостатки:

• короткая продолжительность курса;
• ограниченные даты проведения;
• участие в очных модулях требует присутствия в Москве;

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

• Схемы и модели построения группы компаний
• Правовое обеспечение корпоративного управления
• Новеллы корпоративного законодательства и правоприменительная практика
• Правовое сопровождение корпоративных процедур и сделок
• Лучшие практики корпоративного управления

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

7. Современные подходы к корпоративному управлению | Moscow Business School (MBS)

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

• Стоимость: от 13 708 руб. в месяц (рассрочка на 24 месяца)
• Длительность: 14 месяцев
• Формат обучения: онлайн (видеоуроки, вебинары, практические задания, бизнес-кейсы, нетворкинг, сопровождение куратора, безлимитный доступ к дополнительным курсам MBS)
• Сертификат: диплом «Master of Business Administration (MBA)» и общеевропейское приложение Diploma Supplement, признаваемое за рубежом

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

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

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

Недостатки:

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

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

• Экономическая среда бизнеса
• Маркетинг
• Менеджмент
• Стратегический менеджмент
• Финансы в организации
• Управление человеческими ресурсами
• Операционный менеджмент
• Учет и отчетность
• Руководство и лидерство в организациях
• Организационное развитие и управление изменениями
• Стратегическое управление компаниями
• Бонусный модуль
• Итоговый проект

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

8. Руководитель: команда и бизнес-процессы | Нетология

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

Получить скидку>>>

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

• Стоимость: от 3 464 руб. в месяц (рассрочка до 24 месяцев, возможность оплаты частями или единым платежом 79 000 руб.)
• Длительность: 3,5 месяца (112 часов теории и практики)
• Формат обучения: видеолекции, вебинары, деловые игры, практические задания с проверкой экспертов, воркшопы, доступ к материалам в личном кабинете и мобильном приложении
• Сертификат: удостоверение о повышении квалификации установленного государственного образца

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

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

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

Недостатки:

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

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

• Стратегическое, тактическое и операционное управление
• Управление рисками
• Управление бизнес-процессами
• Постановка и контроль выполнения задач
• Работа с кадрами
• Управление конфликтными ситуациями
• Итоговый проект по оптимизации бизнес-процессов и работы команды

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

9 Основы корпоративного управления | Moscow Business School (MBS)

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

• Стоимость: 21 510 руб.
• Длительность: 1 день (с 10:00 до 17:30)
• Формат обучения: очно или онлайн, лекции, практические разборы, комплект авторских материалов, кофе-паузы
• Сертификат: удостоверение о повышении квалификации или сертификат Moscow Business School государственного образца

Кому подойдет: юристам, корпоративным секретарям, менеджерам, руководителям акционерных обществ, специалистам по корпоративному праву и консультантам, работающим с корпоративными структурами

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

• обучение ведет кандидат юридических наук и эксперт-практик Илья Некрасов;
• программа основана на действующих нормах корпоративного законодательства;
• курс длится один день — идеально подходит для занятых специалистов;
• формат обучения на выбор — очно или онлайн;
• возможность получить официальный документ установленного образца;
• обсуждение реальных кейсов и практических ситуаций компаний;
• авторские материалы от Moscow Business School входят в стоимость;
• гибкий график и индивидуальный подход к слушателям;
• возможность участия в корпоративном формате для команд;
• лицензия на образовательную деятельность № 038233 от 20.02.2017 действует бессрочно;
• поддержка менеджеров школы до и после обучения;

Недостатки:

• короткая продолжительность курса;
• ограниченные даты проведения;
• для участия в очном формате необходимо присутствие в Москве;

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

• Проектирование системы корпоративного управления в акционерном обществе
• Корпоративный секретарь в структуре акционерного общества
• Дистанционная часть (факультативно)

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

10. MBA в области лидерства | Академия Eduson

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

• Стоимость: от 16 583 руб. в месяц (рассрочка на 12 месяцев)
• Длительность: 3 месяца
• Формат обучения: видеолекции, бизнес-кейсы, онлайн-тренажеры, домашние задания с обратной связью, индивидуальная консультация с экспертом
• Сертификат: удостоверение о повышении квалификации или диплом Академии Eduson установленного образца

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

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

• обучение по международным стандартам МВА;
• участие экспертов мирового уровня;
• доступ к курсу и обновлениям навсегда;
• возможность обучения без расписания и дедлайнов;
• формат с практическими кейсами и интерактивными заданиями;
• обратная связь от кураторов и экспертов;
• персональная консультация для профессионального роста;
• материалы, шаблоны и чек-листы для реальной работы;
• государственная лицензия №374370 от 27.05.2022;
• подходит для корпоративного обучения;
• возможность оформить налоговый вычет;

Недостатки:

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

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

• Что значит быть лидером
• Личная эффективность
• Управление сотрудниками и командой
• Управление дистанционной и гибридной командой
• Коучинг как лидерская технология
• Управление конфликтами
• Эмоциональный интеллект
• Деловая переписка и деловое общение
• Публичные выступления и презентации
• Управление инновациями
• Проектное мышление
• Искусственный интеллект и цифровая трансформация

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

Еще 8 курсов корпоративного управления

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

• Профессиональная переподготовка в корпоративном управлении от Учебного центра АПОК. Программа профессиональной переподготовки по корпоративному управлению помогает освоить системное руководство компанией, понять принципы взаимодействия акционеров, директоров и топ-менеджмента. Курс формирует навыки стратегического планирования, управления персоналом, финансового анализа и организации бизнес-процессов. Обучение проводится полностью дистанционно, что позволяет изучать материалы в удобное время и проходить итоговую аттестацию онлайн. Выпускники получают диплом установленного образца, подтвержденный регистрацией в государственном реестре ФИС ФРДО, и могут претендовать на должности корпоративных секретарей и менеджеров по управлению.
• Профессиональная переподготовка по корпоративному управлению от Учебного центра «ЭКОДПО». Курс профессиональной переподготовки по корпоративному управлению ориентирован на изучение современных методов стратегического и организационного менеджмента. Программа охватывает темы, связанные с анализом корпоративных структур, финансовым планированием, управлением персоналом и совершенствованием бизнес-процессов. Обучение проходит в дистанционном формате, что удобно для специалистов, совмещающих работу и учебу. По завершении курса проводится аттестация, после которой слушатели получают диплом государственного образца с внесением данных в ФИС ФРДО и бесплатной доставкой по России.
• Управление проектами в бизнесе от МТИ. Программа профессиональной переподготовки по управлению проектами в бизнесе направлена на развитие навыков стратегического планирования, командного взаимодействия и контроля выполнения задач. Слушатели изучают принципы формирования проектных команд, оформления документации, анализа рисков и оценки эффективности бизнес-процессов. Обучение проводится дистанционно, что позволяет осваивать материал в удобном темпе. После завершения курса выпускники получают диплом о профессиональной переподготовке и могут работать менеджерами проектов, консультантами или руководителями подразделений.
• Корпоративное управление от Института профессионального образования. Программа МВА mini по корпоративному управлению направлена на развитие стратегического мышления и управленческих навыков у руководителей высшего и среднего звена. В ходе обучения слушатели изучают принципы современного менеджмента, финансового планирования и корпоративной культуры, а также осваивают методы мотивации персонала и эффективного лидерства. Программа основана на практических кейсах, реальных примерах и аналитических заданиях, что помогает участникам применять полученные знания в своей компании. По окончании обучения выдается диплом МВА российского и международного образца.
• Корпоративное управление от Открытого Образования. Онлайн-курс знакомит с современными принципами и моделями корпоративного управления, применяемыми в России и за рубежом. Участники изучают механизмы взаимодействия акционеров, менеджеров и сотрудников, методы оценки эффективности управления и принципы разрешения корпоративных конфликтов. В программе рассматриваются практические подходы к построению организационных структур и анализу собственности компании. Обучение длится 10 недель и включает видеолекции, тесты и материалы для самостоятельного изучения. После успешной сдачи экзамена выдается официальный сертификат.
• Корпоративное управление от НУГС. Программа направлена на развитие управленческих компетенций в области корпоративного администрирования и стратегического менеджмента. Слушатели изучают концепции и модели корпоративного управления, основы планирования, оценку эффективности, корпоративные риски и управление в группе компаний. Программа сочетает российский и международный опыт, что помогает адаптировать лучшие практики к отечественным условиям. Обучение доступно в очной, очно-заочной и дистанционной формах. По завершении выдается диплом Национального университета государственной службы о профессиональной переподготовке.
• MBA Корпоративное управление от СНТА. Программа профессиональной переподготовки по направлению MBA «Корпоративное управление» предназначена для руководителей и специалистов, стремящихся системно развить управленческие навыки и стратегическое мышление. Обучение охватывает ключевые направления — организационное развитие, корпоративные финансы, лидерство и стратегическое планирование. Курс реализуется в заочной форме с применением дистанционных технологий, что позволяет совмещать обучение с работой. По завершении участники получают диплом установленного образца с внесением данных в ФИС ФРДО, а документы доставляются по всей России.
• Обучение корпоративному управлению от Управляйте.рф. Программа предназначена для специалистов, желающих освоить современные принципы корпоративного управления и получить международную квалификацию, признанную в Европе и Азии. Курс включает изучение структуры советов директоров, механизмов управления стоимостью компании, корпоративных рисков, ESG-подходов и цифровой трансформации бизнеса. Формат обучения дистанционный, с возможностью участия в онлайн-сессиях, деловых играх и консультациях с экспертами. Участники осваивают реальные кейсы и получают практические навыки, необходимые для работы в советах директоров или консультировании компаний. По завершении выдается международный сертификат и включение в профессиональный реестр выпускников.

Бесплатные курсы корпоративного управления

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

1. Корпоративное управление от Лекториума. Курс посвящен основам корпоративного управления и принципам внутреннего контроля. В нем рассматриваются ключевые элементы эффективного управления компанией, построение систем риск-менеджмента и внедрение внутренних контролей. Слушатели узнают, как выявлять и оценивать риски, разрабатывать механизмы их минимизации и тестировать внедренные решения. Программа сочетает видеолекции, практические тесты и обсуждения в онлайн-чате. После завершения обучения участники получают именной сертификат, подтверждающий освоение курса.
2. Корпоративное управление от Alexander A. Lebedev. Онлайн-курс разработан для тех, кто стремится развить управленческое мышление и получить реальные знания о корпоративных советах и структуре управления компаниями. Программа знакомит с историей корпоративного управления, ролью совета директоров, принципами стратегического развития и повышением инвестиционной привлекательности бизнеса. Видеоуроки Александра Лебедева раскрывают практические аспекты участия в советах директоров и ревизионных комиссиях. Формат обучения — полностью дистанционный, с доступом к видеоматериалам, интервью и аналитическим лекциям. Курс помогает слушателям выстроить понимание корпоративных процессов и подготовиться к работе в органах управления крупных компаний.
3. Базовые принципы антикризисного управления от Карьера и Бизнес. Подкаст посвящен ключевым принципам антикризисного управления и помогает понять, какие действия лежат в основе успешного выхода компании из сложных ситуаций. Автор — Константин Савкин — делится практическими подходами к управлению бизнесом в условиях неопределенности, рассматривая стратегию, лидерство и коммуникации как инструменты стабилизации. Формат коротких выпусков делает материал удобным для восприятия и применения в повседневной работе.
4. Антикризисное управление бизнесом от Академии Смысла для бизнеса. Видеолекция раскрывает практические подходы к антикризисному управлению и сохранению эффективности бизнеса в нестабильной экономической среде. Андрей Курпатов подробно объясняет, как руководителю выстраивать коммуникацию с командой, снижать уровень тревожности сотрудников и направлять энергию коллектива в продуктивное русло. Отдельное внимание уделено стратегическому мышлению, поиску новых рынков, перестройке процессов и адаптации маркетинга под изменившиеся условия. Материал помогает управленцам сохранять ясность мышления и принимать рациональные решения даже в период неопределенности.

Ключевые навыки для эффективного корпоративного управления на программах переподготовки

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

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

Влияние цифровых технологий на управление бизнес-процессами в организациях

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

• ниже операционные затраты;
• выше скорость реакции на сбои;
• больше уверенности в прогнозах, основанных на данных.

Управление превращается в игру с хорошей статистикой, а не в бег по темному коридору.

Как курсы MBA развивают стратегическое мышление для успешного бизнеса

На MBA больше не учат просто «управлять». Там строят мышление, которое смотрит на бизнес как на цепочку последствий. Учебные модули устроены как реальные задачи: нет правильных ответов, но есть последствия. Один неправильный поворот — и вся команда катится вниз. Именно на таких уроках появляется:

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

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

Роль независимых директоров в повышении корпоративной прозрачности и доверия инвесторов

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

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

Особенности управления холдингами: что нужно знать специалистам для эффективного контроля

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

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

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

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

Особый интерес вызывают форматы, где:

• учебные задачи повторяют реальные управленческие вызовы;
• вместо экзаменов — работа над собственным проектом;
• материалы адаптированы под международную аудиторию

Как развивать лидерские качества и управленческие навыки через специализированные программы

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

• управление конфликтами;
• выстраивание диалога;
• поведенческая аналитика.

Часто обучение строится вокруг:

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

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

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

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

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

Как улучшить операционную эффективность и капитализацию компании через образовательные инициативы

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

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

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

Современные подходы к анализу рисков и управлению ими в сфере операционного менеджмента

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

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

Как новые модели корпоративного контроля помогают специалистам по аудиту бороться с рисками

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

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

Цифровизация и управление данными: как менеджеры осваивают современные инструменты для планирования

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

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

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

Поделитесь, какие курсы по корпоративному обучению прошли вы и как они повлияли на вашу карьеру! Какие навыки и знания, полученные на курсах, были наиболее полезными для вашего профессионального роста и принятия стратегических решений в бизнесе?

Ошибка 1. Агрессия и хамство

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

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

Анна Жаркова, руководитель мобильной практики ГК Юзтех, подтверждает, что хамство встречается редко, но перечёркивает всё:

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

Евгений Антонов, тимлид в Yandex Infrastructure и IT-консультант, подчёркивает важность профессионализма в вопросе общения с кандидатами:

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

Саша Шинкевич, руководитель разработки продуктов Яндекс Контест, резюмирует:

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

Совет: общайтесь вежливо и дружелюбно, настройтесь на сотрудничество. Если что-то непонятно — спросите, а не защищайтесь.

Ошибка 2. Попытки обмануть или приукрасить

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

Плохо, когда в резюме указан опыт работы с определёнными технологиями, но наводящие вопросы показывают полное незнание темы. Такие ситуации лично меня как интервьюера заставляют задуматься, а что ещё из описанного может быть неправдой. Любое техническое собеседование — это не только проверка умения решать алгоритмические или технические задачи, но и тест на способность мыслить и действовать под давлением стресса. Если кандидат открыто предлагает использовать дополнительные материалы (например, проверяет документацию используемой библиотеки или активно работает с подсказками редактора кода) во время интервью, в этом нет ничего плохого. Однако попытки тайно подсмотреть ответы или получить подсказки сразу бросаются в глаза — даже если кандидат думает, что действует незаметно.

Порой кандидаты прибегают к откровенным уловкам, например, используют подсказки друзей во время онлайн-интервью. Александр Коротаев вспоминает курьёз:

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

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

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

Евгений Антонов считает, что использование шпаргалок допустимо, если кандидат знает, что искать:

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

Глеб Михеев, руководитель программного комитета FrontendConf, автор телеграм-канала Уставший техдир, ведущий подкаста «Фичи катятся», ментор и консультант, считает, что ненадёжные кандидаты читаются сразу:

Фейк-эксперты палятся моментально — по уверенности, по словам, по дыханию.

Совет: если чего-то не знаете — скажите честно. Тимлиды уважают честность больше, чем идеальное резюме.

Ошибка 3. Неуважение ко времени

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

Если кандидат опаздывает и не предупреждает, мы ждём максимум 15 минут и закрываем интервью. Это тоже результат — просто отрицательный.

Анна Жаркова добавляет, что опоздания из-за технических сбоев можно понять, но уведомить HR-а нужно обязательно:

Люди могут опаздывать чисто по техническим причинам. Тут будет правильнее предупредить интервьюера через HR.

Совет: проверьте и настройте свою технику заранее. Если опаздываете — предупредите.

Ошибка 4. Неподготовленность и отсутствие мотивации

Когда кандидат не может внятно рассказать о своих проектах, путается в деталях или демонстрирует полное незнание о компании, это вызывает разочарование. Саша Шинкевич делится:

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

Отсутствие подготовки не только затрудняет оценку кандидата, но и заставляет тимлидов сомневаться в его заинтересованности. Александр Коротаев подчёркивает:

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

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

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

Ошибка 5. ЧСВ и снисходительный тон

Некоторые кандидаты ведут себя так, будто компания должна быть благодарна за их отклик, демонстрируя высокомерие. Александр Коротаев вспоминает:

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

Такое поведение создаёт барьер, ведь тимлиды ищут тех, с кем комфортно работать в команде:

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

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

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

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

Ошибка 6. Болтовня и нерелевантные ответы

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

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

В другом случае он отмечает:

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

Анна Жаркова подчёркивает:

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

Совет: лучше честно скажите, что не знаете ответа. Затем объясните, как бы вы подошли к задаче. Так вы покажете, как именно мыслите.

Ошибка 7. Отсутствие диалога

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

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

Александр Коротаев уточняет:

Вопросы нужны, но это не связано с моим желанием, чтобы всё было "по шаблону". Хочется знать, что мы оба понимаем друг друга правильно. Что в работе он тоже не уйдет в самостоятельное плаванье без фидбека, когда время будет потеряно, а человек не пойми зачем ушел в дебри, которые и не были нужны.

Совет: подготовьте вопросы о команде и процессах. Например, как проходит код-ревью или как в компании дают фидбэк.

Вывод

Тимлиды не ждут идеальных ответов. Забытый термин, пауза для размышлений или небольшая растерянность — это нормально и не повод для отказа. Однако ложь, хамство и равнодушие моментально портят впечатление. Александр Коротаев считает, что важен баланс:

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

Эксперт также рекомендует заранее изучить компанию:

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

Советы тем, кто готовится к собеседованию:

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

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

Читайте также:

• Техническое собеседование: как пройти и подготовиться к нему
• Оффер во фронтенде в 2025 году: как получить и не облажаться
• Скрутка и накрутка опыта: работает ли это в айтишке
• Поливоркинг в IT: полезная стратегия для карьеры или путь к выгоранию?

Тектонический кадровый сдвиг: миллениалы и зумеры

Поколенческие разломы в IT-сфере становятся всё очевиднее. Миллениалы (Y) видят в карьере долгосрочный проект с целью роста до руководителя. Зумеры (Z) ищут интересные задачи, технологии и возможность проявить экспертность, легко меняя место работы, если их интересы не учитывают.

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

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

Преподаватель MBA-дисциплин по управлению персоналом Анна Кутко видит корни этого различия в историческом контексте: «Игреку нужна стабильность, прозрачные перспективы, потому что это поколение росло, когда мир активно менялся, проходил кризисы. Поэтому они стремятся строить карьеру системно. Z родились в эпоху цифровизации, и у них сформировалось клиповое мышление, им сложно потреблять информацию сразу большими объемами. По моим наблюдениям, зетам нужно всё здесь и сейчас. Чтобы их заинтересовать, важно учитывать, что им комфортно общение онлайн — должны быть специальные платформы, на которых они будут видеть свои обязанности и их стоимость. Например, есть хороший опыт у Ozon и "Самоката" — в их приложениях сотрудникам видны задачи, размер и дата оплаты».

Но как эта разница в мировоззрении проявляется в конкретных карьерных стратегиях именно в IT и в требованиях к работодателям?

От карьерной лестницы к экспериментам

Траектория карьеры претерпела, пожалуй, самые радикальные изменения. Модель «джуниор-миддл-сеньор-тимлид» перестала быть единственной.

Директор кадрового агентства Anti-HR и собственной HR-школы Татьяна Филатова констатирует:

«Примерно десять лет разделяет поколения Y и Z, но их карьерные ориентиры и ожидания различаются существенно. Миллениалы, заставшие рождение интернета и цифровой бум, видели в IT в первую очередь стабильность и возможность построить успешную карьеру. Их идеалами были специалисты из крупных компаний вроде Microsoft, Google или Яндекс. Карьера представлялась, как лестница.

Для поколения Z карьера — устаревшее понятие в принципе, для них это серия интересных экспериментов. Их ролевые модели — IT-фрилансеры, создатели стартапов, блогеры и разработчики в сфере Web3 и AI. Они не боятся менять компании каждые 1-2 года, работать одновременно в нескольких проектах или создавать свой. Горизонтальный рост для них часто важнее вертикального: интереснее освоить новый стек технологий, чем стать менеджером.

Зумеры хотят чувствовать смысл в том, что они делают. Им важна забота о ментальном здоровье: доступ к психологу, программы против выгорания, открытая корпоративная культура без токсичности. Нужна прозрачность и быстрая обратная связь. Работа, по их мнению, должна вдохновлять, приносить пользу и встраиваться в образ жизни, а не наоборот. Тогда как Y готовы хорошо и много работать в обмен на благополучие, возможности личностного и профессионального развития. Их запрос сейчас, в отличие от поколения Z, абсолютно понятен работодателю».

Это подтверждает и управляющий партнер «Агентства Маркетинговых стратегий Макс» Ульяна Павлова. Она приводит конкретные данные: «Миллениалы строили карьеру внутри компаний, а затем массово уходили в самозанятость/аутсорс — именно Y стали драйвером роста самозанятых в 2025 г.

По данным исследования ВТБ, зумеры заходят в компании очень активно — много стажировок, быстрые переходы между должностями, при этом высокая активность в смене места работы. Хотя есть новые исследования, где видно, что Z, как и предыдущее поколение, ищет стабильности: они охотно меняют места в начале карьеры, но готовы оставаться пять и более лет там, где условия прозрачны и развитие реально».

Руководитель по ресурсному обеспечению IT Smart Finance Артем Кириллов резюмирует это чёткой формулой: «Если для Y характерна "долгая дорога" — постепенный рост до роли архитектора или тимлида, ставка на стабильность, грейды, соцпакет и экспертность, то для Z важнее серии коротких спринтов, быстрая смена ролей и проектность. Лояльность тоже изменилась: у Y она к команде и продукту, а у Z — к возможностям роста и развитию личного бренда».

Деньги, смыслы и ментальное здоровье: новая мотивация

Фокус сместился с внешних атрибутов успеха на смыслы и благополучие.

Руководитель внешних коммуникаций hh.ru Мария Бузунова, ссылаясь на исследования сервиса, указывает ключевые тренды:

— Смена фокуса с процесса на результат. Для миллениалов важен был сам процесс построения карьеры и долгосрочные достижения. Например, в рамках опроса hh.ru, на вопрос «Что для вас — работа мечты?» респонденты в возрасте от 25 до 34 лет отвечали, что важные факторы — это своевременная зарплата (51%), возможность карьерного роста и профессионального развития (38%), польза обществу от работы (20%). Зумерам скорее важны быстрый измеримый результат и эмоции. Чаще всего респонденты 18-24 лет, при описании работы мечты, указывают возможность баланса жизни и работы (67%) — это самый высокий показатель среди остальных возрастных когорт. Значимо чаще, чем миллениалы, зумеры указывают отсутствие переработок (35%) и то, что работа должна вписываться в образ жизни (25%). При этом для обоих поколений наиболее важен баланс личной жизни и работы. А респонденты 55 лет и старше реже указывают этот фактор (34%).

— Смысл против стремления к стабильности. «Миллениалы выросли в нестабильное время, что сформировало их запрос на надежность, понятность процессов и накопления. Зумеры ищут в работе не просто доход (хотя их стартовые запросы существенно выше, чем были у миллениалов), а цель. Им важно, чтобы задачи были интересными, а миссия компании совпадала с их ценностями. Они могут отказаться от задачи, если не видят её смысла», — отметила Мария Бузунова.

Взгляд изнутри от практика добавляет нюансов. Фронтенд-разработчица, тимлид Яндекса Саша Шинкевич наблюдает такую картину: «Для поколения Y работа рассматривается скорее как долгосрочное партнёрство, стабильная зарплата, горизонт на годы вперед, рост, пусть не всегда быстрый, но предсказуемый. Для многих игреков быть айтишником — часть самоидентичности. Для молодого поколения работа может быть менее приоритетной стороной жизни. Это лишь способ получить опыт и доход. И если работодатель "не заходит", смена места или проекта воспринимается спокойно. Как ни удивительно, я иногда вижу больше осознанности в вопросе "действительно ли мне нравится этим заниматься» именно у ребят помладше"».

При этом, как подчеркивает Ульяна Павлова, одной зарплатой зумеров не удержать: «В 2025 г. растёт значимость ДМС и дополнительных отпусков; интерес к обучениям/конференциям падает, зеты интересуются психологическим портретом начальства и комфортом». Для них важна забота о ментальном здоровье и «поглаживание по голове». Это отмечает и преподаватель MBA-дисциплин по управлению персоналом Анна Кутко: «Для зетов важно межличностное общение, позитивная обратная связь от руководителя, потому что это дети, которые выросли у поколений X и Y, а те не всегда охотно дают хороший фидбэк».

Условие прозрачности и технологии

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

Во-первых, это требование к ясным условиям. Управляющий партнер «Агентства Маркетинговых стратегий Макс» Ульяна Павлова приводит яркий пример: «8 из 10 представителей Z, в отличие от Y, не откликаются на вакансию с припиской "зарплата по договорённости". Требуют конкретные вилки, KPI, понятные правила бонусов».

Во-вторых, технологические ожидания. Ульяна Павлова указывает, что генеративный AI по умолчанию требуется в работе для Z: «Они приходят готовыми работать с ИИ или очень быстро учатся ИИ-грамотности. Российские компании уже масштабно внедряют GenAI; в ИТ это норма 2024-2025 гг.».

Руководитель по ресурсному обеспечению IT Smart Finance Артем Кириллов добавляет: «В обучении Y традиционно выбирали длинные курсы и сертификации, тогда как Z предпочитают микрообучение, пет-проекты, менторство и использование ИИ-ассистентов».

Что в итоге? Вызов для работодателя

Карьерные ожидания трансформировались от стабильности к свободе. Директор кадрового агентства Anti-HR и собственной HR-школы Татьяна Филатова заключает: «Если Y ценили надежность одного работодателя, то Z ценят свободу выбора и мобильность. Потребность в линейном росте сменилась многовариантностью. Печеньки и корпоративы перестали быть решающим аргументом. На первый план вышли гибкость, миссия компании и забота о благополучии сотрудника».

Разрыв, о котором говорит Ульяна Павлова, — главный вызов для HR и работодателей: «Мы наблюдаем, как HRам, которые привыкли работать с миллениалами, приходится меняться под требования ценностей молодых и сильных IT-специалистов».

Нестандартный взгляд на проблему предлагает Product Owner в Skillaz и автор телеграм-канала «Серёжа печатает» Сергей Попов: «Я не делю людей на поколения, для меня есть три группы: ребята до 25 лет — молодёжь; 25-35 лет — "переходное" поколение; 35 плюс — "олды".

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

У молодёжи другой подход — она не воспринимает работу как средство достижения успеха, это инструмент заработка. Если раньше люди становились айтишниками, потому что им нравилась эта роль, то сейчас среднестатистический молодой разработчик скажет, что пошёл в IT потому, что это приносит бабки. Они хорошо знают свои границы, понимают про work-life-balance, умеют чувствовать свою стоимость на рынке труда, не делают ничего бесплатно. В этом смысле они относятся к себе гораздо лучше, чем "олды", и это правильно. Вопрос в том, насколько этот подход хорош для IT, ведь много крутых продуктов создано как раз, когда люди пахали ночами и горели идеей.

Если все будут работать с 10:00 до 19:00, вряд ли IT сможет развиваться так же мощно, как раньше. Если работодателю нужен огромный успех и быстрый результат — это к "олдам". Молодёжь редко относится к работодателям хорошо, считая, что это люди, которые используют их ресурс для своего успеха. Выстраивая работу с молодёжью, нужно фиксировать все договорённости».

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

Я проанализировала около 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? Какие курсы или материалы стали для вас наиболее полезными? Поделитесь своим опытом в комментариях — это поможет другим сделать правильный выбор и начать обучение с уверенностью.

Что мы видим в реальности?

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

И всё это — следствие одного и того же: отсутствия системного подхода к управлению процессами.

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

«Хороший продукт рождается не только из кода, но и из чётко выстроенных процессов»

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

Почему процесс важнее человека?

Представьте: ваш лучший разработчик, тот самый, кто «держит всё в голове», уходит. Или просто выгорает. Что остаётся? Паника, недели (а то и месяцы) простоя; знания, унесенные в никуда. Человек — не железный. Процесс — да. Именно он — ваш истинный страховой полис. Не набор бюрократии, а живая система, которая стандартизирует рутину, позволяет безопасно делегировать, превращает новичка в бойца за дни, а не недели, и наконец-то делает прогнозы не гаданием, а осознанным планом. Клиент перестает дергаться, менеджер — дышать в бумажный пакет. Это ли не мечта?

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

Целевое использование времени: зачем нужен мониторинг?

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

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

В таких случаях говорят: «Работали много, работали качественно… но почему-то ничего не готово».

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

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

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

Процесс позволяет:

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

Перегруз сотрудника: симптомы и причины

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

Каждый из нас знает, что такое выгорание. Но не все понимают, как оно начинается. Часто это происходит незаметно — постепенно.

Вот несколько симптомов перегрузки сотрудника:

• Постоянное чувство усталости, даже после выходных.
• Снижение концентрации, забывчивость, рассеянность.
• Раздражительность, конфликты в команде.
• Задачи выполняются медленнее, чем раньше.
• Работа занимает всё больше времени, включая сверхурочные.
• Увеличение количества ошибок и багов.
• Снижение интереса к проекту, отсутствие инициативы.
• Появление фраз вроде: «Мне всё надоело» или «Я не вижу смысла».

Почему горим? Пять смертных грехов процесса (или его отсутствия):

• Культ героя

«Вася один сделает, ему проще!» Знакомо? Вася превращается в незаменимого, а его знания — в риски для всей компании. Уйдет Вася — рухнет всё.

• Документация? Не, не слышали

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

• Ад многозадачности

Встречи, срочные запросы, прыжки между задачами каждые полчаса… Фокус размыт, эффективность падает. Мозг не резиновый!

• Бег по кругу

Задача «сделана»? Не спешите радоваться! Вот она вернулась — дизайн перепридумали, бэкенд не стыкуется, ТЗ «немного» изменилось. Нет чёткого «Done» — есть бесконечный марафон.

• Не по Сеньке шапка

Человеку дали задачу не по его скиллам. Он молчит, боится признаться, бьётся как рыба об лед, тратит уйму времени… Результат — стресс, ошибки, ощущение собственной неполноценности.

Как мониторинг помогает понять, кто что может?

Итак, перейдем уже наконец-то к сути. Одним из главных процессов выступает мониторинг. Рассмотрим мониторинг анализа команды.

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

На основе таких данных можно сделать несколько выводов:

• Иван сильнее других в вёрстке.
• Марии нужна поддержка при работе с API.
• Петру стоит пройти обучение по DevOps-процессам.
• Ольга хорошо справляется с автономной работой.

Это уже не просто статистика, а точка роста для всей команды.

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

Советы по интерпретации данных:

• Не сравнивайте людей напрямую: у всех разный уровень подготовки и скорость работы.
• Фокусируйтесь на динамике: например, если задача, которая ранее занимала 12 часов, теперь занимает 7 — это прогресс.
• Смотрите на то, какие задачи решает сотрудник: если он берётся за сложные и новые — это тоже успех.
• Обсуждайте результаты в команде, а не в одностороннем порядке: пусть сам сотрудник объяснит, почему задача заняла столько времени.

В чем соль? Какие могут быть итоги мониторинга

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

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

Все эти ситуации — скрытые потери времени, которые не всегда видны на первый взгляд, но влияют на:

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

Вот самые распространенные «точки утечки»:

Эти проблемы могут существовать годами и съедать время и деньги компании, пока кто-то не начнёт их анализировать и менять.

Рассмотрим более детально каждый кейс

• ТЗ — всему голова (или нет)?

Написано на салфетке без техкоманды — разработчики стартуют в тумане.

Решение: Technical Discovery — священный ритуал перед стартом задачи. Все за столом, все поняли, все согласны.

• Тестирование

Баги ловят уже после релиза, чек-листов нет — стоимость исправлений зашкаливает.

Решение: чёткие критерии приемки в начале задачи. Автотесты — не роскошь, а страховка. Регресс — не наказание, а норма.

• Согласования

Вечный двигатель правок? «Ой, а давайте ещё вот это…», — звучит как приговор сроку.

Решение: жёсткий процесс Change Request. Хочешь изменить? Оцени трудозатраты, согласуй с клиентом цену/сроки. Никакого «ну это же быстро!».

• Деплой

Русская рулетка? Ручные костыли, нет CI/CD — каждый релиз как прыжок с парашютом в неизвестность. Ошибки, откаты, ночные бдения. Решение: автоматизация — ваш друг.

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

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

Code Review

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

Тестирование (manual / automated)

• QA-инженеры проверяют, что функционал работает корректно.
• Автотесты ловят регрессии на раннем этапе.
• Без тестирования сложно понять, что новый функционал не сломал старый.

Чек-лист завершённости задачи

• Например, все поля валидируются? Есть ли обработка ошибок? Проверено ли поведение на разных устройствах?
• Такие списки позволяют стандартизировать проверку и исключить «случайные» проблемы.

Автоматическое тестирование (CI/CD pipeline)

• Запуск тестов перед каждым деплоем.
• Проверка покрытия тестами.
• Линтинг кода, анализ производительности.

User Acceptance Testing (UAT)

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

Post-release monitoring

• Логирование ошибок в реальном времени.
• Использование инструментов вроде Sentry, LogRocket, Bugsnag.
• Быстрое реагирование на инциденты.

Выгода для бизнеса

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

Когда вы улучшаете процессы, вы:

• снижаете трудозатраты,
• сокращаете количество ошибок и переделок,
• ускоряете вывод продукта на рынок,
• повышаете удовлетворённость клиентов,
• увеличиваете повторные продажи.

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

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

Время — деньги. Особенно, если вы работаете в конкурентной нише.

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

И она тем выше, чем позже ошибка обнаружена.

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

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

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

1. Yonote

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

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

Yonote подходит для:

• Командной работы: планирование задач, контроль
  сроков, управление проектами, CRM, сбор и визуализация отчётов, хранение
  инструкций и регламентов.
• Личных целей: заметки, трекер задач,
  бюджетирование, планирование поездок, учёба и хранение материалов.
• Создания Wiki: организация базы знаний о
  продукте с древовидной структурой, вставкой таблиц, диаграмм и медиа, историей
  изменений и комментариями.
• Ведения
  документации: базы данных по
  клиентам, проектам и инвентарю с таблицами, фильтрами, канбан-досками и
  календарями, прикреплением файлов и ссылок.

Формат работы

Yonote работает через web-интерфейс с удобным Markdown-редактором, поиском и историей изменений. Можно встраивать код, схемы и embed-ссылки из GitHub, Figma, Miro и других сервисов.

Поддерживается полный доступ по API, импорт и экспорт в Markdown и PDF, хранение на своих серверах (on-prem) и в облаке. Yonote предлагает более 30 интеграций, включая GitHub, Jira, Trello, Telegram, Miro и Airtable. Настраиваются уровни доступа: можно создавать гостевые аккаунты, разграничивать права на чтение и редактирование, делиться публичными ссылками.

Yonote заменяет несколько инструментов сразу (Trello, Google Docs, Confluence, личные заметки), легко адаптируется под любые задачи, подходит для госорганизаций, частных компаний и личного использования.

Тарифы

• Базовый — бесплатно, 5 ГБ, до 5 пользователей и 10 гостей.
• Старт — 149 ₽ за пользователя в месяц, 20 ГБ, до 50 гостей.
• Про — 249 ₽ за пользователя в месяц. Доступен безлимит гостей, неограниченное хранилище, SSO.
• Enterprise — тариф для организаций с расширенной поддержкой и контролем.

2. Anytype

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

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

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

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

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

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

Формат работы

Anytype работает офлайн на мобильных и десктопных устройствах (iOS, Android, Windows, macOS, Linux), без веб-версии. Скоростная P2P-синхронизация возможна через локальные сети.

Интерфейс основан на визуальном код-фри (no-code) редакторе: можно создавать базы данных, таблицы, канбаны, галереи и граф-связи между объектами.

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

Для разработчиков:

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

Цена и условия пользования

• Explorer — бесплатно, подходит для личного использования.
• Builder — $99 в год за пользователя, открывает расширенные функции и поддержку командной работы.
• Co-Creator — $299 в год за пользователя, с расширенными возможностями и дополнительной свободой кастомизации.

Весь интерфейс и работа — на английском языке.

3. Obsidian

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

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

Есть несколько сценариев:

• Личные заметки и дневники: быстрый доступ к записям на устройстве, структурирование мыслей, создание связей между идеями.
• База знаний и обучение: построение персональных вики с перекрёстными ссылками, графами связей и быстрым поиском.
• Управление проектами и исследованиями: создание канбанов и карт идей в Canvas для планирования и брейншторминга, публикация заметок для команды

Формат работы

Obsidian — десктопное и мобильное приложение (Windows, macOS, Linux, iOS, Android). Доступны следующие форматы:

1. Поддержка открытых форматов файлов (Markdown), которая обеспечивает долгосрочное хранение данных без зависимости от сервиса.
2. С помощью Obsidian Publish можно публиковать заметки как публичную вики, документацию с настраиваемым внешним видом и быстрым поиском.

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

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

Цена и условия пользования

• Бесплатно: использование приложения для личных нужд, хранение данных локально.
• Sync — $4 в месяц за пользователя при оплате за год, синхронизация заметок между устройствами с шифрованием, история версий, совместная работа в общих хранилищах.
• Publish — $8 в месяц за сайт при оплате за год, публикация заметок на сайт без технических знаний, настройка тем и структуры.

4. Gramax

Gramax — платформа для подготовки документации в подходе Docs as Code. Позволяет создавать и редактировать статьи в визуальном редакторе, хранить исходники в Markdown и версионировать их с помощью Git. Подходит для тех, кто хочет управлять документами, знаниями и любым другим контентом в своей инфраструктуре гибко и безопасно.

Как и в Notion, в Gramax есть совместное использование, комментарии и AI-функции (создание и форматирование текста, перевод, поиск по статьям). Отличие — в Git‑first подходе, открытом коде и возможности использовать платформу бесплатно без ограничений.

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

Gramax особенно полезен для:

• Документации по продукту: создание портала с инструкциями, оформленного в корпоративном стиле, с быстрым обновлением и AI-поиском.
• Внутренней проектной документации: база знаний с версиями, Merge Request, поддержкой OpenAPI и технических требований.
• Базы знаний для команд: хранение описаний процессов и систем с удобным поиском и доступом через Git.

Формат работы

Gramax делится на:

• Редактор: web и десктоп на Win/Mac/Linux, можно использовать офлайн.
• Git-хранилище: подключается GitLab, GitHub, Bitbucket и другие, команды Git встроены в интерфейс.
• Портал документации: разворачивается как статический сайт или через Docker.

Для разработчиков есть поддержка диаграмм (Mermaid, Draw.io, PlantUML), подсветка кода (100+ языков), механизм сравнения версий, мультиязычность. Также на портале для чтения можно отображать документацию на разные версии ПО.

Gramax также поддерживает API для передачи данных в сторонние системы и CLI для интеграции в CI/CD, позволяя автоматически собирать документацию в HTML, PDF и DOCX. Есть импорт из Confluence, Notion и Yandex Wiki, экспорт в DOCX и PDF с фирменным стилем.

Цена и условия

• Open Source — бесплатно, без ограничений. Управление доступом на уровне репозиториев.
• Gramax Enterprise Server — 54 000 ₽ за редактора навсегда, первый год обновления бесплатно, далее 40% от лицензии. Управление доступом — по ролям и группам с SSO и корпоративными политиками.

5. KMS Gran

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

Как и в Notion, в KMS Gran есть WYSIWYG-редактор, мобильная версия и AI для работы с текстом. Отличие в том, что на платформе есть модуль «Скриптинг» для построения процессов и гибкая система прав доступа. Подходит командам, которым важно хранить данные локально и быстро строить рабочую рутину.

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

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

Формат работы

KMS Gran работает через web-интерфейс с удобным WYSIWYG-редактором, поддерживающим Markdown, и адаптирован под мобильные устройства. В системе доступен полнотекстовый поиск с морфологией и возможностью получать ответы от AI, а также версионирование с откатом и архивацией статей. Для согласования внутри команды предусмотрена отметка о прочтении. В документы можно вставлять код и схемы через интеграцию с Draw.io, но подключение embed-ссылок из GitHub и Figma не поддерживается.

Платформа поддерживает работу через API для интеграции с внешними системами, хотя CLI в ней не предусмотрен. Можно настроить подключение к Slack, GitHub, CI/CD и Jira через API. Гибкая система управления доступом позволяет задавать роли как на уровне всей системы, так и в отдельных проектах и разделах, а также управлять доступом к разным документам.

Цена и условия

• SaaS: аренда по подписке, ежемесячная оплата за пользователя. Включены базовый функционал, серверные ресурсы и поддержка 9×5, опционально AI-модуль.
• On-Premise: развёртывание у заказчика, лицензия на длительный срок, поддержка AI-модуля и техподдержка.
• AI-модуль доступен как в SaaS, так и On-Premise.

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

Как выбрать платформу для базы знаний

Выбор платформы зависит от ваших задач. Для удобства собрали таблицу с особенностями платформ.

Таким образом:

Если приоритет — работа с документацией как с кодом, версионирование и публикация через Git — ваш выбор Gramax.

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

Если вы ищете корпоративное решение с AI, разграничением прав доступа и встроенными процессами — подойдёт KMS Gran.

Anytype или Obsidian подойдут тем, кто ценит контроль над данными и гибкость кастомизации.

По данным, опубликованным в журнале Nature Human Behaviour, трёхдневные выходные без снижения зарплаты:

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

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

Пандемия как триггер перемен

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

В исследовании участвовали 2896 сотрудников. Им дали 8 недель на перестройку процессов: меньше встреч и рутинных задач, больше смысла. За две недели до старта и через полгода участники заполняли опросники: «Насколько работа вас раздражает?» и «Как вы оцениваете своё психическое здоровье?» Ответы показали заметное улучшение всех метрик.

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

Немного критики

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

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

Вэнь Фань отмечает, что более 90% компаний решили сохранить четырёхдневную рабочую неделю после окончания эксперимента, что свидетельствует об отсутствии опасений по поводу падения прибыли.

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

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

А что вы думаете о четырёхдневной рабочей неделе? Успевали бы справляться со своими задачами? Если вы — менеджер, то поделитесь, как бы вы отнеслись к такому решению в отношении вашей команды?

Спрос на таких специалистов продолжает расти. Средняя зарплата проджект-менеджера в России в 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 мес.

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

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

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

Больше новостей — в нашем тг-канале «Представляешь»

Из почти 10 миллионов резюме, размещённых или обновлённых россиянами, более 3,3 млн — зумеры. В ИТ-сегменте на их долю приходится 30% анкет (512 тысяч). Эти цифры подтверждают: новое поколение активно заходит в отрасль и уверенно заявляет о себе.

Что выбирают зумеры в ИТ

Среди самых популярных направлений — программирование и разработка (26%), дизайн (18%), аналитика и управление проектами (по 13%). Эти роли требуют креативности, цифровой грамотности и способности быстро осваивать новые инструменты — а именно в этом зумеры чувствуют себя уверенно.

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

Запросы молодых специалистов: не только про деньги

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

• 22% зумеров, ищущих работу в ИТ, рассчитывают на зарплату до 80 тысяч рублей в месяц;
• 16% — на 80–160 тысяч;
• только 4% заявляют доход в пределах 160–240 тысяч.
• при этом 56% вовсе не указывают ожидаемую зарплату.

Эксперты hh.ru объясняют это либо недостатком опыта в определении своей «стоимости», либо осторожностью — зумеры не хотят «промахнуться» с ожиданиями. Такая осмотрительность вполне объяснима и типична для начинающих специалистов.

Что действительно важно для зумеров — гибкость и свобода

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

• 23% хотят работать исключительно удалённо;
• 21% ожидают гибкий график;
• 17% интересуются компенсациями (мобильная связь, спорт, обучение);
• 16% рассчитывают на ДМС.

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

Зумеры испытывают интерес к обучению — но при поддержке компании

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

Разбираемся, какие основные задачи закрывает проджект и нужно ли ему знать программирование и уметь кодить. В этом нам поможет Артем Харченков — автор Telegram-канала «IT Инсайты», где он делится мыслями об IT и тимлидстве. Артем руководит командой 40+ человек более 4 лет, управляет департаментами разработки, тестирования, аналитики и DevOps, является спикером TeamLead Conf и участником подкастов и ведущим вебинаров. Был инженером внедрения и Java-программистом.

Какие главные задачи у PM в айти

Менеджер проекта (или Project Manager, PM) — это функциональный руководитель команды, которая работает над определенным проектом. PM отвечает за то, кто и что в команде делает, чтобы достичь поставленных целей.

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

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

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

Нужно ли в принципе проджекту учить программирование или он его должен знать изначально

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

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

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

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

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

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

Как знание кода помогает адекватно оценивать дедлайны

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

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

Про технические штуки: что нужно и не нужно знать

Стоит ли вникать в Git

Git — важный инструмент для командной работы программистов, он уже стал стандартом в современных проектах. Как и в других технических инструментах, PM не обязан знать команды push, fetch или merge и уметь ими пользоваться, но должен иметь общее понимание базовых вещей (например, «ветка», «репозиторий», «merge request», «commit»). Без этих знаний PM не сможет эффективно управлять процессом доставки функций и выпуска релизов, выявлять их узкие места и принимать взвешенные решения по устранению проблем.

Нужно ли знать, чем монолит отличается от микросервисов

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

Должен ли PM знать подходы к разработке, например, CI/CD или TDD

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

Как понимание тестов (типа юнит-тестов) спасает при проверке качества

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

Базы данных — это важно для PM-ов или только для разработчиков

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

Если же проект связан с созданием ПО для работы с базами данных (например, клиента для БД или системы оптимизации SQL-запросов), потребуется гораздо более глубокое знание их принципов работы.

Веб, мобилки, данные — отличается ли набор знаний для PM-а в этих стеках

В общем случае — нет. Различия между этими типами проектов в основном технические, но во всех случаях над достижением цели работает команда с распределёнными ролями. Навыки PM в первую очередь — это способность её мотивировать, выделять приоритеты, проводить эффективные встречи и обеспечивать выполнение задач в срок. Технические инструменты PM (например, таск-трекеры, диаграммы Ганта или покер-планирование) могут различаться, но они не связаны напрямую с инструментами разработки, аналитики или тестирования.

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

Еще недавно я справлялась с этим в 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 Мб. Платный тариф подключается автоматически при добавлении третьего пользователя.

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

Поделитесь в комментариях, какими сервисами для управления проектами пользуетесь:)

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

Альтернативы Google Docs — это не просто «варианты», но и необходимость, если рассматривать возможные риски. И на рынке достаточно решений, которые предлагают больше функций, чем простое редактирование документов. Разберём их более детально, чтобы вы могли понять, какой инструмент подойдёт именно вам.

Обзор популярных альтернатив Google Docs

Notion

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

Проблема только в том, что в сентябре 2024 года Notion заблокировали в России и напрямую им пользоваться не получится.

Что делает хорошо:

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

Недостатки:

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

Для кого:

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

Сколько стоит:

• Для индивидуального использования за Notion платить не нужно, но есть ограничения — пригласить можно до десяти человек, а история изменений будет храниться неделю.
• Plus стоит €9.50 за человека в месяц при оплате за год. Здесь уже больше возможностей, например, безлимитные блоки для команд и синхронизация баз данных со сторонними приложениями. Лимиты значительно выше — 100 гостей и 30 дней истории.
• Business стоит €14 за человека в месяц при оплате за год. Этот тариф подходит для больших команд и включает дополнительные функции: например, приватные пространства и расширенная аналитика. Можно пригласить 250 гостей, а история будет сохраняться 90 дней.
• Есть также тариф Enterprise с ещё большим количеством функций: например, безлимитная история изменений и расширенная поддержка. Цены на такой тариф индивидуальные.

Но так как Notion ушёл из России, оплатить тарифы не получится.

Paper

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

Что делает хорошо:

• Простой интерфейс, легко освоить работу в редакторе. Подходит для ведения заметок, обсуждений и совместного редактирования документов.

Недостатки:

• Нет инструментов для управления проектами или задачами.
• Нельзя организовать базу знаний или работать с большими командами — Paper для этого не предназначен.

Для кого:

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

Сколько стоит:

• Версия Basic с хранилищем 2 Гб и основными функциями бесплатна. Будут доступны основные функции, включая Paper, но пригласить участников для совместной работы получится только в рамках 30-дневного демо-режима. Дальше нужно будет перейти на один из платных тарифов.
• Plus стоит 9,99 $ в месяц при оплате за год, но тариф при этом индивидуальный. Из особенностей — можно синхронизировать устройства, пересылать большие файлы до 50 Гб и есть 30 дней на восстановлений файлов. Объём пространства гораздо больше, чем в базовой версии, — 2 Тб.
• В версии Essentials за 16,58 $ в месяц у вас будет 3 Тб места, а пересылать файлы можно уже по 100 Гб. На восстановление файлов есть 180 дней, а также возможность ставить фирменные знаки на файлы, которыми вы делитесь. Но учитывайте, что этот тариф также рассчитан на индивидуальное пользование.
• Следующий тариф — Business — подходит для командной работы. За каждого члена команды придётся заплатить 15 $ в месяц. Здесь уже есть все привычные функции: разграничение ролей, папки рабочей группы, совместное использование файлов. На всю команду выдаётся 9 Тб.
• Для больших компаний есть тариф Business Plus. За каждого пользователя нужно будет платить 24 $, но лимиты здесь гораздо больше: пересылка файлов до 250 Гб, пространство от 15 Тб, 1 год на восстановление файлов. Есть также сквозное шифрование и расширенное управление ключами.

WorkDrive (Zoho)

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

Что делает хорошо:

• Подходит для компаний, которые используют другие инструменты Zoho (например, Zoho CRM или Zoho Projects). Есть возможность совместного редактирования и хранения документов.
• Есть инструменты для создания простых текстовых документов, таблиц и презентаций — прямо как в Google Docs.

Недостатки:

• Достаточно сложный интерфейс, который чем-то напоминает интерфейс Windows.
• Ограниченная интеграция с инструментами вне экосистемы Zoho — не получится просто перенести данные.

Для кого:

• Бизнесы, которые уже используют Zoho или ищут решение для работы с документами внутри одного экосистемного продукта.

Сколько стоит:

• Бесплатная версия, которая подходит для индивидуального использования, включает 5 Гб места на диске. Можно создавать текстовые документы, таблицы и презентации.
• Тариф STARTER уже подходит для командной работы и стоит 2.50 $ за пользователя. Включает 1 Тб на команду, но если людей больше 10, то на каждого нового выдаётся по 100 Гб.
• Следующий тариф — TEAM — включает уже 3 Тб памяти и стоит 4.50 $ за участника команды. Здесь есть дополнительные возможности, например, функция просмотра активности в файле и брендирование.
• Если вы выберете версию BUSINESS, за каждого пользователя придётся отдать 9 $. Здесь уже 5 Тб, и за каждого участника после 10 человек плюсом выдают 500 Гб. Включает дополнительные возможности, например, кастомный домен и восстановление файлов в течение 120 дней.

Slite

Slite — это инструмент, ориентированный на команды, которым нужно вести заметки и базы знаний.

Что делает хорошо:

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

Недостатки:

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

Для кого:

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

Сколько стоит:

• За базовый тариф Standart придётся отдать 8 $ — это стоимость участия одного пользователя. Главное ограничение этого тарифа — нельзя загружать файлы более 200 Мб. И на каждого пользователя выделено 5 Гб.
• Тариф Premium стоит уже 12.5 $ за человека, но при этом в этой версии нет ограничений на размер файла. Также на каждого пользователя выделяется по 10 Гб. Из главных особенностей — для публичных файлов можно создать собственный домен.
• Стоимость Enterprise-версии рассчитывается индивидуально. В ней можно, например, назначить члену команды возможность только просматривать, но не изменять документы. Также есть расширенная поддержка с приоритетом и отдельным менеджером.

OnlyOffice

В OnlyOffice есть функции, схожие с Google Docs, но с бóльшими возможностями: например, можно конвертировать файл в markdown и HTML.

Что делает хорошо:

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

Недостатки:

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

Для кого:

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

В OnlyOffice есть несколько линеек тарифов, но мы рассмотрим DocSpace, так как эта версия оптимальна для работы с файлами.

Сколько стоит:

• Бесплатная версия STARTUP предоставляет на каждое рабочее пространство по 2 Гб. Документы, таблицы, презентации, формы и другие форматы контента доступны на этом тарифе для всех пользователей. Однако количество администраторов ограничено тремя.
• Тариф BUSINESS стоит €20 за каждого администратора, при этом все администраторы получают по 250 Гб пространства. Количество комнат не ограничено, и поддерживается работа со всеми видами документов, которые есть и в бесплатной версии.
• Enterprise-версия подходит крупным компания и стоит от €6550 за сервер — лицензия действует бессрочно. Из особенностей — систему можно развернуть локально, а файловое хранилище не ограничено.

TEAMLY — когда нужна универсальность

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

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

В чём преимущества:

• Умные таблицы, канбан-доски и база знаний в одном месте.
• AI-ассистент, который помогает работать над текстом и ускоряет поиск.
• Лёгкая миграция из Notion и Confluence.
• Подходит как для небольших, так и для крупных команд.
• Модуль согласования статей, который упрощает работу с договорами.

Для кого:

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

Более того, TEAMLY — это полностью отечественное ПО, а это означает безопасность. Его не заблокируют и к нему не ограничат доступ.

Сколько стоит:

• Бесплатная версия поддерживает до 7 редакторов и 1000 статей, есть и другие ограничения. Но все основные функции включены: умные таблицы, трекер, визуальный редактор, история изменений файлов и статей.
• «Личный тариф» оптимален для индивидуального использования, он стоит от 399 ₽ в месяц. Есть дополнительные функции, например, AI-ассистент и аналитика.
• Тариф «Командная работа» говорит сам за себя. Стоимость пользователя — от 199 ₽ в месяц. Включает всё, что есть в предыдущем тарифе, но уже подходит для общего пользования.
• Тариф «База знаний» подходит, если большинство пользователей только читают документы, а изменяют их редакторы. И за каждого редактора нужно будет заплатить от 479 ₽ в месяц. Остальные участники могут пользоваться платформой бесплатно. Включает всё те же возможности, что и другие платные тарифы.

Как выбрать инструмент для команды

Выбор зависит от ваших задач:

• Если вам нужно просто работать с документами, подойдут Dropbox Paper или OnlyOffice.
• Если нужно больше возможностей для ведения заметок, обратите внимание на Notion или Slite.
• Если нужно комплексное и безопасное решение, TEAMLY станет идеальным выбором. Он не только заменяет Google Docs, но и берёт на себя задачи, которые обычно требуют дополнительных инструментов.

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

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

Я — Даниил Динько, веду свой личный телеграм-канал, где рассказываю о себе, об IT и о Golang, а также являюсь экспертом и спикером в компании Эйч Навыки, TeamLeadом в компании-лидере в международном кибербезе, ex. старшим разработчиком в Ozon Tech. Разбираемся, как четко оценивать задачи, как использовать инструменты для повышения точности планирования и на что обращать внимание в коде и архитектуре, чтобы не допустить скрытых ошибок.

Как подходить к оценке задач на Go (и не только)

1. Понимание бизнес-цели

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

2. Оценка масштаба и сложности

Я анализирую, насколько сложна задача и насколько она совпадает с моей зоной ответственности:

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

• Если в команде есть специалист, который лучше разбирается в этой теме (например, коллега Вася), есть два пути: первый — передать ему задачу с вводными, второй — консультироваться, если Вася занят.

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

3. Классификация задачи

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

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

Производительность и масштабируемость — еще одни важные аспекты, но с ними на старте всё не так просто.

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

4. Нефункциональные требования

• RPS (Requests Per Second) — сколько запросов в секунду выдерживает система?
• Latency — какая допустимая задержка?
• Uptime — уровень доступности в процентах (например, 99.9%).

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

На основе этих данных принимается решение:

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

В 98% случаев мы выбираем MVP. Это нормально. Глубокое продумывание архитектуры — редкость на старте, если только проект не требует стабильности с первых дней.

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

Какие библиотеки и инструменты использовать

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

Популярные инструменты для хайлоад-систем:

Базы данных:

• PostgreSQL — классика для реляционных данных
• Redis/Memcached — быстрые key-value хранилищ
• ClickHouse — аналитическая база для больших объёмов данных
• ScyllaDB, CockroachDB — новые решения, которые набирают популярность благодаря своей производительности и масштабируемости.

Микросервисные архитектуры:

Используется Transactional Outbox — паттерн, позволяющий сохранять атомарность между базой данных и очередью сообщений.

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

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

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

Как это работает:

• В таблице outbox собираются записи для отправки в топик.
• Воркер обрабатывает данные из таблицы и передаёт их в топик.
• Это гарантирует, что состояние базы и очереди сообщений синхронизированы.

Монолит против микросервисов:

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

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

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

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

О производительности и оптимизации

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

Если у вас микросервисная архитектура, начните с анализа трейсов:

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

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

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

Материалов по профилированию на Go — миллион. Если вкратце:

• Используйте встроенные инструменты профилирования Go (pprof, trace).
• Обратите внимание на сборщик мусора (GC) — он может отнимать слишком много времени.
• Проверьте наличие утечек горутин.

Что касается трендовых инструментов, Redis Streams обретает все большую популярность. Redis Streams — это основа для построения своего быстрого in-memory брокера сообщений с кастомными алгоритмами ретраев, крутой интеграцией с key/value Redis, а это возможность сделать пуш в стрим и изменение значения по ключу атомарными. Если говорить более глобально, сейчас постоянно растет количество решений в DevOps, облаках, MlOps. Да и Go постепенно набирает обороты — каждая новая версия языка обычно приносит улучшения в производительности компилятора и стандартной библиотеки.

Какие есть риски при оценки задач

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

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

Почему так происходит? Ответ — подводные камни. Предугадать их заранее сложно, даже теоретически. Это объясняет, почему сеньоры завышают сроки, а мидлы, напротив, обещают сделать всё «завтра», а потом либо перерабатывают, либо просят перенести сроки.

Как минимизировать риски

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

2. Тестируйте новые технологии: не доверяйте только хорошим отзывам — ваш кейс может оказаться нестандартным. Всегда проводите локальные тесты перед внедрением.

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

4. Будьте готовы к изменениям: изменения бизнес-требований — частое явление. Знания команды о продукте могут не совпадать с реальной спецификой.

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

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

6. Что важно описать для багов:

1. Проблему и путь её воспроизведения.
2. Текущее поведение системы.
3. Ожидаемое поведение.
4. Идеи для решения (если они есть).

Как выстраивать командную работу

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

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

Чтобы избежать такого, важно:

• Давать каждому возможность работать в своей зоне ответственности. Это прокачивает навыки и уверенность.
• Периодически поручать задачи вне их основной зоны, чтобы снизить бас-фактор (критическая зависимость от конкретного человека).

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

Об изменениях в управлении Go-проектами

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

Что изменилось в последние пару лет:

1. Проектов на Go становится всё больше. Это касается и хайлоад-компаний, и стартапов.
2. Растёт популярность языка среди разработчиков. Конкуренция за рабочие места увеличивается, зарплаты немного снижаются, хотя они всё ещё остаются одними из самых высоких на рынке бэкенда.
3. Сложность найма. Найти хорошего мидла стало чуть проще, но с сеньорами всё по-прежнему сложно.

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

Советы тимлидам, которые начинают с Go

1. Примите, что найм будет сложным. Если вы не в бигтехе, без хорошего нетворка тяжело быстро нанять нужных специалистов.
2. Балансируйте задачи и созвоны. У разработчиков должно оставаться достаточно времени на фокусную работу. В среднем, это 4 часа в день. Старайтесь не перегружать команду митингами.
3. Снижайте бас-фактор. Следите, чтобы каждый разработчик периодически выполнял задачи вне своей основной зоны ответственности.
4. Не будьте диктатором. Обсуждайте задачи на грумингах, вовлекайте команду в процесс принятия решений. Это повышает их вовлечённость и улучшает качество решений.
5. Давайте ответственность, а не только задачи. Если пытаться тащить всё на себе, можно выгореть.
6. Заставляйте тестировать код локально. Даже если это сложно, практика локального тестирования сильно снижает вероятность багов.
7. Используйте бюджеты на обучение. Развивайте хардовые навыки команды, чтобы повысить их эффективность.

Для новичков в Go

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

1. Найди ментора. Это платный, но удобный вариант для вопросов, не связанных с продуктом.
2. Если вопрос связан с продуктом, обращайся к разработчику, который в нем разбирается.
3. Если он отвечает «ну посмотри в код», используй дебаггер и локальные тесты, чтобы собрать информацию.

Дебаггер — это must-have. Если его нет, тестируй на тестовом или staging-окружении. Если нет и их — проблема не в тебе, а в процессе CI/CD.

Стоит пойти и мягко намекнуть или спросить, а вот как тестировать? Потому что в таком кейсе только на проде тестить, но это совсем ненормально.

Что еще поможет?

• Читай статьи и смотри доклады вечером. Это ускоряет рост.
• Изучай дебаггер и локальные тесты — это твои главные инструменты.
• Участвуй в технических конференциях, чтобы лучше понимать хайлоад и новые подходы.

Несколько полезных ресурсов

YouTube-каналы:

HighLoad Channel

Golang Channel

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

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

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-продуктов.

В большинстве случаев интервью используется в комбинации с другими техниками:

• опрос;
• брейншторм;
• наблюдение;
• визуализация (прототипы, use case);
• документно-ориентированные техники.

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

Лайфхаки для успешного проведения интервью

1. Определите роли в команде

Когда мы говорим про бизнес, состоящий из нескольких представителей (product, owners, ЛПР, участники команды разработки со стороны стейкхолдера), важно «застолбить» зоны ответственности участников.

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

Чтобы ее составить, нужно:

— определить участников проекта;

— расставьте напротив каждого его роль: аналитик, продакт, разработчик, конечный пользователь (если имеется);

— укажите каналы связи, а также ограничения, если они есть (например, продакт доступен с 09:00 до 18:00 по Москве). Уважайте границы каждого человека и держите баланс;

— проставьте приоритеты / «вес людей» на проекте. Они могут выражаться в числовом выражение (от 1 до 5), помечены цветовыми маркерами или сопровождаться описанием. Главное, чтобы эти показатели отражали значимость человека на проекте, а также подсказывал, к кому можно прийти за помощью в той или иной ситуации.

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

2. Установите формат общения

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

— периодичность и длительность встреч;

— состав участников совещаний на основе матрицы ролей;

— формат общения: личный встречи, гугл-миты, диалоги в мессенджерах.

3. Готовьте резюме

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

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

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

— дату проведенной встречи;

— принятые решения;

— дополнительные договоренности («отложенные решения» или задачи, требующие новой информации);

— предварительную дату следующей встречи.

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

4. Задавайте правильные вопросы

Вопросы для интервью должны быть:

А. Понятными

Б. Короткими

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

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

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

5. Налаживайте взаимопонимание

Чтобы выстроить гармонию в общении с заказчиком:

Выявляйте «боли» и опасения клиента

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

Мы предложили сделать авторизацию отдельной вкладкой, не блокирующей основной бизнес-флоу. Клиент остался доволен.

Будьте вовлеченными

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

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

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

Уважайте заказчика

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

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

Демонстрируйте уверенность

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

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

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

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

6. Визуализируйте

Встречи по сбору требований пройдут гораздо эффективнее, если вы сопроводите речь визуализацией: это может быть прототип в Figma, схема, таблица, диаграмма и даже просто структурированный текст (например, список функционала приложения при обсуждении состава MVP). Информация воспринимается легче, когда мы можем на нее посмотреть.

Кейс с проекта Mad Brains: командой обсуждали доработку экрана (не хватало атрибутивного состава), решали, какие данные добавить и как выводить. Встреча была тяжелая, никто не понимал, как точно это должно выглядеть.

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

7. Готовьтесь к интервью

Что это значит?

• Изучайте предметную область, в которой будет разрабатываться проект. Это поможет лучше ориентироваться в потребностях бизнеса и терминологии заказчика.
• Подготовьте свою концепцию проекта. Встречаются клиенты, которые сами не знают, чего хотят: сделайте мне правильно, неправильно не делайте. Поэтому схема с концепцией будущего проекта упростит встречу не только вам, но и заказчику. На своих проектах я обычно накидываю схему в Miro, где фиксирую функциональный состав с комментариями/кратким описанием.
• При наличии документации на проекте очень важно с ней ознакомиться. Когда вы понимаете, о чем пойдет речь, будет гораздо проще составить тот же концепт.
• Составьте список вопросов. Он поможет вести встречу по сценарию «вы рассказывайте, а я послушаю», ведь суть интервью — задать вопросы и получить на них ответы. Плюсом будет создать общий документ с заказчиком, где вы сможете оставлять вопросы, часть из которых разбираются на встречах, а на другую часть заказчик сам сможет отвечать по мере возможности.

8. Определите критерии успеха

Важный момент в работе с бизнес-заказчиками — определить, как именно оценивать успех проекта. Если для разработчиков критериями является DOD (Definition of Done), то для бизнеса более значимыми являются финансовые показатели: увеличение воронки, приток платёжеспособной аудитории, уменьшение зависимостей (от других компаний/внешних систем/наемного персонала), повышение точности аудита.

Определите метрики, которые будете использовать для отслеживания критериев успеха: Яндекс/Google-аналитика, обратная связь от конечных пользователей и т.д.

Проверьте гипотезы перед разработкой: соберите минимальный набор функционала и отслеживайте его применение/востребованность на рынке.

9. Определите скрытые и нефункциональные требования

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

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

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

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

1. Вопросы по нагрузке системы, особенно связанные со спецификой бизнеса и сезонностью: например, если система используется только в будни, тогда можем ли мы позволить себе выкатки/релизы в выходные?
2. Внешние ограничения на нашу систему по типу НПА, локализации (если выходим на международные рынки). Если мы ограничены в ресурсах, то не стоит вкладываться в использовании дорогостоящих технологий отказоустойчивости и безопасности. Для начала можно сделать систему проще, чтобы проверить гипотезу и дать «пощупать продукт».
3. Сроки хранения данных.
4. Нормативно-правовые акты и ограничения.
5. Локализация.
6. Бюджет. Важное уточнение: заказчик не всегда понимает, что поддержка каких-то функций стоит дорого, особенно в случае с безопасностью и отказоустойчивостью. Вы должны проинформировать о рисках и прямом влиянии объема функционала на рост бюджета.
7. Наличие инфраструктуры у заказчика. Если у заказчика уже есть свои мощности, лучше узнать сразу, чтобы не тратить время на ненужную работу. Какие-то данные могут уже быть в сервисах заказчика, что сокращает затраты на базовый функционал и позволяет быстрее собрать то, что нужно.

Продуктовый подход

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

Для того, чтобы избежать неоправданных ожиданий, нужно:

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

Вместо итогов. Помните: в глазах любого бизнес-заказчика его продукт – это самое важное, что вы могли делать в своей жизни. Самое прорывное и уникальное. Так что наберитесь терпения, искренне погружайтесь в предметную область и интересуйтесь деталями. Будьте вежливы, уважительны и открытыми. Эффективных интервью и успешных вам проектов!

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

1. Маленькая моторная лодка
2. Кросскомандные коммуникации
3. Выращивание лидеров
   
4. Личные уроки
   
5. Резюме
   

Маленькая моторная лодка

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

Потом я получил в управление ещё одну команду. В ней изначально было семь человек, но часть разработчиков её покинула, и численность сократилась до трёх. Я посмотрел на бэклог задач, мы кое-что оптимизировали, и сейчас этой команде просто не нужно столько людей, сколько в ней было раньше. С управленческой точки зрения у меня получилась ещё одна «моторная лодка». Теперь их стало две. Руководить ими удавалось, но по мере увеличения количества людей управление начинает занимать пропорционально большее количество времени. Две команды — в два раза больше времени на управление.

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

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

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

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

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

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

Кросскомандные коммуникации

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

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

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

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

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

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

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

Выращивание лидеров

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

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

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

Развитие способности к чёткому целеполаганию — ещё один важный для взращивания хорошего лидера фактор. Человек должен сам понимать, куда растить команду, уметь брать на себя ответственность. Многие ребята думают, что позиция лида — это только «плюшки», раздача поручений и так далее. На самом деле на 80% — это ответственность. Да, у тебя развязаны руки в большей степени, чем у линейного разработчика, но ты отвечаешь за результат. Многие думают, что если они упустят сроки, то просто придут к руководству и скажут: «Ну, у нас не получилось». Люди сильно удивляются, когда ты им говоришь: вы придумали такой план, вы по нему в сроки не умещаетесь, вам надо сейчас сесть и придумать, как успеть. Они думают, что им добавят время, выделят дополнительные ресурсы, если у них не получится. Но в реальности всё выходит иначе.

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

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

У ситуации с рисками есть и обратная сторона, требующая управления. Если начинающие лиды могут чего-то не учесть, то опытные, как ни странно, напротив, иногда усложняют процесс, чтобы учесть даже те риски, вероятность возникновения которых ничтожна. Помня о некоторых случаях из прошлого, они как бы пытаются «подстелить соломку» даже там, где этого делать не нужно. И тут как раз задача управленца заключается в том, чтобы не допустить излишнего усложнения процессов, — потому что сложность обычно означает увеличенные сроки, а нам это не нужно. Не то чтобы тут надо было рисковать и ставить нереалистично короткие сроки, просто мы по опыту знаем, сколько времени нужно заложить на различные нештатные ситуации, когда подтверждаем обязательства по задачам. Например, когда на проекте наши результаты зависят от результатов внешних команд, на которые у нас нет прямых рычагов воздействия, мы «на берегу» закладываем 10–20% времени на случай, если внешние партнеры опоздают с дедлайнами.

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

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

Личные уроки

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

Оглавление

1. Почему важно живое общение
2. Как организовывать созвоны, от групповых до 1-2-1
3. Как готовиться и проводить групповые созвоны
4. Что делать с 1-2-1
5. Как давать обратную связь
6. Как разрешать конфликты
7. Как проводить брейнштормы
8. Как организовать трекер
9. Как организовать общение в течение дня
10. Как в развитии софтов может помочь школа Яндекс Практикума

Почему важно живое общение

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

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

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

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

Как организовывать созвоны, от групповых до 1-2-1

Самые ходовые инструменты: Discord, Zoom, Microsoft.Teams, Google.Meet

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

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

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

В Zoom или Meet есть свои плюсы — можно записать митинги. Но есть и минусы: если кто-то что-то обсуждает, ты не можешь к ним как в офисе подойти и послушать, что они говорят. А Discord как раз это решает.

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

Для начала нужно объяснить, зачем человеку приходить на встречу. Сформируйте и зафиксируйте в описании цель встречи, адженду, тщательно продумайте состав участников: точно ли вам нужна вся команда?

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

Собирайте ожидания от встречи

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

Проводите разминки

Во время созвона для начала нужно расшевелить аудиторию. Представьте, встречается толпа незнакомцев. Чтобы создать комфортную атмосферу, нужно их расслабить, дать познакомиться. Можно начать с неформального вопроса в духе «Как я провел выходные». Так происходит очеловечивание квадратиков на экране. Мы же обычные люди, а не просто скучные специалисты, у нас есть прикольные интересы, которыми можно поделиться. Если в компании есть культура включать камеры, то вообще прекрасно, потому что так гораздо проще устанавливать контакт.

Контролируйте общий план созвона, чтобы не отклоняться от курса

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

В такие моменты важно говорить уверенно: да, было!

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

Поддерживайте динамику созвона с помощью теории вдоха-выдоха

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

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

Проводите шеринг и дебрифинг

Шеринг — это когда мы дали блок информации или провели какую-то активность, а потом спрашиваем, какие у вас чувства, эмоции относительно этого, что думаете?

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

Вернуться в начало

Что делать с 1-2-1

1-2-1 можно проводить регулярно, когда к команде присоединяется новый участник. Нужно отслеживать в каком он состоянии, как адаптируется.

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

Фиксируйте, что обсуждали ранее — лучше обезличенными формулировками

У меня всегда были записки о предыдущей встрече, что я должен сделать на следующей. Я выбирал однозначные обезличенные формулировки, чтобы человек понял и не ушел в защиту. Например, если у меня есть вопросы к перформансу сотрудника, я спрашивал: «Если 100% перформанса, это тебя никто не отвлекает, то какой у тебя сейчас процент от 100%?». Мы выявляли, что не так, и тогда можно было давать обратную связь о том, что мешает человеку достичь результата. То есть я пытался заставить его рефлексировать, дать ответ и возможность помочь ему.

Как давать обратную связь

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

Добавляйте конкретики

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

Сначала учите, а потом лечите и мочите

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

Также есть метод «Пинок»:
P — это позитив,
IN — что-то, что можно доработать,
N — это негатив,
OK — самая важная часть — понял ли человек обратную связь.

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

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

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

Вернуться в начало

Как разрешать конфликты

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

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

Выводите людей на чистоту

Можно сначала попробовать на 1-2-1 собрать фактуру, то есть вообще разобраться, что происходит. Это создаст безопасную, доверительную атмосферу. А дальше уже обязательно честно со всеми поговорить. Это тоже про культуру — мы не замалчиваем проблемы, а умеем открыто их принимать.

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

Как проводить брейнштормы

Самые ходовые инструменты: Miro, Jam, Draw.io, Microsoft Whiteboard, Plant UML

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

Важно ответить на такие вопросы:

• Кто модератор?
• Где проводить брейншторм?
• Как потом транслировать результаты?
• Сколько времени нужно заложить на выступление?
• Как эффективно выстроить коммуникацию?

На брейншторме должна быть «строгая» модерация

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

Важно считать не чистое время, а грязное, то есть учитывать технические и коммуникационные особенности. Например, есть механика, когда в группе из пяти человек высказывается каждый. Модератор планирует по минуте на высказывание, но забывает про переходы между людьми, а ведь они тоже занимают время. В итоге из запланированных 5 минут, группа выйдет за тайминг и получится 6-7. И так в каждой активности формируется снежный ком выхода за тайминг.

Разбивайте большую команду на маленькие группы

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

Мы использовали Miro и аналоги: в Meet есть Jam, Draw.io, но они не такие удобные. Для брейнштормов архитектуры мы готовим UML-диаграммы, их можно редактировать в режиме реального времени. То есть кто-то пишет код, и он появляется на картинке. Потом его можно перекинуть в Notion.

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

Вернуться в начало

Как организовать трекер

Самые ходовые инструменты: Jira, Notion, Redmine, Яндекс.Трекер, ClickUp

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

Выделите у цели четкие стадии работы

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

Кастомизируйте любой инструментарий под свой бизнес-процесс

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

Например, я использовал ClickUp, но там нельзя давать тикет по номеру. В Jira это очень удобно: название проекта, несколько букв и номер. Он легко запоминается, в ClickUp такой штуки нет. Там ID какой-то просто набор букв, и ты никогда в жизни его не запомнишь.

Используйте Kanban-доски

У нас командная работа организована в Notion по Kanban. Есть 4 вертикальные колонки: сделаны, в работе, в плане на спринт и жду ответ. А в горизонтальных колонках указаны ответственные. И, соответственно, они скрываются, открываются как выпадающие списки, то есть мы можем всегда зайти и посмотреть, кто что из нас делает.

Добавляйте фишки в оформление

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

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

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

Вернуться в начало

Как организовать общение в течение дня

Самые ходовые инструменты: Telegram, Mattermost, Slack, Discord

Мемы — это тимбилдинг

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

Заведите отдельный канал для разгрузки

У нас был канал в Discord, где можно было поделиться честным мнением о чем-то. Если ты не хочешь быть токсичным, но при этом хочешь выразить то, что тебе совсем не нравится, ты можешь написать туда: бесит Flask — и слить в канал свои переживания.

Сообщайте коллегам свои рабочие часы

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

Как в развитии софтов может помочь школа Яндекс Практикума

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

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

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

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

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

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

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

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

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

Реклама АНО ДПО «Образовательные технологии Яндекса», LjN8JtbN9

Когда пора наводить порядок?

Когда видите в проекте пункты из списка ниже:

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

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

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

Как избавиться от хаоса в проекте

Найти ответственного

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

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

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

Найти проблемы

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

Те, что вылезают посреди работы. Например, у разработчика закончились задачи — и он не знает, что делать дальше. Или разработчику прислали недостаточно вводных, и он выполнил задачу, «как понял». Я могу выделить несколько маркеров, которые показывают, что в проекте точно есть проблемы (даже если пока их не видно):

• на старте возникает очень много вопросов: «Как должен работать этот продукт?», «Что делает эта фича?», «Кто отвечает за этот проект?» и так далее;
• нет человека, у которого можно всё это спросить (или документации, в которой собраны ответы): Вася знает информацию по этой задаче, Петя по этой, а вот те артефакты, кажется, хранились на диске у Коли три месяца назад;
• нет человека, который собирает и распределяет задачи по сотрудникам;
• текучка кадров и психологическое состояние команды: если люди устали, выгорели, ничего не хотят — это показатель того, что в проекте что-то идёт не так.

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

Показать людям, что проблемы — это проблемы

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

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

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

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

Назначить созвоны

Они необходимы, чтобы команда понимала, что делает, и находила проблемы на раннем этапе.

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

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

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

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

Добавить визуализацию

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

В итоге получилась большая доска с кучей карточек.

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

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

Найти узкие места и дособрать команду

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

Но у нас появился новый проект — такой же неописанный. Мы решили сделать его тренировочным: перестроить процессы и внедрить тестировщика (чтобы он в конце стал полноценным членом команды). И затем уже спокойно декомпозировать новые процессы на старые проекты (по аналогии создать документацию для них).

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

Ребята, когда поработали с тестировщиком, поняли всю его «полезность»: он находил и передавал ошибки, контролировал качество продукта, пока разработчики занимались новым кодом. И продукт выходил с минимальным количеством багов (а если они выпадали, что виноват оказывался уже не разработчик).

Добавить спринты

Два месяца мы поработали в таком режиме, отлаживали процессы. И после ребята сами предложили перейти на спринтовую систему — им самим было интересно попробовать новое.

Мы создали скрам-доску в Jira, добавили столбцы, которые использовали в канбане (на дейликах они оказались очень полезными: мы движемся по приоритету, открывая стори, и пониманием какая из задач на каком этапе и что с ней происходит).

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

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

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

Послушать свою команду

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

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

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

И что получится?

Напомню, что было на старте:

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

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

На текущий момент мы реализовали практически всё, что хотели. Не хватает пока описанных схем бизнес-процессов и CJM. Далее по такому же формату мы опишем старые продукты.

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

Также домен (область проектирования) накладывает дополнительные требования к навыкам и квалификации реуководителя проекта.

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

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

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

Области компетенций менеджера it проектов

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

Технические знания

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

Управление проектами

• Методологии управления проектами: Глубокое знание и опыт применения различных методологий, таких как Agile (включая Scrum, Kanban), Waterfall, Lean и т.д. Это включает умение адаптировать методологии под конкретные условия проекта.
• Планирование и отслеживание: Навыки разработки планов проекта, распределения ресурсов, управления сроками и отслеживания выполнения задач.

Коммуникационные навыки

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

Лидерство и мотивация

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

Аналитические способности

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

Бизнес-ориентированность

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

Финансовая грамотность

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

Риск-менеджмент

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

Знание методов тестирования и качества

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

Законодательные аспекты и безопасность

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

Умение работать с инструментами управления проектами

Программное обеспечение управления проектами: Знание специализированных инструментов, таких как Jira, Trello, MS Project и др.

Специфические технологические знания

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

Способность к обучению и адаптации

• Обучение и саморазвитие: Готовность к постоянному обучению и адаптации к новым требованиям и технологиям в IT-отрасли.

• Планирование и отслеживание: Навыки разработки планов проекта, распределения ресурсов, управления сроками и отслеживания выполнения задач.

• Методологии управления проектами: Глубокое знание и опыт применения различных методологий, таких как Agile (включая Scrum, Kanban), Waterfall, Lean и т.д. Это включает умение адаптировать методологии под конкретные условия проекта.

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

Кажется, много для одного человека?

Но давайте попробуем скомпоновать все что должен уметь и делать менеджер IT-проектов в 2023 году.

Верхнеуровнево можно выделить три основных направления компетенций:

• Менеджмент команды, которая выполняет проект и стекхолдеров, которые ждут результатов проекта.
• Управление проектом, как процессом, для достижения необходимых результатов.
• Учитывать специфику домена Information Technology и нюансы управления таких проектов и команд.

Менеджмент команды

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

Лидерство

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

Межличностные отношения

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

Коммуникации

• Ясность и четкость: Менеджер проектов должен уметь выражать свои мысли и идеи ясно и четко. Хорошая коммуникация помогает избежать недоразумений и ошибок.
• Обратная связь: Предоставление обратной связи членам команды и способность принимать обратную связь от них важно для постоянного совершенствования процессов и достижения результатов.
• Умение слушать: Коммуникация – это не только рассказывание, но и слушание. Менеджер проекта должен активно слушать свою команду, чтобы понимать их потребности и идеи.

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

Проектный менеджмент

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

Управление содержанием проекта

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

Управление сроками проекта

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

Управление стоимостью проекта

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

Контроль качества проекта

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

Управление трудовыми ресурсами проекта

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

Управление проектной отчетностью

• Составление отчетов: Регулярная подготовка отчетов о ходе проекта для заказчиков и заинтересованных сторон.
• Коммуникация с заказчиком: Поддержание прозрачной коммуникации с заказчиком по вопросам хода выполнения проекта.

Управление рисками проекта

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

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

IT Менеджер

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

Образно, можно представить палку о двух концах. На одном ее конце будет классический scrum master – фасилитатор и коуч, который не принимает никаких решений, но у которого сильно развиты soft skills. На другом конце будет классический Team Lead, бывший разработчик, который глубоко погружен в техническую часть, распределяет задачи между командой c круто прокаченными “хардами”.

И, в зависимости от видения компании, обязанности и навыки it project manager может смещаться в ту или иную сторону (а может и хотят иметь всё сразу) и отсюда должны смещаться знания, которыми должен обладать менеджер проектов. Управление проектами именно в IT включает в себя целый комплекс важнейших аспектов, требующих от специалиста глубоких знаний и навыков.

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

Управление жизненным циклом IT-проекта (SDLC – Software Development Life Cycle)

• Анализ и планирование: Менеджер должен уметь проводить анализ требований, определять цели и область применения проекта, а также разрабатывать детальный план выполнения.
• Проектирование: На этом этапе управляющий должен иметь представление о технологических аспектах проекта, включая выбор архитектуры и технологий.
• Разработка и реализация: Понимание процессов разработки, управление командой разработчиков, контроль выполнения задач.
• Тестирование и контроль качества: Управление процессами тестирования продукта, анализ качества и корректировка дефектов.
• Внедрение и поддержка: Знание процедур внедрения разработанного продукта, а также последующей поддержки и обновления.

Инструменты IT-менеджмента

• Выбор и внедрение ПО: Менеджер должен быть способен оценить потребности проекта в инструментах управления, выбрать подходящие и успешно внедрить их. И тут мы говорим и о ПО для самого проектного управления (Jira/MS Project и д.р.), так и непосредственно для разработки (GitHub/Dokker/AWS  и д.р.)
• Обучение команды: Обучение членов команды использованию инструментов, обеспечение поддержки их работы.
• Мониторинг и анализ данных: Способность эффективно анализировать данные, полученные с помощью инструментов, и принимать на их основе решения.

Управление архитектурой проекта

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

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

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

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

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

Алекс Остервальдер, Стефано Мастроджакомо

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

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

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

2. Хорошая стратегия, плохая стратегия. В чем отличие и почему этоважно

Ричард Румельт

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

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

3. Наш айсберг тает

Джон Коттер, Холгер Ратгебер

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

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

4. Финансы для нефинансистов

Людмила Ярухина

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

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

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

Александр Остервальдер

Книга, как понятно из названия, о том, как строятся непобедимые компании. Она продолжает серию книг про создание крепких бизнес-моделей, но именно со стороны сборки компании и процессов.

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

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

Общаться нужно много

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

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

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

Конфликты будут возникать регулярно

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

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

Мой совет: потратить дополнительное время и подробнее изучить кейс. Да, есть правило — занимать рынок быстрее и потом разбираться. Но так велика вероятность выпустить что-то некачественное.

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

Принимать решения придётся вообще постоянно

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

Например, мне нужно было увеличить показатель с 18% на 25+% конверсии из пользователей, которые скачали приложение, в зарегистрированных пользователей в течение 14 дней. Менять что-то серьёзное в рабочей версии продукта было бы сложно. Я выдвинул гипотезу, что можно скрыть некритичную форму для заполнения при регистрации — и показатель вырастет. Так и вышло. Времени и ресурсов на это ушло минимальное количество.

Главное — понимать, как расставить приоритеты. В этом помогают фреймворки. Например, я использую методологию MoSCoW (Must have, Should have, Could have, Won’t have), чтобы определить, что точно должно быть в продукте, что — желательно, и чего не должно быть в принципе.

Как и подстраиваться под новые вводные

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

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

Полностью отдаться процессу не получится

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

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

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

Нужно быть готовым к выгоранию

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

Я был готов к этому, потому что заранее прошёл два курса, прокачивал софт-скилы, навыки продаж. Но на первых порах всё равно ловил себя на мысли, что раздражают встречи и постоянные объяснения ТЗ, которое я достаточно понятно составлял. Тогда банально учился отдыхать и менять обстановку.

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

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

Бюрократия

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

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

Не всегда на рынке есть «идеальные» вакансии

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

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

Итак, что важно знать, прежде чем становиться продактом?

• Нужно много говорить: со своей командой, с другими командами, с заказчиками. Иначе у продукта будут проблемы.
• С бюрократией придётся сталкиваться постоянно: договоры, запросы, заявления и прочее.
• Не факт, что вам сразу удастся взять в работу продукт, который перевернёт рынок.
• Выгорание — это не миф. И нужно будет прокачивать софты и трепетно относиться work-life balance.

Как всё начиналось

Как и у большинства разработчиков ПО, мои обязанности были довольно предсказуемыми. Я получал задачу с фиксированными сроками выполнения или сам решал, когда могу её сделать, согласовав с менеджером. Дальше спокойно писал код, регулярно ходил на дейли, единственные вопросы, которые у меня возникали — как лучше выполнить ТЗ, оптимально реализовать алгоритм или запрос в СУБД. А в должности ведущего разработчика вместе с этим распределял задачи между джунами и мидлами, общался с аналитиками и решал другие вопросы, связанные с реализацией системы для проекта.

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

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

Я учился общаться и искать компромиссы

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

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

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

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

Планировать рабочие встречи и свои задачи

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

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

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

Причём в процессе подготовки часть вопросов обычно решаются сами собой.

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

Оценивать будущий проект и не поддаваться давлению

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

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

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

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

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

Доверять команде и позволять ей выполнять свою работу

Мне пришлось останавливать себя, чтобы не пытаться объяснять разработчикам, как им работать. По привычке я хотел сам придумывать алгоритмы и оптимизировать код. Но нужно было учиться отдавать задачи под ответственность команды и разработчиков. На первых порах это было очень сложно.

Я быстро понял, что невозможно всё делать самому. Да этого и не нужно. Важнее помогать в развитии компетенций каждого члена команды. Необходимо было научиться разбираться в уровнях квалификации разработчиков, чтобы понимать на каком шаге развития они находятся, и давать им подходящие задачи. Ведь даже у разработчиков с одинаковым грейдом может быть разный опыт в конкретной предметной области или технологии. Постепенно я учился (и учусь до сих пор) работать с персоналиями, выявлять сильные и слабые стороны, стимулировать развитие в нужном для проекта направлении.

Работа с людьми стала для меня самым непривычным опытом

Когда я был разработчиком, то с людьми почти не взаимодействовал. Моим основным «коллегой» был компьютер — большую часть рабочего времени я писал код. Дозированного общения с менеджером мне вполне хватало, а с коллегами взаимодействовал в основном по техническим вопросам.

Но на позиции технического менеджера пришлось подключать больше внутренних ресурсов, учиться гасить конфликты (а лучше — не допускать их возгорания), не реагировать остро на ошибки коллег.

Важным навыком оказался процесс обмена обратной связью с ребятами из команды. Большую роль играет способ выражения своих мыслей. Например, если оперировать фактами без явного указания действующего лица, то разговор будет более конструктивным и позитивным.

Не «Ты допустил ошибку», а: «Здесь допущена ошибка» — почувствуйте разницу.

Отдельно пришлось учиться взаимодействовать с эмоционально сложными людьми. Несмотря на то что большинство коллег исключительно позитивные и профессиональные люди, иногда в командах встречались и токсичные ребята, и те, кто считают себя всегда правыми и не воспринимают других подходов, кроме своего. Те, кто не хотят выполнять поставленную задачу, а начинают спорить, чтобы уйти от сути вопроса. Я выработал такой способ общения со сложными собеседниками:

• внимательно слушать;
• игнорировать намёки на грубость и попытки уйти от темы;
• переводить разговор в конструктивное русло.

То есть ставить акцент не та том, кто виноват, а на том, что делать; концентрировать внимание собеседника на общей задаче и способе её решения.

Другой интересный опыт был, когда я подключился к горячему спору разработчиков, забыв про свою роль технического менеджера проекта. Мне это казалось рабочим моментом, в бытность разработчиком таких случалось много. Но когда через пару месяцев я собирал обратную связь от сотрудников, выяснил, что коллегам кажется, будто их ругают, если в спор включается менеджер. Пришлось воспитывать в себе спокойствие, чаще слушать, чем говорить. А если говорить, то выбирать правильную интонацию: спокойную, уверенную и позитивную.

Как мне работается сейчас

За годы работы я уже привык к постоянному общению с людьми, набил руку оценивать проекты, научился планировать время на встречи и личные задачи.

Теперь появляются новые сложности и вызовы — приходится работать в режиме мультитаскинга. К примеру, сейчас стартуют сразу два проекта, а через месяц ещё два. К ним нужно подготовиться: завести Jira, собрать команду, провести вводные встречи. Параллельно идёт пресейл, где я выполняю оценку, считаю бюджет, сроки, ресурсы. Вдобавок приходится следить за текущими проектами: это регулярные встречи, разбор возникающих проблем. Задачи у меня постоянно разнотипные, а значит, есть риск потерять концентрацию, могут вылезать ошибки. Я люблю разнообразие в работе, но иногда наступает «перебор», включается режим бешеной гонки.

Так, я начал ценить не саму задачу, а условия работы над ней. Когда можно выделить пару часов на кейс и спокойно составить ресурсный план или погрузиться в анализ ТЗ. Я понял, что нужно оттачивать новый навык — учиться делегировать задачи младшим менеджерам или ведущим специалистам в проектах.

Я считаю, что принял верное решение, перейдя из разработчиков в технические менеджеры. Меня увлекает выстраивать работу команды перед стартом проекта, планировать задачи, погружаться в новую предметную область. На начальных этапах интересно знакомиться с командой, узнавать людей, организовывать их взаимодействие, наблюдать, как «машина разработки ПО» начинает разгоняться. В финале проекта приятно видеть сплочённую команду, которая выдаёт качественный программный продукт, и осознавать, что в общем успешном результате есть и моя заслуга.

Полученный опыт по преодолению всех трудностей помогает мне не только в работе, но и за её пределами — ведь в жизни тоже нужно уметь общаться и находить общий язык с людьми.

К тому же я вижу для себя и другие области, в которых есть чему поучиться. Например, управление более крупной группой проектов, участие в комплексных высокобюджетных проектах, менторство и наставничество, развитие и укрепление навыков общения и деловых переговоров. Мне интересно осваивать новые области в управлении проектами по разработке ПО, а накопленный опыт разработчика отлично помогает в этом процессе.

Мы начали разработку собственного инструмента для замены сервисов в 2018 году и готовы рассказать, как он сможет организовать рабочее пространство без Atlassian.

Поняли, что пора делать своё

С 2018 года мы выстраивали все бизнес-процессы в компании на базе Jira — и это было непросто.

• Система достаточно сложная для понимания: слишком много кнопок, плоский дизайн, локализация интерфейса сделана не в полном объёме.
• Требовалось докупать плагины, чтобы получить нужный функционал. Например, Диаграммы Ганта, Структура, Учет трудозатрат, плагины автоматизации бизнес-процессов.
• Бизнес-подразделения скептически относились к использованию Jira, потому что считали ее чисто «айтишным» инструментом.

Наша команда начала кастомизировать Jira под внутренние потребности. Приобрели лицензии, дополнительно купили нужные плагины, наняли администраторов на поддержку и разработчиков, которые при необходимости что-то дописывали… А потом убеждали бизнес воспользоваться всем этим для организации процессов.

В итоге это стало выглядеть излишне сложно.

Мы пересмотрели подход к процессам, взвесили все за и против и предложили написать новый инструмент — аналог Jira. Для себя, под свои боли и потребности.

Мы устали от того, что в коктейле стороннего ПО, чужих и самописных плагинов, постоянно что-то идёт не так. Тут не хватает функционала, тут — кнопка не нажимается, тут — интерфейс неудобный.

Прошли все согласования и начали писать

Когда дело касается проектов, я — за основательный, вдумчивый подход. Поэтому перед тем, как начать писать код, мы расписали архитектуру и оформили необходимую документацию.

Дальше выбрали стек:

• Kotlin — для бэка;
• PostgreSQL — для БД;
• TypeScript и React — для фронта;
• MobX в качестве стейт-менеджера.

И приступили к работе.

Систему сделали «среднесервисной». О том, что это такое, и о разработке трекера в целом можно почитать в нашей статье на Хабре (часть 1 и часть 2).

В процессе появилось что-то вроде MVP и система тестирования. Мы брали наш таск-трекер и переводили на него одно из подразделений. Получали обратную связь, анализировали, дорабатывали и масштабировали на новую группу.

Обратная связь была очень позитивной. Ребята стремились помочь: участвовали во всех демо, тестировали систему, давали рекомендации, как сделать продукт лучше и удобнее. Не было негативного настроя: «Снова новый инструмент, снова нужно куда-то переходить».

Основными целями стали: всё быстро, логично, кастомизируемо и «по-русски». То есть ты нажимаешь на кнопку «Перейти на следующую страницу» — и точно знаешь, что перейдешь на следующую страницу.

Проработали визуал и выбрали классное название

Наши разработчики жаловались, что тёмная тема в Jira — особенно если долго сидеть перед монитором — начинает резать глаза. Казалось бы, с этим можно жить. Но мы делаем инструмент, в первую очередь, для себя, поэтому любых проблем в финальной версии хотелось избегать (и так проводим перед экранами 24 часа в сутки).

Поэтому к подбору цветовых схем подошли наиболее внимательно. Разработали мягкую палитру, без кричащих оранжевого и фиолетового. Может быть, она не такая яркая, как традиционные палитры Ростелекома, зато снижает нагрузку на глаза.

Отдельной темой стал нейминг. Мы долго думали, как назвать систему — хотелось подобрать что-то лаконичное и запоминающееся. И остановились на «Яге» — такое точно не забудется. К тому же каждый из нас в душе немного ребенок, и сказочный персонаж, думаю, точно вызовет эмоции.

Была идея назвать продукт «Ритмом» или «Астрой», но это слишком однотипно для рынка. А мы хотели быть заметными.

Добавили фичи

С 2018 года мы дорабатывали функционал Jira, а с 2022 года исследуем то, что делают конкуренты на российском рынке. В итоге выяснили, какие ограничения есть у других продуктов, что мы можем и хотим сделать, чтобы наша система получилась максимально удобной. Расскажу, что получилось.

Простой интерфейс

Голубая мечта любого айтишника — сделать кнопку, которая будет волшебным образом настраивать интерфейс. Мы стремимся к этому: вместе с дизайнерами проанализировали пользовательский путь в других системах типа Picaso, Notion, Jira, ClickUp, постарались выделить и внедрить общую идеологию работы со всеми инструментами, виджетами, задачами, даже элементарными кнопками. И сделать максимум удобных вещей, будь то:

• управление проектами;
• ведение карточек;
• приоритизация задач;
• установка и отслеживание дедлайнов
• написание документации;
• формирование команд.

Кроме того, у нас множество преднастроенных шаблонов для проектов, задач, справочников и прочего. И их можно запустить работу в режиме Quick start. Для сравнения, как это выглядит в Jira:

И у нас:

Важно, что этим может заниматься любой пользователь «Яги», а не только администратор, к которому надо ходить, стоять в очереди, просить завести новое рабочее пространство…

Не надо докупать функционал

Atlassian выпустили отдельный таск-трекер, отдельную систему для написания статей и ещё много всего для организации одного процесса. Мы же постарались не ограничивать пользователей — и сделать инструмент для удобной командной работы, который станет центральным звеном для разных специалистов.

Кроме того, самого востребованного функционала, например, Автоматизации бизнес-процессов, Диаграмм Ганта или Учёта трудозатрат нет в коробочной версии Jira, и приходится докупать плагины. Наша же замена предоставляет такой важный функционал сразу.

Но мы понимаем, что учесть и добавить все в один инструмент невозможно. Поэтому маркетплейс тоже будет, но открытый. То есть каждый пользователь сможет написать и опубликовать собственный плагин — и добавить плюсик к монетизации для своей компании.

И нет лишнего

«Яга» — единая система. Но модульная, потому что не всем командам — или отдельным специалистам — нужна большая система со множеством функций.

Так что можно отдельно использовать, например, модуль управления статьями «Кощей», чтобы публиковать только документы в Wiki-системе.

Или «Ёжку», которая заменяет Trello и Notion.

Например, наш топ-менеджмент пользуется только ей, потому что им нужна не сложная Jira, а простая канбан-доска для ведения статусов по командам и задачам: какие дедлайны, кто и по какой задаче не справляется и так далее.

Кроме того, «Ёжка» — вариант для рядовых пользователей, чтобы отслеживать повседневные дела, планировать поездки, создавать заметки (в том числе коллективные), делать списки и «списки списков».

В перспективе будет отдельный модуль управления тестированием, отдельный модуль для ведения отчётности и аналитики. Ещё будет замена Miro-доски. У нас уже есть готовые продукты, которые осталось просто встроить.

Масштабирование

На российском рынке встречаются облачные решения, которые могут использовать стартапы в 30-40 человек. Завели задачу, расписали, назначили ответственного, сроки — и готово.

Но крупные компании так работать не могут, потому что процессы слишком сложные и требования к информационной безопасности и защите данных на первом месте.

Они обычно используют корпоративные системы управления проектами (это даже звучит страшно — «КСУП»). Такие решения чаще всего реализовываются под конкретного заказчика, его конкретный бизнес-процесс. Они нелегко внедряются, по несколько лет, — и тяжелые сами по себе. А после глубокой кастомизации они, как правило, крайне тяжело отчуждаются и переносятся на другую компанию.

Мы делаем универсальное решение для обеих групп. Оно доступно и разворачивается — так же легко, как и, например, Kaiten. Но также ориентировано на компании, где работают тысячи людей, и может легко масштабироваться.

Преодолеваем стандартные ограничения

При настройке бизнес-процессов в Jira мы часто сталкивались с ограничениями идеологии этой системы — задачи могут быть только двух уровней (задача и подзадача), количество исполнителей на задаче всегда ограничено одним пользователем, проекты настраиваются только администраторами системы.

У нас нет таких ограничений. Можно построить проект с необходимыми уровнями иерархии задач различных типов, как это делает, допустим, Microsoft Project. Для сравнения, вот так это выглядит в Jira:

И вот так у нас:

Решили, что пора делиться

Мы дорабатывали «Ягу» несколько лет и подумали: «Раз всё равно изучаем конкурентов, почему бы и самим не выйти на рынок? Зачем делать систему только для себя?».

Так, появился полноценный большой продукт для компаний. Уровень цен и схема лицензирования будут примерно такими же, как у Jira сейчас. Решение будет ставиться на инфраструктуру заказчика. По нашим оценкам, срок установки, настройка всех баз данных и систем обновления кода будет занимать два с половиной месяца.

Но если кому-то извне уже хочется познакомиться с продуктом, мы можем порекомендовать «Ёжку». Её уже сейчас можно использовать в облачной версии и внутри Ростелеком.

Вряд ли мы с ней пойдем в b2c-сегмент, потому что нагрузка будет чрезмерной. Мы делаем её скорее факультативно, чтобы людям дать возможность облегчить жизнь и работу. Получится такой небольшой дополнительный продукт.

На основе опыта наших команд, работающих в разных областях: от цифровых сервисов для клиентов до высоконагруженных OLTP-систем и ГИСов, мы добавили в наше решение целый ряд важных и полезных инструментов, которые должны быть востребованы рынком.Яга, с одной стороны, инструмент для работы команд с простым и понятным интерфейсом, с шаблонами почти для всех распространённых задач, с возможностью настройки разных модулей для любых потребностей пользователей. С другой, это — ядро, основной интерфейс нашей платформы для работы продуктовых и ИТ-команд в рамках создания ПО на всех этапах жизненного цикла с фокусом на подходы к безопасной разработке и использованию ИИ.

Сегодня буквально из «всех утюгов» и с каждого второго рекламного баннера транслируются призывы вроде: «войди в ИТ», «научиться кодить за неделю – реально» и прочие заманчивые клише. Желающие стать айтишниками принимаются кодить, полагая, что только так можно попасть в самую востребованную профессиональную сферу последних лет. Однако, ИТ – это не только про код, но и про грамотный менеджмент. Директор дивизиона в digital-интеграторе Notamedia Илья Юрасов рассказал, какова роль руководителей в ИТ, какими качествами они должны обладать и почему ценность таких специалистов на рынке ничуть не ниже, чем у разработчиков.

С чего начинается ИТ-менеджмент

Количество и характер менеджерских позиций в организации зависит от ее масштаба. В небольших компаниях менеджер сочетает в себе множество ролей. Это человек, который является единым контактным лицом, «громоотводом» и держателем процессов. Далее, по мере расширения, в компании вводятся известные или собственные методологии управления, соответственно, задачи, роли и обязанности перераспределяются. В ракурсе проектной деятельности, на выходе обычно получается цепочка, где на каждой из позиций может быть сразу несколько специалистов (в зависимости от объема работ и количества проектов).

В Notamedia действует следующая иерархия:

• Руководитель проекта  –  человек, в задачи которого входит планирование, управление, выстраивание взаимоотношений с заказчиком. В целом,  отвечает за успешность проекта.

• Менеджер проекта – больше сконцентрирован на операционной деятельности изнутри. У него есть какая-то определенная задача (обычно большая) или контур, за который он отвечает (например, разработка модулей и их интеграция с внешними системами). В зоне его ответственности – своевременное и качественное исполнение конкретно этой задачи, а также следование указаниям/целям руководителя проекта.

• Администратор проекта – человек, который только хочет войти в менеджмент. Обычно обладает набором необходимых софт-скиллов и выполняет функцию помощника менеджера, который в свою очередь делегирует небольшие операционные задачи, контролирует их выполнение и в процессе обучает.

Как показывает опыт, на стартовых позициях в нашей сфере очень важно быть на драйве, понятно излагать свои мысли (предстоит немало коммуникаций) и четко понимать, что/зачем делается. Более того, эти качества не должны нивелироваться по мере карьерного роста, а только лишь развиваться. Также человек способный стать частью этого мира: учится в нерабочее время, нацелен на самосовершенствование, борется со страхом во всех проявлениях, держит свое слово и умеет признавать ошибки. Это не константы, но точно показатели, подкупающие руководителей, которые «это кино уже смотрели» и знают изнутри.

Что интересует работодателя на собеседовании: софт-скиллы

Я часто прошу подробно рассказать про опыт работы над проектами. С какими ситуациями сталкивался соискатель и как из них выходил. Если рассказ не дает конкретного понимания, то я предлагаю обстоятельства, например:

«Давайте смоделируем ситуацию. Вот у вас, день сдачи этапа контракта. Вы приходите к заказчику, показываете ему макеты, а он говорит, нет, все не так. А у вас все, последний день. Какие ваши действия?»

И вот тут мне интересно, как кандидат будет выходить из положения, используя навыки и знания. Правильного ответа нет, важно понять осознает ли соискатель риски, которые могут быть связаны с такой ситуацией и как он попробует из нее выкрутиться.

И вот у него есть новые вводные, которые он не планировал. Какие он действия совершит для перестройки работы? Что будет делать дальше? Он может просто прийти и сказать команде: «Срочно все делайте». Но, опять же, заказчик сказал, что это надо завтра, а у нас, допустим, день заканчивается. То есть, коллектив надо как-то мотивировать делать это в нерабочее время (достаточно сложный момент).

У руководителя/менеджера проекта лидерские качества должны быть на достаточно высоком уровне, так же, как и эмпатия. В условиях ограничений ему потребуется находить баланс между «надо» и здоровой атмосферой в коллективе. Метод «кнута и пряника» в таком режиме не работает (или работает, но недолго).

Что интересует работодателя на собеседовании: хард-скиллы

Большое преимущество у соискателей, которые работали по каким-то методологиям, вроде PMBOK, PRINCE2 и т.д.. Либо, как минимум, дошли до такого уровня профессионального развития, когда им стало это интересно.

Еще в начале карьеры я просто делал свою работу, как мне сказали ее делать. В определенный момент заинтересовался, почему все именно так, и начал читать PMBOK. Разумеется, не сразу дочитал до конца, так как решил, что описанный там взгляд на управление проектами не применим к нашей сфере и касается больше строительства заводов, проектирования авиалайнеров и прочее, в то время как мы «просто делаем системы и сайты». Только спустя время я пришел к осознанию, что описанная методология ложится на любой проект и соответствует этим правилам.

Взять хотя бы ведение реестра рисков и управление рисками. Это достаточно важный момент, с точки зрения проекта, на который очень многие просто закрывают глаза, потому что не понимают, что это такое. Допустим, у нас есть риск, что инопланетяне захватят Землю. Мы не можем быть точно уверены, что такое не случится, но оценка этого риска будет очень низкая, а его влияние на проект высокое, потому что, скорее всего, будет конец света. В свою очередь, риск того, что техлид уволится – имеет шанс выше, но его влияние будет ниже. В обоих случаях, для каждого риска, помимо оценки, необходимо запланировать, что делать, чтобы не его не допустить или как минимизировать последствия. Например, в случае с увольнением, заранее прописываем: техлида гладить по головке, приносить ему печеньки, не дергать в выходные и т.д. (условно). Это огромный пласт работы, таких рисков может быть бесконечное множество. Понятно, что в реестр рисков попадает только наиболее критичный процент, но, тем не менее, взвешивать их нужно еще до того, как проект стартовал, потому что, если мы поймем, что этот проект слишком рискованный, то, возможно, имеет смысл его не начинать.

Разумеется, проще работать с людьми, которые понимают, с чем могут столкнуться и как себя в той или иной ситуации повести. Не обязательно знать формулы по оценке тех же рисков, но знать о том, как и для чего это работает – важно.

Простые вопросы «на засыпку»

Есть вопрос, который я задаю всем: «Что такое проект?» Необязательно зачитывать справку из Википедии или какой-либо методологии, важно как человек ответит своими словами. Иногда в процессе уточняю, что такое критический путь проекта и подобные базовые термины.

Не менее важно, что человек отвечает, когда его спрашивают о последнем или самом интересном проекте, я особенно внимательно слушаю, как и о чем именно кандидат будет рассказывать. Как показывает практика, бывают два типа рассказов.

Первый рассказ – о конкретном проекте с конкретными задачами, сжатыми сроками и ограниченными ресурсами. В этом случае мне не важно, насколько интересными эти задачи были, важно как именно решались проблемы и какие результаты были по проекту.

Во втором случае, очень часто люди начинают рассказывать, как проектировали условный модуль, что он из себя представлял и т.д. Это явный признак того, что человек излишне погружается в операционную деятельность, в том время, как ему стоит думать критериями успешности проекта с позиции «сверху».

Но если человек начнет рассказывать, что: «У нас был тяжелый заказчик, не хотел с нами работать, но в процессе мы показали качественное и своевременное исполнение задач. Я настоял, чтобы каждую неделю мы проводили совещание на стороне заказчика для того, чтобы докладывать о результатах, спрашивать его мнение», — то я понимаю, что да, сейчас я говорю с управленцем, который был заинтересован в оптимизации процессов и управлял ожиданиями стейкхолдеров.

Red flags: кто не подходит для руководящей позиции в ИТ

Первый сигнал, что человек не подходит для этой работы – проявление открытой или пассивной агрессии еще на этапе собеседования. Иногда я могу специально поправить человека и посмотреть, как он на это отреагирует. Очень распространенная реакция: «А я так и сказал», – что говорит об излишних эмоциях, которые никогда ни к чему хорошему не приводят.

Второй стоп-фактор – неорганизованность мысли. Бывают люди, которые очень долго думают и не могут внятно ответить, а есть наоборот: транслируют поток сознания, где проскакивают правильные мысли, но в этом потоке легко потеряться. Умение четко и локально сформировать свою точку зрения и дать ответ – ценнейший навык на этом рынке (уметь вовремя промолчать – тоже не навредит, скорее наоборот).

Третий – зашоренность. Как мы уже говорили, отлично, если человек работал по РМВОК, но странно, если он не знает основ, к примеру, Agile-методологии и «даже не стал читать». Если тебе не приходилось ее применять, если просто не нравится, стоит все же выяснить, почему полмира по ней работает. Как бы это «мемно» ни звучало, мы – «динамично развивающаяся, современная компания».

Мы должны эволюционировать и расти вместе со сложностью проектов. Если человек, «на входе» – консерватор, есть высокая вероятность, что если даже сейчас он может решить задачу, то через год, скорее всего, настолько отстанет, что, будет просто невозможно работать.

В целом

В ИТ-менеджменте мне в первую очередь видятся люди, которые обладают знаниями, навыками и опытом, достаточными для делегирования им управления проектами. Однако, те, кто считают себя индивидуалистами или не придерживаются философии честных командных взаимоотношений – чаще всего либо не нанимаются, либо надолго не задерживаются. Если же человек обладает искомыми личностными качествами (о которых мы говорили в статье), но ему недостает профессионального опыта – это не является стоп-фактором при принятии на работу начального уровня.

Последний, но не по значению совет – любому руководителю, который хочет расти в этой сфере, полезно читать профессиональную литературу, и, в принципе, читать. Рефлексировать, перекладывать свой опыт на то, что прочитано. Почему делается так, а не иначе? Если бы я знал то, что знаю сейчас, как бы я поступил в ретроспективе? Почему эта ситуация случилась, и что я мог сделать, чтобы этого не допустить тогда и сейчас? Благодаря этому простому «упражнению» специалисты довольно быстро растут. По крайней мере, это помогло мне и ребятам из моей команды.

Примеры полезной профессиональной литературы:Том Демарко и Тимоти Листер. Человеческий фактор. Успешные проекты и команды
Джефф Сазерленд. Scrum. Революционный метод управления проектами
Хэнк Рейнвотер. Как пасти котов
Кен Бланшар. Одноминутный менеджер (серия маленьких книг)
Руководство к своду знаний по управлению проектами (Руководство PMBOK®)

Привет! Меня зовут Даша, HR digital-агентства IBRUSH. Поделюсь своим опытом найма project-менеджера.

Всем знакомо выражение «встречают по одежке, провожают по уму».  И какой бы хороший итог оно не имело, согласитесь, что «встречают по одежке» звучит достаточно несправедливо? Что это за «одежка»? Какой она должна быть? Понравится ли она тем, к кому я иду? А если люди не разглядят ум и мои способности только потому, что я не в той «одежке»?

Эта история хорошо применима к устройству на работу. Вы можете быть бесконечно талантливым человеком, от сотрудничества с которым компания обязательно получит ощутимую пользу, но если у вас будет плохо написано резюме, то с большой вероятностью вас даже не заметят, шанс раскрыть свою эффективность ускользнет, а компания потеряет одного из лучших специалистов.

В этой статье мы пройдемся по пути подбора и поделимся советами, как действовать на каждом из этапов, чтобы пройти собеседование на должность project-менеджера.

Основные обязанности project-менеджера можно понять буквально из названия должности. Он занимается управлением проектами. У нас в агентстве project коммуницирует с клиентом, согласовывает задачи, планирует загрузку команды, ставит задачи группе и следит за их выполнением. Также нам важен технический бэкграунд кандидата. Это сразу +100 к силе.

Что важно для кандидата на позицию project-менеджера

1. Практический опыт в разработке: этапы всех работ, все виды встреч, сроки, бюджеты, документооборот;
2. Опыт работы с большим количеством клиентов и коммуникаций: мессенджеры, почта, трекеры, опыт ведения встреч, умение делать презентации;
3. Опыт проектной и деловой переписки, общая грамотность и инфостиль в письме;
4. Опыт постановки задач группе, налаживание коммуникации с командой и опыт планирования ее загрузки;
5. Технический бэкграунд.

Очень важно умение кандидата брать на себя ответственность за результат команды, быть готовым к огню и его укрощению.

В зависимости от грейдов должности те или иные пункты могут не учитываться, или наоборот раскрываться шире.

Процесс устройства на позицию pm можно сравнить с компьютерной игрой с несколькими уровнями.

Цель игры – дойти до конца, встретиться с боссом и одержать победу – устроиться на работу. В каждом раунде вас будут ждать свои испытания, но в то же  время и подсказки. Игра состоит из трех раундов и обещает быть захватывающей (или нет).

Раунд I: стать заметным

В этом раунде важно позаботиться о качественном составлении резюме:

• Уберите ненужный опыт для позиции PM (ничего зазорного нет в прошлом опыте, но когда у человека слишком много информации в резюме, не относящейся к должности, которую он рассматривает, то становится сложно сфокусироваться и текст становится нечитабельным).
• Обязательно добавьте свои хард и софт скиллы, релевантные должности PM. Поделитесь знанием процессов запуска проекта. Опишите успешные кейсы (если у них ещё есть отзывы с упоминанием вас в качестве менеджера, то это просто прекрасно). Укажите, с какими таск-трекерами работали, знакомые технологические стеки.
• Будьте кратки, пишите по существу. Расскажите о проектах, которые вели и какие задачи решали, кто был в вашей команде и каких результатов вам удалось достичь.
• Обязательно поставьте хорошую фотографию (да, то, как вы выглядите – важно, ни для кого это не секрет).
• Напишите сопроводительное письмо. Здесь можно кратко рассказать, чем заинтересовала вакансия и компания, про свой опыт работы менеджером проектов и указать ваши зарплатные ожидания. В письме можно более подробно показать свои софт и хард скиллы, которые прописаны в требованиях. Например, если у компании стоит в приоритетных услугах – разработка мобильных приложений, то напишите, как участвовали в проекте запуска приложения или знакомы с современными технологическими трендами в мобильной разработке.

Иногда именно сопроводительное письмо может стать суперсилой для ускорения прохождения игры «пройти на должность project-менеджера». Даже если вы в самом резюме по какой-то причине не указали важные для компании компетенции, в сопроводительном письме будет уместно это добавить.

Важно: изучите компанию, в которую откликаетесь. Соответствует ли она тому месту, где вы хотите работать. Узнавайте, исследуйте, смотрите кейсы и главное – определите, стоит ли тратить свое время и время других людей (бывают кейсы, когда кандидаты откликаются для того, чтобы просто откликнуться – так не нужно делать).

Раунд II: очаровать эйчара

Задача II раунда — попасть в III раунд ?

Итак, с вами связался HR, а значит, он будет задавать вопросы по почте и/или мессенджере. К этому нужно быть готовым.

• Пишите грамотно, изъясняйтесь понятным языком и не переусердствуйте с объемом текстовых сообщений. На этом этапе важно показать, что вы приветливый кандидат, с хорошей грамотностью, а также умеете четко и доходчиво отвечать на вопросы (помните, что у HR часто срабатывает фраза в голове «а с клиентом он так же будет общаться?»).
• Задавайте свои вопросы, тем самым покажите свою заинтересованность в данной должности. Если вопросов нет — объясните, что зададите их на собеседовании.
• При согласовании даты и времени собеседования с HR не делайте вид, что вы очень занятой человек и что вам очень сложно найти время на собеседование. Так вы обнулите лояльность к вам, накопленную до этого момента. Если вы очень заняты, просто предложите свои дату и время.
• На предварительном онлайн-собеседовании с HR подключайтесь с хорошим звуком и видео, не относитесь несерьезно даже к 15-минутном диалогу по видеосвязи. Помните, HR — ваш проходной билет дальше.

Важно: На данном этапе у вас есть хорошая возможность выведать информацию о том, как пройти III раунд. Не бойтесь задавать вопросы, которые будут вам полезны. Узнайте, как проходит собеседование с руководителем и как к нему подготовиться.

Раунд III: победить босса

Финальный раунд — встреча с руководителем. Несколько советов:

• Вас должно быть хорошо слышно и видно, без бардака и других людей на заднем фоне.
• Улыбайтесь. Представьтесь, спросите, как настроение у руководителя, проявляйте эмпатию.
• Хорошо говорите и правильно выражайте мысли, старайтесь не нервничать и быть самим собой.
• Расскажите, что успели узнать за это время о компании, и почему хотите работать именно тут.
• Расскажите про свой опыт, про проекты, которые вели, сколько было человек в команде, какие сложности возникали и как справлялись. (тут можно вернуться к пунктам, описанным выше в статье. Используйте их как чек-лист того, что нужно рассказать о себе и своем опыте).
• Не забудьте озвучить свой технический бэкграунд (если его нет, расскажите о своем стремлении прокачивать техническую сторону).

После собеседования поделитесь своей обратной связью с HR, если вспомнили какие-то вопросы – смело пишите, а также уточните сроки по обратной связи.

Два пути

Путь первый: вы победили = пришёл оффер

С чем мы вас поздравляем. Миссия выполнена, вы переходите в другую игру, состоящую из бесконечного числа раундов и постоянной добычей зелья Знания, с боссами и багами на каждом шагу, что делает ее увлекательной и незабываемой.

Второй путь: game over = вам отказали

Если даже вас не взяли, все равно ведите коммуникацию достойно и задавайте вопросы, если они есть. Вы вправе знать, почему вас не взяли (только, наверняка, не все скажут об истинных причинах), поэтому, что бы вам не сказали, поблагодарите и оставьте о себе хорошее впечатление. Возможно, что о вас еще вспомнят.

Хочу отметить, что дело может быть не в вас, к сожалению. Возможно, в игре был баг и ее в принципе невозможно пройти.

За завесой компании и ее процессов может быть множество других причин отказа:  начиная от настроения босса и заканчивая сжатыми сроками на подбор. Не стоит опускать руки и искать причины в себе. Если вы грамотно составили резюме, правильно себя позиционировали и показали хорошим специалистом,  дело не в вас. Примите этот опыт, развивайтесь и идите дальше. На вашем пути обязательно появится именно та компания, в которой вы пройдете все этапы и победите босса.

Если вы хотите пройти игру со мной и победить босса Айбраш, велкам! У меня есть зелье. ?

Теперь вместо них появится Управляющая компания, в которую войдут рядовые менеджеры и топ-менеджеры компании. Команда будет принимать решения, которые связаны с руководством сотрудниками, со стратегическим развитием и развитием ВКонтакте в новых направлениях.

Обновлённый формат управления социальной сетью отражает то, как принимается большинство ключевых решений ВКонтакте. Этот подход доказал свою эффективность и позволит социальной сети продолжить наращивать аудиторию, создавать и улучшать сервисы для пользователей

Как устроена работа в продуктовой команде в Дзене

Мы работаем по принципу SCRUM.

У продактов есть discovery-команды, отвечающие за проработку новых фич: туда входят аналитик, дизайнер и ресёчер. Они генерируют и верифицируют новые гипотезы, которые потом прорабатываются и доставляются ценностью до продукта. Перед полномасштабным запуском новой фичи мы обязательно проводим эксперименты. Это позволяет нам быть максимально уверенными в её эффективности.

Ещё у нас есть демо разработки. Цель этих встреч — показать, как изменился продукт за спринт, что нового и ценного сделали команды, а также повысить прозрачность процессов для наших стейкхолдеров.

Как возникают идеи новых продуктовых фич

Идеи фич обычно появляются из нескольких источников:

• из общения с аудиторией продукта с помощью исследований;
• из аналитики продуктовых метрик;
• из анализа рынка и конкурентного анализа;
• из обращений в поддержку.

А ещё запросы и идеи могут поступать от коллег: например, команда разработки предложила ввести возможность делать подборки в каналах авторов.

Подборки — это фактически папки, в которые можно сгруппировать разные материалы внутри канала одного автора. Они помогают быстрее находить нужные статьи среди обилия контента.

Идея перекликалась с запросами наших пользователей, мы приняли её и воплотили в жизнь. Такие инициативы изнутри возможны благодаря тому, что все участники команд вовлечены в процесс развития продукта и знают, что их мнение услышат.

Как новые фичи проходят верификацию для MVP

Доводим фичу до разработки

Для этого нужно пройти несколько этапов.

1. Продуктовый анализ, который заканчивается процессом продуктового ревью.

Его результатом становится артефакт в виде User Story, где, в частности, есть ответы на следующие важные вопросы:

• есть ли вообще проблема?
• что это за проблема?
• чья это проблема, продакта или пользователей, какого объёма аудитории?
• почему её нужно решать?
• на какие метрики это повлияет?
• как сильно это повлияет на метрики?
• спустя какое время мы ждём положительный эффект?

2. UX, side-by-side исследования и т. д. Порой после них вносятся существенные корректировки в предлагаемые интерфейсы. В исследования отдаются как уже готовые макеты дизайна, так и мокапы и варфреймы (wireframe).

Когда эти этапы успешно завершились, фичу можно передавать в разработку. Не все нововведения доходят до конца, часть отваливается на первом или втором этапе.

После этого фичи отправляются на тестирование, это отдельный большой процесс.

Проводим тестирование

Единого паттерна тестирования новых фич нет. Он отличается в зависимости от изменений, которые мы хотим внедрить.

Если изменения небольшие, то можно провести A/B-тестирование, посмотреть на метрики и сразу реализовать фичу в продакшене.

С помощью А/В мы также можем довольно быстро на большом объёме пользователей понять, что идёт не так не только в продукте, но и в технической реализации, например, найти баги. Некоторые ошибки сложно заметить на тестировании до релиза. Но мы можем протестировать фичу на A/B и уже на следующий день понять, что у нас не так, отключить её и вернуть в доработку.

Если фича меняет продукт в целом, то сначала мы собираем фидбэк от юзеров, на основании которого продумываем решения. Мы структурируем их: почему мы хотим что-то сделать, как это повлияет на пользователей, есть ли у конкурентов такая фича. В итоге остаётся список, который отправляется в разработку.

Иногда мы проводим тестирование прототипов на пользователях. Можем даже спросить у коллег в офисе, нравится ли им нововведение.

Если метрики после А/В-тестирования растут, то мы раскатываем фичу в продукт.

Проверяем метрики в экспериментах

Может случиться так, что метрики не растут — это называется серым экспериментом. Он ни на что не влияет, разницы в улучшении продукта нет. В таких случаях мы ориентируемся на здравый смысл и решаем, полезна ли в целом фича с продуктовой точки зрения, будет ли она развивать продукт в дальнейшем. Здесь подключается экспертиза всей команды. Потому что раскатывать совсем всё нельзя, если это не несёт пользы — ведь фичи всё равно нужно поддерживать, а это затраты для многих команд.

Бывает, что эксперименты стали красными. Значит, какие-то метрики просели. В этом случае мы смотрим на ключевые, которые напрямую влияют на бизнес, они должны быть в порядке. Если всё красное, то, естественно, фичу не выпускаем. Если там серые показатели, просажены какие-то незначительные метрики, то решаем по логике предыдущего примера.

Например, в процессе создания роликов на старте мы тестировали три гипотезы:

1. Если пользователь остановился на просмотре роликов, то при следующем заходе они снова откроются автоматически.
2. Предлагали пользователям на Android, которые чаще остальных смотрят ролики, установить отдельную иконку для них на своём девайсе, чтобы они сразу переходили в ролики.
3. Предлагали пользователю настроить открытие роликов в приложении в первую очередь.

В ходе тестирования мы поняли, что первая гипотеза ломает привычный паттерн потребления Дзена. Пользователь ожидает переход в основной фид, где есть разнообразие форматов и контента, а если мы сразу выдаём ролики, то это плохо влияет на показатели.

Мы остановились на последнем подходе, потому что эта гипотеза показала самые высокие результаты на тестировании. Сейчас пользователю предлагается самому решить, хочет он видеть ролики в первую очередь или нет.

А вот как дизайнеры учили смотреть ролики Дзена

Какие фичи мы внедряли и как

Мы ускоряли загрузку сайта на dzen.ru. Это важная метрика, потому что там загружаются и поиск «Яндекса», и Дзен. Чтобы ускорить сервис, мы делали загрузку страницы двумя чанками — кусками страницы. Сначала мы отдаём пользователю чанк с поиском, потом отдаём второй чанк со страницей. Это позволяет отдавать строку поиска буквально за миллисекунды.

А вот в части Дзена сложная машинерия: нужно учитывать рекомендации для юзера. Это занимает сотни миллисекунд, поэтому мы отдаём его чуть позже. И так как пользователь уже начал получать контент и взаимодействовать со страницей, ожидание для него становится менее тягостным.

Ничего нового мы не придумали: страница как загружалась, так и загружается. Но нам нужно было понять, что это действительно приносит пользу, а по набору продуктовых метрик это сделать сложно. Поэтому мы внедрили множество новых технических метрик, сделали дашборд, в котором есть время загрузки первого байта и второго чанка. Сделали заранее порог, который хотим преодолеть, поставили прямые на графике и начали внедрять изменения.

Скорость загрузки мы увеличиваем не просто так. Мы хотим, чтобы пользователям быстрее отдавался интерфейс, UI–элементы, чтобы он быстрее мог с ним начать взаимодействовать, что-то поискать. Тем самым мы решаем количество вхождений в поиск и уменьшаем количество отказов пользования сервисом.

Такие фичи пользователь не осознаёт. По ним нельзя провести кастдев и спросить, понравилось это людям или нет. По таким фичам мы отслеживаем микс продуктовых и технических метрик. Часть из этих фич не нужно тестировать в А/В, потому что не надо доказывать, что высокая скорость загрузки это хорошо. Это оценка по здравому смыслу.

Бывает, что техническое решение не даёт ощутимого прироста в моменте, но может влиять на продукт спустя время.Люди привыкли, что все приложения работают нативно, ничего не лагает. Если мы сделаем более плавный скролл, то это, скорее всего, не повлияет на метрику прямо сейчас. Но зато у пользователей накопится знание, что Дзен — качественный быстрый продукт.

Как мы работали с негативным фидбэком

Бывало, что MVP продукта успешно прошёл этап проработки, а на выходе в прод на большую аудиторию собрал неоднозначные отзывы. Например, Студия автора. Это личный кабинет, где автор создаёт новые публикации, смотрит за статистикой, управляет постами, комментариями и монетизацией.

У этого продукта есть главная страница. Мы провели UX–исследование, по которому выяснили, что она перегружена, это мешает автору сориентироваться. Тогда мы решили её облегчить: убрали оттуда все блоки, которые были доступны также на вкладках внутри продукта, и оставили только то, чего там не было.

При поэтапном запуске ничего неожиданного не происходило. Но как только мы выкатили его в прод, авторы стали писать, что для них это непривычный интерфейс, и это неудобно.

Тогда мы взяли небольшой тайм-аут, чтобы собрать фидбэк полностью. Мы провели серию глубинных интервью с авторами, которым это не понравилось и которым понравилось. Спросили, что именно не так и что им нужно, постарались понять их насущные потребности. И после перезапустили главную страницу студии: часть нужных авторам блоков вернули, часть реструктуризировали. В результате получили отличную обратную связь и вырастили CSI Студии.

Как на этапе MVP продукта мы понимали, что именно нужно дорабатывать

Дзен — это платформа с большим количеством форматов, настроек и правил, в которых бывает сложно сориентироваться, особенно начинающему автору. Мы довольно быстро это поняли из исследований и метрик, в частности, метрики конверсии в последующую публикацию.

Чтобы снять барьеры входа на платформу для автора, мы запустили MVP онбординга для авторов-новичков. Мы не стали детально прорабатывать дизайн, дали довольно сухую информацию о правилах, которые нужно соблюсти, чтобы получить, например, охваты публикаций.

Мы поняли, что это работает, по метрике конверсии создания пятой публикации, которая выросла в два раза практически сразу. На этапе работы MVP версии онбординга мы смотрели также на то, как авторы взаимодействуют с информацией в онбординге. Так, мы поняли, в каком месте нужно добавить интерактива, а где не хватает информации, и подготовились к полномасштабному запуску фичи.

Также мы запускали онбординг для наших пользователей, который позволил бы лучше понять интересы аудитории и сделать ленту рекомендаций персональнее.

Первый подход вышел не очень успешным, потому что не было фокуса на одной поверхности: мы сделали одинаковый онбординг для приложения, сайта и браузера. Но к ним нужен разный подход. В итоге большую часть наработок пришлось откатить. Мы убрали разные блокирующие сценарии, которые заставляют юзера что-то делать, и оставили только блоки в ленте с интересами.

Во втором подходе мы решили сфокусироваться только на приложении. На сайте онбординга не будет, потому что там больше текущей аудитории, в приложение же мы привлекаем потенциальную. Мы сделали опрос в игровой механике. На старте у пользователя появляется игровой сценарий по типу дейтинговых приложений, в котором он выбирает, что ему нравится и не нравится в формате свайпа.

Ключевая метрика здесь — Retention пользователя на дистанции. Онбординг — это блок для того, чтобы пользоваться приложением. Какое-то количество пользователей уходят из-за него сразу, так как их это не мотивирует.

Онбординг можно считать успешным в нескольких случаях. Если через неделю пользователей с онбордингом будет больше, чем без него. Но даже если их меньше, то можно посмотреть на другую качественную характеристику — время, которое они проводят в приложении. Если оно увеличивается, то онбординг можно считать удачным.

На самом деле не бывает неуспешных MVP. Если что-то не сработало, это калибрует нас и позволяет двигаться дальше к другим идеям.

• грамотно вести проект в рамках стратегии развития компании/организации;
• вести проект в спокойном темпе;
• отслеживать ход работы и статус/качество каждой вехи;
• быстрее завершать проекты;
• сводить к минимуму риски и ограничения;
• управлять рисками, закупками, коммуникациями и интеграцией.

Но не у всех получается выстроить процессы правильно. По данным PMI, из каждого инвестированного миллиарда долларов минимум 12% теряются из-за низкой эффективности выполнения проектов, отсутствия сил и мотивации у команды, сорванных сроков неправильно подобранных приоритетов.

Избежать этого помогает грамотно выбранная методология работы. В данной статье рассмотрим некоторые из них.

MSCW

Впервые этот метод использовали Oracle UK в 1994 году. Он подходит для простых проектов (где есть чёткое понимание от А до Б). Или для очень больших, растянутых по времени и трудозатратам.

Согласные буквы в MSCW обозначают степени приоритетности задач/требований:

• M (или must) – задачи/требования, представляющие основной функционал или ядро задачи. Например, изменение платформы, на которой должно быть представлено решение. Если цель работы — запустить продукт именно на новой платформе, первой задачей будет — установить эту самую платформу.
• S (или should) – задачи/требования второго приоритета, которые ещё обязательны к исполнению и в отсутствии задач категории M становятся главными. Это, например, добавление функционала или обязательных программ для работы.
• C (или could) – задачи/требования, желательные для реализации, но не обязательные для работы продукта. Например, если есть пробный период программы и нужно изучить функционал, чтобы принять решение о её покупке.
• W (или would)– задачи/требования «по возможности», которыми можно пренебречь. Пример такой задачи — изменение цветовой палитры при визуализации приложения.

Преимущество MSCW — в простоте. Задачи делятся только по «критичности», и их не приходится переносить в другой класс с течением времени.

Минусы:

• Субъективность определения приоритетов. Неотъемлемые для заказчика функции могут быть «желательными» для руководителя проекта. И «дополнительными» для разработчика. Так что приоритеты стоит обсудить «на берегу».
• Какой бы, возможно, неприоритетной не стала со временем доработка из первой группы, её придётся доделать. Иначе будет невозможно приступить к задачам следующей категории.

RICE

Эта методология позволяет оценивать каждое требование или задачу по четырём параметрам:

• Reach или охват — количество пользователей/транзакций/задач в измеряемую единицу день, месяц, год;
• Impact или влияние — оценочная субъективная величина влияния на конечного пользователя/потребителя;
• Confidence или достоверность данных при оценке охвата и влияния — количество и структура данных для подтверждения своих выводов;
• Effort или требуемые усилия — оценка усилий для достижения результатов, оценивается в человекомесяцах.

Полученные оценки важно и нужно использовать в системе ранжирования задач/ требований. Это поможет определить, в каком порядке их выполнять, чтобы получить максимальный эффект от реализации. Я рекомендую также перед стартом любого проекта задавать «контрольный вопрос» заказчику: сколько на самом деле стоит проект и есть ли смысл вкладывать в него столько денег.

Обращаю внимание, это входной тест, а не планирование бюджета. Данные будут давать верхнеуровневое представление о стоимости и трудозатратах, и их стоит использовать только в информационных целях.

Основное преимущество в том, что это — универсальная методология. Она позволяет почти объективно оценить приоритетность задач (данные никогда не будут точны на 100%, но об этом поговорим ниже).

Минусы:

• Использование RICE, требует знание основ SMART.
• Модель не учитывает зависимости параметров. Например, очень трудозатратную задачу, важную для многих клиентов, откладывают и отдают предпочтение множеству задач, которые будут иметь то же влияние на клиентов по сумме, но могут оказаться потенциально дешевле;
• При оценке трудозатрат приходится просчитывать риски: поведут ли себя систему некорректно, «выпадут» ли разработчики из процесса, как отреагируют на доработку пользователи и так далее. Все оценки будут субъективными, и это — дополнительная сложность.

SMART

SMART позволяет прикинуть будущий результат и определить чёткие шаги к нему, оценить ресурсы и соответствие стратегии компании, сформулировать задачи с точки зрения бизнес-ценности по шести параметрам:

• Specific — точно определённая;
• Measurable — измеримая;
• Achievable — достижимая;
• Relevant — релевантная;
• Time Bound — ограниченная во времени; оптимальный срок выполнения — три, шесть или 12 месяцев.

Наш мозг очень любит кратковременные цели, и делать контрольные проверки целей проекта в такие сроки — значит держать руку на пульсе. Кроме того, если проект длится слишком долго, так или иначе, происходит «выгорание».

Несколько преимуществ постановки целей с помощью SMART метода:

1. Пять критериев исключают неоднозначные формулировки, помогают оперативно ответить на любые вопросы.
2. Метод не требует времени на изучение.
3. Метод даёт возможность распределять задачи между подразделениями и отдельными сотрудниками.

Основной минус SMART в том, что при постановке цели нельзя точно сказать, достижима она или нет. Мы вводим параметры измеримости, достижимости и релевантности, но они основываются только на наших представлениях о сроках и успешности данной задачи.

Шесть сигм

Содержание проекта удобно подтверждать с помощью «Шести сигм». Эта система включает в себя статистические методы сбора и анализа данных и уникальный подход к организации командной работы. По ней все инициативы, связанные с исправлением или пересмотром бизнес-процессов, нужно вести как проекты.

Процесс выглядит так.

Отбираем первую задачу

Первый проект должен решать важную проблему и гарантировать реальную коммерческую результативность. И быть успешным, краткосрочным и «показательным». Его отбирают по нескольким критериям:

• экономическая целесообразность — максимальный доход/экономия;
• реализуемость — наличие необходимых ресурсов;
• вероятность успеха — субъективный критерий для мотивации команды на успешную реализацию;
• охват — вовлечение в процесс небольшого количества бизнес-процесса;
• безопасность — снижение воздействия на соседние бизнес-процессы;
• стоимость реализации.

В зависимости от первоначальных условий количество и значимость критериев могут меняться.

Детальное обсуждение с руководством организации и согласованность со стратегией компании позволит существенно увеличить вероятность выбора правильного проекта и результативного выполнения задач.

Планирование действий

Это даёт следующие преимущества:

• оценка практической возможности достижения поставленных целей;
• верхнеуровневое выявление потенциальных рисков и неожиданных инцидентов/дефектов;
• обеспечение вводных данных для оценки затрат разработки бюджетов, календарных планов и ресурсов.

Планирование действий разбивается на 6 стадий:

1. Определяем меры, необходимые для реализации проекта/задачи.
2. Оцениваем, сколько времени уйдёт на каждую задачу и подзадачу.
3. Считаем, сколько ресурсов уйдёт на каждую задачу. Сделать это до старта проекта особенно важно.
4. Уточняем показатели, по которым будем оценивать успешность работы.
5. Проверяем сроки и корректируем план.

Многие допускают ошибку и формулируют проблемы в масштабах целой организации. На самом деле, чтобы система работала, стоит выбирать небольшие задачи, которые направлены на совершенствование существующих продуктов/услуг. И которые может выполнить небольшая группа.

Я собрала методологии, которые считаются наиболее успешными. Но признаю, что у каждого руководителя проектов может быть свой взгляд на тему — и любимая методология, которая лучше всего подходит ему/ей и его/её проекту.

Успехов в развитии и совершенствовании навыков. Экспериментируйте для достижения результатов!

Договариваться бывает сложно. И это один из ключевых навыков менеджера. Сделать это проще, если условно разбить участников проекта на несколько типов. Я определил следующие:

• динозавры;
• новаторы;
• хитрецы;
• формалисты;
• тусовщики.

Это собирательные образы, которые я вывел из своего опыта. Советы по общению с разными представителями почерпнуты из известных в комьюнити книг, в том числе одной из самых популярных — «Как пасти котов» Дж. Рейнвотера.

Динозавры

Привычные, проверенные временем практики такие люди считают более эффективными, поэтому склонны отвергать изменения. Договариваться с ними сложно, они, скорее, будут искать отговорки, чем прислушиваться к вашим доводам. Такие люди будут метаться между паникой «я буду не нужен» и агрессией «мой комфорт будет нарушен».

Чаще всего консерваторы в силу стажа имеют вес в организации, поэтому попробуйте услышать их аргументы и после предложите альтернативы, подкрепив наглядными примерами. Если вы даёте человеку высказаться, в ответ он постарается понять и вашу позицию.

Другой вариант более радикальный: действовать только через руководителя, либо ставить жёсткие дедлайны. Например, показываем документ и, если протокол разногласий не прислали к определённому сроку, документ можно считать автоматически подтверждённым. Запомните этот приём, он может пригодиться в разных ситуациях. «Мы показываем вам 5 дней, если нет правок по этой форме, то считается принятым». Иногда он самый действенный.

Новаторы

Противоположная категория. Чаще это молодые ребята, которым интересно развиваться и пробовать всё новое. Для них новая технология — это всегда классная возможность что-то изменить.

Но иногда их предложения могут быть радикальными, внедрить их в большой компании, особенно, не проверив, крайне трудно. Поэтому важно направлять новаторов и учить их самостоятельно оценивать идеи. Когда «новаторы» приходят к вам с очередной затеей, попросите их оценить её плюсы и минусы, подробно расскажите, почему и зачем вы используете нынешние решения, ответьте на все вопросы. И отведите к старшим коллегам, которые с технической позиции объяснят, почему в компании не используют очевидно полезную вещь.

Хитрецы

Такие люди признают, что изменения важны, но не хотят их. Имеют устоявшееся мнение об инструментах и подходах к работе. И если предложите что-то новое — они, скорее всего, деликатно откажутся.

Однако договориться с ними просто. Устройте соревнование — например, пилотный проект или подсчёт экономического эффекта, что-то практическое, где можно наглядно показать плюсы инструмента.

Так, «хитрецы» убедятся на своём примере, что ваши указания не просто дань корпоративным стандартам, а желание принести пользу. И с удовольствием согласятся на ваше предложение. Ведь оно поможет стать эффективнее.

Формалисты

Выделяю в отдельную категорию юристов и безопасников. С ними придётся договариваться в первую очередь, потому что их функция — регуляторная. И если они заблокируют какое-то предложение, реализовать его будет не то что сложно, а просто нельзя.

Здесь руководителю придётся пойти на уступки и принять ограничения, которые накладывают специалисты. Но в то же время выстроить разговор надо так, чтобы они сами подсказали, какими вариантами можно заменить ваше решение или как его адаптировать. Спрашивайте, советуйтесь, ищите компромисс, при котором риски будут допустимыми и с ними можно мириться.

Тусовщики

Это ваши помощники. Они создают вокруг себя комьюнити, сами быстро в него вливаются, налаживают связи со многими отделами и специалистами из разных сфер. С их помощью ваша идея быстрее дойдёт до нужных вам людей. Кроме того, они приносят реальную и живую обратную связь, так как получают её в неформальной обстановке. Узнать таких людей просто: они первыми постят мемы про новую технологию в корпоративных чатах.

Не обязательно становиться им лучшими друзьями, но налаживайте с ними отношения. Интересуйтесь их увлечениями, достижениями, будьте с ними на равных, говорите искренне. Предложите раскрыть свой коммуникативный потенциал: узнайте, вдруг им будет интересно организовать какое-то мероприятие для компании.

Что почитать: «Управление персонажами в IT»

Какие ошибки совершает руководитель ИТ в построении процессов

Наладить общение с коллегами — это полдела. Нужно ещё провести их через весь путь: от постановки цели до финального документирования процесса. По дороге руководитель может совершить ряд ошибок, которые могут аукнуться и повлиять на эффективность проекта. Рассмотрим, что это за ошибки и как их исправлять.

Не объясняет цель

Человека демотивирует бессмысленность. Даже если задача кажется руководителю очевидной, исполнителю она может выглядеть ненужной.

Так что если не объяснить цель, то задачу выполнят либо плохо, либо вообще не сделают.

Что почитать: «Управление проектами с нуля»

Как исправить

Объясняйте выгоды и проблемы задачи. Так вы:

— мотивируете сотрудника,

— убеждаете, что задача важна для компании.

Например, мы должны были подготовить документацию по регуляторным требованиям ЦБ. Иначе компании бы выставили штраф.

Система так устроена, что эту документацию никто не будет применять, она сразу отправится пылиться на полку. Но задачу выполнить надо, и подать эту цель можно так: мы не создаём бесполезный артефакт, а снижаем санкционные риски для компании.

Не уточняет задачу для каждого участника команды

Так, каждый участник будет делать что-то своё. В итоге проект просто не соберётся, а команды поссорятся друг с другом.

Как исправить

Максимально декомпозируйте задачу. Не «сделайте такой-то функционал», а:

— создайте альфу и доведите до тестовой среды;

— раскатите в проде на 100% пользователей;

— убедитесь, что UX-метрики соответствуют стандартам,

— сократите количество багов до минимума.

На каждом из блокирующих этапов зафиксируйте контрольные точки и сверяйте результаты с ответственными за задачу.

Что почитать: «Настольная книга project-менеджера»

Не собирает обратную связь

Если игнорировать проблемы, с которыми сталкивается исполнитель, то либо задачу не получится эффективно решить, либо её выполнение будут саботировать. В итоге и конечный пользователь будет недоволен недоработанным продуктом.

Как исправить

Обратную связь можно собирать централизованно. Для этого мы завели типовые формы обратной связи, куда коллеги пишут, какие функции или артефакты добавить или убрать, какие сложности возникают при согласовании, где не хватает информации.

Не все сотрудники используют такие формы. Например, джуны, которые только разбираются, как устроены процессы, или выгоревшие сотрудники, которым уже всё равно, что будет с проектом. С ними можно проводить адресные беседы один на один.

Но важно не только выслушать информацию, но и принять и обработать запрос. Поэтому мы формируем по обратной связи бэклог, который открыт для всех сотрудников. Так они могут убедиться, что задача не ушла в пустоту, а принята в работу.

Не документирует процессы

Без чётких регламентов границы ответственности размоются, и будет сложно передать работу, если вы уйдёте из компании или возьмёте отпуск.

Или, например, при слиянии или покупке бизнеса нужно оценить, как он работает, для этого вызываются аудиторы. Им важны формальные утверждённые нормативы и артефакты, тонкости разработки им непонятны. Если документации нет, аудиторы решат, что бизнес не контролируется.

Как исправить

Писать документацию под все этапы работы. Она помогает составить:

• инструкции для автоматизации стандартных случаев;
• методики для решения нестандартных кейсов;
• творческие выходы, основанные на общих принципах, которые можно применить в непредсказуемых ситуациях.

Подытожим

В крупных компаниях не обойтись без обобщений и чётких паттернов работы: регламентов, обратной связи, подробной декомпозиции задач, типизации. Поэтому на руководителя в ИТ ложится ответственность: соблюсти баланс между строгими правилами работы и умением найти подход к тем, кто по-разному реагирует на изменения.

1. Состав команды разработки

Состав команды разработки включает в себя разработчиков, тестировщиков, дизайнеров, менеджеров проектов и других специалистов. Важно выбирать специалистов, которые обладают не только техническими знаниями, но и умеют работать в команде, имеют высокую мотивацию и готовность к обучению.

2. Коммуникация

Коммуникация является основополагающим аспектом управления командами разработки в ИТ-проектах. Команды должны иметь доступ к информации, необходимой для выполнения задач, а также взаимодействовать друг с другом для решения проблем и координации работы. Важно установить четкие процессы коммуникации, такие как ежедневные встречи, регулярные отчеты о проделанной работе и совещания, чтобы обеспечить эффективную коммуникацию внутри команды.

3. Лидерство

Успешное управление командами разработки в ИТ-проектах невозможно без хорошего лидерства. Лидер команды должен быть хорошо знаком с процессами разработки и управления проектами, обладать навыками коммуникации и уметь мотивировать команду. Он должен устанавливать ясные цели и обеспечивать команду необходимыми ресурсами для достижения этих целей.

4. Оценка производительности

Необходимо определить критерии оценки производительности, такие как качество кода, сроки выполнения задач и вовлеченность в проект. Оценка производительности позволяет выявлять проблемы в работе команды и принимать меры для улучшения процессов.

5. Процессы (методологии) разработки

Выбор подходящего процесса (методологии) разработки определяет весь ход работ по проекту. Каждый процесс разработки имеет свои преимущества и недостатки, и важно выбрать подходящий процесс разработки, который соответствует требованиям проекта и возможностям команды. Agile, Waterfall, DevOps и Lean – это наиболее популярные процессы разработки, каждый из которых имеет свои уникальные особенности.

   Agile – это гибкий процесс разработки, который позволяет команде быстро реагировать на изменения требований заказчика и изменения внешней среды. Agile основан на принципах коллективной работы, быстрого прототипирования и поэтапной доставке продукта. Agile также предоставляет команде гибкость и автономию в принятии решений, что может повысить уровень мотивации и производительности.

   Waterfall – это традиционный процесс разработки, который состоит из последовательных этапов, начиная с определения требований и заканчивая тестированием и сопровождением продукта. Waterfall предоставляет команде четкие инструкции и процедуры, что может помочь в снижении рисков и повышении качества продукта. Однако, Waterfall может оказаться слишком жестким и неспособным быстро адаптироваться к изменениям, что может снизить гибкость команды.

   DevOps – это процесс разработки, который объединяет разработку и операции в один единый процесс. DevOps предоставляет команде возможность автоматизировать процессы разработки и развертывания, что может повысить скорость доставки продукта и снизить риски. DevOps также предоставляет команде возможность более тесно сотрудничать между собой, что может помочь в снижении ошибок и улучшении качества продукта.

   Lean – это процесс разработки, который сосредоточен на устранении неэффективности и минимизации потерь в процессе разработки. Lean предоставляет команде инструменты для постоянного улучшения процесса разработки и увеличения его эффективности. Lean также предоставляет команде возможность работать с фокусом на потребности заказчика, что может помочь в повышении уровня удовлетворенности заказчика.

Выбор подходящего процесса разработки зависит от ряда факторов, таких как сложность проекта, доступность ресурсов, сроки, бюджет и требования заказчика. Лидер команды должен провести анализ проекта и определить, какой процесс разработки лучше всего подходит для проекта и команды.

6. Управление изменениями

Управление изменениями является неотъемлемой частью управления командами разработки в ИТ-проектах. Изменения в проекте могут происходить в любой момент, и команда должна быть готова к изменениям и уметь быстро адаптироваться к новым условиям. Важно установить процессы для управления изменениями, такие как процедуры изменения, проверки и утверждения изменений, чтобы обеспечить минимальный вред для проекта.

7. Управление рисками

Риски могут возникать в любой момент проекта, и команда должна быть готова к ним и уметь быстро реагировать на них. Важно определить риски, оценить их вероятность и влияние на проект, а также разработать стратегии для управления рисками.

8. Обучение и развитие команды

Команда должна постоянно совершенствоваться и улучшать свои навыки и знания, чтобы соответствовать требованиям проекта. Важно проводить регулярное обучение, тренировки и обмен опытом, чтобы улучшить производительность команды и достичь поставленных целей.

9. Конфликты

Управление командой также включает в себя управление конфликтами. Конфликты могут возникать в любой команде, и руководитель команды должен быть готов к их решению.

Следование эффективным стратегиям и практикам управления командами разработки поможет обеспечить успех проекта и достижение поставленных целей.

Важно помнить, что управление командами разработки – это не одноразовое мероприятие, а постоянный процесс, который требует постоянного внимания и улучшения.

ИТ-актив — это совокупность ресурсов и способностей, от которых зависит деятельность организации.

Структуру ИТ-актива можно условно разделить на материальные и нематериальные элементы. Материальные — это финансы, данные и системы, а нематериальные — процессы, знания, менеджмент и организация. Персонал не входит ни в одну из категорий.

Например, затраты на персонал будут складываться из количества сотрудников и знаний, которыми они обладают. Можно приобрести систему, которую смогут обслуживать 10 джунов, но суммарно они обойдутся компании дешевле, чем найм сеньора с узкой специализацией для разработки системы с аналогичной функциональностью.

Рассмотрим чуть подробнее, из чего может складываться стоимость владения ИТ-активом:

1. Цена лицензий на использование продукта.
2. Стоимость обслуживания сервера, на котором размещена система и ее база данных.
3. Затраты на содержание специалиста по продукту или центра компетенций внутри компании.
4. Затраты на предоставление доступа в интернет.
5. Затраты на оборудование рабочих мест.
6. Затраты на смежные программные продукты, которые обеспечивают работоспособность Comindware Управление закупками.

Для понимания всех аспектов проблемы стоит учесть, что на одном сервере может находиться множество программных решений. Центр компетенций, особенно созданный в рамках ИТ-отдела, часто обслуживает другие системы и процессы. В предложенную модель можно также добавить косвенные затраты на обслуживание помещений, управление смежными процессами и т.д.

Из приведенного примера видно, что оценка актива на основе стоимости отдельного компонента не позволяет рассчитать точные показатели его финансовой эффективности. Адекватно определить стоимость ИТ-актива возможно только на основе модели, которая точно рассчитывает совокупные затраты на владение.

Роль ITAM и ITSM в управлении ИТ-активами

IT Asset Management (ITAM) — это дисциплина, которая помогает рационально проектировать, внедрять и управлять финансовым учетом ИТ-активов предприятия.

Заметим, что ITAM — это не только модель учета имущества, но и набор бизнес-процессов, которые контролируют финансовые потоки. Для полноценного внедрения ITAM компании предстоит скорректировать и свою систему финансового учета, и свою организационную структуру, и свои внутренние регламенты.

Ведущем источником знаний по ITAM, начиная с 2008 года, остается IBPL (IAITAM Best Practice Library) — библиотека лучших практик по управлению ИТ-активами. Она насчитывает около 12 ключевых процессов:

• управление ITAM-программой (Program Management);
• управление закупками (Acquisition Management);
• учет ИТ-активов (Asset Identification);
• коммуникации и обучение (Communication and Education);
• управление соответствием (Compliance Management);
• управление выводом из эксплуатации (Disposal Management);
• управление документацией (Documentation Management);
• управление финансами (Financial Management);
• управление соответствием требованиям законодательства (Legislation Management);
• управление политиками (Policy Management);
• управление проектами (Project Management);
• управление поставщиками (Vendor Management).

Говоря об ITAM, стоит пару слов сказать и об ITSM, поскольку на первый взгляд эти две методологии рассматривают ИТ в качестве самостоятельно актива предприятия, однако между ними есть фундаментальное различие.

• ITSM — это взгляд на ИТ, как на услугу. Взгляд на то, что владелец продукта должен сделать и какими ресурсами обладать, чтобы удовлетворить потребности заказчика.
• ITAM — это взгляд на ИТ, как на единицу имущества предприятия. Взгляд на то, сколько денег компания тратит на информационные технологии и какую прибыль получает взамен?

Внедрение ITAM не направлено на то, чтобы улучшить качество владения технологией, а лишь делает затраты на нее более прозрачными и контролируемыми. Противопоставлять эти методологии нет смысла, они отлично дополняют друг друга.

О роли первичного учета в управлении ИТ-активами

Управление ИТ-активом построено на данных, которые сообщают о его состоянии, качествах, движении и связанных финансовых потоках. Эти данные можно получить только из процессов. Если отвлечься от стандарта IBPL, то можно выделить 4 основных процесса в рамках жизненного цикла актива.

1. Управление закупками
2. Учет и контроль ИТ-актива (идентификация, организация учета, контроль изменений)
3. Управление контрактами
4. Управление финансами

Все эти процессы взаимосвязаны друг с другом, поскольку оперируют одними и теми же данными. Например, если оборудование не поставлено на учет, то отследить его движение даже внутри организации будет невозможно.

Даже самая примитивная система учета позволяет ответить на основные вопросы, которые волнуют финансового директора:

1. Когда было куплено оборудование и было ли куплено вообще?
2. Для чего оно было куплено?
3. Кто за него отвечает?
4. Где найти договоры и техническую документацию по оборудованию?
5. Где оно находится в данный момент времени и в каком состоянии?

Плохая организация системы учета ведет к невозможности управлять ИТ-активом, к частым инвентаризациям, растратам, просроченному SLA и избыточным административным расходам.

Наконец, без учета специфики ИТ-актива невозможно оценить эффективность затрат: рассчитать TCO, ROI, себестоимость сервисов и бизнес-приложений.

Процессы и учетные данные

Мы не будем подробно рассматривать внедрение конкретных учетных моделей, обратим внимание только на несколько аспектов их применения с точки зрения цифровизации.

Модель данных учета ИТ-активов

В процессе закупок компания как бы генерирует поток данных, часть из которых представляют ценность для учета актива. К таким данным относится название продукта, цена лицензий, стоимость доработок на этапе внедрения, сопутствующие расходы на персонал и так далее. Учетная модель ИТ-актива обычно включает несколько категорий данных:

• Финансовые данные: цена покупки, информация о поставщике, стоимость обслуживания.
• Данные по контрактам: условия и положения, гарантийные обязательства, положение об аренде, соглашение о поддержке.
• Инвентаризационные данные: местоположение, владелец, состояние актива.

Часть этой информации доступна в технической документации, часть можно извлечь из финансовой ведомости, часть находится в ведении отдела кадров. Чтобы поставить ИТ-актив на баланс в качестве имущественной едицины, нужно научиться извлекать учетные данные из бизнес-процессов,или же внедрить отдельный процесс постановки актива на учет.

Бизнес-процессы управления ИТ-активами

Контроль финансовых потоков можно осуществлять только в рамках конкретного бизнес-процесса, например, закупок оборудования. С точки зрения управления ИТ-активами важно получить ответы на следующие вопросы:

1. Как определить тип затрат?
2. Кто несет ответственность за финансирование ИТ?
3. Каков порядок такого финансирования?
4. Каким образом будет происходит контроль за финансированием?
5. Откуда брать отчеты о расходовании финансовых средств?
6. Каким образом нужно планировать расходы?
7. Каким образом выстроить работу с бухгалтерией?

Ответом на подобные вопросы должны стать регламенты, которые закрепляют порядок взаимодействия между финансовой службы и другими подразделениями компании в рамках ITAM-инициатив.

Реализация программ управления ИТ-активами

У организации должно быть понимание, какие финансовые потоки она хочет контролировать и какими средствами этого можно добиться. В зависимости от этого можно подобрать решение.

Например, система автоматического продления лицензий. Такие системы помогают отслеживать сроки окончания лицензий и показывают, в каком объеме они используются, нужно ли докупать новые или наоборот сокращать их количество. Если у компании 2-3 программных продукта и в штате работает около 10 человек, то смысла в такой системе нет никакого. Однако если продуктов больше 30, а в штате работает порядка 1000 человек, то продление лицензий уже вызывает трудности.

Под каждую задачу можно разработать свое отдельное решение:

• под закупки дополнительных вычислительных мощностей,
• под сдачу своего оборудование в аренду,
• под приобретения облачных хранилищ,
• под закупку нового оборудования,
• и т.д.

Однако для этого потребуется разработать модель данных и соответствующие бизнес-процессы, которые обеспечат управление активом и контроль над финансовыми потоками. Для этого лучше всего использовать BPMS. Данный класс систем обеспечит внедрение самих процессов и создание управленческой отчетности для руководителей компании.

Наша компания Comindware сталкивалась с реализацией подобных задач и может помочь Вам решить их в Comindware Business Application Platform, на которой можно создавать бизнес-приложения, в том числе для учета ИТ-активов, сдачи в аренду, контроля оплаты и движения актива внутри организации.

Нужны ли вам АБ-тесты

Первый очевидный вопрос, который должен возникнуть – это а нужны ли вам АБ-тесты в принципе? И ответ не обязательно да.

Опять же первый очевидный подход к АБ-тестированию в компании – это никакого АБ-тестирования. Не стоит излишне критиковать этот подход. Именно он подходит небольшим и очень быстро развивающимся компаниям – данных для экспериментов в этом случае мало, а решения нужно принимать быстро. Таким образом, если вы только в начале пути и хотите бежать очень быстро – не замедляйте себя АБ-тестами.

Следующий шаг в развитии компании – улучшения приносят уже меньший эффект, цена ошибки растет – неправильные решения могут привести к ощутимым финансовым потерям. Возможно, пришло время принимать решения на основании данных.

Нужен ли вам аналитик

Если вы приняли решение, что вам нужны АБ-тесты, следующий вопрос, на который вам предстоит ответить – это кто будет оценивать их результат?  Будет ли это человек, который понимает как это работает?

Иногда лучше не проводить никаких АБ-тестов, чем проводить их неправильно – это может создать ложную уверенность в неправильных результатах.

Таким образом, главная рекомендация на этом этапе – наймите аналитика. Пусть это даже не будет выделенная роль, но как и в любой другой области, без понимания процесса, не стоит ожидать результата, вызывающего доверия.

Какие инструменты использовать

У этой статьи нет задачи рекомендовать какие-либо конкретные коробочные решения. Ограничусь лишь тем фактом, что их сейчас много, какие-то решения встроены в системы аналитики для сайтов и приложений, какие-то являются отдельными продуктами. Для небольших компаний использование таких сторонних решений более, чем целесообразно, однако, возвращаясь к прошлому пункту, очень важно понимать как работают все black box решения – нельзя слепо им доверять.

На каком-то этапе (особенно если вы делаете что-то нестандартное) может возникнуть вопрос – не нужно ли сделать свою систему для тестирования, которая будет покрывать все задачи бизнеса. Правильного ответа нет – стоит взвешивать затраты и потенциальную выгоду. При этом не стоит переоценивать сложность построения такой системы – это не космические технологии и вы можете это сделать.

Какие математические подходы применять и как

Ответ на первый вопрос требует больше абзаца текста. Хорошие ответы, можно найти, например, в цикле статей на ab.guru либо, если вы остановились на готовом решении, в документации этого продукта. Вас должно интересовать то какие применяются статистические тесты для определение значимости, как пользователи разбиваются на группы, как определяется размер выборки и срок проведения эксперимента.

Неочевидный теоретический вопрос, ответ на который для вашего случая вы не найдете нигде, и должны ответить на него сами – с каким p value принимать эксперименты? Порог на уровне 0.05 – не более, чем дань традиции.

Низкие значения порога p-value ведут к хорошей точности решений, таким образом, вредные изменения с наибольшей вероятностью не попадут в продакшн, однако часть изменений, которые объективно полезны, не будут запущены из-за того, что не смогли достигнуть порога значимости.

Выбор уровня значимости – важное решение, которое основывается на стратегии развития продукта и аппетита к риску.

Вместо заключения

АБ-тесты – это большая сила и большая ответственность. Культура принятия решений на основании данных в компании – это скорее хорошо, но

важно помнить, что АБ-тесты – это инструмент оптимизации, а не путь к прорывным решениям. Важно не попасть в ловушку оптимизации метрик, которые проще измерять в моменте, и всегда помнить о долгосрочных приоритетах.

1. Выявите любителей поработать на праздниках

Начните с уточнения: какие отделы и сотрудники планируют работать на каникулах. Будут ли они приходить в офис или предполагается удаленная работа, какие приложения и ИТ-системы они планируют использовать? Это отправная точка: нужно представлять, кто и в каком объеме будет нагружать инфраструктуру компании в период относительного затишья.

2. Скоординируйте планы служб эксплуатации со своими

Обязательно уточните у служб, обеспечивающих работоспособность офиса и корпоративной компьютерной сети, не планируют ли они какие-либо технические работы на период праздников. Далеко не всегда оповещение о запланированных работах дойдут до каждой компании в БЦ, скорее всего оповестят только руководство бизнес-центра (например, так любит делать «Мосэнергосбыт»).

Это довольно распространенный сценарий: службы эксплуатации или сервис-провайдеры могут решить, что каникулы — оптимальное время для проведения различных профилактических работ. Они могут затрагивать системы доступа СКУД, электросети, доступ в интернет, системы охлаждения (если у вас своя серверная в офисе) и т.д.

В случае, если ваши планы поработать и намерения подрядных организаций совпадут во времени и пространстве — полноценной работы не получится. Сотрудники не попадут в офис, удаленный доступ к ИТ-систем компании организовать тоже не получится.

Здесь же стоит добавить несколько слов о ЦОДах. Если вы пользуетесь услугами дата-центра или облачного провайдера — убедитесь, что у них не запланирован downtime оборудования (апгрейд, профилактические работы), и все параметры предоставляемых услуг будут в указанный период соответствовать подписанному SLA.

3. Внимание: меняем пароль

В компаниях распространена ситуация, когда сотрудники используют для доступа к общим цифровым ресурсам одну и ту же пару логин/пароль. Это не хорошо и не плохо — это данность. В обязательном порядке необходимо проводить обновление паролей — хотя бы раз в три месяца (обычно закреплено в политиках безопасности).

Можно напомнить сотрудникам проверить почту или оповещения системы, чтобы они заранее сменили пароль, если срок его действия истекает в выходные.

4. Напоминаем, вы работаете!

Обязательно внесите праздничные дни в график дежурств. Не забудьте напомнить дежурным инженерам, ответственным за ИТ-инфраструктуру в компании, о предстоящих дежурствах. Если работа в праздники предполагается, и на ИТ-системы возлагаются определенные ожидания — следует обеспечить эти планы техподдержкой.

Сотрудники могут по инерции решить, что на время каникул от них никакой работы не требуется, и если не предупредить их об обратном, вы рискуете оставить критически важные участки ИТ-ландшафта неприкрытыми.

Также убедитесь, что технические специалисты в праздничные дни обеспечены всем необходимым для работы (доступ к различным инструментам управления, ИТ-системам и ресурсам компании).

5. Оповещайте об отсутствии

Донесите до сотрудников технических служб необходимость обязательного оповещения о своем предполагаемом отсутствии в праздники.

Если кто-то из ключевых для поддержки ИТ-систем сотрудников планирует на праздниках оставаться максимально недоступным, им следует оповестить об этом заранее и активировать на рабочем мэйле автоматический ответ с указанием дат отсутствия и коллег, к которым следует обратиться за решением на это время.

6. Проконтролируйте безопасность удаленной работы

Чисто технический, но довольно важный момент: следует убедиться, что удалённый доступ для сотрудников к ИТ-ресурсам компании, во-первых, исправен, а, во-вторых, все знают, как им воспользоваться.

Вне зависимости от того планирует сотрудник обращаться к базам данных или корпоративным системам учета, или ему требуется удаленный рабочий стол (RDP), эти условия должны выполняться в обязательном порядке.

ИБ-составляющую сегодня трудно переоценить, поэтому защищенный доступ должен присутствовать в числе основных мер обеспечения работы — в праздники это особенно важно, поскольку фокус внимания сотрудников в этот период может ослабевать, а злоумышленники это знают.

7. Мониторинг ресурсов — для подстраховки

Если у вас есть инструменты ИТ-мониторинга, стоит воспользоваться ими для проверки серверов с критически важными ИТ-системами на предмет достаточности вычислительных ресурсов: объема памяти, дискового пространства, ресурсов CPU и так далее.

Если же мониторинга нет, придется провести такую проверку вручную. Ее результаты помогут установить участки для необходимого масштабирования мощностей.

8. Укрепите слабые звенья

Если вы знаете, что какое-то приложение или ИТ-сервис страдают утечками памяти или ведут себя нестабильно, перезагрузите их заранее, выполнив необходимые меры до праздников.

Это нормальная ситуация: какие-то элементы ИТ-ландшафта периодически сбоят и могут подвисать. Такие проблемные участки необходимо знать, уметь их выявлять и иметь отработанный алгоритм отработки возможных сбоев — лучше всего проводить такую профилактику в автоматическом режиме и перезагружать по расписанию. Пока вендор ответить на тикет и решит вашу проблему, пройдет время.

9. Проверяем бэкап

Никогда не будет лишним проверить статус бэкапов для всех сервисов и систем, а также проконтролировать наличие свободного места для новых резервных копий. Оптимальным же вариантом будет проверка работоспособности бэкапа в автоматическом режиме или если у вашей системы резервного копирования нет такой опции, то возможность восстановления из бэкапа стоит проверить вручную — восстановив сервис в тестовой среде.

10. Лицензии в порядке?

Полезна проверка ИТ-активов на предмет истекающих сроков действия лицензий в период праздников. Будет обидно, если ключевой для бизнеса ИТ-инструмент или сервис остановит работу не из-за сбоя или ошибки админа, а по объективной причине просроченной лицензии. Заниматься ее продлением на праздниках, скорее всего, никто не будет.

С наступающим — спокойных каникул без сбоев и простоев!

В данной статье разберёмся в базовых задачах такого сотрудника и определим, что ему нужно знать и уметь.

1. Чем занимается менеджер проектов
2. Что нужно уметь
3. Как стать менеджером IT-проектов
4. Куда расти менеджеру IT-проектов
5. Что ещё нужно знать про менеджмент IT-проектов
6. Что почитать по теме

Чем занимается менеджер проектов

От сферы к сфере, от компании к компании его роли, обязанности, навыки и карьерный трек разнятся. Но, мы можем выделить функционал, c которым сталкивается любой специалист:

• Планирование сроков. Менеджер собирает и адаптирует требования заказчика к проекту, по возможности привлекая для этого бизнес-аналитика и/или архитектора (они формулируют для коллег из системного анализа, разработки и тестирования требования и дают оценку систем, которые будут эти самые требования адаптировать). И затем прогнозирует срок окончания проекта в рамках ограничений, которые диктуют заказчик и объём имеющихся ресурсов.
• Координация проектов. Менеджеру стоит вникать во всё, что касается проекта — иначе он может не успеть принять меры для решения сложного кейса. Например, организовать покупку необходимого софта и железа, согласовать их внедрение в определённые сроки, проверить, вместе с командой и администраторами систем, что всё корректно настроено и отвечает указанным требованиям. Ещё ему нужно отслеживать созависимые проекты: быть на связи с руководителями других проектов, общаться с заказчиками (они бывают внутренними, и внешними, если привлекается сторонняя компания), вести отчётность по проектам для ИТ-партнёра.
• Отслеживание темпов работы. Менеджер отвечает за то, чтобы команда выполняла все поручения вовремя или — что более реалистично — с согласованным отставанием. Для этого чаще всего используются инструменты:Jira — чтобы проверять количество задач в работе и смотреть, на каком этапе или на какой задаче находится команда и что уже реализовано.MS Project — чтобы отслеживать, как сместился изначальный график проекта, какие задачи появились и в какие сроки их планируется решить, сколько сотрудников привлечь к их реализации — и на какой срок.Confluence — чтобы пополнять базу протоколов по проекту и отслеживать с командой ежедневный статус задач (небольших, которые не отслеживаются в Jira и являются частями задач в MS Project).Встречи — чтобы поддерживать темп работы и подчеркивать команде важность соблюдения сроков, оперативно отвечать на вопросы, раскрывать задачи в Jira и сам проект — через консультации с системами. Например, daily — для отслеживания текущих статусов; UАT-встречи (альфа- и бета-тестирование) — для принятия решений о внедрении с конечными пользователями; ретро — для получения обратной связи от команды и формулирования обязательных критериев по разным этапам схожих проектов.
• Тушение «пожаров». Желательно, здесь и сейчас.
• Ведение документации. Нужно собирать все возможные данные о проекте. Я стараюсь сохранять даже переписки с информацией про обсуждаемые и реализуемые требования. В них могут быть важные детали, например, первоначальные требования клиента. Также приходится писать отчёты для заказчиков и сотрудников на все происходящие изменения — которые могут стать блокирующими в рамках дня. Это порой отвлекает от работы с командой и невольно можно  упустить мелкие детали проекта.
• Работа с рисками. Менеджер пытается предугадать все события, которые могут помешать реализации проекта, и заранее предполагает возможные способы их разрешения. Такими событиями могут быть: болезни сотрудников, поломка или нехватка оборудования, повышение цен на софт, отключение интернета, увольнение, нерелевантность выполнения проекта в текущих экономических условиях и так далее.
• Мониторинг бюджета. Критически важно отслеживать, на какие статьи расходов и с каким временным лагом расходуются средства. И грамотно распределять оставшуюся сумму после завершения работ.

Обычно управление проектом: встречи, планирование задач аналитиков, разработчиков и тестировщиков, мониторинг — занимает около 80% рабочего времени. Ещё примерно по 10% уходит на написание отчётов и письма. По моему опыту, менеджеры обычно ведут от двух до четырёх проектов одновременно.

Как оценивать работу менеджера проектов

Универсальных метрик для оценки работы несколько:

• управление стоимостью;
• управление сроками;
• управление рисками;
• управление трудовыми ресурсами.

Однако если появляется специфическая сфера ведения проекта, то могут появиться различные профильные управления. Также система оценки в разных компаниях и организациях может быть разной.

В рамках Проектного офиса компании мы ориентируемся на:

• управление интеграцией проекта;
• управление содержанием проекта;
• управление стоимостью проекта;
• управление сроками проекта;
• управление ресурсами проекта;
• управление закупками и рисками;
• контроль отчётности и качества проекта.

Если проект выполнен в срок — несмотря на всевозможные задержки и проблемы — количество багов минимальное, а у заказчика положительные отзывы, и команде так понравилось работать вместе, что она тем же составом перешла на другой схожий проект — менеджер справился хорошо.

Что нужно знать и уметь

Начну с soft skills:

• Адаптация. Менеджер может параллельно ставить разработчику одну задачу, самостоятельно вести вторую, планировать будущие проекты, оценивать для отчётности уже сделанные и так далее. Без умения быстро адаптироваться к изменениям в рамках рабочего дня и тем более недели такая работа будет казаться постоянным хаосом.
• Стрессоустойчивость. Нести ответственность за всё, что происходит в проекте — это стресс. И без умения с ним справляться упадут и самочувствие, и производительность. К тому же менеджер проектов много общается с людьми, и нужно уметь сохранять нейтралитет и спокойно решать конфликты — если до них доходит.
• Умение принимать решения. Решений — от мелких до критично влияющих на проект — приходится принимать очень много. И не всегда они даются легко, потому что вводные могут открываться только постфактум, например, на этапе разработки. Чаще всего так происходит с софтом: поначалу кажется, что всё правильно настроено. Но на стадии тестирования то, что мы закладывали как крутую работающую фичу, не работает.
• Умение вести беседу и находить подход к разным людям. Нужно грамотно доносить мысли, уметь задавать правильные вопросы, вычленять из ответа главное. А также следить за тем, как доносить информацию про статус работы заказчику, исполнителям и/или руководству. Важно: ваши сленговые обозначения не обязательно должны быть понятны всем.
• Знание иностранного языка. С ним проще работать: общаться с разными специалистами и заказчиками, искать информацию, читать документацию.

Из hard skills нужны:

• Умение работать с сервисами: с Microsoft Office, продуктами Adobe, Bitrix 24, вышеупомянутыми Jira, MS Project, Confluence. Это минимум, и, безусловно, список можно дополнить.
• Знание методологий управления проектами: Agile, Waterfall, гибридного подхода — и отдельных методов, например, Scrum, Kanban и так далее. И умение грамотно адаптировать их под свой проект, если нет единой методологии в компании.
• Технический бэкграунд. На мой взгляд, лучшие проектные менеджеры — разработчики или тестировщики. Они говорят с командой на одном языке, шире смотрят на задачи, лучше понимают, сколько времени нужно для выполнения той или иной работы и насколько реально воплотить идеи заказчика с точки зрения технического/функционального обращения. А ещё могут самостоятельно посмотреть логи, написать или протестировать код, если есть необходимость.

Как стать менеджером IT-проектов

Почитайте PMBoK

PMBoK — это свод знаний по управлению проектами: описание подходов к работе, фокусы внимания, рекомендации. Он помогает разобраться, что за чем идёт, что нужно собрать у тех же системных аналитиков и сделать для разработки и поддержки проекта после выхода.

К тому же многие компании стали запрашивать международный сертификат на знание PMBoK. Первый уровень — от нуля до трёх лет — может сдать почти любой специалист со знанием английского языка.

Обратите внимание на зарубежные курсы

В вузах нет специальных программ, которые учат на руководителей IT-проектов. Факультеты менеджмента дают базовые знания без привязки к сфере. К тому же управление проектами в университете ― всё равно защищённая среда, где риски закладывают либо сами студенты, либо преподаватели. И внезапно перегоревшей лампочки, глобальной перегрузки сети или цунами не будет.

А на онлайн-платформах — по крайней мере, тех, что я видела — берут информацию из зарубежных программ.

Изучите сферу, в которую идёте

Мне бы хотелось видеть у потенциального менеджера IT-проектов опыт работы в похожей сфере. Чтобы человек знал, как выстроены процессы, как провести оценку проекта, как спланировать сроки и бюджет, понимал жизненный цикл проекта: что нельзя перейти с системного анализа сразу на тестирование или начать с разработки. И теоретически отличал методы, Kanban от Scrum, и методологии управления, Waterfall от Agile. Иначе он может взяться за дорогой или вовсе никому не нужный проект и только потратит время как своё, так и компании.

В моей практике был случай, когда команда хотела взяться за проект стоимостью в 50 миллионов — без внятной идеи. Это когда есть команда и есть деньги, но кого взять в заказчики и что реализовать — непонятно. Это самый большой страх менеджера проектов.

Соберите портфолио и описывайте проекты в подробностях

Портфолио — это здорово, всегда будет о чём рассказать на собеседовании. В него могут входить макеты, сделанные на этапе планирования, презентации, выборки из Figma, скриншоты «до и после реализации проекта». Например, когда я приходила на позицию руководителя проектов, то показывала, как мы с командой сделали новую страницу для интеграции с международной организацией.

Иногда визуальные материалы принести не получается — и я смотрю на то, как человек рассказывает о проектах. Спрашиваю, сколько длилась разработка, привлекали ли кого-то из внешних вендоров или делали только своей командой, из скольких человек она состояла, сколько времени потребовалось для окончания проекта.

По таким подробностям легко понять, честен ли соискатель, потому что вряд ли получится найти в поисковике информацию о том, за сколько дней можно реализовать проект по внедрению одной кнопки.

Ответственно подойдите к выполнению тестового

«Напишите техническое задание для реализации проекта по созданию новой платформы. С чего вы начнёте? К чему приступите? Чем закончите?». По шагам, которые опишет соискатель, можно увидеть, насколько хорошо он разбирается в управлении проектами в целом и в IT-сфере в частности.

Приведу пример. Нужно реализовать проект стоимостью 18 миллионов рублей. В команде есть один аналитик и один архитектор. Остальные ресурсы должны быть привлечены к задаче как можно быстрее. Можно ли выполнить задачу за полгода?

Человек, который разбирается в теме, задаст уточняющие вопросы к такому тестовому. Где команда (аналитик и архитектор — это не команда, а люди, которые грамотно ставят бизнес-требования)? Какой проект реализуем (может быть, мы просто меняем цвет рамок на сайте)? А только потом даст ответ.

Также на собеседовании надо говорить о достижениях — но не преувеличивать.

Куда расти менеджеру IT-проектов

Ведущий, главный, старший

Первая ступень в карьере — стажёр проектного офиса. После прохождения стажировки можно вырасти до администратора проектов. И дальше, за годы практики, перейти на роль руководителя проектов. В исключительных случаях это получается сделать за 1–2 года.

Следующая ступень, если мы говорим о банковской сфере, — старший менеджер. На этой должности можно взять под управление большее количество проектов и привлечь администратора для курирования.

При росте до старшего менеджера меняется качество проектов: сначала это может быть изменение цвета кнопки. Затем — более значимые бизнес-задачи. И после — регуляторные проекты, то есть связанные с исполнением требований законодательных органов, и стратегические — направленные на реализацию той или иной стратегии компании.

IT-партнёр и директор

Спустя три-четыре года менеджер IT-проектов переходит на позицию либо продакт-менеджера, либо IT-партнёра, то есть руководителя направления, связанного, например, с подключением к каким-то внешним сервисам. А после 3–5 лет — на должность руководителя подразделения.

Наконец, сотрудник может вырасти до директора направления, одного сектора или всего департамента.

Что ещё нужно знать про менеджмент IT-проектов

Профессия сейчас востребована

Во-первых, чем больше проектов, тем больше менеджеров нужно. Во-вторых, всё больше компаний стараются нанимать специалистов для реализации конкретных задач, а не передавать некрупные задачи продуктовым командам.

Чтобы убедиться, достаточно зайти на условный ресурс для поиска работы. Там опубликовано около семи тысяч вакансий — только по Москве. Из них почти четыре — на удалёнке. При этом на момент написания статьи значительная часть — от IT-компаний.

И на мой взгляд, в ближайшие три года потребность в менеджерах IT-проектов сохранится.

Управленческие навыки помогают в жизни

Обычный специалист отвечает только за себя, но руководитель проектов — за всю команду. Это гигантский уровень ответственности.

В таких условиях учишься расставлять приоритеты — потому что больше никто это не сделает — и оперативно принимать решения. И параллельно держать в голове план-график завершения проекта или релизного цикла.

Всё это помогает в работе и в жизни, потому что цель — это тот же проект. Мы думаем: «Я еду в отпуск, покупаю чемодан,  начинаю упаковывать вещи. Если я забыл купальник, куплю там. Значит, нужны дополнительные деньги». Этот пример показывает, что задачи менеджера проектов уже есть у каждого, просто сфера обычно обозначена бытовыми обязанностями.

Есть возможность что-то изменить

Поскольку менеджер — связующее звено между бизнес-заказчиком и реальными исполнителями, есть возможность создать что-то совершенно новое — даже если это только страница сайта — и функционирующее и повлиять на результат.

Например, реализация закрытия вклада клиентом в выходной, неоперационный, день. Если получилось улучшить систему, оставаясь в рамках законодательства РФ и норм о бухгалтерском учёте, и клиенты в будни могут не отрываться от работы и ехать в банк для оформления услуги — то проект можно оценить на 5+.

Можно общаться с разными людьми, попасть на разные проекты

Сегодня вы занимаетесь одним проектом, завтра — другим, потом, в течение недели, возвращаетесь к первому проекту. Такие переключения помогают прокачать адаптивность и умение быстро собирать и обрабатывать информацию. А также освоить программы, которые упростят ведение проектов и взаимодействие конечных пользователей.

К тому же регулярное общение с коллегами и партнёрами из разных сфер помогает не только наладить коммуникацию, но и построить крепкие связи. А это важно, ведь проекты не стоят на месте.

Работать «9 до 18» получается не всегда

Некоторые задачи выходят в продуктивную среду в выходные. И менеджер должен убедиться, что к утру понедельника ничто не сломается. Например, на завершающих этапах перед выходом в прод мы подключаем команду и ещё раз обсуждаем решения возможных проблем.

Многие вендоры и члены команды работают в разных часовых поясах. Это с одной стороны, позволяет следить за статусом задачи 24/7. Но с другой — невозможно подключить сотрудника к задаче в нужное время. И появляется лаг в коммуникации и скорости решения задач.

Руководители проектов получают меньше, чем разработчики

Причём неважно, о каком направлении или языке разработки мы говорим. Хотя ответственности и нагрузки у проджект-менеджера тоже много.

В открытых источниках можно увидеть вакансии с зарплатой от 40 тысяч рублей до вычета НДФЛ. Обычно она становится привлекательной уже на позиции продакта или IT-партнёра.

Есть стереотип, что менеджеры проектов ничего не делают

Такой стереотип появился, потому что наша работа не так заметна. Разработчики пишут код, тестировщики находят дефекты и баги, а менеджер — контролирует процесс.

При этом руководителю проекта всегда есть чем заняться: одни задачи он закрывает, другие убирает в бэклог, у третьих «держит руку на пульсе». Параллельно ведёт множество переписок, созванивается с разными командами, пишет отчёты и отвечает на письма.

И защищает команду, мотивирует её, помогает разобраться со стоящими проблемами. Потому что хорошие кадры на вес золота.

Что почитать по теме

• Том ДеМарко «Deadline. Роман об управлении проектами». Упоительная книга. Если после неё, желание заниматься проектной деятельностью не угаснет, то рекомендую.
• Том ДеМарко, Тимоти Листер «Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения». Книга больше про разработку. Но благодаря ей понимаешь, почему сколько рисков важно учесть и донести до заказчика.
• Скотт Беркун «Сделано. Проектный менеджмент на практике». В рамках работы над статьёй поняла, что нужно выкроить время и перечитать.

Думаю, что указанные книги — мой личный Топ-3. Если будете искать книги через интернет-магазины, вам предложат что-то ещё. Но указанные отражают то, с чем вы можете столкнуться на позиции менеджера проектов. Если книги не вызывают доверия, ниже мой топ фильмов. Важно: смотрите их как пособие.

• Социальная сеть (The Social Network, 2010). Этот фильм очень грамотно рассказывает о том, как правильно набрать команду, с которой получится работать.
• Непокорённый (Invictus, 2009). Помогает понять других. В нём речь идёт о командном взаимодействии и том, что руководитель проектов должен найти что-то объединяющее.
• Startup.com Очень рекомендую, фильм. Он показывает взлёт и падение. И ещё неизвестно, что отнимает больше сил.
• Апполон 13 (Apollo 13, 1995). Если абстрагироваться, то приблизительно так и выглядит работа над проектом.

Удачи!

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 будет больше, чем негативных.

Меня зовут Иван Успенский, я работаю с UI/UX и аналитическими решениями в КОРУС Консалтинг – и мы с вами поговорим о том, как обычно создаются дашборды и почему это не всегда происходит успешно; а еще сформулируем рекомендации для всех, кто хочет создавать полезные и востребованные информационно-аналитические системы.

Зачем нужен дашборд?

Дашборды – экранные формы информационно-аналитических систем — это современные отчёты, позволяющие принять управленческое решение быстро и обосновано. Классический вариант – это бумажное сообщение в определенной форме, где изложены данные, характеризующие процессы и события. Сотрудники, принимающие решения, изучают материал – и решают, что делать или от чего воздержаться. Дашбордами пользуются в продажах, маркетинге, политике, производстве, охране природы, путешествиях и так далее. Современный цифровой дашборд работает быстрее своего бумажного аналога, может быть интерактивным и содержать данные для разных категорий пользователей.

На тактическом уровне причины создания дашбордов могут быть разными:

1. Оцифровка бумажных отчетных форм. Например, в компании для руководства регулярно готовилась презентация со вполне определенной информацией. Эту презентацию перевели в цифровой вид, автоматизировали сбор и обработку данных — и получили экранную форму в системе.
2. Осознанная необходимость мониторинга в ходе развития. Компания проанализировала бизнес, выработала ряд гипотез, нуждающихся в проверке цифрами; описала ряд ключевых процессов — и сформулировала для них важные метрики (KPI). Для их визуализации и отслеживания построили дашборд.
3. Обобщение или детализация информации. Дашборд по конкретному процессу уже был, но стало важно получить больше данных – или посмотреть на них под другим углом. Если появляются новые пользователи с новыми запросами – возможно, будет логичнее сделать для них новый дашборд на основе работающего, а не дополнять старый данными и функциями для управления их визуализацией.
4. Копирование работающих решений из другой области. Взяли дашборд одного отдела — и внедрили его для других (с изменениями или без таковых); или же — посмотрели на конкурентов или партнеров и т.п.

Как появляются дашборды в проектах?

Есть два основных подхода к созданию программного обеспечения вообще, информационно-аналитических систем (BI) в частности – и дашбордов как части таких систем: проектный и продуктовый.

ИТ-специалисты, создающие дашборды, зачастую также делятся на «проектных» и «продуктовых», не пересекаясь ни в командах, ни даже на уровне организации, в которой трудятся. Так, например, в истории с продуктом выше шанс, что к работе будет привлечен UX-дизайнер; в проектных командах такая роль встречается заметно реже.

Чтобы создать дашборд, сначала нужно подготовить данные для него. Хорошо, если в организации есть подразделение, отвечающее за информационно-аналитическое обеспечение деятельности. .В этом случае речь идёт о постоянном анализе аудитории и удовлетворении её нужд, и здесь можно использовать продуктовый подход. А вот если такого подразделения или хотя бы постоянного подрядчика нет, то деятельность по созданию дашборда становится проектом – разовым мероприятием по созданию уникального результата с ограниченными ресурсными затратами временно сформированной командой, взаимодействующей со стейкхолдерами.

Чтобы выбрать, какой путь больше подойдет вашей команде, нужно учесть все плюсы и минусы:

Проектный метод

Плюсы проектного подхода: бюджет и срок согласованы «на берегу», роли в команде необходимы и понятны. Это гибкий и полезный инструмент управления работами, включающий методы планирования и коммуникаций.

Однако для такого подхода нужно собрать полные требования к дашборду, согласовать необходимые дополнительные затраты и понять особенности реализации и эксплуатации. Расскажем, что может пойти не так.

Давайте посмотрим на иллюстрацию. Проектная команда пытается по косвенным признакам проанализировать ту область деятельности, которой посвящен запрошенный дашборд. Эта команда изображена в нижнем правом углу: один аналитик смотрит на следы процессов, другой – изучает документацию – и оба не видят происходящего в бизнесе, да и потребностей пользователя понять не могут ввиду противоположности точек обзора. Но мы ведь собрали требования к проекту, почему аналитика не работает?

Потому что у сотрудника, аккумулировавшего данные, есть своя точка зрения на процесс:

Сотрудник 1. Ему крайне важно понять реальную ситуацию с бизнес-процессами, чтобы принять необходимые решения и обеспечить стабильность работы и рост организации (на иллюстрации изображен осматривающим ситуацию в целом с высоты).

Сотрудник 2. Хочет, чтобы его недоработки не попали «в кадр», особенно – по выполнению плана по показателю Х в истекшем месяце.

Сотрудник 3. Ему важно, чтобы данные не пришлось вводить слишком часто – потому что придётся регулярно задерживаться на работе.

Если создавать дашборд на основе взаимодействия лишь с одним сотрудником, очевидно, что у нас получится одностороннее видение.

Вот дашборд первого сотрудника. Акцент в нем — на возможности сопоставления разных показателей и интерактивность, обеспечивающую необходимую гибкость настройки отображения данных. К сожалению, этот сотрудник чаще всего занят – и делегирует задачу руководителям подчиненных подразделений. Кроме того, его время слишком ценно – и он не может позволить себе генерацию требований (полноценное интервью исключено); в лучшем случае он готов лично выбрать один вариант из нескольких предложенных.

Таким будет дашборд второго сотрудника. Он отвечает только за один показатель (второй блок дашборда поручен другому человеку), а еще, мы помним, ему невыгодно отображение данных за истекший месяц, поэтому утвержденный им макет ограничивается данными за сутки и за квартал.

Дашборд третьего сотрудника. Будущий пользователь не хочет собирать большой объем данных, и потому оставляет на макете только квартальное значение.

Проектная команда в целом поддерживает третий вариант – потому что здесь исключена интерактивность, т.е. разработка будет ощутимо проще («за» высказались разработчик и руководитель проекта).

Вряд ли в таком случае получится полезный для бизнеса дашборд. В лучшем случае это будет вспомогательный инструмент, а не ультимативное решение проблемы недостатка данных для принятия решений.

Что еще усложняет проектный подход

У каждого стейкхолдера вполне могут быть свои специфические интересы и цели применительно к дашборду и проекту в целом. И все их нужно учесть:

1. Разработчик: «сделать технологично и просто, а еще – использовать компонент, который я недавно освоил, и он мне нравится».
2. Сотрудник функционального подразделения: «Дашборд должен быть максимально похож на то, как выглядит отчёт, который я готовлю для руководства каждую среду».
3. Руководитель проекта: «Сделать все максимально дешево и быстро».
4. UX/UI-дизайнер: «Инструмент должен быть удобным и комфортным для пользователя».
5. Бизнес-аналитик: «Решение должно соответствовать бизнес-целям пользователей в рамках бизнес-процессов».
6. Дата-инженер: «Нужно сделать так, чтобы не пришлось дорабатывать систему-источник».
7. Любой сотрудник: «Давайте сделаем это быстро, чтобы можно было в пятницу уйти с работы пораньше».

Применение UX-дизайна усложняет планирование работ в проекте. С одной стороны, тщательная проработка макетов и прототипов сокращает затраты на разработку программного обеспечения; с другой стороны, такие задачи несколько специфичны — и планирование и управление ими может оказаться не так просто для руководителя проекта.

Минусы проектного подхода можно сократить при помощи правильной работы с командой. Руководитель должен гибко управлять сотрудниками с учетом реальных вводных – это могут быть неполные и нечеткие требования, новые роли и процессы, новые артефакты. Каждый должен понимать свою роль и общую концепцию проекта. В таком случае потери времени и ресурсов будут минимальными, а работа эффективной. Хотя такая осознанная работа над проектом и будет сложнее и, очевидно, более затратна для команды и руководителей.

Продуктовый подход

В отличии от проекта, продукт развивается циклично и итерационно: от гипотезы через её валидацию к проектированию и разработке, тестированию и внедрению со сбором обратной связи. В данном подходе вполне возможно начинать с MVP (минимально жизнеспособного продукта) с базовой функциональностью. А затем в ходе итераций-спринтов дашборд или система в целом «обрастает» новыми возможностями. Зачастую это позволяет в короткие сроки (иногда даже быстрее, чем в проекте) получить работающий инструмент, и за счет дальнейшего развития сделать его максимально эффективным.

Допустим, у компании есть специализированное подразделение, ответственное за информационно-аналитическое обеспечение деятельности организации; в этом подразделении в частности и в организации в целом, соответственно, постоянно идёт работа по совершенствованию и поддержке системы отчетности (ответы на новые вызовы, реакция на новые требования бизнеса). Тогда работа с конкретными дашбордами становится всего лишь одним из шагов в развитии продукта в целом, а не отдельной автоматизацией.

Подход хорош тем, что позволяет не спешить и на каждом этапе внимательно исследовать потребности пользователей. В таком случае функциональность и интерфейс создаются или адаптируются под конкретные потребности бизнес-заказчиков, выявленные в ходе исследований.

Наиболее же очевидный минус – это издержки. Их легче обосновать, когда компания запускает новую систему. И, очевидно, сложнее – если нужно что-то изменить в информационно-аналитическом обеспечении деятельности организации и процессах принятия управленческих решений.

Что выбрать и как действовать?

В ответ на такой вопрос мы предлагаем свой: а зачем выбирать? На практике подходы различаются очень сильно; настолько, что даже роли сотрудников не совпадают для большей части команд (начиная уже с менеджеров проекта и продукта). Почему так сложилось? Возможно, из-за особенностей восприятия продуктового подхода – как методологии создания чего-либо для широкой аудитории и рынка в целом.

KPI продукта обычно включают маржинальность, продвижение, ценностное предложение, перспективы развития и тиражируемости. И почему же мы не можем эти метрики воспринять не только для B2C-продукта? Каждый из этих пунктов вполне трактуется для информационно-аналитической системы внутри организации. А KPI как раз и определяют эффективность деятельности внутреннего ответственного.

Оба подхода полезны при соблюдении правил использования. Более того, мы искренне верим, что на самом деле оба подхода и применяются – при создании работоспособных и эффективных систем – но экторы делают это не вполне осознанно, игнорируя методологические наработки, не признавая такое положение дел даже для себя. Ведь и ответственное подразделение в организации рано или поздно обратится к подрядчику для внедрения или развития BI-платформы в конечные сроки за конечные деньги (появится проект – и соответствующая команда, и план и прочее). А в проектной структуре Исполнителя, если он хочет создавать качественные решения, ориентированные на пользователей и их бизнес-цели, рано или поздно появятся UX-специалисты, методология работы которых с обязательностью включает итеративные исследования и проверки гипотез (паттерны проектирования, характерные в большей степени для продуктового подхода). Признав применимость этих тезисов к своим решениям, вы сможете работать более эффективно, не изобретая велосипедов в методах и средствах проектирования.

В заключение дадим несколько более практических советов.

Пользователь:

Смело формулируйте требования. Требования – единственные возможные критерии качества.

Старайтесь ориентироваться на реальные бизнес-потребности – свои и ваших коллег.

Не пытайтесь 100% скопировать решение: не используйте что-либо только потому, что в другом месте или в другом виде оно каким-либо образом работает.

Не уходите в детали реализации – это можно оставить исполнителям работ.

Заказчик:

Настройтесь на конструктивный диалог. Если работа над результатом превратится в «перетягивание одеяла», есть риск уйти в две крайности. Первая — коллеги-сотрудники будут диктовать требования и получат неудобный и неэффективный инструмент. Вторая – исполнитель сделает все красиво и умело, но бесполезно.

Исполнитель:

Сделайте все для того, чтобы получить подробные требования, а не просто ожидайте готовый набор от Заказчика.

Готовьтесь к тому, чтобы использовать элементы бизнес-консалтинга, UX-дизайна и других не совсем привычных для проектов, составляющих в разработке программного обеспечения.