За шесть лет работы продакт-менеджером в разных решениях для автоматизации проектов я видел одно и то же много раз: выбирают систему по чек-листу — «есть Гант? есть ресурсы? есть бюджеты? берем!». Через n месяцев оказывается, что не так уж и важен сам факт наличия функций. Невозможность адаптировать продукт под реальные процессы — вот что заслоняет собой все остальное.
Типичные ситуации: купили систему X — удобно для простых проектов. Выросли, нужны сложные зависимости — уперлись в потолок, пришлось мигрировать. Взяли мощную корпоративную платформу — любое изменение требует заявки в IT и недель ожидания. Команды потихоньку работают в таблицах и простых таск-трекерах.
В статье вы найдете:
еще одну неприятную историю о ведении проектов — с подсчетом денег в чужих карманах;
четыре проблемы жестких систем и их решения из моей собственной практики;
разбор трансформации low-code Waterfall инструмента в Agile всего за неделю неспешной работы.
Долго, дорого, неудобно: настоящая цена негибких проектов
Обещанная история из опыта компании-интегратора, с которой познакомился на пресейле.
Купили систему для классических проектов за примерные 700к/год. Функциональность покрывала потребности, система работала отлично.
Открыли R&D отдел, там работают по Scrum. Проектная система не поддерживает спринты и доски. Решение: купили отдельно одну известную agile-систему. Итого + 200к/год в лицензиях.
Маркетинг захотел вести кампании в Kanban-формате. Одна известная agile-система для них избыточно сложна. Решение: завели простой таск-трекер, +50к/год.
Что имеем: три разные системы, каждая требует поддержки со стороны IT-отдела — таск-трекер, конечно, в меньшей степени, но все же. Данные живут в разных местах, рассинхронизированы. Сводная отчетность по проектному и R&D отделам — количество часов в месяц не считали, но отнимало дополнительное время.
Итого за каждый год использования:
лицензии трех систем — почти 1 миллион рублей;
время на ручное сведение данных — много и в часах, и в деньгах;
ошибки из-за рассинхронизации — сложно оценить, но последствия ощутимы.
Если бы изначально вели все проекты в одной системе, могли бы как минимум значительно сэкономить. Кроме лишних затрат есть и другие варианты усложнить себе жизнь.
Четыре типичных проблемы жестких систем и как с ними справляется low-code
1. Изменение системы — это отдельный проект
Менеджер проекта: «Нам нужно добавить поле для трекинга рисков в карточку проекта»
IT-отдел: «Хорошо, оформите заявку на доработку»
Через неделю: «Оценили задачу. 12 часов разработки плюс тестирование. Поставим в бэклог на второй квартал»
Менеджер: «То есть изменения будут через четыре месяца?»
IT: «У нас очередь приоритетных задач»
Менеджер (про себя): «Понятно, буду вести в Excel параллельно»
Последствия:
уходят значительные ресурсы на разработку;
часть информации живет в таблицах, чатах и головах людей, поэтому забывается и теряется;
растет доля Shadow IT — растут риски, связанные с соблюдением ИБ и законодательства.
Как работает в гибкой платформе:
Администратор или технолог системы открывает интерфейс настройки, добавляет кастомное поле «Оценка рисков» (тип данных: список, значения: Низкий / Средний / Высокий / Критический). Изменение применяется мгновенно. Потраченное время: зависит от скорости работы, но явно не несколько месяцев.
2. Процесс подстраивается под ограничения системы, а не наоборот
В компании решают использовать каскадную модель для проектов внедрения, Scrum — для продуктовой разработки. Текущая система поддерживает только каскад с жесткими этапами и датами.
Компромиссное решение от руководителя проектов: «Давайте назовём спринты этапами. Спринт 1 = этап 1, спринт 2 = этап 2...»
Результат через месяц:
система неудобна, исполнители переходят на подручные средства;
из-за отсутствия досок страдает наглядность текущей ситуации;
в классике у задач сроки вместо приоритетов — команда путается в задачах, берет менее приоритетные или просто какие хочется.
Почему это плохо:
Процессы и методологии рождаются из реальных потребностей бизнеса и команд. Когда процесс ломается из-за ограничений инструмента — страдает эффективность.
Как работает в гибкой платформе:
Добавляется новая сущность «Спринт». Создаётся Scrum-доска для Agile-команды. «Классические» команды продолжают работать с этапами и диаграммой Ганта, для Agile-проектов используют спринты и доски.
3. Интерфейс перегружен ненужным
Сотрудник открывает карточку задачи, видит:
поля для каскада — этап, веха, базовый план, процент готовности;
поля для бюджета — плановая стоимость, фактическая, отклонение;
поля для ресурсов — назначенные часы, оставшиеся часы.
Внимание, вопрос: «Где мне просто указать, сколько это займет стори-поинтов?»
Последствия:
увеличивается когнитивная нагрузка;
растет риск ошибок при заполнений полей;
люди работают медленней — много лишнего и отвлекающего на экране.
Как работает в гибкой платформе:
создаем отдельное представление для Agile-команды;
видимы — название, описание, story points, исполнитель, спринт;
скрыты — все поля для каскада и бюджетирования.
Раздражение от неудобства и время на выполнение простых задач сразу сокращается.
4. Система не масштабируется вместе с компанией
Изначально: компания 20 человек, 3 проекта одновременно, каскадная модель. Система подходит идеально.
Несколько лет спустя: компания 100 человек, 20 проектов параллельно, микс методологий (каскад + Scrum + Kanban). Система — та же самая.
Возникающие проблемы:
команды вынуждены подгонять методологию под систему — например, разрабатывают по этапам, в результате медленнее доносят ценность, чем в Agile;
процессы стали сложнее, нужна автоматизация рутины — нет нужных инструментов и люди тратят лишнее время. Например, вместо встроенных согласований по задачам приходится ходить по личкам и созвонам, чтобы получить ок.
много дополнительных расходов — будь то доработка текущей системы или покупка дополнительных инструментов;
если же все-таки мигрируют на другую платформу — долго, дорого, с потерями информации.
Как работает в гибкой low-code платформе:
расширяется функционально — новые модули, кастомные сущности добавляются по мере необходимости;
сокращает расходы — адаптируется под усложняющиеся процессы без смены системы или дорогостоящих доработок.
Low-code платформа: в чем суть подхода
Базовая поставка плюс возможности конструктора
Low-code система поставляется с готовой рабочей конфигурацией, которая покрывает 70-80% типовых потребностей, но при этом архитектура платформы позволяет перестраивать процессы под специфику компании.
Пример: ITSM 365 для управления проектами — полноценная система для классических проектов, работает сразу после установки, без настройки.
Из коробки — каскадная модель, в нее входит:
создание иерахической структуры — проект → этап → задача;
диаграмма Ганта с визуализацией зависимостей между задачами;
функция критического пути для выявления задач, влияющих на сроки;
учет трудозатрат, создание встреч, настройка оповещений;
панель с краткой сводкой по текущей ситуации и дашборды.
Low-code основа позволяет адаптировать систему:
добавлять новые сущности — например, «Спринт» для Agile;
изменять интерфейсы — создать Scrum-доску вместо или параллельно с диаграммой Ганта;
настраивать автоматизацию — триггеры на события, вычисляемые поля;
создавать кастомные метрики и дашборды.
Соотношение способов настройки:
80% изменений — через визуальный редактор без написания кода;
15% — простые скрипты для специфичной логики;
5% — сложная логика настройки, требует квалификации разработчика или поддержки вендора.
Low-code позволяет вносить любые изменения в сжатые сроки — например, изменить методологию в основе системы .
Трансформация под Agile: что конкретно меняется в системе
Рассмотрим, как меньше чем за неделю, в свободное от основных задач время, пересобрали каскадную коробку системы ITSM 365 в Agile-инструмент.
Шаг 1. Добавление сущности «Спринт»
Исходная структура — иерархическая. Проект делится на этапы, этапы — на задачи. Мы создали новый тип проекта — Agile, чтобы разделить логику работы проектов по спринтам и по классической модели. Этапы для каскада скрыли из интерфейса, затем перешли к созданию класса «Спринт».
Атрибуты спринта:
Название — Спринт 1, Спринт 2, и т.д.;
Цель спринта — краткое текстовое описание;
Дата начала/окончания — типичная длительность 2 недели.
Также можно добавить любые другие атрибуты — например, статус или скорость, вычисляемую по сумме стори-поинтов.
Шаг 2. Модификация сущности «Задача» под Agile
Создаем новый тип задачи, в него добавляем поля:
Связь со Спринтом — ссылка на объект «Спринт» вместо связи с «Этапом»
Тип задачи Agile — список значений: User Story/Bug/Technical Task
Оценка задачи — запланированное время в днях и часах
В нашем примере мы не стали вводить поля «Стори-поинты» или «Критерии приемки», но ничто не мешает это сделать.
Шаг 3. Создание Scrum-доски
Что было изначально: основное представление — диаграмма Ганта и канбан-доска
Что создаем для Agile: Scrum-доска — Kanban-подобное представление с карточками задач
Процесс настройки:
Создали новое представление типа «Доска».
Определили колонки по статусам задач — «Создана», «В работе», «Код ревью», «Тест», «Выполнена».
Настроили группировку по исполнителям для визуализации нагрузки.
Задали цветовую индикацию карточек по типам задач.
Какие поля показываем на карточке:
Номер задачи
Тема задачи
Приоритет
Аватар исполнителя
Оценка задачи
Дедлайн
Шаг 4. Представление «Бэклог»
Добавили приоритизированный список всех задач проекта, которые еще не распределены по спринтам.
Процесс настройки:
Создали новое представление типа «Список».
Настроили фильтрацию по задачам, не назначенным в спринт:
проект = <текущий>Испринт = пустоОпределили отображаемые колонки — «Номер задачи», «Тема», «Cтатус», «Ответственный», «Приоритет», «Дедлайн» и другие.
Как и все списки в системе, бэклог можно фильтровать и сортировать, а также сохранять настроенные виды списка. Также мы добавили возможность выделить несколько задач и назначить их в выбранный спринт
Дополнительная возможность: можно настроить автоматический расчет приоритета по формуле (например, WSJF: Business Value / Story Points), но это уже требует небольшого скрипта.
Шаг 5. Автоматизация процессов спринта
Здесь добавили три настройки:
Автоматическое создание нового спринта в привязке к дате предыдущего забега с рассылкой уведомлений участникам команды.
Предзаполнение дат начала и окончания нового спринта — стандартная длительность 2 недели, можно исправить при необходимости
Перенос незавершенных задач прошлого спринта в новый
В результате: меньше ручных действий, больше удобства в управлении проектом.
Критически важный момент:
Каскадная функциональность НЕ удаляется из системы. В проектах внедрения и других процессах, где каскадная модель оправдана, продолжают использовать свои инструменты. Для Agile-проектов создан отдельный интерфейс.
Обе методологии мирно сосуществуют в рамках одной платформы, в них используется единая база данных и система управления пользователями.
Вместо итога: нужна ли вам гибкая проектная система
Исходя из нашего опыта, стоит рассмотреть приобретение low-code платформы в следующих ситуациях:
Процессы меняются или будут меняться
Например, компания находится в фазе активного роста — появляются новые методологии, новые типы проектов, новые отделы. Или требуется постоянная адаптация процессов под изменяющиеся условия.
По-разному организованы проектные процессы внутри компании
В организации одновременно используются разные проектные методологии — каскадная модель для одних проектов, Scrum для других. Также гибкая проектная система пригодится, если есть потребность в кастомизации процессов под конкретных клиентов.
Бюджет на кастомизацию и поддержку систем ограничен
Нет средств на содержание штата разработчиков или оплату дорогих подрядчиков, но при этом критична быстрая адаптация системы — дни и недели, а не месяцы разработки.
Есть потребность в гибкой системе для управления проектами? Узнайте больше о возможностях ITSM 365 на сайте.
Чтобы задать вопросы и получить консультацию, напишите нам в клиентский сервис через форму на сайте или на почту — cs@itsm365.com
