Проект «Феникс». Роман о том, как DevOps меняет би - Страница 72

Эрик начинает идти куда-то, я спешу за ним. Скоро мы уже стоим посреди производственного этажа.

«Ты видишь производственный участок там, с мигающим желтым огоньком?» – спрашивает он, показывая пальцем.

Когда я киваю, Эрик просит: «Расскажи мне, что ты видишь».

Пытаясь представить, каково это – вести с ним нормальный человеческий разговор, я принимаю на себя роль туповатого ученика. «Какая-то часть механизма, видимо, сломана – наверное, поэтому мигает индикатор.

Пятеро человек сбились вокруг, включая двоих, похожих на руководителей. Они все выглядят озабоченными. Еще три человека наклонились вниз, обследуя панель механизма, если я правильно понимаю. У них фонарики, и они держат еще и отвертки, определенно здесь поломка машины…»

«Хорошая догадка, – говорит Эрик. – Скорее всего, компьютеризированный шлифовальный станок сломался, и команда работает над тем, чтобы снова его запустить. Что случилось бы, если бы каждую часть оборудования должен был бы чинить Брент?»

Я смеюсь. «По любому сбою немедленно обращались бы к нему».

«Именно, – продолжает он. – Давай вернемся к твоему первому вопросу. Какие проекты можно будет безопасно запустить, когда вы снимите заморозку с проектов? Зная, как проходит рабочий процесс через определенные производственные участки и о том, какие участки нуждаются в Бренте, а какие нет, что бы ты сказал?»

Я медленно повторяю про себя все то, что сказал Эрик, пытаясь собрать его фразы воедино и получить ответ.

«Понял, – улыбаюсь я. – Проекты, которые можно реализовать безопасно, это те, для которых не требуется Брент».

Моя улыбка становится еще шире, когда он восклицает: «Бинго! Все просто, да?»

Но мое настроение падает, когда я думаю о связанных с данной мыслью сложностях. «Подожди-ка, как я узнаю, для каких проектов не нужен Брент? Мы раньше никогда и не думали, что нам нужен Брент, пока половина работы еще не была проделана!»

Я моментально жалею, что задал последний вопрос, потому что Эрик просто уставился на меня: «Я что, должен дать тебе готовые ответы на все, что ты не способен выяснить сам?»

«Извини. Я разберусь, – говорю я быстро. – Ты знаешь, я вздохну с облегчением, когда мы, наконец, выясним, какие конкретно проекты по-настоящему требуют Брента».

«Чертовски правильно, – отвечает Эрик. – Что тебе нужно сделать, так это создать спецификацию для всей той работы, что вы выполняете в отделе IT-сопровождения. Но вместо каталога частей и комплектующих, вроде формовок, шурупов и колесиков, тебе нужно составить список всех необходимых условий для того, чтобы ты мог выполнить работу: например, номера моделей компьютеров, спецификация пользовательской информации, программное обеспечение и необходимые лицензии, требования безопасности, и так далее, и так далее…»

И тут он прерывает сам себя: «Если быть более точным, ты должен составить спецификацию ресурсов, то есть ведомость материалов вместе со списком требующихся производственных участков и маршрутизацией. Как только она у тебя появится вместе с заказами на работу и описанием твоих ресурсов, ты, в конце концов, сможешь понять, каковы твои возможности и каковы требования к вам. Это позволит тебе все-таки разобраться, можешь ли ты принимать новые заказы и выполнять их в срок».

Великолепно. Я практически все понял.

И я уже готов задать еще несколько вопросов, но Эрик опережает меня: «Твой второй вопрос был о том, было ли правильным запустить ваш проект по мониторингу. Ты уже выяснил, что для него не требуется Брент. Более того, ты сказал, что цель данного проекта – предотвращать сбои, позволяя таким образом снизить количество обращений к Бренту. Более того, когда сбой все же произойдет, Брент сможет быстрее выяснить, в чем проблема. Ты уже определил, в чем состоит ваше ограничение, пытаешься выжать из него максимум, и ты построил определенную субординацию между текущим рабочим процессом и ограничением. Так насколько важен этот проект по мониторингу?»

Некоторое время я размышляю. И затем, запуская руку в волосы, бормочу правильный ответ: «Ты сказал, что мы всегда должны искать способы снизить нагрузку на ограничение, то есть я должен делать все, от меня зависящее, чтобы снять с Брента как можно больше разных циклов. Чем и занимается наш проект по мониторингу!»

Я говорю, и сам не верю, что не видел этого раньше. «Проект по мониторингу систем является, возможно, самым важным улучшением, которое мы осуществили, – нужно запускать его прямо сейчас».

«Именно, – соглашается Эрик. – Превентивная деятельность, направленная на сокращение такой работы, которая требует особого уровня квалификации, лежит в сердце всех программ TPM – комплексной системы обеспечения эффективности работы оборудования. Как сказал бы один из моих сенсеев: «Улучшение ежедневной работы даже важнее, чем выполнение ее». Вся суть Третьего пути в том, чтобы убедиться: мы постоянно работаем с системой, мы закрепляем полезные привычки и занимаемся совершенствованием чего-либо. Мы должны постоянно давить на систему с целью избавиться от тех недостатков, которые в ней есть.

Майк Ротер говорит, что, по сути, неважно, что ты усовершенствуешь, пока ты совершенствуешь хоть что-то. Почему? Потому что если ты не пытаешься улучшить систему, энтропия абсолютно точно будет расти, так как работы без ошибок, потерь и инцидентов не бывает».

Внезапно все становится таким очевидным и ясным. Я чувствую необходимость позвонить Патти прямо сейчас, пусть она немедленно запускает проект по мониторингу.