Элияху Голдратт, Джефф Кокс

Ай, что-то необычное в моем книжном дайджесте, вы спросите почему? Потому что эта книга одновременно о производственных и операционных процессах, но в жанре романа

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

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

Теория ограничений (Theory of Constraints) Основной посыл книги — рассказать о теории, согласно которой любой процесс имеет узкие места (ограничения), которые необходимо выявлять и совершенствовать для повышения эффективности и увеличения производительности всей системы

Как дизайнер не могу не попробовать адаптировать принципы ТОС к UX/UI:

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

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

• Максимизация производительности узкого места. Если критическая точка найдена, важно не просто её устранить, а сделать так, чтобы она больше не тормозила взаимодействие. Возможно, проблема вообще не в ней, а в подаче информации до этого момента

• Управление по целям. Любые решения должны соотноситься с бизнес-целями и пользовательскими сценариями

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

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

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

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

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

Наверное, я заслуживаю награду «душнилы года». А еще буду рада послушать ваше мнение

О самой книге я узнала через лекцию Ильи Красинского, тоже советую