Наши исследования и разработки сокращают количество ошибок на 40%. Ты?

Многие научно-исследовательские группы не теряют времени из-за недостатка навыков у их инженеров. Ошибки часто возникают из-за неясных требований, разбросанных файлов, поспешных проверок и небольших изменений, которые не фиксируются. Я видел, как команды тратили дни на исправление проблем, которые можно было обнаружить во время короткого обзора. Отсутствующая спецификация, устаревший чертеж или непроверенное изменение могут пройти несколько этапов, прежде чем кто-либо это заметит. Заявленное снижение количества ошибок на 40 % звучит полезно, но эта цифра имеет значение только тогда, когда команда объясняет, как она была измерена. Если бы я хотел достичь подобного результата, я бы сосредоточился на рабочем процессе, а не просил людей «быть более осторожными». ## Начните с четкого определения базовых показателей ошибок. Я бы записывал типы ошибок, возникающих в течение определенного периода. В список могут входить: - Изменения в проекте, пропущенные во время производства - Шаги тестирования пропущены или записаны неправильно - Дублирующиеся версии технических файлов - Требования, которые открыты для различных интерпретаций - Дефекты, обнаруженные после передачи другой команде - Переработка, вызванная неполными комментариями при проверке. Каждая ошибка должна указывать ее источник, стадию, влияние и время, затраченное на исправление. Простая запись может выглядеть так: | Тип ошибки | Где он появился | Время доработки | Возможная причина | |---|---|---:|---| | Неправильная версия чертежа | Сборка прототипа | 6 часов | Именование файла было неясным | | Условие пропущенного теста | Проверка | 4 часа | Требованию не хватало деталей | | Позднее изменение дизайна | Передача производства | 8 часов | Об изменении было сообщено только по электронной почте | Это дает мне отправную точку. Без базового уровня трудно поверить в процентное изменение. ## Найдите повторяющиеся причины Из-за длинного списка ошибок проблема может показаться более серьезной, чем она есть на самом деле. Одна и та же первопричина может проявляться в нескольких формах. Например, группа может сообщить: - Использован неправильный файл - Скопированы старые измерения - Рецензенты проверяют разные документы - Поставщик получает устаревшую версию Все эти проблемы могут быть связаны с одним пробелом в процессе: у группы нет общего правила контроля версий. Я бы группировал ошибки по причинам, а не только по отделам. Это помогает выявить, где небольшое изменение процесса может предотвратить сразу несколько проблем. ## Упростите проверку требований. Многие ошибки в исследованиях и разработках возникают еще до начала проектных работ. Требование типа «устройство должно хорошо работать в холодных условиях» оставляет слишком большой простор для трактовки. Более строгое требование дает команде измеримую точку: - Рабочая температура: от -10°C до 45°C - Продолжительность испытаний: 500 часов - Максимальная интенсивность отказов: определяется планом проекта - Метод испытаний: назван и утвержден до проверки. Четкие требования помогают инженерам проектировать с одной и той же целью. Они также дают рецензентам что-то конкретное для проверки. Я предпочитаю короткие листы требований с указанием владельца, даты, метода испытаний и статуса утверждения. Длинный документ может содержать полезную информацию, но его все равно сложно использовать в повседневной работе. ## Используйте точки проверки перед передачей. Одна проверка в конце проекта может появиться слишком поздно. Я бы поместил меньшие проверки на ключевые этапы: 1. Проверка требований 2. Проверка дизайна 3. Проверка прототипа 4. Проверка готовности к тестированию 5. Проверка передачи Каждая проверка должна иметь ограниченную цель. Обзор дизайна может быть сосредоточен на пригодности, функциях, рисках и открытых изменениях. Проверка передачи может быть сосредоточена на чертежах, протоколах испытаний, данных поставщиков и утвержденных версиях. Это сохраняет сосредоточенность встреч. Это также снижает вероятность того, что один рецензент проверит все возможные проблемы одновременно. ## Отслеживание изменений в одном месте Электронная почта может поддерживать связь, но это слабая система для отслеживания технических изменений. Сообщения становится труднее искать, вложения можно копировать, а члены команды могут не видеть одно и то же обновление. Я бы использовал одну общую запись для каждого изменения. В нем должно быть показано: - Что изменилось - Почему оно изменилось - Кто утвердил это - Какие файлы затронуты - Какие тесты необходимо повторить - Когда изменение становится активным Запись об изменении не должна быть сложной. Его должно быть легко найти и использовать каждый. ## Изучите практический пример. Рассмотрим продуктовую команду среднего размера из 18 инженеров. В течение одного квартала команда фиксирует 50 ошибок, связанных с изменениями в проекте, протоколами испытаний и версиями файлов. Изучив данные, команда обнаружила три распространенные причины: - Требования написаны в разных форматах. - Инженеры хранят файлы в отдельных папках. - Утверждения изменений передаются по электронной почте. Команда создает один шаблон требований, устанавливает общее правило именования файлов и добавляет проверку изменений перед тестированием прототипа. В течение следующего периода измерений команда фиксирует 30 подобных ошибок. Это будет означать сокращение на 40 %, но команде все равно следует проверить, имеют ли проекты схожие рабочие нагрузки и сложность. Меньший проект, естественно, может привести к меньшему количеству ошибок. Хорошие измерения требуют контекста. ## Сохраняйте полезность процесса Процесс может создать новые проблемы, если он станет слишком тяжелым. Если инженерам приходится заполнять длинные формы для внесения незначительных изменений, они могут избежать использования системы или ввести недостоверную информацию. Я бы сохранил правила, соответствующие риску: - Небольшое изменение: краткая запись и экспертная оценка - Среднее изменение: документированная проверка воздействия - Изменение высокого риска: официальное одобрение и повторное тестирование Цель состоит в том, чтобы не добавлять бумажную работу. Цель — помочь людям обнаружить ошибки, пока их еще легче исправить. Когда я анализирую процесс НИОКР, я ищу три сигнала: повторяющиеся ошибки, неясное право собственности и отсутствие доказательств. Исправление этих областей может сократить количество доработок, не возлагая всю ответственность на отдельных инженеров. Для некоторых команд возможно снижение на 40%, но его ни в коем случае нельзя рассматривать как обещание. Полезным уроком является метод: измерьте отправную точку, определите повторяющиеся причины, сделайте изменения видимыми и проверьте результат с помощью согласованных данных.

