Когда можно обойтись без проджекта: о командах эксплуатации на аутсорсе
Эта статья — текстовая версия выступления Сергея Хованова на онлайн-квартирнике про аутсорс инфраструктуры. Если вам удобнее, можете посмотреть видео. И заодно заглянуть в другие доклады — они тоже интересные. Слово Сергею.
Привет, Хабр! Меня зовут Сергей Хованов, я в Southbridge отвечают за команды: их работу, структуру и прочие организационные моменты. Southbridge — это девопс-аутсорсер, и команды у нас устроены не совсем так, как в обычных компаниях. Расскажу, почему все команды у нас самоуправляемые, как мы обходимся без проджектов и что сделали для организации полностью удалённой работы.
Классические схемы управления и что с ними не так
До Southbridge я работал в большой корпорации с чёткой и жёсткой иерархией: отдел → начальник отдела → директор по направлению → генеральный директор. И где-то сбоку ещё функциональный руководитель, а то и не один. В какой-то момент я вырос из ведущего специалиста до начальника небольшого отдела и услышал от руководства: «Ну, о дружбе с коллегами теперь забудь, ты у них начальник».
Но у меня в голове не укладывалось, почему нельзя по-другому. Я видел примеры на нефтехимическом производстве, где команда вместе с начальником смены решала задачи, не проводя четкую границу между лидером и подчинёнными. И, на мой взгляд, это было гораздо лучше и эффективнее.
В ИТ всё часто тоже устроено похожим образом. Легко встретить классические «корпоративные» команды с руководителем. Есть варианты «команда + тимлид + проджект менеджер и сверху CTO». В общем, почти всегда вокруг команды есть элементы менеджмента. Но все ли они нужны? И как разобраться, что реально нужно, а без чего можно обойтись?
Структура Southbridge: команды из трёх человек и отсутствие менеджера
Мы в Southbridge решили вопрос радикально — убрали все «обвесы», кроме команды, и посмотрели, что и как будет работать.
Команды Southbridge из трёх инженеров
В основе всего — команды из трёх инженеров. Они все равны, то есть включаются в работу и выполняют задачи. Один из них лидер, но не менеджер — он тоже работает, но при этом помогает расставлять приоритеты и обычно руководит коммуникациями.
Число «три» помогает решать несколько задач:
Оно нечётное, так что споры команда может решать голосованием.
С таким количеством команда ещё может работать самостоятельно. 5 человек — уже перебор.
Один из троих может уйти в отпуск, и команда останется работоспособной.
В дополнении к ним есть «менеджерская» команда. В неё входит:
Техдир, который подключается к командам для решения более сложных верхнеуровневых архитектурных вопросов. При этом он не менеджерит, команды остаются полностью автономными.
Scrum-мастер. Это я. Вообще мы не работаем по Scrum, но в договоре моя должность называется именно так, и более подходящего термина мы не подобрали. Я взаимодействую с командой по процессам и нерабочему общению, помогаю организовать работу. В общем, я тот человек, к которому можно прийти с любым вопросом.
Нужный человек по запросу: продажник, финотдел или кто-то ещё.
Это всё, больше никого нет. Команды работают автономно, по сложным вопросам обращаются к руководителям, но в основном все решения принимают сами.
Вы могли заметить, что здесь нет отдела коммуникации с клиентами. Команды у нас общаются с клиентами напрямую — и это работает отлично, так как убирает эффект глухого телефона.
Как мы формируем команды
Для себя мы решили, что при формировании команд желательно учитывать три навыка:
Визионерство — умение видеть следующие шаги команды наперед, верхнеуровнево и архитектурно. По возможности улучшать и автоматизировать.
Движение — умение работать с рутинными задачами, просто взять и сделать, когда нужно.
Коммуникация — умение общаться с клиентом и объяснять свою позицию.
Не обязательно, чтобы все качества присутствовали в одном человеке. Но в одной команде должны быть все три.
Интеграция нового человека в команду
Перейдём к другому важному процессу — как в эту устойчивую схему из команд вписывать нового человека.
Обычно интеграция длится до трёх месяцев. Это «испытательный срок», но не в терминологии ТК РФ, а в смысле времени, когда:
Компания и конкретная команда смотрят, подходит ли им этот человек.
Человек смотрит, подходит ли ему компания.
Получается что-то вроде тест-драйва друг друга.
Часто на этом этапе компании работают на удержание и создание человеку идеальных условий: буткэмпы, экскурсии, тренинги по адаптации. Что-то вроде ванильной тусовки, где сотрудника не допускают к хардкору, потому что искать нового долго, тяжело и дорого. Поэтому за него держатся и вводят в компанию достаточно медленно, ограждая от сложностей и подводных камней.
Не считаю, что это плохо, но мы в Southbridge работаем иначе — сразу добавляем человека четвёртым в боевую команду. Там он получает ментора и переходит к реальным задачам — от рутинных до более сложных.
При этом новичка, конечно, не бросают одного. У него есть команда, ментор и я, к которому новичок может прийти по любому вопросу. Я отвечу, а если не смогу — помогу найти, к кому обратиться.
При таком подходе бывают разные кейсы. Иногда человек уходит через неделю, а то и через два дня. А иногда остаётся с нами на долгие годы, потому что сразу понял, что его здесь ждёт.
Где в управлении командой место человечности
В связке аутсорсер–клиент мы всегда общаемся в некоем процессе: тикет → приоритет → исполнитель → реакция → статус → решение задачи. Одна функция ставит задачу, другая функция выполняет. Но ведь за этими тикетами и чёрными квадратиками на созвоне стоят живые люди. Как об этом не забывать?
Для большинства компаний человек — это ресурс. У HR даже наука есть — управление человеческими ресурсами, УЧР. Мы ходим на работу для выполнения определённого круга задач, чтобы принести пользу бизнесу. И в сфере ИТ на это накладывается стереотипный образ «сурового админа», который не особенно любит говорить по душам. Но кто бы что ни говорил — «человеку нужен человек». Я на практике много раз убеждался в этом.
Работая с людьми, легко скатиться в одну из крайностей:
На работу ходят только работать. Смену отпахал, дежурство передал и забыл.
Каждый день у нас дейлик, каждый понедельник планирование, по пятницам ретро, ещё пару тройку рабочих встреч и еженедельное время на командообразование. Встречи необязательные, но всем быть!
А когда работа удалённая и коммуникаций за кофе или в курилке нет, все становится ещё сложнее.
В Southbridge мы решили ничего не придумывать, а спросить у команд — как бы им хотелось взаимодействовать. Предложили разные варианты и начали пробовать, чтобы выбрать оптимальный.
Для начала я предлагал командам раз в неделю встречаться на командообразование и неформальное общение, а раз в две недели — на ретроспективу. В итоге все пошло совсем не так:
С первой командой мы встречаемся каждый день на 20–30 минут.
Со второй — раз в неделю на час.
С третьей — один раз в две недели.
С четвертой — вообще не встречаемся.
В пятой еще идет настройка, команда новая.
Встречи проходят по разному: иногда обсуждаем рабочие вопросы, иногда актуальные нерабочие темы, иногда личное и семейное, а иногда просто шутим и смеёмся. Ну и, конечно, в личках и чатах летают мемы, приколы и разные обсуждения.
На старте моей работы мы с командами практиковали и живое общение — вместе выезжали в какой-то город и общались там по работе и неформально. Практика показала, что даже одна встреча — серьёзный шаг к сближению, люди начинают общаться дружелюбнее и свободнее.
Команды на встречах в Сочи и Красноярске
Недавно ввели практику общих всекомандных встреч по пятницам. Приходит кто хочет, перекличку не ведём. Обсуждаем рабочие вопросы и вопросы менеджмента, в которых инженеры часто могут подкинуть кучу интересных идей.
Самое главное всегда помнить, что все коллеги — личности. И если вы хотите, чтобы их работа была интереснее, приятнее и кайфовее, то без разнообразия подходов вам не обойтись — унифицировать всё никак не получится.
На квартирнике любой участник мог задать спикерам вопросы. В будущем мы планируем проводить ещё такие мероприятия — чтобы их не пропустить, подписывайтесь на телеграм-канал Southbridge. В нём мы собираем анонсы мероприятий и другую полезную информацию для девопс-инженеров.
