Andon Cord (вторая серия) Как Andon Cord помогает даже там, где никто об этом не думал
Generated by Copilot
"В те времена Мир был таким первозданным, что многие вещи не имели названия, и на них просто тыкали пальцем..."
— Г.Г. Маркес, Сто лет одиночества
Эту цитату я вспоминаю всякий раз, когда сталкиваюсь с концепцией, которая кажется чуждой или совершенно не подходящей на первый взгляд. Одна из таких идей — Andon Cord. В своей прошлой статье я подробно рассказал о том, как эта практика помогает решать проблемы в производственных процессах. Однако многие возражали, мол, это для менеджеров и исключительно для фабрик. На самом деле, Andon Cord применим в любых условиях, в частности в IT это краеугольный камень такой чисто ИТшной философии как DevOps. Давайте расскажу на конкретном примере из моей собственной практики.
Как всё начиналось
Дело было в далёком 2014 году. Я работал в команде DBA (администраторов баз данных) на одном крупном проекте. Поддержка баз данных — дело серьёзное, особенно когда они служат основой критичных бизнес-приложений. Цена ошибки была высока, и ни один специалист от этих ошибок не был застрахован.
Но проблема была не только в ошибках. Основная сложность крылась в доступе к знаниям. В то время понятие о базе знаний типа Confluence было ещё достаточно размытым, не говоря уже о практике её использования. На этом проекте баз знаний, как организованной системы, в принципе не существовало.
Знания между коллегами передавались из уст в уста, через почту или, если повезёт, в виде Word-документов. При этом каждый из них мог лежать где угодно: от папок на рабочем столе до общего сетевого диска под литерой O:.
Естественно, в этой среде были более «прожаренные» специалисты и менее «прожаренные». Два сотрудника могли выполнять одну и ту же типовую операцию, но с совсем разным результатом. Сложные операции при этом выполняли только «избранные» сотрудники, обладавшие значительным опытом.
В целом, уровень работы можно было бы охарактеризовать как "Repeatable" по CMM (Capability Maturity Model). Да, были определённые процессы и минимальная последовательность действий, но всё держалось на индивидуальном опыте и навыках сотрудников, а не на стандартизированных практиках.
Мечты о порядке и японская философия
Именно в это время я начал готовиться к своей будущей роли менеджера (хотя пока это были скорее мечты). Я изучал книги по японской философии управления (TPS, Toyota Production System) и Тайм-менеджменту (Getting Things Done). А к тому же, в этой компании был замечательный принцип: "Всегда есть время сделать всё хорошо".
Особенно сильно меня вдохновили два принципа, которые я выделил для себя.
Первый: если что-то идёт не так, лучше сделать паузу. Разобраться с проблемой, навести порядок, обновить или создать соответствующую документацию, чтобы решить её навсегда. Ещё лучше — сразу донести открытие до коллег: через общий митинг или, по крайней мере, корпоративный чат. Этот принцип учил меня быть проактивным и устранять корень проблемы, а не "залатывать дыры на бегу".
Второй: если сталкиваешься с делом, которое занимает не больше двух минут, сделай его сразу. Опыт показал, что такие задачи решаются быстрее, чем процесс их диспетчеризации и последующего выполнения "потом". Как только ты откладываешь их в очередь, они начинают отнимать больше времени: на напоминания, планирование, управление задачей и переключение контекста. Решение здесь и сейчас — это маленькая инвестиция, которая экономит ресурсы в долгосрочной перспективе.
Кошмар ручного Andon Cord
Но всё пошло несколько не так, как я предполагал. Проблем было так много, что мне приходилось слишком часто дергать этот "Andon cord", превращая свою работу в настоящий кошмар. Сложных ситуаций хватало на каждый день, а решения требовали постоянного переключения между задачами. Двухминутные таски, которые я старался выполнять сразу, тоже прилетали в самое неподходящее время, добавляя ещё больше стресса.
Я уже хотел сдаться. Такой кошмар длился несколько месяцев (возможно, два). Но я по натуре человек довольно упорный. И в один прекрасный день я вдруг осознал: кошмара уже давно нет. Даже не почувствовал, как всё нормализовалось.
Важная находка — Knowledge Base
При той же самой рабочей нагрузке отдел работал с этими задачами намного спокойнее и организованнее. Все типовые операции были задокументированы в Knowledge Base (KB). Удача заключалась в том, что я обнаружил модуль Knowledge Management в нашей ITSM системе Remedy, хотя им никто не пользовался. Я начал создавать статьи с описанием типовых процедур и решений. Например, когда коллеги спрашивали, как пропатчить базу данных, я просто отсылал их к статье в KB с номером KB352354 (Oracle database patching).
Систематизация процессов дала второй результат: благодаря детальному описанию операций и внедрению стандарта удалось перевести технически ответственные задачи с уровня L3 на уровень L2. Это было настоящим достижением для команды, так как более простые ошибки и запросы теперь успешно решались менее опытными специалистами, беря нагрузку с плеч сотрудников уровня L3.
Завершение
Завершая этот рассказ, хочу отметить важное: Andon Cord — это не только для менеджеров. Как минимум у каждого из нас есть один подчинённый, кем мы управляем каждый день, — мы сами.
Кроме того, каждый из нас способен драйвить изменения, независимо от того, на каком уровне мы находимся. Достаточно сделать шаг в сторону улучшения, увидеть проблему и найти способ её исправить. Если Магомет не идёт к горе, гора идёт к Магомету. Возможно, вам не сразу удастся добиться порядка и системности, но упорство и осознанный подход рано или поздно дадут результат.
Andon Cord — это не просто инструмент, это философия действий. Она напоминает о важности не бояться делать паузу, замечать проблему и исправлять её навсегда. А ещё — не забывать, что время всегда есть, нужно только направить его в правильное русло.
Читайте мою серию: Усталый Босс
Прошлые статьи:
