Чрезмерная инженерия влияет больше, чем вы думаете
Чаще всего люди действуют осторожно, а не рискуют. Человеку свойственно не рисковать.
При разработке программных продуктов это иногда создает большую сложность, чем необходимо. А в других случаях упускаются необходимые детали, что приводит к недоработке продукта. Баланс нетривиальный.
Макс Канат-Александер объясняет, что чрезмерная инженерия - это «когда ваш дизайн или код на самом деле усложняют вещи, а не упрощают их».
Когда ваш дизайн или код на самом деле усложняют вещи, а не упрощают их, вы занимаетесь чрезмерной инженерией. - Макс Канат-Александр
Излишняя разработка программных продуктов - это норма, и зачастую это происходит не сразу.
Одна из причин этого заключается в том, что мы сосредоточены на постоянном предоставлении ценности, избегая при этом давления сроков, конкуренции, неопределенности и двусмысленности, которые возникают при разработке программного обеспечения.
В результате чрезмерная инженерия отрицательно сказывается на производительности команды, поскольку теперь необходимо управлять бременем дополнительной сложности.
Это отнимает больше времени, отвлекает нас от работы над «крутыми вещами» и еще больше усугубляет и без того сжатые сроки. В конце концов, достижение поставленных бизнес-целей и задач становится более сложным.
Для менеджера по продукту крайне важно уметь определять, когда ваш продукт подвергается чрезмерной разработке, поскольку это может повлиять на вашу способность быстро продвигаться. Один из распространенных симптомов чрезмерной разработки - неуверенность в том, в каком направлении движется продукт. Вскоре я остановлюсь на других симптомах.
Реальность такова, что мы не сможем предотвратить или устранить чрезмерную инженерию из-за врожденных черт человека. Мы естественно предвзяты. Быстрое автоматическое мышление - в нашей природе. Но это не оправдание незнанию.
Здесь я собираюсь поделиться своими мыслями о том, почему мы склонны чрезмерно разрабатывать программные продукты, как это выглядит, почему это проблема, которую стоит решать, и какие шаги мы можем предпринять для ее решения.
Почему чрезмерная инженерия - это норма
Представьте, что вам было поручено создать мобильное приложение, которое позволит людям в густонаселенных районах легко и удобно обмениваться домашними продуктами и товарами домашнего приготовления (например, органической закваской, чайным грибом и т. Д.).
Сразу возникает несколько вопросов. Они могут быть одними из следующих:
- Сколько будет стоить строительство?
- Сколько времени займет сборка?
- Какая самая важная проблема, которую мы хотим решить?
- Какие функции мы должны создать?
- Какие навыки нам нужны, чтобы создать это мобильное приложение?
- Как целевые пользователи могут получить доступ к этому приложению?
Можно задать бесчисленное множество других вопросов. Некоторые вопросы могут даже показаться неуместными, но это не так, потому что каждый вопрос имеет причину или влияние на другой. Все связано.
Донелла Медоуз, влиятельный автор книги Thinking In Systems, подробно объясняет эту связь с помощью концепции петель обратной связи.
Возвращаясь к примеру с мобильным приложением: проблема в том, что товары местного производства выбрасываются в отходы, или что мы потребляем продукты массового производства, не имеющие качественного питания, или что-то еще?
Если конкретная проблема не была определена как стоящая для решения, то как мы узнаем, какие функции следует сделать в первую очередь и инвестировать в строительство?
Неопределенная проблема может способствовать чрезмерной инженерии просто потому, что команда в конечном итоге займется разработкой и созданием функций либо на всякий случай, либо потому, что это может решить одну из проблем. Это также затрудняет измерение успеха.
Вообще говоря, есть две основные причины, по которым мы чрезмерно занимаемся разработкой программных продуктов.
Причина 1. Разработка программного обеспечения - это упражнение по решению проблем.
Во-первых, разработка программного обеспечения - это неуверенный путь экспериментов, основанный на видении продукта. Мы используем инструменты, методологии (например, Lean Startup и The Design Sprint) и различные навыки, чтобы воплотить концепции в жизнь.
Не существует руководства или шаблона для разработки программных продуктов, а реализовать продукт или функцию можно сотнями способов. Точно неизвестно, когда продукт привлечет массовое распространение или достигнет соответствия требованиям рынка.
Наши требования к продукту часто меняются или развиваются по мере того, как мы собираем идеи в результате исследований, собираем отзывы клиентов, тестируем новые идеи и концепции прототипов.
Это все потому, что разработка программного продукта - это упражнение по решению проблем. Формула создания коммерчески жизнеспособных программных продуктов сложна. Сделать это правильно с первого раза - все равно что выиграть в лотерею.
Причина 2: люди часто иррациональны
Во-вторых, люди разрабатывают программные продукты в динамической среде. Мы жаждем определенности, но в разработке программного обеспечения нет ничего определенного. У нас также сложный ум, но то, как мы принимаем решения и справляемся с предвзятостью, непросто.
Подсчитано, что средний взрослый человек ежедневно принимает 35 000 удаленно осознанных решений. Удивительно, но интересно, как мало мы контролируем наш повседневный мыслительный процесс.
Я могу только представить, что думают лица, принимающие решения, которые решают, сколько инвестировать в новые бизнес-инициативы.
Смартфоны и другие интеллектуальные устройства также изменили способ поглощения информации и взаимодействия с ней, поскольку они действуют как невидимый кабель для передачи цифровой информации в наш разум и из него.
Это дополнительно поощряет наше инстинктивное, автоматическое и эмоциональное (система 1) мышление. Однако это противоположное мышление, которое в основном требуется для разработки успешных программных продуктов. Чтобы принимать правильные решения, нам нужно мыслить критически.
В дополнение к тому, как мы запрограммированы на работу как люди, существует необходимость продемонстрировать ценность для клиентов, захватить долю рынка и привлечь таланты. Все бизнес-инициативы в конечном итоге должны приносить ожидаемую прибыль на свои инвестиции.
Что еще более важно, программный продукт должен быть коммерчески жизнеспособным. Это, в сочетании с двумя основными причинами, указанными выше, является нормой из-за чрезмерной инженерии.
А поскольку неясно, что именно нужно спроектировать и построить для достижения определенной отдачи и захвата определенного размера рынка, нам необходимо сохранять проектирование и разработку программных продуктов как можно более гибкими.
Чтобы идентифицировать чрезмерно спроектированное программное обеспечение, нам сначала нужно понять, как выглядит чрезмерно спроектированное программное обеспечение.
Симптомы чрезмерной инженерии
Программные продукты часто подвергаются чрезмерной инженерии либо с точки зрения дизайна, либо с точки зрения кода. Они проявляются как определенное поведение или действия. Многие из тех, кто занимается разработкой программных продуктов, вероятно, знакомы с симптомами чрезмерной инженерии.
Вот как некоторые люди в сообществе разработчиков программного обеспечения описывают симптомы.
Джефф Стернал описывает сверхинжиниринг как:
«Код, решающий проблемы, которых у вас нет».
Излишняя инженерия может проявляться в архитектуре программного обеспечения, инфраструктуре и безопасности. Марко Вуксанович приводит несколько примеров в этих областях:
«Создание архитектуры микросервисов, когда у вас нет ни одного клиента».
«Разработка системы с задержкой 50 мс, когда вашим пользователям нужно около 10 секунд».
«Когда дело доходит до безопасности, мы разрабатываем такие угрозы, которые не имеют отношения к вашему бизнесу».
Пишете ли вы статью, создаете презентацию, проектируете пользовательский интерфейс или проектируете архитектуру платформы, перо на бумагу по-прежнему остается отличным методом для выражения ваших мыслей, чтобы их можно было лучше организовать.
То же самое и с написанием кода. Дсимча поясняет:
«… когда все проходит через столько косвенных обращений, что трудно найти фрагмент кода, который действительно реализует какую-то конкретную часть функциональности на уровне предметной области».
Если у нас есть плохой опыт, с этого момента мы склонны «делать немного больше», чтобы подготовиться к непредвиденному неизвестному. При разработке продукта это опасно, потому что мы:
«строить больше, чем действительно необходимо, на основе предположений».
Джон Ким объясняет, что существуют два золотых правила программирования: 1. Легко понять и 2. Легко изменить. Он заявляет, что они часто конфликтуют друг с другом:
«Код, который легко читать и понимать, часто означает, что код трудно изменить при изменении требований программы. Как ни странно, верно и обратное ».
Марк Канлас, инженер-программист Apple, поделился на Quora, что:
«Излишний инжиниринг - это решение проблемы с одновременной оптимизацией для других, третичных условий, которые вряд ли верны, что приводит к увеличению затрат».
Также бывают случаи, когда у нас вообще нет законной причины. Функции разработаны, а код реализован, исходя из предположения, что он нам, скорее всего, не понадобится, но мы все равно делаем это «на всякий случай» или из-за классической фразы «у нас есть грандиозное видение».
Ранее я упоминал, что чрезмерная инженерия - это тоже концепция, которая применима к команде, разрабатывающей продукт. Как разработчики продуктов, мы проводим исследования пользователей, чтобы помочь нам определить, какие болевые точки должны быть приоритетными для решения и какие выгоды должны быть получены для конечного пользователя.
Вкратце, данные не говорят нам ни о том, что нужно спроектировать, ни о том, как спроектировать решение. Следовательно, получение правильной функции или дизайна продукта с первого раза - редкое явление.
Мы делаем некоторые предположения, а иногда и слишком много. По сути, мы в конечном итоге заглядываем слишком далеко в будущее. В результате совместные усилия разработчиков продукта, дизайнеров и инженеров иногда создают больше, чем нужно пользователям.
Я уверен, что многие, если не все, вышеперечисленные симптомы вам были знакомы, если вы участвовали в создании программного продукта. Но почему нам должно быть до этого дело?
Давайте посмотрим на некоторые последствия чрезмерной инженерии.
Последствия чрезмерной инженерии
Излишняя разработка продукта влечет за собой множество последствий, но в конечном итоге это ограничивает способность организации реагировать на изменения. Давайте раскроем это.
Более высокие бизнес-расходы
Излишний инжиниринг ведет к более высоким бизнес-затратам, многие из которых «невидимы». Самая большая проблема здесь - точно отслеживать все воздействия и особенности понесенных затрат.
Более того, возможность заранее спрогнозировать эти непредвиденные расходы, по-видимому, является разовым, а не ежедневным упражнением. Издержки могут быть понесены в виде технической задолженности, снижения операционной эффективности, увеличения расходов и / или несвоевременной доставки стоимости.
Последнее имеет множество эффектов, связанных с инициативами в разных командах.
Например, отдел продаж и маркетинга часто ведет работу параллельно с разработкой продукта в рамках подготовки к запуску продукта, поэтому изменения в этом расписании означают перерывы в выполнении других запланированных работ, которые находятся в процессе продаж и маркетинга.
Чем больше денег будет потрачено на непредвиденные расходы и перерывы в работе, тем меньше денег будет потрачено на новые возможности, такие как изучение инноваций и найм уникальных талантов.
Накопление технического долга
Продукты часто разрабатываются в быстро меняющейся, динамичной среде. Сроки часто пропускаются, а неизвестные неизвестные - это норма. Менеджеры по продукту идут на компромиссы посекундно, а инженеры ежеминутно вносят изменения в код в продакшн.
Частые изменения и тяжелые условия затрудняют принятие правильных решений, что часто приводит к техническому долгу. Психологически проще поместить карточку технического долга в столбец невыполненной работы. На самом деле мы не оглядываемся назад, потому что слишком сосредоточены на быстром движении вперед.
Этот технический долг, если оставить его без внимания слишком долго, снижает производительность и эффективность работы всей группы разработки продукта.
Например, повышенная сложность кода усложняет инженерам понимание и развитие в будущем. Другой пример: больше времени тратится на дискуссии о том, как справиться с бременем, вызванным принятыми сокращениями, или устранить его.
Это отнимает время от обсуждения способов развития платформы, например какие эксперименты мы можем провести, чтобы увеличить удержание.
Аналогичным образом, в случае повышенной сложности кода инженеры тратят больше времени на понимание реализации будущих решений и управление долгом, а не на то, как улучшить производительность продукта, оптимизировать выпуск новых функций и т. Д.
Снижение продуктивности и эффективности команды
Несвоевременная доставка стоимости также связана с основным последствием. При работе с командами, которым неясно цели и задачи своего бизнеса, они теряют эффективность в успешной реализации продукта в одной команде.
Например, я работал с компанией, которая уделяла приоритетное внимание запуску новой функции. Для его успешной реализации требовалось объединение усилий от дизайна, продукта, инженерного маркетинга, поддержки клиентов и продаж.
Однако бизнес-цели и задачи этой функции не были четко поняты разными командами. Результатом стала функция низкого качества из-за несоответствия понимания. Как вы понимаете, это привело к некачественному пользовательскому опыту для клиентов.
Вышеперечисленные последствия в конечном итоге приводят к снижению морального духа команды и снижению мотивации. Кроме того, затраты на разработку продукта оказываются выше, чем предполагалось изначально.
Все эти последствия сводятся к затратам. Из-за этого предприятия рискуют не получить ожидаемую отдачу от инвестиций. Чтобы снизить этот риск, давайте теперь посмотрим, как мы обнаруживаем чрезмерную разработку программного обеспечения.
Как с этим справиться
Излишне спроектированные продукты часто имеют экспоненциальный эффект перетекания, который опасен тем, что проявляется не сразу.
Например, я работал над продуктом, который определял бизнес-процессы для нового продукта. Когда дело дошло до разработки рабочих процессов в продукте, вместо того, чтобы начинать с основных рабочих процессов, все рабочие процессы были реализованы сразу.
Много времени было потрачено на изучение и попытки усовершенствовать рабочие процессы до внедрения. К нашему разочарованию, в результате получился слишком сложный набор рабочих процессов, которые было трудно использовать в реальной жизни.
Из раннего пользовательского тестирования мы узнали, что некоторые рабочие процессы были слишком жесткими в «особых» и редких ситуациях. Мы также узнали, что рабочие процессы были скорее руководящими принципами, чем точными инструкциями, которым строго следовали.
Неполное понимание этого привело к ненужной работе по разработке и неудовлетворительному пользовательскому опыту для пользователей. Следовательно, важно, чтобы мы принимали обоснованные решения о том, как расставить приоритеты в работе и снизить риски.
Итак, как нам поймать себя на месте преступления?
Марко Вуксанович, ведущий консультант ThoughtWorks, может быстро и легко определить, слишком ли вы слишком изобретательны. Просто сделайте это:
«Спросите: « Что будет, если мы опустим X? » и если ответ: «Ничего» или «Ничего важного для бизнес-целей», значит, вы, вероятно, слишком изобретательны ».
Но это не серебряная пуля, и ее не существует. Когда дело доходит до разработки программных продуктов, полной информации не существует. Поэтому критическое мышление играет важную роль.
Задавать такие вопросы, как: "Что такое слишком много кода?" и "Что за дизайн?" бесполезны, потому что приводят к субъективному ответу. Кроме того, нет надежного способа измерения того, что такое правильный объем кода или дизайна.
Количество кода или времени, потраченного на дизайн, не одинаково для какой-либо функции, улучшения или продукта. Все зависит от контекста, требований и текущей проблемы, которую вы хотите решить.
С другой стороны, наставничество и обеспечение хороших навыков принятия решений внутри и между командами могут помочь обнаружить чрезмерную инженерию. В частности, мы можем поймать себя на месте, задав несколько вопросов.
Эти вопросы могут помочь в определении правильного баланса между объемом разработки и кодом, написанным во время реализации продукта. Таким образом, мы можем принимать лучшие решения.
Шесть вопросов для его обнаружения
- Какую проблему мы решаем и как этот код / дизайн решает ее напрямую?
- Какие сценарии или пользовательские истории решит ваш код / дизайн? Какая самая важная пользовательская история нам нужна?
- Почему вы выбрали этот подход к дизайну / реализации?
- Какими альтернативными способами мы могли бы подойти к реализации (например, фреймворк, язык и т. Д.)?
- Это самый простой способ разработать / реализовать требование? Если нет, то каковы другие способы?
- Можем ли мы сделать это проще и при этом выполнить требование?
Если нет уверенности в ответах на один или несколько приведенных выше вопросов, высока вероятность того, что произошла чрезмерная инженерия. На этом этапе было бы разумно остановиться и уточнить, чего вы и ваша команда стремитесь достичь.
Затем тщательно просмотрите дизайн и / или код, чтобы свести к минимуму излишнюю инженерию. Это не полный список вопросов, которые нужно задать, а скорее те, которые я нашел полезными по своему опыту при работе с различными группами разработчиков и разработчиков.
Лучший способ избежать излишней инженерии - просто не загадывать слишком далеко в будущее. - Макс Канат-Александр, автор книг Простота кода и Понимание программного обеспечения
Хотя обнаружение и сведение к минимуму излишней инженерии - это улучшение, лучший подход - в первую очередь избегать излишней инженерии, не проектируя слишком далеко в будущем.
Четыре способа избежать чрезмерной инженерии
- Определите и сообщайте цели с четкими показателями успеха.
- Сделайте требования прозрачными.
- Обязательно сообщайте о зависимостях и сотрудничайте по мере необходимости, чтобы найти лучшие решения.
- Оценивайте свой продукт на ранней стадии и часто с помощью моделирования того, как он будет использоваться, чтобы вы могли определить, приносит ли ваш продукт ожидаемую ценность.
В редких случаях излишняя инженерия является результатом определенного бизнес-решения или стратегии по более быстрому выводу продукта на рынок.
Тем не менее, это делается с учетом того, что в ближайшем будущем потребуются дополнительные время и затраты на разработку плана устранения последствий чрезмерной инженерии.
«Идеальное - враг достаточно хорошего, сделанное лучше, чем совершенное» - Хелен Маккуин.
Если мы сможем осознанно развиваться, критически мыслить и эффективно сотрудничать, команды получат возможность добиваться результатов, в частности эффективно решать проблемы и быстро адаптироваться к изменениям.
Если вы спросите: «Что произойдет, если мы опустим X?» а ответ - «Ничего» или «Ничего важного для бизнес-целей», значит, вы, вероятно, слишком изобретательны.
Заключение
У вас есть подобный опыт? Я хотел бы услышать любые другие вопросы или приемы, которые вы сочли полезными для определения того, не перегружается ли ваш программный продукт. Не стесняйтесь делиться в комментариях ниже.
