Предлагаю вашему вниманию перевод статьи, которую я упоминал в заметке «Потери, ПОТЕРИ и потери: все виды классификаций«.
Потери, обнаруженные в производстве, хорошо известны и относительно заметны. Но по мере того, как вы поднимаетесь вверх по потоку в совершенно иную сферу разработки продуктов, отходы становится сложнее находить, но они так же широко распространены. Этот список «грязной дюжины» потерь разработки, представленный Катриной Аппелл и Джоном Дрогошем, раскроет вам глаза.
Обнаруженные в производстве потери хорошо документировали на протяжении многих лет. По мере того, как мы поднимаемся по потоку к разработке продукта, среда явно меняется, но, к сожалению, потери по прежнему остаются широко распространены. Их сложнее «увидеть», поскольку они превращаются в другие категории, нежели те, которые можно найти на заводе. Основываясь на работах Джима Моргана, Джеффри Лайкера, Аллена Уорда и на нашем собственном опыте, мы приводим далее некоторые потери, которые обычно встречаются в разработке продуктов и процессов.
1. Передача
Передача информации или материалов от одной команды к другой. Хотя большинство передач информации в разрабоке продукта в наши дни выполняется в электронном виде, может возникнуть множество потерь из-за неправильного понимания передаваемой информации и/или ожидания обратной связи от коллег.
2. Ожидание
Ожидание данных, ответов, решений, обзоров событий и ресурсов (людей или оборудования). Это одна из самых распространённых потерь при разработке продукта, на которую приходится более 30% времени выполнения проекта.
3. Избыточные усилия
Усилия и расходы, потраченные на создание данных, которые никогда не будут использованы. Это похоже на избыточную обработку в условиях производства. Мы создаём всё больше и больше данных, но действительно ли это знания, которые можно использовать повторно и которые создают ценность? Обновления статуса (проекта) и отчеты — это тоже область работы, в которой мы склонны тратить избыточные усилия.
4. Переделка / избыточные задачи
Повторение одной и той же работы снова и снова — исправление ошибок, множественные проверки одной и той же информации или множественные согласования. Некоторые итеративные подходы к точечной разработке также приводят к значительным переделкам и потере времени. Отсутствие в нужное время кросс-функциональных вводных данных также может привести к перепроектированию/переделке.
5. Остановки и (пере)запуски задач
Человеку каждый раз приходится переключать себя на задачу. Это требует множества «настроек», которые приводят к дополнительным усилиям и задержкам. Создавая иллюзию продвижения вперёд, некоторые виды многозадачности приводят к остановкам и запускам и увеличивают время выполнения заказа.
6. Потери повторного изобретения
Воссоздание или повторное переоткрытие знаний, которыми мы уже обладаем и которые можем повторно использовать. Также сюда входят и знания, доступные за пределами организации. Подход «это не мы изобрели» может привести к повторным изобретениям.
7. Неиспользованные / неправильно использованные таланты
Люди, которые работают над проектами и задачами, которые ненужны и нежелаемы клиентом. Это одна из худших потерь, поскольку не полностью используются таланты нашего наиболее ценного актива — наши квалифицированные сотрудники могут испытать деморализацию. Никто не хочет работать над продуктом, который клиенты не покупают! Помните, что бережливое производство нацелено на вовлечение людей.
8. Транзакционные потери
Это время и усилия по организации работы, которую нужно выполнить (например, переговоры по контракту, расценки, планирование ресурсов, финансовая отчетность). Некоторые из этих задачи не добавляют ценности, но необходимы, в то время как другие — расточительное отвлечение от нашей добавляющей ценность работы.
9. Большая вариативность процесса или входа
Вариативность процесса может вызывать тем, что каждый делает работу по-своему или потому, что его не обучали выполнению стандартного процесса. Обычно это приводит к вариативности входа, поскольку переменное время выполнения работы приводит к неопределённости с доставкой результатов работы последующим этапам потока.
10. Перегрузка системы
Назначение системе слишком большого количества работ. Когда загрузка системы достигает приблизительно 80%, небольшое добавление работы резко увеличивает время выполнения всех работ в данной системе. Выпуск больших партий вносит большой вклад в перегрузку системы, поскольку они перегружают людей и увеличивают время цикла. Чрезмерная загрузка может возникать на любых уровнях — в проектах, отделах и на отдельных рабочих местах.
11. Принятие желаемого за действительное
Как впервые указал Алан Уорд, широко признанный пионер в области бережливой разработки продуктов и процессов (LPPD), этот вид потерь может принимать несколько форм. Принятие желаемого за действительное можно увидеть в принятии решений при нехватке знаний, в установке произвольных сроков, в оценке времени выполнения задач и в чрезмерно оптимистичных ожиданиях от обучения или открытия новых знаний.
12. Несинхронизированные конкурентные задачи
Одна из наиболее коварных потерь. Кажется, что работать одновременно над несколькими задачами правильно, но несинхронихированные параллельные задачи часто становятся корневой причиной большого количества других вышеперечисленных потерь. Подробнее о Темной стороне параллельного проектирования будет рассказно в отдельной статье.
Возможно, вы заметили некоторые из вышеперечисленных потерь в своих процессах? Поскольку все так заняты повседневной работой, мы иногда просто принимаем все эти потери как данность своей работы. Однако, единственный способ высвободить время для создания новой ценности — это начать обнаруживать и устранять эти потери. Хороший способ увидеть потери и понять связи между ними — это построение карты потока создания ценности при разработке продукта.
Оригинал статьи можно найти здесь.