Переход в другую отрасль индустрии для ИТ-директора заключает в себе как новые вызовы, так и новые возможности. Марк Кац, ИТ-директор Американского общества композиторов, авторов и издателей (American Society of Composers, Authors and Publishers, ASCAP), рассуждает о том, что необходимо предпринять, чтобы обеспечить успех перехода.

Свою карьеру Кац начал в секторе финансовых услуг и, постепенно поднимаясь вверх по служебной лестнице в различных структурах, в итоге достиг позиции ИТ-директора в крупной перестраховочной компании. Переходя в ASCAP, он поставил своей целью превратить ИТ-службу в более компактную и гибкую организацию. При полной поддержке со стороны руководства компании Кац предпринял ряд серьезных действий по преобразованию ИТ-департамента.

“В момент моего выхода на новое место работа отдельных групп была плохо организована вплоть до того, что некоторые из них самостоятельно работали над проектами конкретных пользователей; между членами групп не было эффективной взаимосвязи, так что они не знали даже, кто какие решения предлагает и каким образом собирается использовать их, — говорит Кац. — Можно сказать, что ИТ-департамент действовал как пункт приема заказов на огромное количество работ по исправлению текущих проблем и мелких ошибок. О прозрачности портфеля проектов говорить не приходилось, причём для наиболее крупных из них использовалась традиционная “каскадная” методология. Но важнее всего было то, что предлагаемые изменения планировались для каждого конкретного запроса бизнеса без учета их общего влияния на весь портфель проектов, на бизнес-процессы и технологический департамент. Помимо этого существовало несколько “невидимых” проектов, не имевших никакого реального смысла с точки зрения бизнеса”.

Налаживая прозрачное и разумное управление, Кац тесно взаимодействовал с управляющим ASCAP Элом Уоллесом, со своими ведущими ИТ-специалистами и руководителями бизнес-направлений.

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

Затем наступила очередь самих ИТ-методов. “Я большой поклонник гибкой agile-методологии и самоорганизующихся команд”, — пояснил Кац. Разобравшись с тем, какая культура царит в ASCAP, он захотел удостовериться, что agile-методология была должным образом представлена сотрудникам компании. “В действительности agile представляет собой гораздо больше, чем просто изменение методологии, — рассказал он. — Речь идет о выверке и настройке процессов, об их прозрачности и нацеленности на достижение результата в партнерстве с бизнесом. Такой подход повышает информированность ИТ-службы, так что мы теперь в состоянии привлекать бизнес к полномасштабному участию в наших agile/scrum-мероприятиях. А чтобы окончательно закрепить переход ASCAP на agile-методологию, мы стали организовывать встречи представителей бизнеса и технических специалистов в формате открытой площадки. Посещаемость таких встреч оказалась выше всяких похвал”.

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

“Если говорить о механике agile, то начинаем мы с создания эпической саги для каждой продуктовой команды, а затем эту историю разбиваем на короткие временные отрезки (спринты), приоритеты которых определяются бизнесом, — говорит Кац. — После этого проводим ежедневные пятнадцатиминутные совещания, нацеленные на то, чтобы каждые две-три недели выпускать действительно полезное ПО. Кратко наш подход характеризуется словами “да, мы можем”; ответ “нет, это не получится” для нас неприемлем. Изменения приветствуются всегда, даже на исходе спринта. Бизнес расставляет свои приоритеты, и регулярные совещания проходят в очень открытой и честной атмосфере. Эта методика обеспечила повышение скорости работы над проектом, но что ещё важнее, позволила значительно улучшить качество коммуникаций с представителями бизнес-структур”.

Другая инициатива Каца касалась управления. В её рамках он разработал офис управления проектами (ОУП) для ключевых проектов: “ОУП организует интегрированный процесс документооборота в масштабах всей компании. Его смысл — обеспечить повышенную прозрачность, которая далее будет развиваться на основе доверия бизнеса. В компании ASCAP используется федеративная модель управления с полным участием бизнеса и ИТ. Крупные проекты, превышающие определенные метрики, одобряются голосованием за или против на заседании исполнительного комитета. Все другие проекты оцениваются с точки зрения взаимодействия и избыточности и затем получают приоритеты с точки зрения бизнеса”. Поддержка Каца со стороны Уоллеса явилась гарантией того, что ИТ-служба всегда будет иметь полную информацию о наиболее важных для бизнеса проектах.

В момент выхода Каца на новую работу в ASCAP реализовывался крупномасштабный инфраструктурный проект, уже доведенный примерно до середины. “Как новый ИТ-директор первоначально я был вынужден немало времени проводить со своими менеджерами, чтобы разобраться в приложениях и инфраструктуре. Поставщики не предлагали нам каких-либо готовых коробочных продуктов, каждое решение был разработано для конкретного авторского общества, по числу которых у ASCAP нет равных во всём мире. Но при этом они зачастую старались продать свои решения, не имея полного представления о потребностях в музыкальной индустрии. Таким образом много труда тратилось впустую. Сейчас я опираюсь на данные независимых источников, таких как Gartner, и коллег из ИТ-индустрии, которым могу доверять. Помимо этого при переходе в новую для себя область бизнеса чрезвычайно важно пользоваться материалами отраслевых конференций”.

Кац начал контролировать количество совещаний, которые он посещал, сконцентрировавшись на том, чтобы каждым совещанием эффективно управлять. “Многие встречи ограничивались дискуссиями по поводу повседневных проблем, выливавшимися в бесконечные разговоры о дизайне и поиске решений на месте,— продолжает Кац. — Я поручил своим менеджерам подобные вопросы решать со своими подчиненными самостоятельно и постарался сфокусировать совещания, проводимые мной, на выработке конкретных решений. Необходимо обращать внимание на повестку дня таких совещаний и концентрироваться на том, что вы хотите получить по их завершении”.

Кац обнаружил, что в результате таких шагов у него появилось больше времени для встреч с представителями бизнеса и непосредственными подчиненными: “Я каждую неделю разговаривал с глазу на глаз со своими сотрудниками, а также с топ-менеджерами компании. Помимо этого я с сотрудниками всей компании проводил ежеквартальные совещания, на которых выступали представители бизнеса и обсуждалась обновленная концепция развития ИТ в организации в целом”.

В общении с бизнесом очень важно организовать ясные и постоянные взаимоотношения, отмечает Кац: “Необходимо обосновать и показать преимущества каждого своего шага. При этом разговор нужно вести на стратегическом уровне, не опускаться до мелочей. Понять особенности мыслительного процесса каждого человека, разобраться, какие проблемы его сейчас волнуют в наибольшей степени — вот что важно. И самому говорить на том же языке, что и бизнес. Объяснять преимущества обновления инфраструктуры, не демонстрируя при этом расчеты повышения производительности и экономии финансов, — бессмысленно”.

И наконец Кац считает, что прежде чем начинать какие-либо изменения, необходимо ближе познакомиться с людьми и культурой, принятой в организации: “Требуется время, чтобы получить поддержку в компании, соотнести разные позиции, понять, когда и как нужно говорить “нет”, и расставить правильных людей на правильные места”.