Продакты всегда платят свои долги

"Ты знаешь, какой у нас тех. долг?" — вопрос, который однажды слышит каждый продакт и ситуация, в которую попадает каждый продукт. Разберемся сегодня, почему до определенного момента в этом ничего страшного, что случается когда он наступает, и как минимизировать вероятность такого наступления.

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

Обычно, команда разработки придерживается построенной ранее логике/архитектуре кода и подстраивает под неё и дальнейшую разработку. Тем самым, построенное когда-либо на скорую руку кривое решение, с ростом продукта/базы, начинает обрастать большими связями и условиями, которые строятся на кривом решении.

И раз он строится на хлипкой архитектуре и логике, то по теории вероятности, однажды всё начнет работать НЕ КАК НУЖНО, а как... позволяют ограниченные возможности (ещё и убывающие).

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

Я для себя выделяю три вида тех. долга:

№1. Допустимый или осознанный долг

Когда объем тех. задолженности ещё ни на что не влияет и его можно довольно быстро ликвидировать в течение допустимого для команды/бизнеса периода времени, которая ещё осознает.

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

№2. Нарастающий тех. долг

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

Объем задолженности уже начинает сказываться на реализуемых вариантах тех. решений пока еще в виде фраз "именно так сделать ___ не получится, потому что у нас ___, но можем сделать по другому".

И да, это делается, работает, но технически решение сильно привязано к тому самому начальному костылю. Далее уже две, три... пятнадцать пользовательских фич (кода), надстроенных над кривым решением жестко привязаны к нему и ⇒ ограничены на уровне функциональных возможностей кода ⇒ ограничивают UX/UI-механики ⇒ ограничивают продукт.

Уже на этой стадии нужно задуматься над будущим и трезво оценить возможные риски (писал о рисках здесь) и если текущий статус развития продукта и планы на ближайшее будущее позволяют взять 1-2-3 месяца на рефакторинг, то, скорее всего, это нужно сделать.

№3. Критический или невозвратный долг

То, к чему, в конечном счете, однажды и можно придти. Объем задолженности уже такой, что бэклог чаще окрашен в красный цвет баг-репортов, а каждая новая строчка фикс-кода порождает еще Х2 строки (в лучшем случае) или роняет систему уже на новой возникшей ошибке в по-прежнему кривой логике разросшегося с годами кода.

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

Посмотрите на Skype, Google, Facebook. Их ключевые продукты генерят деньги, но... стоят в развитии на месте. Они тормозят, в них иногда мелькают элементы из дизайна 2000-ых, они не гибкие, в них нет API по одной простой причине — в приоритете поддержка текущей работоспособности и рефакторинг быстро стареющего кода и интерфейсов. Думаю, что наверное из-за этого же фактора они покупают молодые стартапы, тех. долг которых еще крайне мал и их легче поглотить, встроив в свою и без того сложную систему.

Советы по уменьшению тех. долга

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

Думай на будущее

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

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

Статья про масштабирование в тему: https://exp.fm/posts/83.

Сообщай команде о будущем

Фраза, которую должен использовать каждый продукт-менеджер в постановке задач для команды разработки на новые фичи в продукте: "Разработать с учётом _____".

Работает просто — если вы ставите задачу на разработку новой фичи и вы, как PM, понимаете, что она по механике связана или может быть в ближайшем времени связана с другими (и возможно даже какими-либо ожидаемыми фичами в продукте), то не поленитесь лишний раз обратить внимание ваших ребят из разработки на это. Тем самым вы снизите вероятность того, что они запилят что-то строго по задаче, что будет работать сейчас, но потенциально плохо с будущими разработками которые еще у вас в голове/далёких сторис.

Дружи с тем, кто отвечает за архитектуру и логику

Потому что это именно тот человек, кто и будет отвечает за то, как в конечном счете будет реализована фича или временный костыль.

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

Документируйте пользовательскую логику и код

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

Три главных НЕ, чтобы не копить тех. долг:

— не копить костыли;

— не забывать своевременно избавляться от них;

— не начинать до этого какие-либо серьезные интеграции и разработку.

Что делать если уже встряли?

Признайте болезнь

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

Придется усиленно попотеть с СТО и командой за разработкой полноценного плана действий, который можно условно разбить на следующие этапы:

1. Ставим цели по задолженностям: "Сократить время загрузки страницы поиска до 1 секунды → Ждем рост польз. действий", "Рефакторинг для запуска API (составная из двух сторис) → 10 подключенных к API клиентов", "Переезд на на Laravel 8.0 → Обновление модели платной подписки до Freemium с ростом оборота на 20%".
2. Документирование. Перво-наперво (и самое главное), нужно собрать реальную картину с архитектурой и логикой того, что вы с командой решили оптимизировать. Придется чекать код, попутно проверяя его работу на продакшене, вспоминая на практике "а как у нас всё работает ___" 🙂 Советую описывать это как полноценные пользовательские мини-кейсы, чтобы в новой версии их можно было быстрее найти, воспроизвести и проверить.
3. Аналитика. Собрав всю инфу и прогнав её на кейсах, смотрим заново/с нуля на свой продукт как конечный инструмент для пользователя, изучая его слабые стороны, анализируя возможные причины и их связь между собой и предлагая варианты по улучшению выявленных проблемных мест.
4. Планирование. Переосмысляем инфу, выбираем новые подходящие варианты без конфликтов с чем либо, обновляя сторис и механику работы фичи/кода.
5. Реализация. Отдельные спринты, переформированная команда, отдельная ветка — думаю, программисты и без нас знают что и как там делать.
6. Тесты и проверка. Без них никуда и тут снова пригодятся мини-кейсы из пункта №2. Смотрим старые механики, находим, прогоняем, сравниваем с новыми.
7. Пост-аналитика. Смотрим в цифры и метрики из №1, сравниваем с собственными ощущениями. Если что-то не так, начинаем с №4.

Повторюсь, что многие этапы и моменты связаны именно с ребятами из команды разработки, которым больше виднее, как планировать и проводить рефакторинг кода. Задача продакта – дать как можно больше информации о том, как применяется и может применяться пользователями ваш продукт.

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