Хабрахабр

Мотивация, делегирование и автоматизация: рецепт создания суперкоманды

Знакомьтесь, это Дима. Он тимлид и отвечает за техдолг и код-ревью, за планирование и технические процессы, за выполнение разработчиками задач в срок — мотивирует, нанимает и, если надо, увольняет. Дима хочет работать только над важными задачами, но работает над миллионом самых разных, постоянно думает о работе и не высыпается. У него все горит: сроки, задачи, время и самооценка. Дима в аду.

Для Алексея Катаева (deusdeorum) — точно. Знакомая ситуация? Сейчас Алексей работает в Skyeng и как-то раз ему удалось сделать из команды суперкоманду — лучшую в компании. Алексей больше 15 лет занимается веб-разработкой как backend, frontend, fullstack-разработчик и тимлид. Как он это делает, в расшифровке доклада, который участники TeamLead Conf 2019 назвали лучшим на конференции. И с тех пор Алексей занимается тем, что создает в Skyeng суперкоманды на постоянной основе.

Рекомендуем посмотреть видео, если есть время, — Алексей заряжает энтузиазмом к переменам. А статья лучше подходит, чтобы просмотреть основные тезисы задуматься о чем-то, что раньше всегда ускользало.
С Димой вы уже знакомы. Раньше он был хорошим разработчиком — брал каждый день по 3 задачи и делал их до конца — это ведь самое главное. Зеленая плашка рядом с Димой — это индикатор ада в его жизни.

Если вы считаете, что он становится тимлидом и ада становится чуть больше, то вы угадали. Что дальше происходит с Димой? Когда будет задача 1653? К Диме приходит продакт и говорит: «Пойдем планировать Q2! У нас скоро релиз!» И ада становится чуть больше.

Что у тебя с техническим долгом? А потом приходит CTO: «Нам нужно нанять еще одного разработчика. И вот еще опросник в Google Doc — заполни его, пожалуйста!» И ада стало еще больше.

Увеличь нам зарплату!» И Дима начинает гореть. Потом пришли разработчики: «Мы хотим расти!

С утра он идет в душ и думает о разработчике и продакте, и о том, что и кому он наобещал. Все приводит к тому, что Дима не высыпается. Задачи теряются — либо Дима о них забыл, либо они где-то далеко в бэклоге и не будут выполнены никогда.

Я больше не буду тимлидом! Локально это может привести к плохим последствиям, когда Дима скажет: «Всё! В итоге мы потеряем кучу денег или что-нибудь вовремя не зарелизим. Я просто хочу делать свои задачки, отстаньте от меня!» Или сорвет задачу, потому что их много, а Дима один — трудно держать фокус на всем.

В конце по традиции будут бонусы. Я расскажу, как убрать ад из жизни и создать суперкоманду.

Intro

Skyeng — это 17 команд разработки, каждая из которых работает над своим продуктом независимо. Чаще всего в команду, кроме разработчиков, входят, как минимум, продакт и тимлид.

Продакт ставит бизнес-цели — у него есть видение продукта, он отвечает за деньги, которые мы зарабатываем и тратим, и общается со всеми заказчиками и клиентами.

Он — технический лидер. Тимлид, то есть Дима, отвечает за техническую стратегию, технические решения, техдолг — за все техническое. У нас нет выделенной роли project, поэтому тимлид отвечает за планирование и все процессы: за то, что задачи выполняются нужными разработчиками и не зависают в статусах. Еще тимлид — это project manager. Тимлид — лидер и наставник, работает с людьми: нанимает и увольняет, развивает и общается, ведет за собой и мотивирует.

Я разделяю их на: Посмотрим на задачи, которые делает Дима.

  • важные задачи;
  • задачи, которые можно делегировать или автоматизировать, чтобы их выполнял кто-то другой, но нужно потратить на это время;
  • рутина — простые задачи, которые приходится выполнять обязательно.

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

Решение на поверхности

Избавляемся от всей рутины, делегируем все, что можно делегировать, автоматизируем все, что можно автоматизировать.

Да, вы сразу подумали, что надо все делегировать и автоматизировать, и наступит счастье. Дима тоже знает, что это надо делать, но почему-то это не работает. Возможно причина в том, что Дима работает 10 часов в день, а на выходных, когда его наконец никто не мучает в Slack, он доделывает важные задачи. На делегирование тоже нужно время — ведь всем нужно долго объяснять, что и как — лучше самому все сделать. Чтобы автоматизировать, тоже нужно время — надо писать какой-то код, а времени не хватает даже на создание репы.

Но есть другой путь, похожий, который я прошел. Это путь, который все знают, но никто не делает.

Избавляемся от рутины

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

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

Обращения и вопросы

Скорее всего, это будет работа с обращениями. По моему опыту, тимлиды тратят много времени, чтобы отвечать на вопросы разработчиков, продактов, CTO, заказчиков — Slack всегда переполнен сообщениями. Сейчас расскажу, как легко избавиться от этого шума.

Я создал канал #billing, сказал, что все вопросы туда, и поставил в статусе «Не отвечаю в личке». Когда я пришел в команду биллинга тимлидом, я сразу сказал, что не отвечаю ни на один вопрос.

Дежурных можно выбрать из числа разработчиков или QA. В Slack я заменил красную иконку, чтобы моя точка не горела никогда, и назначил дежурных — кто-то же должен отвечать людям в этом канале. Команде я тоже сказал не смотреть в этот канал — там ад, а мы просто работаем. Я составил для QA график и попросил отмечать нужных разработчиков, если дежурные не может ответить сам.

Потом я увидел, как пишут обращения люди:

Ничего не работает, ничего не платится! — Ааа!!! Мы все умрем! Деньги исчезли!

Потом мы быстро закодили бота, который пишет эти правила при входе в канал. Поэтому я написал правила, как писать обращения в саппорт.

Никто из команды не тратит на это время. Кстати, мы не пишем ботов сами. Это дешево и быстро. На это у нас выделены два человека в компании, а иногда мы заказываем работу у фрилансеров. Там нет никаких требований к качеству кода — этого бота с правилами мы заказали и получили за пару часов.

Да, кто-то обиделся, наверное, но зато можно делать другие дела. Итого: за час я избавился от траты кучи лишнего времени для ответов на вопросы.

Как еще улучшить это решение?

Попросите дежурных написать ответы на самые популярные вопросы и составить короткую инструкцию, чтобы не тратить время на ответ. Раздел FAQ.

Посмотрите на крутой саппорт, позаимствуйте идеи. Контроль качества. Я сделал контроль качества просто: сказал дежурному писать раз в неделю количество обращений, на сколько вопросов мы ответили, а сколько проблем не решили.

Потом мы интегрировали еще одного бота, который во всех каналах по эмоджи анализирует, обработано ли обращение, и постит такой же дайджест-канал аля SLA по обращениям.

Дима отказался отвечать на вопросы, переложил эту обязанность на плечи QA, написал правила обращения в саппорт, создал FAQ и контролирует качество работы поддержки — ада в жизни стало меньше.

Административные ассистенты

Как я уже говорил, можно отдавать задачи разработчикам, QA, ботам. Но когда нанимаешь крутых спецов в команду, платишь им кучу денег, то неудобно просить их делать ерунду типа переноса документов из одного Google Doc в другой, субтитров, растасовки файлов. И делаешь сам, что еще глупее.

Это внутренний YouDo, но с отличиями. Поэтому в Skyeng есть специальный отдел административных ассистентов.

  • Заранее подписанный NDA. У всех есть доступы во все корпоративные Google Doc, вам не придется тратить на это время.
  • Контроль качества. Есть специальный человек, который отвечает за качество работы ассистентов. Их долго нанимали, обучали и увольняли, если они плохо работали.
  • Чёткий регламент постановки задач административным ассистентам. В Trello есть формат карточки, который создается за одну минуту — вуаля! — простые задачи выполняются. Причем это доступно не только тимлидам, но и разработчикам. Любой может воспользоваться услугами административного ассистента.

Мы делегируем ассистентам много задач. Например, классификацию обращений — просмотреть тысячу обращений за год и разбить их по категориям. Мы пишем видео всех наших встреч: daily, meetups, ретроспективы, и кто-то должен расфасовать их по командам и по папкам. Теперь это делают ассистенты, и всегда можно посмотреть любую встречу за любой день.

Мы еще уменьшили количество рутины в жизни Димы за счет административных ассистентов, регламента их работы и контроля качества.

Джедайские техники

Потом Дима решил еще оптимизировать свой тайм-менеджмент и прочитал книгу Максима Дорофеева «Джедайские техники». Из книги Дима взял кучу лайфхаков. Он решил в конце каждого дня вести чек-лист: что делал сегодня, что сделал важного и что сделает лучше.

Почему? Дима ведет чек-лист и его вроде бы нужно анализировать в конце дня, но не получается. Потому что во вторник упал прод, Дима всю ночь его чинил, и теперь у него голова не работает.

Починка продакшена

Здесь все довольно тривиально. Используем автоэскалации — настраиваем специального бота. В Skyeng это OpsGenie, который звонит нам ночью, если сломался прод и заставляет починить. Но ведь мы как раз хотим уйти от этого и не вставать ночью!

Тимлид не должен просыпаться ночью. Поэтому мы создаем расписание дежурных и убираем себя из этого графика.

Дежурство настроено по эскалации: если разработчик не взял проблему, то бот будет звонить тимлиду. На следующий день тимлид разберется почему разработчик не встал. Но это будет бесполезно, если разработчик через 10 минут, как проснется, сам начнет звонить тимлиду.

Поэтому мы даем доступ всем дежурным ко всем диагностическим инструментам сразу: Kibana, Sentry, New relic, а также root-доступ к серверам, и пишем краткую документацию, как этим пользоваться, где смотреть и что чинить.

Мы пишем специальный документ «Panic doc» — что делать, если все сломалось. Правда, это не работает в команде биллинга — там слишком много денег, но во всех остальных командах присутствует. Когда ночью просыпаешься, все лежит, аллерты сыпятся и вообще не понимаешь, что делать, есть простой Google Doc на одну страницу, где по шагам расписано, как поступать в данной ситуации.

Теперь Дима выспался и может анализировать по записям, что он сделал важного за последние дни: 3 июня — ничего, 4 июня — ничего, 5 июня — ничего. Возвращаясь к чек-листу. Главное, быть честным с собой и не вписывать в чек-лист ерунду, которую делал 5 минут. Это классическая ситуация, у меня такое часто бывает.

Дима смотрит, что вообще он делал сегодня:

  • Утренний митинг.
  • Техническое ревью — так у нас называется техническое обсуждение задач.
  • 1:1 с Олегом.
  • Ретроспектива или кайдзен.

Весь день какие-то встречи!

Вы ждете, что я сейчас скажу: «А давай делегируем встречи!» Это решение «в лоб», которое мы рассмотрим на примере технического ревью.

Техническое ревью

Если Дима скажет: «Макс, ты завтра проводишь техническое ревью», то, скорее всего, оно не получится. Дима два года проводил технические ревью, он прочитал статьи, у него есть куча опыта — было бы странно это терять.

Весь свой опыт я постарался формализовать — написал документ, как я провожу технические ревью. Как я организую технические ревью в команде? Я написал основу, в которой были: Кстати, это мне помогло сформулировать некоторые вещи.

  • Ответ на вопрос, зачем вообще проводить техническое ревью.
  • Алгоритм по шагам.
  • Советы для ведущего, например, как не допустить холивара на встречах.
  • Шаблоны: для голосования, для задач, для расписания, чтобы все было в одном стиле, и человеку не приходилось бы писать все заново.
  • Примеры success story: задача была описана так, мы ее отревьюили, и стало так, как должно быть.

На документ я потратил 40 минут. Мой лайфхак, как быстро писать документы: накидал основу, показал всем тимлидам в компании и получил кучу комментариев. В результате в этой инструкции мы объединили опыт всего Skyeng, потому что было много интересных предложений.

Нельзя просто кинуть, как банкой тушенки, в человека этим документом: «Проводи техническое ревью по этому алгоритму!» Так не работает. Что дальше? Мы сделали расписание и начали проводить ревью по очереди. Я спросил, кто хочет проводить техническое ревью — оказалось, вся команда!

Тимлид должен быть включен, смотреть, как все происходит и прокачивать себя тоже. Здесь важно не исключать себя из процесса, потому что невозможно хорошо сделать то, что ты сам не делаешь идеально.

Я видел эту ошибку много раз, если ты сам не принимаешь участия и не делаешь на 10 из 10, то получится плохо.

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

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

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

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

Но Дима прочитал хайповую книгу Рэя Далио «Принципы» и решил, что нужно сформулировать технические принципы, которые помогут принимать решение без его участия — формализовать их.

Технические принципы

Мы собрались всей командой биллинга, я набросал основу этих принципов, мы долго обсуждали их, голосовали, улучшали. В итоге получился список из 12 принципов. Вот три из двенадцати: что для нас важно — качество кода или скорость разработки, можно ли аутсорсить нашу разработку и думаем ли мы о последствиях?

