Экономим деньги, спасаем стартапы от провалов, изобретаем по-новому вместе с системной инженерией

Почему стартапы обесцениваются, как свести риски провала до минимума и что в России не так с hardware? Ищем ответы в ISO 15288 и системной инженерии вместе с Дмитрием Паршковым — CEO Parshkov Inc и сооснователем Robots Can Dream. Он изучал системную инженерию в MIT, 15 лет делает стартапы, а еще консультирует крупные компании.

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

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

Как этого можно было избежать? В чат входит системная инженерия. Чтобы хорошая идея не рухнула при первом же тесте, нужно тесно общаться с заинтересованными сторонами, внимательно собирать их требования, управлять задачами и контролировать риски. Для этого она и была создана.

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

Мой профессор назвал меня классным инженером, но гаражного уровня. Он дал прогноз: я буду делать хорошие девайсы, но очень понятной сложности. Почему так?

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

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

Методология помогает перевести процессы в проекте на язык каждого исполнителя и сделать из этого карту предстоящей работы.

Системная инженерия, как LEGO, даёт инструкцию, в которой детально прописана последовательность действий

Хотелки

Начинаем со сбора «хотелок»‎ со всех заинтересованных сторон — стейкхолдеров. Это могут быть госорганы, заказчик, организация, которая занимается уборкой в месте, где стоит девайс: чтобы его мыть, он должен быть передвижным — значит, нужно предусмотреть колесики. Нужно также искать стейкхолдеров, которые не связаны с заказчиком.

Помимо этого определяется рабочая группа, коммуникационные чаты, описываются характеристики успешного продукта, конкурентные преимущества, определяются риски, технологические траектории и сегментируется рынок.

Project Management Plan

Далее создается первый важный документ — Project Management Plan. Он утверждается у клиента, и в этот момент появляется общая миссия продукта. После этого начинается разработка концепций. Все требования стейкхолдеров проходят приоритезацию и переводятся на инженерный язык.

На каждое инженерное требование должен наложиться тест. Потому что мы всё ещё работаем на заказчика. Как он поймет, что шум «достаточно тихий»‎? Мы измерим его калиброванным шумомером. И так проходимся по всем требованиям стейкхолдеров. Также на каждое инженерное требование подбирается функция. Автомобиль должен ехать — ему нужен двигатель — выбираем подходящий.

Риски

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

House of quality

Ещё один интересный этап в системной инженерии — House of quality. Это карта, которая показывает: в каких конкретных требованиях мы уходим от идеала, в каких не уходим, а какие друг друга дополняют. Например, пони должен быть тяжелым и дешевым. И мы видим на этой карте, что это две согласованные «хотелки»‎. Потому что толстые лошади, как правило, дешевле. Из этой карты мы понимаем, что нужно оставить и что не повлечет за собой увеличение сложности или денег.

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

Был случай, когда я пренебрег стейкхолдерами. Больше 6 лет назад у меня был проект интерактивных меню для ресторанов, чтобы заказывать еду без официантов. Потом он трансформировался в умный стол-экран. Я видел в этом проекте личную проблему, потому что тогда много путешествовал без знания языков.

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

От концепта отказались, но остались наработки и прототипы. Так у нас получился другой проект MyINI — цифровой консьерж для гостиничного бизнеса.

Не дойти до конца можно и с ней, но путь будет уже не таким жестким. Можно все же дойти до конца, но с приемлемыми рисками. Либо на ранних этапах понять, что система не летит ни экономически, ни по инженерным вопросам и остановиться.

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

У нас системная инженерия не сильно продвинулась. В советское время её пробовали внедрить в Московском Энергетическом университете, даже перевели учебник и назвали дисциплину «Системотехника»‎. Но он получился больше про электронику, а потом и вовсе не разошелся.

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

Сложность еще в том, что в России для человека, придумавшего hardware-стартап, начинается крестовый поход. Ему уже от одной мысли страшно: «возьму денег, за деньги надо отвечать, если не получится — меня зарежут»‎. Даже в этом плане методология может помочь и увеличить количество изобретений, потому что можно говорить, что всё делается по инструкции. Это повышает уверенность.

Да, долгое время у нас было затишье, но с 2012 года появляются люди, продвигающие системную инженерию в правильном виде. Например, это делают в МФТИ. Считаю, у них это получается.

Тем не менее в России сложно найти инженеров, которые работают с этой методологией. Нет, классные специалисты по системной инженерии конечно есть, но заполучить их в штат практически невозможно. Это перекупка очень больших экспертов. Их мало, их нужно хантить из других крупных компаний. Например, в Казани за последние 7 лет нам не удалось найти ни одного человека, который бы знал эту методологию.

При этом стандарт ISO 15288 не экзотика, он есть в ГОСТе от 2002. То есть на уровне государства это известный факт, но с точки зрения продвижения в бизнес, поддержки студентов, обучения молодежи прогресса почти нет.

Да и мало работодателей хотят указывать в требованиях «знание ISO 15288»‎. Я даю консультации многим российским компаниям, тому же Сбербанку. Мне приходится буквально продавать им системную инженерию.

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

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

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

Но одна системная инженерия проблем в России не решит. Тут ещё накладываются санкции, недоступность некоторых продуктов. Так один из моих любимых инструментов, Cameo Systems Modeler (кроссплатформа для совместной разработки систем), в России официально не продаётся. То есть даже со знанием методологии трудно работать с некоторыми процессами. Но конкуренция растет, а она точно поможет увеличить количество личных продуктов. Пусть даже на первых порах они будут нишевые и простые.

Также подписывайтесь на наш телеграм-канал «Голос Технократии». Каждое утро мы публикуем новостной дайджест из мира ИТ, а по вечерам делимся интересными и полезными мастридами.