4 этапа понимания и определения приоритетов работы по сокращению долга

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

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

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

На протяжении многих лет я работал со многими превосходными инженерами и архитекторами, с которыми мне «нравились» эти дискуссии. Хотя, вероятно, были времена, когда мы были близки к тому, чтобы бросить вещи, в конечном итоге мы успешно объединились, чтобы проработать это, и (насколько мне известно) мне удалось остаться друзьями со всеми ними. Ключом к решению проблемы - как оказывается, к большинству сложных проблем в жизни - было общение.

Что такое технический долг? Обязательно ли брать технический долг - это плохо?

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

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

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

Что делает обсуждение технического долга таким трудным?

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

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

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

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

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

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

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

4 этапа приоритезации проектов по сокращению долга

  1. Первым шагом в реализации вашей программы сокращения долга является классификация проектов-кандидатов по категориям, указанным в синих кругах. Обычно эти проекты-кандидаты исходят от самой группы инженеров, поскольку они лучше всего осведомлены о том, где и в какой форме существует задолженность.
  2. Затем убедитесь, что все понимают, как каждый проект-кандидат действует с помощью механизмов, описанных в серых кругах, для улучшения бизнес-результатов, указанных в зеленых кругах. Это важно по крайней мере по двум причинам: а) это повышает доверие к бизнес-заинтересованным сторонам, которые часто не понимают проекты-кандидаты или то, как они действительно приносят пользу клиентам, и б) деконструкция источника выгоды помогает дифференцировать проекты, которые в противном случае могут быть трудно расставить приоритеты, потому что все они приводят к одним и тем же общим преимуществам (т. е. «более высокий технический результат» или «более высокое качество»).
  3. Используйте столько данных, сколько вы объединили с коллективным суждением, для ранжирования каждого проекта в соответствии с его ожидаемым влиянием на бизнес-результаты. Обратите внимание, что может быть очень сложно количественно точно определить, насколько улучшится данный проект по выбранным вами ключевым показателям эффективности (например, Net Promoter Score, количеству ошибок и т. Д.). Это нормально, потому что часто бывает достаточно знать относительную выгоду проекта по сравнению с другими кандидатами. Есть много вариантов того, как это можно сделать, но, например, даже простая оценка воздействия на бизнес по шкале от 1 до 5 может быть эффективной для ранжирования выгод проекта по относительной шкале.
  4. Наконец, оцените стоимость каждого рассматриваемого вами проекта и сравните ее с ожидаемой выгодой. Опять же, существует множество вариантов того, как это сделать, но главное - найти максимальное соотношение выгоды и затрат. Например, вы можете разделить оценку на шаге 3 на ваши затраты (независимо от того, измеряете ли вы затраты в виде очков истории, человеко-дней или спринтов) и ранжировать в соответствии с этим показателем «рентабельности инвестиций». В качестве альтернативы вы можете настроить два на два, как показано ниже, что помогает расставить приоритеты для проектов на более концептуальном уровне, что полезно, когда ваши данные могут не обеспечивать высокую степень точности.

Основные виды инвестиций в сокращение долга

  • Сокращение кода и рефакторинг: устранение ненужных функций для конечных пользователей и инвестиции в переписывание существующего кода, чтобы сделать его более простым и эффективным, например, переписывание библиотек, запросов или перепроектирование баз данных. В идеале это также будет означать превращение интегрированных функций в формально разделенные общие службы, как в сервис-ориентированной архитектуре (SOA).
  • Общие технологии. Инвестиции в многоразовые и, по возможности, общедоступные технологии для замены проприетарных или специализированных библиотек. По мере развития технологий то, что когда-то требовало собственного решения, теперь может стать общедоступным. Эти инвестиции также могут привести к созданию формальных общих служб в рамках подхода SOA.
  • Покрытие автоматизированным тестированием. Инвестиции в расширение покрытия автоматизированным тестированием. Часто команды автоматизируют некоторую часть программного обеспечения, но не все. Увеличение покрытия сократит время, необходимое для выполнения полного регрессионного теста, и уменьшит вероятность устранения дефектов.
  • Инженерные операции: инвестиции в непрерывную интеграцию, автоматизацию выпусков, автоматизированный мониторинг, а также командные инвестиции в коммуникацию, документацию и совместную работу (иногда вместе именуемые DevOps).
  • Постоянное улучшение. Инвестиции в сокращение существующего количества дефектов наряду с другими превентивными стратегиями, упомянутыми выше.

Оценка выгод для бизнеса

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

  • Более высокое качество платформы. Существует множество хорошо задокументированных показателей качества, но некоторые из наиболее распространенных - это подсчет дефектов по серьезности, в том числе отдельное отслеживание новых и регрессионных подсчетов и скорости отклика интерфейса конечного пользователя.
  • Повышение уровня удовлетворенности клиентов. Это связано как с более высоким качеством платформы, так и со способностью инженеров создавать больше новых возможностей продукта. Общие KPI для удовлетворенности клиентов включают Оценка чистого промоутера, Оценка удовлетворенности клиентов, Оценка усилий клиентов и показатели удержания / оттока.
  • Снижение затрат на поддержку. Это связано с более качественной платформой. Ключевые показатели эффективности должны быть нормализованы, чтобы отражать объем клиентов, например количество заявок на клиента в день, возможно, сгруппированные по степени серьезности. (Что касается расходов на поддержку, имейте в виду, что выбранные вами KPI не выглядят лучше, когда поддержка недофинансируется, например, «общий объем инвестиций на одного клиента», что будет вводить в заблуждение.)
  • Повышение результативности разработки. Измерение продуктивности разработки программного обеспечения, как известно, сложно, если не невозможно, и я не пытаюсь сделать это в этой статье (просто погуглите как измерить производительность программного обеспечения »и просмотрите некоторое время, чтобы Поймите, что я имею в виду!) Основная причина этого заключается в том, что, хотя ввод ясен - часы инженерного времени - на самом деле нет общих единиц вывода, которые вы могли бы измерить и сравнить с течением времени или между командами, то есть нет двух функций или продукты такие же. Но все мы интуитивно знаем, что продуктивность не одинакова во времени или в разных командах. Оказывается, зачастую легче измерить объем потерь, например, сколько времени требуется для выполнения полного регрессионного теста или сколько времени требуется для развертывания кода в производственной среде. Таким образом, установка KPI на основе этих вещей и стремление к сокращению потерь - довольно хорошие прокси для повышения производительности труда, если вы готовы верить, что команда не будет просто так долго обедать с экономией времени!

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