Демонстрация рабочей системы закончилась, объективно все работает, но заказчик уходит с ощущением «что‑то здесь не так». Как итог: акт не подписан, в почте — письма с претензиями по доработкам. Многомесячный проект встаёт, доверие заказчика угасает, сроки и бюджет расползаются.

Когда в приемо‑сдаточных испытаниях участвовало 2–3 человека, процесс шел гладко: проверили функциональность, подписали протокол — и готово. После того, как мы расширили состав команды до 7 человек, процесс поломался: появилась несогласованность действий, разночтения в понимании задач, недопонимание между ролями.

Мы решили изменить подход к ПСИ, сделать его системным и воспроизводимым. Делюсь опытом, который помог нам повысить качество испытаний и выстроить понятную методику работы.

Шаг 1. Анализируем текущее положение дел

Перед командой стояли вопросы:

  • Как должны проходить «идеальные» ПСИ?

  • Как оцифровать испытания, если процесс кажется субъективным?

  • Как обеспечить единое понимание у всех участников?

Чтобы найти ответы, мы пошли поэтапно. Мы провели серию интервью с тимлидами, специалистами и смежными командами и руководителями подразделений и выяснилось:

  • Исполнители были уверены, что их задача — показать работающий функционал.

  • Руководители ожидали, что ПСИ подтвердит готовность системы к реальной эксплуатации.

  • Заказчики хотели услышать, как новая функция встроится в их процессы и кто за что отвечает.

То есть общее представления о том, как надо проводить ПСИ совпадали, но ожидания от других ролей и команд различались. Это приводило к взаимным претензиям и конфликтам.

Шаг 2. Формируем единую картину мира

Чтобы устранить разночтения, мы создали тренинг-курс. Он включал:

  • Видеоуроки ( 20–25 минут), где каждый эксперт рассказывал о своей зоне ответственности.

  • Краткие презентации и текстовые саммари.

  • Тесты для закрепления.

Все материалы мы разместили в LMS в корпоративном университете, а прогресс сотрудников отслеживали. Но теория сама по себе не дает уверенности. Поэтому мы добавили бизнес-игру, максимально приближенную к реальным ПСИ. Как это выглядело:

  • Участники делились на «Заказчиков» и «Исполнителей».

  • Первые придумывали каверзные вопросы и создавали препятствия, вторые должны были пройти испытание.

  • Раунды шли по 15–20 минут, затем команды менялись ролями.

В процессе мы наблюдали, кто умеет «держать удар», кто теряется под давлением, кто способен объяснять сложные вещи простыми словами. Для вовлеченности использовали карточки ролей: например, «раздраженный заказчик», «внимательный юрист», «строгий врач-методист». Это делало игру живой и напоминало реальные переговоры в ходе испытаний. Конечно же, было важным обеспечить прохождение тренинга всеми действующими сотрудниками.

Шаг 3. Закрепляем новый подход в регламентах

Мы договорились: контроль должен быть прозрачным и независимым. Руководителю не нужно «ловить» сотрудника за руку, а достаточно свериться с контрольными точками.

Мы внедрили:

  • Единый протокол ПСИ в Confluence — теперь у нас есть база, где хранится вся история испытаний.

  • Регулярный анализ протоколов (раз в неделю) — мы смотрим динамику, выявляем повторяющиеся проблемы.

  • Метрику эффективности (EPI): доля замечаний, найденных на внутренних ПСИ, по отношению к общему числу после реальных испытаний. Наша цель — минимум 80%.

Так у нас появился инструмент, который позволяет не просто «чувствовать», а измерять качество испытаний. Достаточно посмотреть на протоколы: по ним видно, как команда готовится к ПСИ и реагирует на замечания.

Итоги

Каких результатов мы добились благодаря новому подходу:

  1. Участники команд теперь одинаково понимают все этапы и цели процессов при подготовке и проведении ПСИ.

  2. Появился реальный инструмент измерения качества проводимых испытаний.

  3. Ошибки стали выявляться раньше, а не на глазах у заказчика.

  4. За счет данных мы можем точечно улучшать процесс и работать как с отдельными сотрудниками, так и с целыми командами.

Главное — мы превратили подготовку к ПСИ в реальный инструмент развития команды.

А как в ваших проектах проводятся итоговые испытания? Проводите ли вы «работу над ошибками»? Поделитесь опытом — интересно изучить ваши практики!