В России растет интерес бизнеса к разработке собственного IT-оборудования, в частности серверов. Это нерядовая задача, а компании, которые это делают, есть даже не в каждой стране. Как правильно организовать такую работу, рассказал Юрий Ярков (GAGAR>N).
Весной и летом 2022 года аналитики предсказывали резкое сокращение отечественного IT-рынка — от 10 до 39%. Однако, несмотря на экономические трудности, выручка IT- сектора все же выросла. В конце февраля вице-премьер Дмитрий Чернышенко объявил, что в 2022 году российские IT-компании заработали 2,38 трлн руб. Это на 35,3% больше, чем годом ранее.
Особенно отличились компании, которые занимаются производством и дистрибуцией аппаратного обеспечения: даже в таких условиях их доходы увеличились на 42,1%.
Из-за прекращения прямых поставок зарубежного оборудования возникла потребность значительно увеличить производственные мощности местных поставщиков. Завозить аппаратное обеспечение параллельным импортом слишком дорого и сложно, а работать на нем без гарантии и техподдержки — рискованно.
Также сейчас растет озабоченность вопросами безопасности критической информационной инфраструктуры. Поэтому в следующие несколько лет в стране планируют создать базу для полного импортозамещения аппаратного обеспечения, а к 2030 году — наладить выпуск компонентной базы. Поэтому уже видно, как в России растет интерес к организации собственной разработки оборудования.
Разберем, что нужно учесть при ее запуске и развитии.
Матричная структура
Разработка серверного оборудования — долгий и довольно трудоемкий процесс, в котором участвует большое количество разнопрофильных специалистов:
Эффективность работы такой разнородной команды зависит от того, как организовано управление и насколько хорошо работают коммуникации.
Наш опыт говорит, что лучше всего на производстве работает матричная структура управления, когда организовано несколько уровней руководства.
Разработкой в нашей компании занимается продуктовое направление, во главе которого директор по продуктам.
Заказчиком любого конечного продукта выступает продуктовый офис. Он анализирует, какой продукт нужно произвести, и выносит свои предложения на защиту на продуктовом комитете: проект, бюджет и жизненный цикл продукта.
В продуктовый комитет входят:
Продуктовый комитет оценивает бизнес-план каждого продукта, который включает в себя:
После того как продукт защищен, следует обращение в проектный офис — для оформления защищенного бизнес-плана в проект. На этапе планирования проекта обсуждается, какую команду собрать, кого в нее привлечь.
После оформления проекта (для этого используется единая методология) проектный офис ставит задачи для исполнителей, контролирует их исполнение и отчитывается перед руководством и заказчиками.
Все сотрудники департамента разработки подчиняются одновременно и руководителям проектов, и линейным руководителям отделов.
Роль линейных руководителей — экспертная, архитектурная: они как тимлиды координируют выполнение задач. А сами задачи поступают от руководителей проектов, которые определяют и
приоритетность их выполнения.
Кроме того, предусмотрены «горизонтальные» команды. В компании есть несколько групп специалистов, которые сильны в определенных технологиях: серверном оборудовании, электропитании, системах хранения данных. Это не жестко закрепленные, формальные юниты. Они собираются по ходу выполнения проектов из разных отделов для решения конкретных задач.
Параллельно продакт-менеджеры следят за тем, чтобы в процессе создавался именно тот продукт, который требуется по ТЗ, — без отхода от стандартов, роста себестоимости и других отклонений. В их зоне ответственности и будущий коммерческий успех продукта.
Сквозной контроль
Основная сложность при организации разработки аппаратной части — обеспечить качественный результат на каждом этапе создания и выпуска продукции. Важнейшую роль здесь играет контроль процесса. Он должен носить сквозной характер — «от А до Я».
Такой подход помогает отслеживать выполнение всех поставленных задач и KPI на каждом этапе разработки продукта, соблюдать требования и стандарты. Кроме того, прозрачность процесса позволяет быстрее адаптировать продукт к изменениям на рынке.
Матричная структура продуктовой разработки позволяет отслеживать риски в сквозном режиме. Например, если на этапе разработки на уровне ТЗ и спецификаций различных элементов не предусмотреть, что ключевые компоненты могут быть недоступны, а также есть вероятность ценовых скачков, то экономическая целесообразность выпуска продукта может обнулиться.
Качество коммуникаций
Чтобы структура работала на должном уровне, важно организовать качественную коммуникацию между всеми участниками процесса — на всех уровнях и на протяжении всего цикла разработки.
Так, на этапе формирования требований к будущему продукту важно, чтобы взаимодействие было налажено не только между подразделениями разработки, но и с коммерческими единицами, пресейлом, службой клиентского сервиса. Благодаря обратной связи от них продукт будет лучше удовлетворять требованиям и запросам клиентов.
Обычно контроль за взаимодействием между специалистами в процессе разработки берет на себя руководитель проекта. В его ведении как внутренние коммуникации в конкретной команде, так контакт с другими подразделениями компании.
Управление процессами
Создание и выпуск серверного оборудования отличается длительностью сроков. Каждый этап довольно долгий.
Например, разработка схемотехники для оборудования может длиться один-два месяца, топологии — три-четыре. При этом команды не должны простаивать: пока одна группа или отдел реализует свою фазу, остальные должны быть заняты на других проектах.
Во время реализации проектов важно использовать лучшие практики: собственный предыдущий успешный опыт, экспертизу и компетенции, а также гибридный вариант из разных методологий управления проектами. У нас представляет собой сочетание классической каскадной модели — Waterfall с ее модификациями и гибких методологий Agile — kanban и scrum. Это возможность проводить примерную оценку ресурсов, стоимости и сроков разработки, а также быть гибкими и избежать инерционности и высоких рисков классического каскадного подхода.
Поскольку классический scrum-подход здесь не работает, мы используем гибридный подход — «скрамбан» (scrum-ban). Планирование и спринты берутся из scrum, а способ продвижения задач — из kanban. Это позволяет эффективно управлять проектными командами с поправкой на сроки итераций. Например, мы используем двухнедельные спринты и у нас нет scrum-мастера — все управление в руках руководителя проектов, полной свободы вне его надзора за проектом ни у кого нет.
Верная мотивация
Все эти принципы позволяют выстроить достаточное количество уровней для контроля и управления, что в итоге практически исключает риски упустить по ходу работ что-то критически важное, что может привести к сбоям.
Есть еще один дополнительный инструмент, который мы используем сами и рекомендуем рынку, — формировать мотивацию членов команды. Принадлежность к большому делу, серьезному уникальному проекту — бесценна. А запуск собственного производства серверного оборудования, успешный выпуск продукции этого класса локальной разработки — события нерядовые, происходят они далеко не в каждой стране мира. Оказаться причастным к задачам подобного уровня может стоить для многих IT-энтузиастов гораздо больше, чем высокие зарплаты и внушительные соцпакеты.
Именно на этом стоит делать акцент руководству в работе с командой. Незаурядная задача — залог высокой мотивации людей, а заряженная команда — самый важный двигатель всего процесса.
Весной и летом 2022 года аналитики предсказывали резкое сокращение отечественного IT-рынка — от 10 до 39%. Однако, несмотря на экономические трудности, выручка IT- сектора все же выросла. В конце февраля вице-премьер Дмитрий Чернышенко объявил, что в 2022 году российские IT-компании заработали 2,38 трлн руб. Это на 35,3% больше, чем годом ранее.
Особенно отличились компании, которые занимаются производством и дистрибуцией аппаратного обеспечения: даже в таких условиях их доходы увеличились на 42,1%.
Из-за прекращения прямых поставок зарубежного оборудования возникла потребность значительно увеличить производственные мощности местных поставщиков. Завозить аппаратное обеспечение параллельным импортом слишком дорого и сложно, а работать на нем без гарантии и техподдержки — рискованно.
Также сейчас растет озабоченность вопросами безопасности критической информационной инфраструктуры. Поэтому в следующие несколько лет в стране планируют создать базу для полного импортозамещения аппаратного обеспечения, а к 2030 году — наладить выпуск компонентной базы. Поэтому уже видно, как в России растет интерес к организации собственной разработки оборудования.
Разберем, что нужно учесть при ее запуске и развитии.
Матричная структура
Разработка серверного оборудования — долгий и довольно трудоемкий процесс, в котором участвует большое количество разнопрофильных специалистов:
- конструкторы,
- схемотехники,
- топологи,
- программисты,
- тестировщики,
- технологи и т.д.
Эффективность работы такой разнородной команды зависит от того, как организовано управление и насколько хорошо работают коммуникации.
Наш опыт говорит, что лучше всего на производстве работает матричная структура управления, когда организовано несколько уровней руководства.
Разработкой в нашей компании занимается продуктовое направление, во главе которого директор по продуктам.
Заказчиком любого конечного продукта выступает продуктовый офис. Он анализирует, какой продукт нужно произвести, и выносит свои предложения на защиту на продуктовом комитете: проект, бюджет и жизненный цикл продукта.
В продуктовый комитет входят:
- директор по продуктам,
- другие топ-менеджеры по разным направлениям,
- управляющие партнеры компании.
Продуктовый комитет оценивает бизнес-план каждого продукта, который включает в себя:
- исследование рынка,
- план разработки,
- план производства и продаж,
- анализ общей ситуации в отрасли.
После того как продукт защищен, следует обращение в проектный офис — для оформления защищенного бизнес-плана в проект. На этапе планирования проекта обсуждается, какую команду собрать, кого в нее привлечь.
После оформления проекта (для этого используется единая методология) проектный офис ставит задачи для исполнителей, контролирует их исполнение и отчитывается перед руководством и заказчиками.
Все сотрудники департамента разработки подчиняются одновременно и руководителям проектов, и линейным руководителям отделов.
Роль линейных руководителей — экспертная, архитектурная: они как тимлиды координируют выполнение задач. А сами задачи поступают от руководителей проектов, которые определяют и
приоритетность их выполнения.
Кроме того, предусмотрены «горизонтальные» команды. В компании есть несколько групп специалистов, которые сильны в определенных технологиях: серверном оборудовании, электропитании, системах хранения данных. Это не жестко закрепленные, формальные юниты. Они собираются по ходу выполнения проектов из разных отделов для решения конкретных задач.
Параллельно продакт-менеджеры следят за тем, чтобы в процессе создавался именно тот продукт, который требуется по ТЗ, — без отхода от стандартов, роста себестоимости и других отклонений. В их зоне ответственности и будущий коммерческий успех продукта.
Сквозной контроль
Основная сложность при организации разработки аппаратной части — обеспечить качественный результат на каждом этапе создания и выпуска продукции. Важнейшую роль здесь играет контроль процесса. Он должен носить сквозной характер — «от А до Я».
Такой подход помогает отслеживать выполнение всех поставленных задач и KPI на каждом этапе разработки продукта, соблюдать требования и стандарты. Кроме того, прозрачность процесса позволяет быстрее адаптировать продукт к изменениям на рынке.
Матричная структура продуктовой разработки позволяет отслеживать риски в сквозном режиме. Например, если на этапе разработки на уровне ТЗ и спецификаций различных элементов не предусмотреть, что ключевые компоненты могут быть недоступны, а также есть вероятность ценовых скачков, то экономическая целесообразность выпуска продукта может обнулиться.
Качество коммуникаций
Чтобы структура работала на должном уровне, важно организовать качественную коммуникацию между всеми участниками процесса — на всех уровнях и на протяжении всего цикла разработки.
Так, на этапе формирования требований к будущему продукту важно, чтобы взаимодействие было налажено не только между подразделениями разработки, но и с коммерческими единицами, пресейлом, службой клиентского сервиса. Благодаря обратной связи от них продукт будет лучше удовлетворять требованиям и запросам клиентов.
Обычно контроль за взаимодействием между специалистами в процессе разработки берет на себя руководитель проекта. В его ведении как внутренние коммуникации в конкретной команде, так контакт с другими подразделениями компании.
Управление процессами
Создание и выпуск серверного оборудования отличается длительностью сроков. Каждый этап довольно долгий.
Например, разработка схемотехники для оборудования может длиться один-два месяца, топологии — три-четыре. При этом команды не должны простаивать: пока одна группа или отдел реализует свою фазу, остальные должны быть заняты на других проектах.
Во время реализации проектов важно использовать лучшие практики: собственный предыдущий успешный опыт, экспертизу и компетенции, а также гибридный вариант из разных методологий управления проектами. У нас представляет собой сочетание классической каскадной модели — Waterfall с ее модификациями и гибких методологий Agile — kanban и scrum. Это возможность проводить примерную оценку ресурсов, стоимости и сроков разработки, а также быть гибкими и избежать инерционности и высоких рисков классического каскадного подхода.
Поскольку классический scrum-подход здесь не работает, мы используем гибридный подход — «скрамбан» (scrum-ban). Планирование и спринты берутся из scrum, а способ продвижения задач — из kanban. Это позволяет эффективно управлять проектными командами с поправкой на сроки итераций. Например, мы используем двухнедельные спринты и у нас нет scrum-мастера — все управление в руках руководителя проектов, полной свободы вне его надзора за проектом ни у кого нет.
Верная мотивация
Все эти принципы позволяют выстроить достаточное количество уровней для контроля и управления, что в итоге практически исключает риски упустить по ходу работ что-то критически важное, что может привести к сбоям.
Есть еще один дополнительный инструмент, который мы используем сами и рекомендуем рынку, — формировать мотивацию членов команды. Принадлежность к большому делу, серьезному уникальному проекту — бесценна. А запуск собственного производства серверного оборудования, успешный выпуск продукции этого класса локальной разработки — события нерядовые, происходят они далеко не в каждой стране мира. Оказаться причастным к задачам подобного уровня может стоить для многих IT-энтузиастов гораздо больше, чем высокие зарплаты и внушительные соцпакеты.
Именно на этом стоит делать акцент руководству в работе с командой. Незаурядная задача — залог высокой мотивации людей, а заряженная команда — самый важный двигатель всего процесса.