Rnd проект что это
Скрытые связи: как отдел R&D влияет на эффективность продаж
Эффективность работы фронт-офиса в принципе невозможна без налаженного должным образом взаимодействия с остальными подразделениями компании.
Фронт-офис — подразделение, отвечающее за взаимодействие с клиентами компании, чаще всего отдел продаж.
В наибольшей степени на продажи влияет работа блока R&D — то, насколько хорошо компания управляет продуктами, которые предлагает потребителям.
R&D (англ. Research and development — исследования и разработки) — функциональный блок в компании, объединяющий несколько подразделений и отвечающий за создание, выведение на рынок продукта и управление его жизненным циклом.
К блоку R&D относятся:
Процессный подход к работе компании объединяет все действия ее сотрудников, направленные на получение денег от клиентов, в сквозных основных бизнес-процессах.
Процессный подход к управлению строится на организации работы по выполнению описанных и внедренных бизнес-процессов (основных и поддерживающих), когда сотрудники компании взаимодействуют в первую очередь исходя из своих ролей, функционала и требований к выполнению шагов бизнес-процесса, а не из принадлежности к определенному бизнес-подразделению
Сквозной бизнес-процесс — это бизнес-процесс, проходящий через границы разных подразделений и тем самым вовлекающий в исполнение сотрудников этих подразделений; основной бизнес-процесс — тот, который обеспечивает компанию деньгами
Это означает, что отдел продаж не может существовать сам по себе, т.к. тесно связан с другими функциональными единицами.
Есть работа в RnD, или как уйти от монотонных и мелких задач
Недавно мы решили выделить RnD-активности Nexign (ранее «Петер-Сервис») в отдельное подразделение, распределенное по трем городам России — Москве, Санкт-Петербургу и Новосибирску. С тех пор мы активно ищем для него новых профессионалов, которые будут определять облик наших основных решений в будущем. В этом посте мы подробно расскажем о том, как работает RnD Nexign и кого мы очень ждем в нашей команде.
RnD Nexign разделяется в соответствии с тремя основными продуктами компании — BSS (Business Support System), NWM (Network Monetization) и IoT (Internet of Things). Команды не имеют привязки к какому-то одному городу, в одной и той же прекрасно срабатываются специалисты из всех городов присутствия. Талантливым сотрудникам, живущим в другом месте, мы можем помочь с переездом в любой из этих городов.
В основном все подразделения Nexign взаимодействуют с заказчиками, и их работа выстраивается в соответствии с запросами от клиентов. RnD отличается тем, что разрабатывает продукты, ориентируясь на продуктовый роадмап, создаваемый в продуктовом подразделении компании на основании анализа рынка и потребностей клиентов в целевом сегменте. На основе роадмапа и продуктовых требований бизнес-аналитики создают требования для разработки продуктов.
Анализируя запросы, RnD определяет архитектуру, организацию всех наших продуктов. Разработка проудктов в RnD организована в двухмесячные суперспринты, к окончанию каждого из которых в продукте появляются новая функциональность на уровне системы. По их итогам RnD показывает демо для продуктовой команды.
NWM — Network Monetization
NWM представляет собой комплексное решение, с помощью которого можно обеспечивать тарификацию и управлять политиками предоставления сервисов в режиме реального времени. NWM охватывает все известные сетевые стандарты и услуги — мобильную и фиксированную связь, VAS- и OTT-сервисы, электронную коммерцию и платежные карты. NWM соответствует отраслевым стандартам, и ее можно интегрировать с существующими телекоммуникационными сетями и биллинговыми системами. В общем, это один из ключевых элементов инфраструктуры любого BSS-решения для поставщиков связи.
Умными словами: NWM — это 3GPP PCC архитектура с основным узлом OCS (Online Charging System), дополнительными функциями (Policy and Charging Control Function) и вспомогательными сервисами, например, UDR (User Data Repository).
Самый крупный пользователь нашей NWM-системы — это телеком-оператор с аудиторией порядка 70 млн активных абонентов с общим числом транзакций в секунду в районе 30-50 тысяч. Для разработки такого высоконагруженного сервиса мы используем язык программирования C++. У нас разработан свой набор системных библиотек под данный язык программирования, на котором разрабатываются все компоненты нашей системы. Эти компоненты можно комбинировать и кастомизировать в зависимости от пожеланий заказчиков.
Команда разработчиков NWM делится на три группы. Высококвалифицированные программисты занимаются разработкой ядра системы. Другие разработчики на C++ разрабатывают с NWM готовые сервисы. А третья группа занимается кастомизацией — они работают со скриптовым языком программирования Lua, который довольно активно используется в телекоме, например, для кастомизации сервисных платформ Cisco.
Особенностью нашей NWM-системы является то, что она унаследовала большое количество компонентов от других продуктов. Сейчас на одного разработчика NWM приходится до 2-3 подсистемы — сервисов, обеспечивающих конкретную PCC-функцию. Такой объем не создает неприятностей благодаря отлаженной работе специалистов по тестированию — их у нас примерно столько же, сколько и разработчиков. Мы стараемся по максимуму исключить этапы ручного тестирования за счет автоматизации, но это не избавляет разработчиков от обязанности покрывать код юнит-тестами.
Сейчас в рамках роадмапа мы развиваем NWM в сторону NFV, делим монолитные компоненты на микросервисы, в том числе для возможности построения облачного решения.
BSS — Business Support System
BSS (Business Support System) — это комплексное решение для обслуживания деловых бизнес-процессов, софтверное сердце операторского бизнеса. В числе задач BSS — распознать, тарифицировать, посчитать клиента, предоставить ему услуги, выставить счет, принять оплату и сделать это так, чтобы всем было приятно. Даже этот перечень уже выглядит внушительно. А сейчас, с развитием операторского бизнеса BSS усложняются и берут на себя все новые задачи. Когда-то все ограничивалось отправкой служебных смс и формированием допустимых отрицательных лимитов, а сейчас, например, уже подключается и продвинутый адвайзинг, подсказки новых тарифов, индивидуальные предложения новых услуг.
Есть миф о том, что BSS — это закостенелая система, где ничего интересного не предвидится. Это не так. По своей структуре BSS — это большой набор различных сервисов, где есть место для множества современных стандартов и технологий: machine learning и клаудификация, omnichannel и микросервисная архитектура, в будущем — 5G и активное внедрение AI. Больше о потенциале BSS можно почитать в одном из наших предыдущих постов.
В рамках всего RnD мы готовы создавать команды по тем опенсорсным решениям, в которых мы видим перспективу для развития продуктов. Любой специалист, в принципе, может найти себе место в RnD BSS, если его работа укладывается в два основных вектора развития BSS Nexign — уменьшение стоимости и увеличение стабильности сервиса. Если говорить о сугубо технических специалистах — мы очень ждем экспертов по NoSQL, Java, автоматизированному и нагрузочному тестированию. А еще будем рады бизнес-аналитикам и архитекторам с опытом работы в телекоме, знаниями стандартов и требований отрасли.
IoT — Internet of Things
Наша IoT-платформа позволяет интегрироваться с различными датчиками, агрегировать и продавать информацию с них. На основе этой платформы наши заказчики могут строить готовые IoT-решения в разных областях: логистика, «умный город», промышленность и не только.
В RnD IoT, как и в двух других направления, также внедрен полный цикл производства, начиная с бизнес-аналитики и заканчивая сборкой на информационных стендах. Большую часть технологического стека составляет Java-бэкенд. Помимо него, есть команды, которые создают UI в web-приложении и делают реалтайм-интеграцию с сетевыми устройствами через C++ и Lua.
Общие пожелания
Узкие технические запросы мы привели выше. Теперь — что мы ждем от всех кандидатов в RnD. Очень важна высокая мотивация, желание проявить себя и активно развиваться, стремление видеть продукт в целом, а не только в рамках своего кусочка кода. Мы не требуем, чтобы наши кандидаты сразу выдавали ответы на сложные задачи — согласитесь, гораздо ценнее умение самостоятельно прийти к решению, логически обосновав все шаги на пути.
Со своей стороны, мы готовы лично поддержать каждого новичка и предоставить ему опытного ментора/куратора — как правило, тимлида или техлида команды. К ним можно обратиться по любым вопросам, связанным с заданием. По просьбе новичков кураторы детализируют задачи, объяснят нюансы, охотно делятся лучшими практиками — в общем делают все то, чтобы новый человек как можно быстрее стал полноценным членом команды.
Будем рады ответить на вопросы в комментариях.
Внутренняя кухня 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.
— Говорят, есть какая-то особая магия в исследовательской работе. Так ли это?
— Иногда случаются и забавные истории, думаю, каждому исследователю знакомо такое чувство: ты чуть упустил контроль, «сделал, сам не понял что», и тут вдруг всё заработало. И потом думаешь: «А если бы я этого случайно не сделал, нашлось бы решение?!» Так и с некоторыми нерешёнными задачами — ходишь, ходишь, но задача не решается и это ужасно злит. Но все равно очень интересно — решиться и пойти туда, где никто не бывал, найти нужный путь и победить.
Подпишитесь
Оставьте адрес, и каждый месяц мы будем высылать свежую статью
о новых трендах в разработке програмного обеспечения.