Kitobni o'qish: «Заметки цифрового Дон Кихота или как ИТ-Лидеру победить череду цифровых мельниц»

Заметки цифрового Дон Кихота

или как ИТ-Лидеру победить череду цифровых мельниц

Предисловие

Глава 1. ИТ лидер. Между железом сроков и хрусталем душ

Who is IT Leader?

За что отвечает

За что не отвечает

Цель

Качества ИТ лидера

Дипломатия

Глава 2. Оруженосцы: Кольчуга доверия, что куется в пути

Знакомство

Встречи One to one

Собеседование

Ритуалы в рамках Agile

Запланированные встречи внутри команды

Внезапные встречи

Запланированные встречи с «чужими»

Уступки

Взаимоотношения

Глава 3. Лики власти ИТ руководства. Сеньоры в бумажных доспехах.

Лики

Карьерист

Премилый угодник

Садовая улитка

Истеричка

Свет разума

Как поладить?

Смена руководства

Глава 4 Бизнес Руководство. Королевский двор

Милорды двора

Те же

Тень отца Гамлета

Лорд Бульдозер

Лорд Здравосмысл

Точки касания

Смена руководства

Глава 5. Границы интересов. Рукопожатие с шипами

Сотрудники других команд

ИТ лидеры других команд

Руководители других направлений

Лорды Стратегий

Перечень вопросов ко встречам

Глава 6. Бюрократия. И снова мельницы

Мельница регламентов

Мельница артефактов

Мельница писем

Мельница протоколов

Заключение

Алхимическая лаборатория (Словарь терминов)

Спускаясь в жерло мельниц ветряных,

готов будь обратиться в пыль…

Неизвестный бард XV века

Предисловие

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

Не претендуя на полноту и исчерпанность суждений, постараюсь в нескольких главах коротко и на примерах последовательно изложить кто такой ИТ лидер, особенности его работы, с чем он может сталкиваться и как может реагировать, обходить, уклоняться, организовывать, переживать, думать, злиться, выгорать, ломаться и снова воскресать. Я попытаюсь представить особенности окружения ИТ лидера – руководство, смежные команды и их взаимоотношения через призму особенностей процессов и регламентов больших проектов внутри банков.

Здесь вы не встретите сухой педантичной теории. Все истории, ситуации, проблемы и их решения взяты из реальной жизни, из практического опыта, где каждая история и каждая глава оплачены опытом и потом, бессонными ночами в размышлениях и звоном натянутых нервов, горечью поражений и радостью успехов команды.

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

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

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

Глава 1. ИТ лидер. Между железом сроков и хрусталем душ

У самурая нет цели, есть только путь.

У ИТ лидера нет пути, есть только цель.

Выжить...

Директор департамента R&D концерна «Мацушито» Одзи Мирукава

Давайте же попробуем разобраться, кто же он - ИТ лидер, безвестный герой информационных технологий, облаченный в сияющие доспехи из фреймворков и вооруженный софт- и хард-скиллами, сражающийся аки лев с адскими виртуальными мельницами задач, сроков и дашбордов; или жертва обстоятельств, пытающаяся выжить в нелегких условиях дедлайнов и пресса бюрократии, использующая все средства для достижения цели, чтобы успеть, дотянуть, проскочить, уложиться в срок и не выгореть, не впасть в депрессию, не свалиться с высокой температурой или инсультом\инфарктом (были и такие случаи) и не пристраститься к антидепрессантам и алкоголю?

Как вы понимаете, ни то, ни другое.

.1.

Who

is

IT

Leader

?

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

Но мы отвлеклись от нашего заголовка. Так кто же он, этот ИТ лидер? Безусловно, не составит труда найти в новомодных учебниках по Эджайл (Agile) и тому подобном определение данной роли. И, как ни странно, короткого определения нет. Скорее всего, вы найдете список того, что должен делать ИТ лидер, перечень того, какие к нему относятся функции, какими скиллами обладает и прочее. И этот список будет отличаться от статьи к статье, от автора к автору. Вот самые короткие варианты, которые мне удалось найти:

«ИТ лидер – это мост между бизнесом и разработкой»;

«ИТ лидер – это специалист, который сочетает в себе отличное видение продукта и лидерские качества»;

«Чем же реально занимается ИТ-лидер? Терпеть не могу эту фразу, но… это зависит!»

Нисколько не претендуя на истину в последней инстанции, я бы предложил такой вариант:

ИТ Лидер - это тот, кто в ответе за все.

Кто-то ушел в отпуск\заболел и у команды просела производительность – ИТ лидер оказался недостаточно «зрелым», чтобы заранее сообщить руководству, что временно потребуется дополнительный ресурс; клиент жалуется на функционал\в промышленной среде какие-то ошибки – ИТ лидер должен немедленно разобраться и устранить их, чтобы на лице клиента засияла улыбка удовлетворения и бесконечного счастья, как будто он достиг сатори и самбодхи одновременно; необходимо найти контакт\документацию соседней команды – ИТ лидер тут как тут, роется в контактах\своих записях или спрашивает у коллег, таких же ИТ лидеров, и приходит с желанным контактом\ссылкой на документацию; требуется заполнить +100500 заявок на доступы\разрешения\разблокировки и прочее – ИТ лидер спешит на помощь; у руководства появилась гениальная идея заполнения новой таблицы\подготовки презентации\срочной выборки невероятно важной информации – можете не сомневаться, ИТ лидер снова на белом коне мчит на выручку; и т.д. и т.п. И это без учета запланированных к реализации задач, которые имеют свои сроки вывода в промышленную эксплуатацию.

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

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

.2.

За что отвечает

Ритуалы. Почему принято ежедневные и прочие мероприятия по скрам называть ритуалами отдельный вопрос, который ждет своего исследователя. У меня только одна прочная ассоциация с этим словом – похороны.

Подразумевается, что в команде есть отдельный от ИТ лидера человек, который выполняет функции скрам мастера и ведет дейли, ретро, планирование и даже груминги. Но это не так. Обычно все это делает ИТ лидер, так как это гораздо проще и эффективнее. В противном случае погружение сотрудника команды во все перипетии планирования (где и как играем, где рыбу заворачивали, а где что иное наворотили), а к этому – учитывать результаты ретро, понимать по озвученному на дейли, где и куда надо поднажать, будет чрезвычайно отвлекать от основной работы. К тому же есть шанс, что через некоторое непродолжительное время такой работы у сотрудника начнет дергаться правый глаз, а то и ряд конечностей, и он завалит свои основные задачи, уйдя на больничный с тяжелым расстройством психики, потерей сна и аппетита. Или в запой.

Оценка задач. Любая задача, попадающая в бэклог команды, требует оценки. И неважно, что в постановке из всех требований только одна строка и оценка может быть выполнена по голосам в голове, или по внутренностям забитой только что курицы, или каким-то иным способом с крайне достоверным результатом – например, с помощью кофейной гущи. В таких случаях можно назвать 1000 или 700 человекодней, кому что нравится. И далее смотреть на реакцию автора задачи. Если у него будут вопросы по величине оценки, то мотивировать отсутствием внятных требований и рисками; если нет вопросов, то оставляем как есть – бэклогу от этого даже лучше.

Хуже всего, когда оценка по задаче в одну строку требуется в течение получаса, но с примерным перечнем работ, которые будут входить в оценку. В этом случае вы вряд ли сможете обойтись без помощи архитектора и разработчика команды. Но, при определенном навыке и опыте, вы и тут сможете выйти из положения, если ни архитектор, ни разработчик не могут уделить вам внимание в ближайшие 30 минут. Тогда берете те же 700 человекодней и примерно подгоняете оценку работ на архитектуру, аналитику, разработку, тестирование и вывод в промышленную эксплуатацию, не забывая о рисках и своей части – оценке работ на ИТ лидера. В моем случае последняя часть (риски + оценка работ ИТ лидера) включалась в коэффициент, равный 1,4, на который умножалась сумма работ архитектуры, аналитики, разработки, тестирования. Таким образом получалась итоговая оценка.

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

Планирование. Увлекательное мероприятие, когда все, кому не лень, пытаются запихать в стакан команды на 1 литр задач суммарной оценкой на 10 литров. И очень удивляются почему же не влезает. В моем случае владельцем бэклога команды является представитель бизнеса. Поэтому он и должен определять приоритет задач и список того, что будет взято в работу. И тут весь вопрос в том, какие оценки были даны по задачам в бэклоге и у кого из заказчиков этих задач авторитет больше, чем у представителя бизнеса, курирующего команду. Начинаются встречи, на которых идет детальный и тщательный процесс измерения величины авторитетов обеих сторон – вес, объем, диаметр, длина. Не договорившись о корректности замеров, стороны могут пригласить на состязание вышестоящих начальников. И измерительный процесс начинается снова.

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

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

Сроки. Каждый раз обсуждение, или согласование, или перенос сроков походит на перетягивание каната: заказчик тянет, стараясь уменьшить срок, ИТ лидер – увеличить. И взятые на себя обязательства, подписавшись под тот или иной срок, ИТ лидер должен свято соблюдать. От этого зависит множество интересных и не очень моментов, в том числе связанных для заказчика с самоутверждением и получением наград, медалей и прочих «рыгалий» от руководства. И тут уже совершенно не важно, как дела обстоят в реальности. Есть срок, который «должен быть выдержан». Порой ИТ лидеру требуется приложить невероятные усилия, чтобы уложиться в срок и при этом сохранить настрой и мотивацию команды.

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

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

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

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

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

Если ИТ лидер заранее предупреждает о рисках и проблемах и фиксирует все это в письмах, протоколах встреч и т. д., то он демонстрирует, что, подобно Будде Шакьямуни, преисполнился мудрости, и, следовательно, достиг вершин «зрелости» и компетенций архистратига. Но самое главное: ИТ лидер работает на упреждение проблем, которые со временем могут вылиться на команду ушатом приятных и не очень субстанций, защищая таким образом и команду, и себя.

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

Команда. Данный раздел вряд ли будет открытием – все, что будет изложено ниже, озвучивается во всех книгах и курсах по менеджменту и может показаться трюизмами и банальщиной, поэтому постараюсь кратко и с примерами из жизни рассказать о своем опыте. Напомню, что я излагаю исключительно свой личный опыт и его переосмысление.

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

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

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

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

Если кандидат прошел собеседование, то необходимо плавно погрузить его в команду. Необходим «куратор» – сотрудник команды, который имеет аналогичную роль, готовый вводить в курс дела нового сотрудника; требуется максимально точно нарезать новому сотруднику задачи и обозначить сроки, которые вы будете внимательно отслеживать и проверять; потребуется ряд встреч (one-to-one, либо на троих с «куратором») для «прощупывания» состояния сотрудника, его адаптации к новым условиям, для поддержки и мониторинга возможных проблем. Все эти действия помогут влиться новому сотруднику в команду с минимальными проблемами и с ощущением поддержки и внимания. Подобная «опека» занимает от 1 до 3 месяцев – этого достаточно для того, чтобы окончательно определить, сможет ли новый сотрудник работать в команде.

Знаю несколько случаев, когда нового сотрудника буквально бросали в «воду», где были не только «акулы», но и «плезиозавры» и прочие милые «зверушки», и оставляли там барахтаться. А потом, месяца через три, возвращались и искренне удивлялись, что сотрудник куда-то «запропастился». Нечего и говорить о том, что почти всегда это заканчивается печальным опытом для нового сотрудника и его увольнением.

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

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

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

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

Взаимодействие с заказчиком. Самое увлекательное и бодрящее мероприятие для ИТ лидера – это общение с заказчиком. Почему, cпросите вы? Думаю, что основной причиной является разница в мышлении. Заказчик мыслит эмоциями, образами и финансами. В моем случае заказчик – это всегда представитель бизнеса, он мыслит не техническими категориями и далек от специфики ИТ. К общению с ним надо подходить творчески, в приподнятом настроении, в легкой эйфории и обязательно с юмором. И стараться настроиться на волны легкого сюрреализма, как в фильмах Сальвадора Дали и Поля Элюара. В противном случае договориться ни о чем не получится. Главное помнить важную вещь: заказчик понимает язык денег, стоимости ресурсов и расходов. Это главный козырь в диалоге с заказчиком.

Вот как может выглядеть диалог с заказчиком без использования главного козыря:

Сцена VVCX

Участники: Заказчик, ИТ Лидер

Заказчик: (Важно и повелительно) Я визуал (вопросительный взгляд ИТ Лидера). Покажите мне план-график.

ИТ лидер: (обстоятельно и меланхолично) Он еще не готов, милорд, так как мы встречаемся, чтобы как раз согласовать сроки и ресурсы нашего победного марша на очередную группу ветряных мельниц («Строго на север порядка 50 метров …»).

Заказчик: (немного раздраженно) Тогда покажите прошлый план.

ИТ лидер: Вот он.

Заказчик: - (раздражение повысилось на несколько градусов) Но почему тут другие даты и другая диспозиция?!

ИТ лидер: - (в той же спокойной манере) Но вы же просили прошлый план, милорд.

Заказчик: - (раздражение подходит к точке кипения) Но я тут ничего не понимаю. Мне нужен актуальный план-график. Планирую начать операцию завтра в 8 часов и опрокинуть эти мельницы к 12 часам дня. Подготовьте план-график в трех вариантах: Вы атакуете мельницы в одиночном пешем строю без оружия; Вы атакуете в одиночку в конном строю, без оружия, сидя на лошади спиной к мельницам; Вы в одиночном конном строю, жонглируя деревянными булавами, атакуете мельницы, но выбираете направление удара в противоположную от мельниц сторону.

ИТ лидер: Но, милорд. Во всех трех вариантах шансы на победу минимальны?! Может, рассмотрим четвертый вариант, когда мы атакуем…

Заказчик: (окончательно вскипев) Остановитесь. Этих трех вариантов достаточно, чтобы выбрать наилучший вариант для победы в сражении.

Сцена VVCXI

Те же участники

ИТ лидер: Я подготовил план-график для трех вариантов и отправил вам голубиной, фельдъегерской почтой и по граммофону.

Заказчик: (устало и отрешенно) Я не смотрел. Хорошо, что напомнили. От этого зависит наша победа. Давайте же посмотрим. (смотрит невнимательно и по диагонали, хмуря брови и изображая на лице титаническую работу мысли). Да, прекрасно. Вот вариант, который принесет нам легкую победу - Вы в одиночном конном строю, жонглируя деревянными булавами, атакуете мельницы, но выбираете направление удара в противоположную от мельниц сторону.

ИТ лидер: (легкое недоумение) Но ведь я буду безоружен…

Заказчик: (покровительственно) Совершенно верно.

ИТ лидер: (недоумение возрастает) Но ведь один я не справлюсь с мельницами – их слишком много!

Заказчик: (несколько пренебрежительно) Ерунда.

ИТ лидер: (недоумение граничит с помешательством) Но ведь скакать придется в противоположную от мельниц сторону! Как же я смогу их победить?

Заказчик: (покровительственный тон добирается до отеческого благодушия) Постарайтесь, голубчик. Я знаю, что вы достаточно профессиональны, чтобы справиться с этой задачей. И постарайтесь это сделать к 11 часам дня. Я уже запланировал победный парад в честь нашей победы на 12 часов.

Занавес.

А вот как будет выглядеть концовка сцены VVCCXI с учетом козыря в рукаве ИТ лидера: