Привет, спасибо за вопрос) нет, такие таблички мы, слава богу, не делаем, это - чтобы показать "внутрянку" и нужные контрольные точки. У нас на доске задачу тоже не передвинешь, если не заполнить поле "Описание"
Привет! Нет) Мы не обрабатываем персональные данные без наличия на то законных оснований в соответствии с Федеральным законом от 27.07.2006 № 152-ФЗ, в том числе при отсутствии согласия на обработку персональных данных соискателей. То же самое касается и хранения персональных данных. Если соискатель отказывает или не предоставляет согласие на хранение и добавление персональных данных в кадровый резерв, то персональные данные уничтожаются или обезличиваются (если это возможно) в сроки, предусмотренные действующим законодательством.
Спасибо за вопрос! Сервис является внутренней разработкой и не заменяет работу эйчара, а сокращает ему время на выборку той или иной вакансии, либо позиции по кандидату. На проекте работали и аналитики, и ML-команда, и наш непосредственный заказчик - рекрутмент.
Это полноценная разработка приложения с подробным описанием архитектурного решения, проработанного бизнес-аналитиком и системным аналитиком. Модель закрытая и имеет очень четко настроенные парсинги, необходимые в нашем поиске. Взаимодействие эйчара с платформой сводится к тому, чтобы понимать насколько релевантные отклики на ту или иную вакансию. Бывает, что на популярную на ИТ-рынке вакансию приходит сотни резюме от кандидатов, где половина может не подходить по критериям. Поэтому эйчар получает выжимку из самых точных попаданий и уже начинает работать непосредственно с этими кандидатами. Система не заменяет эйчаров ни в коем случае, тут нужна психология, эмоциональный интеллект. Ведь правильно вы пишите, необходимо оценивать не только силы, но и качества кандидата, мотивацию и культурное соответствие компании. В этом процессе не ИИ-сервис главный, это просто инструмент для эйчаров, который в разы сократил им время поиска.
Привет!) Нет задачи заставлять кандидатов генерить резюме. Данный сервис просто помогает рекрутерам найти подходящее резюме в базе, где сотни тысяч резюме и не делать это руками — использую ключевые слова, которые и так должны быть в резюме. Например, если кандидат работал Frontend разработчиком с фреймом React, то это указано в резюме и это является ключевыми словами.
Спасибо за замечание! Планируем опубликовать серию статей — будет и техническая публикация, и про внедрение, и даже анализ аналогов. Это была первая статья из серии.
Привет! Спасибо за вопрос) Ответ от автора: "Я подключился к проекту на этапе уже реализованной предыдущими подрядчиками конвертации и коллеги частично использовали автоматизацию, но в результате стали все руками переписывать. Со своей стороны считаю, что на текущий момент, если бы возникла задача переноса нескольких десятков хранимых процедур с T-SQL на PL/pgSQL — то пошли бы реализовывать руками, поскольку зачастую доработка переведенного когда бывает даже сложнее, чем написание "с нуля". Мы сами уже в параллель оптимизации еще переписали около 70-80 хранимок."
ManageIQ — это открытая платформа для управления гибридной облачной инфраструктурой. Она может управлять контейнерами, виртуальными машинами, сетями и хранилищами с помощью единой консоли. ManageIQ ориентирована на работу с множеством провайдеров и интеграций, таких как VMware, OpenStack, AWS и Microsoft Azure. Её сильная сторона — это непрерывное обнаружение ресурсов и управление жизненным циклом виртуальных машин и контейнеров, а также поддержка расширенных возможностей безопасности и соответствия политике компании.
Octopus больше ориентирован на оптимизацию использования ресурсов и балансировку нагрузки в реальном времени. Основной упор делается на автоматизацию и прогнозирование с использованием ИИ для распределения вычислительных мощностей в гибридных и облачных средах. Octopus также фокусируется на снижении нагрузки на инфраструктуру, интеграции с различными гипервизорами и управлении как физическими, так и виртуальными ресурсами в режиме реального времени.
Octopus предоставляет мощные инструменты для оптимизации нагрузки на серверы, с акцентом на мониторинг, анализ данных и прогнозирование будущих нагрузок. Это позволяет минимизировать простой и оптимизировать использование серверных мощностей, что важно для динамически изменяющихся инфраструктур. ManageIQ также предлагает инструменты для оптимизации, такие как анализ загрузки ЦП и памяти, рекомендации по оптимизации и планирование ёмкости. Однако основное внимание уделяется управлению и оркестрации в сложных гибридных облаках, а не столь специализированной оптимизации нагрузки в реальном времени, как в Octopus.
Привет! Да, здесь требуется стратегический подход и планирование. Лучше с самого начала предусмотреть использование API Gateway, даже если проект кажется небольшим на первых этапах. По мере роста проекта может быть сложно и трудозатратно внедрять AGW в уже существующую архитектуру. Так что небольшие усилия на старте могут сэкономить кучу времени и нервов в будущем. А плюшки действительно будут только на пользу — от версионирования (как в прошлом комментарии) до управления трафиком и безопасностью. Спасибо за такой ценный комментарий!
Привет! Версионирование через API Gateway — действительно отличное решение, особенно когда не хочется завязываться на версию в URL и удобнее держать её в заголовках. Про обработку ошибок тоже хорошая мысль — API Gateway действительно может помочь сгладить косяки на уровне сервисов и вернуть что-то более осмысленное пользователю. Спасибо, что дополнил — очень круто!
Добрый день! Спасибо за вопрос) Ответ от автора: "Немного не поняла вопрос, если вас интересует в каких приложениях еще есть пуш уведомления, то ответ - да почти во всех. Если вы хотите увидеть именно код (судя по вопросу, вас интересует реализация), то, поскольку, код – это собственность каждого продукта, то увидеть его невозможно. Чтобы увидеть реализацию уведомлений, вам надо ее либо написать самим ), либо поискать примеры в интернете. Главное, что надо понимать, во-первых, это работает не так, что вы отправили уведомление и мобильное устройство сразу красиво вам его показало. Во-вторых, пуши – это трехзвенка, состоящая из того, кто отправил, и того, кто показал пуш, а между ними firebase. В-третьих, нет смысла тестировать пуши и смотреть на них без визуализации. Как они будут выглядеть решать вам, сам пуш это просто текстовое сообщение, его можно отобразить как всплывающим окном (как на андроиде) так и огромным баннером на сайте. Если у вас есть андроид приложение (по идее обычный вебовский фронт тоже умеет обрабатывать уведомления, у них есть специальный пакет), то для минимального запуска пушей вам нужно в коде фронта сделать обработку приходящего уведомления. Как это сделать написано например тут https://firebase.google.com/docs/cloud-messaging/android/client, а затем вы можете отправить первый пуш не из кода веба, а прямо из консоли firebase (как написано вот тут https://firebase.google.com/docs/cloud-messaging/android/send-with-console). Если вы хотите посмотреть, как выглядят пуши без кодирования (что-то вроде подключил свой телефон на сайте, нажал кнопку и пришел пуш), то мне о таких инструментах неизвестно, возможно стоит поискать какой-нибудь push simulator."
Если вопрос к автору статьи, то делимся ответом "Речь про иностранные языки и скриншоты интерфейса. Если в продукте используются какие-то сложные настройки (например, файлы конфигурации или скрипты для запуска), то лучше предоставлять их непосредственно файлами или хотя бы текстом, чтобы можно было скопировать. Версия скринов в разных версия инструкций, всё верно. Единую инструкцию, к сожалению, сделать не всегда можно, так как очередная версия функциональности может изменить пользовательский сценарий, и актуальные скриншоты без новых вводных будут непонятны."
Привет)) Ответ от автора "Всё правильно. Обращаю внимание, что все ссылки были предоставлены на старте, как это и написано в первом абзаце в разделе «Какие возникли проблемы и почему они возникли?». А время аналитика, действительно, пожалели. Как говорится, никогда нет времени сделать, но всегда есть время переделать 🙃"
Привет) Ответ от автора "Забавно, что 99% - этого, действительно, достаточно, но этот 1% 😅 бывали кейсы, когда редкая комбинация параметров клиента не учитывается системой, и это не описано нигде, поскольку никогда не возникало подобных запросов. Если это денежный клиент, то проблемы решать придётся, и неплохо бы зафиксировать на будущее её решение. А так, безусловно всё, что можно автоматизировать, нужно автоматизировать. Вопрос бюджета и приоритетов 😉 иногда консьерж-сервис обходится существенно дешевле."
Привет :) Ответ от автора "Согласна с тем, что, как минимум, документацию стоит отдать на ревью кому-то из перечисленных ролей. В отдельных случаях им даже лучше самостоятельно описать функциональность (кейсы со сложной логикой). По поводу 2-х подходов: мы всё-таки для людей пишем, чтобы им жизнь облегчить, поэтому стараемся ёмко и по делу :)"
По направлению Life у нас 11 разработчиков, 5 аналитиков и 2 гордых тестировщика) Наша команда, а если смотреть чуть шире, то все управление информационных технологий по направлению Life - это "дочка" большой компании классического страхования, поэтому во многом мы зависимы от коллег) наши 200 с небольшим кейсов - лишь крошечная часть их большой регрессионной модели, насчитывающей более 2,5к кейсов
Что касается времени на тестирование ТЗ и просто тестирование itself - тут не могу сказать вам точно, разве что получится плюс-минус километр, бывают задачи на 20 минут, поменять что-то в печатной форме, заменить алгоритм проставления агентов, а бывают на 2 -3 дня с полным изменением логики и всех связанных процессов, также и с техническими заданиями, простое на один функциональный модуль или одну несложную доработку или ТЗ на интеграцию нескольких информационных систем с доработкой каждой из них.
Отличный вопрос про подписание идеального ТЗ, вообще, довольно редко такое происходит, ведь если идти по процессу от ТЗ к разработке через тестирование, а не наоборот, сложно набедокурить))) но, буду честной, случатся, что аналитик правит ТЗ уже по результатам разработки, потому что в последний момент бизнес-пользователи захотели сделать чуть иначе. Если же что-то кардинально меняется, тут уже аналитики встают на стражу и не пропускают ТЗ в разработку, забирают к себе на до-анализ и далее только через нас, тестировщиков, отдают в работу
Про автотесты. Как говорила выше, мы зависимы от головной компании и все, что хотим заавтоматить, передаем им: принимаем решение, пишем параметризированные кейсы, ставим задачу на исполнителя в головной компании, ждем, принимаем работу
Аналитики создают отдельную ветку, дорабатывают спецификацию и отправляют на ревью разработчикам. Дальше мяч на их стороне: идет этап ревью, при необходимости отправляют на доработку. Все изменения мержат уже разработчики после окончательного согласования, иногда в этой же ветке проводят реализацию внутренней логики метода, когда она описана и освободились ресурсы
Очень здорово, что переходите на новую модель работы со спецификацией! Процесс непростой, это правда, мы его обкатывали не один месяц, но оно того стоит
В задачах спецификацию не храним, очень сложно потом синхронизировать ее с общей частью, на моем опыте никто из аналитиков после реализации задачи этого не делал (забывали, не хотели, нет времени и еще 1001 причина). Вместо этого вся документация ведется в базе знаний. В таске описываем верхнеуровнево пункты, которые нужно сделать (создать сущность1, реализовать метод2), а для более детальной информации прикрепляем ссылки на страницы в доке и выделяем цветом дельту, которую нужно реализовать.
Что касается задач на интеграцию: для клиентов (в нашем случае фронтов) или смежных команд достаточно при таком подходе отдать swagger, там вся исчерпывающая информация, которая им необходима. Для разработки бека к swagger еще прикладываем описание внутренней логики, которая также хранится в базе знаний
Самих баз знаний 2: swagger (хранится в git) и wiki
Привет, спасибо за вопрос) нет, такие таблички мы, слава богу, не делаем, это - чтобы показать "внутрянку" и нужные контрольные точки. У нас на доске задачу тоже не передвинешь, если не заполнить поле "Описание"
Эх, а еще двое из этих Анн руководители разработки ... никакого равноправия 😁
Привет! Нет) Мы не обрабатываем персональные данные без наличия на то законных оснований в соответствии с Федеральным законом от 27.07.2006 № 152-ФЗ, в том числе при отсутствии согласия на обработку персональных данных соискателей. То же самое касается и хранения персональных данных. Если соискатель отказывает или не предоставляет согласие на хранение и добавление персональных данных в кадровый резерв, то персональные данные уничтожаются или обезличиваются (если это возможно) в сроки, предусмотренные действующим законодательством.
Спасибо за вопрос!
Сервис является внутренней разработкой и не заменяет работу эйчара, а сокращает ему время на выборку той или иной вакансии, либо позиции по кандидату. На проекте работали и аналитики, и ML-команда, и наш непосредственный заказчик - рекрутмент.
Это полноценная разработка приложения с подробным описанием архитектурного решения, проработанного бизнес-аналитиком и системным аналитиком. Модель закрытая и имеет очень четко настроенные парсинги, необходимые в нашем поиске.
Взаимодействие эйчара с платформой сводится к тому, чтобы понимать насколько релевантные отклики на ту или иную вакансию. Бывает, что на популярную на ИТ-рынке вакансию приходит сотни резюме от кандидатов, где половина может не подходить по критериям. Поэтому эйчар получает выжимку из самых точных попаданий и уже начинает работать непосредственно с этими кандидатами.
Система не заменяет эйчаров ни в коем случае, тут нужна психология, эмоциональный интеллект. Ведь правильно вы пишите, необходимо оценивать не только силы, но и качества кандидата, мотивацию и культурное соответствие компании.
В этом процессе не ИИ-сервис главный, это просто инструмент для эйчаров, который в разы сократил им время поиска.
Привет!) Нет задачи заставлять кандидатов генерить резюме. Данный сервис просто помогает рекрутерам найти подходящее резюме в базе, где сотни тысяч резюме и не делать это руками — использую ключевые слова, которые и так должны быть в резюме. Например, если кандидат работал Frontend разработчиком с фреймом React, то это указано в резюме и это является ключевыми словами.
Спасибо за замечание! Планируем опубликовать серию статей — будет и техническая публикация, и про внедрение, и даже анализ аналогов. Это была первая статья из серии.
Привет! Спасибо за вопрос) Ответ от автора: "Я подключился к проекту на этапе уже реализованной предыдущими подрядчиками конвертации и коллеги частично использовали автоматизацию, но в результате стали все руками переписывать. Со своей стороны считаю, что на текущий момент, если бы возникла задача переноса нескольких десятков хранимых процедур с T-SQL на PL/pgSQL — то пошли бы реализовывать руками, поскольку зачастую доработка переведенного когда бывает даже сложнее, чем написание "с нуля". Мы сами уже в параллель оптимизации еще переписали около 70-80 хранимок."
Удачи на собеседовании :)
Добрый день!
ManageIQ — это открытая платформа для управления гибридной облачной инфраструктурой. Она может управлять контейнерами, виртуальными машинами, сетями и хранилищами с помощью единой консоли. ManageIQ ориентирована на работу с множеством провайдеров и интеграций, таких как VMware, OpenStack, AWS и Microsoft Azure. Её сильная сторона — это непрерывное обнаружение ресурсов и управление жизненным циклом виртуальных машин и контейнеров, а также поддержка расширенных возможностей безопасности и соответствия политике компании.
Octopus больше ориентирован на оптимизацию использования ресурсов и балансировку нагрузки в реальном времени. Основной упор делается на автоматизацию и прогнозирование с использованием ИИ для распределения вычислительных мощностей в гибридных и облачных средах. Octopus также фокусируется на снижении нагрузки на инфраструктуру, интеграции с различными гипервизорами и управлении как физическими, так и виртуальными ресурсами в режиме реального времени.
Octopus предоставляет мощные инструменты для оптимизации нагрузки на серверы, с акцентом на мониторинг, анализ данных и прогнозирование будущих нагрузок. Это позволяет минимизировать простой и оптимизировать использование серверных мощностей, что важно для динамически изменяющихся инфраструктур.
ManageIQ также предлагает инструменты для оптимизации, такие как анализ загрузки ЦП и памяти, рекомендации по оптимизации и планирование ёмкости. Однако основное внимание уделяется управлению и оркестрации в сложных гибридных облаках, а не столь специализированной оптимизации нагрузки в реальном времени, как в Octopus.
Привет! Да, здесь требуется стратегический подход и планирование. Лучше с самого начала предусмотреть использование API Gateway, даже если проект кажется небольшим на первых этапах. По мере роста проекта может быть сложно и трудозатратно внедрять AGW в уже существующую архитектуру. Так что небольшие усилия на старте могут сэкономить кучу времени и нервов в будущем. А плюшки действительно будут только на пользу — от версионирования (как в прошлом комментарии) до управления трафиком и безопасностью. Спасибо за такой ценный комментарий!
Привет! Версионирование через API Gateway — действительно отличное решение, особенно когда не хочется завязываться на версию в URL и удобнее держать её в заголовках. Про обработку ошибок тоже хорошая мысль — API Gateway действительно может помочь сгладить косяки на уровне сервисов и вернуть что-то более осмысленное пользователю. Спасибо, что дополнил — очень круто!
Добрый день! Спасибо за вопрос) Ответ от автора: "Немного не поняла вопрос, если вас интересует в каких приложениях еще есть пуш уведомления, то ответ - да почти во всех.
Если вы хотите увидеть именно код (судя по вопросу, вас интересует реализация), то, поскольку, код – это собственность каждого продукта, то увидеть его невозможно.
Чтобы увидеть реализацию уведомлений, вам надо ее либо написать самим ), либо поискать примеры в интернете. Главное, что надо понимать, во-первых, это работает не так, что вы отправили уведомление и мобильное устройство сразу красиво вам его показало.
Во-вторых, пуши – это трехзвенка, состоящая из того, кто отправил, и того, кто показал пуш, а между ними firebase.
В-третьих, нет смысла тестировать пуши и смотреть на них без визуализации. Как они будут выглядеть решать вам, сам пуш это просто текстовое сообщение, его можно отобразить как всплывающим окном (как на андроиде) так и огромным баннером на сайте. Если у вас есть андроид приложение (по идее обычный вебовский фронт тоже умеет обрабатывать уведомления, у них есть специальный пакет), то для минимального запуска пушей вам нужно в коде фронта сделать обработку приходящего уведомления. Как это сделать написано например тут https://firebase.google.com/docs/cloud-messaging/android/client, а затем вы можете отправить первый пуш не из кода веба, а прямо из консоли firebase (как написано вот тут https://firebase.google.com/docs/cloud-messaging/android/send-with-console). Если вы хотите посмотреть, как выглядят пуши без кодирования (что-то вроде подключил свой телефон на сайте, нажал кнопку и пришел пуш), то мне о таких инструментах неизвестно, возможно стоит поискать какой-нибудь push simulator."
Если вопрос к автору статьи, то делимся ответом "Речь про иностранные языки и скриншоты интерфейса. Если в продукте используются какие-то сложные настройки (например, файлы конфигурации или скрипты для запуска), то лучше предоставлять их непосредственно файлами или хотя бы текстом, чтобы можно было скопировать.
Версия скринов в разных версия инструкций, всё верно.
Единую инструкцию, к сожалению, сделать не всегда можно, так как очередная версия функциональности может изменить пользовательский сценарий, и актуальные скриншоты без новых вводных будут непонятны."
Привет)) Ответ от автора "Всё правильно. Обращаю внимание, что все ссылки были предоставлены на старте, как это и написано в первом абзаце в разделе «Какие возникли проблемы и почему они возникли?».
А время аналитика, действительно, пожалели. Как говорится, никогда нет времени сделать, но всегда есть время переделать 🙃"
Привет) Ответ от автора "Забавно, что 99% - этого, действительно, достаточно, но этот 1% 😅 бывали кейсы, когда редкая комбинация параметров клиента не учитывается системой, и это не описано нигде, поскольку никогда не возникало подобных запросов. Если это денежный клиент, то проблемы решать придётся, и неплохо бы зафиксировать на будущее её решение.
А так, безусловно всё, что можно автоматизировать, нужно автоматизировать. Вопрос бюджета и приоритетов 😉 иногда консьерж-сервис обходится существенно дешевле."
Привет :) Ответ от автора "Согласна с тем, что, как минимум, документацию стоит отдать на ревью кому-то из перечисленных ролей. В отдельных случаях им даже лучше самостоятельно описать функциональность (кейсы со сложной логикой).
По поводу 2-х подходов: мы всё-таки для людей пишем, чтобы им жизнь облегчить, поэтому стараемся ёмко и по делу :)"
Спасибо за обратную связь :)
Привет и спасибо за вопросы! Ответ автора:
По направлению Life у нас 11 разработчиков, 5 аналитиков и 2 гордых тестировщика)
Наша команда, а если смотреть чуть шире, то все управление информационных технологий по направлению Life - это "дочка" большой компании классического страхования, поэтому во многом мы зависимы от коллег) наши 200 с небольшим кейсов - лишь крошечная часть их большой регрессионной модели, насчитывающей более 2,5к кейсов
Что касается времени на тестирование ТЗ и просто тестирование itself - тут не могу сказать вам точно, разве что получится плюс-минус километр, бывают задачи на 20 минут, поменять что-то в печатной форме, заменить алгоритм проставления агентов, а бывают на 2 -3 дня с полным изменением логики и всех связанных процессов, также и с техническими заданиями, простое на один функциональный модуль или одну несложную доработку или ТЗ на интеграцию нескольких информационных систем с доработкой каждой из них.
Отличный вопрос про подписание идеального ТЗ, вообще, довольно редко такое происходит, ведь если идти по процессу от ТЗ к разработке через тестирование, а не наоборот, сложно набедокурить))) но, буду честной, случатся, что аналитик правит ТЗ уже по результатам разработки, потому что в последний момент бизнес-пользователи захотели сделать чуть иначе. Если же что-то кардинально меняется, тут уже аналитики встают на стражу и не пропускают ТЗ в разработку, забирают к себе на до-анализ и далее только через нас, тестировщиков, отдают в работу
Про автотесты. Как говорила выше, мы зависимы от головной компании и все, что хотим заавтоматить, передаем им: принимаем решение, пишем параметризированные кейсы, ставим задачу на исполнителя в головной компании, ждем, принимаем работу
Привет!) Ответ от автора:
Аналитики создают отдельную ветку, дорабатывают спецификацию и отправляют на ревью разработчикам. Дальше мяч на их стороне: идет этап ревью, при необходимости отправляют на доработку. Все изменения мержат уже разработчики после окончательного согласования, иногда в этой же ветке проводят реализацию внутренней логики метода, когда она описана и освободились ресурсы
Очень здорово, что переходите на новую модель работы со спецификацией! Процесс непростой, это правда, мы его обкатывали не один месяц, но оно того стоит
Привет!) Ответ от автора:
В задачах спецификацию не храним, очень сложно потом синхронизировать ее с общей частью, на моем опыте никто из аналитиков после реализации задачи этого не делал (забывали, не хотели, нет времени и еще 1001 причина). Вместо этого вся документация ведется в базе знаний. В таске описываем верхнеуровнево пункты, которые нужно сделать (создать сущность1, реализовать метод2), а для более детальной информации прикрепляем ссылки на страницы в доке и выделяем цветом дельту, которую нужно реализовать.
Что касается задач на интеграцию: для клиентов (в нашем случае фронтов) или смежных команд достаточно при таком подходе отдать swagger, там вся исчерпывающая информация, которая им необходима. Для разработки бека к swagger еще прикладываем описание внутренней логики, которая также хранится в базе знаний
Самих баз знаний 2: swagger (хранится в git) и wiki