Мастерство Front-End Engineering Design: пошаговое руководство по планированию проектов

Front-End Engineering Design (FEED): методологический подход к проектированию

Инженерное проектирование должно подходиться с тщательной детализацией и методологическим процессом. Поспешный переход к ранней разработке без тщательного рассмотрения всех возможных решений и общего понимания проблемы может привести к проблемам в дальнейшей разработке и затратам проекта. Front-End Engineering Design (FEED) — подход, используемый для фокусировки на технических требованиях. Он признан распознать первичные затраты для предложения проекта. Эта статья пошагово раскроет, как процесс может помочь вашему следующему проекту и оценить потенциальные риски.

Обзор FEED

Front End Engineering Design основан на характеристике проблемы/разработки продукта. Это не обязательно должна быть проблема, а концептуальная идея или возможное изобретение. У него есть набор целей с целевыми спецификациями, и в настоящее время существует восемь категорий процесса FEED:

1. Учет исходной проблемы
2. Параметры проектирования
3. Управление командой
4. Оценка рынка и бенчмаркинг
5. Оценка потребностей пользователей
6. Исследование продукта
7. План разработки
8. Целевые спецификации

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

Проектные соображения

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

Лучшая возвратность инвестиций (ROI)

Исследования показывают, что те, кто использует Front End Engineering Design, склонны завершать проекты вовремя. Это означает, что ROI улучшается с процессом проектирования. Национальный исследовательский совет в Вашингтоне, округ Колумбия, США, оценил, что по крайней мере 70% затрат на разработку продукта и производство определяются на начальных стадиях дизайна.

Использование Front End Engineering Design

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

1. Управление командой

• Соратники составляют график работы на основе приоритета задачи
• Разбивка работы и назначение задач каждому участнику
• Работники оценивают риски своего проекта
• Создается общая доступная файловая локация для обмена документами
• Еженедельные журналы прогресса для отчетности о разработке индивидуальных заданий

Хорошее планирование проекта необходимо при создании и эффективной реализации структурированного графика. Для следования проекта по графику команда должна оценивать с максимальной точностью доставки проекта и правильное количество времени для их выделения. Предвидение задержек и неожиданных проблем нужно включать при определении общих временных графиков для каждого результата. Спецификация материалов (BOM) необходима для запуска проекта и должна быть построена рано для оценки затрат. Каждый член команды должен адресовать, что требует их проект, и зафиксировать это детально. Понимание необходимых материалов существенно, как и прогнозирование других возможных предметов в этот момент сэкономит время в будущем без препятствования прогрессу проекта. Несомненно, что непредвиденные элементы, не перечисленные в BOM, возникнут и должны обрабатываться с заботой при определении лучшей опции для продукта, а не поддаваться решениям под давлением.

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

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

2. Планирование проекта

Структурированный процесс проектирования для визуальной оценки потоков прогрессии. Обычно блок-схема составляется на основе задач, назначенных через график.

3. Первоначальный анализ и проектные соображения

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

4. Бенчмаркинг и оценка рынка

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

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

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

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

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

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

5. Оценка потребностей пользователей/клиентов

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

6. Исследование продукта

Эта стадия предназначена для понимания исследования продукта через функциональный анализ, проектные соображения, оценку рисков, планирование и принятие во внимание используемых систем. Это можно сделать с использованием инструментов от mind mapping (ментальных карт), которое является концептуальным представлением проекта в целом.

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

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

7. План разработки

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

8. Критический дизайн-ревью

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

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

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