Русский
Русский
English
Статистика
Реклама

Гибкие методологии

3 простых инструмента тайм-менеджмента для удалёнки и неудалёнки

25.06.2020 18:18:39 | Автор: admin

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


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



Сейчас основная сложность в том, что поток информации увеличился в несколько раз. Мы уже давно живём в цифровом мире. А в эпоху самоизоляции почти 100% людей заметили, что стали работать ещё больше.


Потоки информации стали еще объёмнее, количество информации стало еще больше, от компьютера мы не отходим примерно с утра до вечера, а вечером "пересаживаемся" на смартфон.


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


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


Инструмент 1. Есть такая очень известная матрица она называется Матрица Эйзенхауэра. Да, она у всех уже набила оскомину, как buzzword. Но, в целом, многие люди не знают, что можно достаточно быстро фильтровать входящую тебе информацию, как важную и срочную. И, соответственно, это матрица 2 на 2: срочные важные, срочные неважные, не срочные важные, не срочные не важные.


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


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


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


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


Если правильно работать над не срочными, но важными задачами, срочных и важных задач просто не появится.


В идеале такого, наверное, не бывает никогда.


Но, тем не менее, можно свести к нулю. Есть отдельный вид задач, который не срочные, но важные. Важные, но не срочные это те, которые можно и нужно делегировать. Это те задачи, которые нужно трактовать очень широко. То есть, делегировать не просто подчинённым дать. Допустим, чтобы убирать дома имеет смысл начать нанимать людей, которые убирают, а ты в это время продуктивно потратишь на какой-то свой продукт. Или не ходить в магазин, а заказать доставку. В современном мире возможностей для делегирования очень-очень много.


Инструмент 2. Он называется пустой Inbox. Это те задачи, которые важные, которые сыпятся тебе, которые нужно сделать здесь и сейчас. Есть такая рекомендация, Inbox это хранилище всей входящей к тебе информации. Его нужно держать пустым, свободным, проработанным. Это просто психологически приятно да и полезно иметь его пустым. Когда ты задачу, либо делаешь, либо планируешь на выполнение, получаешь такую галочку в голове, дофаминово-окситоциновую дозу, что ты сделал, молодец. Ты сделал это правильно, завершение принято, задача сделана, и мозг тебя за эту дофаминовую мотивационную конфетку и получает.
Эта конфетка та же, что за листанием в Фейсбуке, но здесь ты реально за дело получаешь и продвигаешься вперёд по своей жизни, а не бездумно пролистываешь километры чужих бесполезных тебе жизней. Поэтому, держать его, по возможности, надо пустым, руководствуясь третьим правилом.


Инструмент 3. Называется правилом 5 минут. То есть, на любую задачу, которая попадает в твой Inbox, у тебя есть 5 минут. Почему 5 минут? Потому что, как правило, ты какой-то задачей занимаешься, и ты можешь отвлечься от неё не больше, чем на 5 минут. Почему на 5 минут? Потому что за это время у тебя не успеет уйти контекст предыдущих задач, и ты успеешь к ним вернуться, не потеряв наработки.


В течение 5 минут что можно сделать? Если задача занимает меньше 5 минут, ты сразу её делаешь. Маленькую задачу за 5 минут нужно делать сразу и всегда. Потому что это заблуждение, что, если я сейчас ее не сделаю и отложу на потом, мол, как будто на балкон вынесу и у тебя вдруг придёт в выходные озарение убрать там всё, что у тебя накопилось на балконе, вы не уберёте там никогда. А, если бы, грубо говоря, какая-то картонная коробка осталась, выкинь пойди лучше сразу, не перекладывай на балкон, чтобы потом думать, что с ней делать. Она всё равно будет торчать в памяти, как лом в голове и дверные косяки будет задевать и бейсболка сидеть будет криво.


Второй момент, если задача за 5 минут не укладывается, такое реально бывает, что мы можем сделать? Мы можем запланировать её выполнение, примерно прикинуть, когда к ней можно прийти. То есть, таким образом все задачи, которые у тебя в Inbox поступают, ты их маркируешь, например, планируешь для выполнения, либо выполняешь. Таким образом, у тебя все задачи в твоем Inbox должны быть пустыми.


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


Советами по тайм-менджменту в эпоху пандемии поделился Алексей Куксёнок, соавтор и ведущий онлайн-курса Профессия SCRUM-мастер. Первый бесплатный семинар курса пройдёт 9 июля в 19-00. Алексей проработал 15 лет в ИТ-индустрии в различных ролях, 12 из которых в иностранных компаниях, как продуктовых, так и сервисных. За время карьеры побывал и на стороне исполнителя, и на стороне заказчика. Руководитель проектов в компании DataArt, входящей в Inc. 500 I 5000 (самые быстрорастущие компании США), в список 1000 компаний вдохновляющих Британию. Участвовал в трех десятках проектов с численностью сотрудников от 2 до 60 человек, реализованных, как и с использованием гибких методологий (Scrum, Kanban), так предиктивных (PMI-PmBoK). Спикер международных и российских конференций, организатор митапов, воркшопов, конференций и тренингов.

Подробнее..

Точка кристаллизации негатива в команде Как ее найти и что с ней делать?

01.07.2020 08:11:29 | Автор: admin

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


В чем тут основная сложность? Если быть точным, то сложностей тут две:
1) такая ситуация действительно может только казаться;
2) если не кажется, что с этим делать?


Давайте разбираться. Я лично сторонник нескольких подходов в решении таких задач.



Красота в глазах смотрящего


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


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


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


Конечно, такие метрики в отношении людей не дают 100-процентной гарантии, потому что людей сложно оцифровать, но это лучше, чем ничего.


Мы живем в матрице


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


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


И если это сочетание получается больше, чем, 1 к 3, то есть, на три положительных комментария приходится больше одного негативного, то вот здесь начинается проблема.


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


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


Это первая метрика, которую следует проверить, прежде, чем приступать к изменениям.


Отделяем зерна от плевел


Второй подход состоит в том, чтобы определить, а в чем же собственно проблема и есть ли она вообще? Даже, если вы заметили какое-то нарастание негатива в команде, и решили, что проблема действительно имеет место, то нет. Рано. Пока это не проблема, а факт.


Условно говоря, то, что солнце встает каждое утро это факт. Вода в море мокрая. Снег холодный. Грязь пачкает одежду. Это всё факты.


Для кого-то это проблемы, для кого-то нет. Если человек отпускает язвительные комментарии в адрес кого-то или чего-то вокруг происходящего, это факт. Вопрос, это проблема или нет? И если да, то в чём она состоит? Проблема для команды, проблема для производственного процесса или ещё для чего-то?


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


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


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


Поэтому прежде чем решить проблему, убедитесь, что проблема есть, потом уже решайте ее.


Чемоданчик лидера


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


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


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


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


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


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


Советами по работе с командой поделился Алексей Куксёнок, соавтор и ведущий онлайн-курса Профессия SCRUM-мастер. Первый бесплатный семинар курса пройдёт 9 июля в 19-00.


Руководитель проектов в компании DataArt, входящей в Inc. 500 I 5000 (самые быстрорастущие компании США), в список 1000 компаний вдохновляющих Британию. Участвовал в трех десятках проектов с численностью сотрудников от 2 до 60 человек, реализованных, как и с использованием гибких методологий (Scrum, Kanban), так предиктивных (PMI-PmBoK).

Подробнее..

Подводные камни межкультурных коммуникаций

08.07.2020 18:05:40 | Автор: admin

Бывало такое, что ваши коллеги, которых занесло в западные компании, то ли в командировку, то ли насовсем, или просто им приходится день ото дня взаимодействовать по проекту с иностранцами делились с вами думами тяжкими? И жаловались вам они на проблемы, с которыми тут в России вы ни разу не сталкивались. То не нравится мне наш иностранный заказчик, какой-то он нелюдимый, ни улыбнется, ни пошутит!, то Новый начальник из Европы робот какой-то! Не отпустил меня вчера с обеда домой! А мне в налоговую надо было!, то Позвал нового коллегу из Германии в ресторан, так сказать, проект обсудить, а он отказал! Сказал, что все вопросы надо решать на работе! Я к нему, как к человеку, а он вон как!


Коллеги со всей широтой русской души которая, как поётся, шириной от Волги до Енисея а иноземцы морду воротят и знаться как будто не хотят. И дальше уже не хочется наводить мосты ни пива вместе выпить, ни проект обсудить тет-а-тет, а не в строгой переговорной, да и сотрудничать особо активно тоже не хочется, мол, авось и так проект в продакшн выплывает.


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


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



Я не всегда работал в текущей компании и не всегда был руководителем проектов, когда-то я был младшим разработчиком, а еще раньше системным администратором и именно тогда меня забросило в мою первую иностранную компанию. Называлась она Siemens Business Services, где мне и открылись все прелести работы с иностранными коллегами, которые я продолжаю постигать по сегодняшний день, ведь из 15 лет в IT, примерно 10 прошла и проходит по сей день в тех самых иностранных компаниях.


Вспомним Киплинга: О, Запад есть Запад, Восток есть Восток, и с мест они не сойдут,
Пока не предстанет Небо с Землей на Страшный Господень суд
.


Запад это Северная Америка и Европа, кроме Средиземноморья. Восток русскоязычные страны (СНГ), в меньшей степени Китай, Япония и Азия в целом.


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


  • Эдвард Холл. Результаты он описал в книге Вне культуры или Beyond culture. В этой книге он плотно занимался так называемым контекстом коммуникации (широким и узким), а также проистекающими из этого явлениями, про которые мы сегодня как раз и поговорим.
  • Герт Хофстеде и его книга Последствия культуры или Cultures Consequences. В ней он разработал типологию культур, в частности степень индивидуализма и проистекающие отсюда эффекты при взаимодействии разных культур.
  • Ну и книга немецкого культуролога Александра Томаса Справочник по межкультурной коммуникации и сотрудничеству, где содержатся практические советы по межкультурной коммуникации в деловой среде, а также освещена теория культурных стандартов.

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



Внешние факторы контроля:


Делаем хорошо, только если он/она мне нравится.
Убежденность в деле (пропитка идеей)
Я скажу, если ты спросишь.
Преобладает контролирующая роль.


Внутренние факторы контроля:


Сам себе контроль.
Я скажу до того, как ты спросишь.
Контролирующая роль не основная или отсутствует совсем.


Что нужно делать, чтобы было эффективное взаимодействие с западными коллегами:


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


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


Кейс звучит так: Начальник вашей команды в отпуске, а люди продолжают работать дальше, почему?


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


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



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


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


Ядро культурные стандарты. Согласно немецкому психологу Александру Томасу, про которого я уже говорил, культурные стандарты это все виды восприятия, мышления, оценки и действия, которые большинство представителей определённой культуры считают нормальными и типичными лично для себя и для других. КС являются ментальным ориентиром и, не много не мало, управляют нашим поведением.


Как же эти различия в культурных стандартах проявляются еще?


Например в противопоставлении личностной доминанты деловой доминанте.


Как вы думаете, какой процент работающих в РФ указывает хороший коллектив и атмосферу в коллективе, как основной мотивирующий фактор для работы? 35% это 2-3 место в списке мотивирующих факторов по разным исследованиям. А знаете какое место этот фактор занимает в ментальной карте европейцев? Примерно 9-е из 10.


Личностная доминанта:


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


Деловая доминанта:


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


Что делать, чтобы западные коллеги тебя поняли:


Добавлять деловой контекст во все встречи, без личных и личностных оценок.
Готовить повестку и список лиц, принимающих участие во встрече.
Оставаться в рамках указанной темы.


Просто географической распределённости мало, чтобы объяснить появление таких различий между западным и восточным подходом, должно быть что-то еще.



И объединяло нас общие христианские корни. Но продержалось это единение недолго. Из школьного курса истории средних веков известно, что все началось с раскола христианской церкви в 1054 году, после которого окончательно произошло разделение Церкви на Римско-католическую церковь на Западе с центром в Риме и Православную на Востоке с центром в Константинополе. Разделение, вызванное расколом, не преодолено до настоящего времени, невзирая на то, что в 1965 году взаимные анафемы были обоюдно сняты Папой Павлом VI и Вселенским Патриархом Афинагором.


После этого каждая Церковь и подвластный ей мир пошли своей культурной и мировоззренческой дорогой. Привело это к тому, что в западной цивилизации сформировались следующие принципы и стандарты миропонимания:


Равноправие всех перед Богом.
Уважение к личности.
Индивид преобразователь мира.
Рационализм.
Важность индивидуального восприятия.


В восточной цивилизации это привело вот к чему:


Император (Царь) вседержитель.
Смирение.
Коллективизм.
Конформизм.
Импровизация и завуалированная коммуникация.


Теперь понятно откуда взялась личностная доминанта и внешний контроль в восточной культуре? Мы привыкли к коллективной жизни, в которой нет места индивидууму, а есть всегда некая внешняя сила (царь/император), который и регламентирует наше поведение. В то время как на западе основой жизни был индивид, рационализм и равноправие. В таком контексте нет места внешнему контролю и личным симпатиям в деловой среде.


Но это еще не все. Проявлений культурных стандартов на самом деле много. Вот еще пример.


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


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


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


И знаете, что они сказали в конце моей тирады? Алексей, спасибо, с 1 февраля вы приступаете к работе на этой позиции.


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


Есть такое проявление восточного и западного культурного стандарта как широкий контекст против узкого. Что имеется в виду:


Широкий контекст:


Эксплицитная коммуникация 30%.
Имплицитная 70% (мимика, жесты, интонация, контакт глаз). Детали не проговариваются.
Не говорят нет, но делают нет.


Узкий контекст:


Чувства партнера не считываются. Детали уточняются.
Важно что будет сделано, а не как это будет сделано.


Что нужно делать, чтобы не влететь по самую макушку в такую ситуацию:


Явно коммуницировать статус и результаты, без двойных трактовок.
Явно говорить нет с аргументацией.
Коммуницировать факты, а не чувства.


Мы рассмотрели не все возможные проявления культурных стандартов. На мой взгляд следует посмотреть еще вот про эти вещи. Про первый пункт хорошо рассказано в уже упомянутой книге Холла Вне культуры, а второй пункт хорошо раскрыт в исследовании Хофстеде и его книге Последствия культуры, ну а про третий хорошо рассказано в справочнике Александра Томаса, правда на немецком.



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


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


