Writerside – IDE для технической документации
В соседней команде в JetBrains зарелизили очень крутую штуку – IDE для тех, кому приходится много работать с технической документацией. Вот основные фичи:
👉Построена на принципах Docs-as-a-code: встроена работа с гитом, системами сборки и автотестами.
👉Умеет работать одновременно с XML и Markdown. Поддерживает встраивание Mermaid диаграмм и LaTeX.
👉Встроена куча инспекций, которые проверяют качество документации.
👉Live preview для доков, которое обновляется на лету.
👉Доки собираются в артефакты, которые легко опубликовать в вебе.
Пока Writerside в раннем доступе и распространяется бесплатно, так что можно пробовать.
В соседней команде в JetBrains зарелизили очень крутую штуку – IDE для тех, кому приходится много работать с технической документацией. Вот основные фичи:
👉Построена на принципах Docs-as-a-code: встроена работа с гитом, системами сборки и автотестами.
👉Умеет работать одновременно с XML и Markdown. Поддерживает встраивание Mermaid диаграмм и LaTeX.
👉Встроена куча инспекций, которые проверяют качество документации.
👉Live preview для доков, которое обновляется на лету.
👉Доки собираются в артефакты, которые легко опубликовать в вебе.
Пока Writerside в раннем доступе и распространяется бесплатно, так что можно пробовать.
JetBrains
Writerside - a new technical writing environment from JetBrains.
Writerside is a new technical authoring and publishing environment from JetBrains.
Влияние GitHub Copilot на продуктивность
Сразу большой дисклеймер – исследование проводил сам GitHub, поэтому учитывайте предвзятость, и прикидывайте сами, сколько исследований с менее впечатляющими результатами не было опубликовано.
👉85% разработчиков более уверены в качестве своего кода при использовании Copilot. Качество оценивается по нескольким показателям: Readable, Reusable, Concise, Maintainable, Resilient.
👉Code review проходят в среднем на 15% быстрее, результаты их более actionable.
👉88% разработчиков считают, что поддерживать состояние потока с Copilot проще.
👉55% разработчиков начали работать быстрее.
Сразу большой дисклеймер – исследование проводил сам GitHub, поэтому учитывайте предвзятость, и прикидывайте сами, сколько исследований с менее впечатляющими результатами не было опубликовано.
👉85% разработчиков более уверены в качестве своего кода при использовании Copilot. Качество оценивается по нескольким показателям: Readable, Reusable, Concise, Maintainable, Resilient.
👉Code review проходят в среднем на 15% быстрее, результаты их более actionable.
👉88% разработчиков считают, что поддерживать состояние потока с Copilot проще.
👉55% разработчиков начали работать быстрее.
Вопросы, которые кандидат должен спросить на собеседовании
Неудачный найм – страшный сон и кандидата, и нанимающего менеджера. Куча потерянного времени и денег, стресс, поломанные отношения. В статье собраны вопросы, которые кандидатам полезно задать нанимающей стороне, чтобы не ошибиться при выборе работы. Они покрывают все важные области: ожидания от должности, особенности испыталки, команду, проект, личность руководителя.
Неудачный найм – страшный сон и кандидата, и нанимающего менеджера. Куча потерянного времени и денег, стресс, поломанные отношения. В статье собраны вопросы, которые кандидатам полезно задать нанимающей стороне, чтобы не ошибиться при выборе работы. Они покрывают все важные области: ожидания от должности, особенности испыталки, команду, проект, личность руководителя.
Хабр
Прививка от ошибки выбора: что спросить работодателя «на берегу»
Меня зовут Настя, я руководитель службы инструментов репозитория в Yandex Infrastructure. Больше 15 лет я проработала в IT‑индустрии: сначала как разработчик, потом тимлид, техлид,...
Подборка заметок и статей про стратегию
Как я писал в пятницу, уже сегодня начинается новый сезон тимлидской Подлодки про стратегию. Поддержу стратегический флешмоб подборкой старых постов из канала про стратегию:
👉Как написать техническую стратегию
👉Признаки хорошей и плохой стратегии
👉Механизм принятия сложных решений
👉Оценка стратегии через призму “ставок”, и баланса между risk и reward
👉Про то, почему многим стратегиям не достает ясности, и почему они очень абстрактны
👉Чем отличаются фокусировка и обобщение в стратегии
👉Как собирать фидбэк на стратегию, и почему разные люди говорят разные вещи
👉Почему у многих команд и компаний нет стратегии
👉Нормально ли, если стратегия часто изменяется
Увидимся в чатике сезона!
Как я писал в пятницу, уже сегодня начинается новый сезон тимлидской Подлодки про стратегию. Поддержу стратегический флешмоб подборкой старых постов из канала про стратегию:
👉Как написать техническую стратегию
👉Признаки хорошей и плохой стратегии
👉Механизм принятия сложных решений
👉Оценка стратегии через призму “ставок”, и баланса между risk и reward
👉Про то, почему многим стратегиям не достает ясности, и почему они очень абстрактны
👉Чем отличаются фокусировка и обобщение в стратегии
👉Как собирать фидбэк на стратегию, и почему разные люди говорят разные вещи
👉Почему у многих команд и компаний нет стратегии
👉Нормально ли, если стратегия часто изменяется
Увидимся в чатике сезона!
podlodka.io
Онлайн-конференция Podlodka Teamlead Crew, сезон #14
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам тимлидства, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
Как сэкономить 10 миллионов на найме
Стандартная ситуация, которую я постоянно наблюдаю в разных компаниях. В команду нужен специалист с опытом работы в чем-то сравнительно редком. Открывается вакансия мидлового или сеньорного уровня, которая закрывается по 6-9 месяцев, на протяжении которых бизнес недополучает пользу. В то же время все резюме джунов отметаются сходу с аргументом про то, что учить их некому и дорого.
Ребята в статье делятся своим опытом построения программ внутреннего обучения начинающих специалистов. Сразу предупреждаю, что читается довольно тяжело. Мне в первую очередь понравились цифры, которые они приводят как результат своих экспериментов. Как пример, фокус на найме и обучении джунов дата-инженеров сэкономил 10 миллионов рублей по сравнению с аналогичной воронкой найма сеньоров.
Стандартная ситуация, которую я постоянно наблюдаю в разных компаниях. В команду нужен специалист с опытом работы в чем-то сравнительно редком. Открывается вакансия мидлового или сеньорного уровня, которая закрывается по 6-9 месяцев, на протяжении которых бизнес недополучает пользу. В то же время все резюме джунов отметаются сходу с аргументом про то, что учить их некому и дорого.
Ребята в статье делятся своим опытом построения программ внутреннего обучения начинающих специалистов. Сразу предупреждаю, что читается довольно тяжело. Мне в первую очередь понравились цифры, которые они приводят как результат своих экспериментов. Как пример, фокус на найме и обучении джунов дата-инженеров сэкономил 10 миллионов рублей по сравнению с аналогичной воронкой найма сеньоров.
Хабр
Как мы растим своих джунов
Рынок труда изменился. Ещё недавно он был ориентирован на работодателя. Сейчас, особенно в ИТ-области, это рынок соискателей. Поиск нужных специалистов становится всё более трудным, а конкуренция на...
Как нетворкаться, если ты не любишь общаться с людьми
👉Начните с простого – улыбнитесь кому-нибудь и скажите "привет".
👉Люди любят говорить о себе, поэтому старайтесь задавать вопросы.
👉Не забывайте благодарить того, кто поделился с вами советом или натолкнул на ценную мысль.
👉Если вы хотите установить с кем-то связь, постарайтесь выделить тот интерес, который вас объединяет, и сфокусироваться именно на нем.
👉Не стесняйтесь в любой момент закончить разговор. Не надо придумывать надуманных предлогов. Просто поблагодарите за общение и уходите.
👉Если вы познакомились с кем-то интересным, обязательно напишите фоллоу-ап. Не надо спамить, просто напишите письмо вида "Привет! Встретились там-то, обсудили то-то, будем на связи!"
👉Начните с простого – улыбнитесь кому-нибудь и скажите "привет".
👉Люди любят говорить о себе, поэтому старайтесь задавать вопросы.
👉Не забывайте благодарить того, кто поделился с вами советом или натолкнул на ценную мысль.
👉Если вы хотите установить с кем-то связь, постарайтесь выделить тот интерес, который вас объединяет, и сфокусироваться именно на нем.
👉Не стесняйтесь в любой момент закончить разговор. Не надо придумывать надуманных предлогов. Просто поблагодарите за общение и уходите.
👉Если вы познакомились с кем-то интересным, обязательно напишите фоллоу-ап. Не надо спамить, просто напишите письмо вида "Привет! Встретились там-то, обсудили то-то, будем на связи!"
Vadim Kravcenko
Networking as an introvert CTO
There I was, standing in the middle of a buzzing tech event that our company organized, feeling like a fish out of water. The room was filled with
Подборка из 75 карьерных линеек
Каталог всех матриц компетенций и карьерных линеек, которые различные компании выкладывали в открытый доступ. К большинству приложены еще и готовые шаблоны, статьи-ретроспективы с разбором недостатков, и куча других дополнительных материалов.
Каталог всех матриц компетенций и карьерных линеек, которые различные компании выкладывали в открытый доступ. К большинству приложены еще и готовые шаблоны, статьи-ретроспективы с разбором недостатков, и куча других дополнительных материалов.
Сэм Олтмен про продуктивность
Сэм Альтман, СЕО OpenAI, пишет довольно много эссе в своем блоге. Мне понравился один из последних постов, в котором он рассуждает про то, что влияет на продуктивность. Как и в любом разговоре про продуктивность нет никаких глобально новых идей, но некоторые мысли меня триггернули:
👉Нужно вырабатывать собственную сильную позицию по вопросам, над которыми вы работаете. Если вместо этого вы всегда соглашаетесь с последним собеседником, который поделился своей точкой зрения – это не клево.
👉В долгую не получится быть действительно продуктивным при работе над проектами, которые вам не нравятся. То же верно и при делегировании.
👉В целом, если вы задумываетесь о повышении своей продуктивности, то большую часть усилий надо потратить не на оптимизацию рутины или приоритизацию ежедневных задач, а на то, чтобы повысить шансы движения в стратегически правильном направлении.
Сэм Альтман, СЕО OpenAI, пишет довольно много эссе в своем блоге. Мне понравился один из последних постов, в котором он рассуждает про то, что влияет на продуктивность. Как и в любом разговоре про продуктивность нет никаких глобально новых идей, но некоторые мысли меня триггернули:
👉Нужно вырабатывать собственную сильную позицию по вопросам, над которыми вы работаете. Если вместо этого вы всегда соглашаетесь с последним собеседником, который поделился своей точкой зрения – это не клево.
👉В долгую не получится быть действительно продуктивным при работе над проектами, которые вам не нравятся. То же верно и при делегировании.
👉В целом, если вы задумываетесь о повышении своей продуктивности, то большую часть усилий надо потратить не на оптимизацию рутины или приоритизацию ежедневных задач, а на то, чтобы повысить шансы движения в стратегически правильном направлении.
Sam Altman
Productivity
I think I am at least somewhat more productive than average, and people sometimes ask me for productivity tips. So I decided to just write them all down in one place.
Compound growth gets...
Compound growth gets...
Как запускать кросскомандные проекты
Практически во всех карьерных сетках стафф инженера от сеньора отличает умение запускать и лидить проекты, в реализации которых участвует несколько команд. Многих это ставит в тупик – как можно заставить что-то делать людей, когда у тебя нет достаточного количества полномочий и административных рычагов. В статье для таких случаев предлагают следующий алгоритм:
1️⃣Выровнять всех относительно общей цели
Задача этого этапа – убедить всех, что проблему важно решить. Основная стратегия – сначала убедить маленькую группу людей, и постепенно расширять круг вовлеченных.
- Обсудите проблему в вашей собственной команде, в том числе с менеджером. Соберите фидбэк.
- Напишите или расскажите о проблеме публично, чтобы получить видимость внутри компании. Это поможет получить поддержку других менеджеров.
2️⃣Составить роадмап
Следующий шаг – собрать четкий план того, что должно быть сделано со стороны всех участников. Вам нужно не столько придумать весь план самому, сколько вытащить нужные ответы из релеватных людей.
3️⃣Быть прозрачным
Так как вы отвечаете за проект, ваша задача – вовремя сообщать стейкхолдерам об изменениях. Да и в целом регулярно рассказывать, как идет проект.
Практически во всех карьерных сетках стафф инженера от сеньора отличает умение запускать и лидить проекты, в реализации которых участвует несколько команд. Многих это ставит в тупик – как можно заставить что-то делать людей, когда у тебя нет достаточного количества полномочий и административных рычагов. В статье для таких случаев предлагают следующий алгоритм:
1️⃣Выровнять всех относительно общей цели
Задача этого этапа – убедить всех, что проблему важно решить. Основная стратегия – сначала убедить маленькую группу людей, и постепенно расширять круг вовлеченных.
- Обсудите проблему в вашей собственной команде, в том числе с менеджером. Соберите фидбэк.
- Напишите или расскажите о проблеме публично, чтобы получить видимость внутри компании. Это поможет получить поддержку других менеджеров.
2️⃣Составить роадмап
Следующий шаг – собрать четкий план того, что должно быть сделано со стороны всех участников. Вам нужно не столько придумать весь план самому, сколько вытащить нужные ответы из релеватных людей.
3️⃣Быть прозрачным
Так как вы отвечаете за проект, ваша задача – вовремя сообщать стейкхолдерам об изменениях. Да и в целом регулярно рассказывать, как идет проект.
www.developing.dev
Setting Up Cross-Team Workstreams
A Critical Skill for Both Senior and Staff Engineers
Как научить людей принимать решения
Способность самостоятельно принимать решения у разных людей развита по-разному. Ну и, конечно, она сильно зависит от принятой в команде культуры – если вы всегда все замыкаете на себе, то надеяться на самостоятельную работу ваших сотрудников не стоит.
Если вы решили постепенно помогать людям становиться самостоятельнее, попробуйте следовать простому правилу. Каждый раз, когда к вам кто-то приходит обсудить проблему, помогите ему подняться на следующий уровень из этих пяти:
1️⃣Человек не распознает проблему и не знает, как ее решать
2️⃣Человек видит проблему, но не может найти решение
3️⃣Человек видит проблему и несколько способов решения, но не знает, как выбрать один из них
4️⃣Человек видит проблему, несколько способов решения и предлагает один из них
5️⃣Человек распознал проблему, выбрал один вариант решения из нескольких, исполнил его, и теперь просто делится с вами статусом
Способность самостоятельно принимать решения у разных людей развита по-разному. Ну и, конечно, она сильно зависит от принятой в команде культуры – если вы всегда все замыкаете на себе, то надеяться на самостоятельную работу ваших сотрудников не стоит.
Если вы решили постепенно помогать людям становиться самостоятельнее, попробуйте следовать простому правилу. Каждый раз, когда к вам кто-то приходит обсудить проблему, помогите ему подняться на следующий уровень из этих пяти:
1️⃣Человек не распознает проблему и не знает, как ее решать
2️⃣Человек видит проблему, но не может найти решение
3️⃣Человек видит проблему и несколько способов решения, но не знает, как выбрать один из них
4️⃣Человек видит проблему, несколько способов решения и предлагает один из них
5️⃣Человек распознал проблему, выбрал один вариант решения из нескольких, исполнил его, и теперь просто делится с вами статусом
Corporate Rebels
5 Levels Of Problem Solving: A Framework For (First-Time) Managers -…
Master the art of problem-solving and ascend through the five levels of mastery. Revolutionize your skills by joining our movement.
Не копируйте оргструктуру Spotify
Лет пять назад было очень модно копировать модель, по которой Spotify организует свои команды – все эти сквады, трайбы и гильдии. В большинстве случаев это приносило больше проблем, чем пользы. Причина этого – карго-культ, так как вместо фокуса на идеях компании слепо пытались перенести внешние атрибуты.
У каждой компании своя культура и специфика. Как и во всех других случаях, в первую очередь думайте о проблемах, а не о конкретных решениях.
Лет пять назад было очень модно копировать модель, по которой Spotify организует свои команды – все эти сквады, трайбы и гильдии. В большинстве случаев это приносило больше проблем, чем пользы. Причина этого – карго-культ, так как вместо фокуса на идеях компании слепо пытались перенести внешние атрибуты.
У каждой компании своя культура и специфика. Как и во всех других случаях, в первую очередь думайте о проблемах, а не о конкретных решениях.
Agile Pain Relief Consulting | Scrum and Agile Training and Resources
The Spotify Model of Scaling – Spotify Doesn’t Use It, Neither Should You
The "Spotify Model" probably isn't a model and definitely isn't what is currently practiced at Spotify today. (Some suggest it never was.) The below image was made famous in a video by Henrik Kniberg, where he explains how work was organized into Squads,…
42 урока, вынесенных из опыта создания новой базы данных
Техлид Delos, базы данных, активно использующейся во внутренней инфре Meta, делится наблюдениями, которые будут рклевантны всем, кто руководит платформенными командами или делает какие-то инфраструктурные продукты. Несколько любимых советоа:
👉Старайтесь, чтобы ваш проект был устойчивым к реорганизациям компании. Поддерживайте отношения с иенеджерами, которым когда-нибудь может достаться ваш проект, делайте так, чтобы они понимали его пользу.
👉Не набирайте пользователей сразу. В идеале, начинайте с одного, причем такого, нужды которого дадут вам сосредоточиться на корной технологии.
👉Регулярно повторяйте меннджерам оценку сложности задач, иначе из-за занятости и невнимательности они могут ошибиться на порядки.
👉Если в компании разрабатывается другой проект, решающий ту же проблему, соревнуйтесь с ними не в эффективности решения отдельных задач и не в производительности команд, а в фундаментальных характеристиках систем.
Техлид Delos, базы данных, активно использующейся во внутренней инфре Meta, делится наблюдениями, которые будут рклевантны всем, кто руководит платформенными командами или делает какие-то инфраструктурные продукты. Несколько любимых советоа:
👉Старайтесь, чтобы ваш проект был устойчивым к реорганизациям компании. Поддерживайте отношения с иенеджерами, которым когда-нибудь может достаться ваш проект, делайте так, чтобы они понимали его пользу.
👉Не набирайте пользователей сразу. В идеале, начинайте с одного, причем такого, нужды которого дадут вам сосредоточиться на корной технологии.
👉Регулярно повторяйте меннджерам оценку сложности задач, иначе из-за занятости и невнимательности они могут ошибиться на порядки.
👉Если в компании разрабатывается другой проект, решающий ту же проблему, соревнуйтесь с ними не в эффективности решения отдельных задач и не в производительности команд, а в фундаментальных характеристиках систем.
mahesh’s blog
42 things I learned from building a production database
In 2017, I went to Facebook on a sabbatical from my faculty position at Yale. I created a team to build a storage system called Delos at the bottom of the Facebook stack (think of it as Facebook’s version of Chubby). We hit production with a 3-person team…
NDA не работают
Стандартные NDA практически никак не защищают компанию и ни к чему не обязывают человека, их подписавшего. Для защиты коммерческой тайны нужно разрабатывать целую систему:
👉Документ, подробно описывающий, что вообще составляет коммерческую тайну
👉Подписанное соглашение с каждым сотрудником, адаптированное под конкретную должность
👉Журнал доступа к коммерческой тайне
👉Гриф коммерческой тайны на всех релевантных документах
👉Подписанные акты передачи информации со всеми, кто открывал документы
Кстати, мы записывали выпуск Подлодки на ту же тему для тех, кто хочет погрузиться поглубже!
Стандартные NDA практически никак не защищают компанию и ни к чему не обязывают человека, их подписавшего. Для защиты коммерческой тайны нужно разрабатывать целую систему:
👉Документ, подробно описывающий, что вообще составляет коммерческую тайну
👉Подписанное соглашение с каждым сотрудником, адаптированное под конкретную должность
👉Журнал доступа к коммерческой тайне
👉Гриф коммерческой тайны на всех релевантных документах
👉Подписанные акты передачи информации со всеми, кто открывал документы
Кстати, мы записывали выпуск Подлодки на ту же тему для тех, кто хочет погрузиться поглубже!
Кент Бек про вред оценок и дедлайнов
Хороший пост от Кента Бека, одного из отцов XP. Он напоминает про то, почему оценки и дедлайны не просто бесполезны, а еще и вредны для успеха продукта, и предлагает простой agile процесс, направленный на принесение клиентам максимальной пользы:
👉По понедельникам вся команда собирается вместе и отвечает на два вопроса: "Что для нас важнее всего достичь на этой неделе?" и "Что мы на спмом деле можем сделать за неделю?".
👉По пятницам команда собирается снова и обсуждает, что было хорошо, что можно улучшить, насколько получилось доставить ценность пользователям. Короче, ретроспектива про процессы и про результат.
👉Все попытки сравнивать производительность неделя к неделе, планировать вперед на кварталы, сравнивать команды друг с другом запрещены.
Хороший пост от Кента Бека, одного из отцов XP. Он напоминает про то, почему оценки и дедлайны не просто бесполезны, а еще и вредны для успеха продукта, и предлагает простой agile процесс, направленный на принесение клиентам максимальной пользы:
👉По понедельникам вся команда собирается вместе и отвечает на два вопроса: "Что для нас важнее всего достичь на этой неделе?" и "Что мы на спмом деле можем сделать за неделю?".
👉По пятницам команда собирается снова и обсуждает, что было хорошо, что можно улучшить, насколько получилось доставить ценность пользователям. Короче, ретроспектива про процессы и про результат.
👉Все попытки сравнивать производительность неделя к неделе, планировать вперед на кварталы, сравнивать команды друг с другом запрещены.
Software Design: Tidy First?
Private Estimates, Public Progress
I remember back when being on one of those gigantic, long-lived software projects when I was a wee programmer. Professional project managers had laid out the entire thing before we started coding. Enlightened professional project managers—they only assumed…
Три менеджерских подхода
Статья в первую очередь направлена на СТО и директоров, но может быть полезна и линейным руководителям. Автор выделяет три стиля менеджмента, между которыми надо переключаться в зависимости от типа принимаемого решения.
👉Управление с помощью регламентов. Применяется для однотипных решений, которые надо принимать регулярно.
👉Управление с помощью консенсуса. Применяется для неповторяющихся решений, контекст по которым распределен по нескольким стейкхолдерам.
👉Управление с помощью убеждения. Для важных разовых решений, которые по разным причинам не могут принять без вас, и в контекст которых надо глубоко закопаться.
Для каждого из стилей приведен подробный чек-лист шагов, которые надо предпринять, и примеры ситуаций, в которых они помогали.
Статья в первую очередь направлена на СТО и директоров, но может быть полезна и линейным руководителям. Автор выделяет три стиля менеджмента, между которыми надо переключаться в зависимости от типа принимаемого решения.
👉Управление с помощью регламентов. Применяется для однотипных решений, которые надо принимать регулярно.
👉Управление с помощью консенсуса. Применяется для неповторяющихся решений, контекст по которым распределен по нескольким стейкхолдерам.
👉Управление с помощью убеждения. Для важных разовых решений, которые по разным причинам не могут принять без вас, и в контекст которых надо глубоко закопаться.
Для каждого из стилей приведен подробный чек-лист шагов, которые надо предпринять, и примеры ситуаций, в которых они помогали.
Lethain
Developing leadership styles
For a long time, I found the micromanager CEO archetype very frustrating to work with. They would often pop out of nowhere, jab holes in the work I had done without understanding the tradeoffs, and then disappear when I wanted to explain my decisions. In…
Получите работу в крупной IT-компании всего лишь за один день!
МойОфис ищет опытных бэкенд-разработчиков и готов нанять несколько человек за один день. Отбор проходит в рамках One day offer, который случится уже 25 ноября. Если вы хотите стать частью крутой команды и создавать продукты, которыми пользуются множество клиентов в России и по всему миру, то отправляйте резюме и выполненный онлайн-тест на одну из следующих позиций:
- Golang-разработчик
- C++ разработчик
Ищут специалистов уровня middle, senior и lead с опытом работы от 3 лет.
Плюшки: конкурентная зарплата, ДМС со стоматологией, компенсация фитнеса, оплата питания, возможность работать удаленно и многое другое.
Спешите, заявки принимаются до 17 ноября. Все подробности тут
МойОфис ищет опытных бэкенд-разработчиков и готов нанять несколько человек за один день. Отбор проходит в рамках One day offer, который случится уже 25 ноября. Если вы хотите стать частью крутой команды и создавать продукты, которыми пользуются множество клиентов в России и по всему миру, то отправляйте резюме и выполненный онлайн-тест на одну из следующих позиций:
- Golang-разработчик
- C++ разработчик
Ищут специалистов уровня middle, senior и lead с опытом работы от 3 лет.
Плюшки: конкурентная зарплата, ДМС со стоматологией, компенсация фитнеса, оплата питания, возможность работать удаленно и многое другое.
Спешите, заявки принимаются до 17 ноября. Все подробности тут
Шесть концепций системного мышления
Разбор шести фундаментальных концепций, которые помогают анализировать сложные системы.
Разбор шести фундаментальных концепций, которые помогают анализировать сложные системы.
Как перебороть сомнения в себе и перестать себя газлайтить
Газлайтинг – это такая форма психологической манипуляции, в результате которой жертва сомневается в адекватности своего восприятия окружающего, чувствует себя дефективной. Газлайтинг не всегда требует объекта и субъекта – в эту ловушку можно загнать себя самостоятельно.
Такой эффект часто получается из-за сомнений в себе: вы постоянно чувствуете, что могли бы справиться с рабочей ситуацией лучше, быть лучшим менеджером, переговорщиком, давать более качественную обратную связь – да что угодно еще. При этом с другими людьми внешне все отлично: любые доклады и статьи рассказывают про чьи-то менеджерские успехи, топ-перформеры на работе никогда не сомневаются в своих силах. В итоге, не получая положительного подкрепления о своих действиях, и находясь в постоянном цикле сомнений в себе, вы получаете эффект газлайтинга.
Если вы узнали себя, то в статье есть набор вопромов для рефлексии, которые помогут вернуть чувство реальности, понять, что вас заряжает на работе, и попробовать выкарабкаться из цикла сомнений в себе.
Газлайтинг – это такая форма психологической манипуляции, в результате которой жертва сомневается в адекватности своего восприятия окружающего, чувствует себя дефективной. Газлайтинг не всегда требует объекта и субъекта – в эту ловушку можно загнать себя самостоятельно.
Такой эффект часто получается из-за сомнений в себе: вы постоянно чувствуете, что могли бы справиться с рабочей ситуацией лучше, быть лучшим менеджером, переговорщиком, давать более качественную обратную связь – да что угодно еще. При этом с другими людьми внешне все отлично: любые доклады и статьи рассказывают про чьи-то менеджерские успехи, топ-перформеры на работе никогда не сомневаются в своих силах. В итоге, не получая положительного подкрепления о своих действиях, и находясь в постоянном цикле сомнений в себе, вы получаете эффект газлайтинга.
Если вы узнали себя, то в статье есть набор вопромов для рефлексии, которые помогут вернуть чувство реальности, понять, что вас заряжает на работе, и попробовать выкарабкаться из цикла сомнений в себе.
The Beautiful Mess
TBM 254: Self-Gaslighting and the Doubt Loop
Are you gaslighting yourself? Many of the dynamics we deal with at work are not overtly toxic or unhealthy. We know people mean well and do their best, even when nerves fray and things don't pan out. However, left unchecked, these situations (and how you…
Outcome roadmap
Иногда у вас может появиться необходимость визуализировать планы работы команды таким образом, чтобы стейкхолдерам было понятно, чем и когда вы собираетесь заниматься. Самый очевидный инструмент для этого – роадмап. В своем классическом виде он не очень хорошо сочетается с уровнем неопределенности, в котором работает большинство продуктовых команд. Определить свои цели на год вперед сравнительно просто, а вот заранее готовить список фичей – вредно.
Outcome roadmap – визуализация планов команды, подходящая для таких ситуаций. Вместо раскладывания фичей по таймлайну вы примерно определяете периоды, когда планируете фокусироваться на той или иной цели, и разбиваете каждую из них на этапы рисерча, дискавери, деливери и ожидания эффекта от изменений.
Посмотрите схемы, возможно, такой роадмап подойдет именно в вашей ситуации!
Иногда у вас может появиться необходимость визуализировать планы работы команды таким образом, чтобы стейкхолдерам было понятно, чем и когда вы собираетесь заниматься. Самый очевидный инструмент для этого – роадмап. В своем классическом виде он не очень хорошо сочетается с уровнем неопределенности, в котором работает большинство продуктовых команд. Определить свои цели на год вперед сравнительно просто, а вот заранее готовить список фичей – вредно.
Outcome roadmap – визуализация планов команды, подходящая для таких ситуаций. Вместо раскладывания фичей по таймлайну вы примерно определяете периоды, когда планируете фокусироваться на той или иной цели, и разбиваете каждую из них на этапы рисерча, дискавери, деливери и ожидания эффекта от изменений.
Посмотрите схемы, возможно, такой роадмап подойдет именно в вашей ситуации!