Как стать автором
Обновить

Андрей Ребров: Технический долг в процессах разработки

Время на прочтение 5 мин
Количество просмотров 3.5K
image

Недавно Андрей Ребров поделился в фб со своими читателями своим выступлением про «Техдолг в процессах разработки». С его разрешения, в рамках написания книги про выпускников YC, публикую тут его конспект.

Всем привет, я в разработке с 2008 года. С 2013 года я создаю технический долг в стартапе ScentBird (YC S15), где я являюсь сооснователем и техдиректором. Так же я технический консультант (помогаю техдиректорам) нескольких стартапов — в космической и игровой индустриях.

У нас в компании 40 человек в разработке (Engineering), Product Engineering — 55, общее число сотрудников — 160 человек.

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

Откуда берется технический долг


  • Все начинается со слов: «Давайте сделаем MVP (MLP) поскорее.» Когда ставится задача «срезать углы», чтобы запуститься побыстрее. В стартапах такое случается постоянно, даже у нас после 8 лет.
  • Еще есть COBOL и FORTRAN.
  • Каждая компания тянет за собой технический долг не только в виде кода, но еще и в виде инженерных практик («У нас так принято»).
  • Аутсорсинг и аутстаффинг. Многие аутсорсинговые компании накопили некоторое количество «внутренних библиотек». Если у библиотек нет официального саппорта — это потенциальная проблема.

Не бывает коммерчески успешного проекта без технического долга. Потому что всегда есть компромисс между качеством и сроками. Тут можно вспомнить слова Рида Хоффмана (основатель LinkedIn): «Если вам не стыдно за вашу первую версию продукта, то ваш продукт вышел на рынок слишком поздно.»

image

Мы у себя в компании пришли вот к какому решению для работы с техническим долгом.

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

image

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

Для любой задачи больше недели мы начинаем делать технический бриф. Это двухстраничный документ, который объясняет, какую мы решаем проблему, а не просто играемся с технологией (R&D).

Очень важно описать, что же будет являться критерием успеха для данной задачи. «Давайте перепишем» — не подходит.

Что мы будем менять? Насколько далеко мы полезем со своими изменениями?

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

В документе мы указываем команды, которые будут участвовать в проекте, и команды, которые надо проинформировать, что произошло изменение.

С таким брифом можно уже приходить к product owner или ЛПР.

RACI Matrix


image

  • Responsible
  • Accountable
  • Consulted
  • Informed

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

После этих шагов невозможна ситуация, что кто то скажет: «А меня не поставили в известность».

Очень классный артефакт. Всем кто находится в инженерном менеджменте крайне советую, очень сильно помогает расставить точки над «i».

Когда у вас есть бриф, вы можете достигнуть «единый роадмап».

Единый роадмап


image

Пару лет назад у нас была следующая ситуация: мы только учились правильно управлять продуктом, правильно управлять разработкой и у нас было несколько роадмапов. У продуктовиков — про фичи, У разработки — фронтенд, бэкенд, SRE, QA automation. Естественно, были вопросы «стыковки», кто делает, кто принимает решения.

Единый роадмап показывает всю ситуацию — чем мы занимаемся в каком порядке, куда направляются человеческие ресурсы.

В нашем роадмапе есть проекты разного размера: стратегические инициативы (большие активности с несколькими департаментами для максимальных показателей по подписчикам, выручке и тд), есть инфраструктурные проекты (склад, интеграция внешних ERP).

Это позволяет видеть, как маленькая задача (про технический долг) продвигает стратегическую задачу. Так же это облегчает задачу продать технический долг.

Умение общаться с бизнесом на языке бизнеса, а не на языке разработки (как бы вам этого не хотелось)

Подведение итогов


Выяснить, что то, куда вы пришли — это то куда вы хотели прийти. Стал ли продукт лучше работать? Стал ли он более стабильным? Можно ли теперь скейлиться? Иногда это очень сложно посчитать.

Мы сейчас переходим со SpringBoot на Micronaut, чтобы проще запускать обвязку сервисов машинах разработчиков и для ускорения локальной компиляции. Конечная цель — повысить эффективность разработчиков. Померить эффективность разработчиков сложно. Померить уровень удовлетворенности разработчиков сложно, но можно, это «тонкая материя». Можно померить сколько используется памяти, стартап-тайм. Мы договариваемся об измеримых метриках и их мерим.

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

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

Следующий пункт — очень важно отпраздновать.
Очень часто мы находимся в потоке, делая одну задачу за другой, и вдруг мы понимаем, что мы не испытываем удовлетворения от своей работы: да, мы делаем крутые проекты, мы решаем интересные задачи, у нас интересный коллектив, но… чувства радости нет. Важно, когда мы закрываем очередную задачу по техническому долгу собраться разработчиками за кружечкой чая и обсудить как это выходило, какой опыт получили и что делать дальше. Об этом важно помнить. Успехи надо праздновать.

  • Если вы захотите пообщаться меня можно найти в телеграм: t.me/andrebrov
  • Если вы пишете на Java: t.me/ssc_blog


Вопросы


— Как синхронизировать роадмапы команд?

Я не могу сказать, что мы достигли совершенства, у нас третий подход к тому как делать роадмапы, скорее всего не последний. В сентябре, мы как менеджмент, определили куда мы движемся как компания. Выбранные направления начали формироваться в продуктовые брифы, начинают описываться: цель, как будет работать и тд. Параллельно я работая с техлидами и тим лидами: вот смотрите, куда компания хочет прийти в следующем году, что нам необходимо с точки зрения разработки, какой технический долг убрать, а где заранее проинвестировать в нашу платформу, чтобы наша платформа позволила прийти в нужную точку. И так появляются технические брифы. Когда и те и те брифы готовы, мы сходимся вместе — превращаем брифы в более точные и понятные проекты с точки зрения практического решения задач. Мы используем Story Mapping — когда из описания процессов и flow появляются отдельные индивидуальные задачи.

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

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

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

— В чем оличие от OKR?
OKR будут в нашей продуктово-инженерной команде. Мы не являемся техническим бизнесом (мы не Docker), технологии для нас вспомогательны, у нас есть масса дополнительных подразделений: операционка со складом, бизнес-девелопмент, дизайн. Вводить единый ORK на всю компанию очень сложно.

Теги:
Хабы:
+4
Комментарии 1
Комментарии Комментарии 1

Публикации

Истории

Работа

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн