Есть такой фразеологизм -  «бросать камень в огород (чей-то)», пытаясь создать продукт, полностью удовлетворяющий потребности наших пользователей, я совершил множество ошибок.  Я Скороспелов Денис, человек, обеспечивающий качество продукта в одной из команд компании ВСК, и в свое время я наловил много камней и получил бесценный опыт. Почему бы из них не составить прекрасный сад и не поделиться им, рассказав о своем опыте работы над обеспечением качества продукта? Как, наверное, большинство специалистов, начинающих свой путь к совершенному продукту, а точнее, к обеспечению его качества, я загорелся идеей сделать все хорошо и сразу! Мои мысли были примерно такими: «За все хорошее против всего плохого», «Кто не хочет сделать качественный продукт», «Фокус на конечном результате». Спустя некоторое время работы я пришел к следующим выводам: необходимо понять, какие требования по качеству продукта актуальны сейчас, а какие станут такими в перспективе; процесс достижения абсолютно совершенного продукта бесконечен; фокус должен быть на потоке создания ценности. Какие практики я начал использовать в своей работе и в работе моей команды? У меня получилось определить необходимый минимальный, обязательный и понятный для всех набор критериев, позволяющий говорить о качественном состоянии разрабатываемого продукта: Отсутствие критичных и блокирующих дефектов для работы в продуктовой среде. Все очень просто: неработающий продукт или недоступная часть работающего функционала никому не нужны; Мера качества – цена несоответствия. Необходимо всегда соответствовать требованиям и ожиданиям заказчика и конечного пользователя; Предотвращение ошибок важнее, чем их оценка. Чем раньше обнаружен дефект, тем ниже цена его исправления и последствий. Любой обнаруженный дефект необходимо будет рано или поздно исправить, даже самый тривиальный; В продукте всегда будут дефекты – так называемый «допустимый брак». Все неисправности в продукте обнаружить невозможно, всегда будут всплывать уникальные сценарии использования, дефекты подверженные эффекту «пестицида», ошибки, пропущенные в ходе проверки в том числе из-за человеческого фактора, а также банальное нестандартное использование продукта; Продукт не совершенен и прекрасен одновременно! Не стоит ожидать от MVP-версии, что она будет «шедевром», как и нет смысла затягивать выпуск продукта в раннем состоянии. В полной версии также всегда найдется, что сделать лучше (бесконечное совершенствование); Фокус на создании ценности: Мы начали практиковать конвейерный подход к задачам: придумали – сделали – проверили – доставили. На этапе тестирования теперь проверяем задачи, а не продукт целиком, а также понимаем: чем быстрее весь процесс работает, тем быстрее он будет доставлен до продуктовой среды, и тем довольнее будет конечные пользователи. Создавая продукт, меня иногда «заносило» - хотелось попробовать разные подходы тестирования, методы разработки, собирать разные метрики, гибкие методологии. Естественно, некоторые предложения не находили отклика внутри команды и демотивировало как меня, так и моих коллег. Помимо эмоциональной составляющей, что, конечно же, немаловажно, некоторые активности (процессы) вели к увеличению времени доставки разрабатываемого функционала на продуктовую среду, а это тоже очень важно. Получив опыт, я понял и принял, что некоторые техники и практики неприменимы для моей команды в связи с разными обстоятельствами, инспекции не повышают качество и не гарантируют его, а также то, что обратная связь просто необходима! К чему привели улучшения командной работы? Определили, по каким параметрам можно говорить о состоянии продукта в текущий момент: Благодаря мониторингу можно быстро выяснить состояние системы в режиме онлайн. Не стоит недооценивать «великую силу дашбордов» в процессе обеспечения качества. Правильно настроенный мониторинг упрощает разбор дефектов, а особенно, аварийных ситуаций. Как, например, в работе экипажа самолета: капитан, анализируя показания приборов, понимает текущее положение, видит, закончился ли набор высоты и можно ли предложить пассажирам кофе. Как следствие предыдущего пункта, с помощью мониторинга теперь есть возможность узнать, что пользователи делают в конкретный момент (особенно в режиме онлайн), поэтому больше нет необходимости собирать обратную связь на постоянной основе с помощью опросника или другими средствами. Естественно, мнение конечного пользователя всегда важно и должно иметь высокий приоритет при принятии решения о изменении. Обсудили подход к активностям в работе с командой, выделили среди них отвлекающие. Прежде всего необходимо избавиться от методов контроля внутри команды, связанных с отсутствием у контролирующего компетенций в профессиональной области коллег. Такого рода активности являются демотивирующими и в большинстве случаев ведут к излишней бюрократии. Это не исключает использование метрик, таких как «покрытие кода тестами» или «качество кода» для оценки продукта при отсутствии навыка в разработке у части команды. Если такого рода метрики необходимы команде для понимания состояния продукта в целом, то их, конечно, нужно использовать. Развитие навыка в смежных областях (Т-образный навык) и «размытие» компетенций внутри команды скажется на результате гораздо продуктивнее, нежели инспекции. Еще хочется обратить внимание на излишнюю формализацию процесса: от таких элементов стоит избавляться, если они мешают работе. Постарались сделать работу внутри команды максимально прозрачной и открытой. Например, у каждого члена команды есть доступ к статусу прохождения тестирования, тестовым сценариям, репозиторию. Это позволяет отследить, что изменилось в коде, или банально развернуть локально проект. Договорились в команде о правилах заведения дефектов, написания тестовых сценариев и закрытии задач. Все вышеперечисленное гарантирует получение обратной связи не только от конечного пользователя, но и на всех аспектах жизненного цикла программного обеспечения, а также ускоряет доставку до конечного пользователя. Препятствия, вытекающие при столкновении с предыдущими «камнями», – применение чужих практик как стандартов и формирование шаблонного поведения. Я старался применить весь свой прошлый опыт с других мест работы, из прочитанных книг и дополнительного обучения в команду, которая так работать не привыкла. И вскоре отметил для себя, что осознанная практика – это не то же самое, что реальный опыт, а известные стандарты, навыки, привычки с точки зрения IT-специалистов в команде необходимо актуализировать, менять, добавлять, а порой и просто убирать как несостоявшиеся. К каким изменениям привели мои выводы? Изменился подход к тестированию: случился переход от демонстрации отсутствия наличия дефектов (не отменяя сей принцип) к ускорению способа доставки ценности до конечного пользователя. Например, любимый специалистами по тестированию регрессионный вид тестирования на финальном этапе разработки функционала увеличивает время доставки ценности и в большинстве случаев не требуется. Это не единственный вид теста, связанного с изменениями. Исходя из конкретных условий можно (и даже желательно!) использовать подходящие инструменты и практики, которые сработают быстрее и точнее. Оказалось, что нужно перестать быть тестировщиком. Современные реалии диктуют нам условия, при которых шаблонное поведение и узконаправленное мышление мешают создавать, развивать и совершенствовать продукт, себя и мир вокруг (да-да, мне кажется, что, создавая какой-либо продукт, мы меняем мир вокруг себя). Продолжая оставаться в рамках своих компетенций, мы формируем туннельный взгляд на создаваемый продукт. Например, разработчик может воспринимать продукт как строки кода, классы и методы, тогда как для специалиста по тестированию это монотонные тестовые прогоны и заведенные дефекты. Развивая навык в смежных областях, расширяется горизонт обзора, начинаем «видеть лес за деревьями». Необходимо развиваться и в других направлениях, чтобы стать более универсальным специалистом (Т-образный навык). Стали использовать цикл Шухарта-Деминга (Plan-Do-Check-Act). Это самый простой (а все гениальное просто!) способ начать изменяться и совершенствоваться. Как он работает? Предположим, что вы решили внедрить что-то новое (фреймворк, изменение в процессе и т.д.) для себя и/или для команды. Для реализации своей задумки попробуйте действовать по следующему алгоритму: P (Планируй) - спланируйте какие шаги необходимо делать чтобы достигнуть цели, установите временные рамки; D (Выполняй) – выполните намеченные шаги; С (Проверяй) – проконтролируйте исполнение шагов, соберите обратную связь; A (Действуй) – подведите итог. Используем в работе как практику или корректируем, а может, признаем идею как не состоявшуюся. Стоит помнить, что отрицательный результат - тоже результат, не следует боятся такой ситуации, будьте честны при подведении итогов. Достаточно регулярно проводить анализ проделанной работы и выполненного проекта и отмечать возможные зоны роста. Итоги подводить еще рано! Так как я все еще на пути к совершенству – развиваюсь сам, помогаю развиваться своей команде. А вместе с нашим ростом растет и продукт, над которым мы работаем. В качестве заключения я хочу оставить философский вопрос: «Что вы хотите оставить после себя в компании: руины, кучу камней или прекрасный сад?».