За шесть лет работы продакт-менеджером в разных решениях для автоматизации проектов я видел одно и то же много раз: выбирают систему по чек-листу — «есть Гант? есть ресурсы? есть бюджеты? берем!». Через 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 технологиz позволяет вносить любые изменения в сжатые сроки — например, изменить методологию в основе системы .

Трансформация под Agile: что конкретно меняется в системе

Рассмотрим, как меньше чем за неделю, в свободное от основных задач время, пересобрали каскадную коробку системы ITSM 365 в Agile-инструмент.

Шаг 1. Добавление сущности «Спринт»

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

Атрибуты спринта:

• Название — Спринт 1, Спринт 2, и т.д.;

• Цель спринта — краткое текстовое описание;

• Дата начала/окончания  — типичная длительность 2 недели.

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

Шаг 2. Модификация сущности «Задача» под Agile

Создаем новый тип задачи, в него добавляем поля:

• Связь со Спринтом — ссылка на объект «Спринт» вместо связи с «Этапом»

• Тип задачи Agile — список значений: User Story/Bug/Technical Task

• Оценка задачи — запланированное время в днях и часах

В нашем примере мы не стали вводить поля «Стори-поинты» или «Критерии приемки», но ничто не мешает это сделать. 

Шаг 3. Создание Scrum-доски

Что было изначально: основное представление — диаграмма Ганта и канбан-доска

Что создаем для Agile: Scrum-доска — Kanban-подобное представление с карточками задач

Процесс настройки:

1. Создали новое представление типа «Доска».

2. Определили колонки по статусам задач — «Создана», «В работе», «Код ревью», «Тест», «Выполнена».

3. Настроили группировку по исполнителям для визуализации нагрузки.

4. Задали цветовую индикацию карточек по типам задач.

Какие поля показываем на карточке:

• Номер задачи

• Тема задачи 

• Приоритет

• Аватар исполнителя

• Оценка задачи

• Дедлайн 

Шаг 4. Представление «Бэклог»

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

Процесс настройки:

1. Создали новое представление типа «Список».

2. Настроили фильтрацию по задачам, не назначенным в спринт: проект = <текущий> И спринт = пусто

3. Определили отображаемые колонки — «Номер задачи», «Тема», «Cтатус», «Ответственный», «Приоритет», «Дедлайн» и другие.

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

Дополнительная возможность: можно настроить автоматический расчет приоритета по формуле (например, WSJF: Business Value / Story Points), но это уже требует небольшого скрипта.

Шаг 5. Автоматизация процессов спринта

Здесь добавили три настройки: 

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

• Предзаполнение дат начала и окончания нового спринта — стандартная длительность 2 недели, можно исправить при необходимости 

• Перенос незавершенных задач прошлого спринта в новый

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

Критически важный момент:

Каскадная функциональность НЕ удаляется из системы. В проектах внедрения и других процессах, где каскадная модель оправдана, продолжают использовать свои инструменты. Для Agile-проектов создан отдельный интерфейс.

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

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

Исходя из нашего опыта, стоит рассмотреть приобретение low-code платформы в следующих ситуациях:

1. Процессы меняются или будут меняться

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

2. По-разному организованы проектные процессы внутри компании

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

3. Бюджет на кастомизацию и поддержку систем ограничен

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

Есть потребность в гибкой системе для управления проектами? Узнайте больше о возможностях ITSM 365 на сайте. 

Чтобы задать вопросы и получить консультацию, напишите нам в клиентский сервис через форму на сайте или на почту — cs@itsm365.com