тветы команды биллинга показали, что биллинг за все хорошее и против всего плохого: мы всегда за качество, аутсорсить нельзя и думаем о последствиях.

Например, для команды платформы важна скорость — не то, чтобы они пишут плохой код, но важна скорость проверки гипотез. Но есть команды в компании, где ответы на эти вопросы другие. Последствия тоже важны, как и биллингу, потому что если платформа лежит — финансовые потери огромны. Аутсорсить не только можно, но и нужно — они действительно аутсорсят свой продукт.

Но есть десятки других команд, которые не думают о последствиях, и это нормально для их продуктов.

В каждой команде должны быть свои принципы, которые зависят от продукта и команды.

Принципы работы

Также мы сформулировали принципы работы и зафиксировали их на бумаге. Юваль Ной Харари в «Homo Deus. Краткая история завтра» писал, что мысли обладают особой магией, когда они записаны, а не просто произнесены. Поэтому мы записали то, что для нас важно.

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

Когда я подводил итоги, то посчитал среднеквадратичное отклонение по голосованию и вывел самые противоречивые принципы, где мы не приходим к общему мнению.

  • Личная жизнь важнее, чем Skyeng. Люди поделились поровну на тех, для кого личная жизнь важнее, и тех, для кого — компания.
  • Домашнее дома, рабочее — на работе. Мы не «оффтопим»!

Слава богу у нас не демократия и работает принцип принятия принципов: «тимлид может выбирать принципы». Поэтому первый пункт вычеркнули, а второй оставили.

Дима разобрался с техническим ревью, с техническими и принципами работы и не участвует во всех встречах.

Остались только те, в которых приходится участвовать, потому что там рассматриваются действительно сложные или неописанные кейсы. Но тогда и принципы тоже можно дополнить.

Пушер

Приходит продакт и мучает Диму — от этого-то мы не избавились.

Задача Димы — не отвечать быстро на все эти вопросы и идти мучать разработчиков по цепочке, а построить механизм, где задачи решаются сами и сами улетают в прод.

Я фанат Kanban, потому что он как раз позволяет это сделать. На мой взгляд, конвейер выглядит так: есть колонки, мы пушим задачи.

Бот пропушивает задачи из колонки в колонку и каждое утро пишет: «Ты не заревьюил, ты не зарелизил.» Все уже слышали о боте Арсении.

Например: «Жду ответа Алексея из команды инфраструктуры», а Алексей вообще не знает, что задача его ждет. Я увидел, что это работает не всегда, потому что некоторые задачи неделями висят в колонке ожидания. И Арсений тоже не знает, что Алексей не знает.

Я был у них в гостях, где мне рассказали, что у них есть человек, который каждое утро пропушивает задачи. Поэтому я ввел роль пушера, которую подсмотрел из 2ГИС. Он смотрит на доску и спрашивает, можно ли это сделать быстрее, можно ли сейчас это как-то протолкнуть?

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

Каждую неделю мы его меняем. Дежурный свежим утренним взглядом смотрит на доску и пропушивает задачи. Роль пушера тоже может выполнять не тимлид, ее вполне можно распределить.

Kanban + Demo

Вы сделали рабочий механизм: есть Kanban-доска, все задачи прозрачны, но их 40 штук. Продакту лень на это смотреть, ему интересно, когда у него будут безакцептные платежи.

Мы перенесли идею в Kanban, и теперь каждую пятницу проводим встречу, на которой человек 7 минут рассказывает, что он сделал. В SCRUM есть Demo day —это что-то похожее на спринт-demo. Причем нельзя говорить, что чинил продакшен или настраивал окружение — то, что мы говорим на ежедневных митингах, а только, какие задачи из плана действительно зарелизились.

Чтобы мне не приходилось напоминать людям это делать, я сделал шаблон презентации, на котором крупно написано:

На 99% выполненное — не сделано.

Если на фоне этого шаблона располагать свои задачи — невозможно вставить туда какую-то ерунду.

В этом же шаблоне есть слайд «Что я сделаю на следующей неделе», который должен быть в следующей презентации для сравнения между обещанным и реально выполненным.

Так мы распределили часть задач тимлида.

Новая схема

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

Раньше мы всегда делали так. В грубом приближении флоу разработки в Skyeng выглядят так: цель — план — проблемы — решения — технические решения.


Продакт и тимлид ставят цель на квартал, сами придумывают оптимальный план её достижения и красиво презентуют план команде.

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