Автор наблюдений Алексей Куксенок, соавтор и ведущий курса Профессия SCRUM-мастер. Первый бесплатный семинар курса пройдёт уже завтра, 9 июля в 19-00.


Руководитель проектов в компании DataArt, входящей в Inc. 500 I 5000 (самые быстрорастущие компании США), в список 1000 компаний вдохновляющих Британию. Участвовал в трех десятках проектов с численностью сотрудников от 2 до 60 человек, реализованных, как и с использованием гибких методологий (Scrum, Kanban), так предиктивных (PMI-PmBoK).

Подробнее..

Однодневный спринт реальность или вымысел?

10.09.2020 10:11:09 | Автор: admin

Зная, как я люблю экспериментировать, иногда на конференциях меня коллеги спрашивают: "Ну, какой у тебя теперь минимальный спринт?"


Я и сам сейчас задумался с этой самоизоляцией и работой на дому да на даче, какой у меня реальной длительности спринт.


И с удивлением понял: один день.



Думаете, такого не бывает, что это из разряда жар-птицы, единорога и серебряной пули. А я вам покажу, как бывает.


Честно, то, что я однодневными спринтами иду, я спринтами их не называю, но планирую свой завтрашний день, свой завтрашний спринт. Современный мир настолько быстро меняется, что неделя это такая вещь, которая устаревает очень быстро. Хорошо получается запланировать только один день, а остальные дни нужно постоянно накануне перепланировать, что-то вносить новое в спринт. Поэтому однодневные спринты в современном мире мне кажется, будут оптимальными.


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


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


Потому что один человек мало, что может достичь. Ему всегда нужен кто-то, кто с ним будет проходить этот путь. Хотите, называйте это адептами, последователями, командой, неважно, в какой конфигурации. То есть, это не процесс эксплуатации одного человека другим. Это процесс открытого взаимодействия, открытого создания группы людей, формирования каких-то целей, открытости и прозрачности для достижения этих целей, то есть. Когда все члены команды понимают, что они достигают эту цель, то это, по сути, опять тот же Scrum. На таких принципах он и строится.


Мы провели курс для Scrum-мастеров Профессия SCRUM-мастер. И уже можем поделиться результатами с него и наблюдениями.


N.B. редактора: Это не рекламная и не продающая статья. Курс уже прошёл. В этой статье никто и ничего не предлагает купить, подписаться, зарегистрироваться. Просто обдумать то, что получилось, какие инсайты пришли за время процесса.

Сейчас эксперты разной степени надутости щёк пророчат долгую экономическую рецессию и рост безработицы в мире после пандемии. И естественно, что у IT-специалистов, как опытных, так и начинающих и студентов, возникает вопрос, какие качества и навыки нужно в себе развивать, чтобы оказаться среди тех, кто будет демонстрировать финансовый и карьерный рост?


И это хороший вопрос. Как раз в рамках прошедшего курса. Давайте попробуем сформулировать.


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


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


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


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


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


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


Но есть и опасность переусердствовать. Многие сейчас ринулись в Аgile, как будто пандемия их подтолкнула и не только начали трансформацию снизу-вверх, или там слева-направо, а совсем не сверху-вниз, как и должно быть. Не изменятся топы, дела не будет. Будет чистый карго-культ.


Если вы прочитаете книжку про Билла Гейтса и узнаете, что он встает в 6:00 утра и вы почему-то решили, что он поэтому миллиардер. Если встать в 6:00 утра, то вы миллиардером не станете примерно никогда. То, это как раз такое классическое применение карго-культа. А Scrum или Agile, поскольку он имеет большое количество церемоний, хорошо прописанных в Scrum-гайд там очень легко описанные методологии и задачи пробовать скопировать. И получить из всего этого реальный Agile карго-культ очень легко. Скорее он с большей вероятностью у вас получится, чем реально действующий Agile. Попытаться тупо и без огонька, без трансформации "сверху-вниз", от топов к линейным сотрудникам, просто как написано в Scrum Guide, в надежде, что у вас случился Scrum, попросту бесполезно.


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


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


Когда в сознании в правильном направлении построены все ценности, все эти практики и мероприятия появятся естественным путем. Потому что, примерно так они и появились в своё время. Потому что люди поменяли свое сознание, сделали клиента центром своей Вселенной, а не наоборот и всё начало крутиться вокруг него, и начали появляться те мероприятия, процессы, которые способствовали появлению Agile и Scrum. Это как раз к извечному вопросу: Что появилось первым курица или яйцо. Само клиентоцентричное отношение или Agile.


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


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


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


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


Секретом Полишинеля по спринту длиной в 1 день поделился Алексей Куксёнок, Руководитель проектов в компании DataArt, входящей в Inc. 500 I 5000 (самые быстрорастущие компании США), в список 1000 компаний вдохновляющих Британию. Участвовал в нескольких десятках проектов с численностью сотрудников от 2 до 60 человек, реализованных, как и с использованием гибких методологий (Scrum, Kanban), так предиктивных (PMI-PmBoK).

Подробнее..

Колесо баланса. Как Scrum помогает самому scrum-мастеру

11.07.2020 18:08:48 | Автор: admin

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


На этот раз я решил стать участником самого курса Профессия Scrum-мастер. По ряду причин. Мне всегда нравились непрямые подходы мотивации людей. Не банальные кнут и пряник, которые всем уже знакомы по корпоративным иерархическим культурам. Не триада стыд, страх, грех, которую применяют древние авраамические религии. А нечто новое. То, что и должно появиться в 21 веке пора уже, не правда ли?


Лично моё субъективное мнение это только лишь зачатки того, что будет. Другое отношение к сотрудникам, другое построение компаний может, появление микро-компаний вместо огромных гигантов корпораций, может, изменения направления трансформации сверху-вниз от топов к линейным сотрудникам, может изменения самосознания самих сотрудников, которые будут сами стремиться к такому подходу в компаниях на рынке труда и тем самым формировать сам рынок. Time will tell. Sooner or later time will tell.


Эта статья не реклама. Честно, не люблю рекламные статьи. Это статья наблюдение и размышление о том, что уже зародилось и продолжает меняться. Лично я считаю, что и Agile и Scrum это всего лишь первые шаги на пути изменений обычных процессов. И да, пока что они во многих курсах на образовательном рынке слишком близки к инфобизу, инфоцыганам и прочим тониробинсам. Но тут проблема не в самих гибких методологиях, а в людях. Наносное уйдёт, ценное останется.



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


Спикеры курса:


Заголовок спойлера



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


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


Именно потому уже не кажутся лишними в командах и компаниях психологи или психотерапевты, арбитры и евангелисты. Scrum-мастера. Я вижу, что сама профессия только формируется обрастает инструментами, возможностями, полномочиями, новым практическим опытом.


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


Заголовок спойлера



Честно, лично мне не сильно интересны определения, которые я могу прочитать в Википедии, в Agile-манифесте и Scrum-гайде. Думаю, любому более-менее любознательному IT-специалисту они давно известны.


Заголовок спойлера



Важен внутренний смысл, внутреннее наполнение, которые обеспечивает только практика. Наш мозг довольно мощный инструмент. Он спокойно может запомнить те несколько десятков или сотен строк, из которых состоит эта теория. Как в примере:


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


