Руководство ИТ-командой и разработка ПО имеют несколько общих принципов. Им стоит следовать, чтобы обеспечить гибкость, эффективность и готовность вашей команды, пишет на портале Enterprisers Project Крис Эк, руководитель отдела инфраструктуры компании Coda.
Опыт создания и обучения межфункциональных команд в таких компаниях, как Microsoft, Google и ряде других, позволил выделить три основных принципа, которые применимы как к инженерам-разработчикам, так и к ИТ-специалистам. Эти принципы должны доводиться до всех новых сотрудников и приниматься на вооружение руководителями ИТ-отделов повсеместно.
1. Стремитесь к простоте
Старый принцип (KISS, «делай проще») звучит банально, но ему стоит следовать — независимо от того, насколько сложной может быть ваша ИТ-система.
Что вам больше нравится: «умный» алгоритм, который повышает производительность на 2%, или код, который легко читать в два часа ночи, когда вы сидите дома и пытаетесь понять, почему ваша система не работает? Выбор должен быть очевиден: код, который понятен — особенно в далеких от идеала обстоятельствах — это код, который поможет вам выбраться из затруднительного положения и который будет легче поддерживать, обучать ему новых сотрудников и развивать.
Простота также означает, что нужно входить в положение своих сотрудников. Компаниям необходимы изменения по мере их масштабирования, и в периоды быстрого роста они должны расширять свою ИТ-команду такими же темпами и создавать системы, которые максимально снижают трение. Примером такого рода систем является автоматизация ИТ-тикетинга.
В Coda реализована интеграция между документом и Slack для автоматизации ИТ-запросов. Сотрудник может попросить о помощи в специально созданном канале Slack, и кто-то из ИТ-команды отвечает ему эмодзи в виде тикета. Этот эмодзи запускает создание нового тикета в документе по сортировке и отслеживанию и назначает владельца тикета в зависимости от типа запроса. Таким образом, сотрудники могут обращаться за помощью, применяя инструменты, которые они уже используют для работы, без необходимости заполнять форму или входить в отдельное ПО.
В рамках ИТ-отдела вы должны автоматизировать задачи, которые в противном случае придется выполнять вручную. Помните, что очень важно продолжать адаптировать эти системы по мере роста компании и увеличения объема обработки заявок.
2. Готовьтесь к сбоям
Все ПО дает сбои — это факт жизни, и история доказывает, что «если вы не занимаетесь планированием, то вы планируете потерпеть неудачу». Если вы разрабатываете и тестируете свои системы таким образом, чтобы в случае необходимости переходить на резервный план, то многих проблем можно будет легко избежать или смягчить их последствия.
Классическим примером программной инженерии является система, с помощью которой дежурные инженеры получают доступ к производственным базам данных. Хорошо спроектированная система вместе с доступом обеспечивает ключевые механизмы аудита и соответствия нормативным требованиям, но если она выходит из строя, вам нужна вторичная система, которая так же соответствует вашим политикам безопасности. Важно помнить, что, поскольку эта вторичная система доступа используется нечасто, она требует надежной документации и должна периодически проверяться, в идеале — раз в квартал.
ИТ-системы, даже ориентированные только на внутреннюю эксплуатацию, должны быть спроектированы таким же образом. Процессы утверждения и эскалации всегда должны резервироваться, плейбуки должны записываться, и все необходимые для внесения изменений ключи не должны быть в руках лишь одного человека. Если основное ответственное лицо недоступно по какой-либо причине, вы все равно должны иметь возможность вести бизнес как обычно.
Планирование замещения людей критически важно. ИТ-отдел должен всегда использовать лучшие практики работы с документацией и резервными планами. Это может быть простое решение — дежурный инженер замещает ИТ-специалиста, который находится в отпуске. По мере роста компании и расширения отделов эти лучшие практики также должны расширяться. Таким образом, когда один из важных членов команды покидает компанию, у вас уже имеется надежная документация и план замещения.
3. Проектируйте инфраструктуру так же тщательно, как вы пишете код
В целом, вы должны проектировать свои внутренние системы так же скурпулезно, как вы пишете код. Вы никогда не запустите приложение без тщательного планирования, рассмотрения потенциальных проблем и устранения ошибок P0. То же самое должно быть применимо и к ИТ-инфраструктуре.
Относитесь к инфраструктуре так же, как к ПО. Ни один опытный инженер не сочтет приемлемым войти в рабочую машину и изменить код на лету, кроме как в экстренных случаях — почему ситуация с вашей ИТ-конфигурацией должна быть иной?
Все изменения должны иметь аудиторский след, чтобы вы могли оглянуться назад и понять, кто внес изменения и почему они были сделаны. Если ваши текущие системы не позволяют этого сделать, определите, какие дополнительные инструменты могут помочь вам превратить ваш код в инфраструктуру.
Обдуманно подходите к проектированию ИТ-системы. Если все сделано правильно, это сэкономит время и деньги в долгосрочной перспективе. А ваши конечные пользователи — сотрудники — получат лучший опыт, поскольку их проблемы будут решаться быстрее, а при внесении изменений будет происходить меньше поломок.
ИТ-руководители должны взять на вооружение такие принципы, как простота, подготовка к сбоям и тщательное проектирование, и это пойдет на пользу их ИТ-системам. Сотрудники станут довольнее, команды смогут выполнять свою работу более эффективно, а если что-то пойдет не так, всегда будет план действий.
