Взгляд со стороны! Как аудит процесса разработки ПО меняет продукты к лучшему

Что такое аудит?

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

Взгляд со стороны! Как аудит процесса разработки ПО меняет продукты к лучшему

В конце 2018 года нас пригласили для аудита проекта всемирно известного ритейлера в сфере товаров для дома. Нам предстояло разобраться в том, как несколько подразделений компании при поддержке двух сторонних команд и представителей разработчика оригинального ПО, вместе работают над одним релизом. Да и сам продукт был интересным – внутренняя система обмена big data в сфере маркетинга. А в разработке – не только сама система сбора и анализа информации, но и рабочий веб-интерфейс, и мобильное приложение.

Цель определяет средства

Взгляд со стороны! Как аудит процесса разработки ПО меняет продукты к лучшему

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

Для этого мы разбили процесс аудита на следующие этапы:

  1. Разложить по полочкам процесс разработки и проанализировать его этапы.
  2. Определить позитивные факторы в процессе разработки.
  3. Определить неэффективные факторы в процессе разработки.
  4. Определить риски на каждом этапе, чтобы минимизировать их с помощью инструментов риск-менеджмента.
  5. Составить список ключевых регламентов и привести их к единому виду.
  6. Разработать поэтапный и эффективный процесс создания и изменения продукта.

Чтобы это реализовать, нам предстояло:

  • Ознакомиться с проектом и проанализировать его.
  • Пообщаться с основной командой разработчиков.
  • Узнать как работают смежные команды внутри компании.
  • Определить как работают подрядчики на аутсорсе.
  • Выявить конфликты и неоптимальные решения, предложить изменения и доработать их вместе с командами.
  • Создать новые регламенты и разработать дорожную карту релиза.

План есть – что делать дальше? Устоявшейся формы проведения аудита процесса разработки не существует. Для каждой компании этот процесс индивидуален, везде есть свои особенности и «подводные камни», ведь каждый бизнес обладает своей спецификой.

P.S. Если хотите понять с чего начать аудит в вашей компании,
свяжитесь с нашим мега-мозгом Дмитрием, он ответит на вопросы и поделится опытом.

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

Средства определяют метод

Взгляд со стороны! Как аудит процесса разработки ПО меняет продукты к лучшему

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

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

Теория бережливого производства, Lean + Кайдзен. Эту теорию впервые применили в компании Toyota и там же ее довели до идеала. Суть в том, что концепция управления строится на постоянном стремлении к устранению любых потерь и неэффективных процессов. Причем в этом участвует вся команда – от топ-менеджера до рядового сотрудника. Используя анализ отдельных элементов предлагаются пути их улучшения.

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

Основы риск-менеджмента. Система позволяет определить и снизить риски неудачной реализации проекта, минимизируя возможные потери.

Метрики эффективности (KPI). Четко определенные результаты работы сотрудников и команд позволяют оценивать эффективность процессов и принимать управленческие решения.

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

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

Дело в том, что методология позволяет четко определить причины и следствия, и увидеть все проблемы. Но только опыт подскажет, как их исправить. Разработка регламентов и «сборка» эффективного процесса происходит именно на основе «видения процессов со стороны» и опыта аудитора.

Опыт определяет результат

Взгляд со стороны! Как аудит процесса разработки ПО меняет продукты к лучшему

Какие основные сложности процесса разработки мы выявили?

Основные проблемы выглядят так:

  1. Отсутствие единого центра – у некоторых процессов не хватает руководителя, который бы курировал их и коммуницировал с командами.
  2. Общий недостаток коммуникации – команды используют разные глоссарии, недостаточно общаются друг с другом и неэффективно делятся информацией о продукте.
  3. Нехватка критериев для оценки – отсутствие понятных и эффективных метрик не дает принимать управленческие решения и оценивать процесс.

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

Какие эффективные решения мы предложили заказчику аудита?

  1. В структуре проекта появились новые должности – эти специалисты закрыли пробелы в управлении ключевыми процессами, в которых ранее ответственного не было.
  2. Большое количество решений коснулось эффективности коммуникации – появились новые регламенты взаимодействия, проведения встреч, создания ТЗ, тестирования, показов, деплоя.
  3. Предложены новые эффективные метрики для оценки работы сотрудников и результатов команд – принимать управленческие решения стало проще, благодаря четкой аналитике.

Процесс внедрения изменений по результатам аудита еще идет, но первый фидбек от заказчика нас обнадежил: «С появлением ежедневных отчетов статус работ стал прозрачным». Хорошее начало – уже полдела.

Результаты формируют новый опыт

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

  1. Взгляд со стороны – это важно. Аудит – это серьезный и масштабный процесс, но не пренебрегайте и обычной оценкой специалистов, незаинтересованных в ваших успехах или в вашей похвале. Хотя и не берите такое мнение на веру. Всегда нужно находить баланс между свежим взглядом со стороны и компетентностью.
  2. Коммуникация – ключ к успеху в любых ситуациях, начиная от личных отношений и заканчивая сложными бизнес-процессами. Тот же Элия Голдратт в книгах по теории ограничений очень доходчиво описывает ситуации, когда огромные заводы простаивают только потому, что два специалиста не поговорили друг с другом. Хотя и перебарщивать тоже нельзя, чтобы не уподобляться героям стихотворения Маяковского «Прозаседавшиеся».
  3. Четкие параметры сравнения упрощают работу. Принимать решения проще, когда вы сравниваете одни и те же показатели или оцениваете сотрудников по одинаковым параметрам. Руководитель не должен вникать в детали каждого процесса, поэтому для принятия решений ему нужны данные, которые можно оценивать.

Вот такие у нас будни в сфере аудита процессов тестирования и разработки. Хотите узнать, какой эффект будет от аудита вашего проекта?

А на этом пока все. До встречи в блоге «Лаборатории качества».

Другие статьи