Вебинар про мотивацию от участников нашего чата TLBootcamp
Ребята в нашем чате самоорганизовались и проводят вебинар про мотивацию сотрудников к обучению. Дмитрий Болдырев, организационный психолог, расскажет доклад про то, из чего образуется мотивация, как на нее можно влиять, как провести границу между мотивированием и манипуляцией и, главное, как мотивировать сотрудников к обучению. После доклада – сессия ответов на вопросы, которую будет модерировать Виталий Шароватов.
📆Дата: 3 августа, 19:00 по Москве
👉Ссылка на Zoom
Ребята в нашем чате самоорганизовались и проводят вебинар про мотивацию сотрудников к обучению. Дмитрий Болдырев, организационный психолог, расскажет доклад про то, из чего образуется мотивация, как на нее можно влиять, как провести границу между мотивированием и манипуляцией и, главное, как мотивировать сотрудников к обучению. После доклада – сессия ответов на вопросы, которую будет модерировать Виталий Шароватов.
📆Дата: 3 августа, 19:00 по Москве
👉Ссылка на Zoom
Zoom Video
Join our Cloud HD Video Meeting
Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference room solution…
Новость для опытных продакт-менеджеров
Найден быстрый путь в Тинькофф — Product Manager Week Offer. Можно пройти онлайн-собеседование за выходные и присоединиться к команде уже через неделю.
Дальше — создавать продукты для 30 млн пользователей, работать с данными, ориентироваться на свою экспертность и здравый смысл. Как работать, решать вам, — оценивают только результат.
Оставьте заявку до 9 августа: https://o.tinkoff.ru/wo-product.2023
Найден быстрый путь в Тинькофф — Product Manager Week Offer. Можно пройти онлайн-собеседование за выходные и присоединиться к команде уже через неделю.
Дальше — создавать продукты для 30 млн пользователей, работать с данными, ориентироваться на свою экспертность и здравый смысл. Как работать, решать вам, — оценивают только результат.
Оставьте заявку до 9 августа: https://o.tinkoff.ru/wo-product.2023
McNamara fallacy
Оказывается, есть специальный термин, которым обозначают практику принятия решения на основе одних только количественных данных и с отрицанием любых других сигналов – McNamara fallacy.
Назван он так в честь министра обороны США, который пытался свести войну во Вьетнаме к чисто математической модели, и судить об успехе по соотношению числа убитых с обеих сторон. Когда его спросили, почему он не учитывает отношение к войне среди мирного населения, он ответил, что раз не может измерить его, то оно не важно.
Напоминает большую часть попыток компаний уходить в хардкорную data driven культуру🤷♂️
Оказывается, есть специальный термин, которым обозначают практику принятия решения на основе одних только количественных данных и с отрицанием любых других сигналов – McNamara fallacy.
Назван он так в честь министра обороны США, который пытался свести войну во Вьетнаме к чисто математической модели, и судить об успехе по соотношению числа убитых с обеих сторон. Когда его спросили, почему он не учитывает отношение к войне среди мирного населения, он ответил, что раз не может измерить его, то оно не важно.
Напоминает большую часть попыток компаний уходить в хардкорную data driven культуру🤷♂️
Wikipedia
McNamara fallacy
making a decision based solely on quantitative observations (or metrics) and ignoring all others
Бреслав и Ложечкин: Performance Management
Вышел новый эпизод моего любимого тимлидского подкаста! Любимого не только потому, что мы в Подлодке его продюсируем, но и потому, что я сам слушаю каждый эпизод. Тема выпуска в этот раз – оценка перфоманса инженеров и выстраивание системы мотивации для творческих профессий в целом.
Вышел новый эпизод моего любимого тимлидского подкаста! Любимого не только потому, что мы в Подлодке его продюсируем, но и потому, что я сам слушаю каждый эпизод. Тема выпуска в этот раз – оценка перфоманса инженеров и выстраивание системы мотивации для творческих профессий в целом.
Readability кода в Google
В Google есть интересная практика, направленная на повышение читаемости кода – readability reviews. Каждый pull request ревьюится не только связанными с конкретным компонентом людьми, но и как минимум одним экспертом в языке, на котором написан код. Эксперт в этом контексте – инженер, который хорошо знает лучшие практики конкретного языка, рекомендуемые паттерны, принятые в компании стиль кода и список библиотек.
С одной стороны, такой процесс добавляет жуткой бюрократии – вместо обсуждения действительно полезных вопросов, вы будете зарубаться с незнакомым вам человеком о том, насколько правильно названа какая-то переменная (намеренно утрированный кейс, я предполагаю, что такие вещи все-таки на уровне линтера закрываются). Но с другой стороны, в том числе благодаря этому подходу Google получает похожие друг на друга кодовые базы вне зависимости от конкретного отдела и продукта. А, значит, переход людей между проектами становится значительно проще.
В Google есть интересная практика, направленная на повышение читаемости кода – readability reviews. Каждый pull request ревьюится не только связанными с конкретным компонентом людьми, но и как минимум одним экспертом в языке, на котором написан код. Эксперт в этом контексте – инженер, который хорошо знает лучшие практики конкретного языка, рекомендуемые паттерны, принятые в компании стиль кода и список библиотек.
С одной стороны, такой процесс добавляет жуткой бюрократии – вместо обсуждения действительно полезных вопросов, вы будете зарубаться с незнакомым вам человеком о том, насколько правильно названа какая-то переменная (намеренно утрированный кейс, я предполагаю, что такие вещи все-таки на уровне линтера закрываются). Но с другой стороны, в том числе благодаря этому подходу Google получает похожие друг на друга кодовые базы вне зависимости от конкретного отдела и продукта. А, значит, переход людей между проектами становится значительно проще.
Forwarded from 🍻 Стас под пивас
🪚 Инструменты тимлида
На неделе встретились лидовской гильдией. Хотели закопаться в роадмап тимлида и набрать листочков на прокачку начинающего лида, но все скатилось в обсуждение технических инструментов: таск-трекеров, тулзов для фокусировки и прочее. Приведу подборку по группам с комментариями.
✅ Таск-трекеры
Лидером оказался Todoist. Но как по мне, без разницы что использовать и вообще я цели на месяц веду снаружи, а тут операционные проекты, которые я делаю прямо сейчас.
Для прокачки своей системы здорово поможет Дорофеев “Джедайские техники”. Он притапливает за свой инструмент, но можно набрать кучу дельных советов для построения собственной.
📝 Заметки
Всех обошел Obsidian. Если кто не в курсе, это маркдаун-редактор с плагинами. При помощи него можно сделать собственный репозиторий знаний а-ля маленькую Википедию.
Тоже им пользуюсь, но считаю, что только для лидских задач этот инструмент – оверкилл.
Возможно вам надо вести карточки сотрудников, проекты, ну может какие-то общие мысли. Из-за того, что структура заранее известна, можно обойтись даже Apple заметками.
Еще в пуле инструментов оказались:
- Confluence. Ну а почему бы не держать доку и рабочие заметки в одной системе?
- Miro. Медитировать над организационной структурой в нем намного удобнее, чем в том же мардаун-файле. Отдельный плюс – удобство шаринга и совместной работы
🎯 Фокусировка
Часть ребят использует технику Pomodoro с фокусировкой интервалами 25-45 минут.
Приложений и физических трекеров – бесконечность.
Сам комбинирую технику с режимом “Do not disturb”. Мне помодорки помогают в двух случаях:
- Сфокусировано поработать
- Стартануть неприятное дело, которое прокрастинирую. Спустя одну-две помодорки разгоняешься и уже идет с удовольствием
✉️ Почта / мессенджеры
Планирую написать “Новейшие правила деловой переписки”. В ней будет одна страница, в которой будет капсом: не читать почту.
У нас есть корпоративный мессенджер, туда сам залезаю раз в неделю.
Я шел от идеи “если ответить на сообщение спустя час – мир не рухнет”, и вот что со мной стало… Если что, про почту наброс, туда залезаю тоже раз в неделю.
Страдают только финансовые аналитики, которые подбивают ФОТ раз в квартал и пишут письма, а когда реакции нет – пытаются догнать в корпоративном мессенджере. Но в остальных 99% случаев все работает прекрасно.
Основная переписка команд происходит в телеге. Знаю, что некоторые заводят отдельные аккаунты. Мне хватает папки.
📅 Календарь
Тут вообще скучно. День, а лучше два без встреч. Забитый час каждый день под обед.
Встречи по возможности перевожу в переписку.
Знаю радикальных ребят, которые встречи без агенды отменяют не глядя. Но я до этого еще не дошел. Только про почту такой смелый.
—
Есть еще всякие зумы, гугл таблицы, дропбоксы и прочее, но там вообще ничего интересного.
Если есть мегатулзы неупомянутые выше, делитесь 😉
#тимлидство
На неделе встретились лидовской гильдией. Хотели закопаться в роадмап тимлида и набрать листочков на прокачку начинающего лида, но все скатилось в обсуждение технических инструментов: таск-трекеров, тулзов для фокусировки и прочее. Приведу подборку по группам с комментариями.
✅ Таск-трекеры
Лидером оказался Todoist. Но как по мне, без разницы что использовать и вообще я цели на месяц веду снаружи, а тут операционные проекты, которые я делаю прямо сейчас.
Для прокачки своей системы здорово поможет Дорофеев “Джедайские техники”. Он притапливает за свой инструмент, но можно набрать кучу дельных советов для построения собственной.
📝 Заметки
Всех обошел Obsidian. Если кто не в курсе, это маркдаун-редактор с плагинами. При помощи него можно сделать собственный репозиторий знаний а-ля маленькую Википедию.
Тоже им пользуюсь, но считаю, что только для лидских задач этот инструмент – оверкилл.
Возможно вам надо вести карточки сотрудников, проекты, ну может какие-то общие мысли. Из-за того, что структура заранее известна, можно обойтись даже Apple заметками.
Еще в пуле инструментов оказались:
- Confluence. Ну а почему бы не держать доку и рабочие заметки в одной системе?
- Miro. Медитировать над организационной структурой в нем намного удобнее, чем в том же мардаун-файле. Отдельный плюс – удобство шаринга и совместной работы
🎯 Фокусировка
Часть ребят использует технику Pomodoro с фокусировкой интервалами 25-45 минут.
Приложений и физических трекеров – бесконечность.
Сам комбинирую технику с режимом “Do not disturb”. Мне помодорки помогают в двух случаях:
- Сфокусировано поработать
- Стартануть неприятное дело, которое прокрастинирую. Спустя одну-две помодорки разгоняешься и уже идет с удовольствием
✉️ Почта / мессенджеры
Планирую написать “Новейшие правила деловой переписки”. В ней будет одна страница, в которой будет капсом: не читать почту.
У нас есть корпоративный мессенджер, туда сам залезаю раз в неделю.
Я шел от идеи “если ответить на сообщение спустя час – мир не рухнет”, и вот что со мной стало… Если что, про почту наброс, туда залезаю тоже раз в неделю.
Страдают только финансовые аналитики, которые подбивают ФОТ раз в квартал и пишут письма, а когда реакции нет – пытаются догнать в корпоративном мессенджере. Но в остальных 99% случаев все работает прекрасно.
Основная переписка команд происходит в телеге. Знаю, что некоторые заводят отдельные аккаунты. Мне хватает папки.
📅 Календарь
Тут вообще скучно. День, а лучше два без встреч. Забитый час каждый день под обед.
Встречи по возможности перевожу в переписку.
Знаю радикальных ребят, которые встречи без агенды отменяют не глядя. Но я до этого еще не дошел. Только про почту такой смелый.
—
Есть еще всякие зумы, гугл таблицы, дропбоксы и прочее, но там вообще ничего интересного.
Если есть мегатулзы неупомянутые выше, делитесь 😉
#тимлидство
Почему нельзя дать точную оценку большим проектам: статистическая модель
Исходя из предпосылки о том, что при оценке времени на выполнение задачи люди чаще называют медиану, а не среднее значение, автор статьи построил интересную модель. А потом еще и проверил ее на не самом релевантном, но все же датасете.
Основные выводы такие:
👉При складывании оценок задач друг с другом, что часто пытаются сделать в проектном планировании, ошибки накапливаются, и все становится очень плохо.
👉Время выполнения проекта зависит не от самых больших задач, а от задач с наибольшим уровнем неопределенности.
Код модели вы можете покрутить сами на GitHub. А если захочется обсуждений – длиннющий тред на Hacker News по мотивам поста.
Исходя из предпосылки о том, что при оценке времени на выполнение задачи люди чаще называют медиану, а не среднее значение, автор статьи построил интересную модель. А потом еще и проверил ее на не самом релевантном, но все же датасете.
Основные выводы такие:
👉При складывании оценок задач друг с другом, что часто пытаются сделать в проектном планировании, ошибки накапливаются, и все становится очень плохо.
👉Время выполнения проекта зависит не от самых больших задач, а от задач с наибольшим уровнем неопределенности.
Код модели вы можете покрутить сами на GitHub. А если захочется обсуждений – длиннющий тред на Hacker News по мотивам поста.
Как повышать людей в корпорациях
В больших технологических компаниях любая попытка повышения влечет за собой кучу политики. Чаще всего оно проявляется следующим образом – повышение легко согласуют тем, кто работал над заметными для всей компании проектами, но очень сложно тем, кто занимался менее волнующими, но не менее важными вещами.
Я сам много сталкивался с аналогичной проблемой, когда лидил мобильщиков и фронтендеров. В соседних командах бэкендеры довольно легко получали повышения до Staff уровня, потому что занимались проектами, масштаб, важность и сложность которых были очевидны всем. Например, разносили всю инфраструктуру и данные из одного дата-центра в несколько. При этом настолько же выгодно выглядящих задач на клиентсайде практически не было, хотя ребята делали очень сложные и важные по-своему штуки. И периодически возникала дурацкая ситуация – нужно было либо заниматься тем, что действительно важно, но что будет очень сложно продать комитету по повышениям, либо брать яркий и заметный проект, который на самом деле принесет не очень много ценности.
В статье дают несколько советов, как жить в таких условиях:
👉Важно повышать людей за разные виды вклада в общий результат, так как в итоге вам важны и те, кто умеет запускать сложные проекты, и те, кто обладает глубокими доменными знаниями и на ком держатся существующие системы, и те, кто выстраивает процессы в команде.
👉Как можно раньше привлекайте на свою сторону своих пиров, продавая им идею из предыдущего пункта.
👉Готовьтесь к обсуждению повышений с соответствующим комитетом/человеком заранее, подготовив всю нужную аргументацию и факты.
👉Если повышение случилось, расскажите о нем команде публично – это поможет людям откалиброваться в своих ожиданиях за что дается повышение.
В больших технологических компаниях любая попытка повышения влечет за собой кучу политики. Чаще всего оно проявляется следующим образом – повышение легко согласуют тем, кто работал над заметными для всей компании проектами, но очень сложно тем, кто занимался менее волнующими, но не менее важными вещами.
Я сам много сталкивался с аналогичной проблемой, когда лидил мобильщиков и фронтендеров. В соседних командах бэкендеры довольно легко получали повышения до Staff уровня, потому что занимались проектами, масштаб, важность и сложность которых были очевидны всем. Например, разносили всю инфраструктуру и данные из одного дата-центра в несколько. При этом настолько же выгодно выглядящих задач на клиентсайде практически не было, хотя ребята делали очень сложные и важные по-своему штуки. И периодически возникала дурацкая ситуация – нужно было либо заниматься тем, что действительно важно, но что будет очень сложно продать комитету по повышениям, либо брать яркий и заметный проект, который на самом деле принесет не очень много ценности.
В статье дают несколько советов, как жить в таких условиях:
👉Важно повышать людей за разные виды вклада в общий результат, так как в итоге вам важны и те, кто умеет запускать сложные проекты, и те, кто обладает глубокими доменными знаниями и на ком держатся существующие системы, и те, кто выстраивает процессы в команде.
👉Как можно раньше привлекайте на свою сторону своих пиров, продавая им идею из предыдущего пункта.
👉Готовьтесь к обсуждению повышений с соответствующим комитетом/человеком заранее, подготовив всю нужную аргументацию и факты.
👉Если повышение случилось, расскажите о нем команде публично – это поможет людям откалиброваться в своих ожиданиях за что дается повышение.
Hey
Making the bug fixes count. Or how to fix promotions in tech companies
Yesterday, I came across yet another article explaining how promotions work at big tech. At this point, it's no surprise to anyone that individual contributors and the management team prefer to work on "impactful" projects rather than polish a specific product…
Как помогать людям меняться
Скорее всего, у вас есть коллеги, поведение которых вы хотели бы изменить. Кто-то плохо делегирует, кто-то любит прилетать чаечкой, а кто-то – слишком мягкий, и спускает на тормозах любую проблему. Два стандартных подхода к такой ситуации – конфронтация, когда вы даете человеку прямой фидбэк про то, что вас не устраивает, и пассивность, когда вы отказываетесь решать проблему, надеясь, что она решится сама собой.
В статье проводят параллель между наличием таких деструктивных поведений и наличием алкогольной зависимости. И то, и другое – признак присутствия у человека слепого пятна, из-за которого он находится в отрыве от реальности. Идея в том, что вместо двух стандартных подходов можно попробовать использовать более хитрые техники, которые в борьбе с зависимостями дают больше результата. Вот некоторые из них:
👉Давая фидбэк, позволяйте человеку сохранить ощущение своей автономности.
👉Помогайте увидеть долгосрочные последствия текущего поведения, задавая наводящие вопросы.
👉Хвалите, когда человек ведет себя правильно.
👉В целом инвестируйте в ваши отношения с этим человеком и выстраивайте доверие.
👉Не давайте своим собственным эмоциям выходить из под контроля, даже когда человек ведет себя деструктивно.
Скорее всего, у вас есть коллеги, поведение которых вы хотели бы изменить. Кто-то плохо делегирует, кто-то любит прилетать чаечкой, а кто-то – слишком мягкий, и спускает на тормозах любую проблему. Два стандартных подхода к такой ситуации – конфронтация, когда вы даете человеку прямой фидбэк про то, что вас не устраивает, и пассивность, когда вы отказываетесь решать проблему, надеясь, что она решится сама собой.
В статье проводят параллель между наличием таких деструктивных поведений и наличием алкогольной зависимости. И то, и другое – признак присутствия у человека слепого пятна, из-за которого он находится в отрыве от реальности. Идея в том, что вместо двух стандартных подходов можно попробовать использовать более хитрые техники, которые в борьбе с зависимостями дают больше результата. Вот некоторые из них:
👉Давая фидбэк, позволяйте человеку сохранить ощущение своей автономности.
👉Помогайте увидеть долгосрочные последствия текущего поведения, задавая наводящие вопросы.
👉Хвалите, когда человек ведет себя правильно.
👉В целом инвестируйте в ваши отношения с этим человеком и выстраивайте доверие.
👉Не давайте своим собственным эмоциям выходить из под контроля, даже когда человек ведет себя деструктивно.
Every
The Art of Subtle Influence
How to lead when you don’t have control
Знания-Ответственность-Полномочия
Чтобы выполнять свою работу в определенной области, менеджеру важны три вещи: знания, ответственность и полномочия. Если один или два из этих факторов отсутствуют, появляется один из поведенческих антипаттернов. В статье разбирается, как они выглядят.
Чтобы выполнять свою работу в определенной области, менеджеру важны три вещи: знания, ответственность и полномочия. Если один или два из этих факторов отсутствуют, появляется один из поведенческих антипаттернов. В статье разбирается, как они выглядят.
Ловим всех зайцев, за которыми гонимся: как эффективно управлять несколькими проектами
Легко держать все в голове или календаре, когда под вашим управлением 2-3 проекта, но рано или поздно, если вы хотите расти, их станет 10, 15, а то и больше… В этом случае, чтобы не сойти с ума от количества задач и четко контролировать работу всех команд, понадобятся дополнительные компетенции.
Где такому учат? На бесплатном онлайн-митапе от OTUS.
23 августа в 19:00 мск Дмитрий Белоусов – Sr. Director of Production в Lineate с 10+ годами опыта в IT и опытом управления 25 проектами одновременно – расскажет, как:
▫️Выстраивать процесс мониторинга и контроля проектов
▫️Выбрать необходимые метрики для контроля здоровья проекта и продукта
▫️Внедрять новые процессы в работу команды
Также все участники встречи получат бесплатный чек-лист по формированию системы контроля за портфелем проектов.
➡️ Не упустите возможность бесплатно прокачать свои управленческие скиллы, регистрируйтесь на мероприятие прямо сейчас, чтобы ничего не пропустить: https://otus.pw/XkLX/
Нативная интеграция. Информация о продукте на сайте www.otus.ru
Легко держать все в голове или календаре, когда под вашим управлением 2-3 проекта, но рано или поздно, если вы хотите расти, их станет 10, 15, а то и больше… В этом случае, чтобы не сойти с ума от количества задач и четко контролировать работу всех команд, понадобятся дополнительные компетенции.
Где такому учат? На бесплатном онлайн-митапе от OTUS.
23 августа в 19:00 мск Дмитрий Белоусов – Sr. Director of Production в Lineate с 10+ годами опыта в IT и опытом управления 25 проектами одновременно – расскажет, как:
▫️Выстраивать процесс мониторинга и контроля проектов
▫️Выбрать необходимые метрики для контроля здоровья проекта и продукта
▫️Внедрять новые процессы в работу команды
Также все участники встречи получат бесплатный чек-лист по формированию системы контроля за портфелем проектов.
Нативная интеграция. Информация о продукте на сайте www.otus.ru
Please open Telegram to view this post
VIEW IN TELEGRAM
Always do Extra
Представьте, что вы делаете какую-то задачу, и она заняла у вас на 20% меньше времени, чем вы хотели на нее потратить. В этот момент у вас появляется следующая развилка:
1. Не делать ничего
2. Взять следующую задачу (doing more work в оригинальной статье)
3. Сделать текущую задачу лучше (doing extra work)
Отличие второго и третьего пункта в том, что выполнение задач на потоке – это обычная работа, то, что от вас ожидается. Выполнение extra work – возможность самому придумать цель, которая одновременно и проекту поможет, и прокачает какие-то ваши скиллы и знания. А заодно еще и поможет превысить ожидания и в каких-то случаях создать вау-эффект.
Так вот, автор топит за то, что в большинстве случаев на такой развилке лучше выбирать extra, а не more. При этом, конечно, важно не заигрываться в интересные задачи и не забывать о реальности.
Представьте, что вы делаете какую-то задачу, и она заняла у вас на 20% меньше времени, чем вы хотели на нее потратить. В этот момент у вас появляется следующая развилка:
1. Не делать ничего
2. Взять следующую задачу (doing more work в оригинальной статье)
3. Сделать текущую задачу лучше (doing extra work)
Отличие второго и третьего пункта в том, что выполнение задач на потоке – это обычная работа, то, что от вас ожидается. Выполнение extra work – возможность самому придумать цель, которая одновременно и проекту поможет, и прокачает какие-то ваши скиллы и знания. А заодно еще и поможет превысить ожидания и в каких-то случаях создать вау-эффект.
Так вот, автор топит за то, что в большинстве случаев на такой развилке лучше выбирать extra, а не more. При этом, конечно, важно не заигрываться в интересные задачи и не забывать о реальности.
Девять подходов к проведению health check команды
На позиции тимлида хелсчек – довольно странное занятие. Ты и так должен постоянно держать руку на пульсе всего происходящего, регулярно общаться со всеми участниками команды, и иметь непротиворечивую и близкую к реальности картину мира. Но вот если вы менеджер нескольких команд, то разумный хелсчек может помочь не пропустить сигналы о том, что в происходящее в какой-то команде нужно посмотреть повнимательнее.
В статье предлагается сразу девять моделей, посмотрев на которые, вы сможете собрать что-то, подходящее именно вам. Если что, можели по сути одинаковы, различаются только конкретные вопросы и плюшечки визуализации. Вот некоторые из моделей:
1️⃣Parabol's model: анонимная оценка настроения всех в команде.
2️⃣Spotify Squad model: каждый член команды оценивает разные аспекты процессов, продукта и технологий по светофору.
3️⃣Team health radar: самооценка по пяти категориям и представление результата в виде радара.
На позиции тимлида хелсчек – довольно странное занятие. Ты и так должен постоянно держать руку на пульсе всего происходящего, регулярно общаться со всеми участниками команды, и иметь непротиворечивую и близкую к реальности картину мира. Но вот если вы менеджер нескольких команд, то разумный хелсчек может помочь не пропустить сигналы о том, что в происходящее в какой-то команде нужно посмотреть повнимательнее.
В статье предлагается сразу девять моделей, посмотрев на которые, вы сможете собрать что-то, подходящее именно вам. Если что, можели по сути одинаковы, различаются только конкретные вопросы и плюшечки визуализации. Вот некоторые из моделей:
1️⃣Parabol's model: анонимная оценка настроения всех в команде.
2️⃣Spotify Squad model: каждый член команды оценивает разные аспекты процессов, продукта и технологий по светофору.
3️⃣Team health radar: самооценка по пяти категориям и представление результата в виде радара.
Конференция техлидов из E-com
Ребята из СберМаркета проводят тематическую конференцию про E-com. Техлиды из разных команд Озона, Lamoda, X5 и самого СберМаркета будут рассказывать про интересные технические кейсы, с которыми они работают. В программе: быстрый запуск новых проектов, работа с несколькими датацентрами, организация платформенных команд и проектирование систем.
📆Дата: 24 августа, 16:00 по Москве
👉Регистрация
Реклама. ООО «Инстамарт Сервис», 115035, Москва, ОГРН 1187746494980. 18+
Ребята из СберМаркета проводят тематическую конференцию про E-com. Техлиды из разных команд Озона, Lamoda, X5 и самого СберМаркета будут рассказывать про интересные технические кейсы, с которыми они работают. В программе: быстрый запуск новых проектов, работа с несколькими датацентрами, организация платформенных команд и проектирование систем.
📆Дата: 24 августа, 16:00 по Москве
👉Регистрация
Реклама. ООО «Инстамарт Сервис», 115035, Москва, ОГРН 1187746494980. 18+
Self-hosted альтернативы инструментам Atlassian
Я пропустил новости про уход из России Atlassian стека. Если вас это коснулось, в статье рассказывают про альтернативы, которые можно поднять у себя на сервере.
Что использовать вместо Jira:
👉Plane
👉Redmine
👉Tuleap
Что использовать вместо Confluence:
👉Outline
👉Bookstack
👉Docuwiki
Что использовать вместо Trello:
👉Mattermost Boards
👉Logseq
👉Kanboard
Если вы можете порекомендовать другие аналоги – делитесь в комментариях!
Я пропустил новости про уход из России Atlassian стека. Если вас это коснулось, в статье рассказывают про альтернативы, которые можно поднять у себя на сервере.
Что использовать вместо Jira:
👉Plane
👉Redmine
👉Tuleap
Что использовать вместо Confluence:
👉Outline
👉Bookstack
👉Docuwiki
Что использовать вместо Trello:
👉Mattermost Boards
👉Logseq
👉Kanboard
Если вы можете порекомендовать другие аналоги – делитесь в комментариях!
Хабр
Блокировка Trello и Jira? Ничего страшного, поднимаем свой сервер
Redmine и Plane — опенсорсные альтернативы Jira на своём хостинге Компания Atlassian в рассылке для пользователей предупредила , что все аккаунты в России и Беларуси будут принудительно отключены....
Как построить доверие в общении
Отсутствие доверия друг к другу с кем-то, с кем вы должны работать рука об руку каждый день, это огромная проблема. За любой фразой, даже нейтральной по смыслу, вы будете автоматически замечать негативный подтекст, отвечать тем же самым, и в итоге отношения продолжат идти вниз по спирали.
Построить доверие с такой низкой базы очень сложно, но все еще возможно. Я проходил через такую ситуацию несколько раз, и советы из статьи резонируют:
👉Говорите с человеком осторожнее, всегда помня о том, что каждое слово, которое может быть превратно истолковано, пойдет во вред.
👉Если у вас есть ощущение, что вы могли сказать что-то лишнее, то лучше проговорите эти опасения явно. Пусть даже с момента общения прошло какое-то время.
👉Если вам кажется, что на вас наехали, попробуйте рассказать человеку вашу картину мира, и почему сказанное им вы воспринимаете как агрессию или нарушение границ. Главное – подчеркнуть, что это не реальность, а то, как вы ее воспринимаете.
👉Эмпирическое правило – для здоровых доброжелательных отношений на каждый негативный эпизод должно приходиться пять позитивных. Старайтесь их создавать, просто говоря что-то хорошее по возможности.
Отсутствие доверия друг к другу с кем-то, с кем вы должны работать рука об руку каждый день, это огромная проблема. За любой фразой, даже нейтральной по смыслу, вы будете автоматически замечать негативный подтекст, отвечать тем же самым, и в итоге отношения продолжат идти вниз по спирали.
Построить доверие с такой низкой базы очень сложно, но все еще возможно. Я проходил через такую ситуацию несколько раз, и советы из статьи резонируют:
👉Говорите с человеком осторожнее, всегда помня о том, что каждое слово, которое может быть превратно истолковано, пойдет во вред.
👉Если у вас есть ощущение, что вы могли сказать что-то лишнее, то лучше проговорите эти опасения явно. Пусть даже с момента общения прошло какое-то время.
👉Если вам кажется, что на вас наехали, попробуйте рассказать человеку вашу картину мира, и почему сказанное им вы воспринимаете как агрессию или нарушение границ. Главное – подчеркнуть, что это не реальность, а то, как вы ее воспринимаете.
👉Эмпирическое правило – для здоровых доброжелательных отношений на каждый негативный эпизод должно приходиться пять позитивных. Старайтесь их создавать, просто говоря что-то хорошее по возможности.
Вебинар про работу с техдолгом
Когда я работал в Авито, процесс работы с техническим долгом был выстроен там очень круто. Несколько практик, которые этому помогали:
👉Ответственность за своевременное решение техдолга, как и за общее качество продукта, лежала на тимлиде. Соответственно, о его перфомансе во многом судили именно по этому.
👉Продакт и тимлид находились в разных “ветвях власти”. Ни один из них не мог диктовать другому правила игры. Это вело к постоянному конструктивному конфликту и наличию баланса между продуктовым и техническим бэклогом.
👉Наличие единых по всем командам практик health check помогало СТО и руководителям разработки следить, что техдолг находится под контролем у каждой из команд.
👉Большие куски технического долга, для решения которых требовалось усилие многих команд в течение продолжительного времени, выносились как цели на уровень компании, и получали buy-in от бизнеса. Так было, например, с распилом монолита, или с переездом в несколько дата центров.
Так вот, ребята в Авито хорошо шарят в практиках постепенной борьбы с техническим долгом. Александр Прянин, Technical Unit Lead одной из команд, скоро проводит воркшоп про то, как формировать и приоритизировать техдолг, контролировать его прирост и убыль и минимизировать его накопление.
📆Дата: 30 августа, 19:00 по Москве
👉Регистрация
Когда я работал в Авито, процесс работы с техническим долгом был выстроен там очень круто. Несколько практик, которые этому помогали:
👉Ответственность за своевременное решение техдолга, как и за общее качество продукта, лежала на тимлиде. Соответственно, о его перфомансе во многом судили именно по этому.
👉Продакт и тимлид находились в разных “ветвях власти”. Ни один из них не мог диктовать другому правила игры. Это вело к постоянному конструктивному конфликту и наличию баланса между продуктовым и техническим бэклогом.
👉Наличие единых по всем командам практик health check помогало СТО и руководителям разработки следить, что техдолг находится под контролем у каждой из команд.
👉Большие куски технического долга, для решения которых требовалось усилие многих команд в течение продолжительного времени, выносились как цели на уровень компании, и получали buy-in от бизнеса. Так было, например, с распилом монолита, или с переездом в несколько дата центров.
Так вот, ребята в Авито хорошо шарят в практиках постепенной борьбы с техническим долгом. Александр Прянин, Technical Unit Lead одной из команд, скоро проводит воркшоп про то, как формировать и приоритизировать техдолг, контролировать его прирост и убыль и минимизировать его накопление.
📆Дата: 30 августа, 19:00 по Москве
👉Регистрация