From 790b3a1d996adb742134c4eeda611997b0283cf5 Mon Sep 17 00:00:00 2001 From: Ruslan Bakiev <572431+veikab@users.noreply.github.com> Date: Mon, 4 May 2026 11:08:54 +0700 Subject: [PATCH] Clarify warranty claim procedure --- docs/tz-fregat.typ | 91 +++++++++++++++++++++------------------------- 1 file changed, 41 insertions(+), 50 deletions(-) diff --git a/docs/tz-fregat.typ b/docs/tz-fregat.typ index 3267c2d..00240a1 100644 --- a/docs/tz-fregat.typ +++ b/docs/tz-fregat.typ @@ -2663,48 +2663,17 @@ Wireframe-прототип: Ключевые сторонние компоненты, используемые в текущей реализации, перечислены в разделе технической архитектуры настоящего технического задания. #pagebreak(weak: true) -= 12. Технико-экономические показатели += 12. Стадии и этапы разработки -== 12.1 Назначение показателей - - -Технико-экономические показатели используются для фиксации ожидаемого прикладного эффекта от разработки программного продукта. - -Расчет финансовой эффективности, окупаемости или экономического эффекта в денежном выражении не входит в состав настоящего технического задания, если стороны не согласуют такой расчет отдельно. - -== 12.2 Ожидаемый прикладной эффект - - -Разработка программного продукта должна обеспечить: - -- снижение объема ручной коммуникации при приеме и сопровождении заказов -- единый интерфейс для клиента, менеджера и суперменеджера -- ускорение обработки заявок за счет фиксации состава, параметров и статусов в системе -- снижение риска потери информации по заказам, заявкам и бонусным операциям -- повышение прозрачности статусов заказов и актуальности данных для клиента -- централизованное хранение истории изменений -- возможность дальнейшего развития клиентского, менеджерского, бонусного и интеграционного контуров - -== 12.3 Ограничения - - -Программный продукт не заменяет учетную систему 1С и не является первичным источником бухгалтерских, складских или финансовых данных. - -Экономический эффект зависит от полноты внедрения продукта в рабочие процессы заказчика, качества данных 1С, доступности внешних каналов уведомлений и соблюдения эксплуатационных требований. - -#pagebreak(weak: true) -= 13. Стадии и этапы разработки - - -== 13.1 Общий порядок выполнения работ +== 12.1 Общий порядок выполнения работ Работы выполняются поэтапно, чтобы согласовывать ключевые решения до перехода к следующей части реализации. Переход к следующему этапу выполняется после согласования сторонами результата предыдущего этапа либо после фиксации замечаний, не препятствующих продолжению работ. -== 13.2 Этап 1. Разработка и согласование технического задания +== 12.2 Этап 1. Разработка и согласование технического задания На этапе разрабатывается и согласуется настоящее техническое задание. @@ -2718,7 +2687,7 @@ Wireframe-прототип: Критерий завершения этапа: утверждение технического задания сторонами. -== 13.3 Этап 2. UX/UI и согласование визуального подхода +== 12.3 Этап 2. UX/UI и согласование визуального подхода На этапе подготавливаются 2-3 сверстанные страницы личного кабинета с основными элементами интерфейса. @@ -2738,7 +2707,7 @@ Wireframe-прототип: Критерий завершения этапа: согласование визуального подхода сторонами. -== 13.4 Этап 3. Функциональная реализация без интеграции с 1С +== 12.4 Этап 3. Функциональная реализация без интеграции с 1С На этапе реализуются основные пользовательские и менеджерские сценарии без подключения обмена с 1С. @@ -2763,7 +2732,7 @@ Wireframe-прототип: Критерий завершения этапа: готовность и приемка основного функционала без интеграции с 1С. -== 13.5 Этап 4. Интеграция с 1С и отладка обмена +== 12.5 Этап 4. Интеграция с 1С и отладка обмена На этапе выполняются подключение, настройка и отладка интеграции с 1С. @@ -2786,7 +2755,7 @@ Wireframe-прототип: Критерий завершения этапа: подтвержденная сторонами работоспособность сценариев с 1С в согласованном объеме. -== 13.6 Этап 5. Передача результата и приемка +== 12.6 Этап 5. Передача результата и приемка На этапе выполняются итоговая проверка, устранение критичных замечаний и передача результата работ. @@ -2802,10 +2771,10 @@ Wireframe-прототип: Критерий завершения этапа: подписание акта приемки либо наступление условий приемки, предусмотренных договором. #pagebreak(weak: true) -= 14. Порядок контроля, приемки и гарантийного сопровождения += 13. Порядок контроля, приемки и гарантийного сопровождения -== 14.1 Общие положения приемки +== 13.1 Общие положения приемки Приемка результата работ должна подтверждать соответствие программного продукта требованиям настоящего технического задания, условиям договора и согласованным требованиям заказчика. @@ -2823,7 +2792,7 @@ Wireframe-прототип: - интеграционный обмен с 1С в согласованном объеме - пользовательская и эксплуатационная документация в согласованном объеме -== 14.2 Виды проверок +== 13.2 Виды проверок Для контроля результата работ используются следующие виды проверок: @@ -2836,7 +2805,7 @@ Wireframe-прототип: - проверка интеграционного обмена с 1С - проверка запуска и работы сервисов в согласованном эксплуатационном контуре -== 14.3 Критерии приемки +== 13.3 Критерии приемки Программный продукт считается соответствующим требованиям, если: @@ -2852,7 +2821,7 @@ Wireframe-прототип: - текущая задолженность клиента и дата актуальности данных отображаются при наличии этих сведений из 1С - критичные дефекты, препятствующие выполнению основных сценариев, устранены до передачи результата -== 14.4 Передаваемые материалы +== 13.4 Передаваемые материалы В состав передаваемых заказчику материалов входят: @@ -2867,7 +2836,7 @@ Wireframe-прототип: Технические схемы, модель данных, роли, архитектура, стек, состав сервисов и требования к интеграциям являются частью настоящего технического задания и не дублируются в отдельных документах без отдельного согласования сторон. -== 14.5 Порядок фиксации замечаний +== 13.5 Порядок фиксации замечаний Каждое замечание, выявленное при приемке, должно содержать: @@ -2881,17 +2850,35 @@ Wireframe-прототип: Замечания, не препятствующие выполнению основных пользовательских и интеграционных сценариев, могут быть зафиксированы сторонами для последующего устранения в согласованном порядке. -== 14.6 Гарантийный срок +== 13.6 Гарантийный срок Гарантийный срок на разработанные модули, сервисы и дополнительный функционал составляет 6 месяцев с даты подписания акта приемки выполненных работ, если иной порядок не согласован сторонами. Гарантия распространяется на дефекты разработанного программного продукта, проявившиеся при штатной эксплуатации и относящиеся к функционалу, реализованному исполнителем. -== 14.7 Порядок гарантийного обращения +== 13.7 Первичная проверка гарантийного случая заказчиком -Гарантийное обращение должно быть передано исполнителю в письменной форме или иным согласованным сторонами способом. +До направления гарантийного обращения заказчик выполняет первичную проверку на своей стороне и исключает причины, не относящиеся к разработанному программному продукту. + +В рамках первичной проверки заказчик проверяет: + +- доступность сервера, контейнеров, базы данных и сетевой инфраструктуры, на которых размещен программный продукт +- работоспособность домена, DNS, TLS-сертификатов, reverse proxy и иных инфраструктурных компонентов заказчика +- наличие необходимых ресурсов сервера, включая доступное место, память и процессорную нагрузку +- корректность переменных окружения, секретов, токенов и доступов, которые находятся в зоне ответственности заказчика +- доступность и корректную работу 1С, внешних API, почтового сервиса, Telegram, Max и иных внешних систем +- отсутствие изменений в форматах, правах доступа, настройках интеграций и учетных данных внешних систем +- отсутствие самостоятельных изменений кода, конфигурации, базы данных или инфраструктуры без согласования с исполнителем +- воспроизводимость проблемы на конкретном пользовательском сценарии + +Если по итогам первичной проверки заказчик предполагает, что причина относится к разработанному исполнителем функционалу, заказчик направляет гарантийное обращение исполнителю. + +== 13.8 Порядок гарантийного обращения + + +Гарантийное обращение должно быть передано исполнителю в письменной форме или иным согласованным сторонами способом после первичной проверки на стороне заказчика. В обращении должны быть указаны: @@ -2901,13 +2888,17 @@ Wireframe-прототип: - ожидаемый результат - фактический результат - дата и время обнаружения +- результат первичной проверки на стороне заказчика +- сведения о состоянии сервера, контейнеров, базы данных и внешних систем, если они связаны с проявлением дефекта - дополнительные материалы, если они нужны для диагностики -Исполнитель выполняет диагностику дефекта и, если дефект относится к гарантийной зоне ответственности, устраняет его без дополнительной оплаты. +Исполнитель выполняет диагностику обращения в пределах разработанного им функционала. Если по результатам диагностики дефект относится к гарантийной зоне ответственности исполнителя, исполнитель устраняет его без дополнительной оплаты. -Срок устранения гарантийного дефекта составляет не более 3 дней с даты получения обращения либо иной срок, согласованный сторонами с учетом критичности и характера дефекта. +Если по результатам диагностики причина связана с инфраструктурой заказчика, внешними системами, изменением доступов, изменением форматов обмена, настройками 1С, почтовыми или мессенджерными сервисами, такое обращение не считается гарантийным дефектом программного продукта. -== 14.8 Ограничения гарантийного сопровождения +Срок устранения гарантийного дефекта составляет не более 3 дней с даты получения полного обращения, содержащего сведения, достаточные для воспроизведения и диагностики дефекта, либо иной срок, согласованный сторонами с учетом критичности и характера дефекта. + +== 13.9 Ограничения гарантийного сопровождения Гарантийное сопровождение не распространяется на случаи, когда некорректная работа вызвана: