Оверинжиниринг что это

Моя страсть к оверинжинирингу

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

1.2K открытий

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

Что приводит к оверинжинирингу?

• Перфекционизм. Хочется, чтобы все было выстроено правильно с самого начала и было готово к масштабированию.
• Широкий выбор инструментов для разработки. С бесконечным выбором бесплатных инструментов, библиотек, фреймворков можно легко превратить простой Hello, World! в приложение, требующее установку десятка библиотек.

Node.js packages

• Незнание истории великих продуктов. Первая версия многих известных продуктов, совершенно не впечатляла:

Скриншот первой версии Amazon.com

• Миф о «супер-программисте».Супер-программисты (они же ninja developers) это такие программисты, которые сразу пишут красивый и правильно работающий код. При этом, они еще и работают сто раз быстрее.

Типичный Ninja Developer

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

Snapachat в 2013 году Screenshots by Bobby Goodlatte

• Превращение идеи продукта в идею создания платформы. Программистам нравится делать свои платформы. Пример такого подхода: «У меня есть идея для приложения с обработкой фотографий -> Хм, а может сделать платформу для таких приложений? -> Точно, а сначала сделаем свой фреймворк для создания таких платформ!«. Создавать платформу для несуществующих еще приложений тяжело, даже при наличии ресурсов.

3 комментария

Не хватает определения оверинжиниринга 🙂

Развернуть ветку

@Laisan Shafikova спасибо, добавил в статью!

Развернуть ветку

@E M , спасибо за статью — прямо в точку!
@Laisan Shafikova , за запрос определения — тоже спасибо: оно вроде интуитивно-то и понятно, на без годного определения эти соображения трудно использовать как аргумент.

Ссылочку на демо-стенд оверинжиниринга могу выдать прямо сейчас, там и про платформу даже есть 😉

Оверинжиниринг что это

Как известно, классическая концепция бережливого производства выделяет семь видов потерь, которые сформулировал более полувека назад Тайити Оно, исполнительный директор Toyota. На практике одному из видов потерь уделяется, на наш взгляд, меньше внимания, чем остальным. В разных источниках его называют и трактуют немного по-разному. В российской литературе его чаще называют «излишняя обработка» или «ненужные этапы обработки».

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

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

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

Кто важнее инженер или клиент ?

В западной литературе для описания этого вида потерь иногда используется термин Overengineering или Over-Engineering, дословно – «сверхинжиниринг».

Слово «оверинжиниринг» проникло и в русский язык, но пока его чаще используют компьютерщики для обозначение излишне громоздкого ( «индусского») кода. Специалисты говорят, что когда-то индийским программистам платили за строчки написанных ими программ, поэтому они выдавали сложный, объемный, витиеватый код.

Оверинжиниринг в производственном смысле имеет два аспекта:

• изготовление продукта слишком сложным и затратным способом – «из пушки по воробьям»,
• сам продукт может быть сверхинжиниринговым — с более высоким качеством, чем это требуется клиенту, с излишними свойствами и опциями.

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

Слово «оверинжиниринг» замечательно тем, что указывает на роль инженеров в происхождение данного вида производственных потерь.

Причиной оверинжиниринга может быть завышенный перфекционизм при производстве продукта. Самые современные станки, самые передовые технологии, самые лучшие материалы – все это составляет предмет гордости технических работников. Производственники часто не задаются вопросом можно ли сделать процесс проще и применить более простые средства. Спросите оператора, почему он выполняет операцию именно таким образом, и если в ответ Вы услышите: «Мы всегда так делали», — это четкое указание на несовершенство процессов.

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

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

Сила и слабость инженерного подхода

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

В книге Джеймса Вумека и Дэниела Джонса «Бережливое производство» целая глава называется «Бережливое производство бросает вызов немецкой традиции». В ней приводится драматическая история фирмы Porsche. На производстве трудились самые квалифицированные рабочие и инженеры Германии, они создавали шедевры автомобилестроения, но без оглядки на потери, в том числе и на оверинжиниринг. В результате прибыль в 10 миллионов долларов, которую компания получила в 1990-1991 годах, в 1991-1992 годах обратилась в 40-миллионные убытки при продажах в 1,5 миллиарда долларов. Легендарная марка оказалась на грани краха.

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

