Как подогнать любую методологию управления под свой проект, команду, компанию
Суровое руководство для старта в управлении — или почему внедрение методологии начинается с людей и заканчивается на людях
В компании решили внедрять новую методологию управления проектами. Раньше там не работали по методологиям или работали по другой. Или вообще вели дела в чатах — и про коллективное ведение задач ничего не знают.
Как правило, переход на методологию предполагает две вещи: внедрение новых принципов работы и переход в таск-менеджер — цифровую программу, где ведутся все задачи
Только вряд ли получится с первого дня перехода действовать без затыков и ошибок. Да и ещё и с наскока разобраться в цифровой программе.
Суровая правда
- Если один человек в команде знает основы методологии, а другие считают её название матерным словом, то с первого дня ничего не поедет и не заработает
- С первого раза не получится сделать всё и сразу. Это когда одновременно внедряют методологию, уходят из чатов в таск-менеджер и ещё налаживают процессы
- Даже когда процессы настроены по методологии, надо возвращаться и подкручивать процессы, обновлять регламенты, адаптировать новых сотрудников и работать с запросами команды
- Даже если сам менеджер изучил методологию — и он, и команда неизбежно будут совершать ошибки при внедрении и реализации
Вот, что со всем этим можно сделать.
Как начать внедрение
Внедрять изменения могут: проджект-менеджер, сам руководитель, тимлид или член команды, у которого есть время и желание координировать команду и процессы. Этот человек будет строить новые правила, отслеживать их работу и чинить, если что-то пойдёт не так.
Важно сразу донести до команды: мы переходим на такую-то методологию. Втихую насаждать методологию не надо. Лучше неформально рассказать, чем эта методология поможет процессам, людям и компании в целом.
💡 Лайфхак. Полезно предварительно собрать пул проблем, с которыми все регулярно имеют дело. Например: теряются задачи, срываются сроки, кто-то факапит чужие просьбы. Потом можно расширить аргументы до нужд компании в целом: «Если настроим процессы, то будем быстрее выпускать проекты и обновлять продукт, терять меньше клиентов и денег».
Не стоит сразу сыпать терминами из методологии. Лучше использовать слова, которыми уже говорят в компании, и более человечную лексику:
❌ Теперь мы формируем бэклог спринта, потом берём из него таски в работу
✅ Теперь мы строим план на работу на две недели и разбираем задачи
❌ Ставим таски в тикет-системе с чек-листами и дедлайном
✅ Записываем задачи в вот эту программу, внутри списком прописываем, что надо сделать, ставим ответственного и срок выполнения
Новые правила внедряются эволюционно, постепенно. К примеру, если вводите Канбан-доски с колонками-этапами и задачами, начните с простых колонок: Сделать, В работе, Готово.
Для начала можно сделать по дефолту — буквально как в книжке написано. Сделать колонки: К работе, В работе, Готово, — разложить там простой процесс и запустить с посылом: «Давайте попробуем так работать неделю». Можно начать с отдельным сотрудником или командой — не со всеми сразу. Продолжайте и смотрите, повышает ли это прозрачность процессов.
Важно добиться того, чтобы менеджер или руководитель мог в любой момент зайти в проект и понять, что сейчас происходит. Какие ближайшие планы, что надо взять в работу, что сейчас делают и что уже готово. Эти ключевые моменты должен чётко понимать любой член команды. Если это есть, значит процесс работает хорошо. Значит, таск-менеджер выполняет свою функцию.
Когда часть процессов заработает, можно усложнять. Внедрить, например, ограничение на количество задач в работе — WIP-лимиты. Ввести дополнительные колонки с детализацией этапов. Декомпозировать крупные задачи на подзадачи. Расставлять зависимости между задачами. И так далее.
❗Полезно, если программу для ведения задач сначала изучит тот, кто внедряет методологию. Потом он сможет провести демонстрацию интерфейса и функций для всей команды.
Процесс внедрения новых правил работы всегда эволюционный. Придётся регулярно синхронизироваться с командой — возвращаться к разговору о построении процессов, спрашивать, всё ли складывается, и отвечать на вопросы.
Должна быть обоюдная договорённость: мы работаем таким-то образом, у нас вот такие-то колонки, такие-то доски, мы там таким-то образом помечаем задачи. Этот процесс нужно выстраивать, когда его нет изначально — и выстраивать эволюционно.
Наконец, зафиксируйте всё, о чём договоритесь и что будете внедрять в работу. Оформите новые процессы и принципы в общедоступные и легко читаемые документы. Это может быть:
- Регламент постановки задач. Там пропишите в лоб, как правильно ставить задачи, чтобы исполнитель принял, понял и сделал.
- Флоу постановки задач. То же самое, что регламент, но обычно короче.
- Внутренний словарик компании. Туда запишите все новые слова, с которыми познакомилась команда: базовые термины из методологии и корпоративный сленг.
💡 Круто иметь всё из вышеперечисленного. Это ещё пригодится
Что делать, когда не едет
Вот примерный пошаговый алгоритм перестройки дел, если не получается.
Откатиться до заводских настроек
То есть снова упростить процессы до минимально приемлемых и начать эволюционный переход заново.
Оставить на досках колонки: Сделать, В работе, Готово, протестировать это на короткой дистанции и посмотреть, как идут дела. Затем можно снова усложнить — но с учётом ошибок прошлого. А как найти эти ошибки — следующий пункт.
Пообщаться с командой
Спрашивать, что не устраивает, не подходит и неудобно, и как команда видит решение. При этом важно найти баланс между базовыми требованиями методологии, без которых начнётся хаос, и насущными проблемами команды.
Пересмотреть регламенты
Зафиксированные правила и требования могут быть непонятны, искажаться и попросту не работать. Тут поможет только пересматривать и переписывать регламенты — в соответствии с результатами и собранным фидбеком.
Найти «узкие горлышки»
Это когда всё работает, но есть стабильный затык в одном из этапов работы. Такое хорошо помогают отследить Канбан-доски с их колонками, где могут копиться задачи.
Обратите внимание на следующие метрики — количество задач в работе, время их выполнения и срок давности застоявшихся задач. Эти показатели помогут по факту увидеть, где и что идёт не так. Следом надо идти к команде и разбираться, что происходит
Не пытаться натянуть одну методологию на всех
В одном отделе или команде методология прижилась, а в другом нет. Опять — надо идти к людям, спрашивать у них, что у них не работает и почему. Затем предлагать откат до заводских настроек и пробовать перестроить работу эволюционно.
Если процесс или команда проседает, и менеджер не понимает, что делают люди в единицу времени, — надо бежать туда, собирать всю команду и договариваться. Настраивать процесс эволюционным методом и улучшать до того момента, пока он не начнёт работать. Какие-то команды могут работать по спринтам, а кому-то достаточно Канбана. И нормально, если в разных командах одной компании приживаются разные принципы. Чтобы всё работало, надо добиваться одной цели — все знают, какие задачи делать и как задачи делаются
Ключевой принцип — думать о людях, которые работают по внедряемой методологии. Удобно и эффективно должно быть прежде всего им
Как адаптировать новичков
Методология внедрена, всё едет-работает. Приходит новый сотрудник. Допустим, вчерашний студент или стажёр. У него нет компетенций реальной работы с таск-системой и методологиями.
Просто закинуть его в таск-трекер не прокатит — надо объяснить, что и как принято в компании. Помогут в этом документы о принципах работы и разговоры.
- Покажите новичкам регламент работы, где описаны флоу постановки задач, правила работы в таск-менеджере и общения с коллегами.
- Пригодится и внутренний словарик — соберите в нём базовые термины из методологии, птичий язык из сферы и сленговые выражения, которыми общается команда. Сделать такой нетрудно, а новому сотруднику будет куда легче.
- Не бросайте нового сотрудника в одиночестве. Важно отвечать на вопросы и спрашивать, как у него всё получается, помогает ли методология в работе, с какими проблемами сталкивается.
- Не стоит дуть щёки и закатывать глаза, если новичок не знает, что такое бэклог, спринт, тикет и OKR. Мы тоже когда-то не знали, узнали же.
Начните управлять своими процессами в WEEEK. Поможем пройти весь путь — от внедрения новых правил до звёздных результатов
А все непонятные термины и явления мы объясняем в блоге👇🏻 Например, вот, что ещё почитать по теме:
Бессмысленный текст. Нельзя давать абстрактные советы по методологии. Что вы собрались внедрять? SCRUM? 6 сигм? Бережливое производство? Кайдзен? В каждом из этих случаев подход будет свой. Общие же советы можно свести к формуле: возьмите хоть что-нибудь, авось поумнеете. Но опять же этот совет полезен только для чайка-менеджеров и адептов грибного управления.
Чтобы вы не собрались внедрять, надо понимать — команда может это не принять. Дейлики задолбают всех на вторую неделю. Скрам-мастер получит в зубы, потому что лезет со своими терминами и торопит к окончанию спринтов людей, которые ранее работали в своём темпе. Кайдзен и бережливое производство не взрастёт на земле русской, ибо есть национальная особенность "на авось", и мысль о постоянном улучшении и стремлении экономить ресурсы во имя светлого будущего вызывает зуд.
Вот и получается, что не получается переложить методологии в формате контрл+ц контрол+в на любую команду, любой проект, любую компанию
Совет в этом тексте не абстрактный, а конкретный — смотрите на то, как привыкла и как работает команда, пробуйте разные форматы применения и внедрения методологии. Не пытайтесь с первого же дня обстричь свою команду и проект под методологию