Гарантирует ли Team Ramp Up увеличение скорости разработки?
Опубликовано: 2020-03-28Одним из ключевых моментов при наращивании команд для увеличения скорости выпуска является передача ясности от продуктовых команд к спринтерским командам.
Плавное выполнение спринта — это результат заметного вклада как продуктовой, так и спринтерской команд.
Философия «Правильно с первого раза» (FTR) помогает всем членам команды достичь общей цели.
Когда стартапы переходят из ранней стадии в стадию роста, их приоритеты существенно меняются. Среди всех прочих приоритетом является скорость функциональности, которая играет решающую роль в их стремлении к росту.
Основатель стартапа с посевным финансированием, с которым я работал, недавно поднял раунд серии А, попросил меня удвоить команду инженеров, чтобы через шесть месяцев выпустить новые функции. Однако является ли это единственным существенным фактором сокращения времени цикла? Чтобы ответить, я решил обратиться к игнорируемым аспектам этого распространенного «неправильного представления».
Хотя ресурсная мощность является одним из важнейших факторов, обусловливающих частые выпуски в производство, само по себе это не может гарантировать сокращение времени цикла. Создавая продукты для более чем 16 стартапов, я несколько раз был свидетелем перехода от ранней стадии к стадии роста. Исходя из этого опыта, вот несколько важных факторов, которыми я делюсь с основателями стартапов.
Передайте ясность: главное сверху вниз
Одним из ключевых моментов при наращивании команд для увеличения скорости выпуска релизов является передача ясности от продуктовых команд к спринтерским командам. Когда спринт начинается с неопределенности или не имеет достаточного количества историй для начала, это отрицательно сказывается на коэффициенте выполнения спринта. Расплывчато определенные истории или включение задач в середине спринта замедляют темп, в результате чего спринтерские команды не выполняют запланированные задачи.
Плавное выполнение спринта — это результат заметного вклада как продуктовой, так и спринтерской команд. Команда продукта может сыграть свою роль, подготовив и предоставив дорожную карту команде спринта, по крайней мере, на квартал, чтобы команда могла соответствующим образом спланировать свои результаты.
С другой стороны, спринтерская команда должна постоянно подталкивать продуктовую команду к получению бэклога продукта и еженедельно/раз в две недели обрабатывать его, чтобы обеспечить целенаправленную поставку.
Автоматизируйте выпуск «без ошибок»
«Эффективность — это делать все правильно; эффективность заключается в том, чтобы делать правильные вещи». — Питер Друкер
Когда вы думаете об автоматизации, это пример последней категории. В тот момент, когда разработка функций набирает скорость, весьма вероятно, что производство остановится, если не будут внедрены правильные процессы. Если продукт недостаточно стабилен для разработки новых функций, ваша команда тратит больше времени на устранение проблем, чем на создание новых функций. Следовательно, ваша инженерная скорость снижается.
Именно здесь на сцену выходит CI/CD (непрерывная интеграция и непрерывное развертывание). Здесь исчерпывающее покрытие модульных, интеграционных и автоматических тестов гарантирует, что все поставляемое не сломает систему.
Рекомендуется для вас:
Как платформа агрегатора учетных записей RBI предназначена для преобразования финансовых технологий в Индии
Предприниматели не могут создавать устойчивые масштабируемые стартапы с помощью Jugaad: Cit...
Как Metaverse изменит индийскую автомобильную промышленность
Что означает положение о борьбе со спекуляцией для индийских стартапов?
Как стартапы Edtech помогают повысить квалификацию рабочей силы Индии и стать готовыми к будущему ...
Технологические акции нового века на этой неделе: проблемы Zomato продолжаются, EaseMyTrip публикует...
Не стройте больше, иначе вы больше сломаете
Переделка серьезно снижает производительность и может быть результатом различных факторов, таких как нечетко определенные истории, отсутствие тестирования разработчиков, недостаточное покрытие тестами и так далее. Переделка может снизить производительность, так как потребует времени и усилий QA-инженеров при тестировании и регрессе, разработчиков при отладке и менеджеров релизов при повторном выпуске.
Небольшое замедление может помочь вашей команде работать быстрее и повысить ценность, поскольку эффективная скорость всегда приносит больше пользы, чем просто скорость.
Философия «Правильно с первого раза» (FTR) помогает всем членам команды достичь общей цели — создания надежного и стабильного кода с первого раза. Всегда полезно потратить дополнительное время на определение качества кода, а не торопиться, а затем застрять на доработках.
Некоторые из проверенных способов улучшить соотношение FTR — это регулярная обработка невыполненных работ, повторение историй, регулярные демонстрации менеджерам по продукту. Вместо того, чтобы просто собирать требования, спринтерская команда должна больше сосредоточиться на их прояснении, чтобы улучшить коэффициент FTR.
Структурируйте свою команду для параллельных спринтов
Когда у вашего стартапа небольшая продуктовая команда, каждый в основном работает над одной или двумя функциями одновременно (как правило, это применимо для команды из 4-6 человек). Однако по мере того, как возрастает потребность в предоставлении нескольких функций, настоятельно рекомендуется сформировать несколько подгрупп с отдельными областями деятельности. Таким образом, каждая подкоманда запускает свой спринт и определяет свою дорожную карту.
По сравнению с одной большой командой небольшие команды, рожденные в рамках «логического разделения», более эффективны и дают лучшие результаты. Отдельные группы для микросервисов, разные линейки продуктов и различные компоненты — вот лишь несколько примеров подхода «логического разделения».
Во время реструктуризации всегда важно включить хотя бы одного члена из прежней основной команды в каждую из этих подгрупп для поддержания ДНК. Хотя межгрупповая координация поставок влечет за собой дополнительные накладные расходы, это оправданный компромисс.
Отслеживайте использование функций вместе со скоростью
Пользовательский опыт — самый важный показатель для измерения успеха новой версии функции. По мере того, как вы начинаете быстро предоставлять несколько функций, пользовательский опыт часто отходит на второй план. Когда ваш продукт имеет ограниченные возможности, взаимодействие с пользователем продолжает оставаться гладкой непрерывной кривой.
Однако, когда вы начинаете выпускать новые функции, велика вероятность того, что пользователи будут перегружены и это повлияет на их опыт.
Чтобы добиться лучшего принятия пользователями, отслеживание вовлеченности пользователей вместе со скоростью работы функций по-прежнему остается лучшим способом продвижения вперед. В то время как всестороннее исследование пользователей является одним из проверенных способов, другие важные методы сначала развертываются для выбранных пользователей с помощью флагов функций, AB-тестирования и отслеживания пути пользователя (с помощью амплитуды или аналогичных инструментов аналитики) после каждого нового выпуска.
Не теряйте основных членов
Это может быть очень часто игнорируемый аспект, но он остается очень важным. Небольшие команды не обязательно нуждаются в процессах и имеют гибкую структуру, а голос каждого слышен. Когда эти команды переходят в состояние, когда процессы настроены и добавляются новые инженеры и функциональные члены, здоровое управление — единственный способ избежать хаоса.
По мере того, как ваша команда инженеров успешно расширяется, для постоянной поддержки команды инженеров необходима хорошо подготовленная команда разработчиков. Отток становится неизбежным, когда у членов команды нет значительной работы, но ни один стартап никогда не захочет терять своих основных членов. В этом случае высшее руководство имеет ключ к обеспечению хороших отношений с людьми и хорошему пониманию динамики.
Уроки, которыми я здесь поделился, основаны на многолетнем опыте работы с несколькими стартапами. Я ожидаю, что это будет полезно для основателей стартапов, у которых уже много дел, и они не будут в конечном итоге изобретать велосипед.