Сергей Фролков

Независимая приёмка и технический аудит парсера объявлений автозапчастей
Требуется специалист для независимой приёмки разработанного веб-сервиса мониторинга цен на запасные части. Система загружает номенклатуру заказчика, находит объявления, сопоставляет их с товарами, рассчитывает рыночные показатели и формирует выгрузку для 1С.
Задачи исполнителя:
1. Изучить договорное и преддоговорное ТЗ, руководство пользователя.
2. Составить программу и чек-лист приёмки.
3. Проверить соответствие реализованной системы требованиям ТЗ.
4. Провести функциональное тестирование парсера, интерфейса, расчётов, фильтров, истории цен и экспорта.
5. Проверить полноту загрузки номенклатуры и объявлений.
6. Зафиксировать ошибки с доказательствами, шагами воспроизведения и оценкой критичности.
Ключевая проблема
Выявлено некорректное сопоставление ИСКОМОГО ТОВАРА и ОБЪЯВЛЕНИЙ (ПРЕДЛОЖЕНИЙ). Например, по совпавшему после нормализации артикулу к товару могут относиться объявления о принципиально другой детали. Такие объявления попадают в ценовую выборку и искажают расчёты.
Необходимо установить точную техническую причину ошибки, в том числе проверить:
• как нормализуется искомый артикул из номенклатуры;
• извлекается ли артикул из названия и описания объявления и как он нормализуется;
• по какому правилу создаётся связь «товар – объявление»;
• считаются ли все результаты поиска автоматически соответствующими товару;
• как используются точные артикулы, аналоги и кросс-артикулы;
• откуда берутся связи между аналогами и насколько надёжен источник;
• может ли ошибочный артикул, указанный продавцом, создать ложную связь;
• проверяются ли наименование, тип детали, производитель и назначение товара;
• корректно ли работают таблицы связей, статусы и признаки допуска объявления в расчёт.
Предметная область – запасные части китайских грузовых автомобилей. Доверие к артикулам, кросс-артикулам и применимости, указанным продавцами, ограничено. Простое совпадение нормализованной строки не должно автоматически означать соответствие товара.
Ожидаемый результат:
• матрица соответствия реализации требованиям ТЗ;
• чек-лист и результаты тестирования;
• реестр выявленных дефектов;
• отдельное заключение о причинах неправильного сопоставления;
• перечень необходимых исправлений и критериев их повторной приёмки;
• итоговый вывод: можно ли принимать систему у подрядчика и при каких условиях.
На первом этапе требуется именно независимая приёмка и диагностика. Разработка исправлений может обсуждаться отдельно.
В отклике прошу указать:
• релевантный опыт приёмки и аудита парсеров или аналитических веб-систем;
• опыт анализа алгоритмов сопоставления данных, артикулов или товарных карточек;
• потребуется ли доступ к исходному коду, базе данных и журналам работы;
• предлагаемый порядок проверки;
• срок и стоимость работы;
• пример итогового отчёта или перечень его разделов.

При проведении приёмки необходимо руководствоваться одновременно двумя техническими заданиями: исходным преддоговорным ТЗ и ТЗ, подписанным в составе договора. Требования обоих документов являются обязательными для исполнения и образуют совокупный объём работ.
Подписанное ТЗ не отменяет и не сокращает требования преддоговорного ТЗ, если это прямо не указано.
При расхождениях, противоречиях или различной степени детализации приоритет имеет преддоговорное ТЗ. Соответствие системы необходимо оценивать с учётом этого правила.

Требуется специалист по настройке OKdesk для учета рекламаций по оборудованию
Ищем специалиста для внедрения и настройки OKdesk под учет рекламаций на производимое оборудование – дизель-генераторные установки контейнерного исполнения.
Нужен не просто технический администратор OKdesk, а специалист, который сможет разобраться в нашем процессе регистрации, учета, администрирования и контроля заявок.
Описание оборудования
Мы производим ДГУ контейнерного исполнения. Контейнер включает следующие системы:
* климат: отопление, вентиляция;
* ОПС: охранная и пожарная сигнализация;
* освещение: основное и аварийное;
* ДГУ: двигатель, генератор, контроллер, зарядное устройство;
* сигналы управления: связь с АВР и мониторингом заказчика;
* контейнер: металлический теплоизоляционный антивандальный корпус.

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

