2%

2021-08-02 12:00:17 Всем привет!
Меня зовут Антон Чижов и я рад стать автором этого канала:) С кем-то из вас мы знакомы, со многими нет, поэтому будет совсем не лишним представиться.

Я много работал в проектном менеджменте в сфере организации крупных мероприятий в разных странах и в том числе засчет этого посетил более 50 стран. В IT я перешел на роль релиз-менеджера, а в ходе трансформации стал скрам мастером и успел поработать в этой роли в двух крупных компаниях более, чем с 10 разными командами.

Последние пару лет я работал в Сбере - сначала agile-коучем (запускал и перезапускал команды, продукты, трайбы и вот это все), затем в офисе agile-трансформации, а совсем недавно перешёл в МВидео-Эльдорадо на позицию руководителя направления Agile и вместе с Сергеем запускаю цифровую трансформацию.

Буду писать в этом канале свои мысли по возникающим рабочим кейсам и не только:-) Открыть/Комментировать

2021-08-02 09:00:14 Понедельник, обычно, про планирование, то есть #retro уже прошло.
Нашел вам "поорать в голос" пост на тему "есть что обсудить на ретро"

Автор гогочет в голос между строк, но я почти уверен, что данный пост, полный грустных, комичных наблюдений и витиеватых оборотов из 16-17 веков, написал всерьез и взаправду. Без юмора в наше время никак. Будем тренироваться Открыть/Комментировать

2021-07-31 05:15:07 Практика любви к себе

По наводке великолепной Лили решил посмотреть на Joe Hudson.

В одном из его выступлений он приводит практику проговаривания вслух вещей, за которые стыдно

Все, что нужно сделать.
Берём поведение, за которое хочется себя поругать (например, слишком часто сижу в телефона)
Закрываем глаза и говорим формулу: я делаю «действие» и это нормально.

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

Если решите попробовать, напишите в личку или в комменты, как оно было? Открыть/Комментировать

2021-07-30 18:00:20 Вот удивительно, как так получилось, что #PMI инкрементальную разработку понимает как разработку по каскаду
Открыть/Комментировать

2021-07-29 09:00:13 Когда-то Rich Hickey (автор языка #closure) ввёл термин «Hammock driven development» (разработка через раздумывание на гамаке), в противоположность распространённому подходу на картинке в посте

Let’s make development great again Открыть/Комментировать

2021-07-28 13:38:57 Из избранного: Одна из самых важных активностей продакта

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

Существует много методов выбора самых важных задач из важных и менее важных. Я расскажу о трёх, которыми пользуюсь чаще всего.

Скоринг. Это может быть ваша личная система оценки задач по выбранным критериям или любая из популярных, таких как RICE или ICE. Главное постараться объективно оценивать каждую задачу по каждому критерию. Самый простой способ — табличка, где в строках задачи, в столбцах критерии оценки. Каждую задачу можно оценить по критериям с использованием шкалы от 1 до 4, можно задать коэффициенты критериям (они могут как увеличивать, так и уменьшать вклад в общий рейтинг) и затем посчитать суммарную оценку. В RICE вам ещё и формулу для рассчета оценки дадут готовую. После такого разбора задачи можно просто сортировать по оценке.

Модель Кано. Это не КАно из Mortal Kombat, это КанО Очень простой подход, который направлен на баланс в разработке с точки зрения потребностей пользователей. Делим все фичи на must have, performance и wow-effect features. Для поддержания интереса к продукту нужно делать все must have, периодически добавлять performance и иметь несколько очень крутых фич для wow эффекта. Погуглите картинку "модель Кано", она все объясняет.

User Story Mapping. Сначала кажется, что этот инструмент не про приоритеты. Доска с карточками-фичами очень хорошо помогает визуализировать продукт, которого ещё нет. Сверху идут цели пользователя, ниже фичи, которые помогают их достигать и связанные с ними элементы продукта. Но финальный шаг составления User Story Map это деление карточек на релизы. Сначала пишем цели релиза и его ожидаемое влияние на бизнес, пользователя и метрики. Затем отсекаем всё лишнее кривой линией. Всё, что осталось выше первой линии — наш MVP, между первой и второй — следующий релиз и так далее.

Есть ещё масса методов, но я советую использовать эти три в первую очередь. И, конечно, здравый смысл!

——
Репост с разрешения автора канала Владимира Меркушева Открыть/Комментировать

2021-07-28 09:00:14 Как масштабировать agile

Алистер-наше-все-подписант-манифеста выступил до короны со своим Heart of Agile.

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

Но ценность его выступления в разговоре про первое слово «collaborate» (взаимодействие).
Как говорит Алистер, если пристально смотреть на это слово, то через некоторое время в голове начнут появляться разные слова.
Например, «executive bonuses» (бонусы ТОПов ). Если у ребят противоборствующие цели (жизза), если у них конкуренция за ресурсы (скатилась слеза умиления) и проч, то о каком «масштабировании agile» может идти речь.

Аналогичное верно и для личных performance review, что все ещё встречается много где в организациях нашей страны. Открыть/Комментировать

2021-07-27 09:00:07 Любой совет в формате Тони Роббинса «делай хорошо, а нехорошо не делай» - очевидно справедлив

Вот, например, принцип 3х писем, когда нужно прекращать переписку и встречаться лично
При этом, как и всегда, дьявол в деталях, а именно: как именно эти 3 письма должны быть написаны, чтобы правило сработало

Один из принципов, которые стоит использовать в почте:
«В письме все есть»
То есть читателю письма не надо делать дополнительных телодвижений, чтобы получить доступ к контексту Открыть/Комментировать

2021-07-26 08:50:12 Вакансия agile-коуч в МВидео

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

Что уникального есть у нас:
1. Есть нереальный запрос на изменения, так как для нас это вопрос жизни/смерти. Мы точно выбираем жизнь
2. Наши agile-коучи не «космонавты» - нужно будет работать с 3-4 командами и приносить ценность в конкретных продуктах. Я ожидаю, что в команды будет инвестироваться 70+% времени Agile-коуча
3. Практически полное отсутствие «корпоративных налогов». Минимальная отчетность по работе в формате «поговорим про метрики», а не «проставьте галочки в эксельке»
4. На текущий момент очень много подряда (раньше было еще больше), который, правда, должен снизиться за счет инхауз-разработки. Необычный сеттинг со своими плюсами и минусами
5. Мы по-настоящему рыночная компания (наши акции торгуются на московской бирже), поэтому мы не заливаем проблемы деньгами — надо включать голову
6. У нас сверх амбициозные цели (чтобы убедиться, что это не просто слова из презентации, можно посмотреть выступление наших ТОПов на Strategy Day или диалог с ВТБ)
7. У многих надо работать в формате «тут уже много чего сделано, надо поддерживать». У нас работа в формате «почти ничего нет» — Green Field). Свобода творчества

