Кейс: Как организовать работу IT-подразделения, чтобы оно развивало ваш бизнес

Отбрасываем второстепенные задачи, формируем продуктовые команды, налаживаем коммуникации с операционными подразделениями, приносим много пользы бизнесу небольшими кусочками.

Как реформировать работу ИТ-подразделения компании, чтобы в кратчайшие сроки получить ощутимые результаты для бизнеса, рассказывает директор по продукту компании «Биглион» Алексей Захаров.

Когда я пришел в «Биглион» в январе этого года, группы разработки в компании делились по платформенному признаку, то есть были группа сайта, группа приложений, группа внутренней CRM-системы и группа директ-маркетинга. Поэтому они занимались не столько развитием бизнеса, сколько развитием своих платформ. Условно говоря, группа сайта делала новый дизайн, группа мобильных приложений делала новую версию приложений, группа CRM делала новую версию интерфейса для процесса заведения акций и т.д.

Это продолжалось в каждом из подразделений уже по году без добавления какой бы то ни было новой функциональности в бизнес. Никто никому не мешал, но и не помогал, занимаясь своей частью.

Наши руководители были этим не очень довольны. И это привело, в том числе, к изменению курса.

В первую очередь я провел интервью со всеми топ-менеджерами компании и собрал список стратегических направлений, в которых компания видит свои главные точки роста. Их получилось 14. По мнению руководителей, каждым из этих 14 направлений кто-то занимался. Но так как направления существовали отдельно, а команды — отдельно, то возникала ситуация, что 0,3 программиста занимается одним делом, а 2,7 программиста — другим и т.д. Это было странно и непрогнозируемо. И у сотрудников, естественно, возникали отговорки: они не сделали одно, потому что занимались другим.

Мы сразу договорились о новом правиле: каждый программист, тестировщик, продакт-менеджер, проджект-менеджер должен быть только в одной группе развития и заниматься только одним направлением, и поделить пополам его нельзя. И, соответственно, если мы будем формировать новые группы развития, в них должны быть люди целочисленные.

Также мы договорились, что все те направления, которые мы выберем из четырнадцати существующих и которыми будем до конца года заниматься, для компании важны. Понятно, что какие-то из них могут принести деньги сейчас, какие-то потом, какие-то более стратегически важные, какие-то менее - но все они в равной степени требуют внимания. Поэтому никакого сквозного приоритета больше не будет. То есть, если на каком-то направлении что-то «горит», перебрасывать туда людей с других направлений мы больше не будем.

Естественно, 14 направлений требовали большого числа дополнительных сотрудников. Поэтому мы стали обсуждать с топ-менеджерами, какие из направлений наиболее приоритетны.

В итоге мы оставили в этом году 7 направлений развития:

● эффективность покупателей,

● эффективность внутренних процессов,

● персональные коммуникации,

● разработка маркетинга,

● развитие Frendi (еще один наш бренд),

● кэшбэк как новое, динамично развивающееся направление,

● направление бесшовного опыта (когда процесс покупки услуг происходит целиком на «Биглион», и клиенту не приходится отдельно покупать купон, а потом что-то доплачивать на месте).

Под каждое направление развития мы выделили группу, в которой есть веб-программисты, мобильные программисты, тестировщики, продакт-менеджеры. И там, где группа получилась большая, есть еще проджект-менеджеры.

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

А чем хорош подход с группами развития по направлениям бизнеса? Тем, что в группе для подавляющего большинства решаемых задач есть все необходимые технологии и люди, и они только внутри своей группы что-то приоритезируют. Людей разных компетенций подключают сразу к работе над одной задачей, она максимально быстро проходит стадию работы и становится доступна клиентам.

Для того, чтобы эти группы наиболее эффективно занимались вопросами развития, мы совместно с директором по разработке сформировали еще три поддерживающих подразделения:

● веб-платформа,

● мобильная платформа,

● IT.

Веб-платформа и мобильная платформа помогают продуктовым командам не терять скорости за счет контроля качества кода, периодических работ по рефакторингу, исправления возникающих ошибок в текущей функциональности. А IT-подразделение занимается тем, что готовит инфраструктуру для разработчиков.

Нам требовались квалифицированные продакт-менеджеры. Надо понимать, что когда вся разработка в компании была разбита по платформам, люди, которые назывались продакт-менеджерами, конечно, были, но по факту ими не являлись. Просто приходил генеральный директор или другие менеджеры и рассказывали, какую фичу им нужно сделать следующей - и она как-то делалась. А я считаю, что продуктовый подход включает в себя две составляющих: организация структуры продуктовых и технологических групп, а также целеполагания. Что это означает?

