В IT чудес не бывает
877 subscribers
142 photos
21 videos
1 file
379 links
Лайт-версия блога https://www.maxshulga.ru/ про менеджмент, качество и процессы в IT от доброго доктора АйТиболита @maxbeard12
Download Telegram
- Кто зафакапил сроки и релиз?
- Тестировщики долго тестировали!
- У нас нет тестировщиков.
- Чёрт, такая хорошая отмазка, а не прокатывает!

Из архивов древних интернетов (с) Табличка “Сарказм” (glorphindale из завалинки X-твиттер)

Большие разрывы между релизами, отсутствие удобной возможности доставлять обновления/патчи/фиксы, нежелание заказчиков делать это обновление возможным - шикарное поле для бесконечной деятельности называемой "тестированием".
Которое, как и ремонт, нельзя закончить, можно только прекратить.

ЗЫ а, еще "сертификацию" забыл, тоже очень творческое мероприятие: из-за которой ищем все что можем найти и даже больше, ибо фиксы - очень дорого

#байки #мысли_вслух
👍41🔥1😁1💯1
Если поменять "product" на "feature" тоже неплохая (хотя до безобразия банальная) шпаргалка получается.
А то иногда сначала делаем, потом думаем "зачем".

Product pitches should be delivered like a three course meal
2
плюсую...

#it_memes
😁19💯8👍5
How We Can Stop Confusing Long Term Goals with Short Term Plans

Several of my clients want to plan the product roadmap and then “work to the plan.” They think the roadmap is the long-term goal.
But roadmaps aren't goals. Instead, they are tactics for achieving a long-term goal.

...effective strategy is never really “done.”

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

#развитие #стратегия
👍1
Про жуков и их подсчеты (продолжение)
В прошлый раз мы закончили историю на том, что придя со сбора жуков с картофельного поля, Григорич наткнулся на статью про баги. Первую реакцию вы помните (кто не помнит, идите почитайте).

Картошка жареная, отварная, пюре, картофель фри, картофель пай. Картофельные пирожки с мясом, с грибами и так далее. Картофельные оладьи, картофельная запеканка…” - бурчал Григорич, читая статью и попутно комментируя каждую из метрик в “НаЗавалинке”.

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

Ниже бурчание Григорича и ответы ему от Сергеича.

Метрика: "Количество заведенных и закрытых дефектов" - без понимания того, какой объем кода появился/изменился или какие задачи решали, бесполезная метрика. Но хороший маркер "обсудить".
Дед Сергеич: - Это про то фиксят или нет, объем кода вторичен тут. Хорошо стреляет на командах которые регулярно делают бизнес-рывочек.
Григорич: - Ну 10 багов на 100 строк и 10 багов на 1000 - это разные 10 багов. Не?
Сергеич: - Неа. Потому что модульность/микросервисы/кафка-мать-её-в-сраку и вот это вот все. Плотность багов на единицу строк кода тогда и сейчас - это арифметически одно и то же , а по природе разные вещи.

"Соотношение дефектов и задач" - очень усредняющая метрика, прям как средняя температура по больнице. Причины слабо диагностируются.
Сергеич: - Это ещё один маркер того, что команда тонет в бизнесовых задачах или успевает выгребать тех долг
Григорич: - или просто код херовый пишет :)

"Количество отмененных дефектов по месяцам для теста и прода" - думаю, зависит от продукта, структуры компании (а-ля тестеры "отдельно" от разработки), модели использования продукта. Спорно. Я бы не считал

"Коэффициент ошибок, пропущенных на прод" - вот кажется, что полезна. А на самом деле скорее для ЧСВ тестировщиков. А польза зависит от модели использования: для SaaS (того софта, что сами менеджерим в проде) важнее скорость обнаружения/отката/зачинки. А вот для On-Premise (разворачивание в среде и силами заказчика) может быть интересна: скорость и возможность применения фикса ограничены.

"Распределение дефектов по приоритетам для теста и прода" - имхо баг надо или чинить, или не чинить. Не очень понимаю этих приоритетов. Но я разраб в прошлом, мне простительно.
Ответ Сергеича "Оно работает в паре - если ты на проде вылавливает больше Critical и Blocker чем на тесте - значит у тебя уже есть проблема."

"Распределение дефектов по категориям для теста и прода" - самая полезная метрика, но самая затратная: требует доп.усилий по классификации категорий, компонентов, коду и установки этого в самом дефекте. Будут просто забиывать, а если установка поля будет форсится, то ставить дефолт в джире или “от балды”.

"Время жизни дефектов, найденных на проде, по приоритетам" - норм

"Время жизни дефектов, найденных на проде или тесте, в разбивке по месяцам для каждого приоритета" - норм, похоже на то, про что я выше писал про скорость скорость обнаружения/отката/зачинки

"Количество Acceptance Bug на задачу" - подсвечивает проблемные задачи: с точки зрения проработки и технического качества кода. Маркер для "обсудить"
__________________

Хмм, ну то есть в целом то, вроде не все так и плохо. Какую-то пользу от учета жуков можно получить.
Вся тонкость в том, как, кто и для чего этими циферками потом пользуется. Если "по людям" считать, то будут "ломать", как и любые другие циферки.

Ну и не надо называть это “качеством” - пробурчал напоследок Григорич, закрыл ноут, снова взял баночку для жуков и пошел оглядывать картофельную делянку, которую не посмотрел с утра.
#григорич #качество #metrics
👍2👎1💯1
я гриб - релиз на проде погиб...

Пятничная #it_memes считалочка
😁5
Code coverage vs Code Quality

Покрытие кода - "сколько продакшен кода вызывается, когда запускаются автоматические тесты", очень популярная метрика, которой пытаются измерить качество кода, а скорее тестов, которые его покрывают.
Но давайте простой пример.
Есть функция, которая что-то делает и есть тесты, которые вызывают каждую строчку этой функции, что дает нам 100% покрытия.
Качественный код/тесты? А неизвестно.
Потому что в целом нам важно не только то, что функция сейчас делает, но и ответ на вопрос, а что она должна делать.

Передали, например, в нее NULL, который никак не обрабатывается и finita la commedia нашему 100% покрытию.

Что же нам дает эта метрика на самом деле?
А то, что видя эти цифры, можно отследить момент, когда у нас появилось больше кода, который вообще не затрагивается тестами. И зная про этот код, можно предусмотреть дополнительную активность предусмотренную вашими процессами и тестовой стратегией, будь то "остановка мержа" до устранения возникшего долга или дополнительные "ручные" проверки.

Итого:
• мерять полезно, работает в комплексе, используется для анализа изменений одного и того же кода/тестов на временном отрезке.
• сравнивать эту метрику для 2х команд между собой - херня.
• 100% покрытия не говорит ни о чем
• но, хорошее дополнение в комментариях, для динамических языков большой процент покрытия дает больше уверенности в том, что косяков меньше, чем могло бы быть
• покрытие кода даст вам количество, когда вам нужно качество

#quality #metrics
👍5💯3
Чем больше думаю про качество и над вопросом, как его пощупать (кроме денег), тем больше прихожу к мысли, что мем “нормально делай - нормально будет” вполне себе дает подход с хорошим качеством на выходе.

И дальше весь вопрос в цене того самого “нормально делай” и снова про деньги, которые уже можно сравнивать с тем, что зарабатываешь.

А ты просто думай про фичу, пиши код, документируй реализацию, используй линтеры, статический и динамический анализы, пиши автотесты, меряй покрытие, проводи код-ревью, тестируй на нефункциональные требования. Просто нормально делай свою работу.
Все, дальше просто считай деньги: потраченные и заработанные.

Все остальное от лукавого. Скучно.

PS ну если очень интересно, то можно позадавать себе вопросы "насколько хорошо я делаю то, что должен". Но кого это интересует, мы же тут все про "измерение качества продукта"...

