![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Работа над качеством
Oct. 24th, 2024 10:26 amПоследние несколько месяцев я снова и снова возвращаюсь к мыслям про "работа над качеством".
Качество - интересная концепция, обсуждение которой, это отдельная простыня. Из того, что можно сказать кратко, есть качество случившегося, и качество неслучившегося. Качество случившегося оценить легко - количество инцидентов/огрехов за интервал. А вот качество неслучившегося очень трудно оценивать, потому что как мы оценим влияние меры по защите качества от единичных (но плохих) проблем, если эти проблемы не случились? Вот тот вот тест, который всегда зелёный, он на качество работает? А если он один раз покраснел у разработчика и тот поправил на своей машине, и никто об этом не узнал, это прирост качества?
Но пост не об этом. Пост про "работу над качеством".
Есть системный подход, когда специально выделенный человек или специально выделенное время идёт на поиск мест, где качество ниже требуемого и его исправление. Это QA (не тестировщик, а процесс - Quality Assurance).
Но есть другой подход, оппортунистический, который во-первых я сейчас практикую, а во-вторых, который может быть очень интересным направлением.
Оппортунистический подход подразумевает, что мы повышаем качество, когда видим low hanging fruit, что-то конкретное, actionable, и не требующего реформирующих изменений (которые должны приходить сверху).
Например: ввести метрику качества и устранять отклонения - это системный подход, который требует значительных инвестиций и всего лишь устраняет отклонения в пределах метрики. Расходов много (установление метрики, измерение метрики, анализ отклонений, исправления), а выхлоп - как повезёт (зависит от того, насколько точно метрика описывает инутитивное понятие "качества").
А вот другой пример: шёл мимо, заметил, что если чуть-чуть добавить, то класс проблем будет отловлен, поменял. Усилий мало. Влияние на качество? Непонятно, но явно есть, потому что класс проблем закрыт.
Или: новый процесс, обсуждение. Небольшая коррекция процесса (до его создания) и качество выше, потому что появляется простой и дешёвый в реализации/эксплуатации этап, проверяющий что-то. Качество выше, усилий мало, точный результат не понятен, потому что нет метрик и процесса оценки качества.
И интуитивно есть ощущение, что оппортунистический подход даёт большее качество (хотя менее предсказуемое), чем системный, потому что целится он в 80/20 (20% усилий за 80% результата).
В каком-то смысле, можно использовать latency как метафору. Системный подход ставит своей целью уменьшить latency через фиксированную метрику (выбранный персентиль, или даже max latency) и системные же меры (realtime), а оппортунистический подход уменьшает latency там, где можно (возможно, не влияя на max latency, но уменьшая среднее).
Переход на метрики качества и системный подход экивалентен переходу на realtime систему. Дорого и требует обоснования на уровне всего бизнеса/продукта. Он приходит сверху и является требованием.
Оппортунистический же подход применим всюду, где есть хоть какая-то добрая воля. Он приходит "снизу" и является скрытым параметром продукта, определяемым командой разработки/создателями.
В каком-то смысле, системный подход к качеству является свойством продукта, а оппортунистический подход - свойством разработчика. Системный подход добивается какого-то ожидаемого качества с любым разработчиком (в разумных пределах), а оппортунистический подход делает лучше любой продукт (внимание: не делает продукт известного качества, а для любого продукта делает его лучше: плохой продукт станет чуть менее плохим, хороший станет чуть более хорошим).
Качество - интересная концепция, обсуждение которой, это отдельная простыня. Из того, что можно сказать кратко, есть качество случившегося, и качество неслучившегося. Качество случившегося оценить легко - количество инцидентов/огрехов за интервал. А вот качество неслучившегося очень трудно оценивать, потому что как мы оценим влияние меры по защите качества от единичных (но плохих) проблем, если эти проблемы не случились? Вот тот вот тест, который всегда зелёный, он на качество работает? А если он один раз покраснел у разработчика и тот поправил на своей машине, и никто об этом не узнал, это прирост качества?
Но пост не об этом. Пост про "работу над качеством".
Есть системный подход, когда специально выделенный человек или специально выделенное время идёт на поиск мест, где качество ниже требуемого и его исправление. Это QA (не тестировщик, а процесс - Quality Assurance).
Но есть другой подход, оппортунистический, который во-первых я сейчас практикую, а во-вторых, который может быть очень интересным направлением.
Оппортунистический подход подразумевает, что мы повышаем качество, когда видим low hanging fruit, что-то конкретное, actionable, и не требующего реформирующих изменений (которые должны приходить сверху).
Например: ввести метрику качества и устранять отклонения - это системный подход, который требует значительных инвестиций и всего лишь устраняет отклонения в пределах метрики. Расходов много (установление метрики, измерение метрики, анализ отклонений, исправления), а выхлоп - как повезёт (зависит от того, насколько точно метрика описывает инутитивное понятие "качества").
А вот другой пример: шёл мимо, заметил, что если чуть-чуть добавить, то класс проблем будет отловлен, поменял. Усилий мало. Влияние на качество? Непонятно, но явно есть, потому что класс проблем закрыт.
Или: новый процесс, обсуждение. Небольшая коррекция процесса (до его создания) и качество выше, потому что появляется простой и дешёвый в реализации/эксплуатации этап, проверяющий что-то. Качество выше, усилий мало, точный результат не понятен, потому что нет метрик и процесса оценки качества.
И интуитивно есть ощущение, что оппортунистический подход даёт большее качество (хотя менее предсказуемое), чем системный, потому что целится он в 80/20 (20% усилий за 80% результата).
В каком-то смысле, можно использовать latency как метафору. Системный подход ставит своей целью уменьшить latency через фиксированную метрику (выбранный персентиль, или даже max latency) и системные же меры (realtime), а оппортунистический подход уменьшает latency там, где можно (возможно, не влияя на max latency, но уменьшая среднее).
Переход на метрики качества и системный подход экивалентен переходу на realtime систему. Дорого и требует обоснования на уровне всего бизнеса/продукта. Он приходит сверху и является требованием.
Оппортунистический же подход применим всюду, где есть хоть какая-то добрая воля. Он приходит "снизу" и является скрытым параметром продукта, определяемым командой разработки/создателями.
В каком-то смысле, системный подход к качеству является свойством продукта, а оппортунистический подход - свойством разработчика. Системный подход добивается какого-то ожидаемого качества с любым разработчиком (в разумных пределах), а оппортунистический подход делает лучше любой продукт (внимание: не делает продукт известного качества, а для любого продукта делает его лучше: плохой продукт станет чуть менее плохим, хороший станет чуть более хорошим).