что такое первая линия технической поддержки
Три линии технической поддержки
Классическая структура технической поддержки информационных бизнес-систем предполагает наличие трёх основных линий работы, последовательно решающих поступающие сервисные запросы.
Первая линия – Help Desk
Предназначена для приёма, обработки и первоначального анализа запросов конечных пользователей, а также решения общих и наиболее простых либо типовых вопросов использования ИС в рамках эксплуатации.
Поддержка на второй линии – администрирование
Осуществляется подготовленными и обученными бизнес- и системным администраторами ИС, администратором БД и системным администратором на уровне аппаратно-программной платформы ИС. Данный уровень решает, в основном, задачи управления доступом и несложной штатной настройки опций/параметров системы, её регламентного технического обслуживания и мониторинга ключевых рабочих показателей. Он не предполагает изменения или добавления функционала и интеграции, а также выполнения сложных настроек.
Третья линия – экспертная поддержка
Осуществляется специалистами высокого (экспертного) уровня знаний о внутренней структуре информационной бизнес-системы, принципах её работы, применяемых технологиях и конкретных программно-технических элементах, с помощью которых реализуются возможности системы по сбору, обработке и представлению информации для бизнеса. Именно такой уровень компетенции позволяет квалифицированно выполнять сложные настройки и вносить при необходимости существенные изменения в работу компонентов ИС (вплоть до блоков программного кода) без риска нанесения вреда её работоспособности.
Четыре линии техподдержки
Служба технической поддержки условно делится на уровни. Принято считать, что существует четыре линии.
Содержание
Первая линия техподдержки
Консультирует пользователей по функционалу устройств и программ. Решает не сложные технические задачи, часто путём удалённого подключения.
Задачи:
Кроме того, в задачи первой линии техподдержки входит обеспечение психологического комфорта пользователя. То есть, специалист берет на себя функцию громоотвода, в случаях, когда клиент эмоционально реагирует на сложности в работе с продуктом. После разговора градус напряжения клиента спадает, появляется уверенность, что проблема будет решена, специалисты заинтересованы помочь, понятен алгоритм дальнейших действий.
Первая линия техподдержки должна обладать минимальным набором знаний и навыков, необходимых для решения стандартных пользовательских задач.
Кроме того, первая линия отвечает за организацию таких процессов, как, например, выезд специалиста или замена оборудования, в случаях, когда такая потребность очевидна.
Вторая линия техподдержки
Решает технические вопросы, требующие глубоких знаний, специальных доступов.
Специалисты обязаны в совершенстве знать, как работает продукт.
Данные специалисты также могут удалённо подключаться к пользователям, но кроме того, обладают широкими правами доступа в специализированные системы, могут вносить правки на уровне кода.
Третья линия техподдержки
Исправляет серьёзные программные ошибки, выявляет уязвимые места, информирует разработку о необходимых доработках.
Четвертая линия техподдержки
Отвечает за доработку продукта, как самостоятельно, так и с привлечением сторонних ресурсов, например, поставщиков.
Кроме того, третья и четвертая линии могут быть отделом разработки и находиться на стороне заказчика.
Тем не менее, независимо от того, разделена ли служба формально на четыре уровня, все они так или иначе существуют и работа по поддержке пользователей затрагивает их все.
ITSSupport может осуществлять поддержку с первой по третью линию, а также тесное взаимодействие со службой разработки. Мы готовы организовать службу технической поддержки в зависимости от типа продукта и структуры вашей компании.
Первая линия
Первая линия — это элемент структуры службы технической поддержки поставщика информационных услуг, цель которого — идентификация клиента и его проблемы для дальнейшего ее логгирования.
Первоочередной задачей персонала первой линии является:
К структурному образованию — первая линия поддержки пользователей — часто применяются термины «фильтр» или «воронка», так как именно на этом уровне происходит разделение потока обращений клиентов на проблемы, имеющие простой характер и решения, и задачи, требующие делегирования на более квалифицированный, узкоспециальный уровень технической поддержки.
Практика показывает, что около 70–80% обращений решаются именно на первой линии поддержки пользователей.
В зависимости от квалификации персонала первой линии и установленных правилами полномочий и обязанностей, структура и перечень предоставленных услуг может иметь несколько вариантов:
Несмотря на то, что в иерархии любой службы технической поддержки первая линия считается наименее квалифицированной, важно не забывать, что именно персонал этого структурного образования является, по сути, лицом компании.
Именно специалисты первой линии ведут диалог с клиентом, и от их личных и профессиональных качеств и навыков зависит общее впечатление людей о качестве услуг или продуктов компании.
Наиболее грамотным решением для организации первой линии поддержки в крупной компании будет заключение договор ИТ-аутсорсинга с независимым поставщиком услуг, специализирующимся на диспетчеризации и администрировании и имеющем подтвержденный эффективный опыт в этой сфере.
У вас похожая задача? Оставьте заявку, и наши специалисты свяжутся с вами в ближайшее время и подробно проконсультируют.
Три линии техподдержки
Три линии техподдержки
Классическая структура технической поддержки информационных
бизнес-систем предполагает наличие трёх основных линий работы,
последовательно решающих поступающие сервисные запросы.
Схема сервисного обслуживания
Источник: «Техносерв Консалтинг», 2011
Первая линия – Help Desk – предназначена для приёма, обработки и
первоначального анализа запросов конечных пользователей, а также решения
общих и наиболее простых либо типовых вопросов использования ИС в
рамках эксплуатации.
Поддержка на второй линии – администрирование – осуществляется
подготовленными и обученными бизнес- и системным администраторами ИС,
администратором БД и системным администратором на уровне
аппаратно-программной платформы ИС. Данный уровень решает, в основном,
задачи управления доступом и несложной штатной настройки
опций/параметров системы, её регламентного технического обслуживания и
мониторинга ключевых рабочих показателей. Он не предполагает изменения
или добавления функционала и интеграции, а также выполнения сложных
настроек.
Третья линия – экспертная поддержка – осуществляется
специалистами высокого (экспертного) уровня знаний о внутренней
структуре информационной бизнес-системы, принципах её работы,
применяемых технологиях и конкретных программно-технических элементах, с
помощью которых реализуются возможности системы по сбору, обработке и
представлению информации для бизнеса. Именно такой уровень компетенции
позволяет квалифицированно выполнять сложные настройки и вносить при
необходимости существенные изменения в работу компонентов ИС (вплоть до
блоков программного кода) без риска нанесения вреда её
работоспособности.
Классическая структура технической поддержки информационных бизнес-систем предполагает наличие трёх основных линий работы, последовательно решающих поступающие сервисные запросы.
Схема сервисного обслуживания
Источник: «Техносерв Консалтинг», 2011
Первая линия – Help Desk – предназначена для приёма, обработки и первоначального анализа запросов конечных пользователей, а также решения общих и наиболее простых либо типовых вопросов использования ИС в рамках эксплуатации.
Поддержка на второй линии – администрирование – осуществляется подготовленными и обученными бизнес- и системным администраторами ИС, администратором БД и системным администратором на уровне аппаратно-программной платформы ИС. Данный уровень решает, в основном, задачи управления доступом и несложной штатной настройки опций/параметров системы, её регламентного технического обслуживания и мониторинга ключевых рабочих показателей. Он не предполагает изменения или добавления функционала и интеграции, а также выполнения сложных настроек.
Третья линия – экспертная поддержка – осуществляется специалистами высокого (экспертного) уровня знаний о внутренней структуре информационной бизнес-системы, принципах её работы, применяемых технологиях и конкретных программно-технических элементах, с помощью которых реализуются возможности системы по сбору, обработке и представлению информации для бизнеса. Именно такой уровень компетенции позволяет квалифицированно выполнять сложные настройки и вносить при необходимости существенные изменения в работу компонентов ИС (вплоть до блоков программного кода) без риска нанесения вреда её работоспособности.
Вопрос о том, где и какими силами должны строиться две первые линии поддержки, давно и весьма разумно решён и относится либо к зоне ответственности самого заказчика (если мы говорим о крупных организациях с хорошо развитым внутренним ИТ-департаментом), либо частично или полностью передаётся на аутсорсинг сторонней специализированной организации. Последний вариант более актуален для заказчиков из сегмента СМБ.
Наковали кадров: как первая линия техподдержки стала одним из главных каналов онбординга
Привет! Я Илья Тананаев. Руковожу отделом первой линии техподдержки в ITSumma. И хочу поделиться опытом, как из поиска решения проблемы пропущенных чатиков с клиентами мы построили кузницу кадров. Успешно успевая при этом обрабатывать 3k+ клиентских обращений в сутки.
Итак, пару лет назад мы столкнулись с обычной проблемой: админы техподдержки оказались не настолько мультизадачными, чтобы успевать тушить все пожары, решать текущие проблемы и при этом следить за миллионом чатиков с клиентами.
Придумали простое и утилитарное решение — поставить между высококвалифицированными админами и клиентами первую линию поддержки, которая взяла бы на себя относительно простую работу по уточнению запросов. Но дальше случилось так, что бонусом к изначальной задаче мы открыли отличный способ развития компании и путь обучения недавно пришедших в IT специалистов.
И в этой статье расскажу, что из нашего опыта вы можете применить у себя в любой компании, чтобы справиться с дефицитом кадров.
С чего всё началось
ITSumma начиналась с того, что мы помогали сайтам выдерживать нагрузки и не падать при любых обстоятельствах. Сейчас, спустя 13 лет после основания компании, техподдержка — уже далеко не единственное направление нашей работы, но по-прежнему существенное. У нас большой отдел эксплуатации, который следит за инфраструктурой клиентов и реагирует на инциденты 24/7 с SLA в 15 минут.
Когда клиентов было не очень много, дежурные админы сами реагировали не только на алерты мониторинга, но и на все обращения клиентов, включая телефонные звонки. В маленькой команде это кажется оптимальным вариантом — зачем заводить сломанный телефон, если исполнитель сам может принять задачу и лучше, чем кто бы то ни было, уточнить детали. Но постепенно компания росла, клиентов становилось больше. и в 2018 году система стала давать сбои.
С ростом числа клиентов дежурным админам стало слишком тяжело одновременно решать свои обычные рабочие задачи и отвечать на запросы клиентов; начали появляться потерянные или неотвеченные клиентские чатики. Мы поняли, что пора разделить контроль за отслеживанием входящих запросов и задач и, собственно, их исполнение.
Зачастую любой контроль ложится на плечи руководителя, но такая рутина, как принять задачу у клиента и передать её дальше — не лучшее использование времени и сил менеджера. Эффективнее потратить их на более важные и подходящие по скиллам дела, а рутину делегировать отдельным специальным людям.
Так появилась первая линия поддержки.Вначале она состояла всего из. двух человек. Они должны были звонить и принимать звонки от клиентов, следить за всеми входящими обращениями и облекать их в задачи для админов. Плюс, что-то совсем простое делать сами и потихоньку обучаться новому.
Итерации решения
Сначала первая линия не работала 24/7, да и в принципе, не сразу взяла на себя работу с вообще всеми клиентами. Тем не менее, когда мы вышли на две стабильные смены с 7 утра по Москве (с 12 по Иркутску — наш стандартный режим для большинства сотрудников) и с 11 по Москве в будние дни, это уже сильно сняло нагрузку с админов и помогло упорядочить работу. Мы поняли, что первая линия действительно полезна, а от админов круглосуточной техподдержки поступил запрос на работу первой линии не только в дневное время.
В 2019-м мы ввели еще смены для подстраховки на время пиковой нагрузки — по будням с 10 утра по Москве. А позже, проанализировав ситуацию, решили, что нужно переводить первую линию на 24/7 — чтобы помогать техподдержке всё время.
Итоги первого года работы первой линии:
Избавили квалифицированных админов от рутины по звонкам и приёму обращений клиентов, сделав их работу более упорядоченной.
Ответственным за SLA стал не только отдел эксплуатации, но и первая линия поддержки.
Получили более надежный процесс обслуживания клиентов, в котором задачи не теряются, а выполняются вовремя.
Сотрудники первой линии начали не просто передавать задачи и создавать таски, но и самостоятельно выполнять некоторые из них, например, обновлять сертификаты. Чем помогли админам эффективнее использовать свои ресурсы.
Высвободили часть ценного времени ведущих админов, тем самым получив ресурс для роста компании.
Постепенно на первую линии перешло реагирование на некоторые алерты мониторинга, обновление сертификатов, редактирование конфигурации nginx и ssl certbot. Например, если у клиента в ночное время приходил алерт по продовой площадке и не резолвился, то нужно было оповестить клиента в течении 15 мин согласно SLA.
На картинке число обращений по одному из проектов, которое ежемесячно обрабатывают самостоятельно бойцы первой линии. Понятно, что сложность у них разная, но объёмы всё равно можно представить. Дополнительно мы строим еще кучу графиков в Redash по дням недели, по часам и т.д., чтобы распределять дежурства, соответствующие нагрузке.
Расписание для людей
Проблема приема обращений решилась, но с учётом перехода на круглосуточный режим надо было утрясти расписание работы сотрудников. Если смены просто зафиксировать, условно “два через два”, то в разные месяцы получится разное количество смен — и люди будут то перерабатывать, то не дорабатывать (по ТК должно быть определенное количество часов за период).
Казалось бы, задача сменного расписания довольно типовая и уже точно должно быть выработано нормальное решение. Но нам все равно пришлось попробовать разные варианты на собственном опыте, чтобы в итоге не страдало здоровье наших коллег и никто не выгорал.
Мы попробовали разные варианты: 8- и 12-часовые смены, только дневные и только ночные, вперемешку и т.д. Вот что получилось:
Пробовали чередовать 8-часовые вечерние и ночные смены, чтобы разброс был не такой большой, — ритм нарушается все равно. В итоге люди не могут отоспаться и отдохнуть и просто неожиданно заболевают.
Отдельно ночные и дневные дежурные — вариант, которые устроил больше всего.
Дополнительно по мере развития отдела появились еще 8-ми часовые смены на дневное пиковое время — в это время нагрузка самая большая, и 12 часов подряд её выдерживать тяжело. Сейчас у специалиста первой линии есть не только возможность выбрать подходящий ему график, но и расставить приоритеты для возможной ротации, как по времени, так и по отделам. Сотрудник оценивает по 5-балльной шкале удобство возможного времени работы, а также оставляет комментарии о том, какие у него предпочтения, либо внерабочая активность.
Развитие специалистов первой линии поддержки
Как я уже сказал, изначально первая линия поддержки появилась, чтобы переложить часть нагрузки с плеч высококвалифицированных специалистов на менее опытных коллег. Поэтому в целом мы не выставляем высоких требований к навыкам сотрудника первой линии: важно понимание работы веба и основ сервисов, ну и желание развиваться в администрировании. Но на разных этапах и в зависимости от потока кандидатов мы берём более подготовленных людей или акцентируем внимание на софт-скиллах.
Однако быстро выяснилось, что чем опытнее специалист первой линии, тем больше времени экономится на следующих этапах и быстрее решаются проблемы клиентов. Так в наших глазах (и в глазах наших сотрудников) работа в поддержке превратилась из обычной рутинной в трамплин для развития в IT. Поработав на передовой, ребята набираются опыта, растут как специалисты и переходят в другие отделы на более высокие должности.
Но это нам теперь понятно, что развитие выгодно и сотрудникам, и нам, как компании. А началось все очень прозаично и прагматично.
Таско-дни или командировки в другие отделы
На какой-то из переходных стадий формирования режима работы для комфортной работы нам не хватало по сути дела полставки. Мы взяли в штат нового сотрудника на полную ставку, а суммарное “лишнее” время решили попытаться использовать с пользой.
Договорились с соседними отделами мониторинга и документации, что будем отправлять к ним людей на таско-дни — в эти один-три дня сотрудники первой линии будут полностью заниматься задачами по документации или мониторингу, как будто они работают в этих отделах.
В этом есть смысл даже в том случае, если сотрудник из первой лини приходит по сути в роли стажера и за пару дней не успевает глубоко вникнуть в новую область знаний.
Дело в том, что сотрудники нашей первой линии создают задачи для мониторинга, но им не всегда понятно, почему регламент описания задачи именно такой, почему должны быть прописаны определенные параметры сервера, какой процесс проходит задача дальше и т.д. А когда человек попадает на ту сторону и получает на исполнение составленную его же коллегой задачу, в которой не хватает информации, он сразу начинает понимать, почему и какие нюансы надо уточнять. Это помогает впоследствии гораздо лучше выполнять регулярную работу в первой линии — становится больше осознанности.
Эксперимент с таско-днями был удачным. Он наглядно показал пользу от выбранной тактики — помогать развиваться нашим сотрудникам. Поэтому теперь мы всегда закладываем резерв под подобную практику, но сейчас это не несколько дней для нескольких человек, а полноценные две недели или, в последнее время, месяц для одного сотрудника первой линии, которые он работает в другом отделе. Мы называем это командировками.
Наши командировки похожи на стажировку, только лучше. За время месячной командировки человек успевает не только повысить свою квалификацию, но и принести пользу отделу, к которому он прикомандирован. В отличие от стажировки, на которую приходят совсем с нуля, сотрудник первой линии уже знаком с процессами в компании и быстрее входит в курс дела. У него есть мотивация на рост. И возможность понять, что ему ближе и как он хочет дальше развиваться.
К тому же, есть пространство для манёвра. По результатам командировки, если навыков еще недостаточно, можно спокойно вернуться в первую линию и там подрасти в выбранном направлении — во время относительно малой загруженности браться за задачи для саморазвития под контролем более опытных коллег. В случае же испытательного срока или стажировки приходится расставаться, если отведенного времени не хватило.
На текущий момент командировка — это привилегия. Надо отработать хотя бы несколько месяцев в первой линии и заслужить доверие. Кандидатам мы подробно объясняем, чем занимаются отделы, с чем придется столкнуться, работая там, и какие навыки можно получить в результате. А потом спрашиваем, в чем сотруднику интереснее себя попробовать, и, учитывая его скиллы и потребности отделов, отправляем в командировку.
Направления для командирования сотрудников первой линии поддержки такие:
дежурства второй линии;
В некоторых случаях это самый короткий и эффективный путь для расширения отделов. Например, командировки сильно помогают расти отделу документации. Часто люди не понимают, чем занимаются техписы и что там действительно необходимы технические навыки — у нас в отделе документации пользуются консолью, сами уточняют детали в логах и собирают схемы с систем мониторинга.
Это нас возвращает к тому, зачем понадобилось автоматизировать обучение. Компания быстро развивается, есть много возможностей для роста, и в итоге достаточно часто на первую линию нужны новички (не путать с текучкой, её у нас как раз нет). Так настройка системы обучения и knowledge sharing превратились в приоритетные задачи.
Онбординг-курсы
В технической поддержке много составляющих, которые взаимодействуют со всеми системами: мониторингом, таск-трекером, вики и т.д. Специалисту на первой линии нужно хорошо ориентироваться в потоке и уметь быстро находить нужную информацию. Систематизация знаний и работа над документацией — необходимый этап.
Документирование нашей работы прошло довольно стандартный путь:
Понятно, что сначала документации как таковой не было — были разрозненные наброски.
На первой итерации по улучшению я выделил время и постарался её систематизировать — стало чуть лучше, но еще не достаточно.
Вторая итерация была результатом того, что у нас уже появилось свободные полставки, но мы еще не ввели таско-дни. Наша коллега несколько недель приводила в порядок документацию, после чего по этой документации новый сотрудник уже мог сам более-менее разобраться, что да как.
Третья итерация — не конечная точка, а непрерывная работа по улучшению. Мы собираем отзывы новичков, исправляем и расширяем то, где обнаруживаются недостаточно понятные места. Вообще фидбэк новичков очень полезен, а когда они еще и дописывают недостающую информацию, это вообще супер.
Однако, когда найм стал еще более активным, просто документации для онбординга стало не хватать. Документация, в любом случае, древовидная, и когда ты только погружаешься, разбираться в ней не очень удобно. Сразу трудно сориентироваться, что нужно запомнить в первую очередь, а что лучше изучить на примерах, когда уже столкнешься с этим в работе.
Еще несколько месяцев назад, чтобы ввести в курс нового коллегу, кому-то из менеджеров или более опытных сотрудников приходилось ртом рассказывать всё самое важное, знакомить с основными инструментами, сидеть рядом и показывать, что нужно сделать в каждом случае. Это два-три полных дня и еще пару недель регулярных индивидуальных консультаций — долго и трудозатратно.
Для автоматизации процесса онбординга подняли Moodle и сделали свои курсы. Они состоят из некоторой справочной информации, видеоуроков и тестов. У роликов есть временнЫе метки с описаниями, поэтому к такому материалу удобно возвращаться, если позже понадобится что-то уточнить.
Помимо видео, в Moodle удобно делать тестирование. Причем, тестирование нам нужно, не чтобы оценить сотрудника, а чтобы еще раз акцентировать внимание на самых критически важных моментах — как «вопросы для самопроверки».
При проверке скрипта на корректность перед запуском на какие критерии обращаем внимание?
1. block for commit.
3. PS/SQL file successfully completed.
5. set auto commit off.
В тест мы вынесли то, что, по нашему опыту, чаще оставалось не до конца понятным. Тестирование круто вскрывает нюансы и снижает число будущих косяков.
Пройти и курс, и тест можно пройти сколько угодно раз, это ни на что не влияет.
Можем ли мы изменять категорию задач вручную в созданной задаче? Если да, то где?
a. Можем, но аккуратно в Состояние.
c. Можем. В созданной задаче в правой колонке. Там, где Категория
d. Неее. Такого быть не может
Как видите, это не похоже на строгую сертификацию. Это просто еще один способ помочь новому сотруднику усвоить много информации в короткие сроки.
После доработки документации онбординг курсы — это лучшие инвестиции в развитие отдела.
Потратив один раз время и вложившись в автоматизацию стартового обучения, мы:
Сэкономили время опытных специалистов на онбординг новичков.
Уберегли главного наставника новичков от выгорания.
Сделали онбординг качественнее (и это, пожалуй, главное). Когда один и тот же человек пятый-десятый раз рассказывает одно и то же, он легко может что-то пропустить, потому что путается, что кому уже рассказывал. С автоматическими курсами такое не произойдет.
Результаты
Мы начинали первую линии поддержки с совершенно утилитарной целью и не ожидали, что построим службу, которая приносит компании гора-а-а-аздо больше пользы, чем “зафиксировать обращение, передать на решение”.
Для сотрудников это хорошая возможность для старта карьеры: начальные требования очень лояльные и есть, куда расти. ITSumma занимается разными направлениями, так что новичок у нас может попробовать себя в разных областях и выбрать, что ему по душе. При этом мы расширяемся, поэтому способные люди точно не останутся без новых вызовов и повышения.
Для компании выращивать сотрудников и переводить их из первой линии в другие отделы удобно по многим причинам. Мы уже знаем, что хорошо подходим друг другу по “культурному коду”, знаем сильные и слабые стороны, мы вместе выбираем траекторию развития и уверены в мотивации.
Сейчас в первой линии работает 13 человек, из них 4-5 постоянно находятся в командировках в бэк-отделах, получают новые знания и повышают имеющиеся. За время этого не очень-то длинного эксперимента уже 9 человек пошли на повышение. Например, первая линии поддержки была отправной точкой для тимлида отдела дежурств и тимлида отдела документации, специалистов в отделах документации, мониторинга, бэкапов и аккаунтинга.
И да, у нас больше нет проблем с пропущенными обращениями или невыполненными вовремя задачами от клиентов. Админы и дежурные не отвлекаются на звонки, а расходуют свои скиллы для решения сложных инфраструктурных задач.
Takeaways
В условиях дефицита опытных специалистов на рынке IT-компании в любом случае вынуждены выращивать кадры. Если этот процесс у вас еще не отлажен, но в вашей компании больше 20 человек, найдите участок, в котором можно приносить пользу с малыми знаниями, и сделайте из этого собственную кузницу.
Первая линия поддержки — это просто пример. У любой IT-компании есть что-то, что могут делать новички: ручное тестирование, простая верстка, документация, скриптованное бэкапирование или обновление. Всегда можно найти подходящую “песочницу”.
Чтобы выращивание специалистов приносило пользу, а не боль, придется вложиться в документацию и онбординг. Но документация и налаженный процесс информирования об обновлениях нужен в любом случае — и для новых коллег с опытом, и для старых после отпуска. А порядок в онбординге и создание материалы для новых сотрудников поможет вашей компании расти и развиваться, так что это — инвестиции в своё будущее.
Напоследок признаюсь, что были некоторые внутренние опасения, когда (уже больше года назад) мы перешли на удалённый режим работы и начали активно нанимать людей не из Иркутска, Москвы и Питера — то есть городов нашего оффлайнового присутствия на момент коронавирусного перелома. Но опасались зря: у нас уже работает достаточно людей из ранее непривычных часовых поясов, и вообще, вакансии в отделе практически постоянно есть. В общем, разница во времени — не помеха, если люди хотят работать, а мы хотим, чтобы они у нас работали.