#мысли_вслух #quality

PS2 болеть плохо, всем читателям крепкого здоровья
💯8👍2🔥21
Памятка...
Надо что-то такое придумать (или найти то, что придумано до нас) про оценку и трекинг задач в часах.

Хотя на самом деле, что часы, что сторипойнты, что майки, что слоники - важна дисциплина в том, как ты подходишь к оценке при планировании и трекингу текущего прогресса.

PS смотри больше постов про оценку по хештегу #оценка
5😁3👍2🔥2🤔1
В IT чудес не бывает
Памятка... Надо что-то такое придумать (или найти то, что придумано до нас) про оценку и трекинг задач в часах. Хотя на самом деле, что часы, что сторипойнты, что майки, что слоники - важна дисциплина в том, как ты подходишь к оценке при планировании и трекингу…
Трекинг и #оценка задач в часах:

1 час - "хорошо декомпозированная задача"
2 часа - "хорошо декомпозированная задача" + кофе + партия в кикер
3 часа - "хорошо декомпозированная задача" + кофе + партия в кикер + обед
4 часа - "че ж я такое делал сегодня? А, вот эту задачу"
8 часов - "от рассвета до заката что-то делал 2 дня, но задача в беклоге одна. Просто у нас встреч много"
😁11😢5👍1
If you're thinking without writing, you only think you're thinking.
(с) Leslie Lamport

#мысли_вслух
🤔2💯21🔥1
Планируем и оцениваем лишь для того, чтобы потом было что “резать”.
Всегда умиляла история “вы сначала оцените, потом будем думать, будем это делать или нет”.
Какой смысл точно оценивать то, на что потом точно не дадут времени/денег/людей/инфры?
А если вдруг дадут, то почему сейчас не дают на то, что нужно вот прямо сейчас на другие задачи…
Эмоционально-риторические вопросы про #оценка
🔥61👍1
В IT чудес не бывает
If you're thinking without writing, you only think you're thinking. (с) Leslie Lamport #мысли_вслух
Про "думать".

Всегда гордился умением все (ну ок, почти все) запоминать, быстро потом сопоставлять факты и тдтп.
Но “мыслетопливо” со временем похоже стало заканчиваться быстрее, чем накапливаться и приходится чаще записывать. Особенно, когда речь идет про одновременно идущие и долгоиграющие проекты, неважно в работе или в личной жизни.
Некоторые “бурчалки из метро” так и не появились тут в канале только потому, что я их не успел записать. Или записал тезисами в виде аналогии, типа такой “способы достижения качества - способы приготовления мяса - щуп для температуры”. Офигел потом, когда прочитал этот тезис… (но потом все же вспомнил, про что была мысль).
#мысли_вслух
💯3👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Да просто чек-бокс не работает. Минорчик.
Починим в следующей версии.
😁261🔥1
Когда на неделе уже 2ая пятница, нельзя не напомнить важное в #it_memes
😢6💯43🔥1😁1🤔1
В IT удивительным (но вполне объяснимым) образом сочетается культ чисел и их отторжение.

Одновременно может существовать помутнение в виде подсчета сторипойнтов/размеров маек и тп абстракций и требование учета физических часов.

Никакая мысль не воспринимается без доказательств в виде таблички чисел. При этом те же инженеры, которые сами только что требовали численных доказательств, так и не научились называть что-то похожее на правду в часах при оценке. То есть оценить чью-то мысль без чисел - никак. Сгенерировать (без random) свои числа - тоже никак.

Одновременно топить на ретро за проставление часов в задачах и не делать этого для своих задач - тоже вполне себе уживается в голове среднестатистического инженера.

Менеджеры (но тут я думаю не только в IT) давно используют свои коэффициенты для перевода чисел от разработчиков в числа идущие наверх. И чем опытнее менеджер тем, сложнее его формула конвертации рандома от инженеров в свою оценку.
Особо умудренные даже не парятся с этой конвертацией, а выстраивают сначала процессы учета всех "гаданий", а потом, после очередного облома, уже процессы коррекции ожиданий с реальностью.
Потому что оценка всегда лажает.