Цель внедрения
Настроить в OKdesk понятный процесс обработки рекламаций, чтобы в любой момент было видно:
* какая рекламация поступила;
* кто отвечает за рассмотрение;
* какая информация запрошена у заказчика;
* кто назначен исполнителем;
* какие работы должен выполнить исполнитель;
* какие сроки установлены;
* кто контролирует исполнителя;
* кто принимает работу у исполнителя;
* принял ли заказчик результат;
* есть ли замечания заказчика или спорная ситуация;
* какие заявки открыты, просрочены или закрыты.

Что требуется от исполнителя
1. Разобраться в нашем процессе обработки рекламаций:
* регистрация обращения от заказчика;
* учет поступивших заявок;
* первичная обработка обращения;
* запрос дополнительной информации;
* принятие заявки к рассмотрению;
* определение возможной причины;
* определение плана устранения;
* назначение ответственного и исполнителя;
* контроль работы исполнителя;
* приемка работы у исполнителя;
* передача результата заказчику;
* получение подтверждения или замечаний заказчика;
* закрытие заявки.

2. Предложить оптимальную структуру OKdesk:
* клиенты;
* объекты;
* оборудование;
* серийные номера ДГУ;
* категории рекламаций;
* роли пользователей;
* права доступа;
* карточка заявки;
* отчеты.

3. Предложить минимально необходимый перечень статусов заявки.
Важно: статусы не нужно заранее механически создавать в большом количестве.
Исполнитель должен предложить логичную и минимально достаточную схему статусов после анализа процесса и согласовать ее с нами до настройки.
Статусы должны исключать недопонимание между нами, исполнителями и заказчиком. В каждый момент должно быть понятно, у кого находится следующее действие: у нас, у исполнителя, у заказчика или заявка находится в споре.

4. Настроить карточку заявки с необходимыми полями, включая:
* заказчик;
* объект;
* оборудование;
* серийный номер ДГУ;
* блок оборудования;
* описание замечания;
* дата поступления;
* канал поступления;
* вложения: фото, видео, документы;
* ответственный;
* исполнитель;
* плановая дата начала работ;
* плановая дата окончания работ;
* причина неисправности;
* меры устранения;
* результат выполнения;
* замечания заказчика;
* итоговый статус.
5. Настроить SLA и контроль сроков:
* первичная реакция на заявку – в течение 24 часов;
* контроль просрочки по этапам;
* уведомления ответственным лицам.
6. Настроить возможность назначать индивидуальный чек-лист под каждую заявку.

Чек-лист не должен быть только типовым. По каждой рекламации должен быть возможен отдельный перечень работ для исполнителя с последующей отметкой выполнения и приемкой результата.

7. Настроить отчеты:
* открытые рекламации;
* просроченные рекламации;
* рекламации по заказчикам;
* рекламации по объектам;
* рекламации по блокам оборудования;
* рекламации по исполнителям;
* спорные рекламации;
* завершенные рекламации.

8. Настроить уведомления:
* ответственному за новую заявку;
* исполнителю о назначении;
* ответственному о просрочке;
* руководителю о критичных или спорных заявках;
* заказчику о передаче результата на проверку.
9. Провести краткое обучение пользователей и передать краткую инструкцию по работе с системой.

Ожидаемый результат
Полностью настроенная система OKdesk, готовая к эксплуатации для учета и контроля рекламаций по ДГУ контейнерного исполнения.
В отклике прошу указать:

1. Есть ли опыт настройки каких либо Хелпдеск.
2. Есть ли опыт настройки процессов заявок, исполнителей и приемки работ.
3. Срок выполнения и Стоимость.
4. Что потребуется от нас для начала.