В сети достаточно много информации о работе Project Manager в Software проектах и значительно меньше подобной информацией про ПМ в сфере Hardware development. В этой статье маркетолог EnCata PD Вадим Красновский сравнивает домены и функционал проджект-менеджеров.
Особую благодарность за помощь опытному проектному-менеджеру и ментору Alexander Ryabtsev.
В разработке продукта важно уметь находить золотую середину между требованиями заказчика, бюджетом и возможностями команды. За любым продуктом, которым мы когда-либо пользовались, скрывается многочасовые дискуссии, консультации, конфликты, просроченные дедлайны. И успешный проектный менеджер - это дипломат с широким функционалом, который знает, как, обойдя все преграды и проблемы, завершить проект в срок.
Управление Hardware и Software проектами: основные сходства.
Начнем с того, что при попытке выяснить у Project Manager'ов детали их функционала, все 6 ПМов (3 из software и 3 ПМа из EnCata), с кем мы общались при подготовке этого материала, сразу делали оговорку: “Все зависит от проекта” или “Если нужны детали, то давай поговорим об конкретном проекте”. Поэтому материал получился скорее об основных элементах стратегии руководства проектами, на основе синтеза опыта коллег и партнеров. А подробности разработки конкретных hardware- проектов с привязкой к техническим задачам и целям Заказчиков можно посмотреть в наших Case Studies.
Начнем с краткого обзора существующих сходств обеих областей:
- В независимости софт это или физическое устройство - интересы конечного пользователя прежде всего. Программа или гаджет должны быть удобны, понятны и безопасными в использовании, нести ценность для покупателя. Поэтому в обоих доменах, важен этап исследования будущего продукта на реальных пользователях, что ставит перед руководителем проекта задачу интегрировать результаты исследования аудитории в дизайн продукта. Поэтому, для обоих типов проектов важно включать в проекты стадию тестирования на реальных пользователях.
- В обоих доменах конечный продукт сложен и требует участия в разработке многофункциональной команды (инженеры, исследователи, дизайнеры и т.д.), которые будут работать месяцы, а то и годы над проектом. Проектный менеджер должен синхронизировать взаимодействия разнопрофильных специалистов и команд.
- И software, и hardware, для конечного пользователя “черный ящик”, т.е. потребитель взаимодействует только с “фронтом” или панелью управления продукта. Что внутри? Как это работает? Пользователь не знает ответы на эти вопросы. Руководитель проекта должен активно участвовать в принятии решений, чтобы трансформировать сложные технологии в простой и понятный интерфейс продукта для конечного пользователя на всех этапах взаимодействия с продуктом.
- Существуют разные методологии управления проектами. Kanban, Agile, Scrum, LEAN, спринты, стендапы и т.д. Эти методологии разработки активно применяется в обеих сферах. Но стоит признать, что в этом плане software и hardware развиваются не всегда синхронно Они перенимают эффективные элементы методологии друг у друга и адаптируют под свою специфику. Например: методологию Agile hardware development перенял у software, а методологию “бережливого производства” software development взял из производственной сферы.
С основными сходствами завершили и плавно переходим к отличиям.
В чем разница между управлением hardware and software проектами
Не вдаваясь в нюансы, которые есть в каждом конкретном проекте, в ходе общения с практикующими ПМ из обеих отраслей мы выделили 5 ключевых отличий:
1. Определение конечного продукта: неопределенность vs неопределенности
Не секрет, что идея и концепт продукта задает рамки для разработки. Каким образом идея будет реализована в конечном итоге, зависит от многих факторов, начиная от законов физики, заканчивая актуальными потребностями рынка. И рамки у software проектов более гибкие, чем в аппаратной разработке.
Software
В разработке программного обеспечение, зачастую, на ранних этапах заказчик и команда разработки имеют лишь общее представление о конечном продукте.
Есть понимание основных функций продукта и те задачи, которые программное обеспечение должно решать. При этом, функциональные характеристики объекта разработки могу кардинально или частично видоизменяться после тестирования MVP.
Для разработки программного обеспечения абсолютно нормальный путь: выпустить первую версию, протестировать ее на реальных пользователях, получить обратную связь и на основании этого доработать и кастомизировать функционал, интерфейс, дизайн продукта под потребности пользователей. В определенных случаях, данный путь позволяет сэкономить ресурсы на масштабном маркетинговое исследование и тестирование минимальной жизнеспособной версии фактически заменяет этап исследования.
Hardware
В силу того, что объект разработки Hardware проекта - физический объект, этап оформление идеи в предметный концепт невозможен без детальной маркетинговой проработки устройства. На стороне исполнителя проект проходит стадию feasibility, в рамках которой будущий продукт исследуется как со стороны ожиданий и потребностей пользователей, так и с технической точки зрения. Первоначальное техническое задание изменяется по результатам feasibility стадии, окончательно формируется список технологий, roadmap проекта.
Формирование качественного и детального технического задания, определяет успех проекта. Именно на этом этапе ПМ должен просчитать все возможные риски и четко определить “критический путь” от старта до MVP. Ведь чем ближе MVP к желаемому продукту, тем выше шанс завершить проект в срок.
В отличие от software проектов, стоимость шага назад (откат к предыдущей версии проекта) - стоит очень дорого, особенно если проект перешел из стадии разработки конструкторской документации к процессу создания первого физического прототипа. Данное отличие приобретает особенно важную роль в контексте закупок и доставки компонентов и материалов будущего продукта.
Вывод: Проектный менеджер software продуктов походу развития продукта имеет значительно больше пространства для маневра, практически на любой стадии проект можно вернуть на шаг назад и скорректировать техническую и визуальную часть будущего продукта. Простота “шага назад” = низкая цена ошибки.
В аппаратных проектах, перед менеджером стоит задача просчитывать риски перед каждым следующим шагом, т.к., например, ошибка в плотности компонентов на плате, вынудит не только перепроектировать плату, но и другие элементы продукта, в том числе решение по корпусу. Цена ошибки высокая, т.к. есть точки невозврата.
Длительность разработки продукта
Данный пункт логическое продолжение предыдущего. Скорость разработки важна для успеха на рынке. Очевидно, что промедление может привести не только к потере разовой прибыли, но и к занятию конкурентами целых ниш.
Software
Очевидно, что о сроки реализации зависят от сложности и масштаба реализуемого решения. В среднем можно сказать, что от идеи до вывода полноценного продукта на рынок, срок в 1,5 года в разработке программного обеспечения можно считать нормой.
Hardware
В hardware, период разработки в 2-3 года от идеи до вывода продукта на рынок можно считать нормой. Стоит оговориться, что вывод на рынок в индустрии Healthcare, может быть значительно больше, за счет проведения сертифицированных испытании и получения лицензии на продажу.
Роль ПМ: Сроки проектов в доменах разные, но о серьезных отличиях в функции проектных менеджеров говорить не приходится. В обоих случаях, задача ПМ передать клиенту готовый продукт в обозначенные сроки. При этом сроки определяют темп разработки. Более сжатые сроки в sofware проектах - вынуждают руководителя оперативно реагировать на промежуточные этапы и результаты. В hardware проектах более размеренный темп разработки, за счет большего количества заинтересованных сторон и “высокой цены” ошибки на промежуточном этапе.
Количество стейкхолдеров участвующих в разработке продукта
Проектная деятельность, подразумевает поиск баланса между сроком, интересами команды, заказчика и ожидания рынка. Грамотно выстроенная коммуникация между всеми заинтересованными игроками участниками - залог успеха проекта.
Software
Как правило, кроме команды заказчика software PM взаимодействует только с внутренней командой и, при необходимости, с внешними консультантами. Это позволяет сфокусироваться непосредственно на организации процесса и контроля разработки. Упрощая, задача software проектного менеджера, находить компромисс между тремя главными игроками: заказчиком, командой и потребителем.
Hardware
Перед проектным менеджером в hardware стоит нетривиальная задача, учесть интересы и найти общий язык со всеми узлами “проектной цепи”.
Помимо внутренней команды разработки продукта (инженеры электронщики, программисты, дизайнеры, конструкторы), важно учесть технологические аспекты будущего продукта: коммуникация с инженерами по производству и оснастке. Настройка технологического процесса, не менее важна чем сама разработка и производственный аспект важно учитывать при самом начале разработки.
Отдельный процесс, которым должен управлять и контролировать ПМ - подбор и доставка компонентов и комплектующих для проекта. Данный процесс осложняется тем, что важно сформировать оптимальные логистические цепи, не только для мелкосерийного производства на этапе разработки, но и для массового производства.
В определенных случаях, проектному менеджеру необходимо ориентироваться на требования по сертификации будущего продукта.
Роль ПМ: В обоих доменах, проектный менеджер ищет баланс между интересами стейкхолдеров. Главное отличие между software и hardware проектами, это большее количество и разноплановость у последних. Hardware development подразумевает не только оценку рынка сбыта, но и рынок поставок для нужд производства и обслуживания продукта. Поставщики материалов, OEM компании, поставщики ПО, таможня, сертифицирующие органы, логистические компании и т.п. Эти стейкхолдеры – обычное дело в hardware проекте и очень редко встречаются в software разработке. Еще одной отличительной чертой hardware проектов - необходимость закладывания на начальном этапе ограничений по технологиям производства. ПМ и команде важно не только разработать отличный продукт в одном экземпляре, но и подготовить его к массовому производству, что вводит еще одного “игрока” - технологическое бюро предприятия, на котором будет происходить серийное производство.
MVP и рынок: скорость vs последовательность
Минимальный жизнеспособный продукт - очень важная отсечка в разработке нового продукта. С помощью MVP можно подтвердить или опровергнуть результаты PoC, определить выполняет ли прототип запланированные функции.
Software
Минимально жизнеспособный продукт в софтовых проектов, дает протестировать и вносить изменения прямо в процессе тестирования на реальных пользователях.
Оперативная обратная связь от пользователей - безусловное преимущество, которое значительно удешевляет по стоимости и сокращает время для внесения изменений на пути от "сырой" версии к востребованному на рынке продукту.
Например, создание MVP мобильного приложение может быть создан за 1-2 месяца, при этом вы делаете один MVP и можете распространить его среди огромного количества пользователей. Причем количество пользователей практически не влияет на ваши расходы на запуск MVP.
Hardware
MVP в hardware проектах в абсолютном большинстве случаев физический прототип, что сразу значительно усложняет процесс тестирования и испытания будущего продукта.
Можно выделить 3 ключевых сложности:
- Невозможно получить качественную обратную связь на основе одного прототипа. Для таких индустрий как Consumer and Wearable Devices, Healthcare, как правило, нужна первая мелкая партия, что увеличивает финансовые затраты на производство MVP.
- Процесс тестирования не вызывает трудностей с проверкой основных функций, это можно сделать внутри команды разработки или внешних экспертов. Проведения тестирования на ЦА осложняет получение валидных данных на основе реально пользовательского опыта, т.е. неосознанного взаимодействия и субъективной (осознанной) обратной связи от пользователей.
- Полноценный процесс доработки и дебаггинга прототипа возможен только после завершения тестирования MVP, а не в процессе, как в программных продуктах. Увеличивается время от сбора ошибок до их исправления.
Специфика управления: Гибкость soft проектов в части применения технологий дает руководителю широкий спектр вариантов для экспериментов и, в крайнем случае, возможность без критических затрат вернутся на шаг назад. Перед hard менеджерами выставлены более жесткие рамки по определению этапов жизни проекта, вернутся на шаг назад возможно, но это 100% потери. Риск понести незапланированные затраты вынуждает менеджера быть крайне осторожным.
Подбор команды и организация процесса разработки
Software
Разработка софтверных проектов в удаленном формате еще до эпохи Covid-19 стала нормой, а пандемия катализировала процесс перехода из офиса к удаленке.
Организация эффективной работы с удаленными сотрудниками, один из ключевых навыков Project manager.
Отдельно важно обозначить доступность (количество и качество) трудовых ресурсов. Порог входа в профессию софт-разработчика достаточно низкий, существуют огромное количество курсов, которые позволяет ученикам получить базовые компетенции разработчика буквально за 1 год, что значительно сокращает затраты на подбор команды, особенно линейных специалистов.
Hardware
Covid-19 стал серьезным испытанием для hardware-разработки. Если на начальном этапе разработки аппаратного продукта процесс пострадал в меньшей степени, то по мере продвижения к физическому воплощению продукта, возникает множество сложностей:
- с оборудованием безопасного рабочего места дома;
- взаимодействия с физическими элементами прототипа, особенно при необходимости параллельной работы над прототипом нескольких смежных специалистов;
- с производством и тестированием прототипа.
При относительно мягкой адаптации программных разработчиков к удаленке, hardware разработчики столкнулись с неразрешимыми проблемы.
Переходя к вопрос о подборе команды, можно констатировать, что порог входа в профессию в среднем выше в 4-6 раз. Electrical Designer без профильного высшего образования редкое исключение.
Роль ПМ: Если взять данные по одной из самых популярных фриланс-площадки в мире Upwork, то можно увидеть весомую разницу между количество представленных специалистов обоих доменов. За 2021 год по software проектам было заключено более 211 тысяч контрактов, против 34,5 тыс. контрактов в hardware домене (34,5 тыс. включают услуги архитекторов и специалистов химических отраслей).
Данная статистика, косвенно, подтверждает более высокий уровень предложения и спроса на software специалистов на рынке труда.
В этой ситуации, перед проектным менеджером в домене hardware - стоит не самая легкая задача, собрать команду из профильных специалистов под определенный проект. Данная задача осложняется необходимостью собрать команду “под одной крышей”.
Для менеджера software проекта, возможно частично или полностью собрать команду удаленно. Это дает возможность быть более гибким и оперативным при формировании команды.
Распределение ролей между техническим руководителем и PM. Hard skills PM
В данном пункте сравним каким профессиональным бэкграундом должен обладать ПМ в обоих доменах. А также определим модели распределение ролей на проекте.
Software
Навыки и опыт в разработке cофтовых проектов, безусловно, серьезный плюс для эффективного управления проектом, но это не является обязательным условиям для успешного software project manager.
В обоих доменах, проектный менеджер, в первую очередь, занимается управлением (организация процесса, распределением ролей, контролем сроков) и ключевым коммуникационным звеном между заказчикам и командой.
Отсутствие технического бэкграунда у менеджера software проектов - компенсируется включенностью в управление проектом “архитектора системы” (тех. лида) и лидеров команд.
Архитекторы и тимлиды, как правило, напрямую взаимодействуют с заказчиками по техническим аспектам проекта, что дает возможность оперативно и без посредников принимать стратегические и тактические решения по проекту.
Hardware
При управлении разработкой hardware проекта важность технического бэкграунда определяющая, наравне с менеджерскими, коммуникативными и методологическими скиллами. При этом речь идет не только об высшем техническом образовании, но и об опыте работы инженером-разработчиком.
Именно инженерная база дает возможность учесть все риски при выборе материалов, компонентов и принципиальных решений по продукту. Она дает возможность находить баланс между стейкхолдерами и осуществлять полноценный контроль разработки на стратегическом уровне.
Технический лид на hardware проектах, отвечает за технические аспекты проекта на операционном уровне и обосновывает изменения и решения по технической части проекта перед ПМ–ом. Данная модель становится особенно выраженной, когда owner дизайна продукта не заказчик, а де-факто ПМ.
Технический лидер может напрямую взаимодействовать с клиентом по тактическим моментом, но стратегические решения за проектным менеджером.
Роль ПМ: Основная разница по данному пункту между доменами - это необязательный технический бэкграунд у software проектных менеджеров. Опыт разработчика большой плюс, но куда важнее коммуникационные и организаторские навыки. Возможную нехватку технических компетенции компенсирует “архитектор системы” на проекте.
В hardware домене, мы уверены, что есть опыт успешного управления проектом специалистом без технического образования, но отталкиваясь от опыта нашей компании, реальный опыт в разработке и профильное образование у ПМ-ов - необходимое условие для успешного завершения проекта. В нашей компании 4 ПМ, 3 из них PhD в технических науках . У всех проджект менеджеров большой опыт в сфере научно-прикладных исследований в технических науках, разработке новых продуктов и проектном менеджменте. Это позволяет им вникать в производственные технологии, а также учитывать особенности жизненного цикла продукта в зависимости от материалов, сферы применения продукта, сценариев использования и т.д.
Вместо заключения
Перед менеджером любого проекта стоит нетривиальная задача - угодить всем. На первый взгляд, прочитав в этой статье сравнение специфики управления проектами в обоих доменах, может показаться, что управление софтовыми проектами - это легкая прогулка, по сравнению с hardware проектами, но это точно не так.
Software домен, безусловно, более динамично развивается, у него больше инструментов и возможностей для оперативной и недорогой обратной связи с целевой аудиторией будущего продукта, больше возможностей для экспериментов и тестирование гипотез. Все эти преимущества и простота относительно hardware development, обычно имеют обратную сторону:
- Ровно такими же преимуществами обладают конкуренты и поэтому даже незначительные недоработки проектного менеджера могут серьезно навредить продукту с точки конкуренции на рынке.
- Более гибкая и динамичная среда, вынуждает проектного менеджера в программной разработке, поддерживать высокую скорость на протяжении всего проекта, а также принимать решения в условиях ограниченности временного ресурса.
- Работа команды в удаленном формате усложняет выстраивание общения в команде, т.е. что можно решить за 15 минутный разговор face-to-face, практически невозможно осуществить в онлайн формате за такой промежуток времени. Перманентная синхронизация - требует максимальной фокусировки на внутрикомандной динамике.
Hardware проекты, менее динамичные и гибкие. У проектного менеджера более размеренный ритм работы, но при этом высокая стоимость ошибки, особенно после того, как продукт перешел из CAD-модели в физический прототип. Разработка аппаратная разработка усложняется высокой стоимостью тестирования прототипов на реальной ЦА, а также более низкого качества обратной связи от рынка.
Подводя итог, при всех отличиях функций проектных менеджеров в software и hardware проектах, их объединяет одно - склад характера и навыки, позволяющие уверенно идти навстречу неопределенности.