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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• еженедельные митинги разных форматов, на которых выступают разные команды.

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

• еженедельное утреннее демо по понедельникам в 10:00, где Дима Сергеев коротко рассказывает о ситуации и планах на неделю и вдохновляет команду на подвиги;
• демо продукта по понедельникам в 17:00 — раз в две недели, по окончании спринта. На нем продакты, разработчики и дизайнеры рассказывают, над чем работают и что пойдет в релиз в ближайшее время;

• «рыбный четверг» раз в неделю в 18:00. Раньше по четвергам раз в месяц выступала каждая из команд — продукт, поддержка, маркетинг, продажи, команда Dashly. Сейчас на этих митингах мы сводим воедино информацию «с передовой» — от продаж, поддержки и всех, кто общается с клиентами и партнерами — о том, что происходит на рынке.

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

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

• Daily-митинги

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

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

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

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

• Weekly-митинги для подведения итогов и планирования

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

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

• Если две команды плотно работают между собой — им нужны дополнительные ритуалы. В этом случае тимлидам, например, стоит подключаться к daily-митингам смежных команд.

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

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

• письменное фиксирование планов команды на неделю — Weekly — в открытом для других команд источнике (канал #weekly в Slack, страница в Notion, Favro);

• канал, где мы рассказываем друг другу о больших и важных успехах за неделю — и командных, и личных — #fantastic-friday;

• письменное фиксирование планов на день — daily. Мы ввели эту практику по совету Ильи. Формат сообщений: что доставил, что в процессе, что делаю, что планирую. По понедельникам первым пунктом идут планы на неделю:

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

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

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

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

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

• Все должны соблюдать правила: например, в канал для коридорных тестов писать только про коридорные тесты.

• Учите новичков правильно пользоваться всеми каналами, это окупается:

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

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

• #marketing — для переадресации всех внешних запросов о партнерстве, обсуждения вдохновляющих проектов, рекламных кампаний конкурентов и т. д.
• #success-support — для синхронизации действий ребят из поддержки, внедрения и продаж в отношении клиентов;
• #bugs — для сообщений о багах и проблемах в работе сервиса;
• #clients-hard-truth — для пожеланий по изменениям в сервисе
• и другие.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• c Zoom:

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

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

• с productboard — туда можно добавлять в виде заметок сообщения из канала #clients-hard-truth. Это делается всего в пару шагов:

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

• с Google Docs — она облегчает работу над текстами:

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

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

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

• Команда — это люди, объединенные одной целью. Есть команда — формулируйте цель.
• Цель требует планирования. Выделяйте время на недельное планирование.
• Синхронизироваться нужно постоянно. Задача все время доуточняется: чем больше мы работаем над ней, тем лучше ее понимаем.
• Daily-митинги — для синхронизации по задачам. Проводить в одно и то же время, чтобы не договариваться каждый раз.
• Планы на день фиксируются текстом до звонка. Должно быть понятно, кто и что получит в результате проделанной другими работы.
• На стендапах обсуждаются блокеры.
• Задачи надо правильно ставить. Для этого применяйте Jobs to be Done.
• Слово «доставить» исключает путаницу между «делаю» и «сделал»: задача закончена только тогда, когда вы ее кому-то передали.
• Важное правило передачи задач: написать в чат не значит доставить. Другой человек должен отреагировать и принять задачу, подтвердить, что она не бракована.
• Промежуточные результаты тоже нужно показывать команде.
• Создавайте культ итогового результата. В любом запросе должен быть итоговый результат — лучше всего картинкой, чтобы на выходе можно было две картинки сравнить.