Отбор проблем.
Подошли к самому сложному моменту.Итак перед вами доска/флипчат набитый проблемами (мнениями? домыслами?), маркер в руках, и коллектив людей которым (я надеюсь на это) не пофигу что будет дальше.
Про то, что написано в колонке хорошо (если это действительно хорошо) - говорить обычно не интересно - люди обычно сами хорошо анализируют свой успех, в отличии от неудач.
Естественно успех нужно отделять от удачи или обстоятельств :).
Традиционно, большую часть работы занимает колонка плохо.
Первое что с ней нужно сделать - это сфотографировать на телефон, или сделать ее бекап любым другим удобным (какой интересно удобнее ?) способом.
Почему ? Потому что дальше вы будете ее корежить, и бэкап нужно иметь всегда =).
Второе - не кидайтесь сразу что-то с ней делать, остановитесь, посмотрите на нее, прочитайте все пункты/стикеры еще раз, убедитесь, что все что там написано вам и всем остальным понятно.
Второе с плюсом (только для фасилитатора) - попробуйте проанализировать есть ли или могут ли быть связи между проблемами.
Если есть хоть малейшее подозрение что да - надо привлекать весь коллектив к анализу.
Даже если описанные проблемы кажутся независимыми - то лучше все равно задать вопрос всем.
Тут можно просто прямо послать вас читать замечательную статью Хенрика Книберга про Root-Cause Analysis, и я конечно это сделаю, но надо дополнить.
В любой команде есть определенная емкость терпения/сил/времени/бюджетов для решения любых проблем. И эти бюджеты очень плохо переносят дефициты.
С одной стороный эта емкость ограничивается заказчиком/владельцем продукта который вряд ли одобрит улучшайзинг на политерации, а с другой отсутствие поставки ценности для заказчика - это очень сильный демотиватор для команды.
Поэтому выявление корневой причины и анализ причинно-следственных связей - важен, потому что точное и точечное улучшение лучше чем генеральная уборка во всех углах.
Окей, для простоты картины представим, что взаимосвязей между проблемами у вас нет и они изолированы.
Третье - выбираем проблемы. Тут опять же есть место для социальных игр, про которые я писал ранее.
Я предпочитаю голосование точечками - каждый участник ретроспективы ставит точку (или магнитную точку, такие тоже есть в канцелярских магазинах) напротив той проблемы, которую считаает самой важной для решения.
У каждого члена команды есть право поставить три точки. Почему три ? Опять же правило по-умолчанию.
Если ваша команда настолько крута в области улучшений своего собственного процесса - то можете взять хоть 7.
Только аккуратно - предпочтительно внедрять улучшения по-одному, чтобы понимать какое улучшение какой эффект дает. Если у вас три улучшения в разных областях или даже два из них пересекаются, то отделить эффект одного от другого довольно просто. Если у вас их 7 - то уже сложно.
Второй аспект который касается количества отбираемых проблем для решения состоит в том что это только те проблемы которые вы ХОТИТЕ решить, но не факт что решите. и что еще
хуже не факт, что решите ДО КОНЦА. Это ваши эксперименты с вашим собственным процессом работы, которые вы сами над собой, коллегами и процессом будете ставить. И не факт, что эксперименты будут успешными. Вполне возможно что их придется откатывать, при том делать это не после следующей ретроспективы, а "на горячую", в процессе основной деятельности.
Процесс голосования довольно важный момент - на нем можно увидеть есть ли у команды единодушное мнение о главных проблемах, или это мнение размыто.
Опять же, это отличный момент для фасилитатора "попробовать продавить" решение "главной" проблемы команде - только помните что делать это нужно не на первой ретроспективе и ОЧЕНЬ аккуратно.
И опять же - выбор проблем - это место для возникновения социальных игр. За этим надо следить.
Если чью-то "типа маленькую проблему" запихивают в угол или под ковер, то ее можно попробовать "продавить" под соусом улучшений в другой области.
Итак, голосование завершено, топ-3 проблем собран, переходим к следующему этапу, предварительно сделав фото доски.
Анализ проблем.
Берем проблему с наибольшим количеством голосов и пишем в верхней части доски/флипчарта.Дальше начинаем анализ проблемы любым удобным вам способом.
Тут я хочу сослаться на книгу Дэвида Стрейкера - она будет являться отличным методическим пособием для вас на этой стадии - в ней есть кусочек методологии в связке с инструментом (стикерами).
Достаточно часто бывает так, что проблема "проседает" под тяжелым взором всех участников команды - это значит что все чего им не хватало для решения этой проблемы - это собраться вместе и поговорить. Радуйтесь - вы только что получили +1 в карму фасилитатора. Эту "просевшую" проблему нужно разложить на таски и впихнуть в бэклог.
В процессе анализа проблем у вас и ваших коллег/подчиненных будет возникать куча вопросов, домыслов или предположений.
Скорее всего на поверхность всплывут еще и факты.
С этим всем нужно работать. Во-первых факты нужно отделить от всего остального - они сами по себе.
Предположения, домыслы, гипотезы лучше всего организовать в какую-то схему - mind-map, дерево по Стрейкеру, блок-схему (блок-схема иногда офигенно работает, только большая получается).
Это позволит вам держать перед глазами как отдельные домыслы/гипотезы, так и взаимосвязи между ними а также альтернативные ветки.
Что важно на данном этапе - это то чтобы задачи которые будут являться конечными узлами,например, mind-map-а были простыми, исчислимыми и довольно рутинными.
Во-вторых следует понимать, что не всегда проблему можно взять штурмом - составив схему предположений/гипотез вы не всегда пройдясь по ней сможете точно понять, что вам нужно делать.
Ваша задача в таком случае - за минимальное количество времени и ресурсов максимально достоверным способом отсечь ветви не достойные дальнейшего внимания.
Имея в руках такую схему по анализу проблемы вы должны трансформировать ее в конкретный набор задач.
Если у вас достаточно кросс-функциональная команда и навыки/умения более менее выровнены - то распределением задач можно заняться потом.
Если это не так,то лучше раскидать по исполнителям сразу.
Полезная (необязательная) практика: на задачу назначают два человека - один исполнитель, второй валидатор (дежурный тролль на задаче :)). Данная практика хорошо работает в случае исследовательских задач, когда исследователь может начать исследовать слишком много всего и не всегда нужного.
Итого по результатам анализа вы должны получить:
1) список задач которые прольют свет на непонятные вам моменты (гипотезы и предположения), либо напрямую улучшат ваш процесс
2) схему увязки этих задач в единое целое, как путь от частных задач к большому улучшению.
Схема может прижиться у вас не сразу, может и не прижиться вообще.
Но если вы пытаетесь решить большую проблему - то лучше ее иметь ее, иначе есть шанс запутаться или просто забыть о какой-то вещи.
Сформированные задачи вам нужно будет воткнуть в бэклог, но тут уже у каждого все по-своему.
Оформленные результаты ретроспективы (карту, блок-схему, список задач, прочее) нужно разослать на всех участников ретроспективы.
Опять же полезная практика - в отправляемом письме обозначить список задач и кто за них ответственный.
Также умные люди, которые пишут книги, говорят, что по окончании ретроспективы нужно собрать обратную связь со всех участников - удовлетворены ли они ее результатами/процессом или нет.
На мой взгляд это несколько излишне - еще одно волшебство ретроспективы заключается в том, что люди сами должны скорректировать вас если что-то идет не так. Ретроспектива - это не только анализ положительной/отрицательной обратной связи, но еще и способ обучения как ее давать.
В конце-концов - если вам не нравится как проходит ваша ретроспектива, то это тема для обсуджения на следующей :).
Продолжать повествование относительно данного этапа ретроспективы считаю непродуктивным, если какие-то вопросы остались неосвещенными - добро пожаловать в комменты.
Комментариев нет:
Отправить комментарий