Я управляю командой удаленно с 2014 года. Вот мои 8 советов за 12 лет опыта.
Привет! Меня зовут Кирилл Гришанин, я CEO команды WB—Tech.
Мы тут решили сравнить свой опыт с тем, что говорят коллеги, эксперты и ребята в отзывах на IT-площадках. Собрали актуальные боли удаленного управления и, главное, рекомендации — как это все починить. Ресерчем делюсь с вами.
Сразу спойлер: несмотря на общую схожесть, у нас и «у них» (за рубежом) проблемы разные. В российском remote-IT чаще всего «ломается» координация: где живет контекст, кто владеет данными и как это юридически прикрыть. А зарубежные команды больше страдают от «тонких материй»: нет доверия, цели размыты, нарушен баланс work-life.
Но давайте к делу.
Коммуникация расползается по чатам, почте и созвонам
Почта — долго и спам. Звонки — неудобно, и потом не вспомнишь, о чем договорились. Мессенджеры вообще исторически заходили в бизнес как побочный инструмент.
В итоге — хаос. Решения и файлы летают где-то вне управляемого контура. Плюс импортозамещение, когда привычные Slack/Zoom/Mattermost отваливаются, и «склейка» процессов вообще становится квестом. Особенно больно бывает на масштабе. Попробуйте стандартизировать каналы и роли, когда у вас сотня человек в разнобойных чатиках.
Как лечить? Вы слышали про SSOT (Single Source of Truth) — «единый источник истины», концепцию единой базы, в которой команда хранит и обновляет актуальную версию диалогов, документов и резолюций, чтобы не спорить о «правильной» версии?
Звучит пафосно, но суть проста: решения и статусы живут в задачах и доках. Договорились в чате? Ок, но если это не перенесено в таск-трекер — этого не было. Иначе команда неизбежно начинает дергать друг друга: «А где файл?», «А мы что решили?».
Чтобы это заработало, нужно добавить два слоя:
- Краткий «регламент коммуникаций» (какие темы решаем асинхронно, какие — только общим сбором, и что считать результатом обсуждения).
- Централизованное управление чатами и доступами в корпоративном мессенджере — с ролями и политиками, чтобы доступы отзывались предсказуемо и без ручного «вылавливания» людей по группам.
Да, потребуется дисциплина. Да, поначалу будет скрипеть и плакать. Но рано или поздно люди поймут, что порядок экономит их же время. (Ну, или не поймут, но работать станет легче, гарантирую).
Митап, который мог быть письмом (и должен был им стать)
Обилие митапов создает шум. Контекст приходится каждый раз поднимать заново, пересказывать. Смысл тонет в пересланных сообщениях и устных «окей». Зачем собираться, если после встречи вы продолжаете «дожимать» друг друга в личке?
Мы возвращаем фокус через «гигиену процесса»:
- No agenda, no attenda. Нет повестки — нет встречи. У любого собрания должен быть документальный артефакт: заметки или решение.
- Письменно > Устно. Все, что можно решить текстом — решаем текстом, без романтического рандеву.
- Контекст — король. Если задачу нельзя понять без очного диалога — значит, она плохо описана, контекста в теме недостаточно, это создает зависимости (а, значит, проблемы) в процессе.
- Задача без владельца, он же DRI (Directly Responsible Individual — «конкретный ответственный»), не считается завершенной (и, даже, задачей), так как «висит в воздухе» и множит сущности.
- Явный handoff. Передаешь работу? Зафиксируй: что, кому, когда и где это записано. Иначе не жалуйся!
И про планирование. На удаленке оно регулярно спотыкается о «невидимую загрузку» и параллельные проекты. Чтобы не назначать задачи вслепую, сопоставляйте спрос с реальной емкостью членов команды. Иначе придется регулярно звонить в колокол и трубить общий сбор, чтобы найти крайнего.
Метрики вроде есть, а общего языка нет
Размытые метрики — частая причина конфликтов. Классический пример — MTTR: Atlassian в своем руководстве специально делает фокус — R может быть чем угодно: Repair, Recovery, Respond, Resolve.
Использовать этот показатель по наитию, без явной договоренности — готовый повод для скандала. Попробуй обоснуй оставшимся без премии коллегам, на какое среднее время — ремонта, восстановления, реагирования или решения ты опирался, когда игнорировал сигналы тревоги от упавшей системы.
- MTTR (Mean Time to Restore/Resolve/Repair) — среднее время, за которое команда возвращает сервис или процесс в норму после сбоя/инцидента. В разных командах R трактуют по‑разному: ремонт, восстановление, реагирование. Соответственно, результат также может быть разным.
Что делать? Зафиксируйте «контракт метрики».
- Что измеряем?
- Где старт, где финиш (статусы/события)?
- Режим времени (24/7 или рабочие часы)?
- Откуда берем данные/таймстемпы?
А дальше смотрите на универсальные метрики потока, они одинаково подходят хоть для кода, хоть для договора, хоть для запуска кампании:
- Throughput — сколько единиц работы завершили за период.
- Cycle time — сколько задача была «в работе» от старта до финиша.
- WIP — сколько задач делается одновременно (спойлер: чем меньше, тем лучше).
- Work item age — сколько времени висит текущая задача.
Или придумайте и ориентируйтесь на свои показатели: суть не в них, суть — в одинаковой инструментальной оценке процессов.
Внутренний контур VS риски ИБ и комплаенса
Из-за «расползания» коммуникаций по личным чатам страдает безопасность. В публичном мессенджере рабочие файлы остаются на личных устройствах. Документы утекают за пределы контура, и: привет — фишинг, кража аккаунтов и прочие радости.
В РФ к привычным рискам удаленки добавляется еще два фактора:
- Регуляторика по данным и инфраструктуре.
- Зависимость от зарубежных вендоров.
В итоге имеем типичный сценарий: сначала из-за ухода зарубежного сервиса в компании ломаются отделы — от продакта до бухгалтерии, затем ваши секреты попадают к злоумышленникам, а в конце приходит теплый, родной Роскомнадзор (ни к ночи будет упомянут) с претензией к обращению с 152‑ФЗ «О персональных данных». Оно вам надо?
Единственный способ спать относительно спокойно, имея сеть удаленных сотрудников, — сделать корпоративный мессенджер рабочей средой. С администрированием, правилами и правами. А личные чаты оставить — для мемов и котиков. Если же стабильность не просто важна, а критична, у вас не остается выбора — разворачивайте ПО on-premise (внутри своей сети) и работайте автономно.
Да, лайфхак: включите единый вход (SSO, Single Sign‑On — одна корпоративная учетка для входа) и привязывайте доступ к коммуникациям и корпоративному каталогу, чтобы «украли пароль» не означало «украли компанию».
Это не отменяет дисциплину, но делает РКН — мемным персонажем, а не извещением о возбуждении дела в почтовом ящике.
Удаленка и Трудовой кодекс: квест на ровном месте
Юридическая чистота удаленки — это то, на что многие машут рукой: мол, давайте пока поработаем из дома, а потом разберемся. Вот только эта расслабленность вылезает боком при первом же споре о деньгах и ответственности.
Кто кому что обещал? Где это написано?
Потом HR в истерике собирает договор по скриншотам из Телеграма. И да, обычно это случается не в спокойной обстановке, а когда уже случилось увольнение или проверка.
Три главные ловушки удаленного найма:
- Не определен вид дистанционки. По ТК РФ дистанционная работа может быть постоянной, временной (не больше 6 месяцев) или «смешанной» (часть с дивана, часть — в офисе), и это условие нужно фиксировать в договоре/допсоглашении. Отдельно существует экстренный временный перевод по ст. 312.9 ТК РФ: в ряде исключительных случаев работодатель может перевести на дистанционку без согласия работника, но это именно «аварийный режим», а не способ тихо «переселить» команду на удаленку навсегда.
- Кадровый документооборот не настроен под удаленку: часть документов на бумаге, часть — в email, часть — Telegram-чате. Решение же проще, чем кажется: вы либо официально включаете людей в КЭДО по правилам статей 22.1–22.3 ТК РФ, либо (и это часто удобнее) выстраиваете электронное взаимодействие именно как с дистанционными работниками по ст. 312.1–312.3 ТК РФ — и тогда можно не «поднимать» весь КЭДО на компанию сразу. Нужно только помнить базовую вещь: включение дистанционных работников в КЭДО — это право, а не обязанность работодателя, и от выбранной схемы реально зависят документы, согласия и регламенты.
- Электронные подписи и согласия: технически «подписали», юридически — «не подписали». В материалах по практике ЭДО для дистанционных сотрудников прямо отмечают, что для ПЭП (простой электронной подписи) и УНЭП (усиленной неквалифицированной электронной подписи) нужно предварительное письменное согласие между сторонами, а вот УКЭП (усиленная квалифицированная электронная подпись) отдельного согласия не требует. Поэтому рабочая практика такая: для критичных кадровых событий (прием/изменения/расторжение) заранее выбираете понятную модель подписи и закрепляете ее в трудовом договоре или допсоглашении, а не выясняете «какой подписью мы вообще пользуемся» в день конфликта.
Ваш HR не станет счастливым автоматически, но это резко снизит шанс, что удаленка закончится грустной музыкой.
Заключение
Парадокс удаленки в том, что она одновременно проще и сложнее: проще — потому что меньше «шума офиса» и больше свободы, сложнее — потому что любая тонкая нить в процессах обязательно превратится в обрыв контекста и доверия.
Выше мы долго наводили порядок в инструментах, правилах и артефактах — и это важно, потому что удаленка любит «письменные следы» и прозрачность. Но есть баг, который не фиксится регламентом.Пока вы строите SSOT и режете митинги, люди начинают чувствовать себя лишними. Второсортными по сравнению с теми, кто пьет чай с печеньками в офисе и тягает домой канцелярские скрепки.
Поэтому финальный аккорд будет не про систему, а про человеческое:
- выравнивайте доступ к контексту (remote‑first — важное фиксируем так, чтобы это увидели все);
- держите регулярный «ритм» коротких контактов — общайтесь с удаленщиками чаще;
- контроль ≠ микроменеджмент, не душите людей.
Иначе вместо скорости вы получите тревожность и пассивную агрессию в комментариях к задачам. Добавьте немного «клея» — неформальные включения, благодарность и регулярную обратную связь — и удаленка перестанет быть вечным компромиссом: один раз настроили правила и культуру, а дальше благодарная система сама вынесет вас к вершинам успеха!
Больше мыслей про управление, эффективность и цифры — в канале WB Tech. Заходите, там интересно.