Управление hardware-проектами редко похоже на классический IT-менеджмент. Здесь нельзя бесконечно двигать сроки, менять требования по ходу и рассчитывать, что ошибку получится быстро исправить в следующем релизе. В этой сфере слишком многое завязано на жесткие этапы, взаимозависимость команд и высокую цену любой поздней правки. 

Меня зовут Дарья Капустина, я — старший менеджер проектов в департаменте беспроводных технологий связи YADRO. В статье расскажу, как я пришла в управление hardware-проектами и чем такая работа отличается от привычного проджект-менеджмента в software.

Как я пришла в hardware

Мой путь в управление hardware-проектами не был линейным. Я пришла сюда не с готовым планом стать проджект-менеджером в полупроводниковой индустрии. Больше пяти лет я работала инженером: занималась разработкой печатных плат на заводе в Санкт-Петербурге.

Этот опыт дал мне важную базу: техническое мышление, понимание инженерной среды и привычку разбираться в деталях, а не оставаться на уровне общих слов.

Но довольно быстро я поняла, что хочу больше разноплановых задач и влияния на итоговый результат. Я перешла в небольшую компанию, которая занималась металлообработкой и делала детали для авиационных двигателей. Этот этап оказался полезным, потому что именно там я поняла три вещи:

• в менеджменте мне действительно интересно,

• машиностроение — не совсем мое,

• мне хочется вернуться к электронике.

Так я пришла в полупроводниковую индустрию.

Перейти из инженерии в управление проектами мне помогла одна простая внутренняя установка: мне всегда было важно, чтобы работа была сделана вовремя.

Когда ты инженер и тебя не ставят в жесткие временные рамки, легко сосредоточиться только на своей задаче — спокойно делать, разбираться, доводить ее до ума. Но мне в какой-то момент стало важно не только что мы делаем, но и когда это будет готово. Хотелось, чтобы результатом можно было воспользоваться, а не просто считать задачу технически завершенной.

Наверное, здесь для меня и началось проектное мышление. Ты смотришь уже не только на свою часть работы, но и на весь процесс целиком: кто от кого зависит, где может возникнуть задержка, кого нужно синхронизировать и что нужно сделать, чтобы работа команды принесла нужный результат.

В YADRO я занимаюсь управлением проектами в области разработки и верификации IP — это фундаментальный слой hardware-разработки, на котором строятся более высокоуровневые решения. Слежу за сроками, синхронизирую команды, управляю рисками и помогаю довести систему до работоспособного состояния. От качества и готовности этих компонентов зависят следующие этапы: интеграция, тестирование и выпуск.

В hardware любая ошибка в сроках, коммуникации или ожиданиях сразу запускает эффект домино, который бьет по всему проекту.

При этом технический бэкграунд не делает вход в hardware легким автоматически. Даже если у тебя есть инженерный опыт, новая предметная область все равно сначала кажется сложной. Но техническая база дает опору:

• ты быстрее понимаешь терминологию,

• можешь задавать более точные вопросы,

• легче разговариваешь с инженерами на одном языке,

• быстрее собираешь общую картину проекта.

Еще одна вещь, которую я быстро поняла: в hardware нельзя ждать, что тебе все подробно объяснят и разложат по шагам. В первые месяцы важно самой ходить к людям, задавать вопросы, разбираться в процессах и буквально по кусочкам собирать картину того, как все устроено.

Для меня это стало важным уроком: в hardware-проекты нельзя входить пассивно. В этой области нужно уметь самой добывать информацию и формировать общую картину: разговаривать с людьми из команд, уточнять, как устроен процесс, разбираться в новых терминах и связывать между собой разрозненные знания.

Как устроен hardware-проект по этапам

Если смотреть на hardware-проект изнутри, он не выглядит как одна длинная линия, где команда просто движется от задачи к задаче. Для меня это, скорее, цепочка этапов, в которой на каждом шаге нужно не только что-то сделать, но и проверить, что результат действительно соответствует требованиям. Еще на этапе планирования появляются контрольные точки, на которых команды должны синхронизироваться и обмениваться информацией. Разберемся, как это выглядит на уровне процесса.

Начинаем разработку с командой архитекторов

Архитекторы создают структуру будущего IP-блока или системы с учетом требований бизнеса. Описывают функциональность, интерфейсы, ограничения по производительности, энергопотреблению, пропускной способности и другие ключевые характеристики. На этом этапе создается архитектура, которая задает общее направление всей дальнейшей разработке.

Прописываем микроархитектуру с RTL-командой

Получив архитектурные требования, инженеры детализируют их до уровня микроархитектуры: определяют внутреннюю организацию блоков, пайплайны, FSM, буферы, механизмы обработки данных и взаимодействие между модулями. На основе микроархитектурной спецификации разрабатывается RTL-код.

Проверяем RTL-реализацию unit-level верификацией

Команда верификации разрабатывает план тестирования, определяет покрытие функциональности и создает тестовую среду для проверки конкретного IP-блока. На этом этапе проверяется корректность работы RTL относительно спецификации: валидируются интерфейсы, обработка ошибок, timing-сценарии и другие аспекты поведения блока.

Интегрируем отдельные IP-блоки в более крупные подсистемы

На уровне subsystem verification проверяется взаимодействие нескольких блоков между собой: корректность передачи данных, согласованность протоколов, работа shared-ресурсов, синхронизация и обработка комплексных сценариев, которые невозможно полноценно проверить на уровне отдельных IP.

Собираем систему и проводим system-level верификацию

На этом этапе запускаются сложные end-to-end сценарии, которые затрагивают всю цепочку обработки данных через множество IP-блоков и подсистем. Проверяется не только функциональная корректность, но и поведение системы в условиях, близких к реальной эксплуатации.

Поэтому моя роль в проекте — это не только контроль сроков. Я слежу, чтобы этапы не разваливались по времени, но этим все не ограничивается. На мне еще и вещи, без которых проект просто перестает быть управляемым: реестр рисков, мониторинг этих рисков, поиск вариантов митигации, регулярная отчетность, коммуникация со смежными командами и выстраивание самих правил взаимодействия между ними. Если мы что-то сделали, а зависящая от нас команда об этом не знает, то работа не завершена. Значит, сообщение, синхронизация и следующий шаг тоже лежат на мне.

Наверное, именно в этом и есть ключевая особенность hardware PM: я управляю не только задачами, но и связями между ними. В таких проектах недостаточно хорошо понимать, что делает одна команда. Нужно видеть всю конструкцию целиком — от требований и разработки до верификации, интеграции и передачи дальше. И чем сложнее проект, тем больше моя работа становится похожа не на классическое администрирование, а на постоянную сборку системы из множества зависимых частей.

Чем hardware-проекты отличаются от software

Про управление проектами чаще всего говорят именно в контексте software-разработки — поэтому многие подходы и ожидания автоматически переносят и на hardware, но при внешне похожих процессах логика работы здесь совсем другая. 

Когда я пришла в hardware, мне довольно быстро стало понятно: управлять такими проектами так же, как software-разработкой, не получится. Со стороны может казаться, что разница только в предмете работы — здесь IP-ядра, там программный код. Но разница глубже: в hardware у ошибки более высокая цена, у сроков другой вес, а у изменений по ходу проекта — совсем другие последствия.

Hardware-требования должны быть зафиксированы на входе

Есть отдельный этап сбора требований, после которого обязательно идет детальная проработка архитектуры, и только затем может начинать разработка — такая этапность очень важна. В software к этому часто относятся гибче: можно что-то доработать по ходу, уточнить в следующем спринте, выпустить промежуточную версию, а потом еще что-то поменять. 

Попытка ускорить hardware-процесс может его замедлить

Например, если начинать собирать битстримы и идти с RTL без верификации, то кажется, что можно сэкономить время. Но на деле ты просто переносишь проблему дальше по цепочке. В итоге другая команда начинает дебажить то, что еще не должно было попасть на их этап.

В hardware цена ошибки выше

Проект в hardware завязан не только на внутреннюю разработку, но и на производство. В какой-то момент нужно попасть в конкретное окно на фабрике, а эти окна бронируются на год и больше вперед. Если срок уезжает, это уже не просто сдвиг в календаре, а реальные потери — и по деньгам, и по всей цепочке работ.

Для меня это был один из самых показательных моментов: в software можно думать категориями «поправим позже», а в hardware очень быстро наступает момент, когда «позже» уже стоит слишком дорого. Именно поэтому здесь гораздо жестче относятся к требованиям, контрольным точкам и любым изменениям после старта.

В hardware многие проблемы становятся видны не сразу

Например, команда может что-то разработать, верифицировать, передать для запуска сложных тестов — и только в этот момент выясняется, что в архитектуре что-то недосмотрели. Тогда появляется change request, и проекту приходится откатываться назад: вносить архитектурные правки, заново согласовывать изменения и пересчитывать сроки. 

Здесь особенно важно то, что проблема редко остается локальной. Если меняется архитектура, это почти всегда влияет сразу на несколько направлений: разработка, верификация, интеграция подсистемы в более крупную систему, написание низкоуровневого софта и сценарных тестов, сборки битстримов, бэкенд и следующие этапы по цепочке.

Я не считаю, что hardware живет только по жестким waterfall или v-model, а software — только по agile. В дивизионе полупроводников были двухнедельные итерации, но их использовали не для того, чтобы каждые две недели показывать результат. У них другая цель — научить команду оценивать свои силы, планировать трудозатраты и не распыляться на все задачи сразу. Можно взять инструмент из гибких подходов, но использовать его не как идеологию, а как рабочий способ держать фокус.

По сути, спринт у нас был нужен не для демонстрации результата, а для более приземленных вещей:

• ограничить объем внимания команды и количество задач на одного человека,

• помочь инженерам более реалистично оценивать работу,

• не заставлять людей все время смотреть на огромный бэклог.

Оценка работы команды

Hardware-инженерам обычно ближе человеко-часы: это понятная и конкретная для них логика. Софтверные команды чаще живут в story points и других абстракциях. Во многом это связано с историей самих индустрий: hardware долгое время развивалась вокруг инженерного и производственного подхода, где важны были точные расчеты, этапность и предсказуемость сроков. Software, наоборот, быстрее пришла к гибким методологиям, где важнее скорость изменений и возможность постоянно пересобирать приоритеты. Для меня это тоже хороший индикатор того, что даже язык планирования в двух мирах разный. Значит, и управлять ими одинаково нельзя.

Еще одно важное отличие: hardware-проекты, как правило, занимают от года и больше, тогда как в software сроки чаще измеряются неделями или месяцами.

В hardware-проектах так важны документация, этапность, жесткие точки синхронизации и заранее согласованные критерии готовности. Это способ удержать под контролем систему, где любая поздняя правка может слишком дорого обойтись всей команде.

Наверное, главное различие я бы сформулировала так: в software ты часто управляешь развитием продукта, а в hardware — еще и стоимостью ошибки. Причем в эту стоимость входят не только сроки команды, но и производство, время на фабрике, дорогое лабораторное оборудование, стенды, FPGA-сборки. И это меняет всю логику проджект-менеджемента.

В проекты, которые я курирую, как раз нужны инженеры. Обратите внимание на наши вакансии:

• Инженер по верификации (Wireless & Systems)

• Архитектор беспроводных ИС/Wireless RF IC Architect

Кто участвует в hardware-проекте и почему менеджер здесь работает не с одной командой, а с целой системой

Когда я начала глубже работать в hardware-проектах, мне быстро стало понятно: здесь нельзя мыслить одной командой. В software еще можно сказать: у нас есть команда продукта, разработки и тестирования. В hardware так не получается. Здесь проект почти сразу собирается из нескольких контуров, и моя задача — не просто следить за задачами, а постоянно держать в голове, кто от кого зависит и что произойдет, если один участок задержится.

У меня нет «своей» команды в классическом смысле. Я не управляю всеми людьми напрямую. Я работаю через тимлидов: у них есть свои команды. Моя роль — синхронизировать их друг с другом, договариваться о ресурсах, сроках и приоритетах.

