Какие ошибки делают руководители на удалёнке

Привет, Хабр! Я не разработчик, а менеджер. Меня некоторое время учили управлять людьми, а потом я погрузилась в мрачный мир разработки, где всё идёт не так, как говорят в университете. Сейчас я руковожу практикой управления жизненным циклом программного обеспечения и хочу рассказать несколько, возможно, важных для тимлидов и ПМ'ов вещей, которые касаются перехода на удалёнку. Потому что в наших командах люди было уже начинали так косячить. А потом покажу и расскажу про наш стек автоматизации для удалёнки, и о том, как мы аппрувим релизы из чатов на телефоне одной кнопкой, а не поднимая VPN в защищённый периметр, и это ускорило согласования, и это помогает согласовывать день в день.

Первый совет — хватит доставать своих людей!



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


Дятел-менеджмент в чистом виде

Если стоит задача повысить эффективность команды сейчас и в перспективе — оставьте людей в покое. И установите 15-минутные дейли по утрам. Я уже успела увидеть и общепроектные синхры раз в четыре часа, и дейли по два часа, и впадающих во фрустрацию менеджеров, привыкших договариваться сидя лицом к лицу с кем-то.

Что у нас случилось с удалённой разработкой в КРОК

Мы очень просто перешли, поскольку у нас и так геораспределённая структура офисов разработки. За последние годы привыкли, что рабочий день кого-то из разработчиков может начинаться с 11 вечера по Москве. Соответственно, для команд с такими участниками проблем по управлению почти не было, а вот для тех, кто работал в одной временной зоне, сложности могли появиться. Например, в одной из моих команд понадобились новые встречи в Zoom для синхрона, и начали подбирать оптимальное время. Сначала делали на понедельник и среду, а потом на среду и пятницу, потому что некоторые из разработчиков предпочли работать на выходных и отдыхать в понедельник-вторник. Отчасти это связано с тем, что их меньше достают в чатах в эти дни.

Вторая важная вещь — у нас уже были готовы инструменты связки чатов, трекеров, корпоративной соцсети и весь CI/CD-девопсный стек, и всё это было частично перелинковано так, чтобы данные из одной системы автоматом заносились в другую. Например, договорились о чём-то в чате, можно сказать боту, чтобы он занёс это в Джиру. И он занесёт. Если делать это самостоятельно, то нужно зайти, протыкать все поля и так далее, ну и как-то подключиться к защищённому периметру. А с ботом проще. Самое сложное — система авторизации. Её мы продумали, докрутили и сделали ещё больше года назад.

Как всё начиналось. Сначала все перешли на удалёнку и неделю привыкали. У кого-то стулья плохие и спина болит, у кого-то дома дети за ноги кусают, у кого-то жена обрадовалась, что муж проводит больше времени с семьёй, и просит раз в пять минут открыть банку. Неделю устаканивались инструменты. Потом вдруг разработчики поняли, что они счастливы, что сидят дома. И не надо никуда ходить, никуда ездить, а на встречах сразу понятно, кто был нужен, а кого просто ради ритуала назначили. Ну и собрания стали начинаться вовремя, потому что нет причин опаздывать. Потом начали страдать менеджеры, потому что общение с заказчиком превратилось в ад. Мы начали ставить в календарь регулярные трёхчасовые встречи (три-четыре дня подряд), просто чтобы пройтись с юристом по пунктам договора, иначе всё это зависало бы на месяцы. Пока работает.

Следующий шаг — вопрос того, что разработчикам на удалёнке нужна мотивация. Не такая, как в офисе. Очень важно не давить, очень важно ставить интересную задачу и давать образ целевого результата. Иначе будет прокрастинация, причём лидер её сам спроецирует. Вылезать из кровати, чтобы делать что-то скучное, просто физически сложно. Лидерам внутри проекта надо на равных давать простор для принятия решения. У нас ситуация в том, что ТЗ обычно не меняется, но власть в рамках спринта принадлежит команде, а не менеджеру проекта.

Естественно, по дороге дальше можно наломать довольно забавных дров.

Что может пойти не так?

Ну, для начала надо помнить, что, несмотря на аврал (а он был много у кого после перехода на удалёнку), процессы лучше соблюдать. Одному из заказчиков мы отгружаем релиз из нашего dev в его dev. Синхро после пулла к ним. Мы отгрузили релиз, они должны были провести интеграционные тесты и регресс. И запаблишить у себя в прод. И вот на следующий день они пишут и просят нас накатить этот релиз им в тест-среду. Потому что они сразу выложили его на прод, а потом вспомнили, что хорошо бы синхронизировать наши окружения. К счастью, релиз не шлёпнулся, но, с моей точки зрения, это выглядит несколько, небезопасно что ли.

Ещё у одного заказчика мы восстанавливали один из сторонних проектов после переноса работ на удалёнку. Там всё куда проще: специалисты заказчика выставили БД наружу, заодно зачем-то выставили plain text с паролями, тоже наружу. Какие-то юные кулхацкеры взломали это всё, естественно.

Про ежедневный дайджест с уязвимостями Zoom и финал истории с утечкой записей вы, наверное, знаете. Не все руководители (часто от бизнеса, ставящие задачи ИТ) понимали, что такое Zoom, как он точно работает, и что не стоит некоторые конфиденциальные вещи говорить под запись. Мы сделали памятку для заказчиков, как пользоваться каким каналом. Вроде, помогло. По крайней мере, многие пожилые инженеры с производств вздохнули чуть свободнее. И перестали присоединять к общим конференциям «mydomain.ru», не уточная, знают ли они этого сотрудника.

