Ранее я уже приводил аргументы против обновления на месте систем SQL Server, а также подробно описывал этапы перехода и рекомендации по понижению роли старого сервера и повышению роли нового в процессе «параллельной» миграции. В обоих случаях подчеркивалось, что идея теста приемки – огромное достоинство процедур параллельного обновления, и отказавшись от него, вы совершите большую ошибку.
В некоторых сетях тесты при приемке можно проводить без каких-либо затруднений, особенно если в организации применяются формализованные процедуры либо рекомендации по обеспечению контроля качества (и/или имеются соответствующие специалисты). Однако во многих организациях тесты при приемке могут создавать большие проблемы для администраторов баз данных. Дело в том, что в ходе проведения таких тестов администраторам обычно приходится упрашивать не относящихся к числу технических специалистов пользователей посвящать тестированию какую-то часть своего рабочего времени, подключаться к «тестовому» серверу или приложению, а затем, пробежавшись по всем экранам, пытаться удостовериться в том, что все работает корректно.
Для утверждения приоритета тестов можно использовать совещания. В качестве консультанта мне приходилось участвовать в переводе на новые версии SQL Server целого ряда организаций (в первую очередь тех, в штате которых не было работающих на полную ставку администраторов баз данных). В отдельных случаях планы миграции в целом и расписанные по срокам мероприятия могут откладываться. Так бывает, когда ключевые пользователи, ответственные за проведение испытаний, попросту не находят времени удостовериться, что все функционирует как полагается. К счастью, я обнаружил довольно удачный (хотя в чем-то не совсем корректный) способ сдвинуть дело с мертвой точки в случаях, когда пользователи, ответственные за тесты приемки, не спешат реагировать на неоднократные призывы взяться наконец за дело. Ключик, который я обнаружил, называется «совещания».
Увы, миром бизнеса правят совещания. И мы, продвигая в массы идею тестов приемки, можем взять это обстоятельство себе на службу. Лично я считаю, что многие совещания — пустая трата времени (и это в лучшем случае). Так что я не выступаю за проведение совещаний под лозунгом «Свистать всех наверх!», где вы будете «пропесочивать» тех или иных сотрудников за беспомощность или необязательность. Нет, ведь речь идет о людях, которые попросту слишком заняты (или неприспособлены для правильной расстановки приоритетов), чтобы провести столь необходимые испытания. Так вот, я нашел эффективный способ решения данной проблемы: достаточно запланировать часовое совещание с участием этих сотрудников на их рабочем месте.
Удовлетворяйте потребности конечных пользователей
В работе с людьми, которые постоянно обещают: «Да-да, я непременно займусь этим», но так ничего и не делают, обычно стоит применять такой жесткий инструмент, как рабочее совещание. Это, кстати, будет полезно как для них, так и для вас. В глазах сотрудников совещание даст «железный» повод для выделения какого-то времени на выполнение задания. Ну, а вы получите возможность пройтись по рабочему пространству пользователей и убедиться в том, что они сделали правильный выбор тестовых приложений и серверов, а также намерены наблюдать за ключевыми «экранами» или процессами, которые будут тестировать. Кроме того, вы сможете выяснить, каким образом ключевые пользователи применяют ваши приложения и данные. Наконец, если совещание провести правильно, это может оказать неоценимую помощь в установлении контакта с участниками мероприятия. Вы покажете им, что действительно стремитесь удовлетворить потребности конечных пользователей — и на вас не будут смотреть, как на безликого «айтишного диктатора», который далек от повседневных проблем и сидит где-то в высокой башне.