Работа с заказчиком – это одно из ключевых направлений деятельности владельца продукта. Невозможно культивировать ценность продукта в отрыве от заказчика. Умение формализовать, оцифровать, оценить хотелки на предмет адекватности, реализуемости и полезности – это тот набор компетенций владельца продукта без которого его деятельность не может быть эффективной. Вот почему глубокие знания предметной области, бизнес-процедур для ИТ-директора являются более важными, чем знания конкретных ИТ-платформ, технологий и решений.
Наличие внутреннего владельца продукта – обязательное условие, если вы хотите создать что-то стоящее. Если его нет, то другого варианта, как брать что-то на стороне и мириться с тем, что вам подсунули попросту нет.
Теперь поговорим об управлении внедрением изменений в ИТ-системы.
Вопрос достаточно комплексный и затрагивает такие темы как организацию среды разработки, обеспечение тестирования, подготовку и установку обновлений, разработку документации и обучающих материалов, проведение обучения и аттестации пользователей.
С технической точки зрения здесь все достаточно понятно. Есть масса описанных подходов и проверенных инструментов. Основным является то, что это нужно организовать системно: должны быть определены жесткие правила и отступать от них можно только в случае самой-самой острой необходимости.
Хотелось бы поделиться некоторыми моментами, с которыми приходилось сталкиваться и которые могут быть полезными.
– Ни одно тестирование не гарантирует, что на “боевых данных” все будет гладко.
– Как бы хорошо вы не прорабатывали, но пользователь всегда найдет вариант, который вы не предусмотрели.
– Два отлично работающих и оттестированных по отдельности модуля при совместной установке могут поломаться.
– Никогда не нужно проводить обновления в пятницу или перед праздниками.
– Даже изменение цвета или местоположения кнопки – это обновление.
– О любых изменениях нужно оповещать пользователей.
– Большинство пользователей не читают “Что нового?”
– Косяк обновления может вылезти не только на следующий день, но через месяц.
– Все сотрудники, чьи изменения вошли в релиз, должны быть на месте на следующий рабочий день.
– Обо всех странностях после обновления служба поддержки должна немедленно информировать владельца продукта.
Ну и чтобы текст не был таким сухим приведу два реальных случая, которые имели место во время моей работы в торговой сети Магнит.
Случай первый. Сеть уже насчитывала порядка 1500 магазинов. Каждый магазин имел свою независимую базу данных и система была построена так, что большинство обновлений требовало запуска ряда скриптов, который обеспечивала специальная программа “робот”. Эта программа была сама по себе достаточно уникальна для того времени, поскольку по сети этих “роботов” обеспечивалась передача данных между объектами и они же могли запускать автоматически достаточно большой набор сервисных процедур. Это было прогрессивно: запущенное по сети обновление автоматом устанавливалось практически на все объекты в течении пары дней (связь тогда была еще той), ну а там где возникали ошибки уже подключались люди. Такой подход позволял существенно экономить на обслуживании.
