🧩 Представьте себе программу, выполняющую определённый алгоритм. Она протестирована и работает исправно. Ясно, когда программа должна запуститься, откуда ей брать данные, как обрабатывать и что выдавать на выходе. Хотя программа может быть очень сложной, всегда можно понять, как она работает, если потратить на это достаточное время.
🛠 Однако у такой программы есть уязвимое место: если хотя бы в одном месте изменится формат данных, например, система, из которой мы получаем информацию, начнёт выдавать их по-другому, всё может сломаться. Именно поэтому программисты тщательно следят за строгим соблюдением регламентов оформления данных и ведут версионность всех изменений.
👯♀️ Теперь рассмотрим команду людей, работающих над общей целью. Если наблюдать за командой сколько угодно времени, можно ли чётко сказать, что каждый из её членов делает в каждый момент? Предскажем ли мы каждое последующее действие? Нет, хотя процессы в команде примерно одинаковы для разных задач, все нюансы кроются в этом «примерно».
🤝 Люди — не роботы и могут договариваться, даже если формат данных изменился. Если кто-то сделал что-то не так, как раньше, другой человек может понять, чем это отличается от предыдущего варианта, и скорректировать свою работу. Именно это позволяет процессу продолжаться, несмотря на отсутствие строгой документации.
🥳 С одной стороны, такая гибкость — это сильная сторона командной работы. Моя задача как Agile-коуча — поддерживать эту командную гибкость. Мы с коллегами добиваемся этого, организуя множество пространств для быстрой синхронизации. Все Scrum-события направлены именно на это.
🧐 С другой стороны, эта гибкость создаёт много серых зон в ответственности и процессах команды. Задачи выполняются, релизы выходят, но если попросить команду описать, как они это делают, вам никто не ответит. Если же собрать всю команду и попросить нарисовать процесс со всеми ответственными, то можно увидеть много интересного.
📌 Эти серые зоны часто приводят к срывам сроков, релизов и обещаний клиентам, причём в самый неожиданный момент. Кто-то увольняется, и оказывается, что именно он выполнял важное действие в процессе. Он делал это как командный игрок, ратуя за общий результат, а теперь его нет. Команде нужно время, чтобы подстроиться и перераспределить ответственность в реальной боевой ситуации.
🤬 Часто я наблюдаю, как люди, перегруженные ответственностью, закрываются и говорят: «Теперь все задачи я буду принимать только через выполнение инструкции, если что-то будет заполнено не так, буду возвращать задачу назад». Такой разговор может свидетельствовать о перегрузке сотрудника или дисбалансе ответственности. Эпогей серых зон выливается в явные конфликты внутри команды.
👌 Взращивая командную гибкость, необходимо также систематически работать над устранением серых зон. Как это делать? Визуализацией ключевых процессов с чёткой распределённой ответственностью, с прозрачным обсуждением этого всей командой. И с фиксацией ответственности, например, в виде матрицы RACI. О ней я расскажу в следующем посте.
🧠 Кстати, интересно, как с развитием искусственного интеллекта и внедрением его в бизнес-процессы мы видим, как он тоже учится подстраиваться под изменение данных. Такая подстройка упрощает автоматизацию процессов, но способствует созданию серых зон, которые могут «выстрелить» в самый неподходящий момент. Всё как у людей)
Если статья понравилась подписывайтесь на канал "Путь Agile" в телеграмм