Ведь важна на самом деле не оценка. А воспроизводимая за некую единицу измерения полезность того, что ты делаешь.

#мысли_вслух #оценка
👍73💯3🔥2
Эмм, вкусняха - подумал Григорич, перевернув очередной стейк на решетке.
Хмм, а точно ли вкусно? - мелькнула шальная мысль. - И почему если вкусно мне, то будет вкусно еще кому-то?

Ведь кому-то норм только well done, а кому-то только слегка подкрашенный огнем rare. И ведь все знают, что это определяется температурой внутри куска, и даже понятно, как и чем эту температуру мерять. А все равно на выходе все куски будут разные.

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

Клиенту в итоге все равно может не понравится, но зато ты можешь честно ему показать Jira-отчет со списком багов график температуры внутри куска мяса “в конце было ровно 66 градусов, вы получили свой medium well” :) Где при этом бы щуп и что он мерял - никто не знает. Но формальности соблюдены.
Температура мяса - это все про принципы приготовления, подход, базис. Это не то про метрики, значения которых что-то доказывают.

Думайте про принципы и подходы в разработке, находите критичные точки и узкие места, перестаньте боготворить отчеты по багам. Это не про конечное качество. Хотя, как чудесно написали как-то в комментах, баги считают не для того, чтобы оценить качество продукта, а для того, чтобы проконтролировать то, как ты работаешь. И попасть в ловушку иллюзии, что этот контроль налажен.

Вытряхнув эту мысль из головы, Григорич отправил отдыхать очередной свежеприготовленный стейк.

#григорич #quality
👍3😁2🔥1🏆1
Про бонусы
(с которыми у меня натянутые отношения, но с которыми все же приходится сталкиваться)

If bonuses are necessary
Bonuses are about more than just business metrics. Focus on what truly matters.

It’s no surprise most companies prioritize business metrics when assessing bonuses. This isn’t the right approach. If a bonus system is essential to your company’s culture, consider the following metrics structure:

• Roadmap focus (40%): Contributions to top priorities (~60% to roadmap).
• Initiative completion (30%): Timely and quality project delivery.
• Business metrics (15%): Company financial performance.
• Product stability (15%): Keeping the product stable with minimal outages.

This way, you primarily reward engineers based on their contributions to what matters most, not just the organization’s overall financial success.

If you don’t have clearly defined metrics, your team will turn against you.

Make sure these metrics are clearly defined and communicated to avoid misunderstandings. You’ll lose your team’s trust if they interpret them differently or feel they’re inconsistently applied.

Watch out for these traps
• Don’t link engineer compensation too closely to variables they can’t control. Performance-based incentives can backfire as engineers have limited influence on product outcomes.
• Align incentives with what engineers can impact. Missing targets can result in lost motivation and talent.
• Focusing on OKRs can boost metrics but create a culture where people prioritize their products/projects at the expense of others — where everyone looks out for themselves instead of working together.


Creating the perfect compensation model for your software development team

#management
7👍1🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
UX - красиво нарисовал
разраб - красиво сделал
QA - а давайте вот так проверим...
PO - напишем ограничения "двери открывать только в Калифорнии"

срочные #it_memes, а то народ убегает после моих типа умных постов
😁17🔥42
Никогда не смотрел на найм (или наём, если по-русски) с этого угла: кого нанимать вместо ушедшего сеньора? Сеньора или мидла?
Как-то по умолчанию шло: кто ушел, того и ищем.
Почему? Да потому что потом бюджета на повышение не будет 😏
А тут целые алгоритмы оказывается...

Потому что иначе "засилье" сеньоров будет 😃 (картинка в комментах): промутить то нужно.
PS а если просто не промоутить? 🫠

#management
👍1🤔1