Но недавно в одной команде мы попробовали отойти от стандарта, что, как мне кажется, работает интереснее. Схема работает, мы ее долго использовали.

А вот дальше схема меняется. Продакт отвечает за бизнес и ставит цель: «Наша цель — увеличить конверсию в 2 раза» или «Уменьшить отказы платежных систем на 10%».

Каждой подкоманде дали свою цель и предложили подумать самим, как ее достичь. Мы поделили команду на маленькие проектные подкоманды. Тимлид и продакт теперь просто консультанты.

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

Когда не кто-то тебе сказал: «Вот план, он сработает», а ты сам придумал решение, ты отвечаешь за результат и даешь своего рода обещание, то уже не можешь сказать, что это вообще нельзя сделать, если сам презентовал команде свой план 3 месяца назад. Я реализовал эту схему, потому что думаю, что так можно увеличить мотивацию.

Хотя какая-то часть рутинной работы осталась, но он может использовать больше времени на более важные вещи. Так мы избавили тимлида почти от всей рутины, распределив все, что можно.

Важные функции тимлида

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

Вот наш продукт, вот наши цели, вот наша культура! — Ребята, мы фигачим!

Если тимлид тухлый, то и команда такая же. Так мы передаем людям свою энергию, культуру и заряд. Примеры я видел много раз.

Эти функции делегировать дорого и сложно. Найм и увольнение. Это важный рычаг, который у него есть, чтобы влиять на производительность и команду. Тимлид — единственный, кто видит всю команду целиком.

Так тимлид поддерживает обратную связь со своей командой. 1:1, как двустороннее средство связи. По нему тимлид выуживает проблемы из разработки. Он уже не так погружен во все процессы, и у него должен быть канал обратной связи.

Классные зрелые команды сами могут вносить изменения на кайдзен-встречах. Революционные изменения. Они сфокусированы на своих задачах и проектах, и не должны тратить на это время. Но разработчики не видят всю картинку целиком. Тимлид на то и нужен, чтобы придумать нечто невероятное.

— Давайте разделим команду на две части, или донаймем еще 10 человек, или перепишем бэкенд с PHP на Go.

Такие вещи не посетят голову обычного разработчика.

Мы помогли ему избавиться от огня. Вернемся к Диме, у которого изначально все горело. Сейчас Дима оптимизировал свое время, и его стало хватать на важные задачи.

По моему опыту — минимум год уйдет, чтобы построить эти процессы. Сразу оговорюсь — я рассказал о своем опыте построения суперкоманды в одной статье, но невозможно это сделать так же быстро — это не неделя, не две и не три. Вы не можете сразу сказать: «Завтра проводим стендап, я больше ничего не делаю — делайте все сами!» Рутина все равно будет, нужно долго анализировать вашу ситуацию и потихоньку прививать команде ответственность.

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

Можно ездить по конференциям и рассказывать об успехах. Теперь поговорим о том, чем Диме занять освободившееся время. Но я сторонник того, что все время нужно инвестировать в те самые важные вещи — апгрейдить команду.

Основной принцип — мы должны заниматься не тушением пожаров и не фиксом конкретных проблем, а работать над механизмом.

Механизм тимлида — это его команда. Инвестируйте в механизм, дирижируйте командой как оркестром и улучшайте ее.

Бонусы

Всего их четыре. Принципы. Это 12 наших технических принципов и 12 принципов работы. Конечно, они вам не подойдут, но будет от чего отталкиваться. Книгу тоже советую прочитать, но она очень толстая, а тут маленький файлик. Выстраданный алгоритм технического ревью — то, как мы проводим технические обсуждения. Он тоже может пригодиться. Шаблон демо-дня и правила обращений в канал. Возможно, вам что-то пригодится для организации поддержки.

Еще Алексей ведет telegram-канал Тимлид Леонид, в котором собирает полезные материалы и делится своими тимлидскими наблюдениями. Хотите получить бонусы к докладу — напишите Алексею в telegram (@ax8080) или в Facebook.

Ищем новых спикеров, выбираем актуальные вопросы со знакомыми экспертами. А мы тем временем уже готовимся к следующей TeamLead Conf — в Санкт-Петербурге 23–24 сентября. Вот примерный список тем, которым мы хотим уделить внимание в программе питерской конференции:

  • Процессы, планирование, управление.
  • Персональная работа с сотрудником.
  • Выстраивание команды и внутренних отношений.
  • Взаимодействие со стейкхолдерами.
  • Личностный рост.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть