ИТ-Стайер

Работа с заказчиком – это одно из ключевых направлений деятельности владельца продукта. Невозможно культивировать ценность продукта в отрыве от заказчика. Умение формализовать, оцифровать, оценить хотелки на предмет адекватности, реализуемости и полезности – это тот набор компетенций владельца продукта без которого его деятельность не может быть эффективной. Вот почему глубокие знания предметной области, бизнес-процедур для ИТ-директора являются более важными, чем знания конкретных ИТ-платформ, технологий и решений.

Наличие внутреннего владельца продукта – обязательное условие, если вы хотите создать что-то стоящее. Если его нет, то другого варианта, как брать что-то на стороне и мириться с тем, что вам подсунули попросту нет.

Теперь поговорим об управлении внедрением изменений в ИТ-системы.

Вопрос достаточно комплексный и затрагивает такие темы как организацию среды разработки, обеспечение тестирования, подготовку и установку обновлений, разработку документации и обучающих материалов, проведение обучения и аттестации пользователей.

С технической точки зрения здесь все достаточно понятно. Есть масса описанных подходов и проверенных инструментов. Основным является то, что это нужно организовать системно: должны быть определены жесткие правила и отступать от них можно только в случае самой-самой острой необходимости.

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

– Ни одно тестирование не гарантирует, что на “боевых данных” все будет гладко.

– Как бы хорошо вы не прорабатывали, но пользователь всегда найдет вариант, который вы не предусмотрели.

– Два отлично работающих и оттестированных по отдельности модуля при совместной установке могут поломаться.

– Никогда не нужно проводить обновления в пятницу или перед праздниками.

– Даже изменение цвета или местоположения кнопки – это обновление.

– О любых изменениях нужно оповещать пользователей.

– Большинство пользователей не читают “Что нового?”

– Косяк обновления может вылезти не только на следующий день, но через месяц.

– Все сотрудники, чьи изменения вошли в релиз, должны быть на месте на следующий рабочий день.

– Обо всех странностях после обновления служба поддержки должна немедленно информировать владельца продукта.

Ну и чтобы текст не был таким сухим приведу два реальных случая, которые имели место во время моей работы в торговой сети Магнит.

Случай первый. Сеть уже насчитывала порядка 1500 магазинов. Каждый магазин имел свою независимую базу данных и система была построена так, что большинство обновлений требовало запуска ряда скриптов, который обеспечивала специальная программа “робот”. Эта программа была сама по себе достаточно уникальна для того времени, поскольку по сети этих “роботов” обеспечивалась передача данных между объектами и они же могли запускать автоматически достаточно большой набор сервисных процедур. Это было прогрессивно: запущенное по сети обновление автоматом устанавливалось практически на все объекты в течении пары дней (связь тогда была еще той), ну а там где возникали ошибки уже подключались люди. Такой подход позволял существенно экономить на обслуживании.

В один теплый пятничный вечер раздается телефонный звонок от руководителя службы технической поддержки и он докладывает, что у него шквал звонков из магазинов по поводу неработающих касс. Потом подсчитали, что за полчаса в поддержку поступило порядка 600 звонков. Кто знает, что для продуктового ритейла в магазинах у дома пятничный вечер – тот поймет.

Сразу сыграли тревогу. Крайнего нашли быстро. Ответственный сотрудник отдела сопровождения запустил обновление и по мере обработки обновления роботами магазинные кассы вставали. Потом выяснилось, что сотрудник запустил обновление пораньше, поскольку ему нужно было на день рождения к родственнику и он торопился.

Первое что сделали, это прервали обмен, чтобы те “роботы”, которые не успели получить обновление не повлияли на работу магазинов.

Дальше обнаружили, что кассы, работающие под правами директора магазина или товароведа продолжают работать. На пострадавшие магазины сразу отправили соответствующие инструкции, что с учетом малого количества касс сняло напряженность.

Параллельно шел разбор и поиск ошибки. Оказалось, что ошибка возникала на уровне предоставления прав между объектами базы данных. При формировании обновления в него попало два модуля, каждый из которых по отдельности был протестирован и к ним нареканий не было, но при совместной установке возникал конфликт. Нужно сказать, что на тестовой группе магазинов все прошло гладко именно по тому, что туда модули ставились по отдельности, а в плановое обновление их включили в одну сборку и не проверили. Исправление заняло буквально несколько секунд.

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