Правила развития больших проектов в кризис
Российские технологические компании переживают не лучшие времена, и объявленный властями курс на импортозамещение положение не спасает — сейчас почти все заказчики вынуждены снижать затраты на IT-инфраструктуру. Раньше можно было развивать бизнес, не задумываясь об эффективности отдельных направлений: наличие крупных заказчиков, внешних инвестиций, не требовавших жёсткой отчётности, и поддержка со стороны госструктур — всё это действовало расслабляюще. Кризис уже заставил взглянуть на расходы по-новому очень многих. В том числе и нашу компанию. Первое, что мы сделали, — расставили приоритеты.
Наш основной бизнес состоит в разработке трёх программных продуктов: PKI (управление криптографической инфраструктурой), IDM (управление доступом к информационным системам) и SSO (организация единого входа в приложения предприятий). Наибольшим спросом всегда пользовался программный модуль Avanpost PKI. Он прост во внедрении (в среднем оно занимает один или два месяца) и при этом обеспечивает высокий возврат инвестиций.
При расстановке приоритетов мы [решили] (http://ed.secretmag.ru/#!/topic/4960) сделать ставку именно на это, самое успешное направление и сосредоточили основные силы на выпуске его новой версии.
Перед тем как приступить к работе, мы изменили процесс релиз-менеджмента и сделали выпуск новых версий продуктов независимым друг от друга. Было решено отказаться от использовавшегося раньше годового планирования с ежеквартальным контролем в пользу полугодового — с планированием конкретного перечня задач на краткосрочный период в один-два месяца (по сути, полугодовой план был разбит на контрольные точки). Это дало нам возможность оперативно вносить коррективы в процесс разработки и выпуска.
Следующим шагом стало перераспределение ресурсов. Основные силы, как я уже сказал, были задействованы в работе над новым релизом Avanpost PKI. Система IDM получила второй приоритет, а от запланированного ранее выпуска новой версии SSO было решено отказаться вовсе.
Определившись с тем, развитие какого продукта является для нас самым важным, мы взялись за расстановку приоритетов и в функциональных требованиях к этому продукту. В качестве основного критерия выбрали пожелания заказчиков, которые мы проранжировали согласно их количеству и нашим собственным представлениям о практической целесообразности. На мой взгляд, это вообще универсальное правило — в кризис следует в первую очередь ориентироваться на мнения клиентов, партнёров и сотрудников, отвечающих за продажи.
Проанализировав всю полученную информацию, мы расставили приоритеты с горизонтом планирования в два релиза и выбрали для реализации только те функциональные требования, которые действительно необходимы заказчикам. Самым простым в реализации требованиям, получившим большое количество запросов со стороны заказчиков, мы присвоили приоритет, чтобы реализовать их в первую очередь.
Можно сказать, что мы подчинились закону Парето, согласно которому 20% усилий дают 80% результатов. С точки зрения количества реализуемых требований получилось значительно больше, чем 20%, но такой подход дал нам возможность вынести «эксклюзивный» функционал в следующие релизы — без значительных потерь для потенциальных проектов.
Ещё одним важным решением в процессе выпуска нового продукта стало создание рабочей группы, в состав которой вошли руководители технического блока и представители коммерческих подразделений компании, отвечающие за работу с заказчиками. Как правило, именно эти люди являются первой линией во взаимодействии с клиентами и получают в том числе неформальный отзыв о работе продукта и компании в целом.
Смешивая разработчиков и сейлзов, вы, во-первых, получаете возможность учитывать пожелания заказчиков, высказанные неофициально, во-вторых, снижаете риск того, что в дальнейшем сотрудники коммерческого звена будут противодействовать продвижению нового продукта (а такое бывает), повышая их корпоративную лояльность.
Регулярные собрания рабочей группы с отчётами и демонстрацией проделанной работы также позволили усилить контроль качества и сделали возможным оперативное решение текущих проблем, связанных с техническими или ресурсными ограничениями.
Чтобы оправдать ожидания заказчиков, мы разделили выпуск продукта на несколько этапов. Сначала представили демо с базовым функционалом, затем — стендовую версию с основными возможностями для пилотного тестирования и только после этого — «релизный» вариант продукта с полным функционалом и дистрибутивом.
В результате нам удалось распределить ожидания заказчиков по времени, мы получили возможность работать над устранением ошибок до официального релиза и выдержали запланированные сроки его выпуска.
Фотография на обложке: Pete Ark / Getty Images