Не делай сам

Есть крутое упражнение для тех, у кого проблемы с делегированием. На день, два, или вообще неделю надо забиться с самим собой не делать ничего самому. Всё должны сделать другие: написать письмо, сделать звонок, провести встречу, разгрести бэклог, составить роадмап, что угодно вообще.

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

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

Прикинуться томатом

Реклама сока с детьми в костюмах фруктов породила множество посредственных анекдотов. Фразу «а я томат» должны помнить многие.

Я часто использую её, когда откровенно туплю и косячу. Признал себя томатом = быстро признал ошибку и двигаешь дальше.

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

Также это созвучно с принципом «не в порядке» в системе ведения переговоров по Кемпу (и Синельникову). Если коротко, то другая сторона не должна чувствовать себя хуже на вашем фоне. Поэтому стоит быть немного, но заметно, несовершенным.

В некоторых ситуациях это манипуляция, и такое не рекомендуется повторять в домашних условиях. Для манипуляторов вообще в аду заготовлен отдельный котёл. Но круто, когда это внутреннее ощущение и искреннее желание помочь собеседнику или поддержать оппонента. Тогда это действительно работает.

https://youtu.be/mTW-HEz0TBM

Это вопрос, откройте

Почувствуйте разницу.

Нет: ты уже сделал эту задачу?
Да: какие есть сложности с этой задачей?

Нет: Мы сможем сдать проект вовремя?
Да: Что мы можем сделать, чтобы сдать проект вовремя?

Нет: Вам нравится наш продукт?
Да: Как вы используете наш продукт? Какие проблемы вы решаете с его помощью?

Нет: Любишь рэпчик?
Да: Что ты сделал для хип-хопа в свои годы?

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

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

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

Подробнее:
* в совете Бюро в контексте переговоров https://bureau.ru/bb/soviet/20170811/
* в статье в контексте User Research https://www.nngroup.com/articles/open-ended-questions/

Цикл OPDCA: Observe-Plan-Do-Check-Adjust

Про цикл PDCA знаю давно, но осознанно применил как инструмент совсем недавно после поста в канале «Бабаева, к доске!» https://news.1rj.ru/str/changemarketing/419. Он просто очень вовремя попался, как раз к одной из текущих задач.

Используется цикл для организации процесса непрерывного улучшения и контроля качества. Известен также как цикл Деминга. Мне больше нравится версия с O, чем просто PDCA.
Суть проста:
⁃ Observe: наблюдение за текущим состоянием
⁃ Plan: постановка целей и определение процесса продвижения к ним
⁃ Do: проверка плана в бою
⁃ Check: сбор и анализ результатов Do, а также изменений с предыдущей итерации цикла
⁃ Adjust (по смыслу нравится мне больше, чем Act): подкрутка плана и процессов

Для меня такие инструменты — это способ перевести интуитивные решения в осознанные и структурированные.

Задача, к которой применил: проанализировать текущий процесс разработки в команде, разобраться, почему работы много, а ключевые вещи запускаются долго, починить это всё.

Я расписал по каждому этапу цикла, какие активности, встречи и ритуалы есть у нас в команде, а также какие проблемы сразу видны. Простое упражнение сразу показало:
⁃ у нас много Do: все фигачат и постоянно заняты
⁃ Plan недостаточно сфокусирован и структурирован, приоритеты для Do часто размытые
⁃ Check и Adjust не являются частью регулярного процесса, появляются эпизодически при наличии времени или факапа

Большая часть процесса в команде и компании сформировалась до меня, моё погружение в контекст ещё было неполным. Я честно не мог сформулировать проблему до конца, чтобы начать её решать полноценно. OPDCA помог начать.

Дальше подключились идеи Голдратта и некоторые другие инструменты. Первые результаты уже прорастают. А цикл теперь хочется приложить как подорожник к любому процессу.

https://en.m.wikipedia.org/wiki/PDCA

Чем я могу помочь?

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

Естественная реакция большинства менеджеров на проблему или затык — взять всё в свои руки и по шагам всем рассказать, что и как надо сделать. Микроменеджмент спешит на помощь! Часто я сам веду себя так, дефолтные реакции очень сложно осознать и побороть.

Есть ситуации, когда действительно надо быстро и четко отработать какую-то хрень. Но таких меньшинство. Обычно эта хрень не так критична, поэтому вместо раздавания приказов можно качнуть команду или человека простым вопросом: «чем я могу помочь?».

