- Что такое качество в разработке ПО?
- Во сколько нам обходится некачественное ПО?
- Кто отвечает за качество?
Для меня поводом задаться этими вопросами стала встреча с компанией в которой 3 месяца в году всё подразделение разработки (около сотни человек), занято устранением ошибок и дефектов, а остальные 9 месяцев они пишут ошибки софт для Заказчиков.
Ниже результаты моих теоретических и практических исследований в поисках ответов. Постарался изложить их просто, без «мозговзрыва» присущего этой теме.
Что такое качество в разработке ПО?
На вопрос что такое качество в разработке ПО можно ответить с разных точек зрения. Свои ответы буду формулировать с точки зрения Пользователя-Заказчика и Руководителя компании. 
С позиции Пользователя высокое качество ПО — это полное отсутствие ошибок и решение им задачи ради которого оно создавалось.
Минимальный уровень качества — это решение бизнес-задачи и отсутствие в ПО ошибок, которые блокируют возможность его использования (Блокирующие ошибки).
Средний уровень качества — всё что выше + отсутствие ошибок, которые существенно влияют на опыт использования ПО (Обязательные к устранению), при этом присутствуют ошибки, которые никак не влияют на решение бизнес-задачи: орфография, разные шрифты там где должен быть один и т.д. (Желательные к устранению).
Ошибки, которые найдены пользователями в ходе эксплуатации буду называть Дефектами. Ошибками же будут считать то, что было найдено сотрудниками, вовлеченными в выпуск версии ПО, до передачи его в эксплуатацию Пользователям.
Во сколько обходится нам некачественное ПО?
Часть 1: Подтверждение Дефекта
Когда Пользователь находит дефект он обращается к инженеру службы поддержки. Инженер СП пытается его воспроизвести и подтвердить что это дефект производства. Здесь возникают первые затраты из которых начинается складываться стоимость качества:
- Затраты времени Пользователя — 1 ед.
- Затраты времени Инженера СП — 1 ед.
Если ошибка системная, то всё очевидно, а если она связана с работой функционала по определенной логике?
Здесь инженеру СП потребуется документация, которая описывает каким должен быть эталонный ответ системы при выполнении ею конкретного запроса пользователя. Если этой документации нет, то требуются дополнительные затраты на выяснение дефект ли это или же новое требование.
Отсутствие документации особенно часто встречается когда практикуется быстрая разработка. Все помнят о «Работающий продукт важнее исчерпывающей документации», но забывают про то что ниже написано «То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева».
Инженер СП начинает прикладывать дополнительные усилия на то, чтобы выяснить правду. К расследованию подключаются Владелец Продукта (если он есть) или Инженер-Разработчик, который делал эту функцию или знает этот функциональный модуль. Один из них или оба пытаются вспомнить или определить Заказчика, для которого это сделано.
Пользователь системы не всегда является тем Заказчиком, который формулировал требование к работе системы. То что для Пользователя ненормально для Заказчика может быть нормой.
Вместе с Заказчиком они обсуждают ситуацию и пытаются определить штатно или нештатно отработала система. Если у Заказчика амнезия, а такое бывает, если работу заказал месяца 3 назад (длинный бэклог с работой на полгода вперед), а сделали эту фичу/функцию только сейчас, они пытаются найти какой-то документ или письмо, на основании которого делалась разработка.
Если им повезло найти ответ на свой вопрос, то всё заканчивается следующими затратами:
- Владельца Продукта — 1 ед.
- Инженер-Разработчик — 1 ед.
- Заказчик — 1 ед.
- Затраты времени Инженера СП — 1 ед.
Если не повезло, то их ожидает торг по поводу того считать ли это дефектом, который будет устраняться за собственный счёт, или новым требованием, которое будет оплачивать Заказчик. Допустим, что сторговаться не удалось, Заказчик продавил, считаем это дефектом и устраняем за собственный счёт.
- Ухудшение репутации — 1 ед. (за счёт того, что Дефект и что пришлось привлечь Заказчика к расследованию)
- Пока затраты на устранение дефекта здесь не учитываю, так как они добавятся чуть позже.
Промежуточный итог:
- Затраты времени Пользователя — 1 ед.
- Затраты времени Инженера СП — 2 ед.
- Затраты времени Владельца Продукта — 1 ед.
- Затраты времени Инженера-Разработчика — 1 ед.
- Затраты времени Заказчика — 1 ед.
- Ухудшение репутации — 1 ед.
Стоимость качества — 7 единиц
Можно оптимизировать затраты в этой части заранее потратившись на подготовку пользовательской документации Тех.Писателем-Аналитиком, тогда это будет выглядеть вот так:
- Затраты времени Пользователя — 1 ед.
- Затраты времени Инженера СП — 1 ед.
- Затраты времени Тех.Писателя-Аналитика — 1 ед.
- Ухудшение репутации — 0,5 ед. (Потому что Дефект)
Стоимость качества — 3,5 единицы
Чтобы понять момент, когда Тех.Писатель-Аналитик нужен, нужно начать вести учёт ситуаций, когда для расследования привлекались дополнительные лица помимо Инженера СП и сколько времени они на это потратили, сколько таких спорных ситуаций превратилось в Дефекты и во сколько обошлось их устранение. Когда сумма этих затрат становится больше зарплаты Тех.Писателя самое время его вводить.
Часть №2: Устранение Дефектов
Каждая «Блокирующая ошибка» порождает выпуск отдельного устраняющего патча-обновления. Это обновление проходит через стандартные процедуры тестирования, дабы не породить новых ошибок. Передаётся Инженеру СП для распространения среди Клиентов, которые пользуются версией ПО, в которой была найдена эта ошибка, и закрытия «тикета» дефекта. Затраты:
- Инженер-Разработчик — 1 ед.
- Инженер-Тестировщик — 1 ед.
- Инженер СП — 1 ед.
«Обязательная к устранению ошибка» устраняется в следующим плановом релизе (версии), поэтому затраты на устранение ниже, так как затраты на сборку релиза и регрессионное тестирование ложатся на новые функции и не попадают в стоимость устранения ошибки. Дополнительных затрат на работу Инженера СП также нет кроме закрытия «тикета». Затраты:
- Инженер-Разработчик — 0,5 ед.
- Инженер-Тестировщик — 0,5 ед.
Затраты в обоих случаях оплачиваются из прибыли компании.
Стоимость качества — 4 единицы.
Часть №3: Недопущение Дефектов (Качество основанное на контроле)
Чтобы Пользователи не находили Дефекты для этого есть собственные Инженеры по тестированию. Для них критерий эффективности 100% ошибок — 0% дефектов.
Информация о найденном дефекте передается Инженеру по тестированию для анализа причин пропуска дефекта при тестировании и внесения изменений в методики и инструменты тестирования. Затраты:
- Инженера-Тестировщик — 1 ед.
Эффективная работа здесь сводит на нет следующие затраты времени
Части 1:
- Пользователя — 1 ед.
- Инженера СП — 1 ед.
- Ухудшение репутации — 0,5 ед.
Части 2:
- Инженер-Разработчика — 1,5 ед.
- Инженер-Тестировщика — 1,5 ед.
- Инженер СП — 1 ед.
Стоимость — 6,5 ед. Вложения — 1 ед. Экономия — 5,5 единиц.
Часть №4: Устранение Ошибок
Каждая найденная самостоятельно ошибка, не стоит компании ничего, так как затраты на устранение попадают в конечную стоимость для Клиента.
Но устранение ошибок увеличивает себестоимость продукта и сроки выполнения работ, если Разработка делает много и тяжелых ошибок, а также приходится выполнять более 2-х итераций тестирования и устранения ошибок. Всё это не нравится Клиенту и, особенно, если ему есть с чем сравнивать.
Если разработка ведётся для собственных нужд, то большое количество ошибок ухудшает экономику возврата вложений в Разработку и сужает возможность выпуска большего количества полезных функций (фич) в единицу времени, что сказывается уже негативным образом на экономике всего бизнеса компании.
Затраты здесь:
- Ухудшение репутации — 1 ед.
- Инженер-Разработчик — 1 ед.
- Инженер-Тестировщик — 1 ед.
- Потерянный доход — 2 ед. (п.2 + п.3)
Стоимость качества — 5 единиц.
Часть №5: Недопущение Ошибок (Качество основанное на развитии производственного процесса)
Качество продукта нужно не только и не столько контролировать, сколько предотвращать причины, которые на прямую влияют на появление ошибок.
Допущенные ошибки передаются на анализ Руководителю Разработки (Тим-Лиду) для выявления причин, сотрудников, которые их чаще допускают, и чаще «болеющих» продуктов. Эта работа выливается в ряд мероприятий по код-ревью, дополнительному обучению Инженеров-Разработчиков по темам где недостаёт квалификации и т.д.
- Затраты Руководителя-Разработки — 1 ед.
- Затраты Инженера-Разработчика — 1 ед.
Эффективная работа здесь сводит на нет следующие затраты Части 4:
- Инженер-Разработчик — 1 ед.
- Инженер-Тестировщик — 1 ед.
- Потерянный доход — 2 ед.
- Ухудшение репутации — 1 ед.
Стоимость — 5 ед. Вложения — 2 ед. Экономия — 3 единицы.
Общий расчёт стоимости качества
Обычно ситуация выглядит так: Мы ведем разработку, допускаем ошибки, порой их устранение требует более двух итераций и несмотря на эту работу Пользователи всё равно находят дефекты в ПО, которые нам приходится исправлять путем выпуска дополнительных обновлений.
| Вид затрат | Часть 1 | Часть 2 | Часть 4 | Итого |
|---|---|---|---|---|
| Затраты времени Пользователя | 1 | - | - | 1 |
| Затраты времени Инженера СП | 2 | 1 | - | 3 |
| Затраты времени Владельца Продукта | 1 | - | - | 1 |
| Затраты времени Инженера-Разработчика | 1 | 1,5 | 1 | 3,5 |
| Затраты времени Заказчика | 1 | - | - | 1 |
| Затраты времени Инженера-Тестировщика | - | 1,5 | 1 | 2,5 |
| Ухудшение репутации | 1 | - | 1 | 2 |
| Потерянный доход | - | - | 2 | 2 |
| Итого | 7 | 4 | 5 | 16 |
Если будем готовить документацию по факту выполненной разработки, вложив 1 единицу ресурса Технического Писателя, то это сэкономит 3,5 единицы и стоимость качества снизится с 16 до 12,5. (Структура затрат: Документирование + Подтверждение Дефекта + Устранение Дефекта + Устранение Ошибок)
Обеспечив недопущение дефектов, вложив в это дополнительные затраты времени Инженера-Тестировщика в размере 1 единицы, стоимость качества снизится с 12,5 до 7 единиц. (Структура затрат: Документирование + Недопущение Дефектов + Устранение Ошибок)
Недопущение ошибок потребует вложения 2 единиц, по одной от Инженера-Разработчика и Руководителя-Разработки, и снизит стоимость качества с 7 до 4 единиц. (Структура затрат: Документирование + Недопущение Дефектов + Недопущение ошибок)
Если вложимся в то, что Технический Писатель — Аналитик начнёт писать пользовательскую документацию про то как система должна решать бизнес-задачу Пользователя ещё до разработки, то, возможно, не придется:
- Не только спорить с Заказчиком дефект это или нет, но и вообще общаться с ним по поводу дефектов.
- Анализировать причины по которым ошибки в выполнении целевых задач ПО проскочили к Пользователям через этап Тестирования.
- Анализировать причины по которым Разработчик сделал так, что программа работает не так как должна и отдал это в Тестирование.
- Тратится на дополнительные мероприятия по недопущению ошибок и дефектов, когда проектная документация отсутствует и нужно что-то придумывать чтобы компенсировать её отсутствие.
И на это нужна всего 1 единица затрат. (Качество основанное на развитии процесса проектирования продукта)
Кто отвечает за качество?
В западных компаниях есть такая позиция Quality Assurance Engineer, который отвечает за весь процесс выпуска программного обеспечения и фокусируется на аспекте обеспечения качества.
У нас Software Quality Assurance (Обеспечение качества ПО) утрировано до восприятия как Тестирование, а Quality Assurance Engineer до Инженер-Тестировщик. Но Инженер-Тестировщик максимум что может сделать это найти все ошибки и вернуть их Software Ingineer (Инженеру-Разработчику), но он никак не влияет на их появление.
Ребята в разработке могут не допускать ошибок, но они не роботы, это творческий процесс когда нужно придумать то, чего не было раньше и негде подсмотреть как это можно сделать.
Это также порой осложняется тем, что в качестве входной информации к ним приходит невнятная постановка, причина которой лежит либо в том, что Заказчик не понимает чего хочет и кто-то пропустил это требование до Разработки, либо Заказчик знает чего хочет, но сработал «сломанный телефон» и до Разработки часть требований не дошла.
Team Lead (Руководитель Разработки) может помочь Инженеру-Разработчику научится делать свою работу хорошо и освоить недостающие компетенции и технологии, но он точно не должен быть Внутренним Тестировщиком команды разработки и проверять за каждым, чтобы не пропустить на следующий этап дефектный код. Его задача учить и строить процессы внутри команды, чтобы дефектного кода не было.
Есть ещё Product Owner (Владелец Продукта), который как владелец подходит на роль Отвечающего за Качество Продукта. По этой причине их порой делят на две позиции Marketing Product Manager (Менеджер по продукту) и Software Delivery Manager (Менеджер по выпуску ПО). Первый отвечает за развитие продукта с точки зрения рынка (работа с Заказчиками и требованиями), а второй за развитие производственного процесса выпуска продукта.
Если пристально присмотреться ко всем в списке, то видно что никто из них персонально не производит «Качество». Качество это не компонент программы, который к нему можно добавить. При этом все они участвуют в создании Продукта, который решает бизнес-задачу пользователя и не содержит ошибок. Качество — это командная работа.
Поделить ответственность по этапам Software Development Life Cycle (Жизненного цикла разработки ПО) не получается. Как только это деление начинается, неэффективная работа по середине сразу делает бессмысленной работу сделанную в начале и нагружает дополнительной работой как тех кто стоит в конце, так и всю производственную цепочку заводя на её вход ошибку для устранения.
Заключение
Это классический подход к работе с качеством из промышленности, который основан на трёх методах:
- Качество через проверку готового продукта (тестирование: отлавливание ошибок и дефектов)
- Качество через развитие производственного процесса (предотвращение ошибок в ходе производства)
- Качество через развитие процесса проектирования продукта (предотвращение ошибок закладываемых в скелет-основу продукта при проектировании)
И основным посылом: необходимо больше внимания уделять работе с причинами, а не работе с последствиями.
Он отлично подходит для разработки продуктов работу которых можно спроектировать от и до. И не подходит когда времени проектировать работу продукта нет и определение как он должен работать происходит через итеративный выпуск работающих версий (эмпирически).
В начале быстрой итеративной разработки есть единственный критерий качества — это выполнение продуктом бизнес-задачи ради которой он создается. С каждой итерацией Заказчик добавляет новые критерии качества (ожидания от продукта), которые улучшают его опыт использования продукта для решения бизнес-задачи.
С применением быстрых фреймворков Agile, количество ошибок и дефектов в единицу времени увеличивается пропорционально количеству релизов. Чем больше делаем и выпускаем, тем больше ошибок производим. Чем больше ошибок производим, тем больший процент загрузки команды связан с исправлением допущенных ошибок и переделке сделанного.
Это плата за то, что самолет достраиваем уже в полете, не имея представления о том, как он должен выглядеть в законченном виде и реагировать на условия внешней среды.
Что с этим делать? — мне нравятся ответы данные в статье «Будущее гибкой разработки».
Что ещё почитать по теме:
- Будущее гибкой разработки
- Что такое качество программного обеспечения?
- Управление качеством проекта
- Карьера в IT: должность QA engineer
- Гуру менеджмента качества и их концепции: Э.Деминг, Дж.Джуран, Ф.Кросби, К.Исикава, А.Фейгенбаум, Т.Тагути
Уделите пару минут ответу на три вопроса, так вы поможете провести диагностику средней температуры отношения и внимания к качеству ПО в ИТ-отрасли нашей страны на 1 августа 2017 года. +1 вам в карму за это доброе дело.
Автор: Максим Евстратов
