Меня зовут Борис Кузнецов, я руководитель Управления стратегических проектов ЕДИНОГО ЦУПИС. В конце прошлого года мы столкнулись с необходимостью сменить менеджер задач и перейти на отечественное решение. После тщательной оценки вариантов мы сделали выбор в пользу системы Shtab — и не пожалели об этом. Рассказываю, как все происходило.

ЕДИНЫЙ ЦУПИС — это финтех-сервис, компания зарегистрирована как небанковская кредитная организация. То есть мы можем проводить платежи и переводы, но не можем выдавать кредиты и предлагать клиентам вклады. И, поскольку мы работаем в сфере финансов, у нас высокие требования к безопасности. Они распространяются на все ПО, которое мы используем, включая менеджеры задач.

Проблема: прошлый сервис перестал работать в России

Раньше мы пользовались двумя зарубежными менеджерами задач. Для ИТ-департамента мы используем иностранный трекер — стандартное решение в этой сфере. А бизнес-подразделения пользовались сервисом Asana. Сотрудники привыкли к нему, и все было хорошо, пока сервис не принял решение уйти из России.

Для нас такой внезапный уход был шоком. Asana довольно быстро свернула деятельность в России, несмотря на то что у многих ее российских клиентов сохранялись оплаченные лицензии. Нам пришлось срочно искать замену — без менеджера задач управлять процессами было трудно.

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

Так что параллельно мы начали искать менеджер задач на замену ушедшей Asana. Сразу решили, что решение должно быть отечественным, потому что любой иностранный сервис может так же внезапно уйти с рынка.

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

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

В качестве основных критериев мы выбрали:

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

●     Возможность кастомизации — чтобы мы могли настроить под себя поля, процессы и отображение информации.

●     Поддержку методологий — чтобы мы могли использовать методологию Kanban, по которой организуем работу.

●     Возможность развертывания in-house — чтобы соблюсти требования к безопасности. Облако нам не подходило: продукт нужно было развернуть на своих серверах.

Это далеко не все. Мы оценивали различные сервисы с точки зрения администрирования, работы с процессами, защищенности, скорости развертывания и многого другого. У нас была довольно высокая планка — преодолеть ее мог не всякий сервис.

Выбор: от 15 вариантов к двум финалистам

Изначально мы оценивали по выбранным критериям около 15 сервисов. Причем действовали в несколько этапов:

●     Отправляли анкеты с вопросами. По ответам мы понимали, какие критерии выполняются, а какие нет. И подсчитывали, сколько баллов набрал сервис.

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

Отбор был жестким. Какие-то сервисы казались нам перегруженными. Какие-то не подходили для будущего масштабирования. В результате отбора в финал вышли две компании, одной из которых был Shtab.

Когда мы определились с финалистами, попросили их рассказать о том, как выглядит техническая архитектура сервиса, какие у нее есть возможности для масштабирования. И в тот момент поняли, что наш выбор — Shtab.

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

С Shtab было иначе. Нам показали логику работы, познакомили с технологиями, которые использовали при разработке. Мы увидели, что у сервиса есть потенциал для масштабирования, и он подойдет для наших процессов. Так и сделали выбор. Причина, по которой мы выбрали Shtab, — прозрачность и возможности для масштабирования по сравнению с другими сервисами.

Подключение Shtab: как процесс выглядел пошагово

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

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

Подготовка серверов. Мы разворачивали Shtab на собственных серверах, и их нужно было подготовить. То есть настроить оборудование, рассчитать нужные мощности и установить на сервера вспомогательное ПО. На все это ушло около 2-4 недель.

Развертывание системы. Вместе с коллегами из Shtab мы загрузили продукт на подготовленные сервера. Дальше занялись установкой, тестированием, подключением — всем, что нужно, чтобы начать работу.

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

Интеграции. ЕДИНЫЙ ЦУПИС работает с множеством сервисов и использует единую систему авторизации. Shtab тоже к ней подключили — дали сотрудникам возможность войти в таск-трекер под теми же учетными данными, что и везде.

Подготовка обучающих материалов. На следующем этапе мы создавали материалы для обучения сотрудников, которые будут пользоваться сервисом. Тут нам очень помогли коллеги из Shtab. Вместе мы записывали видеоролики, проводили вебинары — по сути, подготовили целый миникурс по функциям Shtab.

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

Работа с Shtab: как сервис помогает вести проекты

Первое и основное, чем мы в нем занимаемся, — проектная деятельность. Все проекты и бизнес-задачи идут через менеджер задач.

Когда в команде появляется новый проект, для него создается отдельное пространство в Shtab. Задачам по проекту присваивается определенный приоритет, затем они декомпозируются и распределяются по направлениям. Например, что-то идет в бухгалтерский отдел, что-то в юридический, а что-то в ИТ.

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

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

Отдельно хочу отметить несколько функций Shtab, которые особенно помогают нам в работе.

WIP-лимиты. В методологии Kanban есть такое понятие как пропускная способность сотрудника или подразделения. Это лимит задач, которые может одновременно выполнять человек или команда. Пока сотрудник полностью загружен, новые задачи он брать не может.

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

Цели (OKR). С этой функцией можно отслеживать, как выполняются цели компании на какой-то период — например, на год. Каждую цель можно декомпозировать на подцели и разделить на кварталы, можно привязать к проектам или задачам.

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

Возможности для коммуникации. Наши сотрудники редко обсуждают задачи через почту. По e-mail мы в основном связываемся с внешними клиентами и подрядчиками. А внутреннюю переписку чаще всего ведем через таск-трекер — в Shtab есть такая возможность, и это удобно.

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

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

Безопасность, прозрачность и поддержка: как мы оцениваем работу с Shtab

Мы изначально выбрали Shtab, потому что он отвечал строгим требованиям ЕДИНОГО ЦУПИС к безопасности и масштабированию. И не пожалели о выборе — сервис оправдал себя.

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