IT ManagerИТ в бизнесеУправление

Маленькое искусство

Александр Башкиров | 13.05.2014

Маленькое искусство

Можно много говорить про управление проектами — сейчас это своеобразный тренд. Вполне обоснованный, надо признать: на фоне кризиса проектные методологии могут серьезно помочь любой компании, а уж паче чаяния — ИТ-компании... Но хочется сделать шаг в сторону  и поговорить про управление в ИТ в целом. Почему? Да потому, что управление в ИТ, с одной стороны, тесно связно с управлением проектами: по сути своей деятельность ИТ минимум на 50% проектная. А с другой — грамотно поставленное управление ИТ может оказать реальную помощь. Да, опять речь пойдет о сокращении издержек, увеличении эффективности и регулярном менеджменте. Ну а что вы хотели? Кризис — он совсем не сказка.

Священная корова ITIL и ITSM

Говоря об управлении ИТ, первое, что приходит на ум, — ITIL и ITSM. Большая священная корова, вокруг которой, с моей точки зрения, наблюдается нездоровый ажиотаж. Да, с одной стороны, ITIL хорош. Он хорош тем, что позволяет выстроить и структурировать работу ИТ с пользователем. «От каждого по возможностям, каждому по потребностям» — старый лозунг, который зачастую поднимается ИТ при внедрении ITIL. И как следствие, ИТ попадает в ситуацию «снизу», то есть безынициативного, полностью зависимого подразделения. Но ITIL внедрен, и есть формальное основание требовать соблюдения взятых на себя SLA. Типичная ошибка при внедрении ITIL состоит в том, что хочется быть чуть лучше, чем можно, и, соответственно, обязательства ИТ перед пользователями, взятые в процессе производства проекта, растут, а средств обеспечения этих обязательств просто нет: жизнь не сказка (чтобы ни говорили консультанты), она гораздо богаче разными зигзагами; бизнес же обычно трепетно относится к исполнению данных ему обещаний, хотя бы и собственными подразделениями. Точнее, в первую очередь к исполнению обязательств собственными подразделениями. Что, вообще говоря, очень логично: если сами с собой не договоримся и сами не станем соблюдать взятые на себя обязательства, то как договориться с заказчиками?

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

Вторая сторона отношений ИТ и бизнеса обычно прячется за гордой аббревиатурой ITSM — Information Technology Service Management, что, по сути, является частью более общей концепции BSM (Buisness Service Management), или управления подразделением как сервисом. Другими словами, есть управление по принципу «черного куба»: есть «вход», «выход» (приемлемый результат) и по большому счету неважно, как и за счет чего он достигается. При работе в такой концепции становится не очень важно, с кем именно сотрудничать — с внешним подрядчиком или с внутренним подразделением. По опыту могу сказать, что да, такое возможно. Но для реализации подобного рода концепции и компания, и ИТ-подразделение должны иметь достаточно высокую степень зрелости. Что встречается, конечно, но очень нечасто. Возникает логичный вопрос: а как же живут и работают все остальные? 

С небес на землю

А все остальные — как могут. То есть стремятся к идеалу, внедряя понемногу то, что можется. Например, процесс управления инцидентами. Выстраивая отношения с бизнесом так, как получается. Вообще, ни для кого не секрет, что у нас есть такая милая особенность национального бизнеса — и она состоит в том, чтобы «сработаться». Поэтому, если ИТ сработалось с бизнесом — уже хорошо. Сформировали общие правила — замечательно. А если еще этим правилам и следуют все участники — вообще великолепно! (Вопрос о том, насколько часто встречается подобная ситуация, оставим за рамками статьи).

Могу с полной уверенностью сказать, что самое неприятное — это когда правила меняются по ходу игры. И к сожалению, такие ситуации встречаются. Не «сплошь и рядом», но и не «исчезающе мало»; так, чтобы рассматривать их только в теории, из разряда «так делать не надо». Просто потому, что или бизнес не понимает, чего ждать от ИТ, или у ИТ не получается внятно объснить, чем оно может быть полезно бизнесу.

К чему все это? Да к тому, что управление ИТ на самом деле имеет два очень четких вектора. Первый — отношения с бизнесом. Второй — управление собственными ресурсами. Первый вектор состоит из двух основных линий — управление отношениями с пользователями и управлением отношениями на уровне менеджмента. И тут, наверное, надо вздохнуть и вспомнить про столь нелюбимую айтишниками функцию, как регулярный менеджмент. Что это такое? Если очень коротко, это регулярный план-факт анализ, выполняемый ИТ совместно с основным бизнесом. Разумеется, в каждом конкретном случае объекты анализа будут своими, как и частота представления аналитики. Но общие принципы неизменны. Следует отметить, что сам по себе план-факт анализ не несет особого смысла: когда процессы в какой-то степени выстроены, больших сюрпризов в общем не предвидится. А вот анализ в разрезе перспективы и предвосхищения уже становится интересным. Потому что кроме констатации фактов по текущей ситуации возникают новые горизонты, достижение которых обеспечит бизнесу те или иные преимущества. 

«Все это здорово, окей! — скажет искушенный читатель. — Но как быть, когда нет ничего, а требуют очень и очень многое?» Ситуация, кстати, классическая. Ну или почти классическая. В смысле, что зачастую бизнес имеет такой грешок — завышенные ожидания. И чтобы не говорили — переубедить его бывает довольно сложно. Но реально. Нужно лишь найти правильные аргументы для каждой правильной ситуации. И возможно, это придется проделывать неоднократно, до тех пор пока не будут выстроены отношения, при которых бизнес требует от ИТ чуть больше возможного, а ИТ это выполняет. Согласитесь, вызов должен присутствовать, иначе будет совсем неинтересно.

Если же совсем в общем виде, то когда нет ничего — надо составить четкий план: что, когда и как должно быть реализовано. Что это даст. К чему приведет. Какие несет риски. Как им противостоять (и стоит ли противостоять, может, имеет смысл просто принять риск и все?). И работать с конкретными менеджерами от бизнеса, показывая, доказывая, рассказывая... и одновременно приводя ИТ хотя бы к состоянию «удовлетворительно». Это, кстати, зачастую бывает непросто сделать — и без технических решений, и без кадровых преобразований... Вообще, преобразования в ИТ — вещь, которая делается труднее, чем в других подразделениях. Почему? Да потому, что айтишник изначально имеет большую, по отношению к простым пользователям, степень свободы, и больше возможностей для разного рода манипуляций (откровенно говоря, и шантажа тоже). Поэтому, наверное, пресловутый «кадровый вопрос» с айтишниками решается либо предельно корректно, либо не решается вообще. Чего греха таить: с точки зрения бизнеса порой проще держать человека, чем остановить основную деятельность. (Вспомним про еще одну «священную корову»: бизнес зависим от ИТ. И более того, бизнес зависим от конкретных людей в ИТ. Те же доступы «ко всему» есть далеко не у всех, так же как и доступы к критически важным сервисам.)

Про проекты

Теперь немного коснемся темы проектов в ИТ. Как уже говорилось, примерно 50% времени среднестатистического айтишника уходит на то, чтобы работать с проектами. А если совсем точно — реализовывать конкретные проекты. По крайней мере к этому надо стремиться: залог живучести ИТ — непрерывные улучшения. И порой они же — залог получения конкурентных преимуществ всей компании, так что в этом смысле интересы бизнеса и ИТ совпадают, здесь они на одной волне. (И с точки зрения «заработать на зарплату», и с точки зрения сугубо профессиональных интересов: для айтишника нет лучшего стимула, чем интересная задача, которой и являются требования бизнеса.)

Собственно, эти улучшения и «спускаются» в ИТ в виде требований на проекты. Причем обычно любой старт такого рода улучшения — прямое следствие работы регулярного менеджмента: по итогам рассмотрения ситуации и возможностей принимается решение, которое реализуется силами ИТ или привлеченных подрядчиков, с обязательным участием бизнеса. Да, бизнес может и должен принимать самое непосредственное участие в ИТ-проектах: иначе никто не будет гарантировать, что получившееся на выходе в полной мере соответствует ожиданиям и требованиям бизнеса. Ну а форма участия — самая разная, от сотрудничества при создании ТЗ до формирования и работы в совместной проектной команде (лучший вариант, кстати). К сожалению, это могут себе позволить далеко не все компании — обычно от бизнеса выделяется куратор проекта, который так или иначе влияет на его ход и результат. И является независимым наблюдателем и внутренним аудитором. Такая конфигурация работы над проектом, вместе с регулярным менеджментом, применительно к проектной деятельности может дать достаточно хороший эффект и в части результата, и в части удовлетворенности конечных потребителей. Ведь при наличии соответствующих полномочий аудитор вполне способен дать то, чего обычно не хватает ИТ, — видение со стороны бизнеса. А потому не лишне еще раз напомнить, что залог эффективной работы ИТ — тесное сотрудничество с бизнесом и работа во имя и во благо конченого бизнес-пользователя.

Кстати, если такое сотрудничество построено — у бизнеса, как правило, не возникает вопросов, почему сдвинулись сроки реализации или с чем связана корректировка бюджета при «небольших» изменениях в окружении или требованиях к результату проекта. Ведь все коррективы будут проходить не только через формальное сито «есть/нет в ТЗ», но и через оценку эксперта, который может либо аргументированно отказать, либо обосновать необходимость того или иного изменения. И подобный эксперт в силах решить множество «пограничных» вопросов, понимая проблемы и бизнеса, и ИТ. Это в лучшем случае. В худшем — будет жесткое лоббирование бизнес-требований. При кажущемся негативе такой роли — расклад не самый худший для конечного результата: бизнес получит то решение, которое так или иначе его устроит. Но при этом ИТ, а особенно проектная команда, будет вынуждено жить в достаточно некомфортных условиях. Стоит ли того конечный результат — вопрос к каждому конкретному участнику. Но, повторюсь, конфигурация не самая плохая.

А самой плохой для ИТ-проектов является ситуация, при которой каждый из участников предоставлен сам себе. Например, в ИТ передано невнятное описание конечного результата, выделен бюджет и дан карт-бланш. Как вы думаете, что получится в итоге? Нет, если ИТ-директор вовлечен в процессы работы и хорошо понимает потребности бизнеса, проблемы вряд ли возникнут (повторится ситуация с аудитором от бизнеса). А если нет, можно с уверенностью сказать, что проект будет или закрыт, или обретет вторую инкарнацию — в виде доделок, переделок и доводок. И, поверьте, никому от этого не станет хорошо — скорее наоборот.

И напоследок еще раз про дуализм

Повторю одну важную мысль. ИТ по своей сути дуалистично — в той или иной мере оно работает как в оперативном режиме, так и в режиме проектном. И управление ИТ должно строиться исходя из того, что обе макрофункции будут присутствовать априори. Всегда, в каждом конкретном случае с перекосом в ту или иную сторону, но дуализм будет. И к этому нужно быть готовы всем, от ИТ-директора до рядового сотрудника ИТ (ну разве что роме «совсем рядового сотрудника», например оператора службы helpdesk, когда сотрудник работает исключительно в одном из направлений). Исходя из этого, нужно строить работу, формировать отношения, разворачивать систему менеджмента. Вроде бы и нетрудно, но каждый раз получается свое маленькое искусство — со своими сложностями и своим исходом.

управление проектами

Журнал: Журнал IT-Manager [№ 04/2014], Подписка на журналы


Поделиться:

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Также по теме

Другие материалы рубрики

Мысли вслух

Не имея возможности составить из разрозненных пазлов целостную картину надвигающегося на нас постковидного мира, нам приходится довольствоваться соединением отдельных ее фрагментов, которые, за несколько месяцев тотального локдауна, уже обрели достаточно ясные очертания.
Понимали ли теоретики и осторожные практики дистанционного образования, что пока они более или менее безрезультатно тратят время на корпоративном рынке, на идеях капитализируются и стремительно дискредитируют их преимущественно разнообразные «инфоцыгане»?

Поскольку люди не роботы и каждый живой участник процесса выполняет даже одну и ту же функцию немного по-разному, наш цифровой двойник будет выглядеть как некое «облако событий» вокруг «идеального процесса».

Компании сообщают

Мероприятия

15.06.2020 — 18.06.2020
Онлайн-конференция по .NET-разработке DotNext 2020 Piter

Санкт-Петербург, Online

15.06.2020 — 18.06.2020
Конференция по тестированию Heisenbug 2020 Piter

Санкт-Петербург, Online

22.06.2020 — 25.06.2020
Конференция для JavaScript-разработчиков HolyJS 2020 Piter

Санкт-Петербург, Online

22.06.2020 — 25.06.2020
Конференция по мобильной разработке Mobius 2020 Piter

Санкт-Петербург, Online