Краткий ответ
План исправления проблем с подрядчиком связывает каждое нарушение с проверяемой причиной, действием, ответственным и условием приёмки. Предлагаемая схема на 30, 60 и 90 дней ведёт от проверки причин к подтверждению устойчивого результата. До старта согласуйте доступ к данным, границы работ и последствия срыва. В финале выбирайте между возвратом к прежнему формату, сокращением объёма и прекращением сотрудничества.
Когда нужен план исправления проблем с подрядчиком
Подрядчик снова переносит выпуск, но на встрече обсуждают уже следующую дату. План исправления проблем с подрядчиком нужен, когда обещания перестали помогать принимать решения. Он задаёт ограниченный срок, в течение которого исполнитель доказывает, что устранил причину срывов и способен выполнять согласованные обязательства.
Начните с факта: что подрядчик должен был сдать, когда, что сдал и где виден сбой. Не пишите «повысить качество»: по такой фразе нельзя принять работу. Если заказчик добавил задачу после оценки, это не то же самое, что срыв срока по прежнему объёму. Разберите эти случаи до встречи, иначе спор о том, кто что имел в виду, займёт всё время.
Возьмём условный пример, все его параметры — гипотетические допущения. Компания развивает сервис платной подписки. Подрядчик сорвал два согласованных выпуска: оплата проходила, но доступ выдавался с ошибкой. Заказчик намерен дать команде ещё один шанс. Стороны выбирают предложенный здесь горизонт в 90 календарных дней с проверками на 30-й и 60-й день; это управленческая схема, а не обязательный норматив.
Первое решение владельца сервиса — потребовать заменить разработчика. Но пока известно только место проявления ошибки, а не её причина. Замена человека не объясняет, почему неверная выдача доступа прошла проверку. Поэтому предмет плана — восстановление цепочки от согласованного требования до работающей подписки. Фамилии исполнителей появятся после диагностики, а не вместо неё.
План подходит, если стороны готовы работать вместе, имеют доступ к коду и могут проверить результат. Решение о старте принимает руководитель заказчика. Он назначает дату начала, владельца плана и того, кто примет работу. Не давайте подрядчику самому решать, прошёл ли он проверку. Право принять результат остаётся у стороны, которая отвечает за сервис.
От нарушения к причине, которую можно проверить
Причина пригодна для плана, если объясняет наблюдаемый сбой и подсказывает проверяемое изменение. «Команда невнимательная» не помогает выбрать действие. «Проверка оплаты не включала выдачу доступа» позволяет изменить проверку и затем убедиться, что разрыв закрыт.
Соберите задания, историю правок, тесты и журналы ошибок. Для каждого сбоя запишите факт, версию причины и то, что ещё нужно узнать. Если подрядчик винит заказчика в поздних ответах, сверьте даты запросов и ответов. Если заказчик нашёл дефект, сохраните способ его повторить. Без этих данных каждый принесёт на встречу свою версию прошлого, и выбрать между ними будет нечем.
В условном сервисе выясняется: проверяли успешный ответ платёжной системы, а появление доступа вручную смотрел разработчик. Исполнитель считал это достаточным, заказчик ожидал проверки всего пользовательского пути. Дополнительно тестовый контур использовал другую настройку уведомлений. Здесь есть две проверяемые причины: неполный критерий приёмки и несоответствие среды. Простое обещание тестировать тщательнее не устраняет ни одну.
Разделите меры сдерживания и устранения причины. В примере ручная сверка оплат с выданным доступом помогает обнаружить пострадавших подписчиков; её организует владелец сервиса. Исправление настройки и сквозная проверка предотвращают повторение конкретного сбоя; за них отвечает технический руководитель подрядчика. Пока вторая часть не доказана, ручная сверка остаётся временным контролем, а не свидетельством выздоровления проекта.
У заказчика тоже есть задачи: дать тестовые данные, принять сценарии, выделить время на проверку. Если он задержал вход, выясните, на какую работу это повлияло, и согласуйте новую дату её проверки. Не сдвигайте весь план сразу. Помогут критерии готовности и завершенности: по ним ясно, что уже можно брать в работу и что можно принять. Это стоит решить до спора о сроках.
Рабочая матрица: причины, контрольные точки и последствия
Главный документ — матрица восстановления. Каждая строка связывает нарушение с причиной, действием и доказательством, которое принимает заказчик. Ниже — заполненный образец для условного сервиса подписки. Все сроки и пороги в нём являются предлагаемыми условиями этого гипотетического плана.
Перед подписанием матрицы закрепите определения. Своевременный выпуск — результат, принятый к согласованной дате в неизменном объёме. Критическая ошибка в нашем примере — невозможность получить оплаченный доступ либо выдача доступа без основания. Источник даты — история согласованного плана, источник ошибок — журнал проверок и обращений. Подрядчик готовит материалы, назначенный проверяющий заказчика подтверждает их полноту и результат.
| Нарушение и причина | Корректирующее действие | Контрольная точка | Данные и ответственный | Условие приёмки | Последствие провала |
|---|---|---|---|---|---|
| Срыв выпуска: не проверяли выдачу доступа после оплаты | Согласовать полный путь подписчика и выровнять настройки тестовой среды | К 30-му дню | Технический руководитель передаёт сценарии и сравнение настроек; проверяющий заказчика повторяет запуск | Все пять согласованных сценариев воспроизводимы; различия сред устранены либо обоснованы | Не разрешать расширение работ; передать решение руководителям сторон |
| Ошибки подписки попадают в выпуск: отсутствует сквозная проверка | Включить согласованные сценарии в приёмку каждого выпуска | К 60-му дню | Руководитель тестирования передаёт протоколы и версии сборок; владелец сервиса принимает результат | Два последовательных выпуска в согласованные даты, без критических ошибок в проверяемых сценариях | Предложить сокращение объёма и отдельное решение по дальнейшей разработке |
| Улучшение держится на ручном вмешательстве | Повторить штатную приёмку и проверить работу контроля после выпуска | К 90-му дню | Руководитель поддержки передаёт журнал обращений; проверяющий сверяет его с проверками | Контроль выполняется без ручного исправления выдачи доступа; критических ошибок в проверяемом пути нет | Выбрать прекращение сотрудничества либо новый ограниченный объём по отдельному соглашению |
Добавьте в матрицу имена и ссылки на рабочие файлы. Данные нужно передать до встречи: заказчику требуется время, чтобы повторить тест. Нет протокола — нет подтверждения, даже если показ прошёл хорошо. Но и стопка отчётов сама по себе ничего не докажет. Запись запуска с версией сборки полезнее рассказа о том, как команда стала лучше следить за качеством.
До старта решите, как план влияет на оплату. Где подрядчик чинит дефект прежней работы, а где заказчик просит новую функцию? Запишите основание для каждой спорной задачи. Скидка, удержание платежа или новый порядок приёмки не становятся правом заказчика оттого, что попали в план. Сверьте их с договором; если нужно, согласуйте его изменение. Сам план договор не заменяет.
Укажите, кому передавать вопрос при срыве, что этот человек решает и какие работы идут до ответа. Например, руководители решают, можно ли дальше делать новые функции, если проверка не пройдена. Текущую ошибку команда при этом чинит в прежних границах. Все знают, что будет после провала. Иначе календарь встреч рискует стать единственным исправно работающим компонентом проекта.
Как проверить восстановление, не перепутав его с облегчением
Исправленная ошибка доказывает исправление ошибки. Для возврата к прежнему формату нужно дополнительно подтвердить, что команда способна повторить результат в штатном процессе. Проверяйте согласованный объём, исходные условия и работу контроля, а не только исчезновение жалоб.
В нашем гипотетическом примере стороны согласуют пять сценариев: успешная оплата, отказ платежа, повторное уведомление, задержанное уведомление и продление подписки. Для каждого заранее определяют ожидаемое состояние доступа. Эти сценарии не исчерпывают безопасность сервиса, зато позволяют проверить обнаруженный разрыв. Успех здесь нельзя распространять на другие интеграции, которые в испытание не входили.
На первой контрольной точке заказчик получает повторяемую проверку и согласованные настройки. На следующей подрядчик показывает предусмотренные матрицей последовательные выпуски. До заключительной проверки ручную сверку сохраняют как средство обнаружения ошибок, но отдельно отмечают каждое ручное исправление доступа. Иначе человек незаметно компенсирует дефект, а отчёт сообщает, что система восстановлена. Важно различать наблюдение за работой и подмену самой работы.
Сравнивайте один и тот же объём. Если для сдачи в срок убрали интеграцию, вы проверили меньшую задачу, а не прежний темп команды. Если продажи стоят, отсутствие жалоб ещё не доказывает, что доступ выдаётся верно. Запишите, что именно изменилось и какой вывод теперь можно сделать. Планку нельзя менять задним числом лишь затем, чтобы встреча закончилась на хорошей ноте.
В нашем примере можно выбрать компромисс: подрядчик наладил подписку, но не доказал, что может параллельно вести новые интеграции. Заказчик оставляет ему поддержку этого контура, а новые работы обсуждает отдельно. Здесь поможет модель владения программным сервисом: она задаёт, кто принимает правки и отвечает за сервис. При сокращении объёма важно явно передать задачи и права, иначе они повиснут между командами.
Когда продолжать работу, а когда остановить план
Возвращайте прежний формат, если подтверждены согласованные результаты и устойчивость процесса. Меняйте объём, если восстановлена только ограниченная часть работы. Решение о прекращении сотрудничества выносите, когда контрольные точки провалены или достоверная проверка стала невозможна.
Не каждой проблеме нужен полный срок плана. Если пропал доступ к коду или есть признаки утечки данных, сначала защитите сервис и поручите независимую проверку. План не заменяет ответ на инцидент. Если бизнес не может ждать, срок проверки причины должен быть короче. Смотрите на ущерб, который может принести продолжение работы, а не на то, как ровно даты ложатся в календарь.
Если причина во внешнем облаке или недоступном инструменте, спросите, что команда может изменить сама. Есть ли у вашей компании доступ к коду, копиям данных и тестовой среде? На что влияет поставщик облака? Обещание всё исправить мало значит, если подрядчик не управляет причиной. Перенос в другую среду стоит обсудить отдельно: он меняет задачи, ресурсы и то, что нужно проверить до приёмки.
Порядок запуска прост: владелец сервиса собирает факты, специалисты проверяют причины, стороны заполняют матрицу. Затем руководитель заказчика утверждает объём и ресурсы, а проверяющий назначает приёмку. До старта проверьте доступ компании к коду и документации. План передачи знаний поможет понять, сможет ли команда работать без одного из специалистов. Не откладывайте эту проверку до момента, когда он уйдёт.
Ближайший проверяемый шаг — выбрать одно нарушение и заполнить для него строку матрицы. Попросите подрядчика назвать причину, приложить подтверждение и предложить действие с условием приёмки. Заказчик должен суметь объяснить, как самостоятельно проверит результат. Если это не получается, сначала уточняйте обязательство или способ проверки. Дополнительное совещание не восполнит отсутствие наблюдаемого результата. Сразу договоритесь и о споре: кто повторит тест, если стороны увидят разные результаты, и какие данные будут решающими. Проверяющий должен иметь нужные права и среду, а не просить автора кода показать всё ещё раз. Это делает приёмку отдельным действием заказчика, а не частью выступления подрядчика.
В конце оформите решение: что принято, что не проверяли и кто ведёт работу дальше. Если прежний формат вернулся, сохраните новые правила приёмки. Если объём сокращён, перепишите границы задач. Когда сбой начался ещё в требованиях, проверьте результаты этапов разработки. Иначе план закроют, а причина нового срыва останется на месте.
Проверьте, где именно ломается разработка
Если восстановление выявило разрыв между требованиями, проверкой и выпуском, материал «Жизненный цикл ПО» поможет разобрать результаты этапов разработки и причины потери сроков и бюджета. Используйте его, чтобы согласовать, что подрядчик должен передавать на каждом этапе, прежде чем возвращаться к прежнему объёму работ.
Часто задаваемые вопросы
Чем план исправления отличается от списка претензий?
Претензии фиксируют нарушения. План добавляет причины, действия, сроки, доказательства, ответственных за проверку и последствия невыполнения. По нему можно принять решение о продолжении работы.
Обязательно ли давать подрядчику 90 дней?
Нет. Это предложенный горизонт для описанного гипотетического случая. Срок выбирают с учётом критичности сервиса, проверяемости результата и условий договора. Опасный инцидент требует немедленных действий.
Кто должен утвердить план со стороны заказчика?
Руководитель, который вправе согласовать ресурсы, объём и дальнейший формат сотрудничества. Технический проверяющий подтверждает результат, но не должен единолично решать коммерческие вопросы.
Что делать, если заказчик тоже задерживает работу?
Зафиксировать его обязательства и доказательства задержки. Затем оценить влияние на конкретную контрольную точку и согласовать изменение. Это не повод автоматически отменять ответственность подрядчика за остальные действия.
Можно ли приостановить оплату на время исправления?
Такое решение зависит от договора и обстоятельств приёмки. Сам план исправления не даёт права удерживать платёж. Условия оплаты и изменения обязательств нужно согласовать отдельно.
Как поступить, если подрядчик не признаёт причину?
Разделить подтверждённый факт и спорную гипотезу, согласовать способ её проверки. Если исполнитель отказывается предоставлять данные, фиксировать невозможность проверки и передавать решение руководителям сторон.
Можно ли закрыть план после успешной демонстрации?
Демонстрация подтверждает только показанный результат. Закрывать план стоит после выполнения согласованных условий, повторяемой проверки и подтверждения, что результат не поддерживается скрытым ручным исправлением.
Что сохранить после завершения восстановления?
Сохраните матрицу с решением, доказательства проверок, актуальные критерии приёмки и распределение ответственности. Они объясняют, на каком основании работа продолжена, ограничена или прекращена.
Руководит продвижением Scrile. Помогает компаниям и клиентам найти друг друга. Пишет про позиционирование, подготовку материалов и поиск соответствия продукта потребностям рынка в узких нишах.