В этой статье показана важность трансляции ценности ИТ для руководителей с использованием подхода, ориентированного на результат, и даны советы по выполнению.
ИТ-проект – это не самоцель, а средство достижения бизнес-цели. В наше время, когда руководители и лица, принимающие решения, постоянно сталкиваются с новыми фреймворками, технологическими тенденциями, как никогда важно сделать шаг назад и подумать о бизнес-цели, прежде чем принимать решение о технологическом способе ее достижения.
Спустя десятилетия после появления информационных технологий, задача остается прежней: успешно применять ИТ-практики, которые улучшают потоки доходов и раскрывают новые возможности DevOps. Организациям срочно необходимо создать рамки для управления информационными системами и применять их в повседневной деятельности, способствуя повышению ценности бизнеса и улучшению экономических показателей.
Однако значительная часть используемых сегодня практик DevOps была заимствована из автомобильной промышленности. Хотя они работали на сборочных линиях и были хорошей отправной точкой для ИТ и DevOps, их необходимо пересмотреть и обновить, чтобы они оставались актуальными в современном технологическом мире. К таким устаревшим методам относятся:
- Строгая иерархия и исполнение сверху вниз: Команды, организованные со строгим разделением труда, в итоге создают изолированные рабочие зоны, что ставит под угрозу общую цель.
- Каскадная модель: Бизнес-ценность выпускается огромными циклами, не имея подтверждения по ходу проекта.
Для бизнес-лидеров важно следить за результатом. В этой статье мы рассмотрим способы отделения “что” от “как” и дадим лицам, принимающим решения, несколько советов, которые они смогут использовать в своей сложной повседневной работе.
Связь между методологией и результатом не всегда очевидна
В технологических компаниях методология обычно является заботой инженерных групп, а не решением руководства. В большинстве случаев лица, принимающие решения на уровне бизнеса, не имеют детального представления о том, чем занимаются инженеры и как они организуют свою работу.
Аналогичным образом, исполнительная команда не имеет детального представления о том, чем занимаются другие команды компании, например, отдел продаж, маркетинга или операционный отдел. Но это нормально, поскольку это не входит в их обязанности. Их работа заключается в том, чтобы иметь представление о деятельности различных команд и координировать их взаимодействие для достижения целей компании.
Поэтому в обязанности инженерного руководства входит “транслировать” работу команды руководящему составу организации. Если все сделано правильно, организация в целом лучше понимает, какую ценность представляет команда инженеров. У исполнительной команды появляется ощущение, что они могут более точно прогнозировать работу инженерной команды и, таким образом, вписывать ее в планирование более высокого уровня.
Как донести до руководителей ежедневную ценность инженерной деятельности
Задача инженерного менеджмента – сделать этот перевод как можно проще, но это трудная задача. Вот несколько советов, которые могут помочь:
- Увязывайте показатели развития с общими целями организации
Точно так же, как у отдела продаж есть приборная панель с метриками, у инженерного отдела тоже должна быть такая панель. При создании приборной панели с метриками сосредоточьтесь на показателях, которые отслеживают качество программного обеспечения, а не на количественных показателях, таких как количество строк кода или сообщений об ошибках.
- Обеспечьте понимание прогнозирования разработки программного обеспечения руководством компании
Генеральный директор компании может посмотреть на приборную панель отдела продаж и понять несколько основных показателей, например, соответствуют ли цели целям организации или нет.
Если инженеры создадут приборную панель, упомянутую в пункте №1, следующим шагом будет сделать так, чтобы команда руководителей могла самостоятельно читать и понимать ее, чтобы они могли самостоятельно делать выводы. Цель состоит в том, чтобы они могли оценивать процесс разработки программного обеспечения, а не только результат.
- Сосредоточьтесь на межкомандных отношениях
Другим командам в компании сложно понять повседневную работу разработчиков и инженеров. Однако если вы сможете научить их понимать динамику и важность этого, вы сможете радикально улучшить то, как организация видит их работу и, что еще лучше, как остальная часть организации взаимодействует с членами инженерной команды.
Например, если вы научите их, почему разработчикам необходимо сосредоточиться и войти в поток непрерывной работы, другим людям в компании станет легче управлять своими ожиданиями, скажем, относительно того, сколько времени требуется разработчику, чтобы ответить на электронную почту.
- Установите связь между разработчиками, продуктом и клиентом
Разработчики – это те, кто создает продукт, но зачастую они не имеют никакого контакта с клиентом. Многие из них никогда не видят, как их разработка решает проблему, которую она должна была решить в первую очередь. Они создают продукт, внедряют его, и на этом цикл со стороны разработчика завершается.
Задумайтесь на минуту, насколько это ограничивает возможности. Исследование, проведенное в 2014 году, показало, что повара делают еду на 10% вкуснее, когда могут видеть своих клиентов в процессе приготовления. Это объясняется тем, что, как люди, когда мы находим цель в своей работе, мы работаем лучше. Относитесь к своим разработчикам как к людям, а не просто как к еще одному кусочку большого пазла.
Следуя этим советам, вы способствуете тому, что весь процесс разработки программного обеспечения становится гораздо более целостным. Он перестает быть процессом разрозненных людей, выполняющих обязанности, которые каким-то образом вписываются в общую картину, которую они не видят. Он начинает превращаться в сплоченные команды, которые творчески работают над проблемой, взятой ими в свои руки.
Почему вам необходимо выбрать правильный план, ориентированный на результат
В 1968 году математик и программист доктор Мелвин Конвей в статье, представленной в Harvard Business Review, изложил то, что стало известно как “закон Конвея”:
«Организации проектируют системы, которые копируют структуру коммуникаций в этой организации».
Проще говоря, идея, переданная Конвеем, заключается в том, что организации должны формировать себя в соответствии с образом результата, которого они хотят достичь. Поэтому при оценке методов работы руководство должно всегда помнить о результате и формировать команды, процессы и структуры таким образом, чтобы они лучше соответствовали желаемому результату.
Одним из способов достижения желаемого результата является внедрение DevOps в организацию. Различные подходы и методологии должны объединиться под одной движущей силой, и именно этого позволяет достичь DevOps.
В основе DevOps лежат самоорганизующиеся команды различных дисциплин, которые собираются вместе в начале проекта и создают петли обратной связи, которые постоянно улучшают результат. DevOps также автоматизирует задачи, которые можно автоматизировать, и освобождает время и пространство для головы членов команды, чтобы они могли сосредоточиться на том, что действительно важно: на обеспечении ценности бизнеса.
Хотя это может показаться очевидным, правда заключается в том, что спустя почти 50 лет после публикации исследования Конвея организации все еще пытаются достичь бизнес-результатов за счет использования ИТ.
Как оценивать методы, ориентируясь на результат
Менеджеры по продуктам обычно работают на основе дорожной карты продукта, состоящей из списка функций, переданного им высшим руководством. Их задача заключается в том, чтобы подтолкнуть команду к созданию и внедрению этих функций.
Однако может случиться так, что все функции будут реализованы, но при этом будет создан не тот продукт. Почему? Потому что функции являются следствием шага, который должен предшествовать им: проблемы.
Как менеджер продукта, вместо того чтобы говорить об особенностях, попробуйте перевести разговор на проблемы, которые вам нужно решить, и на результаты, которых должна достичь команда.
Допустим, вы создаете платформу, с помощью которой вы будете управлять своими пользователями. Вместо того чтобы думать о такой функции, как “пользователи должны иметь роли и разрешения”, уточните проблему: “Необходимо дифференцировать этих пользователей в плане того, что они могут видеть и делать”.
Теперь подумайте о результате: Как будет выглядеть пользователь-администратор, который управляет конечными пользователями на этой платформе? Что они смогут делать?
При таком переходе важно сохранить эти цели измеримыми, например, сделать их SMART: конкретными, измеримыми, достижимыми, актуальными и привязанными к срокам. Приняв такой способ работы, основанный на проблемах, а не на возможностях, вы получите несколько преимуществ:
Это дает большую автономию командам, позволяя каждому члену внести свой вклад, используя свой опыт.
- Вся команда может владеть проблемой и понимать, когда она будет решена.
- Менеджер продукта будет предоставлять результат, а не функцию.
- Команда перестает разрабатывать функции, которые не нужны клиентам.
- Команда становится более творческой, когда ее просят решить проблемы.
- Команда может сосредоточиться на улучшении существующих функций и достижении решения проблемы, а не на создании новых функций.
Заключение
Успешные ИТ-организации знают, как связать воедино три основных элемента разработки программного обеспечения: людей, процессы и технологии. Эта триада – ключ к процветанию команд и компаний и созданию выдающихся продуктов и проектов, решающих реальные проблемы пользователей.
По мере развития технологий автоматизация становится все более доступной, а практика DevOps становится неотъемлемой частью любой команды разработчиков. Игнорировать их – значит не использовать возможности технологии для стимулирования производительности и создания ценности для бизнеса. Это подводит людей в организациях и процессы, над которыми они упорно трудились.