Один из главных источников боли — изменения и релизы. Новые ...
Один из главных источников боли — изменения и релизы. Новые фичи, конечно, радуют глаз. Но если из-за инцидентов вы не успеваете зарабатывать — рано или поздно за вами приедет бизнес с веником.
Но есть приём, который помогает держать баланс между разработкой и устойчивостью. Простая (очень! 😳) штука — считать деньги.
Делать это идеально в применении к инцидентам, конечно, невозможно, но можно пытаться. Осознавая, что инциденты всё равно будут — закладывайте их в бюджет. Прямо в план.
На основании статистики — можно прикинуть, сколько денег система приносит в час, а после каждого инцидента прикинуть, сколько не досчитались.
Если случился инцидент — дело не только в том, чтобы пофиксить баг. Нужно «списать» полученный убыток из error budget-а и смотреть, не ушёл ли баланс в минус. Потому что если ушёл — значит пора остановиться и подумать: всё ли мы так делаем?
Может быть накопился техдолг? Может быть что-то не так в процессах? Может что-то не так в головах?
Пришло время латать дыры, а потом — можно будет снова приоткрыть краник восхитительных изменений, которые принесут миллиарды денег когда-нибудь потом.
Латать дыры в одиночку бесполезно — нужно собрать всех: инженеров, разработчиков, менеджмент, саппорт. Посмотреть, что ломалось, что уже давно бесит, что надо пофиксить в первую очередь, чтобы система снова начала держаться на ногах.
Потому что фичи подождать могут, а если по итогам месяца кончатся деньги — то и новые отличные идеи делать будет не на что.
Похожие каналы
