Джин Ким - Руководство по DevOps

В то время Кортни Кисслер была старшим директором по системам доставки и технологиям продаж, ответственным за значительную часть технологической организации работы, включая системы в обычных магазинах и веб-узле электронной коммерции. Как позже описывала Кисслер, «в 2011 г. технология организации работы Nordstrom была оптимизирована для экономии расходов, мы передали на аутсорсинг многие технологические функции, у нас был ежегодный цикл планирования с большими заданиями “каскадного” выпуска ПО. И хотя планы выполнялись на 97 % по показателям сроков выпуска, бюджета и достижения целей, мы были недостаточно оснащены для достижения целей пятилетней бизнес-стратегии, потребовавшейся от нас, после того как компания Nordstrom начала оптимизировать скорость работы, а не расходы».

Кисслер и группа технологии управления в Nordstrom были вынуждены принять решение, с чего именно начинать прикладывать усилия по трансформации. Они не хотели вызывать потрясений во всей системе. Вместо этого они хотели бы сосредоточить внимание на отдельных областях бизнеса, чтобы можно было экспериментировать и учиться. Группе была важна победа на первом этапе: она дала бы всем уверенность, что улучшения могут быть повторены в других областях бизнеса компании. Как именно этого достичь, было пока неизвестно.

Внимание сосредоточили на трех областях: на клиентском мобильном приложении, на системе ресторанов, расположенных в их магазинах, и на их цифровых данных. В каждой из этих сфер имелись бизнес-цели, недостигаемые при обычной организации работ. Легче было пробовать различные методы работы. И вот рассказ о первых двух.

Мобильное приложение Nordstrom при запуске потерпело неудачу. Как сказала Кисслер, «наши клиенты были крайне разочарованы продуктом, и когда мы запустили его в App Store, то получили много одинаковых отрицательных отзывов. Что еще хуже, существующие структуры и процессы (то есть “система”) были разработаны так, что обновления выпускались два раза в год». Другими словами, любые исправления попадали к клиенту спустя несколько месяцев.

Поэтому первой целью было делать выпуски быстрее или по требованию, обеспечивая более быстрые итерации и способность реагировать на обратную связь, предоставляемую клиентами. Разработчики создали специализированную продуктовую группу, предназначенную исключительно для поддержки мобильных приложений, при этом данная группа должна была самостоятельно реализовывать задачи, тестировать и доставлять ценность клиентам. Она больше не зависела от других и координировала свою деятельность с десятками групп внутри Nordstrom. Кроме того, был произведен переход от планирования на год к непрерывному процессу планирования. В результате появился единый список приоритетных работ по мобильному приложению на основе потребностей клиентов, что привело к исчезновению конфликта приоритетов, имевших место, когда группа поддерживала несколько продуктов.

На следующий год ликвидировали тестирование как отдельный этап работы: вместо этого его интегрировали в повседневную деятельность [40]. Вдвое увеличили количество функциональных возможностей, создаваемых за месяц, и вдвое уменьшили количество дефектов, добившись тем самым отличного результата.

Во второй области действий основное внимание было уделено системам поддержки расположенных в магазинах ресторанов под маркой Café Bistro. В отличие от потока создания ценности мобильного приложения, где необходимо было сократить время выхода на рынок и увеличить скорость разработки новых функциональных возможностей, здесь бизнес нуждался в уменьшении расходов и повышении качества. В 2013 г. компания Nordstrom завершила разработку 11 «концепций изменений в ресторанах», потребовавших изменений в работе соответствующих торговых точек, в результате чего увеличилось число жалоб клиентов. Вызывало тревогу, что на 2014 г. было запланировано внедрение 44 подобных концепций — в четыре раза больше, чем в предыдущем.

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

Команда смогла определить проблемные области — сбор информации и развертывание — и сосредоточила на них усилия по улучшению. Она смогла сократить время развертывания кода на 60 % и число ошибок, требующих вмешательства вручную, на 60–90 %.