Смена подрядчика сайта: как передать историю решений и незавершённые задачи
Перед сменой подрядчика соберите одну передаточную ведомость: какая версия сайта опубликована, почему приняты важные решения, где лежат редактируемые материалы и кто продолжит открытые задачи. Каждую запись свяжите с проверяемым результатом. Тогда новый исполнитель сможет продолжить работу, а владелец бизнеса — понять, что передано и что ещё нужно согласовать. Ниже — заполненный учебный пример и порядок его приёмки.
Зафиксируйте состояние, которое принимает новый исполнитель
Фраза «сайт передан» оставляет слишком много вопросов. Передали опубликованные страницы, последний макет или изменения, которые ещё никто не проверил? Начните с короткого описания состояния на конкретную дату и время. Отдельно назовите рабочую версию, материалы для будущих изменений и нерешённые вопросы.
Для сайта на конструкторе это могут быть опубликованный набор страниц и сохранённый вариант изменений. Для отдельной разработки — версия кода, соответствующая работающему сайту, и инструкция её подготовки к публикации. Запись должна позволять исполнителю найти нужное состояние без догадки по названию папки «последнее». Способ обозначения зависит от платформы; важна однозначная связь с сайтом.
Договоритесь, какие изменения допускаются во время передачи. Если страницы продолжают редактировать, укажите, кто обновляет ведомость и сообщает о новой версии. Иначе обе команды будут сверять разные состояния. Краткая пауза в согласованных изменениях может помочь, но заявки и обычная работа бизнеса должны продолжаться по понятной процедуре.
Смена исполнителя сама по себе не требует переноса домена, замены платформы или полного пересоздания сайта. Если такая работа действительно запланирована, выделите её в самостоятельную задачу со своими условиями приёмки. Сначала нужно разобраться в текущем состоянии и границах поручения.
Соберите ведомость вокруг одного учебного проекта
Рассмотрим вымышленного поставщика промышленных этикеток. На его сайте опубликованы шесть страниц продукции на русском языке и четыре перевода на немецкий. Запрос расчёта принимает менеджер. Прежняя команда завершает сопровождение; новая должна закончить фильтр каталога и две переведённые страницы. Названия версий, роли, даты и документы ниже придуманы для примера.
| Запись | Что передаём | Как подтвердить |
|---|---|---|
| Работающий сайт | Версия П-7, опубликована 1 октября; форма направляет запрос менеджеру | Сопоставить страницы с сохранённой версией; проверить получение контрольного обращения |
| Следующая версия | П-8: фильтр по материалу готов на проверочной копии, публикация не согласована | Открыть проверочную копию и найти задачу З-12 с ожидаемым поведением |
| Материалы | Тексты Т-4, макеты М-3, фотографии изделий и перечень их происхождения | Открыть редактируемые файлы и сверить их с опубликованными страницами |
| Решения | Журнал Р-1–Р-4: расчёт цены, языки, фильтр и смена получателя заявки | Прочитать основания и отделить принятое решение от предложения |
| Продолжение работы | Перечень З-12–З-16 с проверками, зависимостями и назначаемыми исполнителями | Новая команда подтверждает каждую принятую задачу; владелец согласует объём |
Ведомость служит оглавлением: запись ведёт к конкретному документу, задаче или версии. Большие тексты и файлы могут оставаться в привычных рабочих системах. Дублировать их в нескольких папках необязательно; нужно проверить, что новый участник действительно может открыть актуальный материал.
В строке о заявках достаточно назвать назначение формы и ответственную роль. Пароли, ключи сервисов, коды восстановления и данные реальных клиентов в такой документ не помещают. Необходимые доступы передают отдельно согласованным способом. Учебный образец также не должен содержать настоящих заявок и учётных данных.
Сохраните причины важных решений
Новый подрядчик видит результат, но может не знать ограничений. Отсутствие цены выглядит недоработкой, хотя стоимость зависит от материала и тиража. Напишите, какую задачу решали, какие варианты рассматривали, что согласовали и какие последствия приняли. Для существенного решения достаточно короткой записи со ссылкой на подтверждение.
| Решение и статус | Основание | Следствие и повод пересмотреть |
|---|---|---|
| Р-1. Расчёт через менеджера — принято владельцем 18 сентября | Материал и тираж меняют стоимость; единой подтверждённой таблицы цен нет | Карточка объясняет нужные параметры запроса. Автоматический расчёт обсуждают после согласования правил цены |
| Р-2. Переводы публикуются после проверки специалистом — принято 20 сентября | У терминов о материалах есть несколько вариантов; два перевода пока не подтверждены | Четыре немецкие страницы опубликованы, две остаются в подготовке. Смена исполнителя не означает согласование текста |
| Р-3. Фильтр по материалу — предложено, окончательно не принято | Планируется упростить выбор; свойства шести позиций ещё сверяет менеджер | Проверочная реализация П-8 остаётся вне работающего сайта до подтверждения данных и поведения |
| Р-4. Второй адресат заявки — отложено | Резервного сотрудника ещё не назначили | Текущий получатель сохраняется. Настройку меняют после назначения человека и проверки доставки |
В технической разработке AWS описывает журнал архитектурных решений: в записи сохраняют контекст, выбор и последствия, а изменившееся решение связывают с новой записью. Здесь этот принцип адаптирован к небольшому сайту. Формальный технический процесс не нужен для каждой правки текста; полезно сохранить причины решений, которые новый исполнитель может дорого или ошибочно переделать.
Отличайте подтверждённое основание от предположения. «Менеджер согласовал перечень материалов в документе Т-4» можно проверить. «Клиентам так удобнее» без наблюдений остаётся гипотезой. Если подтверждения нет, запишите, что сведения требуют проверки, и назовите человека, который может их уточнить.
Старые решения разрешено пересматривать. Например, появление утверждённого прайс-листа меняет основание Р-1. В новой записи объясняют, что изменилось, кто согласовал новый подход и какую прежнюю запись он заменяет. История помогает понять переход, а не запрещает улучшать сайт.
Проверьте, что материалы пригодны для продолжения работы
Скриншот страницы помогает увидеть результат, но не позволяет исправить текст или адаптировать макет. По каждой группе материалов укажите редактируемый вариант, его актуальность, расположение и ограничения использования. Получатель должен открыть файл и выполнить небольшое проверочное действие в копии.
Тексты Т-4 в нашем примере содержат заголовки, описания, подписи полей и сообщения формы. У каждого блока указаны страница и язык. Так исполнитель понимает, где применяется фраза, и не принимает неподтверждённый перевод за готовое содержание.
Макеты М-3 доступны для редактирования. В них обозначено, какие экраны соответствуют П-7, а какие относятся к будущему фильтру П-8. Отдельно сохранены изображения продукции в достаточном качестве и сведения о происхождении материалов. По шрифтам, фотографиям и приложениям проверяют разрешённое использование и условия соответствующих сервисов; сам факт получения файла эти вопросы не решает.
Для отдельной разработки передают код, инструкции подготовки и публикации, сведения о необходимом окружении и зависимостях. Для конструктора — доступный способ продолжить редактирование в используемой платформе. Не требуйте от любого сайта одинакового набора файлов: проверка должна соответствовать его устройству и порученной работе.
Если материал потерян, обозначьте пробел. Например: «Фотография доступна только в уменьшенном варианте на странице; оригинал не найден». Затем согласуйте получение оригинала, замену или работу с ограничением. Такая запись точнее обещания «все материалы переданы», которое скрывает необходимость дополнительных действий.
Перепишите незавершённые задачи через результат
«Доделать фильтр» не объясняет объём. Напишите текущее состояние, ожидаемое поведение, зависимость и способ приёмки. Отдельно фиксируйте, кто согласует содержание, кто выполняет изменение и кто проверяет его. Если новая команда ещё не оценила работу, не представляйте старую оценку как её обещание.
| Задача и состояние | Что требуется для завершения | Кто продолжает и что зависит от других |
|---|---|---|
| З-12. Фильтр реализован в П-8, не принят | Подтверждённые материалы дают правильные позиции; сброс возвращает шесть карточек; пустой результат понятен | Новый разработчик — после принятия задачи. Менеджер сначала подтверждает свойства продукции |
| З-13. Два немецких текста подготовлены, не согласованы | Специалист подтверждает термины; редактор сверяет подписи и соответствие русскому предложению | Редактор продолжает после проверки специалистом. Публикация поручается отдельно |
| З-14. Ошибка подтверждена: выбранный материал теряется при возврате из формы | Повторить описанный сценарий на телефоне; после исправления выбор сохраняется | Новый разработчик принимает воспроизведение и оценивает исправление; владелец согласует работу |
| З-15. Второй получатель заявки не настроен | Назначен сотрудник, определён порядок работы, оба адресата получают контрольный запрос | Владелец назначает сотрудника; техническую настройку согласуют после этого |
| З-16. Виджет обратного звонка предлагался, заказ не подтверждён | Владелец решает, нужна ли функция; при согласовании определяется отдельный объём | Владелец принимает решение. Новому подрядчику передаётся вопрос, а не заказ на внедрение |
Эти состояния означают разную работу: проверить готовое, дождаться содержания, исправить воспроизводимую ошибку, получить организационное решение. Одинаковая отметка «в процессе» скрыла бы различия. Задачу, которую решили не выполнять, закрывают с основанием, сохраняя запись, чтобы её случайно не вернули в план.
Для З-14 дополнительно нужны шаги, устройство и наблюдаемый результат: выбрать материал, открыть форму, вернуться к каталогу и увидеть сброшенный выбор. Добавьте дату проверки и безопасную демонстрационную запись. Личные данные посетителя для такого воспроизведения не требуются.
Разделите уточнение задачи и принятие обязательства
Получение списка ещё не означает согласие выполнить его в прежний срок и бюджет. Новый подрядчик проверяет материалы, задаёт вопросы, определяет зависимости и оценивает конкретное поручение. Владелец решает, какие работы продолжать сейчас. Эти действия фиксируют отдельно от технической передачи сайта.
Для каждой принятой задачи запишите исполнителя, согласованный результат, срок или дату следующего решения и необходимые условия. В З-13 срок публикации зависит от проверки терминов. В З-12 разработчик может проверить механизм, но не способен самостоятельно подтвердить свойства продукции. Зависимость должна иметь своего ответственного.
Шаблон документации решений Atlassian предлагает обозначать статус, участников, последствия, варианты и дальнейшие действия. Для нашей ведомости это полезный ориентир: человек, который ведёт задачу, и человек, который утверждает результат, могут быть разными. Участники должны понимать свою роль, а не просто оказаться вписанными в таблицу.
Если прежняя и новая команды по-разному оценивают выполненную работу, выделите проверяемую часть: какой результат показан, какие условия приёмки были согласованы и что удалось воспроизвести. Оплату, договорные разногласия и техническое состояние нельзя свести к одной отметке «готово». Ведомость сохраняет факты и нерешённые вопросы для дальнейшего согласования.
Принимайте передачу через небольшую рабочую проверку
На встрече новая команда должна показать, что понимает записи и может продолжить порученную работу. Выберите типовые действия в проверочной среде. Обсуждение без открытия материалов не выявит потерянный файл, устаревшую инструкцию или недоступный вариант сайта.
| Что показывает получатель | Признак готовности | Что делать, если не получилось |
|---|---|---|
| Находит состояние П-7 | Понимает, какая версия опубликована и где её материалы | Установить связь между работающим сайтом и переданными материалами |
| Объясняет Р-1 и Р-3 | Отличает принятый способ расчёта от неподтверждённого фильтра | Уточнить статус и основание у владельца; сохранить вопрос открытым |
| Редактирует текст в копии | Изменение выполняется в актуальном редактируемом материале | Восстановить доступ к нужному файлу или согласовать замену |
| Повторяет ошибку З-14 | Получает описанный результат или записывает условия, при которых он отличается | Уточнить сценарий до оценки исправления |
| Проверяет путь контрольного запроса | Назначенный менеджер подтверждает получение согласованных данных | Назначить исполнителя проверки доставки; не считать сообщение на экране доказательством |
| Находит порядок восстановления | Знает, что восстанавливается, кем и из какой проверенной копии | Уточнить покрытие и назначить проверку; не обещать восстановление по одному наличию архива |
Контрольный запрос заранее обозначают как проверку и направляют согласованному получателю. Не используйте настоящую заявку для демонстрации. Если проверка не входит в текущую встречу или требует отдельного доступа, назначьте действие и ответственного вместо автоматической отметки об успехе.
Часть передачи может быть принята, пока другие пункты остаются открытыми. Например, тексты доступны, а инструкции публикации ещё требуют уточнения. Зафиксируйте, какие действия новая команда уже может выполнять и какие пока блокируются. Общая подпись под документом не должна скрывать эти ограничения.
Назначьте ответственность на переходный период
Пока передача идёт, посетители продолжают отправлять запросы, а сотрудники — менять предложение. Запишите, кто принимает сообщение о проблеме, кто вправе публиковать изменения и кто связывается с владельцем при остановке важной функции. Дата окончания старого договора сама по себе не подтверждает готовность новой команды.
В учебном примере прежний исполнитель отвечает за согласованные технические действия до подтверждения передачи. Новый принимает сопровождение после проверки материалов и отдельного согласования условий. Если остаётся промежуток без технического сопровождения, владелец должен видеть его и назначить временный порядок действий. Нельзя оставлять обеим сторонам предположение, что уже отвечает другая.
Укажите точку переключения ответственности и способ её подтверждения: кто принял сопровождение, когда и в каких границах. Для открытых задач переключение записывают отдельно. Можно принять обслуживание П-7, но ещё обсуждать разработку фильтра П-8. Разработка новой функции и поддержание работающего сайта имеют разные условия.
После подтверждённой передачи отдельно проверяют, какие доступы прежней команде больше не нужны, и меняют их по согласованному порядку. До этого нужно убедиться, что компания и назначенный исполнитель могут продолжать работу. Резкое отключение единственного рабочего доступа способно остановить исправление проблемы во время перехода.
Начните новую работу с подтверждённых пробелов
Первый план нового подрядчика строят по ведомости. В нашем примере сначала подтверждают материалы продукции и воспроизводят З-14. Затем оценивают фильтр. Переводы ждут специалиста, второй адресат — назначения сотрудника, а виджет обратного звонка — решения владельца. Ни одна из этих зависимостей не исчезает при смене команды.
Согласуйте небольшой первый результат, который можно принять: например, устранение З-14 с повторной проверкой на указанном устройстве. Это позволяет проверить совместную работу и актуальность инструкций. Полная переделка сайта без разбора причин старых решений может повторить прежние ошибки и увеличить объём без ясного основания.
Обновляйте ведомость по мере продолжения: новый результат, дата проверки, кто его подтвердил, что заменено или остаётся открытым. Передача завершена для конкретного участка, когда получатель понимает его состояние, располагает нужными материалами и подтвердил свою ответственность. Для постановки нового объёма используйте отдельный бриф, а для регулярных действий — план обслуживания.
Официальные и профильные ссылки
Эти материалы дают контекст для данных, правил и рекомендаций на странице.
- AWS Prescriptive Guidance — журнал архитектурных решений (англ.) Источник проверен: 07.10.2026
- Atlassian — документация принятия решений и распределение ролей (англ.) Источник проверен: 07.10.2026
Удобнее написать напрямую?
Коротко укажите компанию, рынок и задачу — так разговор будет предметнее.