рилток


Гео и язык канала: Россия, Русский


О проектах, людях и как ими управлять — рилток регулярного менеджмента
Связь — @agolubovich

Связанные каналы

Гео и язык канала
Россия, Русский
Статистика
Фильтр публикаций


Продукт или аутсорс

Где лучше / круче / интереснее работать?

🏂 — продукт
⛷ — аутсорс

#чтолучше


Саббатикал (sabbatical)

Раньше был дауншифтинг, теперь саббатикал — пауза в работе, таблетка от выгорания.

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

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

Вот тут пишут, что инструмент активно применяется многими западными компаниями:
https://lifehacker.ru/sabbatical/

Был ли у кого-нить подобный опыт или хотя бы попытка? Как реагируют работодатели и коллеги? 🤔
Опишите в комментариях


Перейдя по ссылке, вы откроете видео-интервью Даши Герасименко — креатора с более чем 10-летним опытом.

Мы поговорили с Дашей как придумывать идеи, можно ли этому научиться, о креатоне и Breaking bad из Беларуси, об интеграции и женщине-президенте.

https://youtu.be/A4R8Twcng-4

Это пилотный, и надеюсь не последний, выпуск проекта «Есть два стула». Тут я буду расспрашивать и обсуждать с гостями социальные проекты и проблемы Беларуси, узнавать их мнения и что ими движет.

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

Еще один повод остаться вечером дома и залипнуть в ютубчик (сразу после интервью Anacondaz). Наслаждайтесь


Два бесплатных билета на IT Spring 2019 улетают авторам комментариев 8 (@DivaJuliya) и 21 (@yanyaKr).
Так решил рандомайзер🤷‍♂️
Мои поздравления победителям 🎉🎉🎉

Все, кто тоже хотят послушать доклады, но не выиграли билет, могут воспользоваться промо-кодом realtoktok_atITSpring и приобрести билет со скидкой в 10%

P.S. Прошу прощения, что мало сюда пишу. Обязательно это исправлю, но немного позже. Оставайтесь на связи ✊


Спикеров на IT Spring 2019 становится все больше, доклады весьма интересные. Цена вопроса — 279 BYN.

Как и обещал, разыгрываю бесплатный билет среди соих читателей.

Чтобы участвовать в розыгрыше, достаточно под этим постом оставить комментарий "хочу билет".
Ориентировчно через неделю, рандомом будет определен победитель.


​​Delegation poker

Один из инструментов management 3.0

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

На изображении вы видите описание каждой карты в отдельности. Общий их принцип в нарастании с 1 до 7, с полного контроля до полного делегирования.

Работа с картами похожа на Planning poker: у каждого участника своя колода, оглашаем кейс\задачу, каждый выбирает карту самостоятельно, все вместе открывают свои карты. Цель — независимо друг от друга прийти к общему решению. Карты совпали — отлично, нет — повод обсудить и переиграть еще раз.

Нужно стремиться к тому, чтобы задачи были в поле 5-7, ниже 4 намекает на излишний контроль и возможный микроменеджмент.


31 мая, в городе Минск, пройдет восьмая ежегодная IT Spring Conference. Доклады разделятся на 2 направления:
- Product & Data
- Delivery & Scaling
Среди выступающих сотрудники Яндекс, AppsFlyer, Gett, Booking.com и многие другие. Отличная возможность послушать доклады от лидирующих компаний и задать свои вопросы спикерам.

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

#друзьяканала


Правда или ложь

Хороший человек плохой менеджер
Хороший менеджер плохой человек

Согласны?


​​Инвестигейты

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

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

Давать оценку, когда вы совсем не уверены — ошибка. Таким образом вы подставляете не только себя, но и всю команду.

Хороший менеджер сам заметит сомнения у своего сотрудника и предложит потратить какое-то время на изучение вопроса, перед тем как давать оценку — за сроки все же отвечает именно он по итогу.


​​Спасибо за вашу обратную связь.

Самыми частыми запросами оказались:
- больше практических кейсов и “отсебятины”
- чаще выпускать посты

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

Буду учитывать все вами сказанное и делать канал интереснее — посмотрим, что получится)

P.S.
Еще просили смешных картинок)


​​Новогодняя ретроспектива

Хочется подвести небольшие итоги:
- канал существует 6,5 месяцев (первый пост от 18 июня)
- выпущено 29 постов (этот 30-ый), т.е. в среднем по 1 записи в неделю
- вас уже больше тысячи и это прекрасно 🙈
- я структурировал свои знания, завел несколько новых контактов. Очень надеюсь, помог кому-нибудь из вас стать лучше

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

P.S.
Всех с наступающими праздниками. Желаю вам обрести work-life-balance и всегда быть счастливыми 🖤

#ретроспектива


​​Быстрый старт в agile ретроспективы

Если вы давно не проводили ретроспективы, то окончание года для этого подходит как нельзя лучше. Только помните, что вы не Санта, а цель не в том чтобы поощрить хороших и найти плохих. Цель в улучшении процессов, фиксировании лучших практик, исповеди команды.

А если вы еще никогда не проводили ретроспективы, или командам наскучил их формат, то вам пригодится книга Алексея Кривицкого Быстрый старт в agile ретроспективы

В книге описаны 16 упражнений, которые можно комбинировать различными способами и проводить отличные ретроспективы.
Также автор сам предлагает несколько готовых комбинаций.

Книга из разряда “карманных” и читается за 1-2 часа. Столько же вам понадобиться чтобы подготовиться к ретроспективе и примерно столько же на ее проведение. 6 часов и профит — действительно быстрый старт.

#ретроспектива


​​Избыточный контроль

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

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

Контроль должен осуществляться регулярно и команда должна знать когда он будет, что конкретно будут проверять — все должны иметь возможность подготовиться. И конечно, он должен быть не очень часто. Лучше всего обсудить с командой формат и время и прийти к решению вместе (обосновав необходимость), чтобы все понимали его целесообразность, а не относились к этому как к пытке.

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

#контроль


Как взаимодействовать со сложными людьми

Еще одна занимательная ссылка

Крутая градация “сложных” типов всех ролей в разработке ПО. Тут и PdM-диктатор, и дизайнер-артист, разработчик-дива и еще много кто
А также интересные рекомендации как с ними работать и какую угрозу они представляют

Себя узнал на линейке менеджеров в The Meeting Scheduler и The Hoverer — есть над чем поработать 🙈

#огонечек


Описание вакансии

Скинули очень крутое описание вакансии, которым хочется поделиться.

Небольшая выдержка, а остальное по ссылке:

Будет нереальным плюсом (с этим можно сразу на финальное 😉):
• Jasmine для тебя не просто кустарник или спутница Аладдина
• Знаком с CI и delivery methods не только на курилке от DevOps инженера 
• Ты смеешься над шутками интервьюеров


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

Даже захотелось откликнуться чтобы узнать что будет дальше)

P.S. Раз уж речь зашла о написании вакансий, то можете еще почитать @nbabaeva/%D0%BA%D0%B0%D0%BA-%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C-%D0%B2%D0%B0%D0%BA%D0%B0%D0%BD%D1%81%D0%B8%D1%8E-bdfa2f362c43' rel='nofollow'>статью Натальи Бабаевой о том, как сегодня следует писать вакансии

#огонечек


Личности и профессионалы

Все, кто хоть как-то знаком с Agile, знают о манифесте и 12 основополагающих принципах. Если нет, прочтите здесь

Пятый принцип гласит
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

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

На беларуском языке
Гуртуйце праекты вакол зацікаўленых супрацоўнікаў. Стварыце вакол іх адпаведны асяродак, задавольце іхнія патрэбы і даверце ім выкананне працы.

Individuals = личности, супрацоўнікі = сотрудники.

Individuals ≠ профессионалы. Даже наоборот, профессионалы ≠ individuals. Как и супрацоўнікі ≠ individuals.

Методология не панацея и в английском варианте это видно — нужны не просто люди, профессионалы или сотрудники, а личности.

Это отражено в 12 принципе
Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

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

Возможно, в том числе именно поэтому набирает популярность концепция T-shaped и важности софт-скиллов. Все больше говорят о том, что профессионалов нужно растить внутри, а искать для этого личностей.

#agile


​​Мозговой штурм

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

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

Во время генерации идей, они (идеи) только генерируются. Не обсуждаются. Не критикуются. Идеи могут быть самыми разными, абсурдными, нереальными в исполнении, но на первом этапе они только генерируются и фиксируются. К примеру, если у вас не хватает разработчиков и кто-то предлагает их клонировать — просто зафиксируйте это, возможно на этапе обсуждения это натолкнет кого-то на другие, более реалистичные мысли.
Задайте таймер в 10 минут на этот этап и не бойтесь своих и чужих идей.

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

Ну и все это не будет иметь смысла если после обсуждения вы просто встанете и уйдете. Нужно выбрать 1-3 идеи и начинать их проверять. Для этого их нужно разложить на конкретные задачи и на каждую назначить ответственного.

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

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

#фасилитация


​​Оформление таблиц

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

Уметь хорошо оформлять таблицы (а также любые другие материалы) — хороший тон и полезный софт-скил. Поэтому ловите гифку-шпаргалку, которая сохранит зрение и психику ваших коллег.

У меня следовать всем правилам не получается (пока) и я порой использую заливку ячеек, но законом не запрещено, а иногда очень хочется.

#софтскил


Делегирование

Вчера дебютировал спикером на Dev Teams Agile meetup. Рассказывал о делегировании, старался без воды и с примерами. Затронул следующие темы:
- что такое делегирование
- какая польза для бизнеса / руководителя / исполнителя
- почему мы не делегируем
- как начать делегировать
- советы для исполнителей

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

Кликаем и смотрим

Я начинаю примерно на 15 минуте и вещаю минут 20 + вопросы из зала.

Кроме меня выступал Максим Ковтун, director of engineering в Workfusion. Он рассказывал какой путь проходит Workfusion для agile трансформации. Очень интересный доклад, длится 30-40 минут — советую послушать и посмотреть.

#делегирование


​​Shu Ha Ri

Концепция японских боевых искусств, согласно которой обучение делится на 3 этапа:
- Shu — следуй правилам, повторяй в точности за учителем
- Ha — ломай правила, экспериментируй, анализируй результат
- Ri — освобождение от правил, работа по общим принципам, уровень мастера

Эта же концепция описывается в agile-методологиях и она там не спроста. При внедрении гибких методологий (scrum, kanban и т.п.) их часто обвиняют в неэффективности:
- в нашем бизнесе это не работает
- с нашими людьми ничего не сделаешь
- у нас другая ситуация
- и т.д.

Если копнуть немного глубже, часто обнаруживается что дело вовсе не в методологии, а в преждевременном перескакивании с этапа Shu на Ha (либо полном игнорировании Shu):
- зачем нам стендапы, мы и так рядом сидим и всегда в курсе задач друг друга
- ретроспективы это долго, кто захочет высказаться — выскажется
- у нас есть доска, но мы редко ее актуализируем
- и т.д.

И так не только в agile или боевых искусствах. Концепция Shu Ha Ri применима и разумна для любой сферы, задачи, хобби и т.д. Чаще всего приводят в пример готовку:
- Shu — готовите строго по рецепту
- Ha — выбрасываете \ заменяете \ добавляете ингредиенты
- Ri — готовите по ощущениям и опыту

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

#agile #менеджмент

Показано 20 последних публикаций.

809

подписчиков
Статистика канала