Технический роадмап
~ 50 минут
Когда архитектура уже готова и разработана, начинается самый интересный и затратный процесс — поддержка и доработка. В процессе эксплуатации специалисту, который отвечает за архитектуру, нужно продумывать стратегические и операционные шаги по дальнейшему развитию — разрабатывать технический роадмап.
Технический роадмап предусматривает действия, которые направлены на сохранение работоспособности систем, поддержку бизнес-стратегии и в конце концов вывод систем из эксплуатации. Он помогает понять, что, когда и почему будет происходить с IT-системами. Например, текущую легаси систему лояльности нужно заменить в следующем квартале, потому что она не позволяет реализовать бизнес-планы компании за разумные деньги.
Чтобы составить такой роадмап, нужно понимать:
- Что нужно развивать?
- Почему это нужно развивать?
- Как это нужно развивать?
- Сколько это будет в итоге стоить?
При этом не стоит забывать, что компания развивает IT-продукты для того, чтобы бизнес получил выгоду. Например, может возникнуть такая идея: «Давайте поменяем язык программирования на другой, с бóльшим синтаксическим сахаром». Будьте уверены — это плохой план. У каждого изменения в роадмапе должны быть экономические обоснования.
В этом уроке мы разберём, как создать технологический роадмап. Но сначала посмотрим, как формируется запрос на такой артефакт.
Представьте, что вы работаете над приложением маркетплейса. В четвёртом квартале к вам приходят представители бизнеса и сообщают, что у них готова стратегия на следующий год:
- В Q1 нужно повысить продажи на 10%.
- В Q2 запланирован выпуск новой функциональности. Нужно дать пользователям возможность бронировать товар на какой-то срок без изменения стоимости.
- За Q1–Q2 нужно сократить количество технических инцидентов, чтобы сэкономить на компенсациях и простоях.
- В Q3–Q4 планируется выход на рынки Африки.
Бизнес не просто так презентует свои планы. Ему нужно понять:
- Готово ли IT обеспечить данную стратегию?
- Что для этого нужно?
- Сколько это будет стоить в итоге?
Скорее всего, эти вопросы будут адресовать СТО. А он, в свою очередь, задаст их специалисту по архитектуре. То есть вам.
Ситуацию, которую мы описали, обычно относят к краткосрочному планированию. В этом случае вам нужно запланировать технологические изменения на срок до года. Ещё может возникнуть ситуация, когда бизнес принесёт долгосрочные планы, на срок от года, и задаст те же самые вопросы. Тогда речь идёт уже про стратегическое планирование. Подходы к созданию технического роадмапа для этих сценариев будут пересекаться, поэтому сначала мы сосредоточимся на краткосрочном планировании.
В любом случае ответить сразу на все вопросы не получится. Их нужно решать в порядке очереди. Первым делом необходимо определить, что нужно делать и почему.
Как определить направления работы для роадмапа
Давайте разберём это на примере. Посмотрите ещё раз на цели, которые поставил бизнес:
- Q1: повысить продажи на 10%.
- Q2: выпустить новую функциональность — пользователи бронируют товар на какой-то срок без изменения стоимости.
- Q1–Q2: сократить количество технических инцидентов, чтобы сэкономить на компенсациях и простоях.
- Q3–Q4: выход на рынки Африки.
ТЗ на новую фичу приходит от продакта. В этом случае понятно, что делать, поэтому вторую цель отложим в сторону и сосредоточимся на трёх остальных.
На что ещё тут можно обратить внимание? Бросается в глаза третий пункт. Технические инциденты — это по большей части следствие технического долга. Так что первый кандидат в «что делать» — это обновление технологий.
В разрезе остальных целей связь между бизнесом и технологиями не такая прозрачная. Чтобы определить другие приоритеты, проведите исследование, опираясь на цели бизнеса. Возьмём, к примеру, цель на первый квартал — «повысить продажи на 10%». Нужно понять, как эта цель связана с потерями со стороны техники. Допустим, процесс оформления заказа нестабильный: покупатель уходит, «всё тупит» или часто приходят отмены по техническим причинам. Ваша задача — найти метрики, которые влияют на процесс покупки и могут быть связаны с IT-решениями. Такие метрики обычно есть у продуктового менеджера.
Есть вероятность, что никакого явного влияния вы не найдёте. Всё работает чётко и быстро, но продажи всё равно не очень большие. Тогда можно попробовать улучшить технически ту или иную часть, чтобы положительно повлиять на пользователей. Чтобы запланировать такие изменения, снова нужны метрики. Их тоже собирает продакт. Если их нет, можете намекнуть, что они должны быть. Возможно, что-то изменится к лучшему.
Итак, второй кандидат в «что делать» — это влияние на пользователей. В этой группе собраны действия, которые убирают боли пользователей, возникшие по нашей вине. Это позволит вам повысить нужные показатели и в конечном счёте увеличить прибыль от клиентов.
Третий кандидат — повышение продуктивности. Сюда можно отнести все улучшения, которые будут явно влиять на продажи. Например, если не заставлять пользователя каждый раз вводить адрес доставки или выбирать пункт выдачи, то он с большей вероятностью что-то купит, потому что потратит меньше времени на оформление заказа. Обратите внимание: эти изменения отличаются от тех, что попадают в категорию «влияние на пользователей». В первом случае пользователь жалуется на проблемы, мы их чиним. Во втором случае — мы по собственной инициативе делаем новые фичи или улучшаем UX.
Запросы бизнеса со временем растут. Значит, растёт и необходимость разрабатывать продукт быстрее и качественнее. Обновление технического стека может явно увеличить продуктивность, поэтому четвёртый кандидат — это уменьшение технических потерь.
Подведём промежуточные итоги. Чтобы достигнуть целей бизнеса, IT может предложить:
- Побороться с техническим долгом и сократить число технических инцидентов.
- Уменьшить боль пользователя от использования нашего продукта.
- Улучшить пользовательский опыт.
- Повысить свою эффективность и делать быстрее и качественнее.
Вспомним важное условие:
💡 Каждое направление изменений в техническом роадмапе должно быть напрямую связано с бизнес-целями компании.
В списке, который мы получили, нет немотивированных предложений. Обновление технологий нужно не для улучшения настроения у команды разработчиков, а для решения целей компании.
В нашем примере бизнес пришёл с конкретными болями и целями. Но так происходит не всегда.
Бывает, что у бизнеса уже всё отлично. Каких-то прорывов и новых фич не намечается. Текущую стратегию компании можно описать фразой «Пусть и дальше всё будет хорошо». В явном виде стратегия даже может отсутствовать. Есть ещё похожая ситуация: развития в компании особо нет, но бизнесу хотелось бы уменьшить затраты.
В этих ситуациях вы можете предложить бизнесу почти то же самое, что в примере с маркетплейсом. Уберём из списка направлений вещи, которые связаны с пользователями. Останется два пункта:
- Бороться с техническим долгом.
- Повышать свою эффективность.
Итак, мы обозначили направления, которые позволят прийти к успеху. Теперь разберём, что с этим делать и как выбрать «низко висящий фрукт».
Технический долг
Для начала расскажем, как выбрать относительно простые задачи, которые помогут эффективно достигать целей. Один из приоритетов, которые мы назвали для приложения маркетплейса, — это повышение удовлетворённости пользователей. Если говорить о счастье пользователей, то со стороны технологий так или иначе придётся говорить о техническом долге.
✏️ Технический долг, или техдолг, — это компромисс. Он может быть явным или неявным.
Устаревшие технологии, неэффективные методы управления разработкой, низкий уровень тестирования — всё это подходит под понятие компромисса. Если команда осознанно идёт на компромисс из-за разного рода ограничений (деньги, сроки, специалисты, железо), то мы говорим о явном компромиссе. К неявным компромиссам относят решения, которые принимают из-за недостатка знаний.
Виды технического долга
Выделяют десять видов технического долга.
- Архитектурный долг. В этом случае мы сознательно придумали, как сделать «на коленке», чтобы успеть. Например, представьте, что у фичи с бронированием товара для Q3 неправильно спланировали доступность. Команда торопилась, чтобы успеть выполнить план. Теперь это приводит к сбоям при отключении одного из центров обработки данных.
- Долги по кодовой базе. Они возникают из-за недостатка знаний, инструментария, стандартов и политик. Например, наша команда не знает, что уже есть эффективная реализация нужной нам функциональности. В итоге мы квартал изобретаем неэффективный алгоритм, который впоследствии будет регулярно падать в проде. Или оставляем рефакторинг на потом. В этом случае повторяющийся код обработки ошибок и исключений может привести к проблемам с рефакторингом и производительностью.
- Инфраструктурный долг. Он возникает отчасти из-за первых двух видов техдолга, отчасти из-за отсутствия наблюдаемости.Например:
- Избыточность ресурсов означает, что мы тратим лишние деньги.
- Взяли Serverless под большие нагрузки — тратим очень много денег и получаем просадки по производительности.
- Не подготовили disaster план — потеряли много денег при падении ЦОДа.
Теперь вы разбираетесь в видах технического долга. Но в реальности мало знать разновидности проблем. Важно понимать, как их выявить.
Как выявлять технический долг
Архитектурный долг можно собрать из ADR. Для этого проанализируйте инциденты и проблемы, с которыми сталкивается поддержка. Постарайтесь выявить и изучить причины падения скорости разработки. Исследуйте жалобы, которые озвучивает бизнес.
Проблемы с кодовой базой, дефекты, а также всё, что связано с качеством, обычно можно найти в баг-трекере или таск-трекере. Ещё полезно собрать сессию Event Storming или просто расспросить разработчиков и тестировщиков. Дополнительно помогают инструменты статического анализа типа SonarQube и различные линтеры и фаззеры, которые можно встроить непосредственно в пайплайн CI/CD. Также рекомендуем изучать жалобы пользователей и аномальные показатели мониторинга.
Вот основные направления для поиска технического долга:
Проблемы c документацией найти легче всего. Это те темы, по которым чаще всего приходят с вопросом «а как».
Чуть сложнее с процессным техническим долгом. Тут может помочь изучение инцидентов и аудита, если он есть. Ещё советуем выявлять лазейки через общение с командой. Важно понять, зачем обходят те или иные шаги. Тогда вы сможете модифицировать процесс или ограничить возможность такого обхода.
💡 Когда соберёте свои находки, вспомните: не всякий технический долг нужно отдавать здесь и сейчас. Полностью закрыть техдолг практически невозможно.
Проблемы технического долга нужно выявлять на постоянной основе. Когда вы их собрали, оцените техдолг и приоритизируйте его составляющие. Определите для решения те проблемы, которые влияют на бизнес-цели или в целом на жизнеспособность систем. Это самые злые кредиторы.
Зафиксировали: следующий пункт плана — оценка технического долга. К ней перейдём прямо сейчас.
Как оценить технический долг
Для оценки технического долга стоит использовать два способа. Первый даст приблизительную стоимость. Второй — поможет рассчитать коэффициент, который отражает, насколько всё плохо.
Первый метод — оценка стоимости
В качестве первого способа, например, можно использовать оценку проблем через инцидент-менеджмент. Если оценить ущерб от инцидентов, вы сможете наглядно показать финансовые потери.
Правда, с репутационным ущербом дела обстоят сложнее. Его можно оценить только приблизительно, даже если вы проводите анализ спустя какое-то время и опираетесь на метрики. Исключение составляют только случаи, когда из-за ухудшения репутации компания теряет все заказы и фактически уходит в простой.
Другой вариант оценки через инциденты — это анализ не ущерба, а экономии времени, которое команда потратит на инцидент в человеко-часах. В этом случае оценка может выглядеть так:
Не стоит забывать, что инцидент — это понятие относительное. Для кого-то инцидентом будет потеря миллионов рублей за минуту простоя. А для кого-то — полдня разработчика, который не смог подключиться к системе из-за устаревшей документации.
Второй метод — оценка критичности
Примером второго метода может быть коэффициент технической задолженности (TDR, Technical Debt Ration). Это достаточно грубый подход, но он хорошо работает как сигнал.
✏️ TDR = (стоимость устранения / стоимость разработки) * 100%
Стоимость устранения можно приблизительно оценить в человеко-днях. Если хотите пойти простым путём, можете использовать SonarQube — инструмент статического анализа. Ещё можно проанализировать типовые задачи, но это более сложный путь.
Допустим, договорились, что на исправление кодовой базы потребуется примерно 500 часов. Эти данные взяли из Sonar.
Стоимость разработки можно приблизительно рассчитать по такой формуле: время разработки одной строчки кода умножить на количество строчек.
Допустим, в кодовой базе 30 000 строк кода. Это выяснили c помощью инструмента cloc. Получаем: 500 / 30 000 = 0,016 часа на строку примерно по данным из Sonar. Посчитаем, сколько времени потребуется на написание 30 000 строк с нуля, например, по 5 минут на каждую. Получится: 30 000 * 5/60 = 2500 часов.
Соотношение 500:2500 — 1:5. В процентном соотношении это 20% ((1/5)*100 = 20). То есть TDR равен 20%.
Согласно методологии, коэффициент выше 5% говорит о проблемах.
В нашем случае мы используем TDR для составления роадмапа. Он помогает примерно представить, стоит ли покопать в эту сторону, чтобы внести работу над техническим долгом в общий план. В целом коэффициент лучше использовать на долгосроке для планирования миграций, рефакторингов и так далее.
💡 Чтобы обосновать запланированные работы в роадмапе, нужно расписать для бизнеса конкретное влияние того, что вы хотите исправить, на цели, которые перед вами стоят.
Например, у нас цель ― снизить количество технических инцидентов. Мы знаем общее количество инцидентов и причины каждого из них. Поэтому мы можем соотнести инциденты с техническим долгом.
Чтобы презентовать обоснование бизнесу, можно оформить расчёты так:
Человеческие ресурсы измеряем в часах, а железо — в рублях в месяц. Даже у внутреннего облака всегда есть прайс.
Приоритет выставляйте так, как считаете правильным. Можете воспользоваться одним из методов приоритизации. Мы рассказывали о них раньше в контексте разбивки монолита на микросервисы. Напомним несколько методов:
- MoSCoW (Must have, Should have, Could have, Won’t have). Помогает приоритизировать задачи по их значимости для проекта.
- RICE (Reach, Impact, Confidence, Effort). Оценивает задачи по их потенциальному охвату, результативности, достоверности оценок и требуемым усилиям.
- ICE (Impact, Confidence, Ease). Это упрощённая версия RICE.
- WSJF (Weighted Shortest Job First). Учитывает как ценность задачи для бизнеса, так и время, которое необходимо для ее выполнения.
В целом вы можете выбрать самое выгодное и быстрое направление работы, исходя из собственного опыта и особенностей компании. Это и будет самый низко висящий фрукт.
💡 Обратите внимание: в роадмап вносят не конкретные задачи, а только их собирательный образ.
Например, «решение проблем с производительностью» или «работа с техдолгом» — это хорошие варианты. А вот задача «исправить проблемы с БД для сервиса заказов» — неудачный выбор. Для роадмапа это слишком конкретная задача.
Итак, мы прошли по инцидентам и поговорили с командой. Теперь нужно составить список задач, приоритизировать их и отразить в роадмапе скоуп по одной из целей.
Пример
На этом этапе мы выделили направления работы, которые согласуются с двумя целями бизнеса из четырёх.
Продолжаем исследовать. У нас осталось ещё две цели:
- Q2: выпустить новую функциональность — пользователи бронируют товар на какой-то срок без изменения стоимости.
- Q3–Q4: выход на рынки Африки.
Для решения этих задач нам нужно будет подготовить инфраструктуру и проверить идеи в виде MVP.
С точки зрения технологий на коротком сроке нельзя резко всё поменять. Но, например, вы можете применить новую версию фреймворка, которая увеличит скорость разработки, или внедрить API Gateway. Всё зависит от текущих проблем, которые явно или косвенно влияют на бизнес.
Если вы сможете обосновать изменения, исходя из актуальных целей бизнеса, то их можно будет добавить в роадмап. Например, вы считаете, что API Gateway снизит нагрузку на настройку и поможет с масштабированием. А фреймворк даст возможность использовать новую версию языка с более качественным компилятором, что позволит увеличить производительность при выполнении.
Как и в случае с инцидентами, тут желательно рассчитать, сколько будет стоить внедрение. Разница только в том, что для инноваций нужно считать не экономию, а инвестиции.
Как выглядит готовый роадмап
Попробуем составить роадмап для нашего примера. Отразим в нём все приоритеты, которые удалось определить, и добавим работу над продуктом, потому что в реальности работа над ним состоит и из продуктовой, и из технической частей.
Также следует показать:
- примерную численность команд,
- процент их занятости,
- длительность занятости.
Для визуализации можно использовать диаграмму Ганта, презентацию, Miro или другие привычные вам инструменты.
Такой роадмап у нас получился:
Конкретные результаты по каждому кварталу лучше прописывать отдельно. Для нашего примера они будут выглядеть так:
Результаты Q1:
- Инфраструктурные компоненты обновлены и протестированы.
- Решены задачи-хвосты по UI и UX, проведены продуктовые оптимизации.
- Количество инцидентов снизилось на 3–5%.
- Часть команды начала работать над функционалом для запуска в Q4: прорабатывается MVP и функционал.
- Начато внедрение API Gateway для уменьшения связности и повышения эффективности взаимодействия и разработки.
Результаты Q2:
- API Gateway доехал до тестирования.
- Количество инцидентов снизилось ещё на 7–8%.
- Реализованы такие-то продуктовые «большие» истории.
- Проработан функционал и MVP.
- Начали в Q3 подготовку инфраструктуры к запуску в Q4.
- Начали в Q3 продуктовую разработку к запуску в Q4.
Результаты Q3:
- Завершена подготовка инфраструктуры к запуску в Q4.
- API Gateway в проде.
- Реализованы такие-то продуктовые истории.
- Продуктовая разработка завершена, всё готово к запуску и быстрой стабилизации.
Результаты Q4:
- Запуск состоялся. Инфраструктура и код стабилизированы.
- Проработали MVP для Q1 следующего года.
- Реализованы такие-то продуктовые истории.
Мы показали, как составить технический роадмап для оперативного планирования. В этом случае мы ставили задачи на год. Теперь перейдём к особенностям долгосрочного планирования.
Технический роадмап для долгосрочного планирования
💡 Если в случае оперативного роадмапа мы «тушим пожары», то в случае долгосрочного — окапываем рвы и покупаем огнетушители.
Это значит, что нужно:
- Провести инвентаризацию существующих инструментов. Определите всё программное обеспечение, аппаратное обеспечение и IT-системы, которые вы используете в настоящее время. Это поможет вам выделить то, что действительно заслуживает внимания в условиях ограниченности ресурсов.
- Оценить их эффективность. Проанализируйте, какие инструменты приносят пользу, а какие неэффективны. Для этого можно провести опросы разработчиков, инженеров поддержки и других заинтересованных ролей.
- Подумать про масштабируемость. Убедитесь, что существующие технологии могут масштабироваться в соответствии с планами развития компании.
В IT-ландшафте вашей компании, скорее всего, есть абсолютно разнородные инструменты — и по стеку, и по состоянию.
Вернёмся к примеру маркетплейса. Допустим, его архитектура выглядит так:
Если при оперативном планировании мы исходим от сиюминутных задач, то при стратегическом — опираемся уже на долгосрочный курс организации. Это значит, что вам нужно выявить потребность в той или иной технологии или системе в будущем. Например, странно занимать разработчиков обновлением системы складского учёта, которую в перспективе заменят, потому что бизнес планирует переходить на другой стандарт отчётности.
💡 Для долгосрочного планирования нужно хорошо представлять как IT-ландшафт, так и цели бизнеса.
Опишем и то, и другое для кейса маркетплейса.
Архитектура состоит из семи компонентов:
- Корзина. Сервис на Java, ему 10 лет, постоянно дописывается и чинится. Достаточно нестабилен под нагрузкой, технологии периодически обновляются в виде апдейтов фреймворка и языка.
- Склад. Сервис на C#, написан давно, плохо интегрируется, легаси, трудности с отчётностью.
- Сайт. Свежий, сделан на последних технологиях.
- Биллинг. Стабильный сервис на Java, давно написан, почти не требует каких-то доработок.
- Служба логистики. Это отдельная группа сервисов. В основном — недавно написанные монолиты для работы с курьерами.
- CMS. Кастомизированная CMS на PHP, очень старая, не переваривает новые форматы и с трудом поддаётся починке. Но она не под нагрузкой и её простой не грозит миллионными убытками.
- Инфраструктурные сервисы. Простой CI/CD на Gitea и Jenkins, полуручная выкладка в прод. Мониторинг на Zabbix и логирование на ELK.
В ближайшие несколько лет бизнес планирует:
- Активно развивать сервисы доставки: открыть до 1000 пунктов выдачи, в том числе через партнёров, и нанять 200 курьеров.
- Увеличить DAU и GMV на N%.
- Закрепиться на рынке Африки. Доля год к году должна расти на 10%.
- Проработать возможность запуска ещё одного бизнеса. Это продажа автомобилей.
- Создать экосистему для B2B-покупателей.
Чтобы начать формулировать планы для роадмапа, нужно выбрать области или конкретные системы для развития и борьбы с техническим долгом на длительном промежутке времени. Для этого можно использовать метод TIME от Gartner.
Модель TIME
✏️ Модель TIME — это метод оценки и классификации приложений на основе их технической и функциональной пригодности для организации.
Техническая пригодность относится к качеству приложения, его поддерживаемости и совместимости с другими системами.
Функциональная пригодность означает, насколько хорошо приложение соответствует бизнес-возможностям компании и поддерживает их.
Модель TIME построена на четырёх квадрантах: Tolerate, Invest, Eliminate, Migrate. Каждый из них предлагает стратегию по управлению приложением. Вместе они выглядят так:
Разберём каждый квадрант по порядку.
T — Tolerate
К этой категории относятся приложения, которые имеют высокую техническую пригодность, но низкую функциональную пригодность. Стратегически они не имеют высокой ценности, но остаются технически пригодными. Их удаление или изменение — это не приоритет. Такие приложения зачастую остаются в текущем состоянии, несмотря на их ограниченный вклад в достижение бизнес-целей.
Решение о том, стоит ли использовать приложение, часто зависит от затрат и усилий, которые необходимы для его замены или обновления. Если эти факторы перевешивают преимущества от изменений, приложение используется до тех пор, пока не наступит более подходящее время для работы над ним.
I — Invest
Это самые полезные приложения. У них высокая техническая и функциональная пригодность. Такие приложения являются неотъемлемой частью деятельности организации и вносят значительный вклад в достижение бизнес-целей.
Решения об инвестициях в такие приложения принимают на основе их потенциала для повышения ценности бизнеса. Это может быть повышение эффективности, расширение функциональности или возможность поддерживать новые бизнес-инициативы.
Инвестиции могут включать в себя обновление приложения, расширение его использования в организации или более тесную интеграцию с другими системами.
M — Migrate
Это приложения с низкой технической совместимостью, но высокой функциональной совместимостью. Типичный легаси, на котором исторически строится весь бизнес.
Решение о переносе приложения обычно принимается из-за необходимости повысить техническую производительность, сократить расходы или лучше соответствовать IT-стратегии организации.
E — Eliminate
Это приложения, которые попадают в категорию «удалить». У них низкий уровень технической и функциональной совместимости. Такие приложения плохо работают и больше не соответствуют бизнес-процессам. Их необходимо удалить из портфеля приложений.
Чтобы распределить приложения по квадрантам, можете воспользоваться схемой:
Необязательно использовать именно это дерево решений. Вы можете добавить сюда свои вопросы или самостоятельно сформировать критерии. Подойдёт любой способ, который позволит вам распределить приложения по этим четырём категориям.
Например, можно проставить баллы по техническим категориям. Пусть 0 — это минимальный результат, а 50 — максимальный. Для примера возьмём три сервиса из маркетплейса и оценим их по пяти критериям:
Такой же подсчёт сделаем для бизнесовых показателей:
Соотнесём результаты с критериями TIME и получим такую картину:
Получается, что склад нужно либо мигрировать (пограничное состояние), либо выкинуть. С учётом планов бизнеса и перехода на новый стандарт отчётности стоит запланировать миграцию. В корзину и сайт нужно инвестировать — здесь лечим технические долги.
Такую процедуру необходимо проделать с каждой из систем. В результате вы сформируете технические проекты, которые можно отметить в плане развития.
Что ещё следует учесть? Допустим, мы хотим сделать мобильное приложение рядом с сайтом или реализовать много интеграций. Дополнительно рассматриваем инфраструктурные сервисы, которые сложно оценить с бизнесовой точки зрения, но которые должны обеспечивать потребность продуктовых сервисов и повышать эффективность. Например, мы видим, что рынок будет расти, будет расти DAU и сложность разбора проблем. Поэтому в качестве инвестиции мы закладываем реализацию трейсинга, покупку железа и заезд ещё в один ЦОД.
Постепенно так вы создадите для бизнеса целостную картину развития технического ландшафта на несколько лет вперёд. При этом каждое направление необходимо периодически актуализировать в соответствии с изменениями бизнеса. Ещё важно помнить: как и в случае с оперативным планированием, каждое направление из этого роадмапа должно иметь обоснование выгоды. Это может быть потенциальная выгода (инвестиция), экономия или минимизации ущерба.
В следующем уроке мы разберём инструменты, с помощью которых можно управлять технологиями и инновациями. А сейчас — предлагаем вам закрепить теорию, выполнив несколько заданий, и подвести итоги этого урока.
Итоги
- Технический роадмап позволяет бизнесу понять, что, когда и почему будет происходить с IT-системами. Его можно создать для оперативного планирования (срок — до года) и для долгосрочного (стратегического) планирования.
- Чтобы выделить направления работы для роадмапа, изучите бизнес-цели компании. Ваши планы должны напрямую работать на их достижение. Если вы готовите роадмап для оперативного планирования, для вас могут быть актуальны четыре фокуса: обновление технологий, влияние на пользователей, повышение продуктивности и уменьшение технических потерь.
- Если говорить об удовлетворённости пользователей, то со стороны технологий так или иначе придётся говорить о техническом долге. Технический долг, или техдолг, — это компромисс между тем, что нужно сделать, и что получилось сделать. Он может быть явным или неявным. Явный компромисс — это когда команда осознанно идёт на компромисс из-за разного рода ограничений (деньги, сроки, специалисты, железо). К неявным компромиссам относят решения, которые принимают из-за недостатка знаний.
- Выделяют десять видов технического долга: архитектурный долг, долги по кодовой базе, инфраструктурный долг, долги по качеству программного обеспечения, процессный долг, дефектную задолженность, задолженность по документации, известную или преднамеренную задолженность, неизвестный устаревший или случайный долг и технический долг, вызванный «битовой гнилью» или «костылями». Ещё мы обсудили, какие источники позволяют проблемы каждой из этих категорий.
- Чтобы оценить технический долг, стоит использовать два способа: оценку стоимости решения проблем и оценку их критичности. Для расчёта первого показателя можно использовать инцидент-менеджмент. Для второго — коэффициент технической задолженности (TDR, Technical Debt Ration).
- Когда вы определите стоимости решения технических проблем и их критичность, нужно будет составить список задач, приоритизировать их и отразить в роадмапе скоуп по одной из целей. В роадмап вносят не конкретные задачи, а только их собирательный образ.
- Если при оперативном планировании мы исходим от сиюминутных задач, то при стратегическом — опираемся уже на долгосрочный курс организации. Это значит, что вам нужно выявить потребность в той или иной технологии или системе в будущем. Для этого проведите инвентаризацию текущих инструментов, оцените их эффективность и подумайте про масштабирование. Чтобы начать формулировать планы для роадмапа, нужно выбрать области или конкретные системы для развития и борьбы с техническим долгом на длительном промежутке времени. С этим поможет метод TIME.