Что делать с ужасными процессами и нерешаемыми проблемами в команде
Недавно чуть-чуть разгребла свой бэклог и посмотрела два видео: про налаживание ужасных процессов и про проблемы, не решаемые никакими способами. Оба видео комплексные и с большим количеством примеров, попробовала упорядочить в выжимку и добавила ссылки по всем решениям, которые упоминались в докладах.
Ссылки на оба видео как обычно оставлю в конце статьи 👇
Часть 1: ужасные процессы
Признаки таких процессов:
- “Нерадивые” сотрудники: они скучают на ретроспективе и вечно опаздывают на митинги. Часто снаружи это выглядит как нерадивость, но по факту может быть неудобным процессом или, отсутствием информации про тот же митинг.
- Формальные отношения: “не приму задачу, пока не заполнят все поля тикета в JIRA”. Часто это признак того, что на сотрудника падает ответственность, которую он не может нести, и он вынужден ограждать себя дополнительными требованиями.
- Лишний труд: планирование спринта занимает 1 рабочий день, на совещание уходит больше часа. То есть работа вроде идёт, но не неэффективно.
- “Сплошная дребедень”: 10 разных задач в день на разработчика, приоритет задачи может 4 раза поменяться в течение дня, сотрудник не может сесть и спокойно подумать.
- “Я в домике”: разработчики просят за них поговорить с дизайнерами.
- “Идеальный мир”: компания уверена, что у них нет никаких проблем в процессах 🤦
Окей, мы насчитали у себя тьму ужасных процессов, а что делать-то?
Начнём с того, чего НЕ делать. Здесь приведу просто огненную цитату из выступления, вчитайтесь, потом обнимемся и поплачем вместе:
“Любая сложная задача имеет простое, лёгкое для понимания неправильное(!) решение”.
За примерами далеко ходить не надо 🙈
Упала производительность на удалёнке ?— Загоним всех в офис.
Некачественные релизы? — Запретим релизиться в пятницу.
А делать-то что? Как всё-таки из ужасного процесса сделать нормальный?
Лёгких рецептов не будет, но есть два рабочих варианта 👇
Вариант 1: ТРИЗ, метод выделения и разрешения противоречий
- Берем задачу, понимаем какая в ней существенная проблема,
- Описываем проблему как противоречие между двумя каким-то состояниями.
- Перебираем все 5–7 базисных методов разрешения противоречий (вот тут есть неплохая статья про ТРИЗ и его методы)
- В выступлении посоветовали детскую книжку: “Месяц под звёздами фантазии” Б.Л. Злотин, А.В.Зусман
(от себя добавлю: читаю сейчас, даром что типа детская книжка, очень полезная 🔥 где ж она раньше-то в моей жизни была? )
Вариант 2: STATIK, инструмент системного мышления из KANBAN
- Вот тут неплохая статья с объяснениями
- Двигаемся от желаемой цели к началу процесса
- Отмечаем активности и ограничения
- Проектируем требуемый workflow
Если обобщить всё вышесказанное:
- Мы видим у себя в команде / компании ужасный процесс
- Проясняем цель, вычленяем проблему и необходимость её решения
- Придумываем решение методами ТРИЗ или STATIK
- На базе этого решения строим процесс чуть получше
Часть 2: Системный подход, или что делать с командными проблемами, которые не удается решить никакими способами
- проблема существует давно и ест много энергии
- непонятно, с чего всё началось
- обычные инструменты не помогают
Например, есть давний конфликт в команде и он никак не решается.
Очевидный подход: уходить в детали и анализировать инциденты (“кто, что, кому, когда сказал”).
Системный подход: подниматься на уровень выше и смотреть не на отдельные инциденты (те самые “кто, что, кому, когда сказал”), а на паттерны и систему в целом (“а когда ещё были похожие конфликты? а были ли похожие в соседних отделах?”).
Для этого надо задавать правильные вопросы 👇
Вопросы системного интервью
В выступлении приводили примеры, какие конкретно вопросы помогают проанализировать ситуацию с помощью системного подхода, “покейсово” приведу их ниже, после вот этого общего списка.
- В какой момент возникла проблема?
- Что произошло в тот момент?
- Что исчезло (клиенты, продукты, техпроцессы, начальные цели)?
- Что появилось (люди, процессы, здания, локации)?
- Чёрные страницы (то, за что стыдно, нанесённый кому-то вред, несчастные случаи, несправедливость)
- Эту проблему мы долго игнорировали?
- Эта проблема возвращается / повторяется?
- Эта проблема проявляется где-то ещё в компании?
- Случалось ли так раньше?
- Кто получает выгоду от того, что так происходит?
- Представьте, что проблема решена. Что пропадёт?
- Предположим, что проблема решена. Где в системе возникнет такая же?
- Есть ли подобная проблема в других твоих системах?
- То, что происходит с вами, происходило с вашим предшественником?
Кейс 1: Тимлид команды не может отказать, когда к нему приходят с новыми задачами и берёт их в работу, в результате команда завалена и ничего не успевает в срок, а часть задач вообще приходится бросать.
Задаём вопросы из списка выше, чтобы найти проблемное место. Для нас ключевыми будут вот эти:
- Эта проблема проявляется где-то ещё в компании?
- Кто получает выгоду от того, что так происходит?
- Представьте, что проблема решена. Что пропадёт?
- Предположим, что проблема решена. Где в системе возникнет такая же?
В результате в этом кейсе вскрылось, что собственнику компании было важно, чтобы всё, что он просит, было немедленно взято в работу. Поэтому задачи по цепочке иерархии приходили к тимлидам (причём не одному, а разных команд) и их немедленно начинали делать. Получилось, что нет смысла учить конкретного тимлида аргументированно отказывать, если вся компания начиная с собственника работает по такой пирамиде 🤔
Кейс 2: Четвёртый подряд генеральный директор не приживается на заводе, нанимает правильно, онбордит людей правильно, люди хорошие, но ничего не получается.
Задаём вопросы из списка выше, чтобы найти проблемное место. В этом кейсе ключевыми будут вот эти, в скобках напишу полученные ответы:
- В какой момент возникла проблема? (Когда мы уволили первого генерального директора)
- Что произошло в тот момент? (Он стал алкоголиком в последние 1.5 года, перестал справляться со своими обязанностями и его пришлось уволить)
- Чёрные страницы: то, за что стыдно, нанесённый кому-то вред, несчастные случаи, несправедливость (До своего увольнения он был прекрасным генеральным директором и вообще-то основал этот завод 20 лет назад, плюс собрал команду. Поэтому к нему была высокая лояльность в последние полтора года несмотря на алкоголизм, а вот к новым свежепришедшим после него директорам — нет)
В результате кейс решился большой информационной табличкой на заводе, про то, что он был основан таким-то человеком, с длинным перечислением всех его регалий. 5-й генеральный директор, к слову, прижился и довольно долго работал.
Здесь стоит отметить очень важный момент для системного подхода —воздавать уважение и признавать все части истории. То есть и то, что человек основал завод и был очень классным, и то, что конце спустя 20 лет его пришлось уволить, потому что он не справлялся.
“Воздавать уважение”, к слову, может быть не только про основание завода, но и про старожилов в команде, которые написали классный код ❤️
Собственно, как решать (и решать ли) нерешаемые проблемы
Вариант 1: Проблему генерирует сама команда
- Не идём в мелочи, думаем про команду как про систему.
- Проходимся по списку вопросов, находим место, где произошёл сбой.
- Всё проговариваем, воздаём уважение, максимально уважительно относимся к историческому наследию, не запихиваем под ковер инциденты.
- В процессе проговаривания может внезапно выясниться, что в команде нет культуры работы с разными мнениями или культуры конструктивной конфронтации, тогда отдельная статья вам в помощь 😇 (“Коммуникации внутри команды, конструктивные конфронтации”)
Вариант 2: Проблему генерирует бОльшая система (компания)
Не берёмся решать 🤷
В конце выступления спикеру задали, имхо, самый важный вопрос:
“Что делать, если проблема на много уровней выше, например, вы тимлид команды, а проблема системно прилетает от собственника компании, а он меняться не хочет?”
Докладчик ответил, что в этом случае мы принимаем честное взрослое решение: мы либо согласны как-то находиться в этой ситуации и приспосабливаться, либо уходим и не терпим (в данном случае увольняемся).
Бонусные статьи в тему 🔥
Ссылка на оба видео:
