Подул вирус и мир сильно изменился. Слово «удаленка» во многих компаниях из далекой мифической абстракции превратилось в реальность. Реальность иногда милую, а иногда уродливую и странную. Особенно в России. В статье я описываю управленческие принципы, позволяющие эффективно организовать работу удаленную работу команды.
В штатах удаленная работа уже очень давно не диковинка. Году так аж 2003 наш РП на одном из митингов во время обязательного вступительного small talk проговорился, что сидит в своем доме в Калифорнии в одних трусах. Потом ему это несколько месяцев припоминали, а я сам, находясь on site в славном штате Айова, стал свидетелем живой невербальной реакции «бизнеса» на такое откровение. Все это безобразие происходило не с гаражным стартапом, а между вполне солидными компаниями. РП был от IBM, проект для одного из крупнейших штатовских банков.
Я же был со стороны разработки, сейчас бы меня назвали техническим руководителем проекта, или тимлидом, или архитектором. Как назвать не важно, главное то, что разработка также велась распределенной командой из Москвы, Минска, и тех же штатов, даже были ребята из Египта. Разные часовые пояса, разный язык, менталитет. Но все прекрасно работало!
С того момента много воды утекло, но так получалось, что весь мой опыт был связан именно с организацией работ удаленных команд. Долгое время я сотрудничал с компанией Vega ECM Solutions, чьей особенностью было выполнение проектов территориально распределенными командами, где все сотрудники работали из дома. Даже когда компания открыла очень приличный офис в Irvine CA, он чаще всего был пустым и выполнял скорее представительскую функцию. Люди предпочитали работать из дома, а руководство этому не препятствовало. А зачем, когда все хорошо и эффективно работает?
Кто-то скажет, «ну это же американская компания, у нас по-другому». Отнюдь. Принципы управления удаленной разработкой работают одинаково везде. Действуют одинаково на американцев, индусов, россиян, украинцев и египтян. В российской компании «Логика Бизнеса» было несколько территориально-расположенных офисов и продуктовые команды формировались из сотрудников из разных офисов. Кто-то сидел в офисе в Москве, кто-то в Уфе, кто-то в Красноярске. Несколько человек работали из дома. Все прекрасно работало благодаря тем же принципам, о которых дальше.
Наблюдая же то, что зачастую происходило в некоторых, весьма крупных, российских компаниях этим летом, часто возникал вопрос — что не так? Почему плавают коммуникации, почему продвижение по бэклогу стало медленнее, как вообще что-то сделать? На каждый из этих вопросов есть конкретные ответ, но общий корень, питательная среда из которой произрастают все эти проблемы — очень низкий уровень менеджмента. Его не системность, не регулярность и реактивность. Вынужденная удаленка в некоторых компания стала тем самым ребенком из известной сказки. А король-то голый…
Чтобы удаленная работа была не злом, а эффективным, практичным способом совместной деятельности многого не требуется. Надо просто организовывать процесс, используя простые, очевидные механизмы. Управлять, а не пускать все на самотек, прикрываясь мантрами про «самоорганизацию». Принципы ниже про удаленку, но разве только про нее?
Принцип очевидный, примерно такой-же, как необходимость мыть руки. Однако, как руки моют далеко не все и не всегда. До сих пор в некоторых компаниях какое-то число задач проходит мимо трекера. Или задачи как-бы в трекере, но не всегда соответствуют тому, что реально делается. Если при офисной работе это еще как-то допустимо — все на виду, то при удаленке трекинг всех значимых задач обязателен. Что-такое «значимая задача» определяется эмпирически. Мой критерий — «любая задача, которая не может быть сделана за 15 минут». При этом с таймером стоять не надо. Если на какую-то консультацию, разбор ошибки и т.д. вдруг потребуется не 15, а 16 минут, или даже 17, то она вполне может не попасть в трекер, при условии, если таких задач немного. Аналогично и в другую сторону. Если на задачу требуется 5 минут, но за эти 5 минут разработчик делает изменение в коде, то такую задачу нужно зарегистрировать. Иначе как вы через год определите, зачем это вдруг поменяли вот эту строчку кода?
Какой трекер использовать? Ответ — любой, к которому привыкли и который удобен. Мои команды работали с жирой. Редмайн также вполне подойдет. Да даже и Trello.
Но…
Представьте себе, что вы работаете в организации, где трекер жестко мониторится. Рассчитываются разные и множественные показатели эффективности и еще кто-то точно знает чего. По этим показателям проводятся совещания, строятся отчеты, стукают по головам линейных руководителей за отклонения. В общем, делается много важной и полезной работы.
Можно ли в таких условиях организовать нормальный трекинг задач? Ответ — нет. Любой неосторожный шаг может привести к нарушению метрики, а мы же хотим просто работать, планировать, делать жизнь проще…
А если получается наоборот — все очень сложно, то простая и хорошая идея работать по трекеру ломается. Конечно, команда что-то трекает, но в минимальном объеме, чтобы отчеты не испортить…
Вредная мысль… А что если реальный рабочий трекинг вести в альтернативной системе? Trello, например.
По этой теме в сообществе давно идут ожесточенные споры и у меня нет никакого желания абстрактно рассуждать на тему «хорошо»\«плохо». Описываю то, что работает и целесообразно.
В соответствии с Принципом 1 «Работать строго по задачам в трекере», все задачи у нас отслеживаются. В конце рабочего дня каждый сотрудник вспоминает какие задачи он сегодня выполнял и вносит в них затраченное время с коротким описанием сделанного. Описание вполне может быть «много думал». Для того, чтобы списать время на «незначительные задачи», можно завести отдельную задачу — условную «свалку». Понятно, что туда должно улетать немного рабочего времени, так как задачи «незначительные». По таким задачам также необходимо описание того, на что было потрачено время. Например, «консультация Анжелы». Кстати, если вы видите, что в задачу «свалку» пишется много времени, то это звоночек о том, что что-то идет не так и с этим надо что-то делать. Работа руководителя в том и состоит, чтобы слышать «звоночки» и предпринимать действия, чтобы выправить ситуацию.
Итак, все рабочее время учитывается, и его сумма должна получиться 8 часов в день. Или 40 часов в неделю. Правильнее обращать внимание именно на недельный баланс, чем на дневной. Это нормально, когда живые люди иногда работают больше, иногда меньше. Разные ситуации бывают, да и работоспособность наша совсем так равномерна, как предусматривается табелями учета рабочего времени.
В отличие от принципа «Работать строго по задачам в трекере» внедрить принцип ежедневного учета обычно намного сложнее. Важно именно то, чтобы люди списывали свое время ежедневно, а не в конце недели, месяца или когда прилетит пинок от руководителя. Нужно понимать, что принцип учета времени выводит человека из зоны внутреннего комфорта, это вызывает внутренне сопротивление и именно поэтому, он обеспечивает эффективность удаленной работы.
Для внедрения любого начинания требуется сначала его разъяснить, а потом, особенно на первом этапе, регулярно контролировать исполнение и обеспечивать выполнение правила. Неотвратимость намного более эффективна, чем жесткое, но случайное, наказание за невыполнение.
Внедряя принцип учета времени во многих командах, я всегда слышал один и тот же вопрос-утверждение в разных творческих вариантах "мы теперь вместо разработки будем все время тратить на списание времени". Вполне может быть. Вы имеете полное право учесть время, затраченное на списание во времени выполнения задачи. Легко посчитать… сколько времени требуется на то, чтобы залезть в жиру, найти задачу, прикинуть сколько времени заняла задача, что делалось и вписать несколько цифр и пару фраз? Пусть 5 минут. Разработчик редко работает более, чем над 5 задачами в день. Итого, в худшем случае на списание времени будет потрачено 25 минут. Компания может себе это позволить.
Другое частое возражение "а откуда я знаю. сколько времени я потратил?". Ответ — секундомер не нужен. Вносить надо время по вашей оценке в конце дня. Как и в любой оценке ошибки допустимы.
Фишка принципа учета рабочего времени состоит в том, что заставляет каждого игрока в команде проводить ежедневный индивидуальный «ретро». Ведь нужно вспомнить, что делал. Понять получилось или нет, сколько и на что ушло времени. Информация по списаниям открыта руководителю, команде, поэтому писать неадекват не получится. Просто стыдно. Понимание того, что в конце дня нужно будет выполнить процедуру отчетности по времени является очень хорошим средством отлени прокрастинации. В условиях удаленки, где действует огромное число отвлекающих факторов, очень важна самодисциплина и принцип «Ежедневный отчет по затраченному времени» является очень хорошим помощником в этом непростом деле.
Как делать не надо...
Вводя любую новацию нужно самому быть уверенным в ее пользе. Подход — а все так делают, а пришло указание «сверху» убивает идею. Если нет внутренней убежденности в необходимости использовании какого-то управленческого инструмента лучше от него отказаться, чем передавать свою неуверенность и сомнения команде.
Коммуникации в команде, работающей на удаленке очень важны. Каждый должен быть в курсе того, что происходит на проекте, какие есть внешние изменения, кто с какими проблемами сталкивается, когда ожидать завершения задач и т.д. Важно понимать и ощущать, что мы команда, что все в одном контексте, есть общее понимание не только целей, но и того, где мы сейчас находимся. Пусть даже в месте темном и неприятном…
Я назвал такие регулярные митинги команды «планерками», а не скрамовскими дэйли вполне осознанно. Скрам это одна из методологий, эффективная в одних ситуациях, но совсем неприменимая в других. Натягивать скрам на все живое — затея странная и непонятная.
Поэтому именно "планерки", хотя по смыслу и формату они и напоминают дэйли. Обсуждаем статус, вводные. Объемные вопросы переносим в отдельные совещания. Длительность рекомендую ограничивать 15-30 минутами. Оптимальная периодичность в спокойное время — 2-3 планерки в неделю, в горячий период — раз в день.
При проведении планерок важна регулярность. Лучше сразу добавить их в календарь всей команды. И о календаре. На удаленке это обязательный инструмент управления и своим временем и временем команды. Признак уважения. Мне нужно обсудить что-то важное, но я уважаю тебя, твои планы, поэтому заранее приглашаю на встречу. Если предложенное время неудобно, можем перенести. Если есть предварительные вопросы о целях встречи — можешь задать, равно как и отказаться от встречи.
Когда вся команда работает в одном офисе постоянно возникают спонтанные коммуникации. Около кофемашины, на кухне, кто-то кого-то зацепил в коридоре на несколько слов. В режиме удаленной работы такой роскоши нет. Есть только мессенджеры, телефон. Люди же разные, в ИТ чаще интровертные, поэтому может возникнуть ситуация при которой кто-то из сотрудников «потеряется», разорвется межличностная коммуникация, очень важная не только для достижения результатов, но и для социализации сотрудников. Мы же люди и хотим общаться, даже заядлые интроверты.
Помочь здесь могут «спонтанные», полуформальные коммуникации, когда тимлид обсуждает какой-либо вопрос 1х1 с сотрудником. Вопрос может быть организационным, может быть техническим. Важнее то, что тимлид периодически инициирует диалог с каждым. Лучше всего голосом, но в каких-то ситуациях могут быть и текстовые сообщения. Голосом намного лучше! Это не должно происходить по-расписанию, и хорошо придерживаться средней частоты таких встреч не менее 2-х раз в неделю.
Этот принцип исходит из старого, доброго оффлайн навыка хорошего руководителя — общаться с сотрудниками, уделять им внимание. В оффлайне такие коммуникации возникают естественно, сами-собой. В режиме же удаленной работы их нужно специально инициировать. Не забывать про людей.
Я описал четыре базовых принципа удаленной работы позволяют сделать ее продуктивной, эффективной и комфортной для сотрудников. Такой, что не требует возвращения в офис, что само по себе экономически выгодно для компании. Конечно, этими принципами компетенции руководителя не ограничиваются, но следование им, таким простым, уже может поразительно изменить отношение к удаленной работе. Мы закрываем основные управленческие обязанности — трекинг задач обеспечивает планирование, контроль, делегирование. Планерки и встречи 1 на 1 создают единое информационное поле. Возникающие вопросы либо оперативно решаются, либо добавляются в трекер для приоритизации.
Ничего же сложного.
В штатах удаленная работа уже очень давно не диковинка. Году так аж 2003 наш РП на одном из митингов во время обязательного вступительного small talk проговорился, что сидит в своем доме в Калифорнии в одних трусах. Потом ему это несколько месяцев припоминали, а я сам, находясь on site в славном штате Айова, стал свидетелем живой невербальной реакции «бизнеса» на такое откровение. Все это безобразие происходило не с гаражным стартапом, а между вполне солидными компаниями. РП был от IBM, проект для одного из крупнейших штатовских банков.
Я же был со стороны разработки, сейчас бы меня назвали техническим руководителем проекта, или тимлидом, или архитектором. Как назвать не важно, главное то, что разработка также велась распределенной командой из Москвы, Минска, и тех же штатов, даже были ребята из Египта. Разные часовые пояса, разный язык, менталитет. Но все прекрасно работало!
С того момента много воды утекло, но так получалось, что весь мой опыт был связан именно с организацией работ удаленных команд. Долгое время я сотрудничал с компанией Vega ECM Solutions, чьей особенностью было выполнение проектов территориально распределенными командами, где все сотрудники работали из дома. Даже когда компания открыла очень приличный офис в Irvine CA, он чаще всего был пустым и выполнял скорее представительскую функцию. Люди предпочитали работать из дома, а руководство этому не препятствовало. А зачем, когда все хорошо и эффективно работает?
Кто-то скажет, «ну это же американская компания, у нас по-другому». Отнюдь. Принципы управления удаленной разработкой работают одинаково везде. Действуют одинаково на американцев, индусов, россиян, украинцев и египтян. В российской компании «Логика Бизнеса» было несколько территориально-расположенных офисов и продуктовые команды формировались из сотрудников из разных офисов. Кто-то сидел в офисе в Москве, кто-то в Уфе, кто-то в Красноярске. Несколько человек работали из дома. Все прекрасно работало благодаря тем же принципам, о которых дальше.
Наблюдая же то, что зачастую происходило в некоторых, весьма крупных, российских компаниях этим летом, часто возникал вопрос — что не так? Почему плавают коммуникации, почему продвижение по бэклогу стало медленнее, как вообще что-то сделать? На каждый из этих вопросов есть конкретные ответ, но общий корень, питательная среда из которой произрастают все эти проблемы — очень низкий уровень менеджмента. Его не системность, не регулярность и реактивность. Вынужденная удаленка в некоторых компания стала тем самым ребенком из известной сказки. А король-то голый…
Чтобы удаленная работа была не злом, а эффективным, практичным способом совместной деятельности многого не требуется. Надо просто организовывать процесс, используя простые, очевидные механизмы. Управлять, а не пускать все на самотек, прикрываясь мантрами про «самоорганизацию». Принципы ниже про удаленку, но разве только про нее?
Принцип 1. Работать строго по задачам в трекере
Принцип очевидный, примерно такой-же, как необходимость мыть руки. Однако, как руки моют далеко не все и не всегда. До сих пор в некоторых компаниях какое-то число задач проходит мимо трекера. Или задачи как-бы в трекере, но не всегда соответствуют тому, что реально делается. Если при офисной работе это еще как-то допустимо — все на виду, то при удаленке трекинг всех значимых задач обязателен. Что-такое «значимая задача» определяется эмпирически. Мой критерий — «любая задача, которая не может быть сделана за 15 минут». При этом с таймером стоять не надо. Если на какую-то консультацию, разбор ошибки и т.д. вдруг потребуется не 15, а 16 минут, или даже 17, то она вполне может не попасть в трекер, при условии, если таких задач немного. Аналогично и в другую сторону. Если на задачу требуется 5 минут, но за эти 5 минут разработчик делает изменение в коде, то такую задачу нужно зарегистрировать. Иначе как вы через год определите, зачем это вдруг поменяли вот эту строчку кода?
Какой трекер использовать? Ответ — любой, к которому привыкли и который удобен. Мои команды работали с жирой. Редмайн также вполне подойдет. Да даже и Trello.
Но…
Представьте себе, что вы работаете в организации, где трекер жестко мониторится. Рассчитываются разные и множественные показатели эффективности и еще кто-то точно знает чего. По этим показателям проводятся совещания, строятся отчеты, стукают по головам линейных руководителей за отклонения. В общем, делается много важной и полезной работы.
Можно ли в таких условиях организовать нормальный трекинг задач? Ответ — нет. Любой неосторожный шаг может привести к нарушению метрики, а мы же хотим просто работать, планировать, делать жизнь проще…
А если получается наоборот — все очень сложно, то простая и хорошая идея работать по трекеру ломается. Конечно, команда что-то трекает, но в минимальном объеме, чтобы отчеты не испортить…
Вредная мысль… А что если реальный рабочий трекинг вести в альтернативной системе? Trello, например.
Принцип 2. Ежедневный отчет по затраченному времени
По этой теме в сообществе давно идут ожесточенные споры и у меня нет никакого желания абстрактно рассуждать на тему «хорошо»\«плохо». Описываю то, что работает и целесообразно.
В соответствии с Принципом 1 «Работать строго по задачам в трекере», все задачи у нас отслеживаются. В конце рабочего дня каждый сотрудник вспоминает какие задачи он сегодня выполнял и вносит в них затраченное время с коротким описанием сделанного. Описание вполне может быть «много думал». Для того, чтобы списать время на «незначительные задачи», можно завести отдельную задачу — условную «свалку». Понятно, что туда должно улетать немного рабочего времени, так как задачи «незначительные». По таким задачам также необходимо описание того, на что было потрачено время. Например, «консультация Анжелы». Кстати, если вы видите, что в задачу «свалку» пишется много времени, то это звоночек о том, что что-то идет не так и с этим надо что-то делать. Работа руководителя в том и состоит, чтобы слышать «звоночки» и предпринимать действия, чтобы выправить ситуацию.
Итак, все рабочее время учитывается, и его сумма должна получиться 8 часов в день. Или 40 часов в неделю. Правильнее обращать внимание именно на недельный баланс, чем на дневной. Это нормально, когда живые люди иногда работают больше, иногда меньше. Разные ситуации бывают, да и работоспособность наша совсем так равномерна, как предусматривается табелями учета рабочего времени.
В отличие от принципа «Работать строго по задачам в трекере» внедрить принцип ежедневного учета обычно намного сложнее. Важно именно то, чтобы люди списывали свое время ежедневно, а не в конце недели, месяца или когда прилетит пинок от руководителя. Нужно понимать, что принцип учета времени выводит человека из зоны внутреннего комфорта, это вызывает внутренне сопротивление и именно поэтому, он обеспечивает эффективность удаленной работы.
Для внедрения любого начинания требуется сначала его разъяснить, а потом, особенно на первом этапе, регулярно контролировать исполнение и обеспечивать выполнение правила. Неотвратимость намного более эффективна, чем жесткое, но случайное, наказание за невыполнение.
Внедряя принцип учета времени во многих командах, я всегда слышал один и тот же вопрос-утверждение в разных творческих вариантах "мы теперь вместо разработки будем все время тратить на списание времени". Вполне может быть. Вы имеете полное право учесть время, затраченное на списание во времени выполнения задачи. Легко посчитать… сколько времени требуется на то, чтобы залезть в жиру, найти задачу, прикинуть сколько времени заняла задача, что делалось и вписать несколько цифр и пару фраз? Пусть 5 минут. Разработчик редко работает более, чем над 5 задачами в день. Итого, в худшем случае на списание времени будет потрачено 25 минут. Компания может себе это позволить.
Другое частое возражение "а откуда я знаю. сколько времени я потратил?". Ответ — секундомер не нужен. Вносить надо время по вашей оценке в конце дня. Как и в любой оценке ошибки допустимы.
Фишка принципа учета рабочего времени состоит в том, что заставляет каждого игрока в команде проводить ежедневный индивидуальный «ретро». Ведь нужно вспомнить, что делал. Понять получилось или нет, сколько и на что ушло времени. Информация по списаниям открыта руководителю, команде, поэтому писать неадекват не получится. Просто стыдно. Понимание того, что в конце дня нужно будет выполнить процедуру отчетности по времени является очень хорошим средством от
Как делать не надо...
Вводя любую новацию нужно самому быть уверенным в ее пользе. Подход — а все так делают, а пришло указание «сверху» убивает идею. Если нет внутренней убежденности в необходимости использовании какого-то управленческого инструмента лучше от него отказаться, чем передавать свою неуверенность и сомнения команде.
Принцип 3. Регулярные «планерки» команды
Коммуникации в команде, работающей на удаленке очень важны. Каждый должен быть в курсе того, что происходит на проекте, какие есть внешние изменения, кто с какими проблемами сталкивается, когда ожидать завершения задач и т.д. Важно понимать и ощущать, что мы команда, что все в одном контексте, есть общее понимание не только целей, но и того, где мы сейчас находимся. Пусть даже в месте темном и неприятном…
Я назвал такие регулярные митинги команды «планерками», а не скрамовскими дэйли вполне осознанно. Скрам это одна из методологий, эффективная в одних ситуациях, но совсем неприменимая в других. Натягивать скрам на все живое — затея странная и непонятная.
Поэтому именно "планерки", хотя по смыслу и формату они и напоминают дэйли. Обсуждаем статус, вводные. Объемные вопросы переносим в отдельные совещания. Длительность рекомендую ограничивать 15-30 минутами. Оптимальная периодичность в спокойное время — 2-3 планерки в неделю, в горячий период — раз в день.
При проведении планерок важна регулярность. Лучше сразу добавить их в календарь всей команды. И о календаре. На удаленке это обязательный инструмент управления и своим временем и временем команды. Признак уважения. Мне нужно обсудить что-то важное, но я уважаю тебя, твои планы, поэтому заранее приглашаю на встречу. Если предложенное время неудобно, можем перенести. Если есть предварительные вопросы о целях встречи — можешь задать, равно как и отказаться от встречи.
Принцип 4. Коммуникации 1х1
Когда вся команда работает в одном офисе постоянно возникают спонтанные коммуникации. Около кофемашины, на кухне, кто-то кого-то зацепил в коридоре на несколько слов. В режиме удаленной работы такой роскоши нет. Есть только мессенджеры, телефон. Люди же разные, в ИТ чаще интровертные, поэтому может возникнуть ситуация при которой кто-то из сотрудников «потеряется», разорвется межличностная коммуникация, очень важная не только для достижения результатов, но и для социализации сотрудников. Мы же люди и хотим общаться, даже заядлые интроверты.
Помочь здесь могут «спонтанные», полуформальные коммуникации, когда тимлид обсуждает какой-либо вопрос 1х1 с сотрудником. Вопрос может быть организационным, может быть техническим. Важнее то, что тимлид периодически инициирует диалог с каждым. Лучше всего голосом, но в каких-то ситуациях могут быть и текстовые сообщения. Голосом намного лучше! Это не должно происходить по-расписанию, и хорошо придерживаться средней частоты таких встреч не менее 2-х раз в неделю.
Этот принцип исходит из старого, доброго оффлайн навыка хорошего руководителя — общаться с сотрудниками, уделять им внимание. В оффлайне такие коммуникации возникают естественно, сами-собой. В режиме же удаленной работы их нужно специально инициировать. Не забывать про людей.
Я описал четыре базовых принципа удаленной работы позволяют сделать ее продуктивной, эффективной и комфортной для сотрудников. Такой, что не требует возвращения в офис, что само по себе экономически выгодно для компании. Конечно, этими принципами компетенции руководителя не ограничиваются, но следование им, таким простым, уже может поразительно изменить отношение к удаленной работе. Мы закрываем основные управленческие обязанности — трекинг задач обеспечивает планирование, контроль, делегирование. Планерки и встречи 1 на 1 создают единое информационное поле. Возникающие вопросы либо оперативно решаются, либо добавляются в трекер для приоритизации.
Ничего же сложного.
