Существует миф, что один сильный программист может быть в 10 раз продуктивнее другого — ten-X developer. Я считаю, что таких программистов не бывает, но есть ten-X команды, которые перформят в 10 раз лучше самой слабой команды. Чтобы стать ten-X team, нужно поменять отношение к техдолгу.
Всем привет! Меня зовут Олег Федоткин, я руковожу разработкой PAAS в компании «СберМаркет». Эта история про менеджмент и инженерные практики. Ten-X появляется как раз там, где соприкасаются эти два понятия. Начну с детективной истории: кто-то утопил команду в айтишке. Спойлер: убийца — техдолг. Расскажу как его оценивать и измерять, причём здесь зебры, бихевиоризм и психология. А главное — расскажу про выезд из кризиса. Что делать, если вы уже погрязли в техдолге, как им управлять. Поехали!
IT-детектив — кто убийца?
История выдуманная, все совпадения случайны. В команде шесть человек: бекэндеры, фронтэндеры, чувак от бизнеса. Команда перформила прекрасно.
Она завершила два проекта, один — в январе, второй — в мае. Причём первый они завершили раньше положенных сроков. Им доверили делать очень важный третий проект. Он должен был завершиться спустя семь месяцев. Но что-то пошло не так.
В июле они закончили рисовать схемы и распиливать всё на эпики. В августе, говорили, что до MVP осталось пару недель. В сентябре, то же самое. В октябре, что до декабря успеют и точно выкатятся. В ноябре — уже не до декабря… К сожалению, случилось это только после Нового года.
А дальше новогодние праздники, потом раскачка, из команды ушли люди. В общем, ничем хорошим эта выдуманная история не закончилась. Что пошло не так?
Немного о целях…
Несколько лет назад я прочитал одну известную книгу под названием «Цель», это бизнес-роман: художка, но с встроенными в повествование бизнес-уроками. Если коротко, цель компании — зарабатывать деньги. Главного героя назначают директором завода, но предприятие не зарабатывает. Тогда у персонажа появляется наставник Иона. Он рассказывает ему о теории ограничений. Директор внедряет её внутрь завода, всё получается, и прибыль приходит. Happy end.
Сейчас появилось переложение на базе идей автора этой книги Элияху Голдратта — про IT. Книга называется «Проект Феникс».
По сюжету книги, главный герой считал своей работой производство деталей. Но Иона опроверг эту мысль. Он показал склады, логистику, предложил посмотреть на работу сверху. Прочитав, я задумался, а что является моей работой? Я сделал свою часть, дальше разработчик берёт таски из бэклога, делает их, катит в прод. В тот момент моя картина миры выглядела примерно так: на входе новые фичи от продакта, на выходе — прибыль или ценность для бизнеса. Тогда я не понял теорию ограничений и успокоился. Но спустя время вернулся к этой истории и понял, что кто-что упустил.
Однажды утром я пришёл на работу и услышал один диалог. Команда обсуждала задачи: они напилили фичи, но продакт их выкинул. Для наглядности приведу пример из игростроя. Допустим, мы делали игру с подписочной моделью, но тут менеджер решил, что будет не подписка, а free to play, и всё нужно переделывать. Что-то похожее произошло с той командой.
Что это значит для моего графика работы? Обычный пайплайн — фичи, бэклог, разработка, готовые фичи, прибыль. Но готовые фичи могут превратиться в техдолг, потому что нужно не только выпилить их из проекта, но и перепилить старый код. Возвращаясь к примеру выше, невозможно жить с free to play, и с pay to play подписками внутри проекта.
Думаю, многие запиливали фичу просто побыстрее. А ещё предыдущие проекты требуют поддержки, хотя они уже работают в проде. Нужно обновление фреймворков, секьюрити апдейта и ещё много чего. Плюс из-за роста кодовой базы или предполагаемой нагрузки, тоже возникают какие-то изменения. По итогу, прибыль приносят только фичи, которые прошли весь пайплайн.
Источники техдолга
Все эти поддержки, новые вводные и так далее — денег не приносят, а время отнимают. Посмотрим на список источников техдолга, которые нельзя избежать.
Приведу простую истину — оплата технического долга не приносит прибыли. При этом, если долг не выплачивать уменьшится ценность компании и прибыль. Получается следующее: вы не зарабатываете, как выплачивая техдолг, так и не выплачивая его. Это печально.
Вторая печаль: техдолг всегда растёт. Не бывает команд, у которых он статичен, он всегда накапливается.
Так всё-таки как пользоваться таким инструментом как техдолг?
Классификация техдолга
Остановимся на участке пайплайна про бэклог и разработку. Попробуем классифицировать с помощью входных и выходных задач, сколько техдолга пришло в бэклог, и сколько мы сделали.
Если входной техдолг больше выходного, in больше out — команда находится в статусе falling behind. Если эти два числа равны, то мы treading water — держимся на плаву. В Гугле это ещё называют running to stay still — бег, чтобы оставаться на месте, трата сил на то, чтобы просто не утонуть. Тратится энергия и ресурс команды. Если in меньше out, то мы лучше выплачиваем долг, и потом уже innovating — развиваемся.
В первом случае команда тонет буквально, его я называю «хуже каждый день». Time to market снижается, не хватает времени на добавление ценности, снижаются SLO (A), и время ожидания выполнения стремится к 100%.
Немного о загрузке команды
Представим команду из четырёх человек. Рассчитаем по формуле примерное время ожидания одного инженера. Wait time, рассчитывается так: делим процент занятого времени на процент свободного. Допустим, у Макса занято 50, свободно 50. Делим одно на другое, получается 1.
Вася занят 80% времени, 20% — свободен. Получается 4. Если мы обратимся к Васе, а не к Максу, мы будем ждать выполнения этой задачи в четыре раза больше, хотя повысили загрузку только на 30%. Но есть менеджеры, которые говорят что нужно больше занимать людей работой.
И вот он Петя — загружен на 95%. В сравнении с Максом задача будет ждать его 19 раз больше. Есть менеджеры, которые считают, что нужна загрузка максимальная — 98%. Бедный Саша. Да, он оказывается где-то наверху получившейся клюшки. Это плохо! Новые задачи до сотрудника просто не дойдут. Он их не будет выполнять, примерно никогда.
Если у вас есть менеджер, который считает, что нужно загрузить людей задачами, а потом удивляется, что ничего не делается, покажите ему этот график и расскажите про теорию ограничений.
Убийца — техдолг?!
У этой истории есть ещё более страшная сторона. Растёт техдолг и его количество, потому что in больше out. Увеличиваются бэклог и загрузка, менеджер пытается впихнуть больше задач в условный спринт.
Возрастает спринт, загрузка людей, время ожидания выполнения. Чем больше вы срезаете углы, тем сложнее внедрять новые вводные. Потому что у каждого программиста высокое время ожидания. По итогу, получается замкнутый цикл: растёт техдолг, растёт загрузка — растёт загрузка, растёт техдолг.
Команда тонет и проект тонет вместе с ней. Это ответ на вопрос кто убийца. Техдолг потащил её вниз, туда, где никто не хотел бы оказаться.
Если мы удерживаемся на плаву, то мы не тонем, но и не плывём вперёд. Если чуть-чуть прекратить выплачивать долг, то техдолг утащит на дно. Плюс вы потеряете крупных спецов, потому что никто не любит жить в стагнации. Если техдолга мало, то ещё норм, если много, но вы его держите на уровне, это уже плохо.
Если техдолг уменьшается — это хороший статус. Появляется больше времени на создание ценности и на инициативу людей. Мы стремимся попасть сюда, в идеале, в innovating.
Причём тут зебры?
Роберт Сапольски профессор биологии, неврологии и нейрохирургии рассказывал о психологии стресса на примере этих милых животных. Когда зебра в Саванне видит льва, у неё усиливается пульс, увеличивается частота сокращений сердечной мышцы, повышается давление, меняется метаболизм. Если раньше она накапливала энергию, то теперь время отдавать её в мышцы, чтобы убежать от льва. Выключается пищеварение, потому что, если зебра его не выключит сейчас, то лев включит его вечером, чтобы переварить зебру. Ещё память улучшается, в стрессовой ситуации мы запоминаем вещи лучше.
У нас нет шанса встретить льва в Саванне, но мы можем попасть в пробку — реакция организма одинакова. Она отличается лишь уровнем, но не принципом, то есть она количественная, но не качественная.
Встретить льва — это резкий пик, плавный спад, попасть в пробку — это чуть менее резкий пик и менее плавный спад. К примеру, я попал в пробку, приехал в офис, пролил на белую рубашку кофе, пришёл в переговорную, там нет интернета, у меня встреча горит. До вечера эта гармония превращается в пилообразную историю. Всё приводит к тому, что встретить льва полезнее для организма, чем постоянно подвергаться маленьким стрессам.
Краткосрочный стресс превращается в хронический. Нарушается кровеносная система из-за постоянно высокого пульса и давления. Возникает гипертония, аритмия, повреждение сосудов — всё плохо. Метаболизм превращается в синдром хронической усталости, повышается риск диабета. При отключённом пищеварении растёт аппетит, нервное состояние приходится заедать, ухудшается эксплицитная память. Хронический стресс — это яд для вашего организма.
Если заменить слово «стресс» на «технический долг», получается то же самое. Техдолг — важная и нужная часть разработки ПО. Он различается степенью влияния на ваш проект. Если его мало — проблем меньше, если много, то это хронический техдолг, яд для проекта.
Факторы снижения стресса
Всего их пять, они научно доказаны опытами в лабораториях.
Первый фактор — социальное взаимодействие. Если вокруг дружелюбный социум, вы стрессуете меньше.
Второй фактор. Если есть выход для фрустрации, вы стрессуете меньше. Что это такое? К примеру, наорать на коллегу, побить грушу, походить, покататься на велике.
Третий фактор — контроль над ситуацией или создание ощущения того, что вы можете её прекратить. Например, если откатить релиз, возникнет чувство, что вы что-то контролируете.
Четвёртый фактор — прогнозируемость стресса. К примеру, на Яндекс Картах, есть прогноз «сколько осталось стоять в пробке». Прикинув время проведённое в пробке, вы стрессуете меньше. Доказанная история.
Плюс, если ситуация улучшается, стресса меньше — это пятый фактор. Для примера приведу результат эксперимента на крысах. Первое животное били током 10 вольт, потом плавно снижали до 5. Вторую крысу били сразу пятью вольтами. Когда их обеих били по 5 вольт, у первой крысы стресс был меньше. Потому что разряд меньше, значит жизнь налаживается.
Приобретённая беспомощность
Продолжу про научные эксперименты. Крысу помещают в клетку, звучит сигнал, её бьёт током. Но только половину клетки. Крыса — умное существо, она учится избегать ударов, перебегая на другую половину. Она додумывается до этого буквально за пару часов.
Вторую крысу помещают в клетку и сразу бьют током. Причём весь пол. Без сигналов, без возможности что-то исправить. Потом меняют эксперимент на первый. Звучит сигнал, бьют током только половину пола, но крыса уже не пытается сбежать от удара.
Это назвали приобретённой беспомощностью. Когда мы отказываемся обучаться из-за прошлого негативного опыта.
Это напоминает ситуацию в айтишке, когда звучит:
— «Это уже не отрефакторить»;
— «Давайте перепишем заново»;
— «Не трогайте, оно работает».
По-моему, некоторые из нас приобрели эту беспомощность по отношению к техдолгу.
Как выбраться из кризиса
Сначала, что делать, если вы уже попали в кризис и просто тонете? Я видел примеры, когда команда тонет и пытается внедрить Скрам или Канбан, но это не получается. Когда у людей куча работы, они просто будут отталкивать ваши инициативы. Здесь два варианта: меньше делать или больше нанимать. Процессы не работают, пока техдолг не прекратит расти.
Первый вариант — начать проводить стабилизационные спринты. Это когда вы две-три недели платите техдолг и не берёте новых задач.
Второй вариант — нанять больше людей в разработку. Не думайте, что найм не решает проблему. Кто-то скажет, что новые люди в команде принесут только задержки, но в лонгране это сильно поможет. Хотя потратить время на склеивание команды, внедрение, образование новых связей действительно придётся. Из моей практики, капасити нового человека равен минус 30-50% первый месяц и нарастает на 10-20% с каждым следующим месяцем.
Выбраться из статуса «техдолг не растёт» в «техдолг убывает» проще. Можно ввести WIP-лимит. К примеру, у нашего девопс в PAAS не больше двух задач в работе в один момент времени. Это улучшает качество и уменьшает срезанные углы.
Второй вариант — пропорции. Это готовый фреймворк, его можно использовать. Привожу его ниже.
Как управлять техдолгом
Чтобы не допустить большого техдолга, нужно учитывать четыре момента.
Шаг 1. Визуализируйте
История из личного опыта. Мы начали делать PAAS-платформу в новый год и 1 апреля должны были запуститься. Мы успели, и первый сервис поехал в прод нашей платформы. В этот же день я начал трекать техдолг. То есть, первый шаг который мы сделали — ввели в Jira тип задач «технический долг». Мы оценивали его в сторипоинтах, назначали задачи на людей. Вот такой визуальный график был у нас осенью.
Я понял что он растёт очень быстро, и практически не падает. Я мог проследить судьбу той выдуманной команды из выдуманной истории.
Шаг 2. Найдите
Здесь у вас может появиться вопрос: как наполнять Jira этими задачами? Новые вводные попадают сюда от продакта. Срезанные углы от разработчиков на стадии мерджиквеста. Но откуда забирать задачи на поддержку и рост? Кто их приносит в Jira?
Здесь мы переизобрели фичу из Скрама. Есть product backlog refinement, когда вы собираетесь с продактом и задаёте вопросы про задачи, которые есть в бэклоге, и заносите их в Jira с описанием всей истории. Продакт приносит свой поток сознания, его обсуждает команда, и это всё попадает в бэклог. Мы назвали нашу штуку TDR — tech debt refinement. Что происходит?
Команда собирается вместе, обсуждает состояние текущего и прошлых проектов. Вышел новый фреймворк, обновление, ресы с пятой на шестую. Эти встречи обязательны, минимум час в неделю для каждой команды. Больше можно, меньше нельзя. Оттуда у нас появляются поддержка и рост. Эти источники у нас формализуются на tech debt refinements.
Шаг 3. Посчитайте
В бэклоге есть соотношение задач друг к другу. У нас было 10% багов, 60% — задач, 30% — долга. И ровно в таком же соотношении мы начали в наши спринты брать задачи.
Вначале мы выплатили много, потом — ещё больше, а потом — меньше. Просто потому, что изменилось соотношение задач, багов и техдолга внутри нашего бэклога. Поэтому такая получилась лесенка.
Шаг 4. Платите
Если вы визуализировали, нашли, посчитали и не выплатили — получается, всё было зря. Поэтому платите каждый спринт. Если у вас есть продакт, расскажите ему, что будет, если не платить.
Техдолг = стресс
Я говорил про факторы стресса: контроль, прогнозируемость и ощущение улучшения ситуации. Методология ВИСП (визуализируйте, ищите, считайте, платите) помогает со стрессом бороться.
Если вы что-то нашли и отобразили, вы можете это контролировать. Посчитав размеры платежей, вы можете прогнозировать выплаты. Когда вы рассчитали сколько будете платить, вы ощутите улучшение ситуации. Так техдолг и стресс сплетаются воедино. Элементы борьбы и с тем, и с тем очень похожи друг на друга.
Выводы
Техдолг всегда накапливается, невозможно этого избежать. Есть пять основных источников техдолга. Есть четыре стадии развития команды по отношению к размеру её долга. Напоминаю про замкнутый цикл обратной связи: техдолг и время ожидания выполнения. Есть три фактора стресса и пять факторов его снижения: визуализируйте, ищите, считайте, платите.
И главное, что хочется донести, техдолг — просто инструмент, это молоток. Он не кусается, пока им не ударить по пальцу. Надеюсь, что после этой информации у вас появилось больше возможностей не бить этим молотком себя по пальцам.
Надеюсь эта статья была полезна! Если тебя интересуют управленческие практики в it, заглядывай на мой Telegram-канал «Инженер и менеджер». Там я часто советую книги об управлении и стратегии и делится инсайтами о работе в роли EM.
Tech-команда СберМаркета завела соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и YouTube.
Еще много практики от высоконагруженного e-commerce будет на московском HighLoad++ 24 и 25 ноября. Архитектурные кейсы, оптимизация баз данных, инфобезопасность, тестирование, DevOps — 120 новых докладов!