Переделка редко начинается с одной крупной ошибки. Обычно оно вырастает из небольших пробелов: неясного требования, отсутствующего результата теста, устаревшего чертежа или передачи, зависящей от памяти. Я видел, как команды исследователей и разработчиков тратили дни на устранение проблемы, которую можно было бы предотвратить с помощью короткого обзора в нужный момент. Стоимость не ограничивается работой. Переработка может задержать тестирование, увеличить нагрузку на производство и сделать членов команды менее уверенными в этом процессе. Команды, которые сокращают количество ошибок, не полагаются на то, что люди идеальны. Они выстраивают рабочую систему, благодаря которой ошибки легче выявлять и исправлять. ## Начните с общего определения работы Многие проблемы проекта возникают еще до начала проектных работ. Менеджер по продукту может описать потребности клиента широким языком. Инженер может превратить эту потребность в техническую особенность. Специалист по качеству может прочитать то же требование по-другому. Каждый человек может работать осторожно, но результат все равно может не достичь первоначальной цели. Я предпочитаю превращать общие запросы в проверяемые утверждения. Вместо того, чтобы писать: «Создайте компактное и надежное жилье». Команда может написать: «Корпус должен умещаться в пределах 120х80х40 мм, защищать внутреннюю плату от обычного обращения и пройти согласованное испытание на падение». Этот формат дает команде возможность проверить. Это уменьшает личную интерпретацию и делает последующие обсуждения более целенаправленными. Полезное требование должно отвечать: - Что должен делать продукт? - При каких условиях это должно работать? - Как команда будет проверять результат? - Кому принадлежит решение, когда появляется компромисс? Если требование невозможно протестировать, я рассматриваю его как предмет обсуждения, а не как готовое требование. ## Сохраняйте один источник актуальной информации. Устаревший файл может привести к большему количеству переделок, чем к сложной проблеме проектирования. У команды может быть рисунок на общем диске, более новая версия в электронном письме и тестовая заметка, сохраненная на ноутбуке одного инженера. Каждый файл может выглядеть действительным. Риск возникает, когда кто-то использует неправильную версию, не зная об этом. Простой процесс управления документацией может снизить этот риск. Я рекомендую использовать: - Четкую структуру именования файлов - Номера редакций - Видимый статус утверждения - Одно место для выпущенных документов - Краткое описание изменений - Именованных владельцев ключевых файлов Например, файл с именем Bracket_Rev_C_Approved предоставляет больше информации, чем Bracket_Final_New2. Команда должна определить, что означает «одобрено». Файл может быть одобрен для моделирования, но не готов к производству. Другой файл может быть выпущен для прототипа, но перед производством все равно потребуется внести изменения. Маленькие этикетки предотвращают большие недоразумения. ## Проверяйте точки наибольшего риска заранее. Не каждая деталь требует одинакового уровня проверки. Незначительное изменение этикетки и несущего соединения не несут такого же риска. Когда команды проверяют каждый элемент с одинаковыми усилиями, они могут потратить слишком много времени на детали с низким уровнем риска и слишком мало времени на проектные решения, которые могут привести к сбою. Я использую простую проверку рисков: — Что может выйти из строя? - Как неудача повлияет на заказчика или следующую команду? - Насколько вероятен провал? - Можем ли мы обнаружить это до релиза? - Какие действия снизят риск? Например, небольшая группа разработчиков электроники может обнаружить, что ориентация разъемов создает высокий риск ошибок при сборке. Краткий обзор конструкции с участием специалиста по сборке может выявить проблему до того, как будут заказаны детали. Проверка может занять 30 минут. Переработка партии собранных агрегатов может занять значительно больше времени. ## Создавайте прототипы на основе вопросов Прототип должен отвечать на вопрос. Нет необходимости доказывать, что весь продукт готов. Когда я планирую прототип, я записываю неопределенность, которую он должен устранить. Примеры: - Будет ли корпус оставаться устойчивым при нормальном использовании? - Может ли техник собрать деталь без специальных инструментов? - Удерживает ли путь охлаждения целевой компонент в рабочем диапазоне? - Может ли датчик выдавать полезные показания в ожидаемых условиях? Такой подход позволяет сделать прототип целенаправленным. Это также помогает команде не тратить время на доработку тех частей конструкции, которые еще не были протестированы. Команда разработчиков бытовой электроники может распечатать три формы корпуса, чтобы сравнить рукоятку и доступ к кнопкам. Прототипам не нужны окончательные материалы или обработка поверхности. Им необходимо предоставить полезные данные о физическом расположении. Результатом является более быстрое принятие решения с меньшими затратами труда. ## Используйте короткие обзоры дизайна с заранее подготовленными материалами. Длительные встречи не всегда приводят к лучшим решениям. Обзор работает лучше, когда каждый участник знает, что требует внимания. Перед обзором я делюсь: - Версией проекта - Решением, которое необходимо принять - Тестовыми данными или расчетами - Открытыми вопросами - Известными ограничениями - Список необходимых участников В ходе встречи я отделяю факты от мнений. Расчет может показать, что температура компонента превышает предел. Это факт, основанный на имеющихся данных. Предложение изменить материал является конструктивным вариантом. Разделение этих вопросов помогает команде обсудить реальную проблему. Каждое решение должно иметь краткую запись. Он может включать решение, причину, владельца и следующее действие. Эта запись защищает команду от повторения того же разговора через несколько недель. ## Вовлеките в процесс производственные и сервисные группы. Группа исследований и разработок может создать конструкцию, которая работает в цифровой модели, но вызывает проблемы во время сборки или ремонта. Производственный персонал понимает доступ к инструментам, вариации деталей, время цикла и распространенные ошибки оператора. Обслуживающий персонал понимает, как пользователи справляются со сбоями после того, как продукт покидает завод. Их отзывы могут выявить проблемы, которые могут не проявиться при инженерных испытаниях. Например, инженер может разместить два крепежа близко друг к другу, чтобы сэкономить место. Техник может обнаружить, что необходимый инструмент не может добраться до одного из них после установки окружающих деталей. Краткий обзор с людьми, которые создают или обслуживают продукт, может предотвратить проблемы такого типа. Их отзывы не должны заменять инженерное суждение. Он добавляет практическую информацию, которой может не быть у команды разработчиков. ## Отслеживайте причины, а не только количество ошибок Команда, которая записывает только количество дефектов, может упустить причину, стоящую за ними. Я предпочитаю группировать ошибки по причине: - Требование было неясно - Изменение не было опубликовано - Метод тестирования был неполным - Отсутствовали данные о поставщике - В обзор не был включен нужный человек - Проект был выпущен с открытым вопросом - Рабочая инструкция не соответствовала чертежу Предположим, команда обнаружила пять ошибок сборки за один месяц. Одна только цифра мало о чем говорит. Если четыре ошибки возникли из-за устаревших чертежей, лучшее действие — это не еще одно общее напоминание «быть осторожным». Команде нужен более строгий контроль версий. Полезное корректирующее действие меняет процесс, который привел к возникновению проблемы. ## Сделайте следующее действие легко видимым. Открытые действия часто исчезают в заметках о собрании. Я веду список действий с пятью основными полями: - Действие - Владелец - Срок выполнения - Связанный документ или проблема - Статус Язык должен быть прямым. «Проверить зазор между разъемами» легче следовать, чем «Тему разъема для обсуждения». Владельцем должен быть человек, а не отдел. Срок выполнения должен отражать план проекта, а не создавать давление без контекста. Если задача изменится, в записи должно быть объяснено, почему. Эта практика дает команде общее представление о незавершенной работе. ## Извлекайте уроки из промахов Промахи — это полезная информация. Если технический специалист замечает, что разъем можно установить задом наперед до того, как продукт достигнет стадии тестирования, команда обнаружила слабое место, не столкнувшись с более серьезным сбоем. Воспринимать это событие как обвинение может отговорить людей сообщать о подобных проблемах. Задаю три вопроса: 1. Что сделало возможной ошибку? 2. Почему это не было обнаружено раньше? 3. Какое небольшое изменение может снизить вероятность повторения? Ответом может быть ключевая особенность, более четкий чертеж, приспособление, проверка программного обеспечения или обзор на другом этапе. Команда учится быстрее, когда люди могут сообщать о проблемах, не ожидая личной критики. ## Создайте повторяемый контрольный список выпуска. Контрольный список не заменяет экспертные знания. Это защищает команду от рутинных пропусков при загруженном графике. Контрольный список выпуска может охватывать: - Статус требований - Пересмотр чертежа и модели - Выбор материала - Результаты испытаний - Известные ограничения - Обзор безопасности, где это применимо - Обратная связь с производителем - Информация об обслуживании - Записи об одобрении - Открытые риски и владельцы Контрольный список должен быть достаточно коротким, чтобы его можно было использовать. Если это будет длинная форма, заполненная необдуманно, она потеряет ценность. Я просматриваю контрольный список после каждого крупного проекта. Предметы, которые никогда не помогают, можно удалить. Могут быть добавлены повторяющиеся проблемы. Сокращение объемов работы заключается не в том, чтобы просить людей работать быстрее. Речь идет о том, чтобы помочь им раньше принимать правильные решения, делиться одной и той же информацией и обнаруживать слабые места до того, как эти слабые места перейдут на следующий этап. Команда все еще может столкнуться с неожиданными неудачами. Ни один процесс не устраняет каждую ошибку. Надежный процесс дает команде лучший способ выявлять проблемы, понимать их причины и действовать до того, как небольшая проблема превратится в длительный цикл исправления.

Ошибки в исследованиях и разработках редко начинаются с серьезного технического сбоя. Они часто начинают с расплывчатого требования, непроверенного предположения или небольшого изменения, которое никогда не доходит до всей команды. Я видел, как команды тратили недели на создание функции, которая решает не ту проблему клиента. Я также видел, как прототип прошел внутреннее тестирование, а затем потерпел неудачу, когда изменились условия использования. Стоимость не ограничивается доработкой. Задержки влияют на планирование производства, доверие клиентов, концентрацию команды и следующий проект. Более разумный подход к исследованиям и разработкам не означает увеличение количества встреч или создание более длинных документов. Это означает более раннее выявление рисков, принятие решений наглядным образом и четкое определение цели каждого теста. Шаг 1. Превратите запрос в четкую формулировку проблемы. Многие проекты начинаются с такого предложения, как: «Сделайте продукт быстрее». Этот запрос слишком широк. Быстрее для какого пользователя? Под какой нагрузкой? По сравнению с каким текущим результатом? Какие компромиссы приемлемы? Я бы переписал это в измеримое утверждение: «Система должна обрабатывать 500 запросов в минуту, сохраняя при этом среднее время ответа ниже 200 миллисекунд при согласованных условиях тестирования». Четкая формулировка проблемы помогает продукту, проектированию, качеству и операциям работать для достижения одного и того же результата. Это также снижает вероятность того, что каждая команда создаст собственное определение успеха. К полезным вопросам относятся: - Кто будет использовать результат? - Какую проблему мы решаем? - Что должно улучшиться? - Что не должно меняться? - Как мы будем измерять успех? - Какие ограничения нельзя игнорировать? Шаг 2. Запишите предположения до начала разработки Каждый проект содержит предположения. Риск появляется тогда, когда их никто не записывает. Команда может предположить, что материал останется стабильным при определенной температуре. Команда разработчиков программного обеспечения может предполагать, что пользователи предоставят полные данные. Команда, занимающаяся аппаратным обеспечением, может предполагать, что поставщик может поддерживать требуемый допуск. Я предпочитаю простой список предположений с четырьмя столбцами: | Успение | Доказательства | Риск, если ошибаюсь | Владелец теста | |---|---|---|---| Эта таблица не обязательно должна быть сложной. Его цель — показать, что знает команда, во что она только верит и кто это будет проверять. Короткий тест в начале может предотвратить длительный цикл разработки, основанный на слабых предположениях. Шаг 3. Создавайте тесты на основе решений Тестирование становится менее полезным, если команда рассматривает его как финальную проверку. Тест должен отвечать на конкретный вопрос. Например: - Может ли конструкция выдержать ожидаемую нагрузку? - Соответствует ли материал необходимой прочности? - Может ли процесс поддерживать качество в нескольких партиях? - Понимает ли пользователь основной рабочий процесс без дополнительной помощи? Для каждого теста должен быть определен образец, метод, условие, критерии прохождения и следующее действие. Если результат неудовлетворительный, команда уже должна знать, какое решение последует. Практический пример — мобильное приложение, которое показывает нестабильную работу на старых устройствах. Вместо того, чтобы ждать полной версии продукта, команда может протестировать самый большой экран данных на небольшой группе целевых устройств. Этот результат может привести к упрощению интерфейса, уменьшению размера изображения или изменению загрузки данных. Команда учится, пока дизайн еще может меняться. Шаг 4. Прежде чем приступать к дорогостоящей работе, создайте точку проверки. Некоторые ошибки обходятся дорого, поскольку проект переходит от небольшого эксперимента к полноценной разработке без четкого анализа. Прежде чем утвердить следующий этап, я бы попросил команду показать: — Текущие требования — Основные технические риски — Результаты испытаний — Открытые вопросы — Ожидаемые затраты и усилия — Эффект известных вариантов дизайна Обзор — это не поиск виноватых. Это шанс решить, следует ли продолжать проект, изменить направление или сделать паузу для получения дополнительных доказательств. Это особенно полезно, когда прототип выглядит многообещающе, но путь производства остается неясным. Прототип может доказать, что что-то работает один раз. Это не всегда доказывает, что результат можно производить последовательно, поддерживать или поддерживать. Шаг 5. Контролируйте изменения на одном видном месте Проекты исследований и разработок меняются по мере появления новой информации. Изменения сами по себе не являются проблемой. Скрытые изменения создают путаницу. Если требование клиента меняется, команда должна записать: - Что изменилось - Почему оно изменилось - Какие документы или проекты затронуты - Какие тесты необходимо повторить - Кто утвердил изменение - Что изменение добавляет или удаляет из плана Общего журнала изменений может быть достаточно для небольшой команды. Для более крупных проектов может потребоваться формальный процесс утверждения. Метод должен соответствовать размеру проекта, а не создавать работу без четкой ценности. Шаг 6. Изучите ошибки, не скрывая их. Если тест не пройден, я хочу, чтобы команда описала событие, прежде чем обсуждать участников. Полезный обзор спрашивает: - Что случилось? - Когда это произошло? - Какие условия присутствовали? - Какие предупреждающие знаки были в наличии? - Почему существующий процесс не уловил проблему? - Какое небольшое изменение может снизить вероятность повторения? Предположим, что тестовый образец вышел из строя, поскольку не был зафиксирован крутящий момент сборки. Ответом может быть не «обучить оператора еще раз». Для процесса может потребоваться цифровая запись, ограничение инструмента или проверка перед перемещением образца. Такой подход превращает единичный сбой в информацию, которая может улучшить процесс разработки продукта. Научно-исследовательская работа всегда будет включать в себя неопределенность. Цель не в том, чтобы исправить каждую ошибку до начала работы. Цель состоит в том, чтобы сделать ошибки меньшими, их легче обнаружить и их исправление обходится дешевле. Когда я вижу, что проект теряет контроль, я возвращаюсь к четырем основным вопросам: Что мы пытаемся решить? Что мы предполагаем? Какие доказательства у нас есть? Какое решение поддержит этот тест? Четкие требования, очевидные предположения, целенаправленные тесты и контролируемые изменения дают командам более устойчивый способ разработки продуктов. Более разумный подход заключается не в добавлении дополнительных процессов. Речь идет об использовании нужного количества процессов в тот момент, когда они еще могут защитить проект.

