Вечер. Очередное R&D-собеседование подходит к концу, и наши интервьюеры настраиваются на неожиданные вопросы от будущего коллеги. Но никаких сюрпризов: соотношение, выведенное Вильфредо Парето, работает и здесь. В 80% случаев мы слышим четыре вопроса — примерно 20% от общего числа получаемых. Как у вас устроен процесс? Чем я буду заниматься? Как стать сеньором/тимлидом за год? Что по поводу релокации в Европу?
В этом посте мы ответим на первый вопрос и расскажем о процессе разработки в Veeam — от команды к команде этот ответ изменяется меньше всего.
Итак, процесс. Это повторяемая последовательность действий, ведущая к достижению успеха изо дня в день, ну или хотя бы иногда. Вы научились готовить борщ и каждый раз получается одинаково вкусно – процесс. Паркуетесь не на стук – освоили процесс. Процесс позволяет мозгу не задумываться каждый раз над рутиной, превращая ее в механическую работу. Мозг освобождается для творчества.
Процесс разработки — это последовательность действий, превращающих желания пользователей в материальные продукты. Эти желания формулируются аналитиками и продакт-менеджерами, реализуются разработчиками, критически оцениваются тестировщиками, описываются техписателями.
Мы в Veeam делаем массовые продукты для бэкапа и репликации дата-центров — чтоб ничего не потерялось. Классический коробочный продукт без конкретного заказчика. На первый взгляд, вещь простая, но есть нюансы, поэтому делаем уже второе десятилетие.
Каждый релиз — это результат работы нескольких групп:
Некоторые команды предпочитают open space, но чаще — кабинеты
Команды связываются посредством системы учета требований. Мы реализовали ее на базе Microsoft Team Foundation System, так как исторически использовали ее как систему хранения версий исходников. В системе хранятся требования (requirements), дефекты (bugs) и обращения в саппорт (issues), требующие участия QA и разработчиков. В каждый выпуск вовлечены сотни участников, которые работают над тысячами задач, требований и дефектов. Система помогает удержать все это и, что более важно, равномерно распределять нагрузку, расставить приоритеты для разработчиков.
Разработка нашего продукта циклична, каждый цикл заканчивается выпуском очередной версии — релизом. Вот что находит отражение в релизах:
Каждый квартал у нас выходят обновления (апдейты), примерно раз в год — крупные (мажорные) релизы. Они хороши тем, что минимизируют накладные расходы на создание объемной функциональности, связанной с поддержкой новых платформ и сменой парадигм. Исходя из особенностей бюджетирования, IT-департаменты клиентов наиболее активны в конце года, так что и большие релизы мы тоже выкатываем в это время.
Квартальные апдейты в основном преследуют две цели — поддержку новых версий защищаемых серверов и устранение дефектов. В обновлениях мы собираем все исправления дефектов, обнаруженных у клиентов с момента выпуска мажорной версии. Также с помощью обновлений мы оперативно реагируем на изменения в поддерживаемых платформах. По условиям SLA Veeam должен добавить поддержку новой версии гипервизора не более чем за три месяца.
А что делать, если продукт не работает у конкретного клиента? В этом случае выпускаем приватное исправление — проще говоря, костыль. Такие фиксы выпускаются каждую неделю и не всегда связаны с дефектами в продукте. Например, настройки системы безопасности у клиента могут быть несовместимы с продуктом. Выпуская приватный фикс, мы анализируем частотность проблемы и решаем, стоит ли включать фикс в последующее квартальное обновление.
Каждый релизный цикл начинается с планирования — на уровне продукта в целом и на уровне отдельно взятого требования. В первом случае решается вопрос бизнес-приоритетов и распределение требований между командами. В первую очередь, обсуждаются самые срочные требования или эпики. По-хорошему, на эпики стоит отводить не более 60% всего объема работ над релизом, чтобы была подушка времени. Продуктовое планирование осуществляется на уровне руководителей департаментов — продакты, тестировщики, разработчики.
Разработчики и тестировщики делятся на команды. Оптимальное количество людей в команде — пять. Команды бывают как функциональными, так и универсальными. В последнем случае команда самодостаточна, содержит разработчиков с экспертизой в нескольких областях. Функциональные команды более узконаправленные — они работают над пользовательским интерфейсом, системными компонентами и т.д. Люди из разных функциональных команд образуют виртуальные команды, которые начинают реализацию требований. Здесь, как минимум, собираются представители PM-группы, команд разработки и тестирования. Ответственным за требование назначается тимлид одной из функциональных команд.
Начинается работа над требованием. Виртуальная команда встречается еженедельно. Участники рассказывают об успехах за прошедшую неделю и планируют работу на следующую.
Ответственный за требование тимлид модерирует встречи и протоколирует результаты. Он же решает вопросы, которые внутри виртуальной команды решить невозможно. Например, если нужно сдвинуть сроки или отложить часть задач.
Внутри функциональных команд разработки или тестирования точки контроля расставлены более плотно. Как правило, недельный план делится на задачи длительностью не более двух-трех дней. В некоторых командах прижились скрам-практики с ежедневными летучками, где-то более эффективно работает взаимодействие «точка-точка» между тимлидом и командой.
Типичная переговорка для обсуждения текущего статуса проекта
Вся разработка делится на недельные или двухнедельные итерации. В ходе первых итераций нужно создать минимально работающий функционал, который в дальнейшем будет обрастать мясом — например, расширенным пользовательским интерфейсом, API для клиентов и т.д. А главное, что наличие скелета уже позволяет тестировщикам заводить фичу.
Релизный цикл включает в себя альфа- и бета-релизы. С их помощью мы показываем новые функции внешнему миру и заранее собираем отзывы. При необходимости меняются решения по архитектуре или функциональности. До состояния альфы и беты сценарии доводятся не сразу, а пачками. Как правило, в релизном цикле присутствует порядка двух бет.
После стадии беты команды переходят в режим регрессионного тестирования. На этой стадии продукт, в целом, уже работает, пользовательский интерфейс и сценарии работы уже затвердели и меняются с меньшей интенсивностью. В дело вступает команда технических писателей. Параллельно происходит обучение команд технической поддержки.
Регрессионное тестирование ведется двухнедельными циклами. Длительность цикла определяется временем, необходимым на просмотр всех сценариев продукта. Чем больше продукт, тем больше сценариев и, соответственно, циклов. Перед последним циклом объявляется кодлок. Это значит, что в продукт будут вноситься только критически важные изменения — и только после многочисленных код-ревью. Такие драконовские методы нужны для того, чтобы случайно не внести в продукт новые дефекты.
Чем ближе момент релиза, тем больше свободного времени у разработчиков и меньше — у всех остальных. Продакт-менеджерам нужно подготовить пресс-релизы, скоординировать работу служб маркетинга. Тестировщики должны проверить фиксы и осуществить финальное регрессионное тестирование. Технические писатели дописывают пользовательскую документацию. В это благодатное время разработчики разворачивают исследовательскую деятельность для требований уже следующей версии.
И вот он волнительный момент, именуемый RTM — Ready To Market. Это значит, что продукт уже готов к передаче потребителям. В течение двух недель его будут терзать журналисты, сервис-провайдеры. Он будет показываться на презентациях. Спустя две недели продукт станет доступен всем. В это время происходят и внутренние изменения: готовятся новые ветки разработки, осуществляется депонирование кода. И, конечно, поднимается билд-инфраструктура под следующую версию. После публичного выпуска (GA), наступает горячее время для службы технической поддержки. А остальные уже работает над следующей версией.
И напоследок немного матчасти. Как известно, в троице «быстро, качественно, недорого» можно выбрать максимум два варианта. Качество, сроки и функциональность постоянно дерутся между собой. У нас в коробочном продукте качество стоит на первом месте. Хм, а что есть какая-то область, где качество неважно? Конечно же, нет. Весь вопрос в определении качества.
Для нас качество – это:
С таким набором приоритетов для сохранения качества нужно всегда что-то комбинировать, причем как разработчикам, так и тестировщикам. Небольшие изменения в поведении функций могут привести к вынужденному интеграционному перетестированию львиной доли продукта. Попробуйте добавить поддержку азиатских локалей в продукт и поймете, о чем речь. Поэтому вопрос приоритетов — это вопрос совместного обсуждения PM-ов, тестировщиков и разработчиков.
Вторым, почти нерушимым приоритетом являются сроки. В случае обновлений сроки выпуска задаются SLA, в случае больших релизов — бизнес-календарем. По статистике в каждом релизном цикле почти 50% времени уходит на разработку, 50% — на доведение продукта до ума (стадия багфикса).
Что может изменяться, так это функциональность очередного релиза. Здесь помогает приоритизированный список требований, или бэклог. Теоретически все просто: выбираете из бэклога следующую по приоритету функцию, смотрите за оставшимся временем. Когда время близко к исходу, останавливаетесь и выпускаете очередную версию продукта. Дьявол же скрыт в нюансах:
Здесь вступает в дело гибкая разработка. Для нас гибкая разработка означает необходимость периодического перепланирования. Стали известны новые обстоятельства — поменяли планы. Добавились новые приоритетные требования в бэклог — поменяли планы. Не успеваем с неоткладываемыми требованием — режем часть задач или изменяем требование. В теории технического управления это называется системой с обратной связью. Вспомните, как работает автопилот.
Любое планирование в условиях выше опирается на экспертную оценку. Экспертная оценка ответственного за требование тимлида является тем элементом, который делает весь последующий процесс четким и структурированным. Иное название экспертной оценки — «метод ленинского прищура», как любит повторять Александр Орлов из «Стратоплана». Это когда вы на основании предыдущего опыта и интуиции принимаете решение. Несмотря на возможную критику, это работает. Работает, как и все наши описанные выше процессы. Если у вас остались по ним вопросы, приглашаем в комментарии.
Текущий техпроцесс комфортен и уютен как домашние тапочки. Проблема только в том, что в Veeam какое-то невидимое шило всегда подгоняет: быстрее, больше, еще, еще.
Cовсем недавно строили пилотные офисы в Финляндии и Чехии, а уже в этом году готовимся к большому открытию Пражского R&D центра на несколько сотен человек.
Лобби нашего пражского офиса
Недавно появился офис разработки в Израиле, растут команды в Канаде и Германии. Увеличивается количество совместных проектов разработки с HP, NetApp, Nutanix, EMC.
Мануфактура превращается в географически распределенный конвейер, а вместе с тем кристаллизуются и новые процессы. Впрочем, это тема для отдельной статьи.
Stay connected.
В этом посте мы ответим на первый вопрос и расскажем о процессе разработки в Veeam — от команды к команде этот ответ изменяется меньше всего.
Итак, процесс. Это повторяемая последовательность действий, ведущая к достижению успеха изо дня в день, ну или хотя бы иногда. Вы научились готовить борщ и каждый раз получается одинаково вкусно – процесс. Паркуетесь не на стук – освоили процесс. Процесс позволяет мозгу не задумываться каждый раз над рутиной, превращая ее в механическую работу. Мозг освобождается для творчества.
Процесс разработки — это последовательность действий, превращающих желания пользователей в материальные продукты. Эти желания формулируются аналитиками и продакт-менеджерами, реализуются разработчиками, критически оцениваются тестировщиками, описываются техписателями.
Мы в Veeam делаем массовые продукты для бэкапа и репликации дата-центров — чтоб ничего не потерялось. Классический коробочный продукт без конкретного заказчика. На первый взгляд, вещь простая, но есть нюансы, поэтому делаем уже второе десятилетие.
Действующие лица
Каждый релиз — это результат работы нескольких групп:
- Продакт-менеджеры, или аналитики. Они расставляют приоритеты в работе, общаясь с внешним миром — клиентами и партнерами. Партнерство может быть в том числе технологическим. Например, дистрибьютор может подсказать, чего ему не хватает для увеличения продаж, а производитель гипервизора — рассказать о планах на будущее. Для этой команды важно «умение говорить», способность ловить и приоритизировать тенденции в бурном потоке мнений. А затем отстоять выбранную позицию, сказать «нет», объяснить, почему что-то сделано именно так, а не иначе. Неважно, в пресс-релизах, на конференциях или в частном порядке. Эти люди обучают мир сейлзов.
- Служба технической поддержки. Телефон доверия наших клиентов. Важнейшие показатели команды — время реакции на проблему и время ее разрешения (SLA). В течение месяца обслуживается порядка нескольких тысяч обращений. Команда многослойна, включает в себя как группы взаимодействия с клиентами, так и группы аналитики обращений, выработки обходных решений и т.д. На основе информации, получаемой саппортом, формулируется список улучшений и срочность — реализовать ли в приватном фиксе, следующем обновлении или отложить на мажорный релиз.
- R&D-разработчики. Люди, которые материализуют запросы в код.
- Тестировщики, или QA. Первоиспытатели, танковый полигон и вибростенд одновременно. Они не только проверяют то, что уже реализовано — но и подключаются к работе еще на этапе задумки. Повторяя задачи администраторов в инфраструктуре, приближенной к боевой, легче понять, насколько удобен созданный интерфейс или производительны выбранные алгоритмы. Когда техническая поддержка приходит к мнению, что в продукте есть дефект, QA воспроизводит проблемные сценарии и контролирует исправления.
- Команда технических писателей. Они создают документацию для конечных пользователей, а также специфические документы типа «How it works» и «Deployment guide». Материал для работы они получают от разработчиков, тестировщиков и аналитиков.
Некоторые команды предпочитают open space, но чаще — кабинеты
Команды связываются посредством системы учета требований. Мы реализовали ее на базе Microsoft Team Foundation System, так как исторически использовали ее как систему хранения версий исходников. В системе хранятся требования (requirements), дефекты (bugs) и обращения в саппорт (issues), требующие участия QA и разработчиков. В каждый выпуск вовлечены сотни участников, которые работают над тысячами задач, требований и дефектов. Система помогает удержать все это и, что более важно, равномерно распределять нагрузку, расставить приоритеты для разработчиков.
Годичные кольца: циклы разработки
Разработка нашего продукта циклична, каждый цикл заканчивается выпуском очередной версии — релизом. Вот что находит отражение в релизах:
- Долгоиграющие тенденции на рынке. Например, виртуализация и появление облачных инфраструктур. Изменение парадигм работы IT занимает годы — в это время пользователи переходят от подозрения и отрицания («что это за хрень») к массовому признанию («да все так делают»). Виртуализация дата-центров в свое время породила Veeam, так как в условиях виртуализации старые продукты для резервного копирования машин были неэффективны.
- Поддержка новых платформ. Когда-то давно Veeam был предназначен только для виртуализованных дата-центров на платформе VMWare. С ростом количества и размера клиентов возникла потребность в поддержке новых платформ. В довесок к VMWare появились другие гипервизоры (Hyper-V), физические сервера, облачные платформы (AWS, Azure) и т.д.
- Тактические изменения на рынке. Выпускаются очередные версии операционных систем и гипервизоров. Накапливается опыт использования предыдущих версий нашего продукта. Например, так у нас появилась поддержка item-level — выборочное восстановление из популярных серверов приложений, таких как Microsoft Exchange, Microsoft SQL Server, Oracle Databases и т.д.
- Дефекты. Несмотря на все наши старания, жизнь нет-нет, да и преподносит сюрпризы. Разумеется, мы стараемся сводить их к минимуму.
Каждый квартал у нас выходят обновления (апдейты), примерно раз в год — крупные (мажорные) релизы. Они хороши тем, что минимизируют накладные расходы на создание объемной функциональности, связанной с поддержкой новых платформ и сменой парадигм. Исходя из особенностей бюджетирования, IT-департаменты клиентов наиболее активны в конце года, так что и большие релизы мы тоже выкатываем в это время.
Квартальные апдейты в основном преследуют две цели — поддержку новых версий защищаемых серверов и устранение дефектов. В обновлениях мы собираем все исправления дефектов, обнаруженных у клиентов с момента выпуска мажорной версии. Также с помощью обновлений мы оперативно реагируем на изменения в поддерживаемых платформах. По условиям SLA Veeam должен добавить поддержку новой версии гипервизора не более чем за три месяца.
А что делать, если продукт не работает у конкретного клиента? В этом случае выпускаем приватное исправление — проще говоря, костыль. Такие фиксы выпускаются каждую неделю и не всегда связаны с дефектами в продукте. Например, настройки системы безопасности у клиента могут быть несовместимы с продуктом. Выпуская приватный фикс, мы анализируем частотность проблемы и решаем, стоит ли включать фикс в последующее квартальное обновление.
От рассвета до заката: хроника релиза
Каждый релизный цикл начинается с планирования — на уровне продукта в целом и на уровне отдельно взятого требования. В первом случае решается вопрос бизнес-приоритетов и распределение требований между командами. В первую очередь, обсуждаются самые срочные требования или эпики. По-хорошему, на эпики стоит отводить не более 60% всего объема работ над релизом, чтобы была подушка времени. Продуктовое планирование осуществляется на уровне руководителей департаментов — продакты, тестировщики, разработчики.
Разработчики и тестировщики делятся на команды. Оптимальное количество людей в команде — пять. Команды бывают как функциональными, так и универсальными. В последнем случае команда самодостаточна, содержит разработчиков с экспертизой в нескольких областях. Функциональные команды более узконаправленные — они работают над пользовательским интерфейсом, системными компонентами и т.д. Люди из разных функциональных команд образуют виртуальные команды, которые начинают реализацию требований. Здесь, как минимум, собираются представители PM-группы, команд разработки и тестирования. Ответственным за требование назначается тимлид одной из функциональных команд.
Начинается работа над требованием. Виртуальная команда встречается еженедельно. Участники рассказывают об успехах за прошедшую неделю и планируют работу на следующую.
Ответственный за требование тимлид модерирует встречи и протоколирует результаты. Он же решает вопросы, которые внутри виртуальной команды решить невозможно. Например, если нужно сдвинуть сроки или отложить часть задач.
Внутри функциональных команд разработки или тестирования точки контроля расставлены более плотно. Как правило, недельный план делится на задачи длительностью не более двух-трех дней. В некоторых командах прижились скрам-практики с ежедневными летучками, где-то более эффективно работает взаимодействие «точка-точка» между тимлидом и командой.
Типичная переговорка для обсуждения текущего статуса проекта
Вся разработка делится на недельные или двухнедельные итерации. В ходе первых итераций нужно создать минимально работающий функционал, который в дальнейшем будет обрастать мясом — например, расширенным пользовательским интерфейсом, API для клиентов и т.д. А главное, что наличие скелета уже позволяет тестировщикам заводить фичу.
Релизный цикл включает в себя альфа- и бета-релизы. С их помощью мы показываем новые функции внешнему миру и заранее собираем отзывы. При необходимости меняются решения по архитектуре или функциональности. До состояния альфы и беты сценарии доводятся не сразу, а пачками. Как правило, в релизном цикле присутствует порядка двух бет.
После стадии беты команды переходят в режим регрессионного тестирования. На этой стадии продукт, в целом, уже работает, пользовательский интерфейс и сценарии работы уже затвердели и меняются с меньшей интенсивностью. В дело вступает команда технических писателей. Параллельно происходит обучение команд технической поддержки.
Регрессионное тестирование ведется двухнедельными циклами. Длительность цикла определяется временем, необходимым на просмотр всех сценариев продукта. Чем больше продукт, тем больше сценариев и, соответственно, циклов. Перед последним циклом объявляется кодлок. Это значит, что в продукт будут вноситься только критически важные изменения — и только после многочисленных код-ревью. Такие драконовские методы нужны для того, чтобы случайно не внести в продукт новые дефекты.
Чем ближе момент релиза, тем больше свободного времени у разработчиков и меньше — у всех остальных. Продакт-менеджерам нужно подготовить пресс-релизы, скоординировать работу служб маркетинга. Тестировщики должны проверить фиксы и осуществить финальное регрессионное тестирование. Технические писатели дописывают пользовательскую документацию. В это благодатное время разработчики разворачивают исследовательскую деятельность для требований уже следующей версии.
И вот он волнительный момент, именуемый RTM — Ready To Market. Это значит, что продукт уже готов к передаче потребителям. В течение двух недель его будут терзать журналисты, сервис-провайдеры. Он будет показываться на презентациях. Спустя две недели продукт станет доступен всем. В это время происходят и внутренние изменения: готовятся новые ветки разработки, осуществляется депонирование кода. И, конечно, поднимается билд-инфраструктура под следующую версию. После публичного выпуска (GA), наступает горячее время для службы технической поддержки. А остальные уже работает над следующей версией.
О приоритетах
И напоследок немного матчасти. Как известно, в троице «быстро, качественно, недорого» можно выбрать максимум два варианта. Качество, сроки и функциональность постоянно дерутся между собой. У нас в коробочном продукте качество стоит на первом месте. Хм, а что есть какая-то область, где качество неважно? Конечно же, нет. Весь вопрос в определении качества.
Для нас качество – это:
- Сохранение надежности и производительности в зоопарке конфигураций. У одного клиента скромный дата-центр из двух серверов времен Бородинской битвы, а у другого – high-end инфраструктура в соседнем ангаре с Amazon. Продукт должен работать адекватно в обоих случаях.
- Простота использования. Пользователь должен напрягаться по минимуму и уж точно справляться без всяких инструкций. Но за внешней простотой далеко не всегда скрывается аналогично простой код — попробуйте скрестить ужа с ежом бесшовно.
- Наследуемость. Инвестиции у предприятий многолетние, и финансовые директора не будут тратиться на IT без веской причины. Так что нужно сохранять совместимость и с предыдущими версиями, и со смежными продуктами. Нередко при перестройке дата-центров в стену замуровывают почтовые сервера эпохи 80-х. А они все жужжат и помирать не думают.
С таким набором приоритетов для сохранения качества нужно всегда что-то комбинировать, причем как разработчикам, так и тестировщикам. Небольшие изменения в поведении функций могут привести к вынужденному интеграционному перетестированию львиной доли продукта. Попробуйте добавить поддержку азиатских локалей в продукт и поймете, о чем речь. Поэтому вопрос приоритетов — это вопрос совместного обсуждения PM-ов, тестировщиков и разработчиков.
Вторым, почти нерушимым приоритетом являются сроки. В случае обновлений сроки выпуска задаются SLA, в случае больших релизов — бизнес-календарем. По статистике в каждом релизном цикле почти 50% времени уходит на разработку, 50% — на доведение продукта до ума (стадия багфикса).
Что может изменяться, так это функциональность очередного релиза. Здесь помогает приоритизированный список требований, или бэклог. Теоретически все просто: выбираете из бэклога следующую по приоритету функцию, смотрите за оставшимся временем. Когда время близко к исходу, останавливаетесь и выпускаете очередную версию продукта. Дьявол же скрыт в нюансах:
- Неопределенность требований. Например, требование «поддержать резервное копирование физических машин на OS Linux» может в дальнейшем сильно уточняться. Какие ядра должны поддерживаться? Какие дистрибутивы? Какие файловые системы? Одно и то же высокоуровневое требование можно реализовать и за месяц, и за год. Вопрос в полноте.
- Команды имеют специализации. Не любое требование может быть взято любой командой. C#-разработчик не напишет драйверы, разработчик системных компонентов не всегда справится с web-разработкой.
- Требования зависят друг от друга. Это не всегда видно на уровне пользовательских сценариев, но внутри такие связи есть. С точки зрения внешнего мира поддержка резервного копирования с файловых систем NTFS и ExtFS могут быть требованиями с разным приоритетами, но внутри вначале надо будет написать общий движок.
- Требования делятся на откладываемые и неоткладываемые. Если рынок ждет в очередной версии какую-то функцию, и она была анонсирована, то отложить ее не получится.
- Часть требований предполагает исследовательскую работу. Без результатов исследовательской работы невозможно планировать сложность задачи (может, она вообще невыполнима), а спрогнозировать эти результаты бывает сложно.
Здесь вступает в дело гибкая разработка. Для нас гибкая разработка означает необходимость периодического перепланирования. Стали известны новые обстоятельства — поменяли планы. Добавились новые приоритетные требования в бэклог — поменяли планы. Не успеваем с неоткладываемыми требованием — режем часть задач или изменяем требование. В теории технического управления это называется системой с обратной связью. Вспомните, как работает автопилот.
Любое планирование в условиях выше опирается на экспертную оценку. Экспертная оценка ответственного за требование тимлида является тем элементом, который делает весь последующий процесс четким и структурированным. Иное название экспертной оценки — «метод ленинского прищура», как любит повторять Александр Орлов из «Стратоплана». Это когда вы на основании предыдущего опыта и интуиции принимаете решение. Несмотря на возможную критику, это работает. Работает, как и все наши описанные выше процессы. Если у вас остались по ним вопросы, приглашаем в комментарии.
Что дальше?
Текущий техпроцесс комфортен и уютен как домашние тапочки. Проблема только в том, что в Veeam какое-то невидимое шило всегда подгоняет: быстрее, больше, еще, еще.
Cовсем недавно строили пилотные офисы в Финляндии и Чехии, а уже в этом году готовимся к большому открытию Пражского R&D центра на несколько сотен человек.
Лобби нашего пражского офиса
Недавно появился офис разработки в Израиле, растут команды в Канаде и Германии. Увеличивается количество совместных проектов разработки с HP, NetApp, Nutanix, EMC.
Мануфактура превращается в географически распределенный конвейер, а вместе с тем кристаллизуются и новые процессы. Впрочем, это тема для отдельной статьи.
Stay connected.