Прочитать возможно, понять тоже. А вот применить для этого нужна практика, практика и ещё раз практика. Рефлексы нарабатываются не только, когда ты размахиваешь косой, ломом или лопатой. Но и когда учишь людей, помогаешь им, воодушевляешь, поддерживаешь, формируешь у них образ будущего. Не просто так более всего ценятся психиатры после 40-45 лет, даже если они завершили обучение только в эти самые 40 лет. Одна теория без жизненного опыта мало что стоит, чтобы помогать людям.


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


Практика на курсе состояла в том, что в виде мини-спринта размером в 20 минут, случайным образом собранные в различных комнатах Zoom, команды должны найти общий язык и дать коллективно наиболее важные критерии для каждой роли Scrum-мастера.


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


Практика:


Заголовок спойлера






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


И ещё одна ценность вебинара. Колесо баланса. Которое можно применять, как на работе, так и в личной жизни.



Попробуйте составить его сами. Сразу скажу уже это нетривиальная задача. Что у вас в приоритете? Что вам нужно подтянуть, чтобы стать цельным, счастливым и успешным? Если вы затронете одну область, то как изменяться остальные, так как они связаны между собой. Порой подтягивая вверх здоровье, улучшаться и семья, и отношения. А подтянув духовный рост, о чём многие забывают в бешеном ритме современной жизни, могут измениться и отношения, и отдых, и работа. А порой даже и профессия.


Теперь на выходных я изучаю своё колесо баланса и думаю, что я могу изменить. Потому что меняться никогда не поздно.


Наш курс Профессия scrum-мастера и создан для тех, кто стремится к изменениям и чувствует, что созрел для них.


Не в теории. А на практике.

Подробнее..

Хочешь заработать миллион?

30.07.2020 20:10:43 | Автор: admin

Всем известна фраза Рона Хаббарда хочешь заработать миллион создай свою религию, которую он выдал в 1950 году. Тогда он создал ещё одну деструктивную секту, можно это было в 60-х в США которая до сих пор пытается утвердиться в мире, как религия.


Хотя, сорри, друзья.


Во-первых, это было сказано, а точнее написано в 1938 году.


В-вторых, это сделал неподражаемый Джордж Оруэлл, который так мастерски написал антиутопию "1984", что только сейчас до его благодарных читателей в Великобритании и США стало доходить, что писал он о них. Да и вообще Джордж был знатным шутником, учитывая, где он работал и что он знал о широких народных массах.


В-третьих, впервые это фраза появилась в его письме в виде строчки there might be a lot of cash in starting a religion: я бы перевёл, "как можно можно поднять славно деньжат, если застартапить религию".


Долгое время этой простым и немудрённым рецептом пользовались только сайентологи. Но потом к ним подтянулись башковитые ребята из IT c IQ у них всех было всё OK, а деньги и уважение лишними не бывают.


Будем считать это исключительно моей личной субъективной гипотезой, но именно так появились Agile, а затем Scrum. Давным-давно в XIV веке Уильям Оккам сформулировал одну чудесную фразу в одной из книг: Non sunt entia multiplicanda praeter necessitatem. Вот и удивляюсь, как жила разработка до появления Scrum. Наверное, её просто не было. На самом деле "клиентоориентированность" это финальный этап чудесной эпохи потребления, которая как раз заканчивается вертись вокруг клиента, как Солнце вокруг плоской Земли, и всё будет путём.



Одним прекрасным вечером в Массачусетсе Кен Швайбер и Джефф Сазерленд, как истинные патриоты Америки, добивали по третьему бокалу "Long Texas Ice Tea" и размышляли о том, что Agile, который они сочинили это хорошо. Но надо бы подогреть аудиторию. Добавить "птичьего языка", "новояза", "каргокульта". Под это дело запилить пару зубодробительных книжек и с пару десятков славных конференций главное, чтобы на фуршете было весело и продукты свежие. И нормальные продукты, американские. Не какая-то там Япония, Китай, Корея. С тех пор, как Джефф Сазерленд совершил более 100 боевых вылетов во Вьетнаме, он как-то Азии не доверял.



Особенно два друга угорали, когда узнали, что один из лучших полководцев армии США генерал Стэнли Маккристал объявил, что после того, как иракцы во время городских боёв создали у американских солдат выраженую трясучку, медвежью болезнь, нервый тик и ПТСР, что всю армию США надо переводить на Agile.


Кен Швайбер и Джефф Сазерленд, как истинные разработчики-пацифисты, перечитывали Agile-манифест, представляли, как генерал его применит после двух десятков контузий и периодических ярких выступлений на конференциях вроде "Как можно создать команду из семи тысяч пловцов-друзей?". ЛГБТ общество тогда аплодировало стоя. Военные ничего не поняли.


На самом деле, генералу стоило было бы спросить у самых северных варваров, как вести городские бои, что бронетехнику заводить в города нужно с такой поддержкой пехоты, чтобы она с брони осыпалась вместо активной защиты. Но вместо этого ему в руки попался Agile-манифест. Министерство Обороны США одобрило дёшево, трендово и экономит бюджет.


Кен Швайбер и Джефф Сазерленд со скусом, прихлёбывая коктейль с плавающими льдинками, наизусть повторяли ценности Agile.


1. Люди и взаимодействие важнее процессов и инструментов: плачущий солдат должен быть обеспечен офицером-психиатром, а не нормальным оружием, которое не клинит от пыли и песка после каждой перезарядки. И да, 12 летние пацаны тоже умеют бросать гранаты и даже стрелять из "шайтан"-труб могли бы спросить у самых северных варваров, которые прошли Афганистан.


2. Работающий продукт важнее исчерпывающей документации: Неважно, что ствол после 500 выстрелов начинает плеваться во все стороны солдат не обязан читать инструкции, да он вообще не обязан уметь читать. Гарвард и Йель не резиновые. И все эти хитрые шлемы, показывающие расположение союзников на поле боя прямо на тактическом дисплее пусть дети в PlayStation 5 в такое играются. Всё равно в инструкции никто не разберётся, даже разработчики потому что половину засекретили и отправили в Ирак с чёрными полосами вместо текста.


3. Сотрудничество с клиентом важнее согласования условий контракта: Вот тут прямо в точку. На Востоке никто и никогда ещё со времён пророка Мухаммада, да славятся его деяния, никогда не выполняли свои обещания особенно англичанам и американцам. Традиция. Так что "сотруничества" у американской армии в Ираке хоть ass ешь не зря Трамп всё никак не может придумать, как без репутационных потерь "победоносно" вытащить крепко засевшую по каску в Ираке армию обратно домой.


4. Готовность к изменениям важнее следования первоначальному плану: Особенно когда план меняется каждый день. Потому что по какой-то странной причине иракцы не следуют американскому плану. ВВС США даже листовки разбрасывали: "Русски Иван сдафайса". И даже в самой разработке каждый день менять цель продукта, его назначение и функционал это весело и круто. Главное, чтобы у инвесторов деньги не заканчивались.


Так как Джефф Сазерленд переобщался с со старыми русскими друзьями, он доверительно сказал Кену Швайберу: "Грузите апельсины бочками. Братья Карамазовы". Тот утвердительно кивнул. Джефф поднял вверх руку и сказал: "А теперь мы сделаем Scrum". "И немедленно выпил..."(с)