Продакт-менеджеры, которых мы теперь нанимали, должны были обязательно обладать самостоятельностью, проактивностью, бэкграундом в других компаниях, уметь на равных вести переговоры с топ-менеджерами, отстаивать свою позицию.

Все это стало необходимым, потому что целеполагание теперь выглядит следующим образом. Выделив направления развития, мы определили, за какие метрики будет отвечать каждая команда. Например, группа эффективности покупателей отвечает за конверсию на сайте и в приложениях или, например, за рост NPS (индекс удовлетворенности) наших продуктов. И мы нанимаем продакт-менеджера, который уже работал в похожих условиях, имеет определенную экспертизу, понимает, как эти метрики растить.

Продакт-менеджер ежеквартально формулирует, насколько он собирается вырастить те или иные метрики, цели предварительно обсуждаются и согласовываются с командой разработки. Но это не классический подход, когда мы в диаграмме Ганта пишем все задачи одну за другой и просто их делаем по порядку. А это, можно сказать, предпринимательский подход.

Например, мы хотим вырастить конверсию на 10%, у нас есть 10 гипотез, как это может произойти, что-то сработает, что-то не сработает. Продакт-менеджер с командой выбирают эти гипотезы и от наиболее вероятной к менее вероятным в течение квартала реализуют функциональность, которая должна привести команду к планируемым результатам. Продакт-менеджер отслеживает изменение этих метрик, и понимает, движется ли команда в правильном или неправильном направлении.

Мы пользуемся методом OKR. На практике это выглядит так: в компании есть файл в гугл-док, который доступен всему менеджменту. Раз в квартал на вкладках для каждой команды развития формулируются три-четыре цели, под каждой выставляются 2-4 ключевых результата с метриками, на основании которых мы будем понимать, достигается ли цель. Продакт-менеджер приходит на собрание директоров, кратко это все излагает, а ему говорят, достаточно ли это амбициозно. В общем, происходит своего рода «защита» цели. И дальше группа работает в течение квартала, раз в одну-две недели обновляет в гугл-доке информацию о том, как метрики изменились. Все руководство в курсе. И все понимают, кто чем занимается и почему.

Раньше в компании были разработки длиной в год, теперь мы договорились со всеми продакт-менеджерами, что в разработку мы берем кусочки бизнес-ценности за раз не больше чем на два спринта, то есть на месяц. (Под бизнес-ценностью я понимаю что-то, что уже доступно в нашем сервисе конечным пользователям и как-то меняет наш бизнес).

Абсолютный минимум производительности каждой команды — не менее одного кусочка бизнес-ценности в месяц. Это самый крайний вариант, на деле все происходит гораздо быстрее. Все понимают, что мы движемся небольшими шажками, но достаточно быстро.

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

Мы говорим о том, какая функциональность стала доступна клиентам, как она повлияла на бизнес. Выводы делаем на основании AB тестов, которые проводим при запуске каждого кусочка функциональности. И таким образом у нас получается полная прозрачность на этапе планирования и на этапе демонстрации результатов.

А благодаря тому, что мы всю разработку разбили на семь направлений, фактически получается, что у каждого продакт-менеджера задача, упрощенно говоря, в семь раз легче, чем развитие всей компании. Потому что он отвечает только за свое направление, и задача у него поменьше. А моя роль заключается в организации этих процессов, в настройке коммуникаций между всеми бизнес-подразделениями, ИТ-подразделениями, продакт-менеджерами, дизайнерами и аналитиками. А также в том, чтобы наше видение бизнеса, несмотря на то, что мы его развиваем по кусочкам, не распадалось, как пазл - для этого мы проводим синхронизационные встречи.

То, что было невозможно еще полгода назад, стало возможным. Мы за 1-2 спринта (2-4 недели) запускаем такие продукты, например, как доставка еды без купона, оффлайн-кэшбэк по чекам, обновленный поиск с подсказками. Это, на мой взгляд, очень хорошая скорость.

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

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

И я считаю, что это нас приведет к серьезным успехам уже в следующем году. До конца этого года наша цель - нагнать все технологические и продуктовые моменты, от которых мы отстали за то время, пока делались какие-то большие вещи, которые не улучшали бизнес. И несмотря на это уже сейчас заметны изменения, в том числе в сводных отчетах по выручке и эффективности бизнеса.