Сверхинжиниринг в разработке программного обеспечения: что это такое, почему это происходит и что это на самом деле означает для начинающего бизнеса и его MVP?
Что такое оверинжиниринг? Почему разработчики это делают и 4 способа избежать этого
Насколько сложным должно быть ваше программное обеспечение? Общее эмпирическое правило заключается в том, что архитектура и код никогда не должны быть более сложными, чем они должны быть. Большинство из нас интуитивно знает, что чем меньше, тем лучше, но зачастую очень сложно добиться простоты и элегантности в разработке программного обеспечения.
Причина отказа от простых вещей — перфекционизм, амбиции и недостаток общения между членами команды — они хотят, чтобы их приложения затмевали все остальные приложения. Очевидно, что этого невозможно достичь, и это усложняет программное обеспечение, так что его трудно поддерживать и масштабировать.
Как технический директор MasterBorn, я всегда слежу за тем, чтобы написанный код отвечал потребностям бизнеса и клиента, а не перфекционистским устремлениям разработчиков… В этой статье я расскажу вам больше об Оверинжиниринге и его влиянии на продуктивность Команды и бизнес.
Что такое оверинжиниринг?
Сверхинжиниринг — это разработка продукта, который имеет больше функций и возможностей, чем действительно нужно и требуется бизнесу. Это слишком сложно или слишком идеально и красиво. На начальных этапах разработки продукта такой подход не нужен и подвергает стартапы убыткам, поэтому так важно эффективно распознавать симптомы переинжиниринга.
Симптомы чрезмерной инженерии
Один из самых явных симптомов чрезмерной инженерии — попытка решить все краеугольные случаи приложения. Крайний случай — это ситуация, которая происходит за пределами нормальных рабочих параметров.
Примером крайнего случая может быть пользователь, пытающийся заказать 20 автомобилей Uber для всех своих друзей одновременно из одного приложения. Хотя такой угловой случай технически возможен, он не очень распространен. Таким образом, вопрос к командам разработчиков заключается в том, должны ли мы тратить время и деньги, чтобы убедиться, что такой сценарий жизнеспособен в приложении? Возможно нет.
Еще одним признаком чрезмерной инженерии является попытка найти идеальное решение, а не достаточно хорошее. Подумайте о команде, которая целую вечность размышляет над тем, должен ли цвет фона в приложении быть #FBFCFC или #F7F9F9; или разработчик, который целыми днями следит за тем, чтобы его код был чище и современнее, чем у кого-либо еще.
Погоня за инновациями ради них — еще один пример излишней инженерии. Идти по этой дороге довольно легко. Большинство разработчиков — новаторы, они любят экспериментировать и оставаться на вершине игры. Хотя в определенной степени это должно произойти, продуктам часто нужны не модные технологии, а быстрое время выхода на рынок.
Наконец, чрезмерная инженерия часто проявляется в разработке функций и возможностей, которые в данный момент не нужны. Иногда это вызвано непониманием пользователей, а иногда слишком далеким взглядом на будущее продукта без учета настоящего.
Чем не является оверинжиниринг
Избегание излишней инженерии не должно означать, что наши решения должны быть упрощенными или неуклюжими.
Например, поддержание согласованности стандартов кодирования очень важно и не должно считаться излишним. Это помогает гарантировать, что любой новый разработчик, присоединившийся к проекту, сможет легко ориентироваться в кодовой базе и быстро приступить к работе.
Хотя принцип Keep It Simple Stupid (KISS) является одним из ключевых факторов успеха любого стартапа, он не должен становиться религией. Иногда использование более сложной архитектуры или кода оправдано, и тогда его не следует избегать.
Важно поддерживать баланс между крайностями — если мы этого не сделаем, мы можем легко скатиться к недоинжинирингу, который так же опасен, как и переинжиниринг.
Опасности чрезмерного проектирования с точки зрения бизнеса
Что означает сверхинжиниринг для стартапа и его MVP? С точки зрения разработчика или архитектора, использование новейших технологий, сложного кода и создание программного обеспечения, готового ко всем вообразимым крайним случаям, может быть предметом гордости.
Но с точки зрения бизнеса чрезмерная инженерия означает более длительное время выхода на рынок (TTM), а выбор времени является одним из наиболее важных факторов успеха стартапа. Поскольку многие рынки и ниши уже переполнены, для новых компаний и приложений очень важно двигаться быстро и как можно скорее набирать обороты. Время, потраченное на ненужную разработку, просто снижает шансы на успех.
Чрезмерная инженерия также означает, что новые инженеры берут на себя разработку сложно и требуют больших усилий. Простые и понятные решения наиболее эффективны, так как не требуют особых знаний или навыков.
Сложность также оказывает еще одно важное влияние на программное обеспечение — чем сложнее и запутаннее кодовая база, тем больше остается места для технического долга. Для ясности: любой код, даже самый простой и элегантный, в какой-то момент устареет и потребует постоянного обслуживания, но чем он сложнее, тем больше шансов в какой-то момент столкнуться с этим айсбергом. Вы можете узнать больше о техническом долге и 6 вещах, которые должен знать бизнес здесь.
Забавный факт: инженеры тратят в среднем 33% своего времени на работу с техническим долгом.
Излишняя инженерия может быть желательна в некоторых моментах
Некоторые члены сообщества разработчиков могут возразить, что в некоторых случаях чрезмерная инженерия может быть желательна.
Одним из них является производительность и безопасность. Давайте представим программное обеспечение самолета, которое не принимает во внимание крайние случаи. В авиации есть определенные события, которые случаются крайне редко (множественные отказы двигателей, выход из строя всех гидросистем). Но то, что они не распространены, не означает, что бортовые системы не должны быть готовы к такому возникновению. Точно так же беспилотные автомобили должны быть готовы к экстремальным ситуациям, если они хотят, чтобы их воспринимали как заслуживающие доверия.
Другим примером желаемой сложности являются диагностические и медицинские инструменты, которые должны иметь множество функций, чтобы врачи не пропустили ни одного симптома заболевания. Например, современные УЗИ сканеры у вашего участкового кардиолога на 10% аппаратные и на 90% программные. Это помогает проводить сложные расчеты, интерпретировать звуки, издаваемые сердцем, и ставить диагноз, который даже хорошо обученный врач не смог бы поставить самостоятельно.
Интересно, что может быть много примеров менее важного программного обеспечения, когда чрезмерно усердный разработчик спас бизнес, внедрив функции, которые никому не были интересны. Но мы, вероятно, никогда не узнаем, потому что мы узнаем только о впечатляющих инженерных фиаско, а не о тихих успехах.
Как определить сверхинжиниринг?
Иногда бывает трудно быстро реагировать на попытки чрезмерной инженерии. Но вот несколько примеров утверждений, которые должны насторожить:
- «Похоже, этот веб-сайт не идеально работает в Chrome на iPhone 4 с вьетнамскими шрифтами — нам нужно это исправить!»
- «Привет, ребята, этот новый удивительный паттерн, только что запущенный в Силиконовой долине, набирает обороты. Мы должны использовать это, это так современно!»
- «Извините, что так долго разрабатывали запрошенную вами функцию. Я решил расширить его возможности и добавить три дополнительные функции, которые делают его действительно богатым».
- «Хорошо, поэтому я потратил последнюю неделю на подготовку нашей среды AWS для одновременной работы с десятью миллионами пользователей. Я знаю, что мы находимся на этапе проверки концепции, но нам лучше быть готовыми».
Вы понимаете, что я имею в виду, верно?
Почему команды склонны перепроектировать программные продукты?
Теперь давайте сосредоточимся на ключевых причинах чрезмерного проектирования в процессах разработки программного обеспечения.
Отсутствие деловой хватки у разработчиков
Большинство инженеров-программистов технически хорошо подготовлены, что желательно, но им иногда не хватает бизнес-перспективы, и они склонны полагаться на свою интуицию.
«Я думаю, что это приложение должно иметь этот функционал» иногда можно услышать, но просто думать недостаточно. Вы должны поговорить о расширении объема работ и точно объяснить это остальным членам команды.
перфекционизм
Идеальное — враг хорошего. Часто выполнение чего-либо идеальным образом приведет к достижению гораздо меньшего (как гласит правило Парето — 80% нашей работы основано на 20% времени, и вам нужно будет сосредоточить гораздо больше, чем оставшиеся 20% вашего времени, чтобы достичь 100% результатов). Имейте в виду, что идеального кода не существует, а изменяющаяся среда означает, что в какой-то момент вам все равно придется проводить его рефакторинг.
Настрой «на всякий случай»
Если вы думаете, что ваша идея может быть полезна позже, вы, как правило, сосредотачиваетесь на ней и теряете понимание более непосредственной бизнес-цели. Однако это немного сложно, так как это положительно и отрицательно одновременно. Если вы сделаете что-то на всякий случай, это впоследствии сэкономит вам много времени. Но в то же время, это может быть пустой тратой сейчас. Главное – все обдумывать и принимать осознанные решения.
Нужно показать
Звезды любят блистать, а некоторым нравится хвастаться. Хороший разработчик или лидер не должен хвастаться своими навыками и доказывать, что может делать сложные вещи. Они знают, что привлечение внимания к себе не обязательно означает успех продукта.
4 способа избежать чрезмерной инженерии
Оверинжиниринг: совет №1
Четко формулируйте бизнес-цели
Одной из ценностей нашей компании является Ясность, и, на мой взгляд, она имеет смысл в контексте Overengineering. Вы должны быть на одной волне со своей командой в отношении потребностей бизнеса и четко излагать их. Люди склонны уходить от сути, потому что не понимают ее. Если ваше общение честное и прозрачное, обычно достаточно поставить четкую цель, и команда продукта достигнет ее.
Оверинжиниринг: совет №2
Смешивайте личности в команде
Монокультуры — это головная боль: похожие люди думают и ведут себя одинаково, и в конечном итоге они будут тяготеть к очень специфическому способу ведения дел. И если ведущей чертой характера в команде является перфекционизм, это может привести к чрезмерной инженерии. Итак, у вас должны быть смешанные личности в команде и умный лидер, чтобы держать людей в страхе.
Оверинжиниринг: совет №3
Следите за прогрессом
Разработайте процедуру для отслеживания прогресса и будьте активны вместе с командой, чтобы выявлять первые признаки того, что кто-то делает что-то, выходящее за рамки. Общение важно здесь, а также вы должны быть в состоянии объяснить «почему». Понимание основного мышления, лежащего в основе продукта, поможет сохранить волнение и перековать его во что-то конструктивное.
Оверинжиниринг: совет №4
Не пытайтесь найти золотое правило
Универсальных ответов и решений нет. Не пытайтесь найти золотое правило для всего. Вы должны быть избирательны и критичны в своем мышлении, когда дело доходит до тенденций. Помните — контекст решает!
Краткое содержание
Оверинжиниринг встречается чаще, чем вы думаете. В той или иной степени это происходит почти в каждом проекте.
В MasterBorn я уделяю особое внимание обучению людей и разъяснению им процесса принятия решений. Это улучшает понимание общих целей и помогает нам сосредоточиться на важнейших аспектах работы, не тратя слишком много времени на приятные моменты.
Самое главное — принимать все решения, связанные с разработкой, с учетом MVP.
Стартап не должен просто хотеть создавать красивый код, ему НУЖЕН код высокого качества, чтобы быть успешным на рынке. Период.
Без бессмысленного чрезмерного проектирования стартапы, с которыми мы работаем, достигают быстрого прогресса, быстрого выхода на рынок и не переусердствуют со своими приложениями.
Дайте нам знать, если вы думаете о чрезмерной инженерии, и я буду рад поговорить!