Было это в ноябре 2017 года. Многочисленные коучи, блогеры, тренеры, сенсеи, гуру, отцы народа, исправители кармы и родового проклятия подхватили новую тему прославленных бизнес-гуру. Как мантру все повторяли "Скрам это фреймворк Agile". Звучало это настолько мощно, что корпоративные клиенты закатывали глаза и сами отдавали деньги на различные, крайне необходимые agile-трансформации. Всё равно денег был переизбыток.


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


Как нетрудно догадаться, никто и никогда до Scrum всего этого никогда не далал. И даже колесо было квадратным, а код был пятиричным.


Так как в мире с непрерывано работающим долларовым станков ФРС возникло много умных, красивых и читающих людей, то Scrum начали применять повсеместно для разработки программного обеспечения, стоматологии, геологических исследований, разработки оборудования, встроенного программного обеспечения, автономных транспортных средств, микробиологических исследований, воспитания детей, медицины, экстренных операций, космических програм. Scrum использовался в школах, правительстве, маркетинге, в наркокартелях, в управлении благотворительными организациями так как был переизбыток людей, который ничего больше не умели, кроме как рассказывать увлечённо о Scrum. Ну и всячески веселить двух старых мудрых дедов Кена Швайбера и Джеффа Сазерленда.


Scrum даже пытались внедрить на новой ракете для полёте на Марс. Не пошло. Взорвалась. Зато хорошо Scrum зашёл на кимберлитовых месторождениях в Африке scrum-мастера с автоматами обеспечивали "блеймлесс"-культуру среди работников, плоскую структуру и высокую инициативу. А product owner иногда заезжал на хаммере в высоких кожаных сапогах, белых бриджах и пробковом шлеме.


Суть Скрама это маленькая команда людей. Каждая отдельная команда чрезвычайно гибка и адаптивна. А ещё небольшие группы людей проще контролировать. В "бирюзовой" организации, как известно, "нет ни текучки, ни увольнений". Просто кто-то не вписался в Agile-команду. В таких случаях голосует вся команда, так как каждый имеет право голоса. Естественно, что проголосуют все против "слабого звена", потому что никто не хочет быть "вторых слабым звеном". А руководитель всегда может включить "красный уровень", потому что зарплата у него.


Это как "бирюзовый" анекдот о Советском Союзе: "У нас на партсобрании каждый чуточку "против", но все вместе категорически и пламенно "За"".


В scrume обязана быть "прозрачность" абсолютное доверие всех всем, особенно scrum-мастеру. В некотором роде scrum-мастер выступает в роли психотерапевта и исповедника. Все друг другу верят во всём. К слову, Пол Экман американский психолог, профессор Калифорнийского университета в Сан-Франциско, специалист в области психологии эмоций, межличностного общения, психологии и распознавания лжи в ряде экспериментов доказал, что среднестатистический человек в течение дня лжёт в среднем 27 раз.


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


Скрам предполагает четыре формальных события для инспекции и адаптации:


Планирование Спринта когда владелец "бирюзовой" компании просто и "по-красному" объясняет, что ему нужно.
Ежедневный Скрам он же daily, где все лихорадочно думают, какими бы задачами заполнить весь свой день, чтобы показать свою значимость на demo, а не только приблизиться к результату.
Обзор Спринта demo спринта, когда каждый пытается доказать, что выражение "no honey no money" никак не относится к нему.
Ретроспектива Спринта самая приятная часть. Когда каждый говорит правду о сотрудниках и процессах в течение спринта. Выше я упоминал об исследованиях Пола Экмана.


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


Scrum-мастер это лидер-слуга для Scrum-команды. Людям вне команды он помогает понять, что из их взаимодействий со Scrum-командой полезно, а что нет. В руководстве не указано, что он делает с теми, чьё взаимодействие не полезно для Scrum-команды.


Каждый день, утром, все должны видеть любимые лица команды, и приходить секунда в секунду хоть лично, хоть в Zoom, чем проявят уважение и почитание product owner. К сожалению Джефф Сазерленд не смотрел советский фильм "Кин-Дза-Дза", иначе он бы добавил цветовую дифференциацию штанов и обязательный колокольчик в носу.


Верите ли вы в Agile и Scrum, как верю в него я?

Подробнее..

Как мы разрабатывали корпоративное iOS-приложение по Agile, и почему он нас не спас от рисков

19.12.2020 14:20:36 | Автор: admin

Дано:

  1. Корпоративное iOS-приложение, реализованное только под форм-фактор Apple iPad с устаревшим дизайном (особенно, если изучать гайдлайны Apple).

  2. Заказчик = крупное российское полукоммерческое предприятие. Со стороны Заказчика участвуют 4 департамента (с одинаковым влиянием друг на друга), один из департаментов является функциональным заказчиком (ФЗ) и владельцем бюджета. Остальные отвечают за безопасность и ИТ-сопровождение.

  3. Распределенная на 2 города команда со стороны Исполнителя, проблемы с коммуникациями отсутствуют.

Найти:

  1. OS-приложение под iPhone с современным интерфейсом и доп. функционалом

Ограничения:

  1. Заказчик на момент проекта никогда ранее не работал по Agile-методологиям, но их руководство на основе последних трендов повсеместно пыталось запустить использование Agile;

  2. Договорные отношения между Заказчиком и нами были FixedPrice (оформить T&M было невозможно).

Решение:

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

Разработка продукта происходила, как и положено, итерациями. Каждая итерация составляла 2 недели: формирование скоупа -> разработка -> тестирование -> демонстрации -> фиксирование замечаний -> формирование скоупа ->

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

Что было неизменно (для отношений Заказчик-Исполнитель):

  1. Постоянное давление статусом Заказчика и уровнем важности его конечных целевых пользователей.

  2. Растущие аппетиты Заказчика и жонглирование требований между 4 заинтересованными департаментами. Например, в ходе разработки продукта появилось требование использования библиотек корпоративной MDM-системы для сохранения конфиденциальности данных внутри приложения. Как итог: из-за внутренних противоречий Заказчика было разработано 2 сборки (с поддержкой MDM и без), первый год после внедрения в пром 99% пользователей использовали принципиально версию без MDM-системы все из-за тех же внутренних противоречий между департаментами.

Немного графиков со статистикой растущих аппетитов (цифры про трудоемкости и длительности опущены на графиках из-за NDA компании с Заказчиком):

Почему Agile не помог

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

НО

Как писала выше, после использования лучших практик успешно прошли приемо-сдаточные испытание, начали тиражировать приложение в промышленную эксплуатацию. Во время тиража приложение получил руководитель департамента ФЗ, начал использовать, а мы радостно и весело стали переписывать половину интерфейса приложения, так как гайдлайны Apple ничего не понимают о дизайне корпоративных приложений, и нужно было срочно сделать устаревшие формы экранов из iPad на iPhone.

Выводы или зачем нужна эта статья

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

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

Собственно, возникшую проблему после опытной эксплуатации продукта решали другими методологиями, где подробно рассматривается управления рисками. И как учит туториал Хабра: Неуспешные кейсы тоже полезны, они помогут кому-то не наступать на грабли, на которые другие уже наступали. Не скажу, что мой кейс неуспешен, сотрудники Заказчика пользуются продуктом уже несколько лет, в рамках проекта были достигнуты почти все поставленные цели. Но мой кейс один из примеров, когда нельзя забывать о стратегиях управления рисками в угоду пропаганде повсеместного использования Agile.