Сокращение количества ошибок на 40 % не будет просто означать меньшее количество ошибок на панели управления проектом. Для команды исследований и разработок это может означать меньшее количество изменений дизайна, меньшее количество повторных испытаний, более четкую передачу функций и больше времени на работу, которая продвигает продукт вперед. Реальный эффект зависит от того, что команда считает ошибкой. Пропущенное требование, неправильные настройки теста, устаревший чертеж и неудачная передача данных не несут одинаковых затрат. Я бы начал с четкого определения ошибки, а не рассматривал каждую проблему как одно большое число. Полезный базовый показатель может включать в себя: - Количество ошибок на проект - Время, затраченное на исправление каждой ошибки - Стоимость повторного тестирования или отбракованных материалов - Количество изменений конструкции после проверки - Задержки, вызванные неясными требованиями - Дефекты, обнаруженные на поздней стадии тестирования Предположим, группа НИОКР каждый квартал регистрирует 100 ошибок, которых можно избежать, в нескольких проектах. Сокращение на 40% приведет к снижению этого числа примерно до 60. Команде по-прежнему придется решать проблемы, но она сможет избежать 40 случаев, которые когда-то отнимали время разработки. Сэкономленное время может оказаться более ценным, чем сам номер. Инженер, который тратит два часа на исправление ошибки при вводе данных, может потерять больше этих двух часов. Исправление может задержать тестирование, задержать поставщика и вынудить другую команду изменить свой график. Небольшие ошибки часто создают более длинную цепочку работы. Я видел эту закономерность в командах разработчиков продуктов, которые полагаются на общие таблицы и отдельные папки с файлами. Один человек обновляет спецификацию, а другой работает со старой версией. Проблема с продуктом может возникнуть только во время тестирования. На этом этапе команде приходится пересмотреть ранее принятые решения, повторить часть теста и объяснить задержку другим отделам. Четкий процесс контроля версий может уменьшить проблемы такого типа. В каждом файле должен быть указан его владелец, дата изменения, статус утверждения и ссылка на соответствующее требование. Процесс не должен быть сложным. Его должен использовать каждый. Практический план уменьшения ошибок может состоять из пяти шагов. 1. Создайте реестр ошибок Записывайте каждую проблему в одном общем месте. Укажите: - Что произошло - Где это произошло - Кто это обнаружил - Сколько времени потребовалось для исправления - Возникала ли та же проблема раньше - Какие действия могли бы предотвратить повторение Цель не состоит в том, чтобы возложить вину. Цель – увидеть закономерности. Если многие проблемы возникают из-за неясных требований к тестированию, дополнительное обучение само по себе не может решить проблему. 2. Отделяйте предотвратимые ошибки от технических сбоев Не каждый неудачный тест является ошибкой. Некоторые тесты предназначены для выявления пределов продукта. Этот результат может повлиять на следующее дизайнерское решение. Предотвратимая ошибка может включать в себя: - Использование неправильной версии теста - Пропуск необходимой проверки - Ввод неправильной единицы измерения - Забывание изменения в плане тестирования - Отправка устаревшего файла проекта Такое разделение дает команде более полезную цель. Инженерам не следует заставлять скрывать действительные результаты испытаний только для того, чтобы улучшить показатели производительности. 3. Просмотрите передачу Многие ошибки возникают, когда работа передается от одного человека или команды другому. Требования могут меняться в зависимости от планирования продукта и проектирования. Результаты испытаний могут не дойти до владельца дизайна. Отзывы поставщиков могут оставаться в цепочке электронных писем. Я бы наметил основные передачи и задал три вопроса: - Какую информацию необходимо передать? - Кто подтверждает полноту информации? - Где хранится утвержденная версия? Краткий контрольный список при каждой передаче поможет избежать повторных вопросов и пропущенных деталей. Контрольный список должен соответствовать работе. Форма из десяти строк может быть полезна для одного проекта и ненужна для другого. 4. Добавьте проверки, при которых цена ошибки возрастает Ранняя проверка может занять десять минут. Поздняя коррекция может потребовать нескольких дней работы. Команда должна проводить проверки перед такими дорогостоящими этапами, как производство прототипа, тестирование безопасности, выпуск поставщика или проверка потребителя. Автоматические проверки могут помочь при повторяющихся задачах. Система может отмечать отсутствующие поля, несовпадающие единицы измерения, повторяющиеся номера деталей или изменения, внесенные после утверждения. Автоматизация не заменяет инженерное решение, но она может выявить простые проблемы до того, как они достигнут более крупного процесса. 5. Отслеживайте результат с помощью стабильного показателя Команда должна сравнивать похожие проекты или один и тот же тип работы за установленные периоды. Один проект может дать необычные результаты и не привести к долгосрочным изменениям. Полезные меры включают: - Предотвратимые ошибки в каждом проекте - Часы доработок за цикл проектирования - Повторы тестирования, вызванные ошибками процесса - Среднее время от обнаружения проблемы до исправления - Ошибки, обнаруженные до тестирования, по сравнению с ошибками, обнаруженными во время тестирования. Сокращение на 40% следует рассматривать как целевой или измеряемый результат, а не обещание. Результаты будут различаться в зависимости от размера команды, типа продукта, зрелости процесса и качества исходных данных. Например, небольшая группа разработчиков аппаратного обеспечения может уменьшить количество ошибок в документации после замены локального хранилища файлов общей системой и добавления краткого контрольного списка проверки проекта. Команда разработчиков программного обеспечения может сосредоточиться на автоматизированных тестах, правилах проверки кода и более четких записях о выпуске. Инструменты различаются, но основной вопрос остается прежним: какое место в процессе занимает работа, которую можно избежать? Зачастую самое полезное изменение — это не крупная покупка программного обеспечения. Это может быть лучший шаблон требований, четкий владелец утверждения или пятиминутная проверка перед тем, как файл поступит в производство. Если ошибки измеряются тщательно, сокращение на 40 % может показать, где команда исследований и разработок теряет время и как это время можно компенсировать. Число имеет значение, но процесс, стоящий за ним, имеет большее значение. Команда, которая узнает, почему возникают ошибки, может принимать более правильные решения, обеспечивать качество тестирования и давать инженерам больше возможностей для решения проблем, которые действительно требуют их навыков. Свяжитесь с нами по Хуану: info@nb-chuanghan.com/WhatsApp +8618868399669.

Ссылки Международная организация по стандартизации, 2015 г. Требования к системам управления качеством, Национальное управление по аэронавтике и исследованию космического пространства, 2016 г. Справочник по системному проектированию НАСА, Институт управления проектами, 2021 г. Руководство по управлению проектами, свод знаний Руководство PMBOK, Международная организация по стандартизации, 2018 г. Разработка систем и программного обеспечения. Процессы жизненного цикла. Разработка требований. Вомак Джеймс П. и Джонс Дэниел Т., 1996 г. Бережливое мышление, изгнание отходов и создание богатства в вашей корпорации, Деминг Эдвардс, 1986 г. Кризис