Сколько живут проекты и стоят костыли

 Публичный пост
21 мая 2023  352

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

pNc > F

p - вероятность возникновения ошибки за период
N - количество таких периодов
c - стоимость единичной ошибки
F - стоимость фикса

Например,
у нашего тестировщика за месяц ошибка воспроизвелась ровно один раз в течение 30 минут и пофиксить ее в конкретном случае 15 минут. На первый взгляд, что-то минорное и на это можно забить.
Примерный расчет исходит из того, что весь месяц тестировщик только и занимался что проверкой системы

p = 0.5 / 22*8 = 0,3%
с = 0,25

Небольшая система, которой пользуется 1000 человек каждый день. Получим, что стоимость поддержки за год
0,003 * 0,25 * 1000 * 12 = 9 часов

А теперь самый интересный вопрос - сколько лет будет жить моя система? Я предлагаю четыре варианта ответа

  1. Равномерное распределение

Если вы ничего не знаете о процессе, то самая простая гипотеза - процесс имеет равномерное распределение и вы в середине, то есть если проекту 5 лет, то неплохая гипотеза - будет еще 5 лет.

Возвращаясь к примеру, стоимость поддержки бага - 45 часов

  1. Like-to-like

Ваша система будет жить столько же, сколько и аналогичные. Недавно я выключал систему, которой было 18 лет. Можно предположить что система заменяющая будет жить примерно столько же.

Стоимость поддержки для такой системы - 162 часа.

  1. Like Ubuntu

Посмотрите на релизный цикл Ubuntu. Каждый два года выходит версия LTS, которая поддерживается десять лет. Это дает интересное соотношение Long Term Support в пять раз дольше разработки.

Пусть в примере фичу кодили три месяца, поддерживать ее надо будет пятнадцать месяцев.

Стоимость поддержки бага - 11 часов.

  1. Среднее по больнице

Для этого я посчитал среднее время жизни репозиториев github'a, у которых более 10к звездочек

Так выглядит распределение времени жизни архивных проектов

Так выглядит распределение для активных проектов

Дальше можно поспорить какую статистику брать для "среднего времени жизни". Пусть для примеру будет консервативное целое - 6 лет.

Стоимость поддержки бага - 54 часа.

Итого
"безобидный" баг из примера легко обходится в неделю рабочего времени, но я с трудом представляю проджект менеджера, кто подобный фикс берет в работу, даже если фикс займет 8 часов. Хотя с точки зрения Return Over Investment можно получить отличную выгоду, пусть за 8 часов можно сэкономить 11 - ROI = (11 - 8) / 8 = 37,5%

11 комментариев 👇
Александр Фисенко Руководитель направления 21 мая 2023

я с трудом представляю проджект менеджера, кто подобный фикс берет в работу, даже если фикс займет 8 часов

Скорее всего ситуация в том, что у других фиксов экономия выше. Какая-нибудь частоиспользуемая кнопка на 1000 пользователей, которые ее нажимают раз в 5 минут, даже на 1 секунду лага дает больший простой

  Развернуть 1 комментарий

@Fisenn, я не сравниваю баг А и Б, я утверждаю, что по моим наблюдениям, 1) подобного рода дефекты не приоретизируются 2) стоимость поддержки не вычисляется 3) оценка продолжительность жизни проекта неинтересна

  Развернуть 1 комментарий

@dimaya, Приоретизация это и есть сравнение багов А и Б, какой из них быстрее взять в работу.
А для багов в одной системе продолжительность жизни проекта одинакова, поэтому не влияет на сравнение.

  Развернуть 1 комментарий

@Fisenn, Время жизни может быть разным в рамках одной платформы, часть фунционала временная by design, часть будет выключена раньше самой платформы. Стандартный бэклог это сотни существующих issues, большинство из которых находится ниже порогового значения для рассмотрения. Существующие issues сравниваются с новым функционалом, у которого, очевидно, другой срок жизни.

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

@tkozyrev, Да, не всегда, я как раз сегодня читал статью про использование скрытых марковских цепей для оценки. Есть ещё примерно 3-6 неплохих методов, которые дают достойный результат. Этому можно посвятить отдельный пост.

  Развернуть 1 комментарий

@dimaya, ну да. По-сути, "стоимость бага" это та же "стоимость риска" из риск-менеджмента. Этим можно заниматься, но мало кто из прожект-менеджеров это умеют и ещё меньшее количество практикует... По-моему, это в среднем приводит к куда большим потерям на проекте, чем какие-то там баги...

  Развернуть 1 комментарий

@tkozyrev, Смотря что называете риском, в очень широком смысле да, "стоимость бага" - крайне простая форма риска. Типа как формула площади квадрата - это частный случай интегрального исчисления.

  Развернуть 1 комментарий

@dimaya, именно так. Баги - всего лишь один из аспектов риск-менеджмента, причём, (насколько я вижу) далеко не доминирующий.

Я к тому веду, что если кто-то риск-менеджментом занимается, то баги занимают свою нишу (в дальнем пыльном углу). А в первом ряду место занимают намного более значимые риски (не угадали с ЦА, не так поняли проблему ЦА, не теми способами решаем проблему ЦА, прозевали конкурирующий продукт и т. д.). На их фоне экономия 150 часов поддержки продукта даже близко к статистической погрешности не приближается.

  Развернуть 1 комментарий

@tkozyrev, Баги - это технологический риск. В каком-то смысле не важно это очередной log4j или NPE закодили собственными руками.

Работа с ЦА - это из другой области и там другие техники и методологии работают.

  Развернуть 1 комментарий

@dimaya, ну не знаю. Как по мне, так никакой разницы. Та же стоимость, как произведение вероятности на стоимость последствий, те же стратегии - избегание, перенос, смягчение, принятие...

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

В целом - не принципиально :)

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб