Внедрили систему управления проектами сразу для всех - и столкнулись с саботажем. Как внутренний инструмент превратился в тиражный продукт
Чтобы разобраться, как рождаются действительно рабочие корпоративные решения, я поговорила со Стеллой Бояршиновой - автором и методологом продукта "Корадиум". В центре разговора оказались не столько функции системы, сколько история ее развития: от внутреннего инструмента небольшой проектной компании до самостоятельного решения для разных организаций.
Этот путь занял около 12 лет и оказался далеко не линейным. Команде пришлось пережить неудачное внедрение, изменить подход к запуску, отказаться от части первоначальных идей и научиться отличать универсальную методологию от особенностей конкретного клиента.
С чего все начиналось
Когда Стелла пришла в компанию, большая часть работы уже была связана с клиентскими проектами. Организации требовался удобный инструмент, в котором можно было бы планировать этапы, назначать задачи и исполнителей, учитывать ресурсы и трудозатраты.
Готовые решения команда изучала, в том числе продукты на базе 1С. Однако у большинства вариантов обнаруживался общий недостаток: для полноценной эксплуатации требовался отдельный специалист, который постоянно занимался бы настройкой и сопровождением системы. Для небольшой проектной компании это было слишком дорого.
В итоге разработчики решили создать инструмент самостоятельно. Так появилась ВУС - внутренняя учетная система. Ее использовали в собственных проектах, постепенно совершенствовали и долго не воспринимали как коммерческий продукт. Решение создавалось прежде всего для себя: многие процессы были понятны без подробных пояснений, а интерфейс отражал внутреннюю логику компании.
Все изменилось во время работы с одним из клиентов. На этапе пресейла заказчик подробно описал проблемы в проектном управлении, и команда узнала в них собственные прежние трудности. Клиенту показали ВУС, после чего стало очевидно: внутренний инструмент можно адаптировать для других организаций.
Так началось превращение ВУС в "Корадиум" - систему управления проектами для бизнеса, которую можно внедрять постепенно и настраивать под разные модели работы.
Главная ошибка первого внедрения
Первое крупное внедрение команда начала максимально прямолинейно. Систему развернули сразу для всех, руководителей проектов обучили работе, а сотрудников призвали перейти на единые правила.
С точки зрения методологии решение казалось оправданным. Если руководству нужна целостная картина по проектам, в системе должны появляться все задачи, сроки, трудозатраты и статусы. Но для пользователей такой запуск означал слишком резкую перестройку привычного процесса.
От сотрудников одновременно требовали фиксировать работу, заносить задачи, следить за сроками и регулярно обновлять данные. Интерфейс тоже воспринимался как непривычный и перегруженный. В результате пользователи фактически отказались работать в новой системе: она показалась им сложной и неудобной.
Команде пришлось признать, что проблема заключалась не только в обучении или сопротивлении изменениям. Сам сценарий внедрения был построен неправильно. Нельзя заставить всю организацию сразу перейти на сложный процесс, даже если этот процесс логичен с точки зрения руководства.
Подход изменили: количество функций сократили, а запуск разбили на более понятные этапы. Сначала пользователям предложили только те возможности, которые были необходимы в ежедневной работе. Затем, когда базовые сценарии стали привычными, начали добавлять планирование, контроль сроков, учет ресурсов и другие элементы.
Через год тот же клиент уже называл систему "артерией" своей работы. Этот пример стал важным принципом развития продукта: хорошая программа для управления проектами не должна требовать освоения всех функций в первый день. Она обязана давать понятный результат уже на начальном этапе, а затем позволять постепенно углублять автоматизацию.
От внутренней практики к универсальному решению
При коммерциализации системы не потребовалось полностью переписывать ее с нуля. Наиболее устойчивой частью оказалось методологическое ядро: структура проектов, этапы, задачи, роли, ресурсы и трудозатраты.
Зато все, что раньше держалось на внутренних договоренностях, пришлось формализовать. Были переработаны формы, термины, реквизиты и параметры. Для разных ролей появились отдельные рабочие места - например, для руководителя проекта и планировщика.
Особенно сложным оказалось управление ресурсами. Даже компании, работающие в одной проектной логике, могут совершенно по-разному распределять специалистов, учитывать загрузку и планировать участие сотрудников. Поэтому нельзя было просто объявить внутреннюю практику единственно правильной.
Команда постепенно пришла к более гибкому подходу: продукт должен задавать общую основу, но оставлять заказчику пространство для настройки. Именно поэтому внедрение системы управления проектами нельзя сводить к установке программы и проведению пары обучающих занятий. Нужно согласовать методологию, роли, правила работы с данными и постепенность перехода.
Почему не стали делать полноценный Service Desk
В процессе развития у команды возникал вопрос: не превратить ли решение в универсальную платформу, которая одновременно закрывает проектное управление, поддержку пользователей и функции Service Desk.
От этой идеи отказались. Причина проста: попытка охватить все возможные процессы быстро размывает продукт. Вместо ясного инструмента появляется огромная система, в которой много функций, но мало понятных сценариев.
"Корадиум" сосредоточился на задачах проектной работы: планировании, распределении ресурсов, контроле сроков, фиксации трудозатрат и формировании управленческой отчетности. Такой фокус оказался важнее стремления добавить максимум возможностей.
Это важный урок и для заказчиков. При выборе корпоративной системы управления проектами стоит оценивать не количество модулей, а то, насколько быстро сотрудники смогут использовать решение в реальной работе. Избыточность часто становится причиной низкой вовлеченности и последующего саботажа.
Как не превратить продукт в склад пожеланий
У внешних клиентов почти всегда появляются индивидуальные требования. Одни хотят особые отчеты, другим нужны собственные статусы, третьи предлагают изменить логику распределения ресурсов. Если реализовывать каждое пожелание без общей оценки, продукт быстро превращается в набор несвязанных доработок.
Команда "Корадиума" разделяет клиентские запросы на несколько категорий. Часть из них действительно отражает универсальную потребность рынка и может стать функцией продукта. Другая часть нужна только одной организации и должна решаться настройками или отдельными расширениями. Наконец, некоторые идеи противоречат базовой логике системы и не должны включаться в стандартную поставку.
Такой фильтр помогает сохранять целостность решения. Автоматизация управления проектами должна упрощать работу, а не заставлять пользователей разбираться в десятках исключений.
Что находится под капотом
В основе решения лежит не только пользовательский интерфейс, но и связка методологических объектов: проекты, этапы, задачи, исполнители, сроки, ресурсы, трудозатраты и статусы. Их взаимосвязь позволяет видеть не отдельные действия сотрудников, а полную картину продвижения проекта.
При этом разработчики старались сохранить баланс между глубиной и простотой. Система должна поддерживать сложные управленческие сценарии, но не требовать от каждого пользователя знания всей внутренней структуры. Руководителю нужен контроль и аналитика, исполнителю - понятный список задач, планировщику - инструменты работы с загрузкой.
Обновления также приходится выпускать осторожно. Любое изменение влияет на существующие процессы клиентов, поэтому новые функции проверяются не только с точки зрения разработки, но и с позиции методологии. Важно, чтобы обновление расширяло возможности, не разрушая уже сформированные привычки пользователей.
Что команда сделала бы иначе
Главный вывод спустя годы - не стоит начинать внедрение с попытки охватить всю организацию и сразу описать каждый процесс. Гораздо эффективнее выбрать ограниченный, но полезный сценарий, получить быстрый результат и только потом расширять область применения.
Еще один урок касается коммуникации. Пользователям нужно объяснять не перечень функций, а практическую пользу: что изменится в их ежедневной работе, какие действия исчезнут, где станет проще контролировать задачи и сроки.
Внедрение системы управления проектами становится успешным, когда технология сопровождается изменением процессов, обучением и поддержкой. Если же программный продукт просто устанавливают поверх старых правил, он рискует остаться формальным отчетным инструментом.
История "Корадиума" показывает: сильный тиражный продукт необязательно рождается в крупной технологической компании. Иногда его основой становится внутренняя разработка, созданная для решения вполне конкретных проблем. Но для выхода на рынок такой инструмент должен пройти несколько этапов - формализацию, проверку на разных клиентах, отказ от лишней сложности и настройку понятного пути внедрения.
В итоге корпоративная система управления проектами должна быть не энциклопедией функций, а рабочей средой, к которой сотрудники готовы возвращаться каждый день. Именно это превращает автоматизацию из формального проекта в устойчивую часть бизнеса.
