Разработка продукта с нуля. Взгляд деливери менеджера
Меня зовут Евгений Нестеренко, у меня более 14 лет опыта в IT. Начинал я как Software Engineer, работал на позициях Senior, Team и Tech Lead в разных компаниях. В 2008 году после года работы в США как Software Engineer я вернулся и с тех пор работаю с EPAM. Здесь я занимал позиции Team и Tech Lead на проектах для разных клиентов, последние четыре-пять лет играю роль деливери менеджера.
Уже около года мы работаем над проектом для крупного американского холдинга, среди основных направлений которого финансовые сервисы. Это уникальный облачный SaaS продукт, построенный на новой для нашего клиента технологической платформе.
В этой статье хотелось бы рассказать о нашем опыте, с какими сложностями столкнулись в процессе работы над продуктом, и как их преодолевали.
Команда EPAM, которая работает над проектом
Бизнес-домен
Наша команда разрабатывает B2B продукт для автоматизации бизнес-процессов компаний — Workflow. Любой бизнес сталкивается с проблемой оркестрации своих процессов. Пример такого процесса — аудит подразделения компании. Процесс аудита можно представить как последовательность операций. Некоторые из операций проходят автоматически, с помощью тех или других программных инструментов, другие выполняются соответствующими специалистами. Набор и последовательность действий также меняются со временем, например, при изменении законодательной базы или правил, которые регулируют аудит.
Соответственно, у клиента и его пользователей возникла необходимость в продукте, который позволит создавать бизнес-процессы, визуализировать их и быстро изменять. Также важно иметь наборы готовых шаблонов, с помощью которых можно быстро подключать новых клиентов.
С точки зрения конечного потребителя (в нашем случае это другие компании) — это multitenant Software as a Service веб-приложение. В нем пользователи видят процессы и их статусы, задачи, ответственных за них сотрудников, некий репортинг и графики. У приложения также есть интеграции с рядом индустриальных систем.
На данном этапе продукт заточен под конкретный бизнес, но проектировался он так, чтобы в дальнейшем его можно было использовать и в других сферах.
Украинская команда отвечает за все аспекты разработки продукта: от бизнес-аналитиков, UX/UI-дизайнеров, самой разработки и тестирования до DevOps-инженеров, которые обеспечивают деплоймент в облако, и менеджмента. Наша команда также отвечает за архитектуру — ведущий Architect работает из Днепра.
Начало работы
Вовлечение EPAM в проект началось с весны прошлого года. У клиента была своя небольшая команда разработки на западном побережье США. Сперва нас привлекли для помощи с UX и визуальным дизайном, затем понадобились консультации по front-end. Клиент увидел, что украинская команда качественно и в срок справляется с задачами и принял решение расширить коллектив в Киеве.
Рост команды
Осенью прошлого года бизнес осознал, что текущими на тот момент темпами проект выйдет на рынок слишком поздно, поэтому было принято решение существенно расширить масштаб разработки в Киеве. Были созданы две Scrum-команды, кроме имеющегося UX/UI-стрима. Команды были сформированы за очень короткий срок — около 1,5 месяцев. Для организации эффективного и быстрого knowledge sharing несколько разработчиков и продакт-оунер клиента приехали в Киев в наш офис. Одной из первых задач новых команд было проведение feature breakdown и high level estimation exercise.
Как и многие другие распределенные команды, мы столкнулись с проблемой эффективной работы в разных временных зонах. Например, у нас разница составляет 10 часов. Тут очень важно желание заказчика идти навстречу командам разработки, которые находятся в другой временной зоне. Мы вместе с заказчиком составили расписание встреч таким образом, чтобы иметь перекрытие по времени около
Взаимодействие с заказчиком
Создание нового продукта, который будет востребован конечными пользователями, — это один из основных вызовов. Несмотря на то, что клиент знает потребности своих пользователей, для которых создается приложение, всегда остается риск того, что что-то не учтено и продукт «не взлетит».
Процесс разработки у нас начинается с UX. Наш UX-лид работает на стороне клиента и постоянно встречается с конечными пользователями: ездит по их офисам, показывает приложение, собирает отзывы, участвует в регулярных воркшопах с пользователями. На основе этих отзывов формируется high level backlog. Далее происходят сессии, где участвуют UX-специалисты, продакт-менеджеры со стороны заказчика и бизнес-аналитики. Это очень важный этап. Часто приходится пройти несколько итераций создания mockups, wireframes, прежде чем будут финализированы концепции и все стороны согласятся с результатом. Порой заказчику нужно увидеть мокапы страниц, прототипы, чтобы понять, куда двигаться дальше, работает ли та или иная идея. Когда мокапы финализированы, они прикрепляются к соответствующей story, которые команда разработчиков может взять в работу.
Надо отметить, что кроме feature stories очень важно учитывать и разгребать технический долг — работа, которая не дает immediate business value, но которая тем не менее очень важна, чтобы создавать надежный, масштабируемый, легко поддерживаемый продукт. Это ответственность архитектурной команды, и для этой работы в нашей системе хранения требований используются соответствующие теги.
О технологиях и некоторых проблемах
Front-end приложения построен на фреймворке Aurelia и JavaScript ES2016. Для back-end мы используем .NET Core REST Services. Учитывая, что данный проект требует визуализации бизнес-процессов, очень большую роль играет дизайн UI и UX. Мы используем подходы Material Design и Atomic Design, которые позволяют создавать и использовать повторно многие компоненты UI.
В процессе работы над новым продуктом наша команда столкнулась с огромным количеством интересных проблем и задач, которые нужно было решить в короткие сроки. Например, вскоре после того как development был передан в Киев, мы поняли, что необходимо полностью заменить data storage в приложении. Graph database, изначально выбранная для прототипа, не отвечала нашим задачам по таким критериям, как быстродействие, надежность, наличие детальной документации. Было решено заменить graph database на связку document oriented Cosmos DB и SQL + Entity Framework. В процессе замены продолжался активный feature development, поэтому рефакторинг пришлось производить в отдельной ветке.
По ряду причин мы отказались от альтернативных подходов, таких как feature toggling, для данного рефакторинга. Кто имел опыт с масштабным рефакторингом и интеграцией долгоживущих веток на активно развивающемся проекте, поймет трудности, с которыми пришлось столкнуться. Тем не менее, несмотря на сложности, благодаря правильному планированию и инвестированию в unit/integration testing нам удалось достаточно быстро провести замену data storage с минимальным количеством регрессионных багов.
Чтобы добиться хорошего быстродействия приложения, нам приходится решать много интересных и трудных задач. Были внедрены несколько сложных стратегий кэширования, оптимизирован код приложения, реализована буферизация запросов, фильтрация и сортировка данных на клиенте заменена на серверную и т. д. Надо отметить, что работа над оптимизацией быстродействия была бы невозможна без создания развитой DevOps-инфраструктуры — систем логирования и мониторинга. Для этих задач в нашем проекте используется ELK stack (Elastic Search, LogStash, Kibana).
Также оптимизация работы приложения невозможна без глубокого понимания облачной архитектуры. Например, мы столкнулись с зависаниями приложения, которые происходили время от времени в некоторых тестовых средах. Оказалось, что по умолчанию виртуальные машины нашего облачного провайдера имеют только один CPU Core, и когда запускается сборка мусора, обработка всех остальных запросов приостанавливается, что и приводило к этим странным зависаниям в приложении.
Создание правильной культуры
Как деливери менеджер я отвечаю за все аспекты Delivery: создание команд и формирование их структуры, построение процессов разработки и успешность продукта в целом. Я отношусь к Agile DMs и не являюсь сторонником command and control culture, которая присуща waterfall-проектам с их следованием предписанным процессам и документам. Все это большой механизм, где каждый человек — это винтик, он не понимает свою значимость. У нас как раз все наоборот. Мы создаем так называемые автономные команды, agile cross-functional teams, с достаточно плоской организационной структурой, где люди работают вместе над общим результатом.
В команде очень важно создать правильную культуру. Культура — набор неписаных правил и рецептов, которым следует команда, и в Agile-мире культура более важна, чем набор формализованных правил и формальный процесс. Мы создаем культуру, направленную на engineering excellence, инновации и постоянное улучшение (kaizen). Основной инструмент kaizen в Scrum-процессе — ретроспектива. На ней команда обсуждает, что было сделано хорошо в прошлой итерации, что можно улучшить, создаются задания по улучшению процессов разработки и удалению препятствий (eliminating waste).
Я сторонник подхода leadership by example. Любой менеджер должен глубоко разбираться в том, с чем он работает. У меня серьезный технический бэкграунд, соответственно, я, будучи менеджером, разбираюсь в том, что делают разработчики и с какими вызовами они сталкиваются. Таких же людей я стараюсь набирать на ключевые позиции. Все они будут создавать и распространять правильную культуру.
Ее создание также невозможно без правильного и своевременного признания заслуг. Это возможность отметить человека за то, что он сделал хорошо, за внесение инновации, хорошо проведенное демо или найденный баг, который блокировал работу. Быстрый recognition позволяет создавать культуру, мотивирующую людей работать над проектом и вносить дополнительную ценность.
Поддерживать культуру коллаборации можно через тимбилдинги, митапы и постоянный knowledge sharing. Так, на текущем проекте мы проводим JavaScript Meetup, а внутри команд организовывается DevOps Community.
Описанные подходы позволяют избежать так называемой «токсичной культуры» (toxic culture). Примеры ее проявлений — knowledge silos и finger pointing. Пример knowledge silo — когда только один разработчик в команде разбирается в процессе деплоймента, и все доверяют ему. В какой-то момент этот разработчик уходит на больничный и проект останавливается, потому что никто не способен его заменить. Культура, направленная на коллаборацию, постоянный обмен знаниями и изменения рода деятельности позволяет уйти от проблемы knowledge silos.
Еще один пример — finger pointing. Например, когда команда выпустила не очень удачный релиз, front-end может «показывать пальцами» на back-end. Те в ответ говорят, что это front-end написал плохой JS-код, и вместе они указывают на DevOps, которые неправильно задеплоили. Все друг друга обвиняют, а результата нет.
Хочется отметить, что описанные проблемы типичны для IT-проектов во многих компаниях и часто возникают в новых, недавно сформированных командах, которые проходят стадию формирования.
Если член команды что-то не так сделал, правильная культура поможет команде разобраться в проблеме, поднять ее на ретроспективе вместо того, чтобы просто винить человека. Последнее будет создавать у него страх снова ошибиться. Наша практика — это fail fast. Мы лучше допустим ошибку, но сразу ее увидим, чем люди будут бояться любых инноваций или изменений, опасаясь получить критику от менеджмента или членов команды.
Заключение
В заключение мне хотелось бы дать небольшой список best practices, которые, на мой взгляд, могут оказаться полезными для других похожих проектов. Данный список не претендует на абсолютную истину, я хочу поделиться тем, что сработало у нас.
Советы/извлеченные уроки в Product management:
- Разработка продукта начинается с UX/UI.
- Наличие UX-лида онсайт у клиента или частые командировки UX-инженеров для получения своевременного фидбэка и участие в UX review сессиях.
- Тесное взаимодействие бизнес-аналитиков, UX/UI-инженеров и Product Owner. Именно эта группа людей отвечает за качество юзер-стори. Если на этом этапе возникают проблемы, команда разработчиков будет сталкиваться с большим количеством противоречий в стори, нефинализированными макетами, невыявленными зависимостями и т. д.
Советы/извлеченные уроки в Delivery management:
- Набор правильных людей в команды. Какие бы ни были процессы на проекте, от людей на 100% зависит успех.
- Создание культуры высокопроизводительных команд, направленную на коллаборацию и инновации.
- Кросс-функциональные, автономные команды, состав которых может меняться на разных этапах проекта.
- Фокус на функциональное тестирование на ранних этапах разработки, но создание необходимой базы/фреймворка для automation-тестирования с самого начала. В начале ваш продукт скорее всего будет слишком быстро меняться, поэтому качественное функциональное (ручное) тестирование — правильное решение. Но по мере роста code base, разработки большего количества нового функционала, стабилизации разработки некоторых модулей, время на регрессионное тестирование будет возрастать, поэтому без инвестирования в automation не обойтись.
Советы/извлеченные уроки в Engineering:
- Сильная архитектурная команда. Без архитектора, который определяет техническую стратегию, создание надежного, масштабируемого, поддерживаемого продукта почти невозможно. В нашем случае отсутствие архитектора на ранних этапах разработки привело к некоторым странным технологических решениям, которые потом приходилось исправлять, затрачивая большие ресурсы.
- Постоянный рефакторинг, управление техническим долгом. Без постоянного инвестирования в рефакторинг, юнит-тестирование, затраты на поддержку продукта, добавление новых фич очень скоро возрастут экспоненциально.
- Культура Engineering Excellence в командах. Регулярные воркшопы/митапы разработчиков по текущим проблемам с качеством кода, обсуждение предложений по новым инструментам, подходам, юнит-тестированию и т. д.
- Сильная DevOps-экспертиза. DevOps-инженеры в командах разработчиков. Постоянное инвестирование в автоматизацию билдов и деплоймента, систем логирования и мониторинга.
