IT, ориентированное на результат
Я не являюсь теоретиком или практиком управления ИТ. Но в моем послужном списке были также и руководящие должности с определенным уровнем ответственности, были и собственные бизнесы, с которыми как-то надо было управляться. Видимо управлялся я с ними плохо, раз они больше не существуют. Но для плохого специалиста, как известно, дорога одна - в хорошие консультанты. А там, глядишь, можно и до начальника дорасти. Пока не дорос - порассуждаю об ИТ-отделах больших компаний, в которых я имел удовольствие поработать, а также о тех, что я наблюдал или видел.
ИТ-отделы во многих компаниях начинались (да зачастую и начинаются) с одиночек-кустарей, которые все умеют. Затем ИТ-отделы разрастаются, вместе с ростом бизнеса и его технологической составляющей нанимаются на работу все больше и больше специалистов, а потом в один прекрасный момент случается коллапс, когда управлять этим скопищем людей больше невозможно, проблемы пользователей не решаются, и как всегда - мечта любого администратора - это выкатывание нового релиза программистами в пятницу вечером без тестов и без участия администратора, что обычно приводит к остановке работы на все выходные.
В этот момент большое руководство компании обычно в первый раз обращает внимание на ИТ-отдел и начинает судорожно выбирать себе директора ИТ. Обычно выбор останавливается на каком-нибудь ITIL-пересертифицированном специалисте и начинается на предприятии процесс внедрения ITIL. Процесс этот, как показывает моя практика, никогда не заканчивается. Сменяются ITIL-специалисты, открываются и закрываются отделы, создаются и снова исчезают рабочие группы, проводятся многочасовые митинги и километры лесов исчезают в многостраничных документах, но все время находятся новые неурегулированные процессы, которые надо описать, формализировать, назначить роли всем исполнителям, попробовать автоматизировать и т.д. При этом несмотря на видимый эффект от использования ITIL, по мере разрастания ИТ-отдела (а он разрастается - всегда) качество работы ИТ опять ухудшается. И даже ITIL уже не в состоянии помочь - большое начальство все больше говорит о технологических проблемах.
В последней IBM CEO Study впервые за 8 лет ее проведения руководители бизнесов обозначили именно технологические факторы, как наиболее влияющие на бизнес предприятия. В 2004 г. те же самые технологические факторы были на 6м месте, а на 1м месте все эти годы был маркетинг. Сейчас именно технологии дают компании (даже не ИТ-компании, а обычной компании из обычного «реального» мира) конкурентные преимущества. А соответственно технологические проблемы создают вполне конкретные проблемы для бизнеса. Как пример - в одном банке (не буду показывать пальцем) много лет пытались внедрить систему для онлайн-проведения платежей, чтобы когда пользователь кликнул «оплатить» в онлайн-банкинге или принес платежку операционисту платеж был сразу же проведен, а не ждал конца банковского дня, когда будет сведен баланс. За все время, что я имел счастье наблюдать за этой историей, так ничего и не было внедрено. Результат - банк терял свою долю рынка частников вместо того, чтобы ее приобретать. И еще раз замечу - эта история длилась несколько лет!
Другой пример из реальной жизни. Скажите за сколько времени Вы устанавливаете Linux на лэптоп? Сколько времени Вам надо, чтобы установить AIX на Power? Или Oracle на AIX, уж не знаю, в чем конкретно Вы специалист. Лично у меня установка AIX’а редко занимает больше получаса вместе со всей предварительной конфигурацией. Через полчаса - сервер готов к работе. А теперь заглянем в отдел ИТ большой корпорации. Сколько времени занимает установка AIX там? Правильный ответ - один месяц. Этот ответ повторяется от одной большой компании к другой. Если есть давление сверху, то AIX будет установлен за неделю. Если Вы думаете, что там работают плохие специалисты и вся проблема в этом, то Вы ошибаетесь. Даже самые лучшие специалисты начинают устанавливать AIX за один месяц.
Так почему же в столь любимом всеми директорами ИТ полностью ITIL’нутом ИТ-отделе не решаются проблемы? Почему внедрение новых технологий занимает так много времени? В чем заключается проблема и как ее решить?
С моей точки зрения проблемы ИТ-отделов начинаются как раз с попытки полностью соответствовать ITIL и внедрить у себя процессы. Когда мы говорим о бизнесе, мы должны понимать, что у каждого бизнеса есть вполне определенная цель - это заработать деньги. Именно на реализацию этой цели направлена вся деятельность предприятия. Когда мы говорим об ITIL, мы подменяем цель процессом. Мы больше не говорим о том, как мы можем помочь бизнесу, мы говорим о выполнении процессов. Именно ориентация на процессы и является ахилессовой пятой ITIL. Если вспомнить историю, то ITIL был написан государственным органом для себя. У государственных органов нет цели заработать деньги. У них по сути вообще нет целей - они просто работают. И им, вероятно, процессы подходят наиболее хорошо. В любой же коммерческой организации первым и самым важным является клиент, удовлетворение его потребностей. Клиенту все равно, насколько Вы ITIL-конформны. Клиенту нужен сервис. И если Ваша организация, вся из себя ITIL’нутая поставит ему готовый сервер за месяц, а другая поставит за 2 недели, то Вы проиграли. Конечно, ИТ-отделам хорошо - они не продают свои услуги в чистом виде, как внешние подрядчики. Но рано или поздно директору ИТ приходиться отвечать за срывы сроков проектов, превышение бюджета и прочие радости жизни.
Почему же все-таки ITIL не работает? Во-первых, он все-таки работает. Во-вторых, он работает плохо. И основная причина кроется в стандартной схеме организации работы ИТ-отделов. Большинство ИТ-отделов разделено на два больших подотдела, регулярно враждующих между собой - разработки и поддержки. В отделе поддержки проводится дальнейшая дифференциация между администраторами Linux, AIX, Oracle, DB2, Windows, Lotus, SAP, ... name it. Каждый новый продукт порождает новых администраторов и новую группу. Я сам был долгое время апологетом подобного подхода к организации ИТ и он казался мне оправданным. Я как администратор AIX не хочу заниматься Windows, да и что общего может быть у меня с ними? Практика показала, что очень многое.
Наиболее продвинутые ИТ-отделы, понимая, что эта схема почему-то не работает, пытаются реорганизоваться и еще более строго следовать ITIL-процессам. Для этого отделы создаются не в соответствии с компетенцией администраторов, как в предыдущей схеме, а в соответствии с процессами ITIL. Вот есть у нас процесс подготовки сервера перед выдачей его клиенту, а значит у нас будут администраторы, которые занимаются только подготовкой этих серверов. Есть процесс поддержки - значит будут и администраторы, которые занимаются только разгребанием тикетов. До сих пор я встречал подобную организацию только в двух компаниях, в одной из них этот процесс до сих пор идет, и надо ли говорить, что большинство сотрудников оценивают эту новую организацию очень скептически.
Если все плохо, то как надо сделать хорошо? Очень просто. Надо вспомнить, что современный ИТ-отдел фактически продает бизнесу свой сервис. Но сервис этот называется не установка AIX или настройка SAP. Сервис этот может называться, например, «поддержка основной банковской системы», или «поддержка системы кадрового учета» и т.п. Именно от этого и надо начинать плясать. Бизнесу не очень интересно, используется ли в инфраструктуре AIX или Windows. Бизнесу очень интересно, чтобы его система кадрового учета, которая может быть построена на базе SAP или Oracle, крутиться на сервере Power или Intel x86, под управлением Linux или Windows, но самое главное - чтобы она была доступна и работала! А когда бизнесу требуется новая фенечка, она должна быть имплементирована в кратчайшие сроки! Каким образом это может быть обеспечено? С моей точки зрения созданием горизонтальных команд. Я не открою Америку - это известно давно, что горизонтальные команды работают эффективнее вертикальных. И мое предложение не является чем-то новым в истории ИТ - о необходимости создания горизонтальных команд говорят давно. Но я впаду в крайность - необходимо не просто создавать горизонтальные команды, необходимо строить ИТ, исходя из горизонтальных команд. Не должно быть в современном ИТ отделов администраторов AIX или Linux или еще чего-то. В современном ИТ-отделе должен быть отдел поддержки кадровой системы, в который входят Product Manager (и он же по совместительству - начальник), администратор AIX, администратор Oracle, администратор SAP, разработчик под SAP HR на каком-нибудь ABAP, и т.д. - все люди, которые требуются для поддержки этой кадровой системы, включая в случае необходимости отдельный хелпдеск со своим колл-центром, мониторинг, сторедж, свои сервера. В крайнем случае (если, например, продукт критичен для бизнеса) - даже свой датацентр. Опять-таки из моей практики именно подобные группы, отвечающие исключительно за один продукт, функционировали наилучшим образом.
Создавая подобную структуру мы в состоянии решить сразу же несколько проблем ИТ-отделов. Во-первых, мы в состоянии улучшить качество работы ИТ и его восприятие со стороны бизнеса. Обычный процесс поддержки в большой компании начинается со звонка в хелпдеск, где как всегда все телефоны заняты, а операторов не хватает. Потом хелпдеск долго разбирается, к какому приложению относится эта проблема и пытается отвесить проблему на администраторов приложения. Затем администраторы приложения решают, что проблема, например, на стороне Oracle и перевешивают тикет на ораклистов, которые в свою очередь отсылают тикет на администраторов AIX, которые после проверки тикета решают, что проблема в системе хранения данных. Все это время проблема не решается, а перепинывается между группами. Время ожидания решения проблемы будет на 90% состоять из времени пока тикет просто висел, ожидая, что его кто-то посмотрит. В случае наличия продуктовых команд, тикет попадает сразу же в такую команду. В команде нет смысла долго перекладывать задачу с одного на другого - все работают вместе, общение и передача данных происходит быстрее. Следствие - быстрее решается проблема, а значит клиент (наш бизнес) становится довольным работой ИТ-отдела (или более довольным, чем был раньше).
Если нужно внедрить что-либо новое в продукт, то опять-таки продуктовая команда в состоянии это сделать быстрее, чем вертикальные команды, по той же причине - общение в команде происходит быстрее. Как часто общаются администратор AIX и администратор Oracle между собой в большой компании? У каждого из них свои проблемы и когда нужно что-то новое установить, бедному проектному менеджеру приходится бегать между ними двумя, согласовывая время, а также желательно собрать двоих на митинг, чтобы каждый мог высказать другому в лицо, что о нем думает. В продуктовой команде отпадает необходимость в беготне проектного менеджера, т.к. есть product manager, отвечающий за продукт, а по совместительству и начальник обоих администраторов, который может приоритезировать им работу. Соответственно, тикет на установку не будет висеть годами, ожидая своего времени и свободных ресурсов.
Если же нужно внедрить совершенно новый продукт, которого еще не существовало, то необходимо создать команду с нуля, пополнив ее сразу же product manager’ом и архитектором.
Во-вторых, поговорим об оценке труда специалистов. Нет, не о денежной. Зарплатой все всегда недовольны. Поговорим об оценке труда специалиста его начальством. Начальство всегда хочет иметь измеряемый инструмент оценки своего подчиненного. С внедрением ITIL и всевозможных тикет-систем оно такой инструмент получает. Зачастую после этого работа специалиста оценивается очень просто - сколько тикетов он за месяц закрыл (принял участие в решении) и как долго эти тикеты на нем висели. Соответственно, чем больше первый показатель и чем меньше второй показатель, тем лучше. Во что выливается подобный подход? Очень просто - мне как специалисту легче всего на свете решать большое количество легких однотипных тикетов. У меня на NIM-сервере сегодня ночью бэкапы не прошли - было открыто 20 тикетов. И вот целый день я закрываю эти 20 тикетов. По всем показателям - полностью загружен работой. То, что в этот момент может висеть тикет на установку новой системы меня не очень волнует - установка дело долгое и хлопотное, я за день 20 систем не установлю. И даже если установлю - это будет больше работы, чем закрыть 20 тикетов с проблемой бэкапа. На следующий день я снова получу 20 тикетов от NIM-сервера. По одной простой причине - я вчера сделал бэкапы, но я не искал, почему они ночью не прошли. Зачем мне искать? Если я не ищу корень проблемы, то я каждый день получаю 20 тикетов, которые я знаю, как решать и могу всегда легко решить. Если же я начну искать, то во-первых, я потрачу больше времени на решение проблем, во-вторых, у меня не будет больше новых тикетов. И то, и другое с точки зрения начальства - плохо. Я ведь должен закрывать много тикетов за короткое время, демонстрируя свои потрясающие навыки в администрировании AIX!
Подобный подход, внедренный по-моему во всех компаниях, где я работал, является абсолютно неверным. Единственным мерилом труда любого специалиста является то, насколько доволен его клиент. При создании продуктовых команд это становится мерилом труда всей команды. Клиента (бизнес) можно и нужно опрашивать, насколько он доволен работой ИТ-отдела. Но в вертикально-организованном ИТ-отделе такие опросы практически ни к чему - разве что галочка для директора ИТ. А вот в горизонтально-организованном ИТ-отделе от такого опроса зависит дальнейшая работа команды, т.к. здесь заранее известно, что отдел кадров, например, пользуется системой кадрового учета, которая поддерживается вот этой командой во главе с этим Product Manager’ом. И ему уже будет очень невыгодно, чтобы я закрывал 20 тикетов сорвавшегося бэкапа каждый день ради рисования красивых картинок с красивыми KPI.
Единственный вопрос, который у меня возникает при подобной схеме - не является ли это возвратом в «дикое» прошлое, когда у каждого отдела был свой любимый сервер и свой любимый администратор, а ИТ-отделов фактически не существовало? Не принесет ли дублирование функций дополнительного возрастания расходов? С моей точки зрения - нет. Во-первых, современная ИТ-инфраструктура предприятия, хоть и состоит из большого количества приложений, но тем не менее все приложения связаны между собой. Таким образом полностью разделить приложения и разнести их по разным отделам, как это было лет 20 назад, практически невозможно - всегда будут сохраняться некоторые общие части, например, сетевая инфраструктура в датацентре. Также общей должна оставаться архитектура ИТ предприятия. Т.е. при этом совершенно спокойно в продуктовой команде могут быть и свои архитекторы, и свои сетевики, обслуживающий свой участок работы. Но общая концепция, capacity planning, или разделяемые ресурсы, такие как каналы между датацентрами, должны продолжать обслуживаться «общим» ИТ. Во-вторых, использование горизонтальных решений в современном ИТ может оказаться финансово выгоднее, чем использование вертикальных. Как это связано с организацией ИТ-отдела? Да очень просто. Когда мы консолидируем, например, AIX-сервера, то обычно выходит, что для них нужно либо несколько 770х, либо несколько 795х серверов. Когда же мы говорим об отдельном приложении, то для него может хватить и одного 740го сервера. Разница в цене - грубо 50k$ и 2M$. Конечно, надо считать не только TCA, а TCO полностью (где-то в этом журнале я когда-то писал про это статью). Но опять-таки пока мы ставим локальные цели (уровень приложения), мы тратим меньше денег. Как только ставится глобальная цель - взять да все консолидировать! - расходы имеют тенденцию расти.
В общем, подводя итог пяти страницам в Word’е, я считаю, что подобная организация ИТ имеет право на жизнь и является моделью ИТ-отдела ближайшего будущего, в первую очередь для тех организаций, которые стремятся вперед. Кстати, примажусь-ка я к модному нынче движению DevOps - ведь фактически та же идея, объединение разработчиков и operations в одну команду, чтобы кругом один profit был.
ИТ-отделы во многих компаниях начинались (да зачастую и начинаются) с одиночек-кустарей, которые все умеют. Затем ИТ-отделы разрастаются, вместе с ростом бизнеса и его технологической составляющей нанимаются на работу все больше и больше специалистов, а потом в один прекрасный момент случается коллапс, когда управлять этим скопищем людей больше невозможно, проблемы пользователей не решаются, и как всегда - мечта любого администратора - это выкатывание нового релиза программистами в пятницу вечером без тестов и без участия администратора, что обычно приводит к остановке работы на все выходные.
В этот момент большое руководство компании обычно в первый раз обращает внимание на ИТ-отдел и начинает судорожно выбирать себе директора ИТ. Обычно выбор останавливается на каком-нибудь ITIL-пересертифицированном специалисте и начинается на предприятии процесс внедрения ITIL. Процесс этот, как показывает моя практика, никогда не заканчивается. Сменяются ITIL-специалисты, открываются и закрываются отделы, создаются и снова исчезают рабочие группы, проводятся многочасовые митинги и километры лесов исчезают в многостраничных документах, но все время находятся новые неурегулированные процессы, которые надо описать, формализировать, назначить роли всем исполнителям, попробовать автоматизировать и т.д. При этом несмотря на видимый эффект от использования ITIL, по мере разрастания ИТ-отдела (а он разрастается - всегда) качество работы ИТ опять ухудшается. И даже ITIL уже не в состоянии помочь - большое начальство все больше говорит о технологических проблемах.
В последней IBM CEO Study впервые за 8 лет ее проведения руководители бизнесов обозначили именно технологические факторы, как наиболее влияющие на бизнес предприятия. В 2004 г. те же самые технологические факторы были на 6м месте, а на 1м месте все эти годы был маркетинг. Сейчас именно технологии дают компании (даже не ИТ-компании, а обычной компании из обычного «реального» мира) конкурентные преимущества. А соответственно технологические проблемы создают вполне конкретные проблемы для бизнеса. Как пример - в одном банке (не буду показывать пальцем) много лет пытались внедрить систему для онлайн-проведения платежей, чтобы когда пользователь кликнул «оплатить» в онлайн-банкинге или принес платежку операционисту платеж был сразу же проведен, а не ждал конца банковского дня, когда будет сведен баланс. За все время, что я имел счастье наблюдать за этой историей, так ничего и не было внедрено. Результат - банк терял свою долю рынка частников вместо того, чтобы ее приобретать. И еще раз замечу - эта история длилась несколько лет!
Другой пример из реальной жизни. Скажите за сколько времени Вы устанавливаете Linux на лэптоп? Сколько времени Вам надо, чтобы установить AIX на Power? Или Oracle на AIX, уж не знаю, в чем конкретно Вы специалист. Лично у меня установка AIX’а редко занимает больше получаса вместе со всей предварительной конфигурацией. Через полчаса - сервер готов к работе. А теперь заглянем в отдел ИТ большой корпорации. Сколько времени занимает установка AIX там? Правильный ответ - один месяц. Этот ответ повторяется от одной большой компании к другой. Если есть давление сверху, то AIX будет установлен за неделю. Если Вы думаете, что там работают плохие специалисты и вся проблема в этом, то Вы ошибаетесь. Даже самые лучшие специалисты начинают устанавливать AIX за один месяц.
Так почему же в столь любимом всеми директорами ИТ полностью ITIL’нутом ИТ-отделе не решаются проблемы? Почему внедрение новых технологий занимает так много времени? В чем заключается проблема и как ее решить?
С моей точки зрения проблемы ИТ-отделов начинаются как раз с попытки полностью соответствовать ITIL и внедрить у себя процессы. Когда мы говорим о бизнесе, мы должны понимать, что у каждого бизнеса есть вполне определенная цель - это заработать деньги. Именно на реализацию этой цели направлена вся деятельность предприятия. Когда мы говорим об ITIL, мы подменяем цель процессом. Мы больше не говорим о том, как мы можем помочь бизнесу, мы говорим о выполнении процессов. Именно ориентация на процессы и является ахилессовой пятой ITIL. Если вспомнить историю, то ITIL был написан государственным органом для себя. У государственных органов нет цели заработать деньги. У них по сути вообще нет целей - они просто работают. И им, вероятно, процессы подходят наиболее хорошо. В любой же коммерческой организации первым и самым важным является клиент, удовлетворение его потребностей. Клиенту все равно, насколько Вы ITIL-конформны. Клиенту нужен сервис. И если Ваша организация, вся из себя ITIL’нутая поставит ему готовый сервер за месяц, а другая поставит за 2 недели, то Вы проиграли. Конечно, ИТ-отделам хорошо - они не продают свои услуги в чистом виде, как внешние подрядчики. Но рано или поздно директору ИТ приходиться отвечать за срывы сроков проектов, превышение бюджета и прочие радости жизни.
Почему же все-таки ITIL не работает? Во-первых, он все-таки работает. Во-вторых, он работает плохо. И основная причина кроется в стандартной схеме организации работы ИТ-отделов. Большинство ИТ-отделов разделено на два больших подотдела, регулярно враждующих между собой - разработки и поддержки. В отделе поддержки проводится дальнейшая дифференциация между администраторами Linux, AIX, Oracle, DB2, Windows, Lotus, SAP, ... name it. Каждый новый продукт порождает новых администраторов и новую группу. Я сам был долгое время апологетом подобного подхода к организации ИТ и он казался мне оправданным. Я как администратор AIX не хочу заниматься Windows, да и что общего может быть у меня с ними? Практика показала, что очень многое.
Наиболее продвинутые ИТ-отделы, понимая, что эта схема почему-то не работает, пытаются реорганизоваться и еще более строго следовать ITIL-процессам. Для этого отделы создаются не в соответствии с компетенцией администраторов, как в предыдущей схеме, а в соответствии с процессами ITIL. Вот есть у нас процесс подготовки сервера перед выдачей его клиенту, а значит у нас будут администраторы, которые занимаются только подготовкой этих серверов. Есть процесс поддержки - значит будут и администраторы, которые занимаются только разгребанием тикетов. До сих пор я встречал подобную организацию только в двух компаниях, в одной из них этот процесс до сих пор идет, и надо ли говорить, что большинство сотрудников оценивают эту новую организацию очень скептически.
Если все плохо, то как надо сделать хорошо? Очень просто. Надо вспомнить, что современный ИТ-отдел фактически продает бизнесу свой сервис. Но сервис этот называется не установка AIX или настройка SAP. Сервис этот может называться, например, «поддержка основной банковской системы», или «поддержка системы кадрового учета» и т.п. Именно от этого и надо начинать плясать. Бизнесу не очень интересно, используется ли в инфраструктуре AIX или Windows. Бизнесу очень интересно, чтобы его система кадрового учета, которая может быть построена на базе SAP или Oracle, крутиться на сервере Power или Intel x86, под управлением Linux или Windows, но самое главное - чтобы она была доступна и работала! А когда бизнесу требуется новая фенечка, она должна быть имплементирована в кратчайшие сроки! Каким образом это может быть обеспечено? С моей точки зрения созданием горизонтальных команд. Я не открою Америку - это известно давно, что горизонтальные команды работают эффективнее вертикальных. И мое предложение не является чем-то новым в истории ИТ - о необходимости создания горизонтальных команд говорят давно. Но я впаду в крайность - необходимо не просто создавать горизонтальные команды, необходимо строить ИТ, исходя из горизонтальных команд. Не должно быть в современном ИТ отделов администраторов AIX или Linux или еще чего-то. В современном ИТ-отделе должен быть отдел поддержки кадровой системы, в который входят Product Manager (и он же по совместительству - начальник), администратор AIX, администратор Oracle, администратор SAP, разработчик под SAP HR на каком-нибудь ABAP, и т.д. - все люди, которые требуются для поддержки этой кадровой системы, включая в случае необходимости отдельный хелпдеск со своим колл-центром, мониторинг, сторедж, свои сервера. В крайнем случае (если, например, продукт критичен для бизнеса) - даже свой датацентр. Опять-таки из моей практики именно подобные группы, отвечающие исключительно за один продукт, функционировали наилучшим образом.
Создавая подобную структуру мы в состоянии решить сразу же несколько проблем ИТ-отделов. Во-первых, мы в состоянии улучшить качество работы ИТ и его восприятие со стороны бизнеса. Обычный процесс поддержки в большой компании начинается со звонка в хелпдеск, где как всегда все телефоны заняты, а операторов не хватает. Потом хелпдеск долго разбирается, к какому приложению относится эта проблема и пытается отвесить проблему на администраторов приложения. Затем администраторы приложения решают, что проблема, например, на стороне Oracle и перевешивают тикет на ораклистов, которые в свою очередь отсылают тикет на администраторов AIX, которые после проверки тикета решают, что проблема в системе хранения данных. Все это время проблема не решается, а перепинывается между группами. Время ожидания решения проблемы будет на 90% состоять из времени пока тикет просто висел, ожидая, что его кто-то посмотрит. В случае наличия продуктовых команд, тикет попадает сразу же в такую команду. В команде нет смысла долго перекладывать задачу с одного на другого - все работают вместе, общение и передача данных происходит быстрее. Следствие - быстрее решается проблема, а значит клиент (наш бизнес) становится довольным работой ИТ-отдела (или более довольным, чем был раньше).
Если нужно внедрить что-либо новое в продукт, то опять-таки продуктовая команда в состоянии это сделать быстрее, чем вертикальные команды, по той же причине - общение в команде происходит быстрее. Как часто общаются администратор AIX и администратор Oracle между собой в большой компании? У каждого из них свои проблемы и когда нужно что-то новое установить, бедному проектному менеджеру приходится бегать между ними двумя, согласовывая время, а также желательно собрать двоих на митинг, чтобы каждый мог высказать другому в лицо, что о нем думает. В продуктовой команде отпадает необходимость в беготне проектного менеджера, т.к. есть product manager, отвечающий за продукт, а по совместительству и начальник обоих администраторов, который может приоритезировать им работу. Соответственно, тикет на установку не будет висеть годами, ожидая своего времени и свободных ресурсов.
Если же нужно внедрить совершенно новый продукт, которого еще не существовало, то необходимо создать команду с нуля, пополнив ее сразу же product manager’ом и архитектором.
Во-вторых, поговорим об оценке труда специалистов. Нет, не о денежной. Зарплатой все всегда недовольны. Поговорим об оценке труда специалиста его начальством. Начальство всегда хочет иметь измеряемый инструмент оценки своего подчиненного. С внедрением ITIL и всевозможных тикет-систем оно такой инструмент получает. Зачастую после этого работа специалиста оценивается очень просто - сколько тикетов он за месяц закрыл (принял участие в решении) и как долго эти тикеты на нем висели. Соответственно, чем больше первый показатель и чем меньше второй показатель, тем лучше. Во что выливается подобный подход? Очень просто - мне как специалисту легче всего на свете решать большое количество легких однотипных тикетов. У меня на NIM-сервере сегодня ночью бэкапы не прошли - было открыто 20 тикетов. И вот целый день я закрываю эти 20 тикетов. По всем показателям - полностью загружен работой. То, что в этот момент может висеть тикет на установку новой системы меня не очень волнует - установка дело долгое и хлопотное, я за день 20 систем не установлю. И даже если установлю - это будет больше работы, чем закрыть 20 тикетов с проблемой бэкапа. На следующий день я снова получу 20 тикетов от NIM-сервера. По одной простой причине - я вчера сделал бэкапы, но я не искал, почему они ночью не прошли. Зачем мне искать? Если я не ищу корень проблемы, то я каждый день получаю 20 тикетов, которые я знаю, как решать и могу всегда легко решить. Если же я начну искать, то во-первых, я потрачу больше времени на решение проблем, во-вторых, у меня не будет больше новых тикетов. И то, и другое с точки зрения начальства - плохо. Я ведь должен закрывать много тикетов за короткое время, демонстрируя свои потрясающие навыки в администрировании AIX!
Подобный подход, внедренный по-моему во всех компаниях, где я работал, является абсолютно неверным. Единственным мерилом труда любого специалиста является то, насколько доволен его клиент. При создании продуктовых команд это становится мерилом труда всей команды. Клиента (бизнес) можно и нужно опрашивать, насколько он доволен работой ИТ-отдела. Но в вертикально-организованном ИТ-отделе такие опросы практически ни к чему - разве что галочка для директора ИТ. А вот в горизонтально-организованном ИТ-отделе от такого опроса зависит дальнейшая работа команды, т.к. здесь заранее известно, что отдел кадров, например, пользуется системой кадрового учета, которая поддерживается вот этой командой во главе с этим Product Manager’ом. И ему уже будет очень невыгодно, чтобы я закрывал 20 тикетов сорвавшегося бэкапа каждый день ради рисования красивых картинок с красивыми KPI.
Единственный вопрос, который у меня возникает при подобной схеме - не является ли это возвратом в «дикое» прошлое, когда у каждого отдела был свой любимый сервер и свой любимый администратор, а ИТ-отделов фактически не существовало? Не принесет ли дублирование функций дополнительного возрастания расходов? С моей точки зрения - нет. Во-первых, современная ИТ-инфраструктура предприятия, хоть и состоит из большого количества приложений, но тем не менее все приложения связаны между собой. Таким образом полностью разделить приложения и разнести их по разным отделам, как это было лет 20 назад, практически невозможно - всегда будут сохраняться некоторые общие части, например, сетевая инфраструктура в датацентре. Также общей должна оставаться архитектура ИТ предприятия. Т.е. при этом совершенно спокойно в продуктовой команде могут быть и свои архитекторы, и свои сетевики, обслуживающий свой участок работы. Но общая концепция, capacity planning, или разделяемые ресурсы, такие как каналы между датацентрами, должны продолжать обслуживаться «общим» ИТ. Во-вторых, использование горизонтальных решений в современном ИТ может оказаться финансово выгоднее, чем использование вертикальных. Как это связано с организацией ИТ-отдела? Да очень просто. Когда мы консолидируем, например, AIX-сервера, то обычно выходит, что для них нужно либо несколько 770х, либо несколько 795х серверов. Когда же мы говорим об отдельном приложении, то для него может хватить и одного 740го сервера. Разница в цене - грубо 50k$ и 2M$. Конечно, надо считать не только TCA, а TCO полностью (где-то в этом журнале я когда-то писал про это статью). Но опять-таки пока мы ставим локальные цели (уровень приложения), мы тратим меньше денег. Как только ставится глобальная цель - взять да все консолидировать! - расходы имеют тенденцию расти.
В общем, подводя итог пяти страницам в Word’е, я считаю, что подобная организация ИТ имеет право на жизнь и является моделью ИТ-отдела ближайшего будущего, в первую очередь для тех организаций, которые стремятся вперед. Кстати, примажусь-ка я к модному нынче движению DevOps - ведь фактически та же идея, объединение разработчиков и operations в одну команду, чтобы кругом один profit был.