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

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

Мой «сад камней»

Камень 1. Ошибка в мышлении

Как, наверное, большинство специалистов, начинающих свой путь к совершенному продукту, а точнее, к обеспечению его качества, я загорелся идеей сделать все хорошо и сразу! Мои мысли были примерно такими: «За все хорошее против всего плохого», «Кто не хочет сделать качественный продукт», «Фокус на конечном результате».

Спустя некоторое время работы я пришел к следующим выводам:

1. необходимо понять, какие требования по качеству продукта актуальны сейчас, а какие станут такими в перспективе;

2. процесс достижения абсолютно совершенного продукта бесконечен;

3. фокус должен быть на потоке создания ценности.

Какие практики я начал использовать в своей работе и в работе моей команды?

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

   1. Отсутствие критичных и блокирующих дефектов для работы в продуктовой среде. Все очень просто: неработающий продукт или недоступная часть работающего функционала никому не нужны;

   2. Мера качества – цена несоответствия. Необходимо всегда соответствовать требованиям и ожиданиям заказчика, и конечного пользователя;

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

   4. В продукте всегда будут дефекты – так называемый «допустимый брак».

      Все неисправности в продукте обнаружить невозможно, всегда будут всплывать уникальные сценарии использования, дефекты подверженные эффекту «пестицида», ошибки, пропущенные в ходе проверки в том числе из-за человеческого фактора, а также банальное нестандартное использование продукта;

2. Продукт не совершенен и прекрасен одновременно! Не стоит ожидать от MVP-версии, что она будет «шедевром», как и нет смысла затягивать выпуск продукта в раннем состоянии. В полной версии также всегда найдется, что сделать лучше (бесконечное совершенствование);

3. Фокус на создании ценности:

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

Камень 2. «Шум»

Создавая продукт, меня иногда «заносило» - хотелось попробовать разные подходы тестирования, методы разработки, собирать разные метрики, гибкие методологии. Естественно, некоторые предложения не находили отклика внутри команды и демотивировало как меня, так и моих коллег. Помимо эмоциональной составляющей, что, конечно же, немаловажно, некоторые активности (процессы) вели к увеличению времени доставки разрабатываемого функционала на продуктовую среду, а это тоже очень важно.

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

К чему привели улучшения командной работы?

1. Определили, по каким параметрам можно говорить о состоянии продукта в текущий момент:

   1. Благодаря мониторингу можно быстро выяснить состояние системы в режиме онлайн. Не стоит недооценивать «великую силу дашбордов» в процессе обеспечения качества. Правильно настроенный мониторинг упрощает разбор дефектов, а особенно, аварийных ситуаций. Как, например, в работе экипажа самолета: капитан, анализируя показания приборов, понимает текущее положение, видит, закончился ли набор высоты и можно ли предложить пассажирам кофе.

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

2. Обсудили подход к активностям в работе с командой, выделили среди них отвлекающие. Прежде всего необходимо избавиться от методов контроля внутри команды, связанных с отсутствием у контролирующего компетенций в профессиональной области коллег. Такого рода активности являются демотивирующими и в большинстве случаев ведут к излишней бюрократии. Это не исключает использование метрик, таких как «покрытие кода тестами» или «качество кода» для оценки продукта при отсутствии навыка в разработке у части команды. Если такого рода метрики необходимы команде для понимания состояния продукта в целом, то их, конечно, нужно использовать. Развитие навыка в смежных областях (Т-образный навык) и «размытие» компетенций внутри команды скажется на результате гораздо продуктивнее, нежели инспекции. Еще хочется обратить внимание на излишнюю формализацию процесса: от таких элементов стоит избавляться, если они мешают работе.

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

Камень 3. Опыт

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

К каким изменениям привели мои выводы?

1. Изменился подход к тестированию: случился переход от демонстрации отсутствия наличия дефектов (не отменяя сей принцип) к ускорению способа доставки ценности до конечного пользователя. Например, любимый специалистами по тестированию регрессионный вид тестирования на финальном этапе разработки функционала увеличивает время доставки ценности и в большинстве случаев не требуется. Это не единственный вид теста, связанного с изменениями. Исходя из конкретных условий можно (и даже желательно!) использовать подходящие инструменты и практики, которые сработают быстрее и точнее.

2. Оказалось, что нужно перестать быть тестировщиком. Современные реалии диктуют нам условия, при которых шаблонное поведение и узконаправленное мышление мешают создавать, развивать и совершенствовать продукт, себя и мир вокруг (да-да, мне кажется, что, создавая какой-либо продукт, мы меняем мир вокруг себя). Продолжая оставаться в рамках своих компетенций, мы формируем туннельный взгляд на создаваемый продукт. Например, разработчик может воспринимать продукт как строки кода, классы и методы, тогда как для специалиста по тестированию это монотонные тестовые прогоны и заведенные дефекты. Развивая навык в смежных областях, расширяется горизонт обзора, начинаем «видеть лес за деревьями». Необходимо развиваться и в других направлениях, чтобы стать более универсальным специалистом (Т-образный навык).

3. Стали использовать цикл Шухарта-Деминга (Plan-Do-Check-Act). Это самый простой (а все гениальное просто!) способ начать изменяться и совершенствоваться.

Как он работает? Предположим, что вы решили внедрить что-то новое (фреймворк, изменение в процессе и т.д.) для себя и/или для команды. Для реализации своей задумки попробуйте действовать по следующему алгоритму:

• P (Планируй) - спланируйте какие шаги необходимо делать чтоб достигнуть цели, установите временные рамки;

• D (Выполняй) – выполните намеченные шаги;

• С (Проверяй) – проконтролируйте исполнение шагов, соберите обратную связь;

• A (Действуй) – подведите итог. Используем в работе как практику или корректируем, а может, признаем идею как не состоявшуюся.

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

В заключение

Итоги подводить еще рано! Так как я все еще на пути к совершенству – развиваюсь сам, помогаю развиваться своей команде. А вместе с нашим ростом растет и продукт, над которым мы работаем.

В качестве заключения я хочу оставить философский вопрос: «Что вы хотите оставить после себя в компании: руины, кучу камней или прекрасный сад?».