В книжке «Проект “Феникс”. Роман о том, как DevOps меняет бизнес к лучшему», прочитанной на днях, внезапно нашелся замечательный инструмент для анализа требований и понимания, а что же Заказчику действительно нужно. В книге речь идет о работе руководителя службы ИТ-поддержки, который пытается понять, а что же именно в его работе нужно поменять (книга еще много о чем, но в данном контексте – именно об этом), что бизнес компании от этого выиграл.
Цитата:
Но настоящая бездонная пропасть претензий раскрывается перед нами, когда я спрашиваю его, как выглядит его плохой день.
«Плохой день? – повторяет он, с недоверием смотря на меня. – Ну что же, Билл, катастрофой можно назвать тот день, когда системы внутренней отчетности и телефонные системы, которыми ты управляешь, перестали работать несколько недель назад. Только из-за сбоя в системах отчетности и планирования ресурсов мы получили столько звонков от клиентов, вопящих о задерживающихся счетах и отчетах, что ты себе представить не можешь, а двое из них отменили заказы на четверть миллиона долларов каждый в один момент. Нам приходится прикладывать невероятные усилия, просто чтобы возобновить сделки с нашими лучшими покупателями на 1,5 млн долларов».
Рон нависает над столом. «А когда телефоны перестали работать за несколько дней до конца квартала и клиенты не могли у нас ничего заказать или что-то изменить в своих заказах?! Это заморозило сделок еще на 1,5 млн долларов, а десять клиентов провели переоценку своих контрактов, закладывая еще по 5 млн долларов на риски.
Ты делаешь мою работу намного, намного тяжелее, приятель, – продолжает Рон. – Многие мои люди потеряли свои бонусы из-за вещей, абсолютно им неподконтрольных».
Ради интереса попробовала использовать на очередной встрече по сбору требований к информационной безопасности, задав Заказчику вопрос «Ну вот мы запустили систему, и что-то пошло не так. Как будет выглядеть самый плохой день, если система встанет?». И внезапно оказалось, что несмотря на то, что в целом сама система некритична для бизнеса – есть 2 недели в году, когда основная система отключается, и та, которую мы делаем сейчас, дублирует ее. И если в эти 2 недели система упадет или что-то случится с данными – может случиться много чего плохого вплоть до полной остановки производства. Теперь требования к надежности мы будем кардинально пересматривать плюс вносить изменения в контракт на поддержку, чтобы иметь возможность посадить человека на круглосуточный мониторинг работы на эти 2 недели.
Видимо, этот простой вопрос уводит человека от чисто технических аспектах, и он переключается на оценку бизнес-рисков. В общем, идея интересная, советую.
Добавить комментарий