Как бы ни был далек уровень производства в России от такового в Германии, инженерный уклон и у нас также силен. Локомотивами индустрии в СССР были оборонные предприятия. Во главе «фирм» стояли главные конструкторы, задачей которых было создание «изделий», наилучшим образом выполняющих свои функции, надежность, мощность, многократный запас прочности. Никаких упрощений, унификации, никакой технологичности. Об экономике никто не думал — цена не имела никакого значения.

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

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

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

Как избежать оверинжиниринга ?

Практика показывает, что для различных товаров затраты за счет сокращения функций и свойств, которые не требуются потребителям, могут быть снижены от 10 до 30 %, а иногда и больше. Поэтому вложения в изучение предпочтений покупателей окупаются за счет снижения издержек. Целенаправленные улучшения на основе результатов подобных исследований гораздо более эффективны, чем работа под абстрактным девизом: «Делать все лучше».

Оденьте «очки клиентов» и посмотрите на свои процессы и на сам товар. Может выяснится, что решение о покупке потребитель принимает совсем не по тем причинам, о которых Вы думали.

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

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

Смотрите также.

FIXING TOYOTA
ХОРОШО, КОГДА ЕСТЬ С КЕМ ПОСОВЕТОВАТЬСЯ !
КАК ЗАРАБОТАТЬ НА МЕБЕЛЬНОМ ПРОИЗВОДСТВЕ

О проекте

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

Темы

• Автоматизация
• Взгляд со стороны
• Выставки
• Любопытные факты
• Оборудование
• Организация производства
• Передовой опыт
• События

Оверинжиниринг блоггинга

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

Звучит как добрая фантастика, если честно. Но сама идея хорошая. Я иногда думаю — не сделать ли так же, но боюсь, что шутку не оценят.

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

К примеру, если бы я хотел рассказать, что iPhone и вообще современные смартфоны — это продукт наркоманского бреда, а не инженерного расчета, то написал бы много правдивых и проверяемых историй по двум темам
1. Как Стив Джобс и соучастники в молодости отрывались по полной
2. Душераздирающие признания современных мобильных разработчиков о дичи, которая творится в API у крупных корпораций.

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

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

Еще я вспоминаю странных динозавров древней эволюции гаджетов — эх, какие веселые уродцы тогда возникали! Похоже, все деньги уходили на дизайнеров.

А Apple тупо пришла и показала, что главное — стандарты софта и фашизм в дизайне. Глядя на них, даже Google пытается делать фашизм в дизайне и рекомендованные практики, но у них не такой суровый фильтр в магазине. Это — только один из реальных факторов продуманности и стратегичности гигантов рынка.

6 грехов, которые совершают программисты

Эта статья — перевод с medium.com, в которой Daan, ее автор, предостерегает нас от неверных решений при выборе между скоростью и эффективностью в программировании.

Фото с сайта Unsplash. Автор: Artem Sapegin

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

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

Итак, 6 вещей, которые делают программисты, прекрасно зная о негативных последствиях.

1. Поспешные решения

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

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

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

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

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

2. Привычка проглатывать ошибки в коде

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

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

Можно представить себе несколько прецедентов, в которых было бы предпочтительнее скрыть уведомление об ошибке (например, по какой-либо причине не удалось создать лог-файл, но сообщить об этом негде). Тем не менее, как показывает опыт, этого лучше не делать.

3. Оверинжиниринг

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

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

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

4. Попытки изобрести велосипед

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

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

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

5. Неинформативные комментарии к коммитам

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

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

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

6. Прокрастинация

С ней вы будете сталкиваться довольно часто. Разработчики, как правило, прокрастинируют, когда они в тупике или проект «не заходит». В какой-то момент вы можете обнаружить, что прокрастинируете, потому что не видите леса за деревьями. Количество работы, которая должна быть сделана, настолько давит, что в итоге вы не делаете ничего.

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

Действие побеждает бездействие (Ог Мандино).

Подводя итог

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

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

Спасибо за чтение!

• программирование
• карьера программиста
• разработка
• советы

• Блог компании Plarium
• Программирование
• Карьера в IT-индустрии
• Лайфхаки для гиков