Привет! Меня зовут Андрей Грачев, и я продакт-менеджер в СИБУРе.
У нас в СИБУРе регулярно происходят «остановочные ремонты». Это что-то вроде профилактики, планового обслуживания и ремонта, на время которого весь завод или часть его полностью останавливается. Такие ремонты необходимы для обеспечения бесперебойной работы предприятия в дальнейшем. Но, понятно, что в это время завод не зарабатывает деньги, поэтому важно сделать всё как можно быстрее. Для этого нужно оптимально спланировать и провести работы. Так появилась идея создать собственное мобильного приложение для остановочных ремонтов, которое сделало бы процесс управления работами более организованным, минимизировало бы потерю времени. Расскажем, как мы это сделали, что в итоге получилось и к чему мы стремимся теперь.
Для начала расскажу, что такое остановочный ремонт. Это комплекс мероприятий по ремонту большого количества оборудования завода, которые необходимо проводить в определённый период времени — например, раз в год, квартал или с другой периодичностью. На это время производство останавливается, на завод заезжает подрядчик, проводится ремонт всего, что нужно. Это может длиться неделю, несколько недель, на «Сибур-Химпроме», например, завод останавливался почти на месяц.
Такой масштабный ремонт практически всего оборудования на заводе можно представить как большой проект. У него есть подготовительные операции, когда завод постепенно снижает мощность и останавливается. Есть активная фаза, когда идет замена и обслуживание агрегатов, и фаза возобновления производства. За 10-11 месяцев до начала остановочного ремонта все ответственные лица начинают планировать эту процедуру, создаются заказ-наряды на те работы, которые необходимо провести. Таким образом, к началу работ накапливается большой пул задач, которые нужно выполнить в отведённый для ремонта срок. Эти задачи часто взаимосвязаны: не закончив одну, нельзя начать другую. Например, мы не можем отремонтировать что-то в насосе, потому что его надо сначала отключить, снять оборудование, которое препятствует разбору этого агрегата, а уже потом работать с насосом. Из этих взаимосвязей и выстраивается срок всего остановочного ремонта.
У остановочного ремонта есть «критический путь». Как правило, из года в год на каждом предприятии есть неизменные операции, без выполнения которых завод нельзя запустить. Получается, что критический путь — это самое длинное время, которое можно потратить на остановочный ремонт. Всё остальное планируется так, чтобы оно или соответствовало времени остановочного ремонта, или как минимум не удлиняло его. Значит, эти работы должны происходить параллельно.
Всё это до текущего времени делалось так: люди в SAP создают в течение года заказы, которые помечаются как требующие остановочного ремонта. Когда приходит время, все заказы из SAP выгружаются в так называемую «дефектную ведомость», исходя из которой механики разрабатывают график остановочного ремонта. Это сотни строк в Excel, из которых нужно потом понять перечень необходимых работ, сколько на них понадобится времени и людей, выстроить логику во времени: что за чем будет ремонтироваться. На всех предприятиях СИБУРа это делается практически одинаково — руками в Excel. Только на одном предприятии, «Сибур-Химпроме», научились это делать в сервисе для планирования Primavera. Для нас он крайне неудобен в плане интерфейса и пользовательских сценариев.
Конечно, мы смотрели в сторону и других сервисов — таких, как MS Project. Но их функционал либо был недостаточен для нас, либо на обучение нужно было бы потратить очень много времени и, соответственно, денег. Поэтому решили разрабатывать собственный продукт.
Когда мы начинали, картина в СИБУРе складывалась такая: все пытаются спланировать серьёзный проект в таблицах Excel. Всё это распечатывается, ставятся подписи заинтересованных лиц, утверждающих график. Дальше во время остановочного ремонта люди собираются на планёрки и группируются в штабы, где экселевский файл выводится на экран, и в нём ставятся проценты выполнения задач.
Такого рода многочисленные и регулярные собрания нужны, чтобы свести воедино и актуализировать информацию. Представитель подрядчика рассказывает, что сделано, какие есть проблемы, а представитель заказчика отмечает всё в бумажном документе. Затем другой человек собирает информацию с каждого ответственного, консолидирует её и готовит централизованный отчёт. Это всё сложно и долго, люди задерживаются на работе до ночи.
Мы подумали, что управление любыми проектами строится на базовых вещах: планировании процессов и прозрачности того, что происходит в каждый конкретный момент времени. Чтобы обеспечить прозрачность, необходимо во время ремонта давать системе актуальные данные о происходящем. Мы подробно изучили производственные процессы, поняли, как происходит остановочный ремонт, и предложили структуру, в которой можно вести график. Мы решили поначалу не ломать существующий процесс и не лезть в пользовательские сценарии людей. Кто привык планировать в экселе — пусть планирует. Кто научился в Primavera, тот пусть работает там.
Первоначально наш продукт представлял собой систему визуализации тех графиков, которые они делают. Мы разработали приложение на iOS, Android и браузерную web-версию. В сервис загружается график вместе с ответственными, исполнителями и контролёрами — три основные роли во время остановочного ремонта. Это важный момент, поэтому остановлюсь на нём подробнее и покажу, как всё работает на примере.
Есть задача отремонтировать насос.
У задачи есть исполнитель — это бригадир подрядной организации, которая ремонтирует какой-то конкретный объект.
Ответственный — отвечает за то, чтобы всё было подготовлено к ремонту, он должен сдать объект в ремонт и потом принять его, подтвердив, что подрядчик завершил работы в полном объеме и может приступать к другим задачам. Как правило, это делает механик установки.
Контролёры — это высший управляющий состав предприятия, люди, которые хотят постоянно видеть соответствие работ плану-графику.
У ответственных и исполнителей есть доступ как в приложение, так и в веб-версию. Исполнитель видит те задачи, которые на него назначены на сегодня, а также на весь остановочный ремонт. У исполнителя есть очерёдность этих задач. Он, приступая к работе, должен нажать соответствующую кнопку, внести в программу количество человек, которые работают над этой задачей. Руководству важно знать, соответствует ли количество людей, работающих над этой задачей, количеству, которое запланировали. Исполнитель нажимает кнопку — и работа пошла. Приложение следит за длительностью процесса. В случае, если дедлайн пройден, а исполнитель не нажал кнопку завершения работы, ответственному приходят оповещения о просрочке. Значит, ответственный идёт и смотрит, что произошло.
Если всё нормально и в установленное время исполнитель завершает работу, он нажимает кнопку «Внести отчёт» и пишет, что выполнил работу на 100%. Тогда ответственный также получает уведомление, что все сделано, нужно пойти и посмотреть результат. Так работает ролевая модель.
Люди могут не держать в голове всё, что происходит на вверенном им участке, они видят график на каждый день и получают уведомления о процессе.
Также мы предусмотрели возможность работы с задачами, которые длятся больше одного дня. Это функционирует так же, как и с небольшими задачами, только в конце каждого дня в программу нужно вносить отчёты: например, сегодня работа выполнена на 50%. Ответственный получает уведомление и должен проверить, соответствует ли эта информация действительности. Если нет — он отклоняет отчёт и заставляет исполнителя ставить другую цифру.
Что касается веб-версии, то функциональность её немного другая, она предназначена больше для контролёров — менеджмента предприятия. Мы поняли, что людям привычно воспринимать информацию о прогрессе по всем работам в диаграммах Ганта. Они видят план-факты, взаимосвязи, статистику по мобилизации человеческих ресурсов, скольких людей мы хотели видеть на заводе во время ремонта и сколько работает по факту. И, соответственно, по всем производственным установкам контролёр может посмотреть процесс выполнения работ, оперативно увидеть отставания от графика.
Всегда во время остановочного ремонта появляются скрытые дополнительные работы, которые нельзя игнорировать. Например, при разборе оборудования находится поломка в той части, которая в собранном состоянии агрегата не видна. Эти задачи тоже вносятся в график, принимается решение, что скрытые работы мы тоже выполняем во время остановочного ремонта. Всё заносится в программу. Если эта дополнительная работа влияет на длительность всего остановочного ремонта, то программа автоматически отодвинет все другие задачи на то время, которое нужно для выполнение этой скрытой работы. Так же и в обратном случае — если какие-то задачи выполняются быстрее, чем запланировано, график оптимизируется.
Для таких случаев мы с командой спроектировали серьёзную систему сообщений и пуш-уведомлений, чтобы предупредить людей, которые приступают к работе, что они могут сделать это раньше или позже. И здесь вскрылся интересный момент. Мы довольно серьёзно переборщили с этими уведомлениями.
Дело в том, что мы завели туда «график четвёртого уровня» — большой, подробный план всего остановочного ремонта. Для наших целей он оказался слишком подробным. Получилось, что пользователи получали уведомления о каждой мелочи, которая может быть незначительна для процесса в целом. Ведь когда человек работает без приложения, он не смотрит каждый день в график работ. Он просто знает: чтобы отремонтировать условный насос, нужно выполнить много операций (разобрать его, почистить, заменить агрегаты, собрать, проверить и так далее). И человеку, который проверяет, как работает подрядчик, не нужно контролировать прохождение каждого из этих этапов. Достаточно посмотреть на результат работы в целом и на соответствие заявленным срокам.
То есть, если переходить к уведомлениям, то контролер должен узнавать о двух событиях: начале ремонта и завершении ремонта. Поэтому мы на ходу корректировали приложение. Для начала просили изменить графики и укрупнить их. Затем отказались от некоторых мелких событий и стало всё работать ровнее, пользователя стали меньше отвлекать уведомлениями.
Когда мы доработали приложение, получился сервис, который позволяет постоянно иметь актуальную информацию по предприятию: что сейчас ремонтируется, на каком этапе процесс и когда срок сдачи. Это позволяет спланировать работы и подготовить график. По сути, эта система управления проектом остановочного ремонта — продвинутый таск-менеджер.
Изначально мы заявляли главной метрикой сокращение времени остановочного ремонта. Понятно, как оценить это в деньгах: ведь известно, сколько стоит час или день простоя производства. Поэтому мы ставили целью ускорить проведение остановочного ремонта. Сейчас мы видим, что важна и аналитика — оценка того, что происходит во время остановочного ремонта, до мелочей. Если мы будем логировать действия пользователя, как и когда он принял работу, какие комментарии написал, что пошло не так, как идут согласования, будем видеть образование скрытых дефектов, понимать, кто как работает — тогда можно проанализировать и понять многое о производственных процессах. Как раз для их оценки у нас есть «Функция эффективности производства». После каждого ремонта собирается определённый массив данных: сколько денег затрачено, сколько было запланировано, как быстро мы вышли из ремонта.
Конечно, мы предусматриваем дальнейшее развитие проекта. Пока это только первый шаг по сбору статистики по остановочным ремонтам. Мы хотим собрать достаточно данных, чтобы с ними можно было работать и делать больше выводов. Например, нам надо отремонтировать насос. Этим занимается X людей и это занимает Y времени. Соответственно, всё последующее планирование какого-либо ремонта может опираться уже на эту модель. Мы сможем планировать работы исходя из того, что уже есть подтвержденная данными аналитика, а значит — не завышать и не занижать ожидания по срокам.
Наше приложение может использоваться не только для производств. Это может быть управление капитальным строительством, любые другие области, где применяется аналогичный подход к планированию работ.
Над проектом работала группа людей как внутри СИБУРа, так и подрядчики. Разработка серверной части и фронт-енда полностью была на подрядчике, мы внутри команды занимались проектированием логики работы приложения и интерфейсом. В качестве консультантов привлекались менеджер остановочного ремонта, механик, который непосредственно работал над графиками, главный инженер, следящий за процессом, и директор предприятия.
На все про все (исследования, пилотирование, интерфейсы и разработку) ушло полгода.
В ближайших планах — несколько ключевых апдейтов. Пока есть проблемы с подсчётом физических объёмов в рамках какой-либо задачи, например, по заменённым арматурам. Нашим коллегам на предприятии важны не только относительные, но и абсолютные показатели: нужно понимать, насколько процентов выполнены работа, сколько арматур из условной 1000 уже были заменены. Сейчас в графике работ приложения это никак не учитывается. Будем думать, как это реализовать. Пока мы можем только сказать о прогрессе выполненных работ и проценте их выполнения, фиксировать ситуации по отставанию или опережению сроков.
Возможно (и такое понимание уже есть), весь процесс планирования остановочного ремонта будем переносить в наш проект. Возможно, при этом вся разработка переедет инхаус.
Будем рады видеть в команде новых коллег: владельцев продукта, продуктовых дизайнеров, разработчиков. Список актуальных вакансий по ссылке на hh.ru.
У нас в СИБУРе регулярно происходят «остановочные ремонты». Это что-то вроде профилактики, планового обслуживания и ремонта, на время которого весь завод или часть его полностью останавливается. Такие ремонты необходимы для обеспечения бесперебойной работы предприятия в дальнейшем. Но, понятно, что в это время завод не зарабатывает деньги, поэтому важно сделать всё как можно быстрее. Для этого нужно оптимально спланировать и провести работы. Так появилась идея создать собственное мобильного приложение для остановочных ремонтов, которое сделало бы процесс управления работами более организованным, минимизировало бы потерю времени. Расскажем, как мы это сделали, что в итоге получилось и к чему мы стремимся теперь.
Зачем всё это нужно?
Для начала расскажу, что такое остановочный ремонт. Это комплекс мероприятий по ремонту большого количества оборудования завода, которые необходимо проводить в определённый период времени — например, раз в год, квартал или с другой периодичностью. На это время производство останавливается, на завод заезжает подрядчик, проводится ремонт всего, что нужно. Это может длиться неделю, несколько недель, на «Сибур-Химпроме», например, завод останавливался почти на месяц.
Такой масштабный ремонт практически всего оборудования на заводе можно представить как большой проект. У него есть подготовительные операции, когда завод постепенно снижает мощность и останавливается. Есть активная фаза, когда идет замена и обслуживание агрегатов, и фаза возобновления производства. За 10-11 месяцев до начала остановочного ремонта все ответственные лица начинают планировать эту процедуру, создаются заказ-наряды на те работы, которые необходимо провести. Таким образом, к началу работ накапливается большой пул задач, которые нужно выполнить в отведённый для ремонта срок. Эти задачи часто взаимосвязаны: не закончив одну, нельзя начать другую. Например, мы не можем отремонтировать что-то в насосе, потому что его надо сначала отключить, снять оборудование, которое препятствует разбору этого агрегата, а уже потом работать с насосом. Из этих взаимосвязей и выстраивается срок всего остановочного ремонта.
У остановочного ремонта есть «критический путь». Как правило, из года в год на каждом предприятии есть неизменные операции, без выполнения которых завод нельзя запустить. Получается, что критический путь — это самое длинное время, которое можно потратить на остановочный ремонт. Всё остальное планируется так, чтобы оно или соответствовало времени остановочного ремонта, или как минимум не удлиняло его. Значит, эти работы должны происходить параллельно.
Как всё происходило раньше?
Всё это до текущего времени делалось так: люди в SAP создают в течение года заказы, которые помечаются как требующие остановочного ремонта. Когда приходит время, все заказы из SAP выгружаются в так называемую «дефектную ведомость», исходя из которой механики разрабатывают график остановочного ремонта. Это сотни строк в Excel, из которых нужно потом понять перечень необходимых работ, сколько на них понадобится времени и людей, выстроить логику во времени: что за чем будет ремонтироваться. На всех предприятиях СИБУРа это делается практически одинаково — руками в Excel. Только на одном предприятии, «Сибур-Химпроме», научились это делать в сервисе для планирования Primavera. Для нас он крайне неудобен в плане интерфейса и пользовательских сценариев.
Конечно, мы смотрели в сторону и других сервисов — таких, как MS Project. Но их функционал либо был недостаточен для нас, либо на обучение нужно было бы потратить очень много времени и, соответственно, денег. Поэтому решили разрабатывать собственный продукт.
Когда мы начинали, картина в СИБУРе складывалась такая: все пытаются спланировать серьёзный проект в таблицах Excel. Всё это распечатывается, ставятся подписи заинтересованных лиц, утверждающих график. Дальше во время остановочного ремонта люди собираются на планёрки и группируются в штабы, где экселевский файл выводится на экран, и в нём ставятся проценты выполнения задач.
Такого рода многочисленные и регулярные собрания нужны, чтобы свести воедино и актуализировать информацию. Представитель подрядчика рассказывает, что сделано, какие есть проблемы, а представитель заказчика отмечает всё в бумажном документе. Затем другой человек собирает информацию с каждого ответственного, консолидирует её и готовит централизованный отчёт. Это всё сложно и долго, люди задерживаются на работе до ночи.
Первый прототип
Мы подумали, что управление любыми проектами строится на базовых вещах: планировании процессов и прозрачности того, что происходит в каждый конкретный момент времени. Чтобы обеспечить прозрачность, необходимо во время ремонта давать системе актуальные данные о происходящем. Мы подробно изучили производственные процессы, поняли, как происходит остановочный ремонт, и предложили структуру, в которой можно вести график. Мы решили поначалу не ломать существующий процесс и не лезть в пользовательские сценарии людей. Кто привык планировать в экселе — пусть планирует. Кто научился в Primavera, тот пусть работает там.
Первоначально наш продукт представлял собой систему визуализации тех графиков, которые они делают. Мы разработали приложение на iOS, Android и браузерную web-версию. В сервис загружается график вместе с ответственными, исполнителями и контролёрами — три основные роли во время остановочного ремонта. Это важный момент, поэтому остановлюсь на нём подробнее и покажу, как всё работает на примере.
Есть задача отремонтировать насос.
У задачи есть исполнитель — это бригадир подрядной организации, которая ремонтирует какой-то конкретный объект.
Ответственный — отвечает за то, чтобы всё было подготовлено к ремонту, он должен сдать объект в ремонт и потом принять его, подтвердив, что подрядчик завершил работы в полном объеме и может приступать к другим задачам. Как правило, это делает механик установки.
Контролёры — это высший управляющий состав предприятия, люди, которые хотят постоянно видеть соответствие работ плану-графику.
Пользовательские роли
У ответственных и исполнителей есть доступ как в приложение, так и в веб-версию. Исполнитель видит те задачи, которые на него назначены на сегодня, а также на весь остановочный ремонт. У исполнителя есть очерёдность этих задач. Он, приступая к работе, должен нажать соответствующую кнопку, внести в программу количество человек, которые работают над этой задачей. Руководству важно знать, соответствует ли количество людей, работающих над этой задачей, количеству, которое запланировали. Исполнитель нажимает кнопку — и работа пошла. Приложение следит за длительностью процесса. В случае, если дедлайн пройден, а исполнитель не нажал кнопку завершения работы, ответственному приходят оповещения о просрочке. Значит, ответственный идёт и смотрит, что произошло.
Если всё нормально и в установленное время исполнитель завершает работу, он нажимает кнопку «Внести отчёт» и пишет, что выполнил работу на 100%. Тогда ответственный также получает уведомление, что все сделано, нужно пойти и посмотреть результат. Так работает ролевая модель.
Люди могут не держать в голове всё, что происходит на вверенном им участке, они видят график на каждый день и получают уведомления о процессе.
Также мы предусмотрели возможность работы с задачами, которые длятся больше одного дня. Это функционирует так же, как и с небольшими задачами, только в конце каждого дня в программу нужно вносить отчёты: например, сегодня работа выполнена на 50%. Ответственный получает уведомление и должен проверить, соответствует ли эта информация действительности. Если нет — он отклоняет отчёт и заставляет исполнителя ставить другую цифру.
Что касается веб-версии, то функциональность её немного другая, она предназначена больше для контролёров — менеджмента предприятия. Мы поняли, что людям привычно воспринимать информацию о прогрессе по всем работам в диаграммах Ганта. Они видят план-факты, взаимосвязи, статистику по мобилизации человеческих ресурсов, скольких людей мы хотели видеть на заводе во время ремонта и сколько работает по факту. И, соответственно, по всем производственным установкам контролёр может посмотреть процесс выполнения работ, оперативно увидеть отставания от графика.
Внеплановые работы
Всегда во время остановочного ремонта появляются скрытые дополнительные работы, которые нельзя игнорировать. Например, при разборе оборудования находится поломка в той части, которая в собранном состоянии агрегата не видна. Эти задачи тоже вносятся в график, принимается решение, что скрытые работы мы тоже выполняем во время остановочного ремонта. Всё заносится в программу. Если эта дополнительная работа влияет на длительность всего остановочного ремонта, то программа автоматически отодвинет все другие задачи на то время, которое нужно для выполнение этой скрытой работы. Так же и в обратном случае — если какие-то задачи выполняются быстрее, чем запланировано, график оптимизируется.
Для таких случаев мы с командой спроектировали серьёзную систему сообщений и пуш-уведомлений, чтобы предупредить людей, которые приступают к работе, что они могут сделать это раньше или позже. И здесь вскрылся интересный момент. Мы довольно серьёзно переборщили с этими уведомлениями.
Где мы ошиблись?
Дело в том, что мы завели туда «график четвёртого уровня» — большой, подробный план всего остановочного ремонта. Для наших целей он оказался слишком подробным. Получилось, что пользователи получали уведомления о каждой мелочи, которая может быть незначительна для процесса в целом. Ведь когда человек работает без приложения, он не смотрит каждый день в график работ. Он просто знает: чтобы отремонтировать условный насос, нужно выполнить много операций (разобрать его, почистить, заменить агрегаты, собрать, проверить и так далее). И человеку, который проверяет, как работает подрядчик, не нужно контролировать прохождение каждого из этих этапов. Достаточно посмотреть на результат работы в целом и на соответствие заявленным срокам.
То есть, если переходить к уведомлениям, то контролер должен узнавать о двух событиях: начале ремонта и завершении ремонта. Поэтому мы на ходу корректировали приложение. Для начала просили изменить графики и укрупнить их. Затем отказались от некоторых мелких событий и стало всё работать ровнее, пользователя стали меньше отвлекать уведомлениями.
Каков результат?
Когда мы доработали приложение, получился сервис, который позволяет постоянно иметь актуальную информацию по предприятию: что сейчас ремонтируется, на каком этапе процесс и когда срок сдачи. Это позволяет спланировать работы и подготовить график. По сути, эта система управления проектом остановочного ремонта — продвинутый таск-менеджер.
Изначально мы заявляли главной метрикой сокращение времени остановочного ремонта. Понятно, как оценить это в деньгах: ведь известно, сколько стоит час или день простоя производства. Поэтому мы ставили целью ускорить проведение остановочного ремонта. Сейчас мы видим, что важна и аналитика — оценка того, что происходит во время остановочного ремонта, до мелочей. Если мы будем логировать действия пользователя, как и когда он принял работу, какие комментарии написал, что пошло не так, как идут согласования, будем видеть образование скрытых дефектов, понимать, кто как работает — тогда можно проанализировать и понять многое о производственных процессах. Как раз для их оценки у нас есть «Функция эффективности производства». После каждого ремонта собирается определённый массив данных: сколько денег затрачено, сколько было запланировано, как быстро мы вышли из ремонта.
Конечно, мы предусматриваем дальнейшее развитие проекта. Пока это только первый шаг по сбору статистики по остановочным ремонтам. Мы хотим собрать достаточно данных, чтобы с ними можно было работать и делать больше выводов. Например, нам надо отремонтировать насос. Этим занимается X людей и это занимает Y времени. Соответственно, всё последующее планирование какого-либо ремонта может опираться уже на эту модель. Мы сможем планировать работы исходя из того, что уже есть подтвержденная данными аналитика, а значит — не завышать и не занижать ожидания по срокам.
Наше приложение может использоваться не только для производств. Это может быть управление капитальным строительством, любые другие области, где применяется аналогичный подход к планированию работ.
Кто работал над проектом?
Над проектом работала группа людей как внутри СИБУРа, так и подрядчики. Разработка серверной части и фронт-енда полностью была на подрядчике, мы внутри команды занимались проектированием логики работы приложения и интерфейсом. В качестве консультантов привлекались менеджер остановочного ремонта, механик, который непосредственно работал над графиками, главный инженер, следящий за процессом, и директор предприятия.
На все про все (исследования, пилотирование, интерфейсы и разработку) ушло полгода.
Каково будущее продукта?
В ближайших планах — несколько ключевых апдейтов. Пока есть проблемы с подсчётом физических объёмов в рамках какой-либо задачи, например, по заменённым арматурам. Нашим коллегам на предприятии важны не только относительные, но и абсолютные показатели: нужно понимать, насколько процентов выполнены работа, сколько арматур из условной 1000 уже были заменены. Сейчас в графике работ приложения это никак не учитывается. Будем думать, как это реализовать. Пока мы можем только сказать о прогрессе выполненных работ и проценте их выполнения, фиксировать ситуации по отставанию или опережению сроков.
Возможно (и такое понимание уже есть), весь процесс планирования остановочного ремонта будем переносить в наш проект. Возможно, при этом вся разработка переедет инхаус.
Будем рады видеть в команде новых коллег: владельцев продукта, продуктовых дизайнеров, разработчиков. Список актуальных вакансий по ссылке на hh.ru.
