рилток

2018-12-28 19:00:13 ​​Новогодняя ретроспектива

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

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

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

#ретроспектива Открыть/Комментировать

2018-12-20 19:00:42 ​​Быстрый старт в agile ретроспективы

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

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

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

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

#ретроспектива Открыть/Комментировать

2018-12-12 19:00:30 ​​Избыточный контроль

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

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

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

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

#контроль Открыть/Комментировать

2018-12-06 18:45:07 Как взаимодействовать со сложными людьми

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

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

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

#огонечек Открыть/Комментировать

2018-11-30 18:45:04 Описание вакансии

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

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

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

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

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

P.S. Раз уж речь зашла о написании вакансий, то можете еще почитать статью Натальи Бабаевой о том, как сегодня следует писать вакансии

#огонечек Открыть/Комментировать

2018-11-27 18:30:12 Личности и профессионалы

Все, кто хоть как-то знаком с 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 Открыть/Комментировать

2018-11-15 18:45:15 ​​Мозговой штурм

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

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

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

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

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

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

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

#фасилитация Открыть/Комментировать

2018-11-06 18:45:17 ​​Оформление таблиц

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

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

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

#софтскил Открыть/Комментировать

2018-10-31 19:00:32 Делегирование

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

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

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

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

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

#делегирование Открыть/Комментировать

2018-10-24 18:45:16 ​​Shu Ha Ri

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

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

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

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

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

#agile #менеджмент Открыть/Комментировать