Конечно, у нас есть то же, что и у других, например
1. Поддержка от СЕО и Board
2. Нет привязки к фреймворку. Выбор подхода под контекст продукта, а не наоборот
3. Команд много, они разные (как по задачам и контексту, так и по maturity) — скучно не будет
4. Оценка работы agile-коуча — это вопрос эффективности команд. Agile-коуч — часть команды, часть корабля
5. Мы строим agile-комьюнити, в котором ты сможешь развиваться сам и развивать других

Нам будет о чем пообщаться, если:
1. Ты работал как минимум с 2 командами 1-2 года в большой или средней организации (стартаперам будет чуть сложнее)
2. У тебя есть конкретные и измеримые кейсы роста эффективности команд
3. У тебя ИТ-background или как минимум опыт проектного менеджмента
4. Ты развиваешься по модели компетенций agile-коуча (Лисса-Адкинс-наша-все)
5. Есть сертификаты или красивая история, почему ты решил их не делать

Что мы хотим от agile-коуча:
1. Повышение эффективности команды:
1. Улучшение продуктовых метрик
2. Улучшение метрик производства (DORA)
3. Повышение зрелости команд
2. Обучение по agile, производству и продуктовке команды, продактов и менеджмент
3. Развитие в комьюнити, ведение и участвовать в гильдиях
4. Настройка knowledge sharing

Вишенка на торте:
1. Рыночная ЗП
2. ДМС
3. Техника (MacBook)
4. Скидки в сети МВидео и Эльдорадо

Интересно обсудить
Пиши мне в telegram @SergeArt Открыть/Комментировать

2021-07-24 10:00:07 Agile-коуч agile-коучу рознь
— у всех разный background.

Много ребят с оч развитыми софтами (soft skills), но в плане особенностей разработки не оч.

Если хочешь расти, можно упороться и вкачать в себя полноценный курс по разработке ПО (кусок про scrum лучше, наверное, пропустить)

Потом взять себе курсы по #python, например, раз и два или любой другой курс на #courcera. Питон лёгкий для осваивания (не java), основы программирования без необходимости глубокого погружения в синтаксис и адские конструкции.

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