Вызовы менеджера в мире разработки

Когда человек решает идти по пути менеджера в разработке, например, в начале карьеры или, особенно, уже работая в команде разработки, то приходится фокусироваться на знаниях, которые порой трудно классифицировать и уложить в своей голове. В отличие от разработчика, чей фокус часто сужен до решения конкретных технических задач, менеджеру приходится иметь дело с менее осязаемыми инструментами: процессами, коммуникацией и людьми. В основе своей они имеют другую природу, потому что здесь больше неопределенности и различных инструментов, которые должны помогать в работе. Часто менеджер фокусируется на выполнении правил фреймворка, на механике какого‑нибудь инструмента или метода, забывая, что в конечном итоге пользователь должен получить ценность. Вполне возможна ситуация, при которой все условия фреймворка выполнены, процесс разработки «настроен», на доске сотни выполненных задач, но пользы от них не так много, как кажется. И заказчики, и конечные пользователи могут не оценить вклад команды разработки и самого менеджера. Ситуация, увы, частая и очень обидная. Главная сложность заключается не в изучении теории, а в её применении на практике, где ключевую роль также играет и «социальный фактор».

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

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

ITIL 4: системный взгляд на создание ценности

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

Ответом на эти вопросы может стать библиотека ITIL, а именно её актуальная — четвертая версия (ITIL 4). Между предыдущими версиями и четвертой есть большая разница. В отличие от предыдущих версий, сфокусированных на IT‑инфраструктуре, ITIL 4 предлагает целостный взгляд на создание ценности через сервисы. Если вы раньше никогда не сталкивались с ITIL, я рекомендую изучать сразу четвертую версию. К сожалению, её часто незаслуженно обходят вниманием в пользу более «модных» фреймворков.

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

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

По сути, ITIL 4 — это та самая карта или «конспект», который собирает лучшие мировые практики управления сервисами и разработкой в единую непротиворечивую систему.
Команда профессионалов собирает в нее лучшие практики со всего мира без привязки к какой‑либо методологии, фреймворку и тому подобное Акцент делается на практики и принципы, которые постоянно обновляются и дополняются. Если кто‑то практикует Scrum или использует Kanban метод, он сразу найдет в ITIL много знакомого. Это современные методы, которые доказали свою эффективность и вошли в ITIL. В этом плане ITIL объединяет все лучшее, проверенное временем в одном месте. Такая информация быстро помогает менеджеру освоится во всем современном многообразии инструментов и выбрать из них те, которые будут полезны ему и команде разработки. Проще говоря — стать компетентным менеджером.

Из личного опыта

В разработке я не так давно, примерно 6 лет. Работаю Delivery manager«ом. В поисках чего‑то нового и интересного увидел на Youtub«e выступление Пименова Алексея. Он рассказывал про новый подход в Agile — Kanban метод. Решил попробовать углубиться и изучить тогда новый для меня метод. Прошел обучение по программе KSD и получил официальный сертификат. Для начала казалось не плохо. Это действительно очень мощный курс с упором на применение знаний на практике. И большое спасибо Алексею, за то, что он, на тот момент, уже адаптировал официальный курс от Kanban University.

Но вот что меня больше всего поразило, когда я проходил этот курс. Меня не покидала мысль, что я знаю все, о чем говорит тренер. И очень часто даже угадывал итоги, которые он выводил. Поразительно, но там, где другие видели «революцию», новые подходы, инструменты, я видел логичные и понятные для меня действия, которые я и без того применял на практике. Из всего курса я записал себе на бумаге только несколько слов: LT, throughput, CFD. Проблемы здесь нет, я не потратил время впустую. Как я уже сказал, курс очень полезный и я готов его рекомендовать. Что касается именно меня, то я, на тот момент, уже не первых год изучал и применял ITIL. Начал я с третьей версии, а на тот момент хорошо был знаком с четвертой версией. Уже прошел обучение и сдал не самый простой экзамен в своей карьере. Другими словами, у меня в голове уже был хороший конспект, на который отлично ложился материал курса KSD.

Система создания ценности (Service Value System) — ядро ITIL 4

Если попытаться рассказать вкратце об ITIL, то удобнее всего начать с Service Value System (SVS):

На русский ее можно перевести как система доставки ценностей. Обучение ITIL сводится к более глубокому пониманию именно такой модели или, как создатели ITIL считают, системы. С первого взгляда эта система кажется логичной, но не очень понятной. Изучая SVS, мы точно можем сказать, что для успешной работы нужны управляющие принципы, хороший высший менеджмент, непрерывное выполнение определенных практик и, безусловно, постоянное улучшение. Последнее отсылает нас к циклу Шухарда‑Деминга. Более глубокое понимание раскрывается, когда пытаешься понять, почему система имеет такую форму, а элементы расположены именно в таком порядке. Важно знать какую роль ITIL отводит для каждого элемента в этой системе. Даже направление стрелок имеет значение. Изучая SVS, становится очевидно, что в процесс доставки ценности вовлечено довольно много разных по логике, но связанных между собой элементов.

Центральным элементом системы является Цепочка создания ценности (Service Value Chain), которая детализирует набор действий, необходимых для реакции на спрос и создания ценности:

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

Руководящие принципы

На самом верху SVS находятся руководящие принципы. Эти принципы, которых всего 7, призваны поменять подход к управлению.

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

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