Подробнее..

Синхронизация продуктовых команд в Sportmaster Lab (часть 2)

04.02.2021 16:05:13 | Автор: admin

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

Метрики

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

Наша самая главная метрика Lead Time: это характерное время, за которое задача доходит от одной из четырех контрольных точек (появление идеи, ТПР, Х и ТПО) до установки на продуктив.

..

Как видим, они образуют иерархию вложенности. Мы используем величины Lead Time, выраженные в рабочих, а не календарных днях. Если над одним продуктом работает больше одной команды, то TTM, Customer Lead Time и Х Lead Time относятся к продукту в целом, а Lead Time для потока у каждой команды может быть свой.

Устоявшейся терминологии для разных Lead Time пока нет, поэтому аналогичные по смыслу показатели у других авторов можно встретить под другими названиями, например, для потокового Lead Time (тот, который самый короткий) часто используется термин Cycle Time. Здесь буду придерживаться нашего варианта жаргона, извините, если что.

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

Потоковая диаграммаПотоковая диаграмма

Еще эту диаграмму называют Бассейн, так как она построена по принципу втекает-вытекает-оставшийся уровень. Inflow поток задач, которые взяты в поток за неделю, Done количество успешно выполненных задач, Discarded количество отбракованных из потока задач, Unfinished количество задач, оставшихся в потоке на конец недели (другое название - WiP Work in Progress).

Прогнозирование с использованием показателей Lead Time разных уровней

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

Если заглядывать сюда регулярно, то сможем отследить и их перемещение между областями.

Визуализация эпиков и задач продуктовой команды на карте жизненного циклаВизуализация эпиков и задач продуктовой команды на карте жизненного цикла

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

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

Чтобы понять, сколько времени обычно нужно, чтобы провести задачу через поток, рассмотрим спектральную диаграмму Lead Time для потока этой команды за последние три месяца:

Спектральная диаграмма LeadTimeСпектральная диаграмма LeadTime

Для удобства рассчитываются и дополнительно выводятся на графике значения 50-го и 85-го перцентилей это количество рабочих дней, которое у команды занимает решение одной задачи для 50% и 85% всех задач соответственно. В данном случае это 2 и 4 дня. Значит, только для 15% задач Lead Time составляет больше 4-х рабочих дней. Вспомнив про типизацию задач, посмотрим на спектральные диаграммы разных типов задач по отдельности (слева направо - Дефект, Эксплуатация, Технические и Бизнес), и увидим, что для бизнес-задач 85 перцентиль составляет не четыре, а шесть рабочих дней:

Спектральная диаграммы для отдельных типов задачСпектральная диаграммы для отдельных типов задач

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

Теперь посмотрим, как можно мониторить движение эпика на всем жизненном цикле, от идеи до реализации при помощи статистики Lead Time разных уровней:

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

Рассмотрим одну из таких задач. Плановую дату ее исполнения обозначим как день Д. Построим LeadTime-профиль продукта/команды, которая будет ее выполнять, в виде таблицы:

Пример LeadTime-профиляПример LeadTime-профиля

Дни рабочие, неделя соответствует 5 рабочим дням. 85% вероятность выполнения РП считает приемлемой.

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

  1. РП приходит с новой задачей к Product Owner (PO) и договаривается о помещении ее в продуктовый бэклог с таким приоритетом, чтобы она, по предварительной экспертной оценке PO, была выполнена до дня Д. PO создает соответствующий эпик. РП ставит себе календарное напоминание на Д - 8 недель - это зеленая дата попадания эпика в следующую область Решили делать, и уходит заниматься другими делами.

  2. При срабатывании напоминалки РП проверяет, что его эпик пересек ТПР. В этом случае он ничего не предпринимает и ставит себе следующую напоминалку на Д - 14 дней (дата перемещения в Готово к взятию в поток в зеленой зоне).

  3. После очередной напоминалки РП видит, что эпик по-прежнему лежит в области Решили делать, не пересек точку Х и не декомпозирован на задачи. В этом случае он включает режим экспедирования: идет к Product Ownerу и договаривается о том, чтобы эпику подняли приоритет. Затем он ежедневно отслеживает ситуацию, пока эпик не оказывается в области Готово к взятию, декомпозированный на задачи. Предположим, что это случилось в дату Д - 8 дней.

  4. Далее имеет смысл отслеживать задачи, входящие в эпик, по отдельности. Предположим, что их три, в области Готово к взятию они расположены на втором, пятом и шестом месте по приоритетам (см. рисунок ниже). Мы уже знаем, что если задача находится на самом верху области Готово к взятию, то с вероятностью 85% она будет выполнена не позже, чем через 6 дней. Остается понять, сколько нужно времени, чтобы все три задачи эпика попали в поток. Посмотрев на потоковую диаграмму, мы увидим, что команда берет в поток в среднем 15 задач в неделю, то есть примерно по три задачи в рабочий день. Шесть задач будут взяты в работу, скорее всего, не позднее, чем за два дня. Поскольку день Д близко, РП стоит проследить, чтобы в бэклог поверх его задач не были помещены дополнительные задачи. Не стоит забывать, что команда принимает обязательства выполнить задачу только в момент ее взятия в поток, а до этого возможны изменения приоритетов.

Когда задачи 2, 5 и 6 попадут в поток?Когда задачи 2, 5 и 6 попадут в поток?

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

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

Важно: при движении эпика по жизненному циклу все виды Lead Time нужно измерять для той части эпика, которая дошла до продуктива.

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

Нужно ли автоматизировать прогнозирование сроков исполнения задач?

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

Можно ли спрогнозировать движение конкретной задачи от идеи к реализации, с учетом количества и характеристик задач, которые находятся выше нее по приоритетам и/или правее по ЖЦ? Получится ли в результате более точный прогноз, нежели мы можем получить из LeadTime-профиля продукта? Ведь пробабилистический прогноз с помощью LeadTime-профиля учитывает только в какой области находится задача , но не учитывает, сколько и каких задач команде предстоит сделать, прежде чем она приступит к интересующей нас задаче. Примерно как РП из предыдущей главы оценивал время, когда задачи 2, 5 и 6 будут взяты в поток, только автоматически, с учетом характеристик задач, подробных исторических данных.

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

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

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

"Самосбывающийся прогноз"

Автоматизированное прогнозирование обычно применяют для тех событий, на которые потребитель прогноза повлиять не может погода, покупательский спрос, движение автобуса в пробках, etc А на движение продуктовых задач потребители прогноза (команда и заказчики) имеют большое влияние. Если прогноз не устраивает заказчика и/или команду, то есть как минимум три инструмента для исправления ситуации:

  1. Договориться об изменении приоритета задачи.

  2. Сократить скоуп и требования, реализовать сначала ту часть, которая дает наибольший эффект при меньших затратах.

  3. Реализовать сначала менее трудоемкое, временное решение с образованием.

Достижение необходимого срока возможно без штурмовщины, если:

  1. Изначальные сроки реалистичны - находятся в зеленой зоне LeadTime-профиля команды.

  2. Задача действительно нужна, кто-то ждет ее выполнения и прилагает периодические усилия для поддержания ее приоритета.

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

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

Изменение зон ответственности при работе со сроками

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

В проектной парадигме базовый алгоритм работы со сроками следующий.

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

