Треугольник принятия решений
Я периодически делюсь статьями про разные практики документирования принимаемых в команде решений. Классический пример – Architecture Decision Records, документы, которые сохраняют весь контекст когда-то принятых решений про дизайн проекта. Так вот, вне зависимости, какое именно решение вы документируете, у него можно выделить три ключевых компонента:
👉Желаемое будущее, в которое вы хотите прийти.
👉Действие, которое должно привести вас в это будущее.
👉Триггер – событие, которое вызвало необходимость принятия решения.
Если использовать эти компоненты как вершины треугольника, мы получаем отличную ментальную модель, в которой его стороны становятся дополнительными аспектами принятия решения:
👉Критерии: ограничения, которые влияют на то, в какое будущее мы хотим прийти, и желаемые критерии успеха.
👉Сценарии: все возможные варианты будущего, к которым может привести выбранное действие.
👉Анализ: сбор информации, который помогает перейти от триггера к непосредственному действию.
После того, как решение принято и исполнено, с помощью этой же модели удобно сравнивать ожидание и реальность (картинка как раз про это). Если модель заинтересовала, то в статье есть очень подробный пример продуктового решения, разложенного по этой модели.
Я периодически делюсь статьями про разные практики документирования принимаемых в команде решений. Классический пример – Architecture Decision Records, документы, которые сохраняют весь контекст когда-то принятых решений про дизайн проекта. Так вот, вне зависимости, какое именно решение вы документируете, у него можно выделить три ключевых компонента:
👉Желаемое будущее, в которое вы хотите прийти.
👉Действие, которое должно привести вас в это будущее.
👉Триггер – событие, которое вызвало необходимость принятия решения.
Если использовать эти компоненты как вершины треугольника, мы получаем отличную ментальную модель, в которой его стороны становятся дополнительными аспектами принятия решения:
👉Критерии: ограничения, которые влияют на то, в какое будущее мы хотим прийти, и желаемые критерии успеха.
👉Сценарии: все возможные варианты будущего, к которым может привести выбранное действие.
👉Анализ: сбор информации, который помогает перейти от триггера к непосредственному действию.
После того, как решение принято и исполнено, с помощью этой же модели удобно сравнивать ожидание и реальность (картинка как раз про это). Если модель заинтересовала, то в статье есть очень подробный пример продуктового решения, разложенного по этой модели.
Как прорабатывать свой performance review
Если вы смотрите новый сезон Severance, то там есть восхитительный момент с типичнейшим performance review. Герой справляется с его проработкой так себе, а вот вам в похожей ситуации поможет простой гайд:
👉Постарайтесь воспринимать performance review как ценный фидбэк, который поможет вам стать лучше. В реальности в значимом проценте компаний performance review – карго-культ, который приносит больше вреда, чем пользы. Но в любом случае вам стоит выжать из него максимум для себя, иначе зачем это все.
👉Если какой-то фидбэк вы не готовы принять, не надо сразу же спорить с ним. Возьмите время на то, чтобы подумать над уточняющими вопросами и вернуться к менеджеру или тому, кто этот фидбэк дал.
👉Определите для себя, с каким фидбэком вы по итогу согласны, а с каким нет. Вам точно не нужно пытаться исправлять все, о чем вам нафидбэчили другие люди. У всех есть свои предрассудки, да и вообще, вы не обязаны нравиться каждому.
👉Используйте ту часть обратной связи, с которой согласны, чтобы выработать план действий. Не нужно бросаться на все пункты одновременно, выберите самый импактящий на вашей текущей роли, и начните с него.
Если вы смотрите новый сезон Severance, то там есть восхитительный момент с типичнейшим performance review. Герой справляется с его проработкой так себе, а вот вам в похожей ситуации поможет простой гайд:
👉Постарайтесь воспринимать performance review как ценный фидбэк, который поможет вам стать лучше. В реальности в значимом проценте компаний performance review – карго-культ, который приносит больше вреда, чем пользы. Но в любом случае вам стоит выжать из него максимум для себя, иначе зачем это все.
👉Если какой-то фидбэк вы не готовы принять, не надо сразу же спорить с ним. Возьмите время на то, чтобы подумать над уточняющими вопросами и вернуться к менеджеру или тому, кто этот фидбэк дал.
👉Определите для себя, с каким фидбэком вы по итогу согласны, а с каким нет. Вам точно не нужно пытаться исправлять все, о чем вам нафидбэчили другие люди. У всех есть свои предрассудки, да и вообще, вы не обязаны нравиться каждому.
👉Используйте ту часть обратной связи, с которой согласны, чтобы выработать план действий. Не нужно бросаться на все пункты одновременно, выберите самый импактящий на вашей текущей роли, и начните с него.
Способы принятия решений в команде
Если в понедельник мы обсуждали довольно абстрактную модель принятия решений, то теперь держите максимально прикладные методы:
👉Голосование точками. Тут все стандартно, помогает быстро выбрать один ответ из множества, и при этом учесть мнение каждого.
👉Степень поддержки. Каждый участник оценивает решение по x-балльной шкале. Решение принято, только если средний уровннь поддержки больше нужного уровня.
👉Метод NUF. Взвешенная оценка – новизна (new), полезность (useful), осуществимость (feasible). Решение можно принимать как по общей оценке, так и выбрав один или несколько приоритетных критериев.
👉Игра в покер. Похоже на предыдущие методы, но проводится в закрытую. Все так же, как в planning poker – все выкладывают карты, вскрываются, затем владельцы минимальной и максимальной оценок спорят.
👉Метод парных сравнений. Выбираются критерии, каждое решение сравнивается с каждым, победитель получает +1 балл. Наилучшим становится тот вариант, который победил во всех парах.
А вообще, я наконец-то в отпуске, так что на этой и следующей неделе ежедневных статей не обещаю!
Если в понедельник мы обсуждали довольно абстрактную модель принятия решений, то теперь держите максимально прикладные методы:
👉Голосование точками. Тут все стандартно, помогает быстро выбрать один ответ из множества, и при этом учесть мнение каждого.
👉Степень поддержки. Каждый участник оценивает решение по x-балльной шкале. Решение принято, только если средний уровннь поддержки больше нужного уровня.
👉Метод NUF. Взвешенная оценка – новизна (new), полезность (useful), осуществимость (feasible). Решение можно принимать как по общей оценке, так и выбрав один или несколько приоритетных критериев.
👉Игра в покер. Похоже на предыдущие методы, но проводится в закрытую. Все так же, как в planning poker – все выкладывают карты, вскрываются, затем владельцы минимальной и максимальной оценок спорят.
👉Метод парных сравнений. Выбираются критерии, каждое решение сравнивается с каждым, победитель получает +1 балл. Наилучшим становится тот вариант, который победил во всех парах.
Хабр
Преодолеваем паралич выбора: более 10 методов принятия решений в команде
Привет, Хабр! Я Светлана Болсуновская, стратегический коуч-консультант в YADRO с 13-летним опытом в IT, помогаю командам и лидерам развиваться. Каждый день мы принимаем решения: иногда это...
AI фейки на собеседованиях
Буквально недавно к нам собеседовался русскоязычный продакт, который в начале разговора подключил к звонку Otter.ai (это такой сервис автоматической расшифровки звонков). Он очень бодро отвечал на все behavioral вопросы, а порой даже слишком бодро, подкрепляя свои истории кейсами других людей (а вы знаете, что с такой же проблемой сталкивался и Джобс...). Явно прокололся он в тот момент, когда пытался выговорить незнакомые ему сложные слова на английском языке. Короче говоря, наша гипотеза в том, что он автоматически расшифровывал наши вопросы, отправлял их LLM вместе с кастомными промптами, и весело зачитывал ответы.
Так вот, такой читинг – это еще цветочки. Держите дикую историю про то, как в один и тот же стартап собеседовались два польских программиста с идеальными техническими знаниями и небольшими желтыми флагами на скрининге и интервью с нанимающим менеджером. Только на последнем этапе стало понятно, что это – полностью AI-генерированные фейки, начиная от аватара на видео, заканчивая всем LinkedIn профилем.
Буквально недавно к нам собеседовался русскоязычный продакт, который в начале разговора подключил к звонку Otter.ai (это такой сервис автоматической расшифровки звонков). Он очень бодро отвечал на все behavioral вопросы, а порой даже слишком бодро, подкрепляя свои истории кейсами других людей (а вы знаете, что с такой же проблемой сталкивался и Джобс...). Явно прокололся он в тот момент, когда пытался выговорить незнакомые ему сложные слова на английском языке. Короче говоря, наша гипотеза в том, что он автоматически расшифровывал наши вопросы, отправлял их LLM вместе с кастомными промптами, и весело зачитывал ответы.
Так вот, такой читинг – это еще цветочки. Держите дикую историю про то, как в один и тот же стартап собеседовались два польских программиста с идеальными техническими знаниями и небольшими желтыми флагами на скрининге и интервью с нанимающим менеджером. Только на последнем этапе стало понятно, что это – полностью AI-генерированные фейки, начиная от аватара на видео, заканчивая всем LinkedIn профилем.
Как техническому менеджеру не терять свои навыки
1️⃣Периодически проходитесь и по всем этапам пользовательского пути, и по этапам стандартного процесса разработки в вашей команде, выписываете все проблемы, составляете friction log.
2️⃣Почти во всех командах львиная доля времени уходит на различную операционку – закрытие мелких багов, инфраструктурные задачи, решение инцидентов. Регулярный глубокий анализ всего, что происходит в этих областях, и поиск возможностей их оптимизировать – как помогут команде, так и дадут менеджеру больше контекста о происходящем.
3️⃣Участвуйте в той же ротации дежурных по инцидентам, что и вся команда. Вы сможете буквально на кончиках пальцев понимать, где в вашей системе самые проблемные места, насколько хорошо все документировано, и чем весь процесс можно сделать лучше.
4️⃣Возьмите на себя подготовку различных документов – и техдокументации, и пострмортемов, и ADR.
5️⃣Попробуйте периодически брать "engineerication"(engineer+vacation) – несколько дней или недель непрерывного времени, когда вы занимаетесь только инженерными задачами. Это особенно хорошо работает, когда нужно быстро погрузиться в новый домен.
1️⃣Периодически проходитесь и по всем этапам пользовательского пути, и по этапам стандартного процесса разработки в вашей команде, выписываете все проблемы, составляете friction log.
2️⃣Почти во всех командах львиная доля времени уходит на различную операционку – закрытие мелких багов, инфраструктурные задачи, решение инцидентов. Регулярный глубокий анализ всего, что происходит в этих областях, и поиск возможностей их оптимизировать – как помогут команде, так и дадут менеджеру больше контекста о происходящем.
3️⃣Участвуйте в той же ротации дежурных по инцидентам, что и вся команда. Вы сможете буквально на кончиках пальцев понимать, где в вашей системе самые проблемные места, насколько хорошо все документировано, и чем весь процесс можно сделать лучше.
4️⃣Возьмите на себя подготовку различных документов – и техдокументации, и пострмортемов, и ADR.
5️⃣Попробуйте периодически брать "engineerication"
Chaitalinarla
Hands-On
Ways to stay tech-savvy while adding value as an engineering manager
Про технических продактов
Давние подписчики канала знают, что я уже давно не настоящий тимлид, и еще в 2019 году перепрыгнул на параллельный карьерный трек и стал продактом – сначала языка программирования, а потом и других инструментов для разработчиков. И пока еще ни разу об этом не пожалел!
Так вот, на этот счет у меня есть два тезиса:
👉Переход именно в технического продакт-менеджера, который отвечает за внутренние платформенные штуки, девтулы или API – самый простой шаг для разработчиков и тимлидов, которые хотят поменять свою карьеру. У вас уже есть отличные доменные знания, а значит, одна из обязательных галочек закрывается.
👉Про технических продактов катастрофически мало контента – это касается и обучающих материалов, и кейсов, на которых можно повышать свою насмотренность.
Так вот, если вам такой карьерный трек тоже интересен, рекомендую подписаться на канал Артема Арюткина, который тоже работает техническим продактом и делает платформу для разработчиков в Яндексе. Вот несколько постов, с которых можно начать:
👉Как повысить эффективность разработки
👉Как продакту вкатиться в проектирование систем
👉Что спросить нанимающего менеджера
👉Как писать полезные PRD
Реклама. Самозанятый Арюткин, ИНН 331104861099, erid: 2SDnjeisiyJ
Давние подписчики канала знают, что я уже давно не настоящий тимлид, и еще в 2019 году перепрыгнул на параллельный карьерный трек и стал продактом – сначала языка программирования, а потом и других инструментов для разработчиков. И пока еще ни разу об этом не пожалел!
Так вот, на этот счет у меня есть два тезиса:
👉Переход именно в технического продакт-менеджера, который отвечает за внутренние платформенные штуки, девтулы или API – самый простой шаг для разработчиков и тимлидов, которые хотят поменять свою карьеру. У вас уже есть отличные доменные знания, а значит, одна из обязательных галочек закрывается.
👉Про технических продактов катастрофически мало контента – это касается и обучающих материалов, и кейсов, на которых можно повышать свою насмотренность.
Так вот, если вам такой карьерный трек тоже интересен, рекомендую подписаться на канал Артема Арюткина, который тоже работает техническим продактом и делает платформу для разработчиков в Яндексе. Вот несколько постов, с которых можно начать:
👉Как повысить эффективность разработки
👉Как продакту вкатиться в проектирование систем
👉Что спросить нанимающего менеджера
👉Как писать полезные PRD
Реклама. Самозанятый Арюткин, ИНН 331104861099, erid: 2SDnjeisiyJ
Большой анализ зарплат по всему миру
Держите офигенный разбор того, как платят сеньорам по всему миру. Из интересных наблюдений:
👉Почти во всех ключевых регионах можно выделить несколько сегментов компаний с разными медианами и распределениями зарплат. Чаще всего одним из сегментов является международный бигтех, а другим – локальные компании.
👉Рынок вытягивают вверх в основном компании с HQ в США.
👉На локальном рынке США компенсация супер-сильно зависит от штата, вот тут можно посмотреть распределение.
👉Чем больше общая компенсация, тем большую часть в ней занимают опционы. Но при этом самые большие пакеты – в хедж-фондах, где никаких опционов нет, зато премии в кэше составляют до 200% от базовой зарплаты.
👉Приложил к картинкам классную оценку того, как изменение цены акций компании повлияло на компенсационный пакет разработчиков. В случае Nvidia за три года он вырос на 45%, а в менее успешных компаниях упал на треть.
Держите офигенный разбор того, как платят сеньорам по всему миру. Из интересных наблюдений:
👉Почти во всех ключевых регионах можно выделить несколько сегментов компаний с разными медианами и распределениями зарплат. Чаще всего одним из сегментов является международный бигтех, а другим – локальные компании.
👉Рынок вытягивают вверх в основном компании с HQ в США.
👉На локальном рынке США компенсация супер-сильно зависит от штата, вот тут можно посмотреть распределение.
👉Чем больше общая компенсация, тем большую часть в ней занимают опционы. Но при этом самые большие пакеты – в хедж-фондах, где никаких опционов нет, зато премии в кэше составляют до 200% от базовой зарплаты.
👉Приложил к картинкам классную оценку того, как изменение цены акций компании повлияло на компенсационный пакет разработчиков. В случае Nvidia за три года он вырос на 45%, а в менее успешных компаниях упал на треть.
👋OTUS приглашает на бесплатные живые вебинары для опытных IT-специалистов, тимлидов, управленцев:
«Тайм-менеджмент для тимлида»: регистрация
В результате вебинара:
- После посещения вебинара поймёте важность планирования и обретёте инструментарий для повышения эффективности.
«Пора на выход: как тимлиду сказать это сотруднику правильно»: регистрация
В результате вебинара:
- Вы научитесь корректно увольнять сотрудников, минимизировать стресс в команде и избегать распространенных ошибок, сохраняя профессионализм и уважение.
«Как тимлиду эффективно распределять роли в ИТ-команде»: регистрация
В результате вебинара:
- Тимлиды опытные и начинающие научатся оценивать возможности команды, исходя из особенностей ее членов.
- СТО, CIO, Руководители ИТ отделов поймут, как эффективно распределять роли в соответствии с типами сотрудников.
- Проектные и продуктовые менеджеры узнают, как собирать и сохранить эффективную команду.
Открытые уроки проходят в рамках онлайн-курса «DevOps Lead». Приходите и задайте вопросы экспертам, пока ответы еще бесплатны!
🤝После вебинара продолжите обучение на курсе со скидкой и даже в рассрочку!
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, erid:2SDnjdmZz8k, www.otus.ru
«Тайм-менеджмент для тимлида»: регистрация
В результате вебинара:
- После посещения вебинара поймёте важность планирования и обретёте инструментарий для повышения эффективности.
«Пора на выход: как тимлиду сказать это сотруднику правильно»: регистрация
В результате вебинара:
- Вы научитесь корректно увольнять сотрудников, минимизировать стресс в команде и избегать распространенных ошибок, сохраняя профессионализм и уважение.
«Как тимлиду эффективно распределять роли в ИТ-команде»: регистрация
В результате вебинара:
- Тимлиды опытные и начинающие научатся оценивать возможности команды, исходя из особенностей ее членов.
- СТО, CIO, Руководители ИТ отделов поймут, как эффективно распределять роли в соответствии с типами сотрудников.
- Проектные и продуктовые менеджеры узнают, как собирать и сохранить эффективную команду.
Открытые уроки проходят в рамках онлайн-курса «DevOps Lead». Приходите и задайте вопросы экспертам, пока ответы еще бесплатны!
🤝После вебинара продолжите обучение на курсе со скидкой и даже в рассрочку!
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, erid:2SDnjdmZz8k, www.otus.ru
Интервью на СТО
Недавно я анонсировал открытое интервью на позицию СТО, где Александр Ложечкин собеседовал Андрея Бреслава. Так вот, все прошло классно, и, если вы опоздали на лайв, обязательно посмотрите запись на Youtube!
Недавно я анонсировал открытое интервью на позицию СТО, где Александр Ложечкин собеседовал Андрея Бреслава. Так вот, все прошло классно, и, если вы опоздали на лайв, обязательно посмотрите запись на Youtube!
YouTube
Mock-up интервью на позицию СТО
Андрей Бреслав (ex-JetBrains, а теперь основатель стартапа) и Александр Ложечкин (ex-Microsoft, ex-Amazon, а теперь CIO в банке) рассуждают, спорят, делятся опытом, и просто болтают на темы развития людей, руководства, технологий и всего остального.
Сайт…
Сайт…
Важность – Решаемость – Запущенность
Чаще всего, выбирая точки приложения усилий, менеджеры сортируют возможные задачи по степени их срочности. Иногда вмешивается матрица Эйзенхауэра, и, помимо срочности, появляется компонент важности. Держите чуть более глубокий фреймворк, который помогает ответить на вопрос "Будет ли мое участие как менеджера полезным?"
👉Решаемость (tractability) – насколько вообще выбранную проблему можно решить в разумное время.
👉Запущенность (neglectedness) – насколько уровень выделяемых ресурсов на проблему соответствует тому, который нужен, чтобы реально ее решить.
👉Важность (importance) – ну тут все по классике.
Так вот, при оценке всех проблем по этим критериям, вы можете увидеть довольно важные вещи. Самыми интересными выглядят вот эти два кластера:
👉Важные, но нерешаемые проблемы. В такие места вам имеет смысл погрузиться и попробовать понять, нельзя ли пересмотреть саму проблему или текущий подход к ее решению. В статье как раз приводится хороший пример с распилом монолита.
👉Важные, решаемые, но при этом запущенные проблемы. Сюда попадает знакомый многим длинный хвост проектов, которыми занимается по полчеловека, и которые в итоге годами не двигаются вперед.
Чаще всего, выбирая точки приложения усилий, менеджеры сортируют возможные задачи по степени их срочности. Иногда вмешивается матрица Эйзенхауэра, и, помимо срочности, появляется компонент важности. Держите чуть более глубокий фреймворк, который помогает ответить на вопрос "Будет ли мое участие как менеджера полезным?"
👉Решаемость (tractability) – насколько вообще выбранную проблему можно решить в разумное время.
👉Запущенность (neglectedness) – насколько уровень выделяемых ресурсов на проблему соответствует тому, который нужен, чтобы реально ее решить.
👉Важность (importance) – ну тут все по классике.
Так вот, при оценке всех проблем по этим критериям, вы можете увидеть довольно важные вещи. Самыми интересными выглядят вот эти два кластера:
👉Важные, но нерешаемые проблемы. В такие места вам имеет смысл погрузиться и попробовать понять, нельзя ли пересмотреть саму проблему или текущий подход к ее решению. В статье как раз приводится хороший пример с распилом монолита.
👉Важные, решаемые, но при этом запущенные проблемы. Сюда попадает знакомый многим длинный хвост проектов, которыми занимается по полчеловека, и которые в итоге годами не двигаются вперед.
Management for Anarchists
Importance isn't enough
Here's a nuanced framework for thinking about how leaders should spend their time
Как давать обратную связь, чтобы вас слышали и что-то менялось?
Обратная связь — фундаментальный навык в управлении, который экономит время, деньги и нервы. И в теории вроде понятно, каким должен быть хороший фидбэк, но как дело доходит до практики… То подчиненный не так понял, то обиделся, то вовсе не захотел исправлять свои косяки.
27 марта в 20:00 по мск школа коммуникации Soft Skills Lab проведет открытый вебинар про обратную связь.
За 1,5 часа вы узнаете:
▫️ Как быстро формулировать обратную связь, чтобы она четко доносила суть и не демотивировала сотрудников?
▫️ Что понижает и повышает ее результативность?
▫️ Как найти баланс между мягкостью и жесткостью?
Вы на кейсах разберете конкретные принципы и ошибки, учитывая которые сможете легко и грамотно давать обратную связь. Так, чтобы в команде не страдали процессы, отношения и инициатива.
🗣 Спикер — Нелли Григорьева, ведущий тренер Soft Skills Lab, преподаватель по переговорам в ВШЭ, ex-head of marketing в международных стартапах, консультант технологических компаний в области маркетинга.
Занятие пройдет в Zoom, поэтому будет возможность обсудить свои вопросы и кейсы.
👉🏻 Чтобы получить ссылку на конференцию, просто запустите бота.
Обратная связь — фундаментальный навык в управлении, который экономит время, деньги и нервы. И в теории вроде понятно, каким должен быть хороший фидбэк, но как дело доходит до практики… То подчиненный не так понял, то обиделся, то вовсе не захотел исправлять свои косяки.
27 марта в 20:00 по мск школа коммуникации Soft Skills Lab проведет открытый вебинар про обратную связь.
За 1,5 часа вы узнаете:
▫️ Как быстро формулировать обратную связь, чтобы она четко доносила суть и не демотивировала сотрудников?
▫️ Что понижает и повышает ее результативность?
▫️ Как найти баланс между мягкостью и жесткостью?
Вы на кейсах разберете конкретные принципы и ошибки, учитывая которые сможете легко и грамотно давать обратную связь. Так, чтобы в команде не страдали процессы, отношения и инициатива.
🗣 Спикер — Нелли Григорьева, ведущий тренер Soft Skills Lab, преподаватель по переговорам в ВШЭ, ex-head of marketing в международных стартапах, консультант технологических компаний в области маркетинга.
Занятие пройдет в Zoom, поэтому будет возможность обсудить свои вопросы и кейсы.
👉🏻 Чтобы получить ссылку на конференцию, просто запустите бота.
Настольная книга СТО стартапа
Держите золото – бесплатную книгу с описанием кучи концепций, практик и процессов, которые нужны любому техническому руководителю.
👉Менеджмент людей: коучинг, деревья компетенций, continuous improvement, обучение менеджеров.
👉Жизненный цикл сотрудника: найм, онбординг, перфоманс менеджмент.
👉Управление технической командой: общая культура, техдолг, developer experience.
👉Технологии: архитектура, SDLC, DevOps, инцидент-менеджмент.
Держите золото – бесплатную книгу с описанием кучи концепций, практик и процессов, которые нужны любому техническому руководителю.
👉Менеджмент людей: коучинг, деревья компетенций, continuous improvement, обучение менеджеров.
👉Жизненный цикл сотрудника: найм, онбординг, перфоманс менеджмент.
👉Управление технической командой: общая культура, техдолг, developer experience.
👉Технологии: архитектура, SDLC, DevOps, инцидент-менеджмент.
«Управление IT-продуктами» — день открытых дверей онлайн-магистратуры Яндекс Практикума и МФТИ
2 апреля в 19:00 мск
На встрече поговорим о современном формате магистратуры для менеджеров продукта от Яндекса и МФТИ. Как поступить, как проходит обучение и какие знания вы получите на выходе.
Подробно расскажем, что такое очная онлайн-магистратура — как это, когда учишься онлайн, но со студенческим билетом, отсрочкой от армии и дипломом магистра МФТИ после выпуска.
Что будет на событии:
— О профессии продакт-менеджер и какие задачи есть у специалистов разных грейдов — расскажет Елена Тупикова, академический руководитель программы, Chief Product Officer ex-Яндекс, CEO CPO.Agency.
— Чему научитесь и как устроено обучение на прикладной программе — поделится Виктория Копаева, менеджер программ высшего образования, Яндекс Практикум.
— Как поступить: сроки, экзамены, документы, оплата — расскажет Юлия Соболь, заместитель директора Центра «Пуск», МФТИ.
→ Зарегистрироваться
2 апреля в 19:00 мск
На встрече поговорим о современном формате магистратуры для менеджеров продукта от Яндекса и МФТИ. Как поступить, как проходит обучение и какие знания вы получите на выходе.
Подробно расскажем, что такое очная онлайн-магистратура — как это, когда учишься онлайн, но со студенческим билетом, отсрочкой от армии и дипломом магистра МФТИ после выпуска.
Что будет на событии:
— О профессии продакт-менеджер и какие задачи есть у специалистов разных грейдов — расскажет Елена Тупикова, академический руководитель программы, Chief Product Officer ex-Яндекс, CEO CPO.Agency.
— Чему научитесь и как устроено обучение на прикладной программе — поделится Виктория Копаева, менеджер программ высшего образования, Яндекс Практикум.
— Как поступить: сроки, экзамены, документы, оплата — расскажет Юлия Соболь, заместитель директора Центра «Пуск», МФТИ.
→ Зарегистрироваться
Что вынуждает топ-перформеров увольняться
👉Отсутствие ясного вижна у компании. Топ-перформеры готовы сами находить новые челленджи и двигать компанию вперед, но для этого им важно понимать общен направление.
👉Добавление новых задач без отказа от старых. По себе знаю, насколько просто попасть в ловушку бездумного накидывания задач в своих самых сильных людей. А за перегрузкой будет следовать либо выгорание, либо провал каких-то из проектов.
👉Скидывание части ваших задачс когда вы передаете их не с целью развития навыков, а просто для того, чтобы освободить собственное время.
👉Обещать отдать контроль, но на деле постоянно микроменеджерить и забирать его на себя. Помимо того, что вы забираете возможность развития, вы таким образом показываете отсутствие доверия.
👉Предполагать, что вы знаете, что их мотивирует. Когда какой-то человек с радостью берет на себя новые сложные задачи, легко сделать вывод о том, что его основная мотивация лежит в интеллектуальных челленджах. На самом деле ситуация может быть вообще другой, и, не понимая всех причин, вы будете принимать плохие решения.
👉Отсутствие ясного вижна у компании. Топ-перформеры готовы сами находить новые челленджи и двигать компанию вперед, но для этого им важно понимать общен направление.
👉Добавление новых задач без отказа от старых. По себе знаю, насколько просто попасть в ловушку бездумного накидывания задач в своих самых сильных людей. А за перегрузкой будет следовать либо выгорание, либо провал каких-то из проектов.
👉Скидывание части ваших задачс когда вы передаете их не с целью развития навыков, а просто для того, чтобы освободить собственное время.
👉Обещать отдать контроль, но на деле постоянно микроменеджерить и забирать его на себя. Помимо того, что вы забираете возможность развития, вы таким образом показываете отсутствие доверия.
👉Предполагать, что вы знаете, что их мотивирует. Когда какой-то человек с радостью берет на себя новые сложные задачи, легко сделать вывод о том, что его основная мотивация лежит в интеллектуальных челленджах. На самом деле ситуация может быть вообще другой, и, не понимая всех причин, вы будете принимать плохие решения.
newsletter.canopy.is
The Hidden Ways Leaders Unintentionally Punish Their Top Performers
How to identify the subtle behaviors that drive away your top performers, and what to do instead
Современные распределённые системы не прощают ошибок в интеграциях.
Как выбрать между REST, gRPC и event-driven? Как не утонуть в хаосе версионирования API и управлении нагрузками?
С 7 по 11 апреля на онлайн-конференции Podlodka Techlead Crew разберёмся с вопросами межсервисного взаимодействия:
• Проектированием API распределённых систем с Алексеем Рыбаком (devhands)
• Выбором архитектуры интеграций (gRPC, HTTP, Event-driven, базы данных) с Кириллом Ветчинкиным, Филиппом Дельгядо и Сергеем Петрелевичем
• Инструментами observability в распределённых системах с Григорием Кошелевым (Контур)
• API First подходом к разработке с Николаем Нагорным.
Всё максимально прикладное и применимое в работе.
🎟 Забирай билет https://podlodka.io/techcrew
Как выбрать между REST, gRPC и event-driven? Как не утонуть в хаосе версионирования API и управлении нагрузками?
С 7 по 11 апреля на онлайн-конференции Podlodka Techlead Crew разберёмся с вопросами межсервисного взаимодействия:
• Проектированием API распределённых систем с Алексеем Рыбаком (devhands)
• Выбором архитектуры интеграций (gRPC, HTTP, Event-driven, базы данных) с Кириллом Ветчинкиным, Филиппом Дельгядо и Сергеем Петрелевичем
• Инструментами observability в распределённых системах с Григорием Кошелевым (Контур)
• API First подходом к разработке с Николаем Нагорным.
Всё максимально прикладное и применимое в работе.
🎟 Забирай билет https://podlodka.io/techcrew
Почему учить других – хороший способ учиться самому
1️⃣ Когда вы объясняете кому-то новую тему, вам приходится глубоко в ней разобраться. Если вы не можете ясно изложить материал, значит, вы сами еще недостаточно его поняли.
2️⃣ Чтобы доступно объяснить что-то другим людям, вам приходится упрощать информацию, искать понятные примеры и аналогии. В этом процессе вы и сами лучше понимаете суть изучаемого материала.
3️⃣ Когда вы только-только изучили что-то новое, вы еще помните, что это такое – не понимать материал. Это помогает вам предвидеть возможные вопросы, объяснять тему более доступно, и уметь так же объяснять ее и в будущем.
4️⃣ Необходимость обучить теме кого-то еще хорошо так пинает разобраться в теме глубже, и не откладывать это на последний момент.
1️⃣ Когда вы объясняете кому-то новую тему, вам приходится глубоко в ней разобраться. Если вы не можете ясно изложить материал, значит, вы сами еще недостаточно его поняли.
2️⃣ Чтобы доступно объяснить что-то другим людям, вам приходится упрощать информацию, искать понятные примеры и аналогии. В этом процессе вы и сами лучше понимаете суть изучаемого материала.
3️⃣ Когда вы только-только изучили что-то новое, вы еще помните, что это такое – не понимать материал. Это помогает вам предвидеть возможные вопросы, объяснять тему более доступно, и уметь так же объяснять ее и в будущем.
4️⃣ Необходимость обучить теме кого-то еще хорошо так пинает разобраться в теме глубже, и не откладывать это на последний момент.
hardmodefirst.xyz
Teach to Learn: Why Sharing What You Know Makes You Smarter
Considering the powerful possibility that each of us is a learning, and a teacher, all the time
Юристы в ИТ: почему тимлидам и проджектам без них никуда, как и бизнесу в целом?
Поговорили об этом с Юлией Суворовой, Head of Legal and Compliance в Сравни. Обсудили, как юристы помогают командам обезопасить разработку (и сопутствующие процессы) от возможных рисков, и что нужно знать ИТ-руководителям о букве закона в рамках компании.
В этом выпуске:
• Как не обжечься с покупкой ПО, использованием open source решений и оформлением права на код
• Когда ИТ-компании (и команды) могут обойтись без юристов?
• Как нормативные акты влияют на процессы разработки
• Правила успешной коммуникации с юристами в ИТ
Посмотреть или послушать можно здесь:
✅VK
✅YouTube
✅RUTUBE
✅Mave
Поговорили об этом с Юлией Суворовой, Head of Legal and Compliance в Сравни. Обсудили, как юристы помогают командам обезопасить разработку (и сопутствующие процессы) от возможных рисков, и что нужно знать ИТ-руководителям о букве закона в рамках компании.
В этом выпуске:
• Как не обжечься с покупкой ПО, использованием open source решений и оформлением права на код
• Когда ИТ-компании (и команды) могут обойтись без юристов?
• Как нормативные акты влияют на процессы разработки
• Правила успешной коммуникации с юристами в ИТ
Посмотреть или послушать можно здесь:
✅VK
✅YouTube
✅RUTUBE
✅Mave