MVP головного мозга, или Экономически «обоснованный» рост техдолга

Чем больше смотрю вокруг, тем больше вижу подход, когда «Ну вот мы сейчас попробуем фичу малыми силами, а если она взлетит, то сделаем нормально». И у себя в команде, и в смежных, и в больших продуктах. В итоге фича выкатывается, неплохо взлетает, действительно собирает хорошие метрики, вот только доработка до «как надо» будет теперь стоить команде условных пару месяцев переделывания, а за это время вообще-то надо успеть и другие метрики улучшить, так что «Сделаем нормально в Q5, обязательно».

В одной из команд у нас была такая фича, которую мы любя называли «гроб с гвоздями». Гвоздь — это эксперимент для A/B-тестирования, фича-флаг. И в какой-то момент она настолько обросла этими гвоздями, что поддерживать эту жуткую комбинацию флагов стало почти невозможно адекватными усилиями. Не знаю, что произошло в итоге с фичёй, к тому моменту я уже сменил команду, но это был наглядный пример того, как MVP головного мозга всё-таки привёл к блокированию дальнейшей разработки до полноценного переписывания фичи.

В итоге аббревиатура MVP для многих команд звучит не как проверка гипотезы, а как «херак-херак и в продакшен».

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

🔷Перейти от MVP к MLP. Про это я писал у себя в dev-канале. Если у вас не стартап, где каждый час торможения влияет на выживание будущего продукта, а конкурентная среда, то вам прям нужно делать MLP. Интересно то, что для создания MLP часто приходится продумывать архитектуру внимательнее, потому что маленькие детальки могут потребовать значимых доработок.

🔷Считать экономическую выгоду от возврата техдолга. Это прям сложный пункт, который нуждается в нетривиальном анализе трекера задач, разметке блокеров. Но на самом деле техдолг — это как двигатель, который не заводится с первого раза. Иногда вы тратите несколько секунд на заведение, иногда минуту. А иногда движок стопорится полностью, и теперь нужно вызывать эвакуатор. Посчитайте затраты времени на «тыр-тыр-тыр-тыр», умножьте на стоимость часа работы — вот вам и экономическая выгода. К слову, вполне нормально, если какая-то новая MVP-фича может принести сильно больше выгоды, чем переделка старой. Тут уже ничего не поделать.

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

🔷Забить. Да, я серьёзно. В некоторых случаях можно просто забить. Если вы делаете проект-однодневку, который нужен к конкретному ивенту, а потом его закроют — ну и ладно. Если вы в целом планируете потом всё переписать осознанно в рамках объединения с другим продуктом — ну и ладно. Преждевременная оптимизация — это ведь тоже зло. Когда стрельнёт — тогда и поправите.

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