Когда я высказал эту мысль своим коллегам, мне тут же возразили, что так не бывает. Роль руководителя проекта придумана как раз из-за того, что эта "пуля" сама по себе в цель не попадает почти никогда. Ее надо постоянно подруливать в полете, и кто-то должен этим заниматься. Но изначальный смысл именно в этом - после согласования плана ответственность за срок переносится на исполнителя, чтобы освободить заказчика для более важных дел.

В продуктовой парадигме:

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

Таким образом в продуктовой парадигме ответственность за достижение сроков в большей степени ложится на сторону заказчика. Рабочая гипотеза состоит в том, что в обмен повышается общая эффективность приложения усилий заказчиком: выше вероятность получить то, что нужно, к нужному сроку, меньше неактуальных задач, сделанных потому, что их забыли отменить. Проверкой этой гипотезы мы сейчас и занимаемся в SM Lab :).

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

Для того чтобы работа команды была прогнозируемой, нужно чтобы у показателей Lead Time разброс (дисперсия распределения) был поменьше. Даже при небольшом разбросе не нужно забывать, что это вероятностный, а не детерминистический прогноз, отклонения всегда возможны, и ни одна команда не может быть на 100% предсказуемой. Но если распределение имеет большую дисперсию, то этот показатель полностью теряет предсказательную силу.

Вернемся к таблице LeadTime-профиля. По различию в 50-м и 85-м перцентилях легко понять, насколько силен разброс значений соответствующего Lead Time. Понятно, что по мере движения по жизненному циклу слева направо проработанность задач увеличивается, а степень неопределенности уменьшается. В нашем примере для Lead Time потока 85-й перцентиль больше 50-го в полтора раза (6 и 4 рабочих дня), а для Customer Lead Time - уже более чем в три раза (8 недель = 40 р.д. и 12 р.д.).

Для внешних интересантов интереснее всего предсказуемость задач как раз в левой части жизненного цикла, в областях идеи и решили делать. От этих прогнозов зависят решения, которые принимаются при формировании дорожных карт и бизнес-планов. Будет ли готова новая функциональность к началу новой коллекции, или надо сразу отложить ее внедрение на полгода, до следующей коллекции? На какой период планировать дополнительные ресурсы, связанные с этим? И множество других важных вопросов. В идеале, заказчик хочет знать, когда будет готово, сразу же, как только он высказал новую идею в наших терминах это значит, что дисперсия распределения Time to Market должна быть как можно меньше. К сожалению, обеспечить такую предсказуемость в области идей для команды очень сложно, так как эта область в наименьшей степени подвержена ее влиянию. Если каждую идею прорабатывать сразу до такой степени, чтобы по ней можно было дать обоснованный срок реализации, у команды не останется времени на полезную работу все уйдет на детальную проработку идей, которые никогда не будут реализованы.

Поэтому усилия по улучшению предсказуемости предлагается прилагать, начиная с области Решили делать, куда задачи (они же - эпики) переносятся через Точку Принятия Решения с участием представителей команды. Поэтому на разброс Customer Lead Time повлиять уже возможно, и для этого подходит то же средство, которые команды привыкли использовать для стабилизации работы своего потока - ограничение количества задач, находящихся в работе. На область Решили делать можно установить WiP-лимиты, так же, как это делается большинством продуктовых команд для этапов работы в потоке и для области Готово к взятию в поток.

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

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

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

Выводы

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

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

Для контроля сроков применяются методы визуализации и прогнозирования. Управление осуществляется через динамическое изменение скоупа и приоритетов.

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

Это все. Спасибо, что дочитали! :)

Подробнее..

Проводим ретроспективы для распределенных команд (и как Trello в этом помогает)

19.04.2021 10:09:21 | Автор: admin

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

Почему Trello

Я пользовался большим количеством инструментов, из которых можно выделить основные: Miro - как интерактивный флипчарт, с которым может взаимодействовать вся командa; Google Docs с секциями помапанными на стадии ретроспектив; Confluence (так как все мои проекты пронзены Atlassian-стеком); а также, порой, Jira (вау, это была достаточно плохая идея)!

Я думаю что все пытались нащупать тот самый инструмент, который можно применить фактически в любой области!

И вот я бы выделил основными критериями для проведения Ретро и собирания фидбека о Демо в подобных инструментах:

1. Насколько хорошо оно работает на уровне объектов (во время обсуждений). -> в идеале тут хотелось бы видеть карточки (все таки мы в физическом мире работаем со стикерами) :)

2. Быстрая и эффективная работа с карточками / объектами

3. Подсветка / теги для карточек / объектив (чтоб все могли), не важно как (цвет, тег, еще какая-то штука позволяющая дифференцировать карточки)

4. Перетасовка / изменение порядка карточек / объектов / айтемов

5. Как можно меньшее время, затраченное на следующую последовательность действий: создание секции (списка) -> добавление в него объектов / карточек -> тегирование / подсветка айтемов (членами команды) -> добавление комментария к айтему.

Miro

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

Google Docs

Гуглодоки это дефолтный инструмент для тысяч компаний во всем мире. При этом, как бы не нравилась простота самой платформы, она недостаточно наглядная, если мы хотим работать в ретро на уровне заметок-объектов, которые куда-то потом в идеале надо положить, декомпозировать на самостоятельные сущности, объединенные колонкой.

В этом плане, знаете, даже google sheets казалось бы удобно использовать, как инструмент более подходящий для нашей аналогии двухмерной-классической-ретро-доски (ну как двухмерной, скорее именно с точки зрения того, что у нас есть некие секции с контентом для хорошо/не оч/ улучшить). Но и тут нас поджидает неудобство - drag-n-drop для айтемов, и их линкование друг с другом работает ужасно. Я еще пробовал в свое время google slides, с подходом слайд-для-секции (например перечислить все те великие свершения, в которые мы шмогли с прошлого спринта) - но в итоге менеджить это было сложно, ввиду тяжеловесности решения, ну и на одном таком канвасе могло одновременно ну человека два работать может, не больше. Ну и подсвечивать айтемы там конечно можно, но оно для того не очень приспособлено.

Confluence

Ну вот же confluence, там же целый шаблон для ретро есть! Скажете вы. И будете правы!

Но хорош этот шаблон для документирования/стенографирования, для журнала принятия решений. А нам это в ретро не нужно! Нам нужна живая дискуссия где народ таскает карточки по колонкам, клонирует, обсуждает, помечает!

Более того, Atlassian обычно старается сделать confluence неким легковестным решением, если вас кормят всем их стеком. Но по простоте коллаборации там до gDocs как до луны. Возвращаясь к нашему подходу (ищем блочную структуру для карточек) - confluence неудобен. А еще - нестабилен: с потерей контента и его перезатиранием в режиме коллаборации, отвалом соединения и последующими невозможностями сохранить.

Trello

Ну вот а когда мы подходим к Trello - оно просто поддерживает карточки. И голосовалку для этих карточек с помощью power-up'ов (очень просто). Или через тегирование этого дела цветами (что работает просто и быстро).

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

Короче говоря: trello это самый простой в использовании аналог флипчарта со стикерами :)

Подготовка к самой ретроспективе, и ее начало

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

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

- Общего понимания того, что своё лицо шарить нужно. Поэтому ретро без включенных камер - это как ретро без включения в процесс

