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

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

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

Предисловие

Глава 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 месяцев – этого достаточно для того, чтобы окончательно определить, сможет ли новый сотрудник работать в команде.

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

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