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

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

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

Предисловие

Глава 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 с учетом козыря в рукаве ИТ лидера:

…

ИТ лидер: (констатация и холодность) Но ведь я буду безоружен…

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

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

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

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

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

ИТ лидер: (вино в бокале замерзло) Это будет стоить два сундука золота, три алмазных рудника и 10 волооких прелестниц-крестьянок.

Заказчик: (возмущенно и неуверенно) Что? Это слишком дорого. Есть другие предложения?

ИТ лидер: (произошло замерзание спирта) Да. Мы нападем на них ночью, зайдя в тыл и ударив пиками 20 тяжело вооруженными кирасирами в сомкнутом строю. Успех будет обеспечен. Это будет стоить один сундук золота. И ваш завтрак будет приправлен вкусом победы.

Заказчик: (оживляясь) Вы уверены, что этот вариант принесет нам успех?

ИТ лидер: (мировой океан превратился в лед) Вот расчеты метрологии, отношение твердости наших пик к лопастям мельниц, вращательный момент маховика, сила аромата конского пота, мощь попутного ветра…

Заказчик: Достаточно (вытирая пот со лба). Решено, пусть будет ваш вариант, хоть я и не смогу насладиться моей сокрушительной победой в полной мере – ночью будет слишком темно.

ИТ лидер: (легкая оттепель) Предусмотрели, Ваша светлость. Мы атакуем в полнолуние.

Заказчик: - Прекрасно. (Лицо Заказчика сияет в лучах славы и воображаемого венка фельдмаршала, который водружает на его голову сама Афина).

Занавес.

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

.3.

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

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

.4.

Цель

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

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

Мораль: сложно играть по правилам, когда никто, кроме вас, не соблюдает этих правил.

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

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

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

.5.

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

Существует теория об упрощенном графическом представлении сотрудника, на основании которой дается общая оценка ценности того или иного сотрудника для команды\компании. Условно сотрудников делят на:

- I-shape (от англ. Shape - форма) – специалист, который хорошо погружен только в одну область. Узкий специалист (англ. «I» означает горизонтальное погружение только в одном направлении).

- T-shape – специалист, у которого есть набор базовых знаний в нескольких областях и высокая квалификация в одном направлении (горизонтальная черта – базовые знания, вертикальная черта – высокая квалификация в одной области).

- C-shape (от англ. Combo – комбо, комбинация) – сотрудник, сочетающий в себе высокую квалификацию в нескольких направлениях (графически изображается как горизонтальная черта, из которой исходит несколько вертикальных линий, вроде этого «TTT»).

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

Перечень качеств, которые сегодня являются обязательными для ИТ лидера и входят в топ-лист качеств по мнению крупных, а за ними и не очень, компаний, который, безусловно, слепо заимствован из западной литературы, выглядит из большого списка, который теоретически можно разделить на soft (англ., буквально «мягкий») и hard (англ., буквально «твердый») skills¹ (англ., буквально «навык, умение»). Если не вдаваться в разделение на типы «скилов», то примерно список выглядит следующим образом:

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

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

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

.6.

Дипломатия

Поразительно, как увеличились и упростились возможности коммуникации между людьми в современном мире. Ранее послание в виде письма или устного сообщения, которое должен был заучить, а потом озвучить посланник (главное, чтобы в процессе долгого путешествия он не забыл текст сообщения), могло двигаться так долго, что получение самого сообщения уже не имело никакого смысла. Известно, что один гонец даже скончался после доставки «почты».

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

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

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

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

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

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

ИТ лидер должен помнить, что после каждой важной встречи (а встречи почти все важны, кроме встреч внутри команды, наверное), ИТ лидер должен аккуратно и максимально в пользу своей команды составить протокол, который направит на всех заинтересованных лиц.

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

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

Для каждого оппонента желательно подбирать свой тип поведения в общении для достижения наилучшего эффекта от встреч и взаимодействия в мессенджерах и почте.

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

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

Оркестра музыка ласкающая слух -

Итог союзного усилья музыкантов,

Где каждый знает свой черед, и вместе

Они являют единенья дух…

Из поэмы Фридриха Баденбургского

2.1. Знакомство

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

Сам этап знакомства с очередной командой у меня всегда проходил по приблизительно одинаковому сценарию: проводилась онлайн-встреча с командой, происходило представление из серии «Алиса, познакомься, это Окорок! Окорок, это Алиса». И далее, как и у Алисы за столом, на встречах ощущалось легкое напряжение. Команда нервничает, так как непонятно, чего ждать от нового ИТ лидера, и наоборот, новый ИТ лидер, попадая в новые условия, чувствует дискомфорт, так как не понимает, что ждет его впереди. Конечно, можно использовать шутку (бывают шутки и со стороны участников команды), чтобы как-то разрядить напряжение на первой встрече, но из моего опыта следует, что подобные встречи никогда не проходят гладко. Далее потребуется еще несколько месяцев, чтобы окончательно разобраться и понять, у кого какой темперамент, кто с какой скоростью делает ту или иную задачу, какие оценки озвучивает (оптимистичные или пессимистичные), кому надо напоминать о встречах\событиях календаря, а кто приходит заранее, у кого какой опыт и настрой на работу и т. д. Участники команды тоже пытаются как можно быстрее разобраться в ИТ лидере и тут на помощь приходит такой инструмент, как встречи One-to-one (от англ. «один на один») и проведение собеседований с кандидатами.

2.2. Встречи One-to-one

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

Что касается самой встречи, то у меня сложился следующий план:

Вступление\разогрев\разминка.

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

Основная часть, на которой происходит неформальное общение, поднимаются вопросы, относящиеся к участнику встречи.

Пройдемся по каждому этапу, чтобы раскрыть их смысл и цель.

Вступление. Очень короткий этап, по сути, это приветствие и один-два незначительных вопроса для создания доверительной атмосферы (о погоде или на любую другую тему, не связанную с работой). Главное, чтобы собеседник почувствовал легкость и непринужденность диалога.

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

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

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

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

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

Я стараюсь разбивать собеседование на пять частей: приветствие; представление - короткий рассказ о проекте, команде, процессах и почему мы ищем сотрудника на ту или иную позицию; технические вопросы кандидату; общие вопросы кандидату; вопросы кандидата.

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Примечания

1

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

Hard skills - профессиональные знания и умения, которые необходимы для выполнения определённой работы

Вернуться