- Соединение должно быть отличное! Мы не хотим страдать из-за непонимания (особенно в мультиязычных командах :), и нам не нужны лаги

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

Сама Ретроспектива

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

Запланированные улучшения с прошлого спринта

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

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

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

Иногда эта стадия может затянуться (планировали улучшение - не смогли достичь - начинаем погружаться слишком сильно в детали почему). Как фасилитатор, ваша задача помочь команде найти продуктивный путь для выявления настоящей причины в достаточно короткий срок (у нас ведь есть таймбокс). Поэтому мы с вами планируем один обязательный пункт улучшения, два уже имеют риск затянуть начало ретроспективы. Также старайтесь просто запарковать это обсуждение на полее поздние части ретроспективы - если нужно действительно разобраться. А возможно это даже не относится к ретроспективе как к событию, а надо проводить RCA / Post-Mortem?

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

Цели спринта и метрики

Цели Спринта

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

Опять же, color-coding предельно простой - зелененький цвет говорит что цель достигнута, красный - нет. Можно добавить комментарий, чтоб дать контекст почему нет или да.

Метрики

Метрики спринта важны и как внутренний-SLA для команды, и как общий индикатор, который в комплексе помогает команде понять динамику.

Обычно команда навскидку придумает с десяток факторов, которые для неё препятствия чтоб быть более эффективной. Если поддерживать ведение такой дискуссии в правильном русле (читай, фасилитировать), и помогать команде наводящими вопросами (читай, коучить), ребята сами соорудят путь к улучшению и как его измерять. Главное чтобы был запрос на улучшение, и была понята сама проблема (нафига оно нам вообще). Еще нюансик: не рассматривайте метрики отдельно друг от друга, и стройте связи между опережающими индикаторами (гипотезами) и запаздывающими индикаторами (результатом). Например, действительно ли увеличение покрытия кода тестами увеличивает уверенность в том, что на проде качество улучшается?

Стандарные метрики, которые я стараюсь использовать:

- Lead Time (время от запроса клиента до поставки)

- Cycle Time (время от начала работы над задачей до поставки). Когда объяснишь на примере донесения ценности до пользователя - как устроен весь пайплайн и где затыки, ребята сами будут мотивированы следить за этими метриками (если, конечно, они у вас общаются с клиентами постоянно),

- Время в Code Review (атож, сколько задача висит и сколько ее проверяют),

- Количество раз тикет был переоткрыт (помогает вместе с определением Definition of Ready),

- Mean Time to Recovery (инцидент-метрика для понимания среднего времени на устранение),

- Bug Escape Rate (сколько багов мы не поймали на тестовых стендах, но поймали после релиза на прод).

В целом все зависит от ситуации, но я считаю Cycle Time и Lead Time тем самым минимумом для всех. Cycle Time в целом дает вам понимание прозрачности и предсказуемости.

Активность на выявление дельты улучшения ~ 'Хорошо-Плохо-Улучшения

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

Собираем фидбек с команды о том, как прошла ретроспектива

Ну а что, нужно же нам знать, насколько плохо мы справились! Я просто прошу оценить ретро по 10-бальной шкале, и назвать одно улучшение, чтобы увидеть дельту.

Референсы и полезности

У Бена Линдерса (Ben Linders) есть хорошая трелло-доска, в которой люди краудсорсят ретроспективные техники для распределенных команд в трелло.

  • https://www.benlinders.com/news/trello-board-retrospective-techniques/ Это, наверное, и разговоры с самим Беном, были огромным подспорьем, чтобы написать этот пост.


Подробнее..

Гибкое управление бизнес-процессами и роль информационных систем

20.02.2021 18:04:03 | Автор: admin

Приветствую, Хабр!

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

Проблемы традиционного взгляда на бизнес-процессы

Когда говорят про управление бизнес-процессами, то представляют консультантов, которые анализирует данные, оптимизируют организационную структуру компании и порядок тех или иных действий. Ещё на ум приходят инженеры, которые разрабатывают и внедряют различные системы контроля, анализа, оцифровки и автоматизации процессов. Ну и, конечно же, мы представляем операционных директоров, которые занимаются отладкой и управлением бизнес-процессов на местах.

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

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

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

И здесь встаёт вопрос: если среда неумолимо меняется и воздействует на нас, зачем выстраивать жесткую систему менеджмента и отливать в монолите бизнес-процессы? С точки зрения контроля над компанией и минимизации операционных рисков всё понятно. Но, на мой взгляд, избыточно структурированные системы имеют риск разрушения, как только столкнутся с непредсказуемостью.

Гибкое управление бизнес-процессами

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

Я представляю процессы НЕ как что-то искусственное, в стиле: "вот мы описали процессы и они начали существовать", а как органическое следствие роста организации, где с каждым шагом по рынку появляются всё новые проблемы и задачи, направленные на их решение. А на основе опыта решения проблем в компаниях появляются "Тропинки действий", которые мы и называем бизнес-процессами.

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

Есть такой термин как Adaptive Case Management. Его еще называют Agile BPM. Суть метода как раз описывает внедрение изменений в задачи на основе полученного опыта, где кейсы это ситуации, с которыми компания сталкивались в прошлом. Если проблема была решена успешно, то оставляем последовательность задач как было. Если проблема была решена плохо, то вносим коррективы и в следующий раз используем другой алгоритм.

Информационные системы и гибкое управление процессами

Когда нарастание сложности компании превращается в корпоративный хаос, менеджеры задумываются о внедрении инструментов, чтобы удержать контроль над системой. И здесь на помощь руководителям призваны различные информационные системы. Причём не важно, идет ли речь об ERP, BI, BPM, CRM, обычные таблицы любой класс этих продуктов для большинства менеджеров разновидность учёта и контроля качества бизнес-процессов. Где-то менеджеры контролируют движение денежных потоков. Где-то контролируют входящий клиентский поток. Где-то контролируют работ, которые выполняют сотрудники.

В гибком управлении процессами информационная система в большей степени не инструмент учёта управленца, а прежде всего инструмент для удобного взаимодействия сотрудников, где они могут сами организовать планирование и учёт в том виде, в котором это удобно для выполнения работы. Это когда-то давно поняли японцы, создавшие для координации и управления целыми заводами простые канбан доски. Сегодня это понимают разработчики таких инструментов как Trello, Airtable, Miro, Notion, Slack, Unicore и других сервисов...на первый взгляд, между этими системами мало чего общего. Но, по-моему, все они решают одну большую проблему предприятий отсутствие общего, удобного и адаптируемого информационного пространства для совместного решения задач бизнеса.

В случае с Трелло речь идёт об удобно настраиваемых горизонтальных списков задач. В случае с Эиртэйбл речь идёт о настраиваемых таблицах с дачами. Юникор про классические, гибко настраиваемые вертикальные списки задач. Миро позволяет планировать работу с помощью настраиваемого канваса, на котором могут отображаться задачи в виде стикеров. Ноушн совмещает базу знаний с местом для планирования списков задач. Слэк использует диалоговую систему управления задачами. Все эти продукты стараются быть не менеджмент-ориентированными, а пользователь-ориентированными.

Относительно недавно появился термин Work Management System то, о чём я пишу об этом. Софт становится человекоориентированным и гибким, чтобы с помощью него не менеджеры управляли процессами, а сами сотрудники.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru