Джек М. Жермен
29 июня 2021 года, 4:00 утра по тихоокеанскому времени
Индустрия разработки программного обеспечения — это подготовка к постпандемической деятельности. Но разработчики, без сомнения, обнаружат, что гонка за выпуском, скорее всего, не удастся, если они не учтут значимые показатели в своей реализации.
Наиболее важным фактором для успешных внедрений и запусков является использование умных, точных и эффективных показателей, — говорит Ауримас Адомавичус, соучредитель и президент Devbridge, глобального консалтингового агентства по цифровым продуктам.
Устойчивое программное обеспечение определяется показателями продукта, но оно должно быть принято во всем предприятии. Он пояснил, что эффективные метрики служат точкой сравнения для бизнеса и меняют поведение при принятии решений. Организационное принятие метрик обеспечивает единое измерение для команд и инициатив для принятия более крупных решений по портфелю.
Адомавичюс имеет опыт разработки эффективных программных продуктов для нескольких компаний из списка Fortune 500. Его мантра заставляет разработчиков программного обеспечения понять важность использования правильных и точных показателей при разработке устойчивых продуктов.
В возрасте 27 лет он основал Devbridge, чикагскую консультационную фирму по техническим вопросам, и увеличил штат компании до пятисот сотрудников в пяти глобальных офисах.
Ауримас стал лауреатом премии Ernst & Young «Предприниматель года» в 2018 году и был отмечен в журналах Entrepreneur, Raconteur, Forbes и других изданиях. Он является автором книги «Секретный источник: культура, навыки и процесс создания великолепных цифровых продуктов»
TechNewsWorld поговорил с Адомавичиусом, чтобы обсудить концепцию того, как разработчики программного обеспечения могут заставить работать значимые показатели
.
TechNewsWorld: Как пандемия изменила восприятие или использование показателей продукта?
Ауримас Адомавичус: Вопрос может быть больше о росте или показателях как индикатор. Я не знаю, действительно ли что-то кардинально изменилось, за исключением того, что во время пандемии многие организации очень быстро поняли, в чем заключаются пробелы в их реализации. Большинство этих пробелов на самом деле связано с самообслуживанием клиентов и улучшением качества обслуживания клиентов.
Значит, пандемия не повлияла на разработку программного обеспечения?
Адомавичус: Для внутренних работников возникла большая пробел, потому что в тот момент, когда люди были отправлены в работая из дома, многие компании осознали, что большая часть технологий, лежащих в основе программного обеспечения продуктов, во многих отношениях не позволяет обеспечить распределенную рабочую силу. Сейчас большинство людей возвращаются. Полагаю, условия нормализуются.
Как этот сдвиг повлиял на индустрию программного обеспечения?
Адомавичус: Большинство сервисов предоставляется онлайн, в отличие от людей, использующих обычные сайты. Компаниям необходимо было ускорить создание технологий и программного обеспечения.
Мы наблюдаем рост бизнеса более чем на 30 процентов по сравнению с 2020 годом. По тому же вектору в 2021 году вы будете расти довольно быстрыми темпами. Думаю, он будет расти и дальше. Пандемия ускорила создание компаниями необходимых инструментов, своих сотрудников, а также программного обеспечения и опыта.
Итак, с точки зрения разработчика программного обеспечения, разработчики должны быть внимательны, когда мы говорим о показателях. Нам действительно нужно подумать об этом.
Как именно показатели учитываются при реализации программного обеспечения?
Адомавичус: Во-первых, нам нужно установить, что такое хорошая метрика. Обычно мы количественно оцениваем их в контексте того, насколько они конкретны, измеримы и достижимы. Итак, эти три условия должны присутствовать для любого набора показателей.
Что касается показателей и показателей продукта, мы не хотим включать только разработчиков. Разработка продукта — это сочетание ролей. У вас есть сама разработка программного обеспечения. Вместе с разработчиками программного обеспечения у вас также есть дизайнеры и менеджеры по продуктам. Как правило, из трех разных типов продуктовые команды складываются кросс-функциональные. Вам нужно действительно охватить широкий спектр вещей, которые имеют значение в продукте, поэтому три набора — это три большие категории.
Как эти наборы показателей взаимосвязаны?
Адомавичус: Существуют показатели затрат на продукты и показатели доставки. Идея состоит в том, что показатели качества определяют степень устойчивости продукта. Метрики продукта смотрят на бизнес-цели и результаты, которые должен продвигать продукт. Например, если у вас есть программное обеспечение, которое используется для планирования и доставки, ваш бизнес, связанный с этим программным продуктом, должен иметь возможность планировать на любой день, изменять тенденции во времени и т. Д.
Ауримас Адомавичус
Метрики качества могут быть любыми, от мониторинга дефектов на наличие приемлемых дефектов до серьезных дефектов. Качество — это нечто большее, чем просто царапина на поверхности. Используя показатели доставки, вы оцениваете успех использования гибкой методологии доставки.
Метрики могут учитывать такие факторы, как скорость и выгорание, состояние невыполненной работы и многие другие. Когда мы смотрим на разработку программного обеспечения в целом, мы должны установить набор показателей для любого конкретного продукта или продуктовой группы.
Мы просматриваем эти три категории, а затем отслеживаем те, которые являются наиболее важными для конкретного продукта.
Является ли какая-либо из категорий более значимой для успешного внедрения программного проекта?
Адомавичус: Показатели продукта, вероятно, являются наиболее близким или хорошим вариантом. Одним из показателей продукта может быть что-то вроде одновременных пользователей в системе, активно использующих продукт с течением времени. Уровень принятия на самом деле может быть одним из показателей вашего продукта. Но нам нужно смотреть на них целостно. Нам всегда нравится смотреть на это как на систему показателей.
Очень важно иметь правильный набор показателей для продуктовой команды. Принятие должно быть частью метрической системы. Это позволит команде выполнять и наблюдать за этими показателями при разработке продукта и обдумывать наиболее полезные функции.
Вы часто говорите о роли личных предубеждений, которые могут повлиять на то, что происходит при разработке программного обеспечения. Объясните это понятие.
Адомавичус: В целом предвзято относится к каждому человеку. Когда мы думаем о продуктах, очень вероятно, что у нас есть несколько аудиторий, говорящих о том, каким будет продукт. Например, компании по разработке программного обеспечения имеют дело с пожилыми людьми, заинтересованными сторонами и руководителями. Они общаются на сессиях планирования, высказывая свое видение того, каким должен быть продукт.
Некоторые из этих взглядов основаны на анекдотических отзывах, которые собираются на переднем крае бизнеса. Некоторые из них основаны на исторической осведомленности об отрасли. Но проблема заключается в том, что, когда руководители или заинтересованные стороны приходят на помощь, но демонстрируют предвзятость, основанную на их взглядах на бизнес.
Хорошим примером может быть ситуация, когда заинтересованное лицо действительно заинтересовано в представлении о продукте, которое отражает предвзятую точку зрения, требующую особо важной функции. Внедрение аналитики продукта в программное обеспечение по мере его вывода на рынок может очень быстро оценить, насколько важна эта конкретная функция для клиентов.
В ответ вы можете предоставить предварительный просмотр функции, не обязательно разрабатывать эту функцию, а затем оценить заинтересованность клиента в использовании этой функции до того, как будет совершено вложение.
Для проверки наличия предубеждений можно использовать множество типов тестов. Или разработчики могут структурировать реализованную аналитику продукта, чтобы направлять и информировать команду об элементах, которые необходимо улучшить.
Мы используем непрерывный анализ уточнения. Этот процесс должен происходить на постоянной основе.
Консультации по программному обеспечению, которые вы предоставляете, являются частью новой тенденции?
Адомавичус: Я думаю, что исторически программное обеспечение создавалось инженерами. Это техническая область. Его создали инженеры. Часто, когда программное обеспечение выпускается, оно подвергается трению, когда программное обеспечение разрабатывается с точки зрения инженера, но не с точки зрения пользователя.
Эта отрасль начала отходить от чисто инженерной мысли. Разработка программного обеспечения в продукт могла происходить последние семь или восемь лет.
То, что происходит с тем, как создается часть программного обеспечения, связано с использованием этой метрической методологии, когда продукт находится в центре, а отзывы пользователей — в основе команды. Мы называем этот подход циклом построения, измерения и обучения.
По мере того, как подход, основанный на значимых показателях, начал набирать обороты, методология получает все большее признание в отрасли. Некоторые из крупнейших компаний мира, такие как Netflix и многие другие, используют такую методологию, ориентированную на продукт. Потребность в этих услугах резко возросла. Так что это действительно приближает технологию к нам.
Помимо пандемии, какие факторы влияют на разработку программного обеспечения сегодня, которых не было до цифровой трансформации?
Адомавичус: Такие вещи, как прогнозная аналитика и искусственный интеллект, большие данные и возможности машинного обучения — все это позволило признать необходимость изменений в разработке программного обеспечения.
Продукты, которые используются для работы корпораций, представляют собой устаревшее устаревшее программное обеспечение. Устаревшее программное обеспечение написано на языках, которые больше не поддерживают уязвимости. В результате увеличивается количество хакерских атак и нарушений безопасности.
Этот вид разработки, ориентированной на продукт, может применяться для решения многих проблем в этих организациях. Надеюсь, это позволит этим компаниям стать более компактными и выполнять больше работы. Команды могут быть намного эффективнее благодаря улучшенным технологиям. Или команды могут быстрее принимать решения с меньшим количеством ошибок и даже делать свою работу более приятной.
Работает ли эта концепция значимых показателей одинаково хорошо с разработчиками проприетарных продуктов и продуктов с открытым исходным кодом?
Адомавичус: Это не имеет особого значения, потому что открытый исходный код по сравнению с проприетарными технологиями по-прежнему остаются программные технологии. Возможно, разработчики используют разные языки или фреймворки. Эти вещи на самом деле не меняют того, почему это должно происходить или как мы решаемся и управляем этим бизнесом.
На самом деле не имеет значения, является ли интеллектуальная собственность встроенной в продукт, или лежащие в основе структуры или языки кодирования являются открытыми или нет. Если вы посмотрите на отрасль, вы увидите Java или .Net. Большинство из этих фреймворков имеют открытый исходный код. На самом деле речь идет о результатах, которые могут быть достигнуты в бизнесе. 
