Собственная методология разработки R&D-проектов в AI, от идеи до создания
Что такое R&D-проект в AI?
Для начала стоит определиться, чем является R&D-проект. Это проект, в котором очень много работы с кодом, а инфраструктуре уделяется намного меньше внимания. Стратегия следующая: в основном концентрироваться на разработке самих моделей и их дальнейшей работе. При этом используется мало инструментов, чтобы поставлять и поддерживать решение. Как правило, все проекты имеют три ограничения:
Типичный клиентский запрос: для экономии средств и ускорения обработки данных нужно провести компрессию данных без потери качества. Для этого берется модель на вход, с ней проводятся определенные операции, и она возвращается клиенту. В результате модель будет работать оптимальнее. Эти задачи могут относиться к разным сферам — машинному зрению, обработке естественного языка, обработке сигналов и другим.
Почему нужна своя методология работы
Необходимо выстроить работу через понятные итерации и блоки, чтобы снизить риски и ответить на вопросы. Одна из реалий — методологии, представленные на рынке, не очень подходят для R&D-проектов. Основная причина этого — достаточно непрогнозируемый результат тестируемых идей. Никогда не известно наверняка, какое именно количество идей нужно проверить и какая именно сработает. При этом есть требования рынка и заказчиков — они хотят, чтобы разработка двигалась понятными для них итерациями и выдавала прогнозируемый результат в конце каждого спринта.
Где возникают похожие сложности? В построении продуктов. Когда команда работает над новым продуктом, у них есть очень много гипотез, заранее предсказать успешность которых практически невозможно. При этом у команды есть ограничения: время, финансирование, целевой результат.
Хотите больше реального опыта представителей индустрии, регистрируйтесь на митап Selectel, где соберутся лидеры MLOps-комьюнити.
Чем пользовались другие компании
Популярное решение — одна из моделей создания продукта, Triple Diamond от компании Zendesk. Здесь есть этапы работы с проблемой и решением, а также реализации всего этого в продукте.
Этапы Triple Diamond в визуальном виде
В подобных командах есть разделение R&D-работы на два процесса — Discovery и Delivery.
Discovery-трек — это зона полной неопределенности: открытие чего-то нового, подтверждение своих идей и гипотез, подтверждение того, что они работают, проверка их работоспособности.
Delivery-трек — зона определенности, когда команда уже занимается реализацией идей.
Два этих трека существуют и работают параллельно. Delivery всегда двигается прогнозируемыми итерациями, потому что точно известно, что нужно делать. А цель Discovery — проверить в единицу времени максимальное число гипотез и выбрать те, которые с наибольшей вероятностью дадут результат. По сути, это генерация, приоритизация и проверка идей.
Поиск своего решения
Как генерируется идея, которая сработает? Для этого нужно следующее.
Методология
К созданию своей методологии MIL Team подошла с постановки целей. Нужно было, чтобы схема включала и ролевую, и функциональную модель проекта, для понимания того, кто и чем занимается. Также было необходимо, чтобы этапность спринта и проекта была понятной, так методологию реально масштабировать на несколько проектов.
Команда MIL Teам проанализировала свою обычную работу над проектами, выписала 50 процессов внутри команд, сгруппировала их до 4 уровней и сделала первую версию. Она состоит из следующих блоков: management, vision, development, capitalisation. Они хорошо описывали актуальный способ работы, учитывали риски ожидания и видение решения. Это был итеративный, понятный и измеримый процесс. Но он не позволял продвинуться вперед, привнести что-то новое и решить те проблемы, которые есть.
Поэтому была создана вторая, более сложная версия. Озвучим основные особенности:
Существует и блок с Delivery, где реализуется определенная функциональность для библиотеки. Здесь внедряются результаты проверки идей, либо формируется набор требований для тех функций, которые есть в технических заданиях, в стандартных практиках software engineering или же на основе рефакторинга кода для его оптимизации.
Качество и метрики
Как понять, что работа идет хорошо? Для этого нужно наложить на процесс определенные метрики, чтобы он стал более прозрачным. Нужно сформулировать критерии, которые могли бы сигнализировать о проблемах.
Вот три метрики, с помощью которых команда MIL Team оцифровала процесс:
Артефакты
Помимо этапов методологии и метрик, с помощью которых отслеживается качество работы, есть также список артефактов, которые позволяют смотреть на проект. Это данные, которые в любом случае генерируются в ходе проекта и которые позволяют понять, какая работа проделана, какие результаты достигнуты и прочее.
Каких результатов помогает достичь методология?
Решения Selectel для ML-инфраструктуры
Вот какие элементы вычислительной инфраструктуры можно использовать:
Чтобы не пропустить релиз этих (и многих других) продуктов, подписывайтесь на наш блог и оставайтесь в курсе всех новостей.
Скрытые связи: как отдел R&D влияет на эффективность продаж
Эффективность работы фронт-офиса в принципе невозможна без налаженного должным образом взаимодействия с остальными подразделениями компании.
Фронт-офис — подразделение, отвечающее за взаимодействие с клиентами компании, чаще всего отдел продаж.
В наибольшей степени на продажи влияет работа блока R&D — то, насколько хорошо компания управляет продуктами, которые предлагает потребителям.
R&D (англ. Research and development — исследования и разработки) — функциональный блок в компании, объединяющий несколько подразделений и отвечающий за создание, выведение на рынок продукта и управление его жизненным циклом.
К блоку R&D относятся:
Процессный подход к работе компании объединяет все действия ее сотрудников, направленные на получение денег от клиентов, в сквозных основных бизнес-процессах.
Процессный подход к управлению строится на организации работы по выполнению описанных и внедренных бизнес-процессов (основных и поддерживающих), когда сотрудники компании взаимодействуют в первую очередь исходя из своих ролей, функционала и требований к выполнению шагов бизнес-процесса, а не из принадлежности к определенному бизнес-подразделению
Сквозной бизнес-процесс — это бизнес-процесс, проходящий через границы разных подразделений и тем самым вовлекающий в исполнение сотрудников этих подразделений; основной бизнес-процесс — тот, который обеспечивает компанию деньгами
Это означает, что отдел продаж не может существовать сам по себе, т.к. тесно связан с другими функциональными единицами.
Новая профессия: R&D-менеджер
R&D-менеджеры (от англ. Research &Developmet) — это «возмутители спокойствия» внутри корпораций. Именно они разрабатывают стратегии технологического развития компании, ищут перспективные разработки и проводят модернизацию производства. Подчас им приходится решать нестандартные для отрасли задачи и осваивать новые области знаний. И все это одновременно и в кратчайшие сроки.
Департаменты R&D созданы практически во всех крупных российских компаниях, как частных, так и государственных: «Росатом», ФГУП «Космическая связь», НЛМК, Объединенные машиностроительные заводы, «Русэлпром», «Русгидро», СИБУР, РЖД, КАМАЗ, «Алроса» и др. В самых продвинутых с точки зрения технологий компаниях численность R&D отдела может достигать нескольких десятков человек. Например, в «Лаборатории Касперского» R&D отдел объединяет треть сотрудников (882 человека).
В зависимости от отрасли, должность руководителя может называться «начальник отдела инноваций и развития», «директор по стратегиям и развитию бизнеса» или «менеджер по маркетингу инноваций». По инициативе института развития ОАО «РВК» Институт менеджмента инноваций НИУ ВШЭ провел опрос 55 R&D-менеджеров из 46 крупнейших российских компаний и выяснил, что большинство респондентов относятся к категории топ-менеджеров и имеют соответствующий статусу доход — в среднем 160 тысяч рублей и выше.
85% опрошенных имеют базовое техническое или естественно-научное образование. Причем подчиненных они набирают по тому же принципу: наличие у соискателя дополнительного экономического или менеджерского образования не влияет на решение о трудоустройстве. На базе хорошего технического образования специалист может уже в процессе работы овладеть методами разработки стратегий и оценки экономической эффективности, получить необходимые знания по управлению инновационными проектами.
— Менеджеры зачастую вырастают из рядовых специалистов, — говорит заместитель директора «Лаборатории Касперского» по работе с персоналом Виолетта Абрамова. — У нас есть ряд ценностей: гибкость, адаптивность и интеллект, которые Евгений Касперский назвал самыми важными для специалистов высокотехнологичной сферы. Уже на этапе отбора кандидатов мы смотрим, обладает ли человек этими качествами. Наши специалисты в R&D посещают самые лучшие стажировки. Для нас корпоративное обучение имеет большую ценность, поскольку оно дает специалистам конкретные практические знания из конкретной области. Тогда как аспирантура и второе высшее образование — это больше академические истории.
В «Яндексе» также предпочитают самостоятельно растить будущих R&D менеджеров из сотрудников с базовым техническим образованием. «Весь наш бизнес построен на новых идеях и технологиях, и фактически в каждой команде — свои разработки, — поясняет Юлия Бабикова, PR-менеджер компании «Яндекс». — Также есть отдельное структурное подразделение — группа исследователей. Они занимаются исследованиями в областях информационного поиска, машинного обучения, обработки изображений, фильтрации спама и других. Часть сотрудников группы — выпускники Школы анализа данных (ШАД), созданной по инициативе «Яндекса». Кстати, к образовательным проектам в компании подходят с особой тщательностью и начинают воспитывать потенциальных сотрудников еще со школьной скамьи. Стратегическое решение «Яндекса» — открыть ШАД для старшеклассников. Это лишнее подтверждение тому, что высококлассные программисты будут востребованы на рынке труда в долгосрочной перспективе.
В настоящее время R&D директоры — в абсолютном большинстве выпускники технических вузов, выросшие до топовой должности с позиции рядового специалиста внутри компании. Идеальных специалистов каждая компания предпочитает воспитывать в первую очередь «под себя» соразмерно собственным запросам. Впрочем, в ближайшем будущем технические вузы начнут выпускать готовых R&D-cпециалистов. ОАО «РВК» как институт развития инициировало разработку нового курса «Инновационная экономика» для бакалавров технических вузов. В НИТУ «МИСиС», МГТУ им. Баумана, Самарском государственном аэрокосмическом университете, Московском государственном горном университете и Рязанском радиотехническом университете студенты уже осваивают программы по коммерциализации и трансферу технологий. Учебно-методическое объединение вузов РФ в области материаловедения и металлургии рекомендовало внедрить этот курс во всех технических университетах страны. Так что вскоре инновационный менеджмент станет такой же неотъемлемой частью образовательного стандарта, как и высшая математика.
Внутренняя кухня Veeam: как устроен R&D процесс
Вечер. Очередное R&D-собеседование подходит к концу, и наши интервьюеры настраиваются на неожиданные вопросы от будущего коллеги. Но никаких сюрпризов: соотношение, выведенное Вильфредо Парето, работает и здесь. В 80% случаев мы слышим четыре вопроса — примерно 20% от общего числа получаемых. Как у вас устроен процесс? Чем я буду заниматься? Как стать сеньором/тимлидом за год? Что по поводу релокации в Европу?
В этом посте мы ответим на первый вопрос и расскажем о процессе разработки в Veeam — от команды к команде этот ответ изменяется меньше всего.
Итак, процесс. Это повторяемая последовательность действий, ведущая к достижению успеха изо дня в день, ну или хотя бы иногда. Вы научились готовить борщ и каждый раз получается одинаково вкусно – процесс. Паркуетесь не на стук – освоили процесс. Процесс позволяет мозгу не задумываться каждый раз над рутиной, превращая ее в механическую работу. Мозг освобождается для творчества.
Процесс разработки — это последовательность действий, превращающих желания пользователей в материальные продукты. Эти желания формулируются аналитиками и продакт-менеджерами, реализуются разработчиками, критически оцениваются тестировщиками, описываются техписателями.
Мы в Veeam делаем массовые продукты для бэкапа и репликации дата-центров — чтоб ничего не потерялось. Классический коробочный продукт без конкретного заказчика. На первый взгляд, вещь простая, но есть нюансы, поэтому делаем уже второе десятилетие.
Действующие лица
Каждый релиз — это результат работы нескольких групп:
Команды связываются посредством системы учета требований. Мы реализовали ее на базе Microsoft Team Foundation System, так как исторически использовали ее как систему хранения версий исходников. В системе хранятся требования (requirements), дефекты (bugs) и обращения в саппорт (issues), требующие участия QA и разработчиков. В каждый выпуск вовлечены сотни участников, которые работают над тысячами задач, требований и дефектов. Система помогает удержать все это и, что более важно, равномерно распределять нагрузку, расставить приоритеты для разработчиков.
Годичные кольца: циклы разработки
Разработка нашего продукта циклична, каждый цикл заканчивается выпуском очередной версии — релизом. Вот что находит отражение в релизах:
Квартальные апдейты в основном преследуют две цели — поддержку новых версий защищаемых серверов и устранение дефектов. В обновлениях мы собираем все исправления дефектов, обнаруженных у клиентов с момента выпуска мажорной версии. Также с помощью обновлений мы оперативно реагируем на изменения в поддерживаемых платформах. По условиям SLA Veeam должен добавить поддержку новой версии гипервизора не более чем за три месяца.
А что делать, если продукт не работает у конкретного клиента? В этом случае выпускаем приватное исправление — проще говоря, костыль. Такие фиксы выпускаются каждую неделю и не всегда связаны с дефектами в продукте. Например, настройки системы безопасности у клиента могут быть несовместимы с продуктом. Выпуская приватный фикс, мы анализируем частотность проблемы и решаем, стоит ли включать фикс в последующее квартальное обновление.
От рассвета до заката: хроника релиза
Каждый релизный цикл начинается с планирования — на уровне продукта в целом и на уровне отдельно взятого требования. В первом случае решается вопрос бизнес-приоритетов и распределение требований между командами. В первую очередь, обсуждаются самые срочные требования или эпики. По-хорошему, на эпики стоит отводить не более 60% всего объема работ над релизом, чтобы была подушка времени. Продуктовое планирование осуществляется на уровне руководителей департаментов — продакты, тестировщики, разработчики.
Разработчики и тестировщики делятся на команды. Оптимальное количество людей в команде — пять. Команды бывают как функциональными, так и универсальными. В последнем случае команда самодостаточна, содержит разработчиков с экспертизой в нескольких областях. Функциональные команды более узконаправленные — они работают над пользовательским интерфейсом, системными компонентами и т.д. Люди из разных функциональных команд образуют виртуальные команды, которые начинают реализацию требований. Здесь, как минимум, собираются представители PM-группы, команд разработки и тестирования. Ответственным за требование назначается тимлид одной из функциональных команд.
Начинается работа над требованием. Виртуальная команда встречается еженедельно. Участники рассказывают об успехах за прошедшую неделю и планируют работу на следующую.
Ответственный за требование тимлид модерирует встречи и протоколирует результаты. Он же решает вопросы, которые внутри виртуальной команды решить невозможно. Например, если нужно сдвинуть сроки или отложить часть задач.
Внутри функциональных команд разработки или тестирования точки контроля расставлены более плотно. Как правило, недельный план делится на задачи длительностью не более двух-трех дней. В некоторых командах прижились скрам-практики с ежедневными летучками, где-то более эффективно работает взаимодействие «точка-точка» между тимлидом и командой.
Типичная переговорка для обсуждения текущего статуса проекта
Вся разработка делится на недельные или двухнедельные итерации. В ходе первых итераций нужно создать минимально работающий функционал, который в дальнейшем будет обрастать мясом — например, расширенным пользовательским интерфейсом, API для клиентов и т.д. А главное, что наличие скелета уже позволяет тестировщикам заводить фичу.
Релизный цикл включает в себя альфа- и бета-релизы. С их помощью мы показываем новые функции внешнему миру и заранее собираем отзывы. При необходимости меняются решения по архитектуре или функциональности. До состояния альфы и беты сценарии доводятся не сразу, а пачками. Как правило, в релизном цикле присутствует порядка двух бет.
После стадии беты команды переходят в режим регрессионного тестирования. На этой стадии продукт, в целом, уже работает, пользовательский интерфейс и сценарии работы уже затвердели и меняются с меньшей интенсивностью. В дело вступает команда технических писателей. Параллельно происходит обучение команд технической поддержки.
Регрессионное тестирование ведется двухнедельными циклами. Длительность цикла определяется временем, необходимым на просмотр всех сценариев продукта. Чем больше продукт, тем больше сценариев и, соответственно, циклов. Перед последним циклом объявляется кодлок. Это значит, что в продукт будут вноситься только критически важные изменения — и только после многочисленных код-ревью. Такие драконовские методы нужны для того, чтобы случайно не внести в продукт новые дефекты.
Чем ближе момент релиза, тем больше свободного времени у разработчиков и меньше — у всех остальных. Продакт-менеджерам нужно подготовить пресс-релизы, скоординировать работу служб маркетинга. Тестировщики должны проверить фиксы и осуществить финальное регрессионное тестирование. Технические писатели дописывают пользовательскую документацию. В это благодатное время разработчики разворачивают исследовательскую деятельность для требований уже следующей версии.
И вот он волнительный момент, именуемый RTM — Ready To Market. Это значит, что продукт уже готов к передаче потребителям. В течение двух недель его будут терзать журналисты, сервис-провайдеры. Он будет показываться на презентациях. Спустя две недели продукт станет доступен всем. В это время происходят и внутренние изменения: готовятся новые ветки разработки, осуществляется депонирование кода. И, конечно, поднимается билд-инфраструктура под следующую версию. После публичного выпуска (GA), наступает горячее время для службы технической поддержки. А остальные уже работает над следующей версией.
О приоритетах
И напоследок немного матчасти. Как известно, в троице «быстро, качественно, недорого» можно выбрать максимум два варианта. Качество, сроки и функциональность постоянно дерутся между собой. У нас в коробочном продукте качество стоит на первом месте. Хм, а что есть какая-то область, где качество неважно? Конечно же, нет. Весь вопрос в определении качества.
Для нас качество – это:
Вторым, почти нерушимым приоритетом являются сроки. В случае обновлений сроки выпуска задаются SLA, в случае больших релизов — бизнес-календарем. По статистике в каждом релизном цикле почти 50% времени уходит на разработку, 50% — на доведение продукта до ума (стадия багфикса).
Любое планирование в условиях выше опирается на экспертную оценку. Экспертная оценка ответственного за требование тимлида является тем элементом, который делает весь последующий процесс четким и структурированным. Иное название экспертной оценки — «метод ленинского прищура», как любит повторять Александр Орлов из «Стратоплана». Это когда вы на основании предыдущего опыта и интуиции принимаете решение. Несмотря на возможную критику, это работает. Работает, как и все наши описанные выше процессы. Если у вас остались по ним вопросы, приглашаем в комментарии.
Что дальше?
Текущий техпроцесс комфортен и уютен как домашние тапочки. Проблема только в том, что в Veeam какое-то невидимое шило всегда подгоняет: быстрее, больше, еще, еще.
Cовсем недавно строили пилотные офисы в Финляндии и Чехии, а уже в этом году готовимся к большому открытию Пражского R&D центра на несколько сотен человек.
Лобби нашего пражского офиса
Недавно появился офис разработки в Израиле, растут команды в Канаде и Германии. Увеличивается количество совместных проектов разработки с HP, NetApp, Nutanix, EMC.
Мануфактура превращается в географически распределенный конвейер, а вместе с тем кристаллизуются и новые процессы. Впрочем, это тема для отдельной статьи.
Stay connected.
R&D-магия, или как справиться с неизведанным
Время чтения: 3 минуты
Отправим вам статью на:
Считается, что отдел R&D могут себе позволить только крупные компании, где такой отдел создается для поддержания имиджа, чем для решения конкретных прикладных задач. Владимир Черницкий возглавляет научно-исследовательский отдел (R&D) компании Azoft. Его команда занимается разработкой в сфере передовых технологий и решают задачи, требующие нетривиального подхода, фундаментальных знаний и нестандартного мышления. Зачем компании Azoft R&D-направление и какие задачи оно решает, читайте в интервью с Владимиром Черницким.
— Владимир, скажи, на что похожа ваша работа и какие задачи вы решаете?
— Наш отдел называется R&D (Research and Development) и занимается исследовательскими разработками в сфере программного обеспечения. Мы привлекаемся только к технически сложным, нелинейным и наукоёмким проектам, где необходимо абсолютно новое решение. В своей работе над такими проектами мы иногда обращаемся и к необычным специалистам, например, в Институт гидродинамики за секретными формулами имитации движения жидкости, консультируемся по новейшим алгоритмическим наработкам в области обработки изображений в Институте математики и т. д.
— Предположим, кто-то хочет присоединиться к вашей команде. О чем нужно знать заранее?
— Сейчас в моём подчинении всего два человека, но в Azoft любой сотрудник может присоединиться к решению наших задач и поломать голову вместе с нами. Просто не все готовы к тому, что предложенная идея может не сработать, может не подойти и пятая. Не надо огорчаться.
— Всегда ли сразу находится нужное решение? Долго ли приходится искать ответ на поставленную задачу?
Чаще всего процесс поиска решений выглядит так: есть идея, которую мы проверяем на пригодность. Проходит неделя, одну идею вычеркнули, но вместо нее появились ещё три варианта развития событий. Три не выстрелили — находятся ещё семь альтернативных, и так до тех пор, пока мы не решим задачу. Мы не стараемся найти оптимальную технологию (этим потом занимается производство), мы ищем хоть какое-то решение, такова специфика проектов в нашем отделе.Кстати, бывают и забавные проекты, например, как-то требовалось найти серединную линию персика для обработки фруктов на конвейерах. Справились.
— Ты помнишь первые проекты, над которыми работал ваш отдел?
— Один из первых R&D-проектов, которым мы занялись — мобильное приложение для рисования в технике эбру. Это турецкая традиция создания узоров на воде: ставится ёмкость с водой, на поверхности которой можно рисовать. Мы добились получения очень реалистичной картины, вода на экране планшета к смотрелась очень реалистично, колыхалась и реагировала как настоящая. И тут мы столкнулись с частой причиной не-реализации: для корректной работы приложения не хватает мощности девайса. Но в ближайшем будущем появятся такие гаджеты, и тогда мы запустим наше приложение.
— Все ли клиенты осознают риск, когда обращаются с R&D-задачей? Понимают ли, что результат в работе может быть совершенно неожиданным?
— Любой наш заказчик знает, что он обратился к нам с необычной задачей, и по времени проект может занять больший срок, чем мы заявили изначально.Мы думаем, что если чего-то нельзя сделать — значит, для этого ещё нет математического аппарата.
Взять того же Больцмана. Может, люди раньше другие были? Но я так и не могу себе представить, как в 19 веке учёный приходит домой, привязывает коней, топит печь и садится писать решёточные уравнения. Как ему только в голову пришло описать математически, как бултыхается вода в ванне? Тем не менее, всё укладывается в математику, всё можно объяснить на её языке.
— То есть с помощью математики и физики можно решить абсолютно любую задачу, с которой обратился клиент?
— Наш проект по передаче данных с помощью ультразвука, например, чистая физика, которая помогла решить поставленную задачу. Клиент запросил технологию, которая бы позволяла совершать финансовые транзакции с телефона. Как известно, не все гаджеты дружат между собой, поддерживают Bluetooth и Wi-Fi, NFC и т. д., но, очевидно, что у всех телефонов есть микрофон и динамик. От этого мы и начали отталкиваться при разработке решения — задействовали все наши знания о звуке и ультразвуке. За месяцы работы мы так углубились, хотя сначала думали, что все будет гораздо проще.
— Расскажи, пожалуйста, об особенностях своей работы?
Такое подразделение, как наше, есть разве что у гигантов индустрии. Исследованиями обычно занимаются институты, лаборатории. У больших компаний R&D — это роскошь, которую они могут себе позволить, тратя значительные суммы. Но мы органично вписались в общую структуру Azoft и решаем и прикладные задачи, которые становятся основой новых проектов с внешними клиентами. Мы стараемся любое исследование использовать в практических целях: мы включаем результаты в решение других проектов, пишем специализированные статьи, можем создавать собственные продукты по следам проведённой работы.
— С чего началась твоя карьера в R&D?
Я начинал как PHP-разработчик, но всегда был упёртым в решении сложных задач, руководство Azoft заметило, и несколько лет назад мне предложили организовать и возглавить отдел Research & Development.
— Говорят, есть какая-то особая магия в исследовательской работе. Так ли это?
— Иногда случаются и забавные истории, думаю, каждому исследователю знакомо такое чувство: ты чуть упустил контроль, «сделал, сам не понял что», и тут вдруг всё заработало. И потом думаешь: «А если бы я этого случайно не сделал, нашлось бы решение?!» Так и с некоторыми нерешёнными задачами — ходишь, ходишь, но задача не решается и это ужасно злит. Но все равно очень интересно — решиться и пойти туда, где никто не бывал, найти нужный путь и победить.
Подпишитесь
Оставьте адрес, и каждый месяц мы будем высылать свежую статью
о новых трендах в разработке програмного обеспечения.