В hardware-проекте обычно одновременно вовлечены: 

• RTL-дизайн,

• unit-верификация,

• системная верификация, 

• backend-департамент,

• software-департамент,

• команды драйверов,

• прототипирование и другие смежные участники. 

Со стороны это может выглядеть как просто список функций. Но на практике это живая цепочка зависимостей.

Например, software-команда может писать для нас сложные тесты, которые запускаются уже на битстриме. Но если у нее нет битстрима, то команда не может ничего проверить и запустить. А битстрим, в свою очередь, собирается из RTL, который сделали и верифицировали коллеги из hardware-разработки. Получается простая, но очень показательная вещь: одна команда формально может быть готова работать, но фактически не может сдвинуться с места, потому что ждет артефакт от другой.

Чем занимается проджект-менеджер каждый день

Если смотреть на мой день с практической стороны, то он редко состоит из чего-то одного. 

Коммуникация. Большая часть дня — это митинги самой разной направленности: от технических синков внутри команд до крупных проектных статусов, где мы сверяемся по срокам, зависимостям и общему состоянию проекта.

Процессы вокруг разработки. Я слежу за тем, чтобы весь процесс работал корректно: как приоритизируются баги, как они распределяются между командами, где возникают блокеры и кому нужна помощь, чтобы их разобрать и не тормозить проект.

Планирование следующей фазы проекта. Нужно связать между собой разработку, верификацию, готовность моделей и передачу результатов в другие команды — например, на интеграцию в другую подсистему. То есть моя работа почти всегда про стыковку нескольких процессов сразу.

Отслеживание метрик. Не ради самих цифр, а чтобы понимать, где процессы начинают давать сбой и что можно улучшить.

Управление рисками. В hardware они редко появляются внезапно. Чаще сначала возникают слабые сигналы: где-то команда не успевает, где-то растет количество багов, где-то начинают «плыть» зависимости.

Моя задача — отслеживать такие вещи заранее и понимать, какие риски действительно влияют на проект. Я их фиксирую и ищу способы минимизировать последствия: перераспределить ресурсы, пересобрать план, заранее синхронизировать команды.

Где hardware-проекты чаще всего ломаются

Главная иллюзия в hardware-проектах — думать, что раз процесс выстроен по этапам, то дальше все пойдет предсказуемо. На практике проект начинает ломаться не потому, что у команды нет плана, а потому, что реальность оказывается сложнее исходной схемы.

Одна из самых частых причин — изменения требований уже после старта

В hardware это быстро бьет по архитектуре, срокам и ресурсам. Например, бывало так: команда уже начала разработку, а потом на уровне бизнеса принималось решение сократить часть функциональности, чтобы выпустить продукт раньше. После этого приходилось перестраивать и архитектуру, и график, и распределение людей.

Новая разработка, которую сложно точно оценить

Команда может быть уверена, что уложится, скажем, в полтора месяца верификации. Но проходит еще столько же времени, а работа все так же далека от завершения. Это особенно болезненно, когда на запланированные сроки уже завязаны другие команды.

Еще один риск — архитектурные проблемы, которые всплывают слишком поздно

На сложных тестах или во время верификации может выясниться, что в архитектуре что-то не учли. Тогда появляется change request, и проекту приходится возвращаться на шаг назад. В моей практике такие истории могли сдвигать сроки на полгода.

К этому часто добавляются еще две вещи: R&D продолжается уже по ходу продуктовой разработки, специалистов не хватает и усиление одного участка часто ослабляет другой.

Отдельно ситуацию усложняют сроки, спущенные сверху. Это тот случай, когда команда получает красивую дату раньше, чем успевает реалистично оценить объем работы. В результате проект живет в отрыве от реальности, а не по плану.

Что делать менеджеру, когда сроки уже сдвигаются

Когда в hardware-проекте начинают сдвигаться сроки, главное — не делать вид, что все еще идет по плану. Если поехал один этап, то он почти всегда тянет за собой зависимые команды. Поэтому первый шаг — как можно раньше признать проблему и начать с ней работать.

