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