"В те времена Мир был таким первозданным, что многие вещи не имели названия, и на них просто тыкали пальцем..."
— Г.Г. Маркес, Сто лет одиночества
Эту цитату я вспоминаю всякий раз, когда сталкиваюсь с концепцией, которая кажется чуждой или совершенно не подходящей на первый взгляд. Одна из таких идей — 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 — это не просто инструмент, это философия действий. Она напоминает о важности не бояться делать паузу, замечать проблему и исправлять её навсегда. А ещё — не забывать, что время всегда есть, нужно только направить его в правильное русло.
Читайте мою серию: Усталый Босс