Сначала нужно быстро уведомить всех, кто зависит от нашего результата. В hardware задержка редко остается локальной: если мы не успеваем, значит, свои планы должны пересмотреть верификация, интеграция, software и другие участники цепочки.

Дальше я обычно рассматриваю разные варианты:

• подключить новых людей,

• перераспределить ресурсы,

• сократить scope,

• пересобрать критерии ближайшего этапа.

Но в hardware редко бывает быстрое решение. Если добавить людей нельзя, а старый план уже не работает, остается только пересматривать объем работ. Иногда это значит договориться, что к ближайшему этапу команда делает не весь изначальный объем, а только минимально необходимую часть.

У нас, например, бывало такое: для достижения очередной контрольной точки проекта мы заранее договаривались, какую часть тестов считаем достаточной для текущего релиза, а какие проверки переносим на следующий этап. Это не идеальный сценарий, но иногда именно так удается вернуть проект в управляемое состояние и не останавливать всю цепочку работ.

В такой ситуации моя задача как менеджера — не «спасти все», а быстро пересобрать ожидания: честно сообщить о сдвиге, договориться о новом объеме работ и зафиксировать реалистичный план. Именно такой подход в hardware обычно работает лучше, чем давление на команду и попытка любой ценой удержать старые сроки. 

Какие навыки нужны менеджеру в hardware-проектах

Для меня проджект-менеджмент в hardware — это про способность работать в сложной технической среде, где многое держится на коммуникации, точности и умении быстро формировать полную картину. Здесь нужно понимать, как устроена разработка, где возникают риски и с кем нужно говорить, чтобы проблема не осталась незамеченной.

Первый ключевой навык — проактивность. В hardware редко бывает так, что кто-то сам приходит и заранее говорит: у нас проблема, мы не успеваем или не можем решить проблему. Чаще менеджеру нужно самому идти к людям, задавать вопросы, вытаскивать блокеры и вместе искать варианты, как с ними работать. Если этого не делать, проблема слишком долго остается внутри команды и становится заметной уже тогда, когда начинает влиять на сроки проекта.

Второй важный навык — коммуникация. Для меня это вообще основа всей работы. В такой среде нельзя надеяться, что понимание придет в процессе — его нужно формировать самостоятельно.

При этом коммуникация в hardware — это не просто умение поддержать разговор. Это еще и умение говорить с разными командами на понятном им языке. Особенно если проект связывает разработку, верификацию и software. У каждой функции свой фокус, свои ограничения и своя логика работы — и менеджеру важно не терять фокус при переключении между ними.

Еще один важный навык — умение описывать процессы. В технических командах многое может существовать «по умолчанию»: все понимают, кто и за что отвечает и как передаются задачи, но это не всегда зафиксировано письменно. Для проекта это риск, поэтому менеджеру важно либо помогать командам фиксировать правила, либо брать эту задачу на себя. Иначе слишком многое будет держаться на личных договоренностях и памяти отдельных людей.

Наверное, главное, что я поняла про эту работу: здесь нельзя быть пассивным координатором. Нужно самой идти в проект, самой собирать понимание, самой связывать людей и самой вовремя замечать, где система начинает ломаться. Именно это и делает менеджера в hardware не просто человеком со статусами, а человеком, который помогает проекту оставаться управляемым.

Мне кажется, hardware особенно хорошо показывает, что проджект-менеджмент — это не про контроль ради контроля. Это про умение работать со сложностью: связывать команды, удерживать проект в понятных рамках, вовремя замечать риски и помогать людям двигаться к результату, даже когда условия меняются. Здесь невозможно ограничиться только статусами, отчетами и календарем — нужно по-настоящему понимать, как живет проект изнутри.

Наверное, именно поэтому меня и держит эта сфера. В hardware почти не бывает ощущения, что ты уже все поняла и дальше просто повторяешь знакомый сценарий. Наоборот: кажется, что ты начала в чем-то разбираться, но тут же появляется новый термин или контекст. И для меня это не минус, а одна из причин оставаться в этой работе.