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

Мне кажется, что в любой компании, деятельность которой как-то связана с IT, отдел разработки является двигателем бизнеса. Leadership team дает направление движения и прокладывает основные координаты, а development дает тягу и мчит компанию в хорошем случае вперед, по проложенному маршруту. Ну или в некоторых случаях куда-то еще. Мы называем наш development процесс и команду Warp Drive, и в этой статье я расскажу про то то, как он построен и про основные принципы его работы.

Для начала картинка, основных составляющих нашего движка. Упрощенная схема выглядит примерно так:

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

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

В целом процесс, по которому мы идем основан на agile практиках. На вход в двигатель поступают требования от бизнес\команды руководства. Это то, что впоследствии будет преобразовано в составляющие конечного продукта, фичи и апдейты. Раз в 2 недели мы проводим Warp Jump (Sprint Planning) где истории назначаются на конкретных людей в команде и мы идем по стандартному 2-х недельному спринту. В результате прыжка в продукте появляются новые фичи, и они потихоньку накапливаются в Dev Environment. Там они проходят проверку качества, и затем деплоятся на Prod. Для простоты Staging/QA environments в нашей схеме пропущены.

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

Итак - желтые фичи находятся в состоянии квантовой неопределенности. Все новые фичи, которые появились в Dev начинают с этого состояния. Это означает, что на данный момент, мы не имеем точного представления о том, является ли эта фича полезной конечному пользователю, или же она только отвлекает\не работает\работает не как надо\не используется. Ответы на эти вопросы мы можем получить только после того, как фича была задеплоена на Prod Environment и мы увидели обратную связь от пользователей. Если пользователь доволен - фича переходит к подтвержденно-хорошее состояние (зеленая), если что-то не так - подтвержденно-плохое состояние (красная) и должна быть либо отправлена на доработку, либо удалена из системы.

Синие фичи, это Technical Debts, т.е. те улучшения, которые девелопмент команда запланировала сделать для своей собственной эффективности. Это может быть или улучшение инфраструктуры проекта, или архитектурный рефакторинг, либо что-то еще. Т.к. участники Warp Drive сами являются заказчиками Tech Debts и мы знаем, что конкретно мы хотим, то такие фичи не проходят через фазу квантовой неопределенности и поэтому классифицируются отдельно от бизнес фич\требований и обычно просто соответствуют состоянию Confirmed Good. В целом процесс перестроения и патчинга двигателя на полном ходу с помощью Tech Debts завораживает, но я думаю все мы в IT индустрии к этому уже давно привыкли.

Далее пройдемся по деталям и поговорим про анатомию одной конкретной фичи.

Из чего же состоит одна фича на нашей схеме? Во первых в нее входят затраты времени на сбор требований и понимание того, какой мы видим ту или иную функцию. Затем, перевод требований в истории, которые непосредственно пойдут в разработку и их приоритизация. Дальше идут Front-End/Back-End development, иногда подключаем DevOps, если нужно еще и environment докрутить. Затем идут затраты на тестирование/QA. И еще один пункт, это поддержка того, что уже работает в Prod.

Для наглядности, развернем эту картинку на полосу конвейера конвертации топлива warp drive(времени) в одну фичу.

Затраты на реализацию одной фичи у нас делятся на 2 типа: повторяющиеся (на схеме отмечены звездочкой), и неповторяющиеся. Для простоты будем считать, что собирать требования, разбивать на истории, проводить backend/frontend development нам нужно только один раз за жизненный цикл фичи. В то же время есть повторяющиеся операции, которые скорее всего понадобится делать снова и снова, уже после того, как данная функция была выпущена в PROD environment. Такими операциями могут быть тестирование, поддержка, иногда конфигурация среды и прочие сервисные штуки.

Таким образом мы получаем, что каждый раз, когда мы релизим что-то в PROD, за счет повторяющихся составляющих фичи, мы увеличиваем операционную стоимость нашего продукта. Если один релиз скорее всего пройдет незаметно, то релизы множества различного функций со временем накапливаются и начинают работать законы масштабируемости. И, как мы обсуждали ранее, не все фичи одинаково полезны. Одним из побочных эффектов нашего Warp Drive являются фичи в Confirmed Red State(красные). Если мы оставляем в системе красные фичи, которые не несут полезной функциональной нагрузки, они не просто увеличивают кодовую базу приложения, но и прибавляют к стоимости поддержки всего продукта. Если не обращать на этот фактор внимание, со временем продукт обрастает функциями, которые не нужны пользователю, и за него еще и платить нужно все больше и больше. И поэтому это очень важно, для поддержания эффективности продукта с точки зрения usability и операционной стоимости стараться держать положительный баланс зеленых фич приложения, и конечно же избавляться от красных. Именно для этого мы держим постоянный контакт с конечными пользователями и требуем от них обратной связи на те или иные функции. Это является частью нашего feature management process.

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

Здесь мы видим соответствие участников процесса технологиям, которые используются для разработки фич, таким как front-end development, back-end development, support, requirements gathering, и т.д. Нет, процентные показатели на данной диаграмме это не опыт участников в какой-то технологии. Это количество внутренней энергии и заинтересованность человека в чем-то. Например, если мы дадим Василию ковырять Front-End, наверное не стоит ожидать от него супер продуктивности, просто потому что у него с этой частью как-то не сложилось и он оценил свою вовлеченность в эту область в 10%. Василий предпочтет настроить вместо этого базу данных и будет при этом работать с высокой отдачей, потому что это та деятельность, которая ему нравится, и которая наполняет его энергией.

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

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

https://brandoncwhite.com/startup-podcast-build-business-brandon-straight-talk-for-entrepreneurs/

Спасибо за внимание.