Илья Красинский и Дмитрий Сергеев о том, как создать и поддерживать культуру работы в распределенной команде

Как и всем в сложившихся обстоятельствах, нам в Carrot quest пришлось перейти на удаленную работу и вынужденно стать распределенной командой. У нас было много процессов, которые позволили нам быстро перестроиться, но коммуникация стала не такой эффективной — у нас было мало опыта дистанционного общения друг с другом.

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

Илья Красинский — CEO и основатель сервиса сквозной аналитики с роботом-аналитиком Rick.ai, сооснователь Uncrn.me и автор продуктового курса Product Heroes, методолог ФРИИ. Пообщался с Ильей наш CEO & founder Дмитрий Сергеев.

Ключевое отличие remote-компаний в том, что без некоторых ритуалов и процессов в командах они не могут работать совсем или работают неэффективно. Мы собрали ключевые правила организации командной работы на удалёнке и подробно описали конкретные ритуалы, которые помогают поддерживать рабочий процесс в удаленном режиме.

Для всех проблем, которые у нас возникли, нашлись проверенные командами Rick.ai и Uncrn.me решения. Мы с удовольствием попробовали их на себе и расскажем, как нам это понравилось, и покажем кейсы, как применяем эти принципы.

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

Вариантов решения много. И задача может решаться в разы быстрее и лучше.

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

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

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

Помимо этого при постановке задачи стоит визуализировать и проектировать результат.

Сделайте проект того документа, в котором вы хотите получить результат: создайте сами все нужные страницы, строки и столбцы.

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

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

Гипотетический пример: задача для аналитика — посчитать, сколько в нашей базе пользователей потенциальных пользователей SDK.

Аналитик, который умеет отличать бракованные задачи, спрашивает, кто и что потом будет с этими данными делать. И уже в момент постановки задачи выясняются важные детали: нужна не одна табличка, а две. Потому что продакту, которому аналитик должен «доставить», то есть передать дальше для использования в работе, результаты этой задачи, нужно не только число пользователей, но и список этих пользователей с контактами. Смысл задачи кардинально меняется.

Еще пример — эта статья. Она должна была стать подкастом. Как этот, в котором Аня, Илья и Дима обсуждают самоорганизацию и шутят про бомжей и красных лидеров. Или этот — про work-life balance, утят, цикличность, Шостаковича и Маркса. Но не стала из-за качества записи. Следующая итерация — первый вариант текста. Еще одна — после редактуры текста. Еще одна — после внутреннего согласования. Еще одна — после внешнего согласования. Множество итераций. Старайтесь учитывать количество возможных итераций при планировании.

Что поможет остановить множащиеся переписки такого рода? Прозрачность всех процессов. Регулярно синхронизируйтесь — и устно, и письменно.

На уровне компании:

У нас в Carrot quest был целый ряд командных ритуалов, которые мы сейчас успешно перевели в онлайн и которые здорово нас выручают:

Опыт команд Rick.ai и Uncrn.me тоже подтверждает важность ритуалов на всю команду.

На уровне команд:

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

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

Важная часть daily-митингов — обсуждение возможных проблем и блоков:

Сейчас у каждой команды в Carrot quest есть ежедневные утренние стендапы. Мы стараемся проводить их в одно и то же время — так они легко встраиваются в рабочий день каждого участника команды. Например, стендапы команды маркетинга начинаются ежедневно в 10:15.

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

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

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

Большинство описанных выше ритуалов были у команды Carrot quest давно. Но даже их оказалось недостаточно в условиях, когда мы не видим друг друга постоянно. Поэтому мы добавили:

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

Важный бонус письменных daily: они сокращают время стендапа (привет всем, кто тоже устал от видеосвязи!) Потому что на стендапах обсуждаются только спорные моменты и возможные проблемы.

Чтобы этого избежать, замените «сделать» на «доставить». Со словом «доставил» проще: либо доставил, либо нет. Если задача все еще у тебя, значит, она не завершена.

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

Мы уже применяем эти принципы при создании каналов. К примеру, из таких каналов у нас есть:

Для сообщений в каналы нужны регламенты и правила. О них — ниже.

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

Правильно формулировать запросы, в том числе срочные, помогает теория Jobs to be Done. Сделайте JTBD обязательным к изучению в компании. Мы уже описывали этот подход в теории и рассказывали, как применять его на практике. Job stories — это универсальный фреймворк для постановки задач. Его применяют и команды Ильи Красинского, и наша команда. Он помогает изучить контекст, в котором находится пользователь/заказчик задачи и точно описать ситуацию и необходимую “работу”. То есть позволяет придумать решение именно для этой “работы” именно в этом контексте.

Это фреймворк универсален, но особенно круто работает, когда с проблемой связана паника. Как научить всех его применять? Разработайте правила, регламентирующие, как надо писать о проблемах и багах, и запиньте их.

Наши тестировщики, например, разработали целый гайд для описания багов.

Используйте слово-триггер: например, слово «когда» отлично помогает описывать ситуацию.

Есть такие задачки, которые мы делаем каждый день. Они вроде простые, но все вместе отнимают много времени. И много внутренних ресурсов мы тратим на то, чтобы про них не забыть. Вот такие задачки стоит по возможности автоматизировать. Тут на помощь придут боты и интеграции.

Боты напоминают нам о встречах и о том, что к ним нужно готовиться:

И даже проверяют, какое настроение у команды:

Бот запускал опрос в Slack каждый день в 10:05 с тремя вариантами ответов: «Я жив-здоров, работаю из дома», «Болею», «Я в офисе». Этот простенький механизм придавал определенности. Благодаря стендапам определенность была внутри команды, благодаря боту — между разными командами: мы понимали, на чью помощь можно рассчитывать. Когда реакции на него стали выглядеть так:

стало понятно, что ему пора эволюционировать. И он превратился в бота-проверяльщика настроения.

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

Хорошая штука — интеграции. Они экономят время на переходы и копирование информации вручную.

Вот несколько интеграций Slack, которыми мы пользуемся, чтобы упростить коммуникацию внутри команды:

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

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

Раз. Два. Готово.

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

Учитесь управлять своими привычками и привычками команды. Сделайте себе рабочую зону. Оборудуйте место так, чтобы не хотелось прилечь, развлечься, перекусить. Окружите себя тем, что не отвлекает вас. И никогда не работайте в кровати.

Примечание: Чтобы понять, как решение что-то сделать превращается в автоматизм, советуем прочитать книгу Чарльза Дахигга «Власть привычки».