Крутая штука в том, что после этого вопроса вас перестают воспринимать как ещё одну угрозу и начинают думать более свободно. Часто в итоге человек или команда сами все делают или чинят. Если реакция не такая идеальная, а такое будет случаться регулярно, то всё равно советы и рекомендации зайдут уже намного лучше. Если находится, чем реально вы можете помочь, то ещё лучше. Поделать что-то руками, лучше понять, что и как происходит в команде, процессе, продукте — это офигенный бонус.

Шаблон организации проекта в Trello

Собрал в trello набор досок, которые частями или полностью использовал для организации уже приличного числа проектов в течение многих лет. И использую до сих пор. Изначальная идея была подсмотрена у замечательной компании thoughtbot, с неё же началась моя любовь к trello. Но основа — пост компании UserVoice.

Этот набор досок немного перекошен в сторону разработки и адаптирован под свои заморочки. Но легко применим для многих других случаев от дизайна до стройки.

В основе — канбан и идея конвеера, по которому движутся задачи. Для удобства понимания на досках в виде задач оставлены комментарии, чтобы вообще не приходилось думать.

Подробнее описал в посте https://telegra.ph/SHablon-organizacii-proekta-v-Trello-09-04

Сами доски собраны в одной команде в trello: https://trello.com/onehandclapping_demo

Конспект курса «Управление проектами, людьми и собой» Николая Товеровского

Последние несколько месяцев часто обращаюсь к записям, которые делал на курсе Товеровскго уже больше 3 лет назад. Оказалось, что в моей новой команде не все знают, что такое флексить, зачем нужно прибивать гусеницу и фиксировать дедлайн, почему именно исполнитель понимает задачу, что на самом деле значит «сделать», почему важно делать не в притык и концентрироваться на пользе.

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

Про "fixed price, fixed budget, flexible scope" (ФФФ) я впервые прочитал у 37signals (теперь просто basecamp), но в России именно Бюро Горбунова, их статьи и курсы — один из основных распространителей подхода.

Курс Николай проводит до сих пор. Это не реклама, но я искренне до сих пор советую его всем, кто причастен к управлению в IT, а иногда советую и тем, кто не причастен, но хочет сделать свою работу лучше.

Оцифрованный конспект доступен по ссылке, все три дня в виде коротких заметок и цитат.

https://telegra.ph/Konspekt-kursa-Upravlenie-proektami-lyudmi-i-soboj-Nikolaya-Toverovskogo-09-01

Про стори поинты от создателя стори поинтов

Я всегда не любил стори поинты, как и оценки для задач и проектов. Если только задуматься, насколько целая индустрия полагается на умение (точнее неумение) угадывать будущее, то сразу отчаяние накатывает. Про движение #NoEstimates и то, как оно немного сдвинуло моё сознание в отношении эстимейтов, я расскажу отдельно. Сегодня хочу поделиться замечательной статьёй про стори поинты от их непосредственного создателя.

В статье прекрасно всё с первого предложения: "I like to say that I may have invented story points, and if I did, I’m sorry now."

Рон Джеффрис рассказывает, как концепт родился в их тусовке XP из идеальных дней, которые домножали на коэффициент, чтобы не путать стейкхолдеров. Как он должен был восстановить равновесие силы, а не ввергнуть её во мрак. Как неплохая идея в итоге чаще всего используется неправильно.

Ключевые моменты:

⁃ стори поинты нельзя использовать, чтобы предсказать, когда что-то будет сделано
⁃ трекать, насколько оценка в стори поинтах, соотнеслась с затратами времени бесполезно
⁃ сравнивать команды на основе умения делать оценки вредно
⁃ эстимейты чаще всего являются попыткой угадать, нельзя воспринимать их как обещание и коммит
⁃ важнее определять самые важные и приоритетные вещи для работы и делать их быстро
⁃ чтобы это было возможно надо резать задачи на кусочки, каждый из которых несёт ценность; стори поинты и оценки в этом не помогают
⁃ Рон идет дальше и говорит, что идеи итераций и спринтов также вторичны и не особо нужны перед знанием, какие следующие фичи принесут наибольшую ценность
⁃ честный ответ на «когда это будет сделано?» при фиксации списка фич «никто на самом деле не знает»
⁃ гораздо лучше идти от обратного: выбрать дату релиза пользователям и до неё сделать как можно больше полезного; оценки и стори поинты тут опять не помогают

Несколько цитат

> The best way to deliver value isn’t more, more, more, it’s to do small valuable things frequently. If instead of estimating stories, we slice them down to “small enough”, we can come to a smooth flow of value, delivering all the time.

> I’ll go further: I’d prefer to avoid iteration or Sprint planning entirely. We wouldn’t work to fill up a budget for the next few weeks: we’d work to have a list of the few most important next things to do.

> It is common practice to make a list of essential features, think about them for a while, and then decide that they define the next release of our product. The next question, of course, is “when will all this be done?”
> The answer is that no one knows.

> It’s far better to pick a close-in date for the next release to customers, and pick as much good stuff into that release as possible. Estimating, be it in story points or gummi bears or even time, gets in the way of this. Where possible, in my opinion, it’s best avoided.

https://ronjeffries.com/articles/019-01ff/story-points/Index.html

Что впитывать начинающему менеджеру

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

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

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

1. Книги https://basecamp.com/books, блог https://m.signalvnoise.com/ и подкаст https://rework.fm/ от компании Basecamp (ex 37signals). Советую, т.к. во многом разделяю их философию. Не везде и не всё применимо в наших реалиях, но вектор правильный. Недавно они выложили в паблик новую книгу https://basecamp.com/shapeup, изучаю прямо сейчас.
2. Курс Товеровского и Бюро https://bureau.ru/educenter/fff/ — как правило советую всем, кто относится к работе в IT, даже если не руководитель, но последним особенно. В сети есть множество неплохих конспектов, мой есть выше в этом канале, на сайте бюро много советов, а у Николая выходит книга на базе курса https://bureau.ru/books/fff/demo/3
3. Для академических целей можно почитать Голдратта. Например, «Цель». Это классика, но с ней надо аккуратно в интерпретациях. На идеях Голдратта организовано много управленческих подходов. Мне нравится ментальная модель конвеера для процессов разработки, но не все её разделяют.
4. Книга "No Estimates" https://oikosofyseries.com/no-estimates-book-order. Интересна для понимания, что можно делать по-другому, и опыт десятилетий в индустрии не обязательно гарантирует, что какая-либо практика полезная и хорошая.
5. По работе с людьми всегда и всем советовал книгу «Общаться с ребёнком. Как?» Гиппенрейтер. Давно не перечитывал, но в своё время много откровений получил оттуда.
6. Ещё в сторону понимания людей и себя: «The Power of Habit» by Charles Duhigg.
7. Советую критично относиться к разрозненным статьям, блогам и телеграм-каналам (такая вот ирония), больше доверять авторскому опыту, но использовать это всё как поддержку для книг, а не замену.

Выживают наиболее приспособленные

В эволюционном процессе выживает не сильнейший, а тот, кто адаптировался быстрее и лучше. Survival of the fittest.

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

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

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

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

Обречённая команда может стать крутой и выжить. Это не просто и требует сдвигов сознания, ломки, местами признания слабости и просьбы помощи. Но выживание того стоит.

"Shape Up" by Ryan Singer from Basecamp

Слежу за тем, что делают ребята из Basecamp (ex. 37signals) уже лет 10, если не больше. Во многом разделяю их идеи и философию.

Shape Up прочитал с огромным удовольствием. Некоторые идеи уже применял в работе раньше, что-то начал внедрять в процессе прочтения, до некоторых вещей еще предстоит дорасти.

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

Собрал ключевые идеи, принципы и цитаты.

https://telegra.ph/Recenziya-na-knigu-Shape-Up-by-Ryan-Singer-from-Basecamp-10-20

Работать нормально

В одной из своих рассылок vas3k (@vas3k_channel) написал:
> «Палю моднейший тренд в айти: работать нормально.»

Фраза меня зацепила. Далее по тексту было пояснение в контексте статьи про 10x engineers. Моё «нормально» созвучно, но всё-таки отличается.

В реальности большинство людей хотят работать нормально. Только это «нормально» у каждого своё. Это как многие злодеи в фильмах думают, что творят добро, только по-своему.

Мне стало любопытно, и я спросил несколько друзей: что для них значит «работать нормально»? Формат ответа был любой, никаких ограничений.

Получилось любопытно. По ссылке несколько ответов и в конце мой.

https://telegra.ph/CHto-znachit-rabotat-normalno-10-28

Конспект PM Starter Pack

https://pmstarterpack.onfielder.com/ — этот небольшой гайд запустился на Product Hunt в мае и ссылку на "Practical guide on how to get started in product management" можно было увидеть во многих околопродуктовых каналах и рассылках.

