Хлопок одной ладони
«Ты можешь услышать хлопок двух менеджеров, когда они ударяются друг о друга, — сказал Мокурай. — Теперь покажи мне хлопок одного менеджера».
https://onehandclapping.ru/
https://twitter.com/nhndclppng
@onehandclapping_bot
Recent Posts
RSS для подкаста «Аэростат» Бориса Гребенщикова
Я слушаю подкасты уже лет 15. И всё это время в виде подкаста я продолжаю слушать только одну передачу — «Аэростат» Бориса Гребенщикова. Передача выходит на «Радио России», и в виде нормального подкаста её давно уже, к сожалению, не выпускают. Сначала она публиковалась на russianpodcasting, потом на podfm, потом на сайтах энтузиастов. Потом долгое время не было ничего, кроме RSS-потока последних 20 выпусков, который поддерживает один программист-энтузиаст (код парсера сайта радио есть на github, ищите по radiorus-rss).
Уже собирался сделать нормальный фид со всей историей сам, но нашёл сайт https://aerostatbg.ru/ и связался с его создателями. Сайт создан ценителями-энтузиастами на некоммерческой основе. И там есть полная база передач Аэростата. Я рассказал ребятам про потребность, они сделали отличный RSS-фид, который вы можете добавить в свой любимый подкаст-плеер. Сам использую Overcast https://overcast.fm/. Прямая ссылка на фид:
https://aerostatbg.ru/rss.xml
На сайте поток пока не афишируется. Но пользоваться уже можно.
Это история не про менеджмент, а про колаборацию. Круто, что можно связаться с незнакомыми людьми, найти общий язык и создать что-то новое, удобное и полезное. Спасибо!
Я слушаю подкасты уже лет 15. И всё это время в виде подкаста я продолжаю слушать только одну передачу — «Аэростат» Бориса Гребенщикова. Передача выходит на «Радио России», и в виде нормального подкаста её давно уже, к сожалению, не выпускают. Сначала она публиковалась на russianpodcasting, потом на podfm, потом на сайтах энтузиастов. Потом долгое время не было ничего, кроме RSS-потока последних 20 выпусков, который поддерживает один программист-энтузиаст (код парсера сайта радио есть на github, ищите по radiorus-rss).
Уже собирался сделать нормальный фид со всей историей сам, но нашёл сайт https://aerostatbg.ru/ и связался с его создателями. Сайт создан ценителями-энтузиастами на некоммерческой основе. И там есть полная база передач Аэростата. Я рассказал ребятам про потребность, они сделали отличный RSS-фид, который вы можете добавить в свой любимый подкаст-плеер. Сам использую Overcast https://overcast.fm/. Прямая ссылка на фид:
https://aerostatbg.ru/rss.xml
На сайте поток пока не афишируется. Но пользоваться уже можно.
Это история не про менеджмент, а про колаборацию. Круто, что можно связаться с незнакомыми людьми, найти общий язык и создать что-то новое, удобное и полезное. Спасибо!
Про автоматизацию маркетинга в геймдеве
В начале осени давал небольшую обзорную консультацию по построению с нуля автоматизации в маркетинге для компании, разрабатывающей мобильные игры. Делюсь ключывми моментам.
Дисклеймер: мой опыт ограничен только работой в Playrix, мысли ниже очень обобщены и обязательно должны быть адаптированы под ситуацию конкретной компании.
- автоматизация маркетинга — это набор процессов, который в первую очередь обеспечивает поступление и обработку данных от поставщиков информации и услуг, а также дальнейшее представление нужных отчётов и данных в форме, необходимой бизнесу для принятия решений по стратегии закупки рекламы. Во вторую очередь это процессы по сокращению ручной работы сотрудников маркетинга (ведение разных реестров, формирование и загрузка бидов и т.п.). Аналогичным термином «автоматизация маркетинга» называют команды, которые обеспечивают эти процессы.
- обычно данные собираются с Mobile Measurement Partner (MMP; AppsFlyer, Adjust), каждой подключенной рекламной сетки, платформы игры (Apple, Google) и с самих игр, обогащение может происходить из внешних аналитических платформ (App Annie, Sensor Tower и т.п.)
- минимальный состав команды по ролям: инженер данных (data engineer), DevOps, BI специалист, программист, тестировщик, engineering manager. В идеале команду должен сопровождать и направлять аналитик данных, но эта роль может быть и внешней. Конкретное число специалистов каждой роли сильно зависит от масштабов и амбиций компании. Совмещение ролей разными людьми практически невозможно, фокуса хватать не будет
- если идёт построение отдела с нуля, очень важно наличие сильного инженера данных с пониманием и опытом, иначе ошибки на начальной фазе будет дорого исправлять потом. И, конечно, это вопрос скорости разработки.
- чтобы поднять автоматизацию с нуля до стабильного уровня нужно в районе полугода, дальше развивать можно вечно. Но если объёмы никакие и потоков данных нет, то на коленке собрать первый сетап можно и за 2-4 недели. Реализация очень сильно будет различаться в зависимости от объёмов данных. Чем их больше, тем умнее надо быть
- для работы с данными нужны:
- хранилище сырых данных — может быть медленным, является подстраховкой при необходимости пересчётов. Например, Amazon S3
- база для работы с обработанными данными — полусырые данные в источнике, который могут мучать аналитики. Например, ClickHouse, Amazon RedShift и т.п.
- BI система — визуализации, интерактивные дашборды, которые создают аналитики и в автоматизации. Я активно работал только с Tableau и, в целом, могу его рекомендовать.
- ETL процессы (extract, transform, load) — код, который буквально забирает, преобразовывает и сохраняет данные. Настроить их можно сильно по разному, но обычно ключевые слова такие: python, airflow, luigi, spark
- для автоматизации ручной работы нужно меньше — хороший программист и опытный человек внутри или вовне команды с пониманием, что автоматизировать, в каком порядке и почему
- по мере взросления сетап неизбежно обрастёт сопровождающими инструментами и процессами: мониторинг инфраструктуры, контроль состояния систем партнёров (чужие API ломаются чаще, чем хочется), бэкапы, логи, проверка целостности данных, сравнение разных источников, системы оповещений и т.п.
- the last but not the least. Автоматизация маркетинга не будет иметь смысл, если не будут выдрочены два момента: интеграция нужных SDK в самих играх и формирование правильных событий. Именно поэтому важно наличие аналитика для проектирования и тестировщика для проверки. Выпущенный с ошибками релиз может дорого стоить, т.к. на данные за все дни проблемы опираться будет нельзя
Для погружения в тему мобильного маркетинга в целом могу посоветовать сайт https://mobiledevmemo.com/, один из немногих, которые отслеживал, когда работал в сфере.
В начале осени давал небольшую обзорную консультацию по построению с нуля автоматизации в маркетинге для компании, разрабатывающей мобильные игры. Делюсь ключывми моментам.
Дисклеймер: мой опыт ограничен только работой в Playrix, мысли ниже очень обобщены и обязательно должны быть адаптированы под ситуацию конкретной компании.
- автоматизация маркетинга — это набор процессов, который в первую очередь обеспечивает поступление и обработку данных от поставщиков информации и услуг, а также дальнейшее представление нужных отчётов и данных в форме, необходимой бизнесу для принятия решений по стратегии закупки рекламы. Во вторую очередь это процессы по сокращению ручной работы сотрудников маркетинга (ведение разных реестров, формирование и загрузка бидов и т.п.). Аналогичным термином «автоматизация маркетинга» называют команды, которые обеспечивают эти процессы.
- обычно данные собираются с Mobile Measurement Partner (MMP; AppsFlyer, Adjust), каждой подключенной рекламной сетки, платформы игры (Apple, Google) и с самих игр, обогащение может происходить из внешних аналитических платформ (App Annie, Sensor Tower и т.п.)
- минимальный состав команды по ролям: инженер данных (data engineer), DevOps, BI специалист, программист, тестировщик, engineering manager. В идеале команду должен сопровождать и направлять аналитик данных, но эта роль может быть и внешней. Конкретное число специалистов каждой роли сильно зависит от масштабов и амбиций компании. Совмещение ролей разными людьми практически невозможно, фокуса хватать не будет
- если идёт построение отдела с нуля, очень важно наличие сильного инженера данных с пониманием и опытом, иначе ошибки на начальной фазе будет дорого исправлять потом. И, конечно, это вопрос скорости разработки.
- чтобы поднять автоматизацию с нуля до стабильного уровня нужно в районе полугода, дальше развивать можно вечно. Но если объёмы никакие и потоков данных нет, то на коленке собрать первый сетап можно и за 2-4 недели. Реализация очень сильно будет различаться в зависимости от объёмов данных. Чем их больше, тем умнее надо быть
- для работы с данными нужны:
- хранилище сырых данных — может быть медленным, является подстраховкой при необходимости пересчётов. Например, Amazon S3
- база для работы с обработанными данными — полусырые данные в источнике, который могут мучать аналитики. Например, ClickHouse, Amazon RedShift и т.п.
- BI система — визуализации, интерактивные дашборды, которые создают аналитики и в автоматизации. Я активно работал только с Tableau и, в целом, могу его рекомендовать.
- ETL процессы (extract, transform, load) — код, который буквально забирает, преобразовывает и сохраняет данные. Настроить их можно сильно по разному, но обычно ключевые слова такие: python, airflow, luigi, spark
- для автоматизации ручной работы нужно меньше — хороший программист и опытный человек внутри или вовне команды с пониманием, что автоматизировать, в каком порядке и почему
- по мере взросления сетап неизбежно обрастёт сопровождающими инструментами и процессами: мониторинг инфраструктуры, контроль состояния систем партнёров (чужие API ломаются чаще, чем хочется), бэкапы, логи, проверка целостности данных, сравнение разных источников, системы оповещений и т.п.
- the last but not the least. Автоматизация маркетинга не будет иметь смысл, если не будут выдрочены два момента: интеграция нужных SDK в самих играх и формирование правильных событий. Именно поэтому важно наличие аналитика для проектирования и тестировщика для проверки. Выпущенный с ошибками релиз может дорого стоить, т.к. на данные за все дни проблемы опираться будет нельзя
Для погружения в тему мобильного маркетинга в целом могу посоветовать сайт https://mobiledevmemo.com/, один из немногих, которые отслеживал, когда работал в сфере.
Как работать над софт скиллами
Недавно у меня был разговор с одним канадцем, очень опытным менеджером, руководителем в большой компании. Мы обсуждали, какие самые важные навыки должны быть у менеджера. После небольшого размышления сошлись на том, что это эмпатия и умение принимать решения (judgment, decision-making). Посетовали о том, что очень сложно качать это в себе и тем более в других. И разошлись.
Это не единственные качества, которые помогают в работе и относятся к софт скиллами. Можно формулировать и группировать по-разному. Иногда я формулирую софт скиллы для себя как всё, что нельзя или очень сложно вызубрить по книжке в одиночку. Немного притянуто, но в целом работает.
Собрал в одном посте тезисно свои мысли и подходы к прокачке софт скиллов, пока высокоуровнево. Например:
- что человек — робот, но программировать напрямую его сложно
- что софт навыки качать «больнее» и «опаснее» хардов
- что фреймворк прокачки софтов концептуально такой же как для хардов, разница в восприятии и деталях реализации
- что желательно повышать понимание себя, и немного про то, как это делать
- что сам читал или проходил
Подробнее по ссылке:
https://onehandclapping.ru/how-to-improve-your-soft-skills
Недавно у меня был разговор с одним канадцем, очень опытным менеджером, руководителем в большой компании. Мы обсуждали, какие самые важные навыки должны быть у менеджера. После небольшого размышления сошлись на том, что это эмпатия и умение принимать решения (judgment, decision-making). Посетовали о том, что очень сложно качать это в себе и тем более в других. И разошлись.
Это не единственные качества, которые помогают в работе и относятся к софт скиллами. Можно формулировать и группировать по-разному. Иногда я формулирую софт скиллы для себя как всё, что нельзя или очень сложно вызубрить по книжке в одиночку. Немного притянуто, но в целом работает.
Собрал в одном посте тезисно свои мысли и подходы к прокачке софт скиллов, пока высокоуровнево. Например:
- что человек — робот, но программировать напрямую его сложно
- что софт навыки качать «больнее» и «опаснее» хардов
- что фреймворк прокачки софтов концептуально такой же как для хардов, разница в восприятии и деталях реализации
- что желательно повышать понимание себя, и немного про то, как это делать
- что сам читал или проходил
Подробнее по ссылке:
https://onehandclapping.ru/how-to-improve-your-soft-skills
Базовые навыки
Менеджерам и другим работникам умственного труда для успешной карьеры и прогресса нужны не только специфичные для области/роли/функции знания, но и набор базовых навыков.
Эти базовые навыки оцениваются при найме и позже сильно влияют на результаты, на качество взаимодействия с коллегами, на скорость развития в процессе работы и в жизни тоже. Вне найма, например, на фрилансе или в бизнесе, кажется, эти навыки ещё более важны.
Среди таких навыков для себя выделяю следующие (список пополнен фидбеком в твиттере, очерёдность не означает приоритет):
- уметь критически мыслить
- печатать вслепую
- слушать активно
- адаптировать стиль чтения под материал
- эффективно вести заметки
- писать грамотно и ясно
- выражать свои мысли доступно
- контролировать своё внимание
- знать горячие клавиши используемых приложений
- знать английский язык
Конечно, можно быть успешным и без перечисленного. Большинство из нас могут быть особенно хороши в некоторых навыках и слабы в остальных. Это спектр, а не бинарное состояние «есть всё или нет ничего». Гипотеза в том, что в среднем при наличии перечисленных навыков прогрессировать проще, открытых возможностей больше, а результаты качественнее.
Базовым навыкам можно научиться. Их прелесть в том, что часто они становятся автоматическим поведением. Разучиться можно только при очень долгом отсутствии практики.
Что бы ещё добавили в список или что предложили убрать?
Менеджерам и другим работникам умственного труда для успешной карьеры и прогресса нужны не только специфичные для области/роли/функции знания, но и набор базовых навыков.
Эти базовые навыки оцениваются при найме и позже сильно влияют на результаты, на качество взаимодействия с коллегами, на скорость развития в процессе работы и в жизни тоже. Вне найма, например, на фрилансе или в бизнесе, кажется, эти навыки ещё более важны.
Среди таких навыков для себя выделяю следующие (список пополнен фидбеком в твиттере, очерёдность не означает приоритет):
- уметь критически мыслить
- печатать вслепую
- слушать активно
- адаптировать стиль чтения под материал
- эффективно вести заметки
- писать грамотно и ясно
- выражать свои мысли доступно
- контролировать своё внимание
- знать горячие клавиши используемых приложений
- знать английский язык
Конечно, можно быть успешным и без перечисленного. Большинство из нас могут быть особенно хороши в некоторых навыках и слабы в остальных. Это спектр, а не бинарное состояние «есть всё или нет ничего». Гипотеза в том, что в среднем при наличии перечисленных навыков прогрессировать проще, открытых возможностей больше, а результаты качественнее.
Базовым навыкам можно научиться. Их прелесть в том, что часто они становятся автоматическим поведением. Разучиться можно только при очень долгом отсутствии практики.
Что бы ещё добавили в список или что предложили убрать?
Как тратить меньше времени на оценку задач и больше на реально полезную работу
На прошлой неделе консультировал друга. Он ведущий разработчик в стартапе. Инхаус команды пока нет, работают с аутсорсом. И так выходит, что много времени он тратит не на продукт, а на оценки, споры за часы и доделки, взаимные валидации табличек, бюрократию и другие развлечения.
Как это можно изменить?
Давно хотел подробнее описать подходы и идеи #NoEstimates, и вот он стимул.
Коротко суть.
Эстимейты — устаревшая практика, которая не добавляет ценности в процесс разработки продуктов. Трюк в том, чтобы перейти от «как долго это займёт» к «что мы можем успеть за этот промежуток времени».
Чтобы начать движение в эту сторону надо:
- перейти к прогнозам на данных вместо оценок на глаз
- резать и нормализовывать задачи
- неизбежно начать флексить
- избегать торгов за часы
Полный текст вышел слишком длинным для канала, поэтому подробнее по ссылке:
https://onehandclapping.ru/how-to-do-fewer-estimates-and-more-actual-work
На прошлой неделе консультировал друга. Он ведущий разработчик в стартапе. Инхаус команды пока нет, работают с аутсорсом. И так выходит, что много времени он тратит не на продукт, а на оценки, споры за часы и доделки, взаимные валидации табличек, бюрократию и другие развлечения.
Как это можно изменить?
Давно хотел подробнее описать подходы и идеи #NoEstimates, и вот он стимул.
Коротко суть.
Эстимейты — устаревшая практика, которая не добавляет ценности в процесс разработки продуктов. Трюк в том, чтобы перейти от «как долго это займёт» к «что мы можем успеть за этот промежуток времени».
Чтобы начать движение в эту сторону надо:
- перейти к прогнозам на данных вместо оценок на глаз
- резать и нормализовывать задачи
- неизбежно начать флексить
- избегать торгов за часы
Полный текст вышел слишком длинным для канала, поэтому подробнее по ссылке:
https://onehandclapping.ru/how-to-do-fewer-estimates-and-more-actual-work
Люди не ресурс
В одной близкой галактике, в неназванной компании было много проектов. И каждый проект сложный и большой. Чтобы проект развивался, нужно было много специалистов: программистов, дизайнеров, аналитиков и многих других.
Находить и удерживать таких людей тяжело. Люди не столы, их нельзя подвезти в офис из Икеи в течение дня.
Но менеджеры компании это не осознавали или регулярно об этом забывали. Называли специалистов словом «ресурс» и всё время искали эти самые ресурсы. Они каждый день играли в игру по добыванию ресурсов, по отбиванию ресурсов, по отстаиванию ресурсов, по перебалансировке ресурсов, иногда даже по накапливанию ресурсов впрок.
Проектов становилось больше, сложность возрастала, цена изменений тоже. Менеджеры продолжали играть.
Специалисты переходили между командами, переходили между проектами, скакали между задачами. Затем им надоедало, они выгорали, и уходили. Их пытались удержать, рассказывали, что всё изменится, станет лучше, по-другому. Но ничего не менялось. Их мечты о лучшем будущем разбивались о суровую реальность. И они теряли веру. Менеджеры продолжали играть.
Когда сдвигался запланированный срок релиза, менеджеры говорили, что у них не хватило ресурсов. Когда новая фича переносилась на следующий релиз, у менеджеров не хватало ресурсов. Если перед релизом в важной фиче обнаруживалось множество багов и недоработок, это объясняли нехваткой ресурсов, а иногда и их качеством. Менеджеры продолжали играть.
Эта история не про конкретную компанию и конкретных менеджеров, любые совпадения случайны, все имена выдуманы и вообще отсутствуют. И ещё у этой истории нет конца. Но если вы узнали в ней кого-то, если вы узнали в ней себя, то просто произнесите вслух три раза: «люди не ресурс».
Люди не ресурс. И не надо с ними работать как с ресурсом. Если заменить слово на что-то конкретное, например, «станок», разница становится нагляднее. Людей не нанимают как ресурсы, людей не учат как ресурсы, их выращивают по-другому, прокачивают по-другому, тренируют по-другому, с ними общаются по-другому.
Если вы относитесь к людям как к ресурсу, вы можете показывать отличные результаты в бизнесе, быть прибыльны, успешны и знамениты. Но вы будете плохим менеджером. И ваши люди будут это знать.
В одной близкой галактике, в неназванной компании было много проектов. И каждый проект сложный и большой. Чтобы проект развивался, нужно было много специалистов: программистов, дизайнеров, аналитиков и многих других.
Находить и удерживать таких людей тяжело. Люди не столы, их нельзя подвезти в офис из Икеи в течение дня.
Но менеджеры компании это не осознавали или регулярно об этом забывали. Называли специалистов словом «ресурс» и всё время искали эти самые ресурсы. Они каждый день играли в игру по добыванию ресурсов, по отбиванию ресурсов, по отстаиванию ресурсов, по перебалансировке ресурсов, иногда даже по накапливанию ресурсов впрок.
Проектов становилось больше, сложность возрастала, цена изменений тоже. Менеджеры продолжали играть.
Специалисты переходили между командами, переходили между проектами, скакали между задачами. Затем им надоедало, они выгорали, и уходили. Их пытались удержать, рассказывали, что всё изменится, станет лучше, по-другому. Но ничего не менялось. Их мечты о лучшем будущем разбивались о суровую реальность. И они теряли веру. Менеджеры продолжали играть.
Когда сдвигался запланированный срок релиза, менеджеры говорили, что у них не хватило ресурсов. Когда новая фича переносилась на следующий релиз, у менеджеров не хватало ресурсов. Если перед релизом в важной фиче обнаруживалось множество багов и недоработок, это объясняли нехваткой ресурсов, а иногда и их качеством. Менеджеры продолжали играть.
Эта история не про конкретную компанию и конкретных менеджеров, любые совпадения случайны, все имена выдуманы и вообще отсутствуют. И ещё у этой истории нет конца. Но если вы узнали в ней кого-то, если вы узнали в ней себя, то просто произнесите вслух три раза: «люди не ресурс».
Люди не ресурс. И не надо с ними работать как с ресурсом. Если заменить слово на что-то конкретное, например, «станок», разница становится нагляднее. Людей не нанимают как ресурсы, людей не учат как ресурсы, их выращивают по-другому, прокачивают по-другому, тренируют по-другому, с ними общаются по-другому.
Если вы относитесь к людям как к ресурсу, вы можете показывать отличные результаты в бизнесе, быть прибыльны, успешны и знамениты. Но вы будете плохим менеджером. И ваши люди будут это знать.
Вакансии для менеджеров в IT
Хочу рассказать о своём небольшом сайд-проекте — сервисе по поиску работы для менеджеров в IT https://itmanagerjobs.io. Основной функционал ещё в разработке, но полезные штуки уже есть:
- Собираем вакансии для менеджеров с ключевых русскоязычных площадок и нескольких десятков сайтов западных компаний. Доступ к базе скоро откроем публично, пока присылаем ссылку, оставившим email.
- Автоматически определяем категории вакансий: project, product, engineering.
- Каждую неделю в полуавтоматическом выпускаем подборки вакансий в телеграм канале https://t.me/itmanagerjobs_ru
Ближайшие планы:
- Запуск регулярных рассылок на почту
- Расширение базы вакансий (добавим ещё несколько нишевых площадок и тысячи сайтов компаний напрямую)
- Полноценная веб-версия для вывода вакансий, а не только виджет на Airtable 🙃
Далее планируем запустить и другие сервисы: управление откликами вакансий, подбор релевантных вакансий по приватной анкете. Будет чуть больше, чем джобборда. Но будущее покрыто туманом. Лучше оповестим, когда появится.
Это сайд/пет-проект, который мы делаем вдвоём с другом парт-тайм. Идея родилась из собственных потребностей, но будет круто, если ещё кому-то будет полезно.
P. S. Снова писать код помимо чисто менеджерской работы — кайф! Давно не хватало работы руками.
Хочу рассказать о своём небольшом сайд-проекте — сервисе по поиску работы для менеджеров в IT https://itmanagerjobs.io. Основной функционал ещё в разработке, но полезные штуки уже есть:
- Собираем вакансии для менеджеров с ключевых русскоязычных площадок и нескольких десятков сайтов западных компаний. Доступ к базе скоро откроем публично, пока присылаем ссылку, оставившим email.
- Автоматически определяем категории вакансий: project, product, engineering.
- Каждую неделю в полуавтоматическом выпускаем подборки вакансий в телеграм канале https://t.me/itmanagerjobs_ru
Ближайшие планы:
- Запуск регулярных рассылок на почту
- Расширение базы вакансий (добавим ещё несколько нишевых площадок и тысячи сайтов компаний напрямую)
- Полноценная веб-версия для вывода вакансий, а не только виджет на Airtable 🙃
Далее планируем запустить и другие сервисы: управление откликами вакансий, подбор релевантных вакансий по приватной анкете. Будет чуть больше, чем джобборда. Но будущее покрыто туманом. Лучше оповестим, когда появится.
Это сайд/пет-проект, который мы делаем вдвоём с другом парт-тайм. Идея родилась из собственных потребностей, но будет круто, если ещё кому-то будет полезно.
P. S. Снова писать код помимо чисто менеджерской работы — кайф! Давно не хватало работы руками.
Слайды презентации «Сам себе менеджер»
В ноябре 2019-го года я сделал для своей команды небольшой доклад под названием «Сам себе менеджер». Хочу поделиться слайдами презентации.
Тогда я руководил автоматизацией маркетинга в компании Playrix, у нас был недельный сбор в офисе в Вологде, всю неделю мы работали вместе, делились знаниями, планировали следующие крупные проекты.
У моей презентации было несколько целей:
1. сблизить контексты и определения — мы активно перестраивали процессы, поэтому важно было рассказать команде, на каких принципах строятся изменения
2. рассказать о принципах и приёмах, на которые я сам опираюсь в работе
3. сделать каждого члена команды ещё более самостоятельным, дать ему соответствующих инструментарий. Этот пункт преимущественно и дал название выступлению.
У презентации есть небольшая вводная с базовыми принципами и две основные части: как работать с задачами и как работать со временем.
Были планы на ещё как минимум две: как работать с людьми и как работать с собой. Про них есть пара слайдов в конце. Но, к сожалению, полноценно до них не добрался.
Три основных источника информации, на которыя я опирался:
- Советы Бюро Горбунова
- Книга Shape Up
- Книга NoEstimates
В текущую версию внёс минимальные изменения. Т.к. слайды дают мало контекста без сопровождающего рассказа, в pdf добавлены presenters notes, они немного дополняют картинку. Некоторые идеи из презентации планирую превратить со временем в отдельные заметки.
В ноябре 2019-го года я сделал для своей команды небольшой доклад под названием «Сам себе менеджер». Хочу поделиться слайдами презентации.
Тогда я руководил автоматизацией маркетинга в компании Playrix, у нас был недельный сбор в офисе в Вологде, всю неделю мы работали вместе, делились знаниями, планировали следующие крупные проекты.
У моей презентации было несколько целей:
1. сблизить контексты и определения — мы активно перестраивали процессы, поэтому важно было рассказать команде, на каких принципах строятся изменения
2. рассказать о принципах и приёмах, на которые я сам опираюсь в работе
3. сделать каждого члена команды ещё более самостоятельным, дать ему соответствующих инструментарий. Этот пункт преимущественно и дал название выступлению.
У презентации есть небольшая вводная с базовыми принципами и две основные части: как работать с задачами и как работать со временем.
Были планы на ещё как минимум две: как работать с людьми и как работать с собой. Про них есть пара слайдов в конце. Но, к сожалению, полноценно до них не добрался.
Три основных источника информации, на которыя я опирался:
- Советы Бюро Горбунова
- Книга Shape Up
- Книга NoEstimates
В текущую версию внёс минимальные изменения. Т.к. слайды дают мало контекста без сопровождающего рассказа, в pdf добавлены presenters notes, они немного дополняют картинку. Некоторые идеи из презентации планирую превратить со временем в отдельные заметки.
Говорить об очевидном
В один из сомнительных периодов моей университетской жизни в общежитии у нас с соседом по комнате было развлечение: освободить вечер, купить стратегический запас пива и дошираков, забыть обо всём, забить на всё и нон-стопом смотреть мультсериал «Поллитровая мышь» (12 oz. Mouse). Если вам нравятся сверхпримитивная анимация и плоские шутки, советую.
С тех времён прошло больше 10 лет, я не помню ни сюжета сериала, ни содержимого хотя бы одной серии. Но одна цитата осталась в голове до сих пор. Произнёс её Квадратный Бизнесмен (в оригинале Rectangular Businessman):
«Я говорю только об очевидном, поэтому в любом разговоре на 100% прав».
— Квадратный Бизнесмен
Чаще всего она приходит в голову, когда что-то посчитали очевидным, и об этом не поговорили.
К сожалению, то, что очевидно одному, далеко не всегда очевидно другому. То, что очевидно в одной ситуации или процессе, может быть совсем неочевидно в других случаях. В проекте могут быть очевидные проблемы, но о них не говорят. И как следствие проблемы не решаются, растут, накапливаются.
Часто об очевидном не говорят, если боятся или думают, что ничего не поменяется. Ещё хуже, если подразумевают, что «и так все всё знают». Почему-то во многих командах и компаниях говорить об очевидном стесняются или стыдятся. В итоге об очевидном забывают, его игнорируют и упускают.
На самом деле, говорить об очевидном — хорошо и полезно. Это помогает свериться на самом базовом уровне, разрешить потенциально критичные ситуации. Говорить об очевидном — это честно по отношению к себе и другим.
Говорите об очевидном. И в любом разговоре будете на 100% правыми.
https://onehandclapping.ru/talk-about-the-obvious
В один из сомнительных периодов моей университетской жизни в общежитии у нас с соседом по комнате было развлечение: освободить вечер, купить стратегический запас пива и дошираков, забыть обо всём, забить на всё и нон-стопом смотреть мультсериал «Поллитровая мышь» (12 oz. Mouse). Если вам нравятся сверхпримитивная анимация и плоские шутки, советую.
С тех времён прошло больше 10 лет, я не помню ни сюжета сериала, ни содержимого хотя бы одной серии. Но одна цитата осталась в голове до сих пор. Произнёс её Квадратный Бизнесмен (в оригинале Rectangular Businessman):
«Я говорю только об очевидном, поэтому в любом разговоре на 100% прав».
— Квадратный Бизнесмен
Чаще всего она приходит в голову, когда что-то посчитали очевидным, и об этом не поговорили.
К сожалению, то, что очевидно одному, далеко не всегда очевидно другому. То, что очевидно в одной ситуации или процессе, может быть совсем неочевидно в других случаях. В проекте могут быть очевидные проблемы, но о них не говорят. И как следствие проблемы не решаются, растут, накапливаются.
Часто об очевидном не говорят, если боятся или думают, что ничего не поменяется. Ещё хуже, если подразумевают, что «и так все всё знают». Почему-то во многих командах и компаниях говорить об очевидном стесняются или стыдятся. В итоге об очевидном забывают, его игнорируют и упускают.
На самом деле, говорить об очевидном — хорошо и полезно. Это помогает свериться на самом базовом уровне, разрешить потенциально критичные ситуации. Говорить об очевидном — это честно по отношению к себе и другим.
Говорите об очевидном. И в любом разговоре будете на 100% правыми.
https://onehandclapping.ru/talk-about-the-obvious
Twitter на английском
У этого канала не так давно появился экспериментальный сателит — твиттер на английском.
Большую часть того, что читаю, смотрю и изучаю, я потребляю на английском языке. Мои заметки — смесь оригинальных цитат и интерпретаций на русском. Давно хотелось больше практики в формулировании мыслей на английском. В формат статей инвестировать время пока не готов, а для коротких постов твиттер подходящая площадка.
Если используете твиттер и читаете на английском, присоединяйтесь: https://twitter.com/nhndclppng
У этого канала не так давно появился экспериментальный сателит — твиттер на английском.
Большую часть того, что читаю, смотрю и изучаю, я потребляю на английском языке. Мои заметки — смесь оригинальных цитат и интерпретаций на русском. Давно хотелось больше практики в формулировании мыслей на английском. В формат статей инвестировать время пока не готов, а для коротких постов твиттер подходящая площадка.
Если используете твиттер и читаете на английском, присоединяйтесь: https://twitter.com/nhndclppng
Ryan’s Newsletter
Райан Сингер (Ryan Singer) — глава продуктовой стратегии в Basecamp и автор книги ShapeUp.
В ноябре 2020 он запустил свою рассылку, Ryan’s Newsletter, где делится своими наблюдениями, мыслями и идеями на основе того, над чем сейчас работает. Формат очень лёгкий и приятный. Как он сам описывает, это почти как Твиттер, но с добавлением контекста.
Мне очень интересна работа Райана, она на стыке управления продуктом и процессами. И он показывает реальный внутряк: свой процесс на реальных фичах, со скриншотами скетчей, схем, диаграмм и документов, описывает ход мышления, недавно записал видео о том, как сейчас пробует коммуницировать концепты новых фич команде, используя идею языка паттернов (pattern language).
На текущий момент вышло пять выпусков, в каждом 2-3 идеи. Вот несколько, которые меня зацепили.
1. Demand-side differentiation (дифференциация по спросу)
Разные подходы часто ведут к соревнованию, какой из них единственно верный. Но в этом соревновании нельзя победить, т.к. подходы контекстны ситуации, компании, людям. Выход — дифференциироваться по спросу.
Например, есть стопицот таскменеджеров, которые продвигаются, подчёркивая разницу в интерфейсе и фичи — это дифференциация по предложению. Но если сфокусироваться на том, какой аудитории идеально подходит конкретный таскменеджер и для каких задач, то это уже поиск отличий по спросу.
2. Sequence != priority (последовательность — это не приоритет)
Это очень красивая и новая для меня мысль. Я привык думать о приоритете в контексте последовательности действий. Но, оказывается, их можно разделить.
Приоритет по сути бинарное состояние: must-have или nice-to-have в рамках ограничения времени. Когда установлен этот приоритет, уже можно говорить о последовательности в рамках must-have элементов.
> Sequence and priority sound similar. It can be natural to say "I'll use the diagram to figure out what to prioritize first." But actually, given a fixed time box, sequence and priority are orthogonal. Sequence is about order: first, second, ... last. Priority is about what's in and what's out: what is a "must" within the given time constraint and what is "nice to have." When every element in a system is a "must," you have a sequencing problem
3. Измерение использования фичи через отношение сигнала к шуму
Здесь Райан рассуждает о том, как можно измерить, что продукт работает для его пользователей так, как должен, через определение «намерения». И примеряет один из подходов статистических методов Тагучи, чтобы определить метрику правильности использования фичи.
Отношение сигнала к шуму для функции системы должно показывать, насколько часто функция используется так, как задумано, по отношению к общему числу использований. Детали лучше прочитать в рассылке, т.к. пересказ потянет на отдельный пост.
Подписаться на рассылку можно по ссылке: https://mailchi.mp/hey/ryans-newsletter
Сайт Райана: https://feltpresence.com/
Ключевые мысли из книги ShapeUp: https://onehandclapping.ru/shapup-by-ryan-singer-from-basecamp
Райан Сингер (Ryan Singer) — глава продуктовой стратегии в Basecamp и автор книги ShapeUp.
В ноябре 2020 он запустил свою рассылку, Ryan’s Newsletter, где делится своими наблюдениями, мыслями и идеями на основе того, над чем сейчас работает. Формат очень лёгкий и приятный. Как он сам описывает, это почти как Твиттер, но с добавлением контекста.
Мне очень интересна работа Райана, она на стыке управления продуктом и процессами. И он показывает реальный внутряк: свой процесс на реальных фичах, со скриншотами скетчей, схем, диаграмм и документов, описывает ход мышления, недавно записал видео о том, как сейчас пробует коммуницировать концепты новых фич команде, используя идею языка паттернов (pattern language).
На текущий момент вышло пять выпусков, в каждом 2-3 идеи. Вот несколько, которые меня зацепили.
1. Demand-side differentiation (дифференциация по спросу)
Разные подходы часто ведут к соревнованию, какой из них единственно верный. Но в этом соревновании нельзя победить, т.к. подходы контекстны ситуации, компании, людям. Выход — дифференциироваться по спросу.
Например, есть стопицот таскменеджеров, которые продвигаются, подчёркивая разницу в интерфейсе и фичи — это дифференциация по предложению. Но если сфокусироваться на том, какой аудитории идеально подходит конкретный таскменеджер и для каких задач, то это уже поиск отличий по спросу.
2. Sequence != priority (последовательность — это не приоритет)
Это очень красивая и новая для меня мысль. Я привык думать о приоритете в контексте последовательности действий. Но, оказывается, их можно разделить.
Приоритет по сути бинарное состояние: must-have или nice-to-have в рамках ограничения времени. Когда установлен этот приоритет, уже можно говорить о последовательности в рамках must-have элементов.
> Sequence and priority sound similar. It can be natural to say "I'll use the diagram to figure out what to prioritize first." But actually, given a fixed time box, sequence and priority are orthogonal. Sequence is about order: first, second, ... last. Priority is about what's in and what's out: what is a "must" within the given time constraint and what is "nice to have." When every element in a system is a "must," you have a sequencing problem
3. Измерение использования фичи через отношение сигнала к шуму
Здесь Райан рассуждает о том, как можно измерить, что продукт работает для его пользователей так, как должен, через определение «намерения». И примеряет один из подходов статистических методов Тагучи, чтобы определить метрику правильности использования фичи.
Отношение сигнала к шуму для функции системы должно показывать, насколько часто функция используется так, как задумано, по отношению к общему числу использований. Детали лучше прочитать в рассылке, т.к. пересказ потянет на отдельный пост.
Подписаться на рассылку можно по ссылке: https://mailchi.mp/hey/ryans-newsletter
Сайт Райана: https://feltpresence.com/
Ключевые мысли из книги ShapeUp: https://onehandclapping.ru/shapup-by-ryan-singer-from-basecamp
Десять ключевых мыслей c курса Change Basics
В декабре прошёл курс-сериал Change Basics от Наташи Бабаевой и Школы ченджеров.
Change Basics выстроен в виде истории, в каждой из 10 серий героиня падает всё глубже в кроличью нору, а мы смотрим, как ей удаётся это осознать и найти равновесие. Ключевые идеи подаются через призму разделения активностей на «чендж и ран» по модели компании Gartner, её также называют бимодальной (Bimodal).
Курс классный. Уже купил его в подарок другу на Новый год. По-моему, это главный показатель крутости продукта — желание подсадить на него всех вокруг.
Для начинающих специалистов — это просто находка, для уже более спелых и зрелых — отличный способ ещё раз вспомнить основы, пересистематизировать знания на базе новой подачи и ситуаций и, конечно, пожалеть, что такого курса не выдавали на старте карьеры.
При прохождении составил себе подробный коспект, но поделюсь десятью мыслями из курса, которые для меня показались самыми важными и актуальными.
1. Не смешивать ран и чендж. Это касается и правил игры, условий работы, и оценки ошибок, и измерения прогресса, и подходов, и оценки качества, и отношения к процессу и результатам. Разделение помогает избавиться от вредных искажений восприятия.
2. Чтобы быть хорошим ченджером, надо понимать ран. Чтобы быть хорошим раннером, надо понимать чендж. Этапы ченджа и рана переплетены, понимание улучшает взаимные и общие результаты.
3. Ран можно и нужно уплотнять. Для этого есть понятный арсенал: визуализации, шаблоны, чек-листы, «полуфабрикаты», анализ, оптимизация.
4. Не забывать мечтать. Dreamability — дополнение привычных компонентов дизайн-мышления (desirability, viability, feasibility). Вопрос: от чего прёт?
5. Планировать назад. От дедлайна, от желаемого результата, от ограничений.
6. Праздновать эмоциями, как дети. И хорошее, и плохое. Часто. Не вечеринками, не алкоголем.
7. Докручивать цикл. Качественный анализ итогов проекта или итерации — основа дальнейшего роста.
8. Ограничивать Work in Progress. От уровня проектов, до уровня отдельных задач.
9. Нанимать людей круче себя.
10. Не срезать коммуникацию. Через неё решаются многие проблемы команды.
Это всё только верхушка айсберга, под водой гораздо больше идей, нюансов и деталей.
Я был участником первого потока, брал тариф с домашкой, но постепенно на неё забил (зря). У курса офигительный лендинг https://basics.changerschool.ru/: понятно, подробно, полно и с картинкам. Советую.
В декабре прошёл курс-сериал Change Basics от Наташи Бабаевой и Школы ченджеров.
Change Basics выстроен в виде истории, в каждой из 10 серий героиня падает всё глубже в кроличью нору, а мы смотрим, как ей удаётся это осознать и найти равновесие. Ключевые идеи подаются через призму разделения активностей на «чендж и ран» по модели компании Gartner, её также называют бимодальной (Bimodal).
Курс классный. Уже купил его в подарок другу на Новый год. По-моему, это главный показатель крутости продукта — желание подсадить на него всех вокруг.
Для начинающих специалистов — это просто находка, для уже более спелых и зрелых — отличный способ ещё раз вспомнить основы, пересистематизировать знания на базе новой подачи и ситуаций и, конечно, пожалеть, что такого курса не выдавали на старте карьеры.
При прохождении составил себе подробный коспект, но поделюсь десятью мыслями из курса, которые для меня показались самыми важными и актуальными.
1. Не смешивать ран и чендж. Это касается и правил игры, условий работы, и оценки ошибок, и измерения прогресса, и подходов, и оценки качества, и отношения к процессу и результатам. Разделение помогает избавиться от вредных искажений восприятия.
2. Чтобы быть хорошим ченджером, надо понимать ран. Чтобы быть хорошим раннером, надо понимать чендж. Этапы ченджа и рана переплетены, понимание улучшает взаимные и общие результаты.
3. Ран можно и нужно уплотнять. Для этого есть понятный арсенал: визуализации, шаблоны, чек-листы, «полуфабрикаты», анализ, оптимизация.
4. Не забывать мечтать. Dreamability — дополнение привычных компонентов дизайн-мышления (desirability, viability, feasibility). Вопрос: от чего прёт?
5. Планировать назад. От дедлайна, от желаемого результата, от ограничений.
6. Праздновать эмоциями, как дети. И хорошее, и плохое. Часто. Не вечеринками, не алкоголем.
7. Докручивать цикл. Качественный анализ итогов проекта или итерации — основа дальнейшего роста.
8. Ограничивать Work in Progress. От уровня проектов, до уровня отдельных задач.
9. Нанимать людей круче себя.
10. Не срезать коммуникацию. Через неё решаются многие проблемы команды.
Это всё только верхушка айсберга, под водой гораздо больше идей, нюансов и деталей.
Я был участником первого потока, брал тариф с домашкой, но постепенно на неё забил (зря). У курса офигительный лендинг https://basics.changerschool.ru/: понятно, подробно, полно и с картинкам. Советую.
Настройка MacBook для замороченного менеджера
Собрал в один пост всё, что настраиваю и устанавливаю на своём макбуке для комфортной ежедневной работы.
Может показаться, что заморочек по настройкам слишком много, но по сути они все направлены на то, чтобы:
- минимизировать отвлечения и шум
- убедиться в базовых мерах безопасности
- настроить всё так, чтобы потом не замечать и не вспоминать про ось, фокусируясь только на текущем деле
В канале теперь включены комментарии. Делитесь своими фишками, рекомендуйте софт, расскажите, что оказалось полезным.
https://onehandclapping.ru/macbook-setup-for-managers
Собрал в один пост всё, что настраиваю и устанавливаю на своём макбуке для комфортной ежедневной работы.
Может показаться, что заморочек по настройкам слишком много, но по сути они все направлены на то, чтобы:
- минимизировать отвлечения и шум
- убедиться в базовых мерах безопасности
- настроить всё так, чтобы потом не замечать и не вспоминать про ось, фокусируясь только на текущем деле
В канале теперь включены комментарии. Делитесь своими фишками, рекомендуйте софт, расскажите, что оказалось полезным.
https://onehandclapping.ru/macbook-setup-for-managers
"The Power of Habit" by Charles Duhigg
Откопал и обработал заметки и сохранённые цитаты из книги Чарльза Дахигга «Сила Привычки».
Сейчас, в эпоху осознанности, медитаций и домашнего просветления, эти идеи растиражированы довольно сильно. Но в своё время, в 2014 году, книга стала для меня небольшим откровением.
Ключевая мысль: мозг ленивый, люди — влажные роботы, много стандартных программ которых работает по фреймворку cue -> routine -> reward (триггер -> действие -> награда). Награда даёт положительное подкрепление, и с каждым следующим триггером привычка становится всё сильнее.
Книга не перегружена наукой, построена на историях и примерах, читать интересно.
https://onehandclapping.ru/the-power-of-habit-by-charles-duhigg
Откопал и обработал заметки и сохранённые цитаты из книги Чарльза Дахигга «Сила Привычки».
Сейчас, в эпоху осознанности, медитаций и домашнего просветления, эти идеи растиражированы довольно сильно. Но в своё время, в 2014 году, книга стала для меня небольшим откровением.
Ключевая мысль: мозг ленивый, люди — влажные роботы, много стандартных программ которых работает по фреймворку cue -> routine -> reward (триггер -> действие -> награда). Награда даёт положительное подкрепление, и с каждым следующим триггером привычка становится всё сильнее.
Книга не перегружена наукой, построена на историях и примерах, читать интересно.
https://onehandclapping.ru/the-power-of-habit-by-charles-duhigg
Обмазаться
Чтобы эффективно и быстро погрузиться в новый проект, надо создать условия, при которых новый контекст обволакивает тебя со всех сторон, лезет из всех внешних щелей во все предназначенные для этого внутренние, буквально погружает тебя с головой.
За последние полтора года я несколько раз сталкивался с проектами в сферах, где у меня было мало опыта. На каждом новом включении я применял примерно одинаковый подход, который для себя называю «обмазаться». Термин бережно заимствован у бывших коллег, но автора не помню.
На практике это означает воткнуться во все информационные потоки:
- подписаться на апдейты проектов в системе ведения задач и на апдейты ключевых задач
- сходить на все командые встречи и обсуждения
- попасть во все возможные каналы общения (slack и подобное)
- прочитать все имеющиеся материалы из документов, документаций и баз знаний
- пообщаться со всеми ключевыми ребятами и выборочно с линейными специалистами
Обмазаться — это аналог первой фазы любого research, когда идёт активный, немного хаотичный сбор материалов. На этом этапе надо впитывать и перемалывать контекст, привыкать, вычленять терминологию, задавать вопросы, вмешательство в ход событий должно быть минимально.
Ещё один аналог — это O из OPDCA. Observe, наблюдай.
Главный трюк обмазывания — вовремя остановиться. Иначе станет сложно отмываться. Поэтому на старте надо обмазаться по полной, а затем методично сокращать включения до нужного уровня погружения и детализации, сохраняя знание, куда можно копнуть в случае конкретного вопроса.
Чтобы эффективно и быстро погрузиться в новый проект, надо создать условия, при которых новый контекст обволакивает тебя со всех сторон, лезет из всех внешних щелей во все предназначенные для этого внутренние, буквально погружает тебя с головой.
За последние полтора года я несколько раз сталкивался с проектами в сферах, где у меня было мало опыта. На каждом новом включении я применял примерно одинаковый подход, который для себя называю «обмазаться». Термин бережно заимствован у бывших коллег, но автора не помню.
На практике это означает воткнуться во все информационные потоки:
- подписаться на апдейты проектов в системе ведения задач и на апдейты ключевых задач
- сходить на все командые встречи и обсуждения
- попасть во все возможные каналы общения (slack и подобное)
- прочитать все имеющиеся материалы из документов, документаций и баз знаний
- пообщаться со всеми ключевыми ребятами и выборочно с линейными специалистами
Обмазаться — это аналог первой фазы любого research, когда идёт активный, немного хаотичный сбор материалов. На этом этапе надо впитывать и перемалывать контекст, привыкать, вычленять терминологию, задавать вопросы, вмешательство в ход событий должно быть минимально.
Ещё один аналог — это O из OPDCA. Observe, наблюдай.
Главный трюк обмазывания — вовремя остановиться. Иначе станет сложно отмываться. Поэтому на старте надо обмазаться по полной, а затем методично сокращать включения до нужного уровня погружения и детализации, сохраняя знание, куда можно копнуть в случае конкретного вопроса.
Learning How to Learn
Чтобы понять, что такое рекурсия, надо понять, что такое рекурсия. А чтобы научиться учиться, надо пройти курс Learning How to Learn на курсере.
Заканчиваю читать книгу Mindshift, которую написала Барбара Оакли (Barbara Oakley), поэтому решил освежить в памяти материалы её курсов (есть ещё курс, который называется Mindshift).
В Learning How to Learn Барбара рассказывает, что лучшему запоминанию способствуют, например:
- здоровый сон + повторение материала перед сном
- работа с материалом: подчеркивать, выделять, проговаривать
- распределение обучение во времени (spaced repetition)
- разбиение материала на кусочки (chunking)
- занятия спортом
- ещё куча вещей
Там же будет про то, как творчески подойти к прокрастинации и работе с памятью, про то как дофамин не всегда одинаково полезен, а ацетилхолин и серотонин в этом плане кажутся получше.
По ссылке ключевые идеи + более подробный конспект. Советую пройти курс самостоятельно, он совсем ненапряженый, но важный для осознания базовых вещей по работе с любым обучением.
https://onehandclapping.ru/learning-how-to-learn
Чтобы понять, что такое рекурсия, надо понять, что такое рекурсия. А чтобы научиться учиться, надо пройти курс Learning How to Learn на курсере.
Заканчиваю читать книгу Mindshift, которую написала Барбара Оакли (Barbara Oakley), поэтому решил освежить в памяти материалы её курсов (есть ещё курс, который называется Mindshift).
В Learning How to Learn Барбара рассказывает, что лучшему запоминанию способствуют, например:
- здоровый сон + повторение материала перед сном
- работа с материалом: подчеркивать, выделять, проговаривать
- распределение обучение во времени (spaced repetition)
- разбиение материала на кусочки (chunking)
- занятия спортом
- ещё куча вещей
Там же будет про то, как творчески подойти к прокрастинации и работе с памятью, про то как дофамин не всегда одинаково полезен, а ацетилхолин и серотонин в этом плане кажутся получше.
По ссылке ключевые идеи + более подробный конспект. Советую пройти курс самостоятельно, он совсем ненапряженый, но важный для осознания базовых вещей по работе с любым обучением.
https://onehandclapping.ru/learning-how-to-learn
Рекомендую
В последнее время всё чаще делюсь с коллегами и друзьями рекомендациями курсов, книг и прочего по менеджменту и вокруг него. Решил сделать подборку и собрал всё на одной странице, буду постепенно дополнять и обновлять. Пока есть курсы и книги. Очередность ничего не значит, порядок случайный.
Только опробованное лично и то, что считаю полезным.
https://onehandclapping.ru/recommendations
В последнее время всё чаще делюсь с коллегами и друзьями рекомендациями курсов, книг и прочего по менеджменту и вокруг него. Решил сделать подборку и собрал всё на одной странице, буду постепенно дополнять и обновлять. Пока есть курсы и книги. Очередность ничего не значит, порядок случайный.
Только опробованное лично и то, что считаю полезным.
https://onehandclapping.ru/recommendations
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
Посмотрел, законспектировал и выделил основное из воркшопа Clair Lew, CEO сервиса Know Your Team, про то как грамотно управлять удалённой командой. В идеях видно наследие идеалогии Basecamp. Но мне оказалось не лишним себе ещё раз напомнить. Вот самое главное:
1. Асинхронность — самый важный и при этом недооценённый бонус удалённой работы. При этом самый нетривиальный в настройке. Менее реактивная коммуникация даёт возможность фокусироваться на задачах и думать.
2. Удалённо работать можно только на доверии. Трекинг и микроменеджмент это убивают. Тащат понятная трансляция ожиданий в одну сторону и прозрачный прогресс (в идеале автоматический) в другую сторону.
3. Настроенные процессы очень важны. Начать с базы: док-методичка «как мы работаем», правила коммуникации, вопросы по таймзонам и ожиданиям по времени вообще. Дальше подкручивать.
4. Уделить внимание социальным связям. По сути офисные неформальные коммуникации надо адаптировать для удалённой работы. Потому что работа это огромная часть жизни людей, и это не только про «фигачить», но и про коммуникацию.
5. Встречи один-на-один: не превращать в сверку по текущему статусу, а стараться раскрыть потенциал или потенциальные проблемы. Регулярность встреч решает.
Более подробный конспект на английском: https://onehandclapping.ru/claire-lew-how-to-manage-a-remote-team-well
Вера и идеи
В фильме замечательного режиссёра Кевина Смита «Догма» на тему веры и идей мне запомнилось два диалога.
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.
В русской озвучке последний диалог звучал так:
— Кризис веры миновал?
— Я получила больше, чем заказывала.
— Не засуха, так ливень. Укрепилась верой?
— Нет. Но обогатилась идеями.
— Браво.
Если представить, что Вифания и Руфус два менеджера, и одна из них сначала перегорела на работе, но потом пришла в себя через почти божественное касание, то мы получаем нужный контекст. И цитирование фильма «Догма» выглядит уже не так странно.
Вера — отличный инструмент создания интерсубъективной реальности для любой группы людей. В том числе компании или, более локально, команды. Но он обладает существенным недостатком — мы воспринимаем веру догматично. Поэтому всё, что переходит в разряд веры, а точнее то, что мы переводим в разряд веры, нам самим же становится сложно менять, оно реже подвергается сомнениям. Вера становится «слепой», команда негибкой, инерция неизбежной, а люди постепенно начинают сгорать. Это в том числе случай, когда в ответ на «почему?» получаем ответ «мы всегда так делали». Да, я специально обобщаю и утрирую, чтобы сделать акцент.
Идеи как противопоставление веры очень крутой концепт. Идеи свежи. Идеи могут быть неверны, но это нормально, потому что идеи ничего не стоят сами по себе. Без реализации, без валидации, без проверки гипотез идея очень хрупка. Идея стимулирует к действию, открыта к неудобным вопросам. Она лучше поддаётся трансформации и адаптации. И поэтому идеи более удачный инструмент создания коллективного знания.
В вере нет ничего плохого, если она не доведена до фанатизма или автоматизма. Но лучше всё-таки обогащайтесь идеями.
В фильме замечательного режиссёра Кевина Смита «Догма» на тему веры и идей мне запомнилось два диалога.
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.
В русской озвучке последний диалог звучал так:
— Кризис веры миновал?
— Я получила больше, чем заказывала.
— Не засуха, так ливень. Укрепилась верой?
— Нет. Но обогатилась идеями.
— Браво.
Если представить, что Вифания и Руфус два менеджера, и одна из них сначала перегорела на работе, но потом пришла в себя через почти божественное касание, то мы получаем нужный контекст. И цитирование фильма «Догма» выглядит уже не так странно.
Вера — отличный инструмент создания интерсубъективной реальности для любой группы людей. В том числе компании или, более локально, команды. Но он обладает существенным недостатком — мы воспринимаем веру догматично. Поэтому всё, что переходит в разряд веры, а точнее то, что мы переводим в разряд веры, нам самим же становится сложно менять, оно реже подвергается сомнениям. Вера становится «слепой», команда негибкой, инерция неизбежной, а люди постепенно начинают сгорать. Это в том числе случай, когда в ответ на «почему?» получаем ответ «мы всегда так делали». Да, я специально обобщаю и утрирую, чтобы сделать акцент.
Идеи как противопоставление веры очень крутой концепт. Идеи свежи. Идеи могут быть неверны, но это нормально, потому что идеи ничего не стоят сами по себе. Без реализации, без валидации, без проверки гипотез идея очень хрупка. Идея стимулирует к действию, открыта к неудобным вопросам. Она лучше поддаётся трансформации и адаптации. И поэтому идеи более удачный инструмент создания коллективного знания.
В вере нет ничего плохого, если она не доведена до фанатизма или автоматизма. Но лучше всё-таки обогащайтесь идеями.