Ещё один наш заказчик забыл, что в офисе остались цветы, которые надо поливать. Это мы случайно выяснили при анализе угроз. Цветы спасли.

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



У тех специалистов по Agile, кто привык разговаривать, оклеивая стены стикерами, наступил творческий коллапс, потому что теперь так делать стало нельзя. Во многих случаях проблему решили Trello или Miro. Всем стало легче. Я с удовольствием наблюдаю, как мои коллеги учатся общаться в новой среде с нуля, и их социальность не даёт им таких бонусов, как раньше.

Хороший подход — записать где-то близко режимы каждого разработчика. У нас с этим привычно из-за географии, но добавления вроде «с 16:00 до 19:00 только через телефон в срочных случаях» очень помогают. Именно вот тут очень классно работает аппрув реквеста по док-файлу и результатам проверок: можно сделать даже из кровати, если хочется. Потому что иначе придётся ждать следующего рабочего утра восьми-девяти часов. Такой же простой стек мы стараемся донести тем заказчикам, с кем плотно работаем, потому что если мы привыкли, что документ проходит от системы к системе, то у заказчика тот же атлассиан-стек может быть недоступен, и надо будет отправлять *.docx-файлы с промежуточными отчётами.

Ещё в ряде команд возникла проблема с тем, что встречи в календарь присылаются без заглядывания в этот самый календарь. На один слот может приходиться по три приглашения, причём сам слот уже занят. Это тоже решается организационно и просто.

Вот ещё наши разработчики рассказывают:

Сделали бота для демо — плюсовать тому, кому все плюсуют. И нормально с детьми сидим.

У меня был один из ужасных случаев — у нас был большой проект по внедрению прикладной системы в территориально-распределённой компании. Я находился на Дальнем Востоке с небольшой командой, а основная команда находилась в Москве. Между инсталляциями связь была через механизмы репликации данных, поэтому перед опытной эксплуатацией нам нужно было проверить, как репликация работает под нагрузкой: за три часа на расстоянии 10 000 км надо прогнать объём документов 10 Гб и посмотреть справится ли сеть, не будет ли конфликтов при обработке данных, нет ли взаимных блокировок. Естественно, составили тест-планы, назначили ответственных, окно тестирования. Все на готовности запускать, всё супер, запускаем! И тут понимаем, что пакет данных для репликации запустил наш внедренец на рабочей базе, перепутав настройки. Как итог: временное снижение быстродействия системы, конфликты репликации на рабочей базе, звонки от пользователей, администраторов ИТ-департамента и толпа бегающих консультантов с нашей стороны. От заказчика услышали огроменный нагоняй и то как надо осторожнее подходить к процессу тестирования. Зато есть плюс… провели репликацию на боевой базе сразу и получили подтверждение от заказчика, что система справилась с нагрузкой несмотря на наш косяк.

Никакой разницы с обычной разработкой на удалёнке нет. Ты ж всё равно работаешь с сервисами. Давно был случай, когда мой коллега при регламентных работах случайно прибил VPN-сервер, через который подключался для обслуживания этого VPN-сервера… При пятиминутном окне для обновления системы под нагрузкой резко отваливался доступ в момент после остановки приложения и до запуска новой версии (в эпоху полуручных обновлений)… Или когда запускаешь команды rm -rf /data, а потом понимаешь, что это у тебя продуктив, и быстрее-быстрее ctrl-c.

Чатопс курильщика:



Сделали редеплой релиза на уже зарелизенную машину коллеге. Занулив его работу. Ну, бывает.

А есть примеры по стеку?

Да, вот они:




Это пример техстека с чатопсом



Сам девопс и CI/CD-инструменты у нормальных команд давно отработаны. С точки зрения управления процессом важно то, что на каждом шаге нужно снижать количество неудобных действий, оставляя только полезные. Например, вы выше видите ботов, которые докладывают о состоянии релиза — такие push куда удобнее, чем заходить и смотреть, как он там. Но настоящая ценность появляется тогда, когда всё это позволяет создать непрерывный процесс от «обсудили задачу в чате» до «поставились все задачи со ссылками на обуждение», «прикрепилось ТЗ и пронеслось через все системы» до билда, плюс по пути снялись все нужные метрики вроде меток самооценки. Для разработчиков этот проект был челенджем, потому что обычно они пишут код, а не рисуют архитектуры, пишут концепции и т. д. И если разработка автоматизирована максимально, то у многих команд автоматизация обмена документами или апрувлами не очень хорошо реализована.

Вот пример. Задача считается выполненной, когда каждая строка в ТЗ будет представлять собой рабочую ссылку на кросс-таблицу.

Я руководитель, на чём сейчас сосредоточиться?

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

Если интересно обсудить уже чисто процесс руководства отдельно, то мы делаем вебинар 27-го в 16:00, вот тут можно записаться. Там будет про то, как можно строить процесс, разные ошибки и управленческие кейсы, разделение ответственности (особенно с ИБ), про документооборот между разработчиками, аналитиками, тестировщиками, немного про CI/CD. Ну и даже если вам кажется, что вы и так всё знаете, можно сделать как настоящий джедай — записаться на вебинар, убавить звук и сидеть делать свою работу!