Разработка показателей качества программного обеспечения в качестве специалиста по обработке и анализу данных: 5 извлеченных уроков

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

1. Данные в программном обеспечении не являются нормальными

1. Метрики качества программного обеспечения должны измерять каждый шаг

1. Статистика отличная, но...

1. Поделитесь своей работой

1. Думайте обо всех пользователях

1 Данные в программном обеспечении не являются нормальными

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

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

Однако данные в программном обеспечении, как правило, имеют более длинные хвосты с правой стороны. Рассмотрим пример сообщения. Большинство сообщений доставляются получателю менее чем за 1 секунду. Тем не менее, некоторые из них могут занять больше времени, а конкретное время может варьироваться от 2 секунд до 24 часов. Такие данные могут следовать распределению Парето (отличному от правила 80/20, хорошо известный в приложениях для контроля качества.

Можем ли мы использовать этот факт при разработке метрик качества программного обеспечения?

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

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

:::Информация

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

Я бы порекомендовал это видео для разъяснения:

https://www.youtube.com/watch?v=IFKQLDmRK0Y

2 Метрики качества программного обеспечения должны измерять каждый шаг

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

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

3 Статистика — это здорово, но…

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

Когда я начал разрабатывать метрики качества программного обеспечения во время стажировки, я пытался найти способы измерения качества программного обеспечения, которые были бы вычислительно эффективными, но при этом точными. Я ничего не мог поделать.

Затем я показал это своему коллеге, и пока я объяснял, как это будет работать, он остановил меня и попросил подумать, сколько времени потребуется, чтобы объяснить, что это такое. Я должен был спросить себя, лучше ли мое предложение более стандартных подходов во всех аспектах? Мне было очень весело пытаться разработать что-то новое. Однако затем был коммуникативный аспект. Будет ли это иметь смысл для высшего руководства?

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

Если кто-то попросит вас написать портрет, он не будет ожидать картину Пикассо.

4 Поделитесь своей работой в процессе

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

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

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

5 Подумайте обо всех пользователях

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

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

Метрики качества программного обеспечения и наука о данных

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

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

Если вы обнаружите, что разрабатываете метрики качества программного обеспечения, я также рекомендую прочитать о SixSigma [критическом для качества] (https://www.6sigma.us/six-sigma-articles/critical-quality-six-sigma-dna/) подход.

Удачи!