Александр Стихарёв, Shtab: Российскому рынку collaboration-систем не хватает экосистемности
Российские компании продолжают миграцию с западных collaboration-платформ, но главные трудности лежат далеко не в области кода. По словам Александра Стихарёва, генерального директора и сооснователя сервиса для совместной работы Shtab, сегодня крупный бизнес сталкивается прежде всего с организационной инерцией и требованиям к безопасности. В интервью TAdviser он рассказал, почему рынок возвращается к on-prem, как меняется роль ИТ и ИБ в выборе платформ и где проходит граница между хайпом и реальной ценностью ИИ.
Стихарёв
Александр, прежде чем мы перейдем к трендам рынка, давайте зафиксируем для читателя: что такое Shtab сегодня? Это классическая замена Jira или нечто другое?
Александр Стихарёв: Если говорить формально, Shtab — это единая экосистема для управления проектами. Но идеологически мы решаем фундаментальную проблему разрыва между стратегией и тактикой.
Часто бывает так: глобальные цели компании живут в презентациях топ-менеджмента и советов директоров, а реальная работа — в таск-трекерах. Эти миры не пересекаются. Мы в Shtab связываем их в единый контур. Глобальная цель декомпозируется до конкретных задач, и каждый сотрудник видит, как его ежедневная работа влияет на успех компании.
Теперь поговорим про рынок. Почему в 2024–2025 годах крупные компании все чаще предпочитают on-premise, хотя еще недавно активно мигрировали в облака?
Александр Стихарёв: Это травма 2022 года, когда вендорские облачные сервисы блокировались без возможности переноса данных, иногда даже без предупреждения. В предыдущие годы риск такого события был гипотетическим, а теперь стал суровой реальностью. Крупный бизнес не готов проходить это повторно. Лучше самостоятельно отвечать за свои данные, чем зависеть от третьей стороны.
Есть и другие важные причины: регуляторика, закрытые контуры, интеграции с DLP и SIEM-системами. Отправлять чувствительные данные в облако зачастую просто невозможно.
Еще один важный фактор — контроль обновлений. Если облако обновилось, оно обновилось у всех пользователей. Но у Enterprise могут быть другие планы: возможно, в компании идет отчетный период, а вендор с утра пораньше выкатывает новый интерфейс, в котором сотрудники не сразу находят нужные функции. В on-prem клиент сам выбирает время обновления, предупреждает пользователей, делает бэкапы.
Мы в Shtab предлагаем и облако, и on-premise. И если заказчик вырос из облачного решения до уровня, требующего закрытого контура, помогаем перенести данные во внутреннюю архитектуру без прерывания процессов.
Как меняется роль ИТ-директора и службы ИБ в принятии решений по collaboration-платформам по сравнению с ситуацией 3-5 лет назад?
Александр Стихарёв: Три–пять лет назад ИТ и ИБ были скорее gatekeeper’ами — «привратниками», защищающими компанию от неподходящего ПО. Они, условно, «ставили галочку», что решение соответствует инфраструктурным требованиям и политикам безопасности, и на этом их участие в проекте заканчивалось. Сейчас все иначе.
По сути, ИТ и ИБ стали продукт-менеджерами для сотрудников. Их задача — не просто допустить внедрение, а обеспечить, чтобы сотрудники действительно пользовались системой, чтобы не образовывалось так называемое «теневое ИТ». Так бывает, когда, например, компания внедряет корпоративный чат, а люди все равно общаются в Telegram.
Еще одно важное изменение — компании стали тщательнее считать TCO (совокупную стоимость владения). Учитывать не только стоимость лицензий, но и стоимость обучения, сопровождения, обновлений, поддержки. ПО может стоить дешево, но потребовать найма трех дополнительных админов — и тогда речь пойдет совсем о других цифрах. Так что ИТ-директоры — это теперь еще и финансовые аналитики в каком-то смысле.
В целом, ответственности стало намного больше. Если ПО нестабильно, если есть риски по доступности или безопасности, если система не справляется с бизнес-задачами, отвечать придется ИТ и ИБ. Никто не хочет бегать ночами и тушить пожары, действовать нужно проактивно.
Так что CIO и CSIO сегодня — это полноценные участники бизнеса, разделяющие ответственность за его успех.
Почему замена западных решений чаще всего оказывается сложной не с технической, а с организационной точки зрения?
Александр Стихарёв: Технически заменить, скажем, Jira на Shtab — это вопрос, решение которого займет несколько часов. Максимум — пара недель, если нужны сложные интеграции или объем данных очень большой. А вот организация людей и процессов может длиться месяц и это хороший результат. Сила инерции в этом деле очень велика.
Во-первых, есть мышечная память. Люди привыкают к определенной логике интерфейса, к расположению кнопок, к последовательности действий. Новый инструмент требует адаптации, и первые недели сотрудник делает задачу не за минуту, а за две.
Во-вторых, есть страх ответственности. Поменять ПО — значит пересмотреть процессы, пересогласовывать регламенты, учить людей. И за это должен кто-то взять ответственность. В идеале — один человек. А это всегда риск.
Но действительный плюс нашего продукта в том, что он внедряется быстро, главное — управленческая воля. Все же российские продукты с точки зрения интерфейсов, с технической, в общем с любой, не уступают западным решениям.
Что мы делаем как вендор? Снижаем организационный стресс. Мы не только внедрили наш сервис для совместной работы, но и сделали совместную программу обучения, где участвовали эксперты с обеих сторон. У нас есть инструкции, видео, вебинары, индивидуальное обучение. И мы считаем это частью продукта — потому что «продать лицензию и забыть» — это не про наш бизнес.
Сейчас почти в любой ИТ-продукт включают ИИ. Где, на ваш взгляд, проходит граница между маркетинговым хайпом вокруг ИИ и реальной ценностью для руководителей?
Александр Стихарёв: Очень просто: граница — в P&L (отчете о прибылях и убытках). Если ИИ делает красивые презентации, которые не конвертируются в результат, — это хайп. Если ИИ снижает операционные расходы, ускоряет time-to-market, помогает избежать ошибок и простоев — это рабочий инструмент.
Мы в Shtab, например, оцениваем каждую AI-фичу с точки зрения экономии времени для конечного сотрудника. Не экономит — отправляется в конец очереди. Уходим от абстрактного «ИИ поможет вам быть креативными» к конкретному «ИИ сократит время онбординга сотрудника на 3 дня» или «снизит время на планирование спринта на 4 часа». От «Wow-эффекта» к измеримому ROI.
В Enterprise ценность ИИ особенно видна в обработке больших потоков данных и снижении влияния человеческого фактора: поиск узких мест в процессах, управление загрузкой сотрудников, прогнозирование срыва дедлайнов — все это в масштабах крупной компании помогает сэкономить миллионы рублей.
Какие функции в enterprise-среде ИИ действительно уже готов забирать на себя — без потери управляемости и контроля?
Александр Стихарёв: Сейчас мы активно реализуем и видим растущий спрос на проактивную аналитику проектов: AI подсвечивает узкие места, логические ошибки в планировании, перегруженных сотрудников или, наоборот, тех, кто остался без задач. Это анализ отклонений от статистической нормы.
Стандартные, но мощные кейсы — это переводы, суммаризация документов, семантический поиск по данным и инструкциям внутри продукта, поиск пересечений (например, где упоминается конкретный проект в разных задачах и документах). Отдельное направление — ассистенты для разработчиков: рефакторинг, код-ревью, поиск ошибок. ИИ работает как второй пилот. Он не должен выполнять задачи типа «скопируй этот сайт и создай мне второй Amazon. Но он может экономить человеку от двух до четырех часов в день — просто за счет рутины: преобразовать структуру данных, найти ошибку, переписать сложный фрагмент.
В безопасности — тоже много применений: аудит логов, поиск аномалий, выявление подозрительных событий.
Также ИИ здорово справляется с формированием базы знаний — помогает преодолеть «боязнь чистого листа» и составить четкие регламенты, проверить документы на логичность и полноту.
Как меняются требования к безопасности и изолированности AI-инструментов в условиях закрытых on-prem-контуров?
Александр Стихарёв: Enterprise требует: все внутри, только open source модели, обязательная проверка на уязвимости и инъекции. Вокруг модели должен быть выстроен строгий кордон, чтобы никакие чувствительные данные — персональные, коммерческие — никуда не ушли.
Типовая проблема: если обучить LLM на всех внутренних документах компании, она может выдать сотруднику то, к чему у него не должно быть доступа. И бог с ней, с зарплатой гендиректора — это всего лишь повод для сплетен. А вот если сотрудник получит доступ к базе клиентов, финансовым отчетам, аудиту безопасности — последствия могут быть гораздо хуже. Поэтому в Enterprise обязательны системы контроля доступа (RBAC), которые проверяют права пользователя на доступ к данным перед тем, как дать ответ.
Еще один из трендов — обфускация запросов «на лету»: ФИО заменяются на Иванова Ивана Ивановича, конкретные цифры — на абстрактные, но со сходной структурой. Модель обрабатывает обезличенный запрос, а в ответе данные подменяются обратно.
И, конечно, важно знать, на чем и как именно обучали модель, нет ли в ней вредоносных паттернов или скрытых предубеждений.
Почему для enterprise-заказчиков сегодня становится принципиальной готовность вендора показывать архитектуру и «внутренности» продукта?
Александр Стихарёв: Потому что приобретение корпоративного ПО — это не импульсивная покупка, как подписка на Netflix. Это больше похоже на брак по расчету с договором на 5-10 лет. Никто не хочет покупать черный ящик. Заказчику нужно понимать, что это за актив, как он устроен, что будет, если вендора купят или изменят стратегию, сменится политика или вектор развития. Риск зависимости от поставщика, так называемый vendor lock-in, для крупных компаний вполне реален, поэтому продукт оценивают не только с точки зрения функционала и стоимости «здесь и сейчас», но и в перспективе.
Классическая страшилка: внедрили ПО за рубль с пользователя, обучили 1000 сотрудников, а через год вендор говорит: «Теперь будет 5000 рублей с пользователя». Enterprise хочет разделить подобные риски с партнером. Прозрачность архитектуры — это вопрос доверия заказчика и вендора. Плюс есть bus-factor: если продукт может дорабатывать только технический директор, а завтра он уйдет — все остановится. Никому не нужен продукт, который завязан на одного человека.
Вот свежий пример из нашей практики: в кейсе с ЕДИНЫМ ЦУПИС решающим фактором для победы в тендере было именно то, что мы открыто показали архитектуру и объяснили, как она влияет на безопасность и развитие. И это то, что рынок начинает требовать все чаще.
Куда движется рынок collaboration-систем в России? Чего не хватает российскому ПО, чтобы превзойти Atlassian, а не просто скопировать его?
Александр Стихарёв: Одним словом — экосистемности. Atlassian — это не просто Jira и Confluence. Это армия партнеров-интеграторов, консультантов, методологов и огромное сообщество разработчиков, которые создают плагины и приложения на Marketplace.
В России рынок меньше, и такого сообщества пока нет. Идеальная модель: вендор разрабатывает ядро, а партнеры кастомизируют, внедряют и развивают экосистему вокруг. Это то, что предстоит построить.
Какие из трендов, которые мы обсудили, вы закладывали в архитектуру и стратегию Shtab изначально, а к каким пришлось адаптироваться по ходу развития продукта?
Александр Стихарёв: Изначально мы строили продукт вокруг удобства человека, с гибкостью «снизу вверх». Мы изначально не хотели навязывать определенную методологию типа Agile или Waterfall. Жизнь показала, что компании работают по-разному, и продукт должен быть максимально гибким. Именно такой мы и создаем: хотите Kanban — вот вам Kanban, хотите диаграмму Ганта — вот вам диаграмма Ганта, хотите простой список задач — пожалуйста.
Из трендов, к которым мы адаптировались, стоит назвать enterprise-требования к безопасности, конфиденциальности данных, работе в закрытых контурах. Огромную роль здесь сыграл проект с ФНС — именно он стал для нас эталонным кейсом на тему безопасности и архитектуры.
И, конечно, ИИ. Изначально его не было в нашей дорожной карте. Сейчас мы плотно интегрируем его как «второго пилота» — не замену человеку, а умного помощника, даже, пожалуй, «рабочего ангела-хранителя», который экономит время и снижает риск ошибок. Наша задача сейчас в том числе просветительская: обучать пользователей правильно формулировать запросы и обогащать их промпты контекстом из данных внутри системы.
Какой опыт внедрений Shtab в крупных организациях больше всего повлиял на ваше понимание того, каким должен быть современный инструмент совместной работы?
Александр Стихарёв: Каждое внедрение приносит уникальный опыт. Запуск в ЕДИНОМ ЦУПИС (финтех в регулируемой индустрии развлечений) — пример работы в высоконагруженной среде с банковской тайной. Это драйвер для развития функций безопасности и compliance. Кингисеппский машиностроительный завод (КМЗ) — жесткое производство с точным планированием. Это кейс про строгие сроки, учет ресурсов и дисциплину задач. ФНС Якутии (госсектор) — совсем другие процессы и требования к документообороту и отчетности.
В этих проектах мы поняли важную вещь: один и тот же результат можно достигать совершенно разными путями, и инструмент должен давать такую свободу. Например, постановка задачи может быть реализована и в виде короткого комментария, и как детально описанное техзадание с приложением соответствующих инструкций. Хороший инструмент минимизирует необходимость в «чайка-менеджменте» — постоянных уточнениях «ну как дела по моей задаче?» Все статусы и блокеры должны быть видны в системе, что позволяет менеджеру подключаться и конструктивно помогать, когда действительно требуется помощь.
Резюмируя нашу беседу: на рынке сейчас десятки трекеров. Если бы у вас было 30 секунд в лифте с ИТ-директором крупной корпорации, какие три главных аргумента в пользу Shtab вы бы привели?
Александр Стихарёв: Первое — мы связываем стратегию и тактику в единый контур. Часто бывает так: глобальные цели компании живут в красивых презентациях топ-менеджмента, а реальная работа — где-то между задач и обсуждений, эти миры не пересекаются. В Shtab мы реализовали методологию OKR (Objectives and Key Results). Каждый сотрудник видит, как его конкретная задача влияет на цель отдела и всей компании. Это дает совершенно другой уровень вовлеченности и прозрачности. А компания растет и движется в едином направлении.
Второе — это тотальная гибкость и управление знаниями. Мы не навязываем жесткую логику «как надо работать». Shtab — как конструктор. Можно отключить все лишнее, настроить визуализацию проектов под себя и вести дела так, как привыкла именно ваша команда. Более того, мы убрали барьер между «работой» и «знаниями». Документы, регламенты и страницы создаются прямо в сервисе. Вам не нужно бегать между разными приложениями и платить за каждое.
И третье — мы не бросаем клиента наедине с софтом. Мы понимаем, что внедрение — это стресс, поэтому предлагаем полноценное партнерство: помогаем с обучением, настройкой и адаптацией. Готовим короткие и понятные инструкции, делимся лучшей практикой. Мы не отгружаем просто лицензии. Наша цель — полностью внедренное решение, которое делает людей продуктивнее, а бизнесу дает ощутимый возврат инвестиций.