На прошлой неделе добрался посмотреть, что же там внутри. К сожалению practical этот гайд назвать можно с трудом. Внутри достаточно общие и абстрактные истории. Вместо конкретики в большинстве ситуаций подборки ссылок на статьи. Ryan Hover в комментарии на странице гайда на PH просто написал, что советует начинающим продактам копать свои сайд проекты, и он прав.

Сделал одностраничный конспект. Рекомендую только действительно начинающим ребятам.

https://telegra.ph/Konspekt-PM-Starter-Pack-10-31

«Хьюстон, у нас всё хорошо (на самом деле нет)»

Писать в канал после 5 месяцев тишины — почти восстать из мёртвых.

Нет, работы не стало меньше, скорее наоборот. Нет, это не из-за самоизоляции, хоть она и немного способствует.
Просто изменилась структура времени и следом за ним внимания. Хотя чаще происходит наоборот.

Возвращение в поток началось с ревизии, приведения в порядок и разбора старых записей. Поэтому сегодня делюсь заметками с лекции Людвига Быстроновского, которую посетил ещё в 2015-м.

Её название удивительно созвучно текущему времени. Но мы же тут про менеджмент, поэтому не буду слишком обобщать.

Людвиг очень круто мыслит, выступает и пишет. Вот несколько отличных цитат:

> Я могу пойти в настройки и сказать уведомлению: «а ну-ка иди нахуй»

> Как избавиться от микроменеджмента: надо дать людям обосраться

> Вы не можете контролировать ситуацию. Единственное, что вы можете контролировать — это себя

На днях поделюсь конспектом с ещё одной лекции Людвига.

И да, в дополнение к каналу теперь есть простой сайт. Или в дополнение к сайту теперь остался канал. Как пойдёт.

https://onehandclapping.ru/ldwg-houston-we-are-fine-or-not.html

«Дизайн+1»

Продолжаю разбирать конспекты и записи. Эту лекцию Людвига Быстроновского я лучше всего помню по новому для себя факту: если в меню ресторана есть салат «Цезарь», его берут чаще остальных в 8 раз.

Но лекция, конечно, не про салаты. А про профессионализм. И не только дизайнеров а вообще всех. Вот, например, несколько мыслей:

> Чтобы научиться делать проекты, надо делать проекты.

> Не надо останавливаться на технологии, останавливаться надо на решении задач.

> Если люди делают хорошо, хули лезть.

> Можно за 15 минут сделать много, если ты умный, но если ты 8 часов как чмо, то и письмо напишешь как чмо.

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

https://onehandclapping.ru/ldwg-design-plus-one.html

Rams

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

В этом контексте мне очень понравился фильм Rams независимого режиссёра Gary Hustwit. Личность немецкого дизайнера Дитера Рамса привлекла внимание, а его философия "less, but better" оказалась очень созвучна с моим ощущением дизайна и мира.

Дитер Рамс известен как дизайнер множества продуктов фирмы Braun, мебели от компании Vitsœ, а также автор 10 принципов хорошего дизайна. Его работа стала вдохновением для многих поколений дизайнеров.

> "Less, but better" is not just a design concept, it's also about our behavior. Less would be better everywhere.

Посмотрите обязательно.

https://onehandclapping.ru/rams

Заслать фоллоу-ап

Фоллоу-ап — краткий итог встречи, которым поделились со всеми участниками в удобном всем канале. Например, это может быть письмо, пост в чате, комментарий в задаче.

Этот термин распространён в продажах, но для меня это больше про закрепление любого устного взаимодействия письменным.

Фоллоуапить — очень крутая практика и навык. Сказанное слово ненадёжно, оно забывается, меняет смысл, что приводит к проблемам, неоправданным ожиданиям и спорам в стиле “he said, she said”. Письменное слово в гораздо меньшей степени подвержено девиациям и разным трактовкам.

Фоллоу-ап — это выжимка, а не изложение. Часто готовить фоллоу-ап можно прямо по ходу встречи. Это нормально делать записи по ходу разговора. Навык слепой печати и умение сжато формулировать помогают.

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

Идеальный фоллоу-ап содержит следующие детали:

- что обсудили
- о чём договорились и почему
- план ближайших действий
- договоренность о следующей точке синхронизации
- просьба подтвердить правильность написанного

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

Самая главная проблема с фоллоу-апом — это сомнение, как же правильно писать это слово на русском. С дефисом? Или слитно? Или через пробел? А если в глагольной форме? Но с этим всем можно жить.

