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