Хочу поделиться своим путем: от команды из двух человек с моим одноклассником до управления департаментом.
Это точно не набор лайфхаков. Это вряд ли очередная история успеха про то, как все получилось. Это скорее про рефлексию, про свои ошибки, про свой опыт и про те инструменты, которые помогали мне на каждом этапе пути.
Кто такой инженер? Это молодой специалист с дипломом? Может быть, разработчик, а может быть, тот, кто вырос из разработчика? Может быть, это специалист по инфре или тот, кто знает платформу? А может быть, это аналитик или эксперт в процессах?
Я смотрю на роль инженера несколько шире. В моей картине мира инженер – это специалист, который создает, проектирует, совершенствует системы и использует для этого свои знания, опыт, умения, навыки и какой-то инструментарий. Но самое главное – делает он это системно и предсказуемо.
Вот этот человек – это Ицхак Адизес, международный консультант по управлению и автор книги «Управление жизненным циклом корпораций».
Но сейчас не про корпорацию, а про его книгу, которая называется «Идеальные руководители: почему ими нельзя стать и что из этого следует».
Мне интересна не сама книга, а модель баланса управленческих ролей, которая называется PAEI.
Что это такое? Это первые буквы обозначения функционала руководителя. И каждая из них – часть общего профиля скиллов менеджера и инженера. Баланс этих функций PAEI напрямую зависит от размера команды и зрелости процессов в ней.
И здесь хочется задать дискуссионный, риторический вопрос, вряд ли позволяющий ответить на него однозначно: вы управляете людьми или системой? Подумайте об этом.
Когда я готовил статью, я задумался: а как это все произошло? Откуда у меня этот драйв, этот запал?
Первый инсайт: от ручного труда к автоматизации
2004 год. Я с отцом работаю на стройке подсобным рабочим. И был такой кейс, который отложился в памяти. Мужики берут ведра с цементным раствором, поднимают их и идут таскать на третий этаж. Я, такой ответственный, тоже взял и потащил.
Отец говорит: «Зачем? Вот кран. Давай в кран загрузим, он поднимет».
Я такой: «Точно. Так можно было».
Инсайт: зачем работать руками, если можно работать головой?
Проходит десять лет. Я менеджер по продажам стройматериалов в Екатеринбурге. Там в центре есть высокий-высокий небоскреб, «Башня Исеть» называется. Там я реализовал первый проект в Европе по подъему штукатурной смеси на 52-й этаж.
Кажется: причем тут айтишка и стройка? А инсайт точно такой же: зачем поднимать руками, если можно реализовать это с помощью автоматизации?
Первый управленческий перелом: взять ответственность за систему
Но ровно в этот же момент начало подгорать. Подгорать у меня начало в первую очередь потому, что вот он, самый крутой проект: я все сделал, а куда дальше идти – непонятно.
Тогда же я начал все чаще упираться в айтишку – и тут появляется какой-то условный Иваныч. Это человек, который отвечал за нее в той компании, где я тогда работал. Компания небольшая, человек пятьдесят. И вот как сейчас помню: приходишь к Иванычу и говоришь: «Иваныч, давай замутим какую-нибудь фичу в 1С, будет круто. Поможет мне как продажнику, поможет складу».
Он такой: «У-у… Месяц, может, два. Мне некогда».
Во что это все в конечном итоге вылилось? Была тогда УТ. И я как сейчас помню эти постоянные регулярные конфликты блокировок, завершение сеансов администратором. Набиваешь счет позиций на 600, нажал кнопочку – а оно чпоньк, и все вылетело. Нет слов. Я не говорю про неконтролируемые изменения конфигурации или про то, как платформа с флешки обновлялась на пятидесяти компьютерах. В общем, максимально понятный кейс, как делать не надо.
И в этот момент, наверное, есть смысл поговорить про очень базовый паттерн – про проактивность и реактивность.
Проактивность – это история про то, когда ты способен посмотреть на шаг вперед, осознать, как поменять вокруг себя среду: может быть, компанию, может быть, людей, сделать что-то для того, чтобы лучше жилось тебе и твоим окружающим.
Реактивный подход, напротив, – это позиция: «Я человек маленький, я ничего не решаю».
В этот момент, кажется, пришло озарение. Пришел я к собственнику компании и говорю: «Наверное, хуже уже быть не может. Я хочу взять на себя ответственность и построить систему».
Надо сказать, что до этого я уже помогал решать несколько технических айтишных вопросов и чуть-чуть понимал, как там все устроено. В общем, были долгие переговоры, уговоры, доводы. Убедил.
От молодого IT-руководителя к команде
И вот 2014 год. Я молодой IT-руководитель. Через три дня лег гипервизор. Это штука между железякой и виртуальной машиной, на которой они крутятся.
Я 8 мая, в свой день рождения, в выходной, сижу в серверной и пытаюсь восстановить весь этот зоопарк. В тот момент я был искренне рад, что Иваныч не додумался вынести файловое хранилище на тома и хранил все файлы в базе. Хотя бы они уцелели.
2016 год. Иваныч ушел на заслуженный отдых. Я пригласил одноклассника, как это делается в маленьких компаниях: друзья друзей, родственники, семейная история. Тут же по знакомству нашли 1С-ника. Он в Москве, мы в Екатеринбурге – удаленка до того, как она стала мейнстримом.
Потихоньку-помаленьку все настроили, дыры заткнули, месяц закрыли, запретили ходить в прошлые периоды, синхронизацию с бухгалтерией настроили. Вроде паровозик тронулся, что-то поехало.
Возникает резонный вопрос: ты вроде про стройку, а при чем тут айтишка? Вот в интернеты сходили, тут узнали, там посмотрели – таким образом накапливались знания и экспертиза.
И в этот момент есть смысл вернуться к модели. А кем был тот руководитель Дмитрий? Он был продюсером. Он был тем, кто делает все сам ручками, с криками: «Смотри, как нужно, я сейчас тут все-все-все запилю».
Процессов никаких. Команда из трех человек занимается всем: и чтец, и жнец, и на дуде игрец. Вот этот кейс про проверить лично, принять лично решение и самому его исполнить – это все туда, все в одни ворота.
Кризис роста: когда лидер становится бутылочным горлышком
Итак, 2018 год. Команда растет. Нас стало уже не трое, а семеро. Появились сотрудники техподдержки, появились аналитики, разрабы. Мы стали полноценной командой.
Бизнес к тому моменту тоже очень сильно подрос. Из 50 человек стало 400, появились новые филиалы и регионы. Появились новые проблемы.
С одной стороны, уже был какой-то устоявшийся релизный цикл, коммиты перед бизнесом за сроки выполнения задач. Но в то же время была конкуренция за объекты: «Кто захватил корень? Отпусти быстрее, мне по-быстренькому что-нибудь поправить».
Ночные релизы. Я не шел спать до тех пор, пока мне мой коллега Денис не писал: «Базу обновил, галки снял». Имею в виду снятие отметок блокировки входа пользователей и разблокировки регламентных заданий.
Никакого мониторинга тогда не было, автоматизации не было тоже.
Но в этот момент увеличившиеся темпы явно дали понять одно: нужно начинать управлять процессами. А в другой руке появилось понимание, что если я вдруг отойду в сторонку, то все ляжет и упадет. Такой колосс на глиняных ногах: вроде наверху все красиво, а если что-то вглубь копнуть – беда.
С явным ощущением, что что-то идет не так, я пришел к тому, что мы заболели симптомами какой-то неправильной управленческой модели. Есть перегрузка меня как руководителя. Команда лишний шаг боится сделать без согласования. Конфликты приоритетов: складу что-то надо, продажам что-то надо. Приходит бухгалтерия, всех раздвигает и говорит: «Мы первые, у нас отчетность».
С другой стороны, это постоянные пожары и в конечном итоге выгорание от отсутствия микропобед. И все опять же приводит к тому, что оказывается: я как лидер стал тормозить команду. Я стал бутылочным горлышком.
И еще один инсайт, проверенный на себе: если ты как лидер сводишь все к себе, будь готов, что команда побежит со скоростью самого медленного игрока.
Новый этап: от контроля людей к правилам игры
2019 год. Мы с командой впервые поехали на «Инфостарт». Много о нем слышали, разговаривали, и наконец появилась возможность.
В тот момент я и коллеги, по их отзывам, почувствовали себя как ребенок, которого впервые привели куда-нибудь в «Детский мир». Куча игрушек, глаза разбегаются, ты не знаешь, с чего начать. Такой: «А-а-а! Вот это, вот это, вот это».
В конечном итоге, когда мы приехали домой, это первое, что мы сделали. Это реальное фото из нашего не очень симпатичного кабинета, но смысл не в этом. Смысл в стикерах. Каждый из нас, когда вернулся, написал название доклада, который ему зашел. Мы их на доску разлепили и стали запускать, стали внедрять те процессы, продукты и инструменты, о которых узнали и услышали.
И здесь прилетел новый инсайт. Я вдруг резко осознал, что моя роль лидера меняется: от контроля людей к их сервису. Мне не нужно контролировать каждого. Мне нужно создать команде комфортную среду с помощью инструментов, технологий, каких-то понятных решений.
Мы приходим к тому, что надо ответить на вопрос не «что нужно сделать», а «как нужно это сделать, какие инструменты применить». И в этот момент очень важно установить правила игры. Используя конкретный инструментарий, продукты, софт, фреймворки, нужно сделать так, чтобы команда начала играть по правилам, которые понятны всем участникам.
Это тот инструментарий, о котором мы узнали тогда, в 2019 году. С 2019 по 2022 год именно в той команде, в той компании мы все это абсолютно успешно внедрили. Сначала был Jenkins, потом GitLab – мне он больше зашел. Но смысл не в этом. Смысл в том, что это именно тот инструментарий, который позволил установить правила игры и автоматически контролировать исполнение этих правил.
И теперь ждать сообщения от Дениса о том, что база обновлена, галки сняты, мне уже не приходилось.
2022 год: новая компания, новая команда и страх релиза
2022 год – новое место работы. Новая компания, новые процессы, новые задачи, переход из УП в ERP.
Но проблема: нет команды. Я, по сути, один, с конкретным запросом от бизнеса: нужна команда и нужно реализовать процесс перехода.
Важно: это производство 24/7. До этого у меня такого вызова не было. Здесь было определенное ограничение в виде практически отсутствующего технологического окна с одной стороны, и обязанности запустить пооперационное производство, которое фактически напрямую влияло на производственный цикл, – с другой.
Появился страх релиза. С одной стороны. А с другой – я оказался в тисках между долгим, качественным тестированием и time-to-market, между коммитом за сроки и необходимостью реализовать задачу.
Вспоминаем: команда только формируется, ее практически нет. Но есть четкое ощущение, что формировать эту команду нужно уже под готовую среду. И я снова ушел в харды.
В этот момент я сидел, строил пайплайн, разбирался с тем, как работает контейнеризация, запускал тесты в Vanessa в контейнерах. Все это привело меня к мысли о том, что автономия команды возможна только тогда, когда правила понятны и известны, когда есть работающие механизмы и работающий инструментарий.
А какой инструментарий может помочь руководителю эти процессы контролировать? Какие процессы нужно контролировать с помощью этого инструментария?
Первое – это какой-то flow. Давайте так: я написал GitFlow, потом не стал менять, но в принципе очень важно определить тот подход к разработке, который есть. Чтобы было понятно: у тебя есть новая задача – создаешь или ветку, или новое хранилище, или сразу идешь в разработку. Неважно. Важно, чтобы эти правила были понятны.
Всегда и везде топлю за CI/CD. Мне кажется, что это тот инструментарий, который позволяет снять кучу боли, кучу вопросов и, самое главное, сократить время доставки фичи в продуктив.
Дальше – это управление окружениями, изоляция сред, возможность тестировать, разрабатывать, проверять на разных средах, на разных окружениях.
Статический анализ. Про это уже не сказал только ленивый, но так или иначе иногда эта штука находит такие замечания в коде, которые на код-ревью мало кому доступны.
Автотесты. База? База, но до сих пор понимаю и осознаю, что многие до этого еще не добрались.
И самое главное – это ритуалы.
Что такое ритуалы? Ритуалы – это тот подход, тот набор паттернов, который так или иначе позволяет команде работать ритмично, работать циклично. То есть это набор ранее принятых решений, которые нужно просто поддерживать и исполнять. Самый простой пример – дейлики.
У меня был опыт: ребята каждый день в девять проводили дейли, но все растягивалось минут на тридцать. Первое, что я сделал, – посмотрел, почему растягивается. Оказывается, люди ждут друг друга, потому что кто-то опаздывает.
Я говорю: «Окей, давайте будем приходить не в 9:00, а в 9:07. Но в 9:07 мы совершенно точно начинаем работу. Если вас в 9:07 нет – ну, сорян, пишите объяснительную».
Но посыл какой? Этот паровозик поехал, процессы завелись, кажется, инструменты начали нам помогать.
Инсайт: чем понятнее процессы, тем более саморегулирующейся, самоустанавливающейся становится команда. Ее можно отпустить в свободное плавание. Понятно, какие-то углы подсгладятся, но так или иначе на подкорке они уже остаются.
Это работает. Процесс пошел, дело сделано. Это тот результат, которого я ожидал. Бизнесовую задачу тоже получилось закрыть: переход состоялся меньше чем за год.
2024 год: новый масштаб и роль интегратора
2024 год. Настало время двигаться дальше, и я оказался в «Почтотехе».
Был ли это вызов для меня? Совершенно точно да. Это совсем другой масштаб, совсем другая компания, совсем другие задачи, приоритеты, люди сильно более компетентные.
В такой роли, понял я, очень важен баланс навыков. А кем я туда пришел? Технарем или переговорщиком? Тем, кто работает руками, или тем, кто классический руководитель, водитель руками?
Может быть перекос в hard skills, может быть перекос soft skills. Но как будто бы на позиции, когда ты поддерживаешь работу пятнадцати ключевых систем крупнейшего оператора связи, нужно балансировать.
Я руководитель, у меня двенадцать людей в подчинении, матричное управление, полтора десятка систем. Я себе представлял работу, как постоянные переговоры, но фактически сел на своего любимого конька и снова пилил пайплайны.
Так или иначе, hard skills и soft skills со временем сбалансировались, и способность работать руками мне в этот момент очень сильно пригодилась.
Но в этот момент стало понятно, что мой опыт нужно масштабировать на команды. Напомню, их там практически пятнадцать штук. И нужно ответить на вопросы: кто это должен сделать? Как? С помощью какого инструментария? Оказывается, теперь надо делиться своей экспертизой, своим опытом.
И в такой среде очень критично развивать роль интегратора: того человека, который может наделить своим опытом, передать свои знания коллегам, запустить эти процессы, просто скопировать, вставить, размножить в среде, в которой он находится.
В этот момент я понял, что есть смысл использовать уже знакомый мне и работающий подход.
Командам я сказал: «Не будьте героями. Выстраивайте процессы. Делайте так, чтобы эти процессы были понятны. Фиксируйте решения. Договаривайтесь о приоритетах и вперед, в бой». Но самое главное: работать в процессе гораздо проще и понятнее в долгосрочной перспективе, чем бежать с красным флагом на амбразуру.
Пилот на ЗУП: идти туда, где страшнее всего
Пришло время пилота. И вновь новый инсайт: если систем много, если проблем много, если глаза разбегаются и непонятно, куда идти, надо идти туда, где страшнее всего, и светить фонариком в самую тьму.
Я посветил. Выбрал три буквы. Это самая сложная система: порядка восьмидесяти интеграций, сотни тысяч сотрудников, локальный Fresh, пара десятков баз, под сотню областей, команда двадцать пять человек, самый архаичный релизный цикл и куча проблем.
Ну да, это был ЗУП.
Что делать? Автоматизировать.
Через пот, кровь, слезы, боль мы запустили работу с ветками, переехали в локальный GitLab и научились работать с merge request.
Все процессы внутри merge request обвесили проверками.
Какими? Правильного ответа нет. Я обвешивал теми, где болело.
Например, проверял наличие номера задачи в merge request. Это самое простое.
Или, например, контролировал версионность в расширениях. Локальный Fresh очень требователен к паттерну имени: надо, чтобы там были четыре точки. Пару раз сборки из-за этого ложились. Кажется, это надо проверять руками? Да ну нафиг.
То же самое делал для того, чтобы контролировать порядок объектов внутри конфигурации. Это позволяло, с одной стороны, иметь симпатичную, причесанную рабочую среду, а с другой – избегать merge-конфликтов, когда в конфигурационный файл добавляется пара объектов одновременно.
Это окошко с релизом в Jira. Была проблема: мы бизнесу отдавали один список задач, а релизили почему-то другой. Как – непонятно. А просто потому, что не было ритуала, не было процесса, который бы это контролировал.
Очень простая проверка: добавляем джобу, упаковываем ее в контейнер и с помощью API Jira начинаем проверять, что все задачи с нужными префиксами есть в нужном нам релизе. А префиксы мы уже научились проверять.
От ручного контроля к стратегии развития
Мы приходим к четвертой функции: как и зачем это нужно сделать.
Если сейчас вернуться на десять лет назад: нужны ли были мне подобного рода подходы в той маленькой команде? Да нет, конечно. Вот они все передо мной, ребята сидят. Их там два-три-пять человек. Мне гораздо проще сказать им: «Ребят, так делать не надо». Раза с третьего каждый поймет.
Но когда ты масштабируешься, кажется, что во главе стоит уже не ручной контроль, а стратегия развития. Нужно думать на пару-тройку-четверку шагов вперед и с помощью тех самых технических процессов контролировать работу команды.
Но это еще не все. В тот момент, когда на ЗУП этот процесс запустился, осталось еще четырнадцать систем. Как контролировать их работу? Как посмотреть на все системы целиком?
Для этого есть интересный продукт, который называется Apache DevLake. Он позволяет из GitLab, Jira, Sonar получать набор метрик и представлять из них симпатичную картиночку.
В конечном итоге эта симпатичная картиночка оборачивается в четыре ключевые метрики.
Первая – время доставки изменений до продуктива.
Вторая – частота изменений. Чем чаще вы релизитесь, тем лучше.
Третья – процент релизов с косяками. Косячить не надо. Лучше, чтобы там был ноль.
И четвертая – если вдруг накосячили, сколько времени занимает исправление. То есть в течение какого времени вы выпускаете патчи и исправляете то, что пошло не так.
Итоги
Итак, что делать для того, чтобы получилось?
Первое – фиксируем узкие места. Идем туда, где болит. Это база, но почему-то я очень часто слышу от коллег, что приходится распыляться. Возьмите конкретную проблему и бейте туда до тех пор, пока она не будет решена. Две задачи, но не больше. Три – уже довольно сложно.
Второе – формализуйте поток изменений: делай раз, делай два, делай три. Если мы не контролируем merge request или наименование задачи в хранилище, значит, нужно добавить проверку. Не нужно идти в какие-то супертехнологичные сборки, если у нас не закрыт базовый процесс. Иначе это все, как карточный домик, посыплется друг за другом.
Третье – внедрить автоматические проверки. Ровно в тот момент, когда инженерия становится неотъемлемой частью рабочего процесса, вы как управленец, вы как менеджер, начинаете этой инженерии доверять самое сокровенное – процессы менеджмента, процессы управления рутинными задачами. И, как будто бы, это тот способ, который позволяет вам задуматься о каких-то стратегических подходах. Кажется, что ваша задача – не работать руками. Ваша задача – работать головой и быть визионером.
Четвертое – сделать статусы прозрачными. Вся команда должна понимать, что происходит, куда вы идете. Если есть вопросы – разберите их на one-to-one или проговорите на общих встречах.
Что мешает перейти от ручного контроля к сервисной роли?
Первое, наверное, может быть, даже основное – это страх потерять влияние: «Как же я вот это, то, что своими руками строил, отпущу?» Да легко. Люди будут благодарны.
Недоверие к процессу: «А вдруг что-то пойдет не так? Вот я здесь точно все-все проконтролирую, я знаю, куда смотреть». Супер. Если ты знаешь, куда смотреть, гораздо проще это автоматизировать. Нет смысла тратить на это время, силы и ресурсы.
Непрозрачные приоритеты. Если человек не знает, куда бежать, он может бегать по кругу.
Отсутствие автоматики. Если человек может накосячить, он обязательно накосячит. Если что-то может пойти не так, оно обязательно пойдет. Вопрос не в том, «если», а в том, «когда».
Недостаток hard skills. Что важнее: soft skills или hard skills? Мне кажется, баланс всегда где-то посередине. И если есть возможность углубиться, есть возможность задать самому себе или команде вопрос: «А почему это пошло не так?» – и получить мотивированный ответ с отсылкой на какие-то технические проблемы или вопросы, абсолютно точно есть смысл в этом разобраться. Тем более сейчас есть куча инструментов, например, ИИ, который может помочь вам в этом разобраться.
И, наверное, самое главное – привычка быть героем. Ведь всегда классно подняться на сцену и сказать: «Я победил».
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.