Работа над качеством
Oct. 24th, 2024 10:26 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
amaraoПоследние несколько месяцев я снова и снова возвращаюсь к мыслям про "работа над качеством".
Качество - интересная концепция, обсуждение которой, это отдельная простыня. Из того, что можно сказать кратко, есть качество случившегося, и качество неслучившегося. Качество случившегося оценить легко - количество инцидентов/огрехов за интервал. А вот качество неслучившегося очень трудно оценивать, потому что как мы оценим влияние меры по защите качества от единичных (но плохих) проблем, если эти проблемы не случились? Вот тот вот тест, который всегда зелёный, он на качество работает? А если он один раз покраснел у разработчика и тот поправил на своей машине, и никто об этом не узнал, это прирост качества?
Но пост не об этом. Пост про "работу над качеством".
Есть системный подход, когда специально выделенный человек или специально выделенное время идёт на поиск мест, где качество ниже требуемого и его исправление. Это 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 систему. Дорого и требует обоснования на уровне всего бизнеса/продукта. Он приходит сверху и является требованием.
Оппортунистический же подход применим всюду, где есть хоть какая-то добрая воля. Он приходит "снизу" и является скрытым параметром продукта, определяемым командой разработки/создателями.
В каком-то смысле, системный подход к качеству является свойством продукта, а оппортунистический подход - свойством разработчика. Системный подход добивается какого-то ожидаемого качества с любым разработчиком (в разумных пределах), а оппортунистический подход делает лучше любой продукт (внимание: не делает продукт известного качества, а для любого продукта делает его лучше: плохой продукт станет чуть менее плохим, хороший станет чуть более хорошим).
no subject
Date: 2024-10-24 07:31 am (UTC)no subject
Date: 2024-10-24 09:55 am (UTC)no subject
Date: 2024-10-24 07:38 am (UTC)Первій же МВА зарубит оппортунистический подход, потому что в мире менеджмента продукт (со всеми его свойствами, включая качество) должен біть независим от персонала и его доброй воли.
no subject
Date: 2024-10-24 09:59 am (UTC)Оппортунистическое качество возникает в моменты возможностей. Чтобы отнять эти возможности нужно отнять возможность менять продукт.
Например, человек пишет функцию. Он может подумать про инвариант, а может написать минимум, который записан в ТЗ.
Человек, когда пишет тест, может разобрать тест на инварианты и написать три теста на три разных инварианта, а может написать bdd-стиль, который проверяет несколько экземпляров классов эквивалентности.
В CI человек может принести новый линтер с статическим анализом кода, а может не принести.
И никакой MBA не поймёт, не увидит это и не сможет контролировать. Чтобы такое контролировать, нужно контролировать мысли в голове у человека.
no subject
Date: 2024-10-24 10:57 am (UTC)Єто хорошо на флетрейте - по сути, имеешь профит в том, что минимизируешь себе самому будущий геморрой. Но если в будущем кодом будет заниматься кто-то другой, никакой мотивации, кроме чистой єстетики, не остается. А єто, уві, не всем дадено.
no subject
Date: 2024-10-24 11:27 am (UTC)no subject
Date: 2024-10-24 12:19 pm (UTC)Мой опіт показівает, что сферически вакуумированій начальник никогда не міслит в терминах "хороший/плохой разработчик". Если на участке работника тихо и нет проблем, то єто не разработчик хороший, а участок беспроблемній. И - тадам! - зачем платить больше на беспроблемном участке?
Как пел один чел, "здесь мерилом работі считают усталость".
no subject
Date: 2024-10-24 01:22 pm (UTC)Проблема: либо человек уходит, либо +10% к ЗП. Да/нет?
no subject
Date: 2024-10-24 01:58 pm (UTC)Как разработчики, в борьбе со сложностью проекта, прибегают к структурной и функциональной декомпозиции на обособленніе сущности, так и манагері, в борьбе со сложностью управления метапроектом, прибегают к известнім, обкатанім и (важно!) санкционированім методикам. Одна из єтих методик - инкапсуляция проекта относительно персонала. Ни один разработчик не должен біть ключевім, каждій должен біть заменяем, кто не бегает в міле - тот не нужен, лучше нанять нового за 2х, чем дать слабину и согласиться на 1.5х старому.
Все єто уже десятки лет практикуется на десятках и сотнях тісяч проектов и полагается пусть не самім єффективнім, но достаточно надежнім, чтобі получать средний по рінку віхлоп.
А для работника в єтой стандартно-типовой, квадратно-гнездовой методологии есть только один способ получить +25% - уволиться и наняться в другое место. Причем, на новом месте запросто можно получить и +100%, а вот на старом даже +10% получить практически нереально. Я за все время видел только два случая, когда персоналу повішали рейті, но єто біли очень небольшие конторки (до 30 человек), и там разрабі дали феерический коммерческий віхлоп, примерно 10х от инвестиций. Но, замечу, разрабі получили только прибавку, но не долю в проекте :)
no subject
Date: 2024-10-25 06:16 am (UTC)Адекватный начальник знает, сколько стоит наём нового человека.
no subject
Date: 2024-10-24 12:26 pm (UTC)no subject
Date: 2024-10-24 07:18 pm (UTC)К сказанному
> нужно отнять возможность менять продукт
Тривиально же. Ни одного коммита без ревью, ревью не проходит без ссылки на джиру, таски в джире трассируются до бизнес-требований и привязаны к текущим целям.
PS. Да нет, не "сраная дыра", примерно любой крупный энтерпрайз
no subject
Date: 2024-10-25 06:20 am (UTC)Алсо, какое бизнес-требование определяет стайлгайд проекта и начичие статического анализатора в пайплайне?
no subject
Date: 2024-10-25 11:19 pm (UTC)В данном вопросе непринципиально, но я встречался с правилом "один MR -- один коммит"
> не бывает бизнес-требований, которые разбирают код
Требований не бывает, а вопросы ревьюеров "что делает это изменение?" и "зачем это здесь и сейчас, у нас сроки горят" -- еще как бывают.
> стайлгайд проекта и начичие статического анализатора
Я понимаю что ты хочешь сказать, но пример неудачный -- и гайды и линтер как правило уже норма, их не требуется отдельно приносить. Если рассматривать запрещающий эффект "вообще", для абстрактного тула в вакууме, то он, как правило, обусловлен усилиями на внедрение и постоянными издержками на интерпретацию результатов работы.
И это мы еще чисто личностный аспект не рассматриваем: один разработчик не признаёт линтеров вообще, другой считает данный конкретный продукт дерьмом, третий хватается за любую возможность саботировать сроки...
В теории такое может работать в спаянной команде единомышленников, в усреднённом корпоративном сеттинге... ну, сомнительно.
no subject
Date: 2024-10-29 10:08 am (UTC)> и гайды и линтер как правило уже норма, их не требуется отдельно приносить.
Скажи, ты хоть раз в большом энтерпрпайз-проекте смотрел, кто все эти линтеры и стайлчекеры принёс, и почему? Там ссылка на бизнес-требование или отец-основатель просто делал хорошо?
Помни, любой энтерпрайз-проект начинался с (аналога для соответствующего года) git init.
Вот я и говорю, что есть люди, которые делают только бизнес-требования в минимальном виде на "отстань", а есть люди, которые в этом месте делают оппортунистически-лучше.
no subject
Date: 2024-10-29 11:50 am (UTC)Хз, возможно, оно так и есть.
Я только не понимаю почему ты любую мотивацию не вносить улучшения сводишь к "сделано на отстань". Случаи могут быть разные, и в моменте сделать два бизнес-требования может быть выгоднее чем одно бизнес-требование и одно улучшение. Так что если попытаться убрать из дискуссии всякие там коннотации плохо-хорошо, то речь может идти о стратегии забега на среднюю и на длинную дистанцию, причём какая из этих двух стратегий "вдлинную" -- я бы еще поспорил.