Вот пример фоллоу-апа:

- обсудили: что такое фоллоу-апы и как их готовить
- договорились: будем фанатично фоллоуапить после всех встреч на всех участников
- дальнейший план: будем разбираться с чем-нибудь поинтереснее скучных фоллоу-апов
- до встречи в новой заметке
- поделитесь постом с коллегами, если всё верно

Лекция Виктора Козлова в ИТМО

За последние два месяца интернет-магазин Ozon стал для меня регулярным местом для посещения и перераспределения бюджета от несостоявшихся поездок и других невозможных сейчас активностей. При том, что до этого я пользовался им много лет назад. Самоизоляция действительно перестраивает жизнь.

На этом фоне вспомнил про конспект выступления Виктора Козлова, одного из основателей Ozon,Рексофт, Assist и Clever Pumpkin. В лекции не было неожиданных откровений, но были довольно простые и понятные мысли и идеи без претензии на что-то глобальное:
- ставьте меньше условий для своего счастья
- создавайте удачу упорным трудом
- расценивайте неудачу как полезный опыт
- учитесь всю жизнь

Думаю, поэтому и человек, и лекция произвели приятное впечатление.

https://onehandclapping.ru/victor-kozlov-v-itmo

Вера и идеи

В фильме замечательного режиссёра Кевина Смита «Догма» на тему веры и идей мне запомнилось два диалога.

Bethany: You’re saying having beliefs is a bad thing?
Rufus: I just think it’s better to have ideas. I mean, you can change an idea, changing a belief is trickier. People die for it, people kill for it.

Rufus: Why, Bethany Sloane, are you saying you believe?
Bethany: No. But I have a good idea.

В русской озвучке последний диалог звучал так:

— Кризис веры миновал?
— Я получила больше, чем заказывала.
— Не засуха, так ливень. Укрепилась верой?
— Нет. Но обогатилась идеями.
— Браво.

Если представить, что Вифания и Руфус два менеджера, и одна из них сначала перегорела на работе, но потом пришла в себя через почти божественное касание, то мы получаем нужный контекст. И цитирование фильма «Догма» выглядит уже не так странно.

Вера — отличный инструмент создания интерсубъективной реальности для любой группы людей. В том числе компании или, более локально, команды. Но он обладает существенным недостатком — мы воспринимаем веру догматично. Поэтому всё, что переходит в разряд веры, а точнее то, что мы переводим в разряд веры, нам самим же становится сложно менять, оно реже подвергается сомнениям. Вера становится «слепой», команда негибкой, инерция неизбежной, а люди постепенно начинают сгорать. Это в том числе случай, когда в ответ на «почему?» получаем ответ «мы всегда так делали». Да, я специально обобщаю и утрирую, чтобы сделать акцент.

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

В вере нет ничего плохого, если она не доведена до фанатизма или автоматизма. Но лучше всё-таки обогащайтесь идеями.

How to Manage a Remote Team Well

Посмотрел, законспектировал и выделил основное из воркшопа Clair Lew, CEO сервиса Know Your Team, про то как грамотно управлять удалённой командой. В идеях видно наследие идеалогии Basecamp. Но мне оказалось не лишним себе ещё раз напомнить. Вот самое главное:

1. Асинхронность — самый важный и при этом недооценённый бонус удалённой работы. При этом самый нетривиальный в настройке. Менее реактивная коммуникация даёт возможность фокусироваться на задачах и думать.
2. Удалённо работать можно только на доверии. Трекинг и микроменеджмент это убивают. Тащат понятная трансляция ожиданий в одну сторону и прозрачный прогресс (в идеале автоматический) в другую сторону.
3. Настроенные процессы очень важны. Начать с базы: док-методичка «как мы работаем», правила коммуникации, вопросы по таймзонам и ожиданиям по времени вообще. Дальше подкручивать.
4. Уделить внимание социальным связям. По сути офисные неформальные коммуникации надо адаптировать для удалённой работы. Потому что работа это огромная часть жизни людей, и это не только про «фигачить», но и про коммуникацию.
5. Встречи один-на-один: не превращать в сверку по текущему статусу, а стараться раскрыть потенциал или потенциальные проблемы. Регулярность встреч решает.

Более подробный конспект на английском: https://onehandclapping.ru/claire-lew-how-to-manage-a-remote-team-well

Рекомендую

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

Только опробованное лично и то, что считаю полезным.

https://onehandclapping.ru/recommendations