Фокус на ценности (в первую очередь для клиента/заказчика)
Первый и главный принцип. Как правило, установка на самые ценные задачи происходит за счет приоритезации беклога. В scrum и его форках, это может сделать человек с ролью владелец продукта. В Kanban беклог может отсутствовать или эту активность можно перенести на заказчиков. Очень часто я вижу, что задачи, которые уже должны быть в работе, находятся в беклоге. В это время, в работе задачи, ценность которых не ясна или отсутствует. Не редки случаи, когда задача, над которой уже работает команда разработки, теряет свою ценность. Хороший триггер, чтобы задуматься о продолжении работы над такой задачей. Здесь ITIL учит нас смотреть на работу глазами пользователей и перед тем, как взять задачу в работу или выбросить ее из работы, задаться вопросом: «Какую ценность для пользователя несет эта задача?». Это позволяет бороться с ситуацией, когда процесс формально отлажен, задачи выполняются, но реальная польза от продукта оказывается минимальной. Очень полезно иметь систему определения ценности выполняемой работы.
Начни с того, что уже есть сейчас
Тем, кто изучает Канбан метод, этот принцип хорошо знаком. Именно так он и звучит в Канбан методе. По важности я бы поставил его на ровне с первым. При своей кажущейся простоте и легкости понимания, этот принцип почти всегда игнорируют. Изучая процессы управления разработкой, начинающие менеджеры не заслуженно обходят его стороной. Много раз я видел, когда в команде появляется новый руководитель, который начинает со строительства доски. Обычно, менеджер, уже слышавший про Канбан. Идея, в общем, не плохая. Только в этой деятельности он, как правило, забывает изучить процесс, по которому сейчас работает команда. Может быть не совсем хороший процесс, не идеальный, но процесс, который уже приносит какую‑то пользу. Любые преобразования должны начинаться с глубокого анализа текущего состояния процессов и уважения к существующей практике. Приходя в команду с готовым решением («внедрим новую доску!») и игнорируя текущий уклад, менеджер обрекает себя на сопротивление и имитацию изменений. Понятно, что такой процесс не даст никакой пользы ни одним, ни вторым.
Работай итеративно, собирая обратную связь
На текущий момент существует не мало статей про пользу итеративной разработки и петли обратной связи. Чаще всего ассоциируется со спринтами в Scrum. Не все и далеко не сразу понимают смысл спринтов. Неправильный процесс, когда команды каждые две недели формируют спринты, цель которых выполнить все задачи спринта. Команды работают так годами и не видят ничего плохого в таком подходе. Иногда такой подход действительно работает. Но чаще приводит к разрыву между заказчиком и разработчиками. К использованию спринтов, как элемент давления на команду разработки (в обратную сторону тоже бывает). Некоторые компании нанимают scrum‑мастера для поддержания такого процесса разработки. В итоге, получаем большую проблему как для компании в целом, так и для самого scrum‑мастера. Человек, который разбирается в scrum, на такую должность не пойдет, а вот начинающий scrum‑мастер или человек, который хочет им стать, вполне может. В его голове стойко закрепится не правильное понимание использования спринтов и сбора обратной связи. ITIL 4 итеративный подход раскрывается глубже. Речь не о простом дроблении работы на двухнедельные отрезки, а о создании коротких циклов обратной связи со всеми участниками системы: заказчиком, пользователями, командой. Это позволяет быстро проверять гипотезы, адаптироваться к изменениям и не уходить в разработку того, что уже не актуально.
В части ITIL Foundation этот принцип раскрывается слабо. Лишь краткое описание и рекомендации по его использованию. Более подробно он описан в треках Managing Professional (MT), Transition как важная часть для профессионального роста менеджера.
Поощряй сотрудничество и развивай прозрачность
Этот принцип выходит далеко за рамки команды разработки. В лучшем своем проявлении этот принцип распространяется и на заказчика, и на пользователей продукта. Прозрачность процесса разработки и сотрудничество с бизнесом трудно поддерживать при стремительном росте компании. Когда бизнес маленький, заказчик один и может напрямую общаться с разработчиками. Команда разработки одна и в ней 4–5 сотрудников. В роли заказчика может выступать собственник компании. Когда компания растет, количество людей быстро увеличивается. Растет и отдел разработки. Появляются отделы инфраструктуры и эксплуатации. Становится сложнее управлять продуктом и его разработкой. Многие начинают наращивать прослойку между заказчиком и разработкой. Нанимают большое количество менеджеров проектов и других управляющих, на плечи которых сваливается ответственность по управлению разработкой. И очень часто только ответственность. Как правило, у менеджера проектов нет ни знаний, ни полномочий управлять процессом разработки. Все, что он может — рисовать и бесконечно переделывать диаграмму Ганта, устраивая при этом постоянные «статусные совещания». Эта ситуация даже породила мем про попугая и менеджера проектов.
Kanban помогает нам привлечь обратно непосредственного заказчика в разработку за счет хорошей визуализации процесса. Многое в Kanban нацелено на то, чтобы руководитель самого высшего звена, одним взглядом на доску разработки смог оценить ситуацию с проектами, которые сейчас разрабатываются и, возможно, принят решение. Получаем процесс, при котором при росте компании, мидл менеджмент в лице менеджеров проектов, не растет или даже не появляется.
Scrum и его фреймворки решают туже задачу — масштабировать процесс разработки таким образом, что бы можно было избежать лишних прослоек менеджмента. Длину спринта подбирают таким образом, чтобы удобно было получать обратную связь от заказчика и вовремя реагировать на изменения.
ITIL 4 показывает нам и учит, что прозрачность процесса и активное сотрудничество с бизнесом — ключ к избежанию наращивания лишних управленческих прослоек и издержек.

Заключение

ITIL 4 хороший фундамент для эффективного управления. Это не очередной жесткий фреймворк, который нужно внедрить «по учебнику». Это система знаний, которая помогает менеджеру выработать правильное мышление и адекватно реагировать на постоянные изменения. Она позволяет понять, зачем нужны те или иные практики из Scrum, Kanban или других методов, и как их грамотно интегрировать в общую систему доставки ценности. Изучая ITIL 4, менеджер становится архитектором сервисов, фокусируясь на главном — результате, который оценит конечный пользователь.

ITIL 4 для менеджеров в разработке. Почему фреймворк — это еще не всё