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

Например, Apple недавно представила автоматический подсчет ссылок для программ iOS. Это значительное улучшение по сравнению с вызовами ручного сохранения / разблокирования, которые раньше приходилось использовать. Код легче писать и легче поддерживать. Сам переход может привести к некоторым сбоям. Но как только они будут решены, количество случайных странных сбоев, вероятно, уменьшится.

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

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

Как мне справиться с ситуацией?

РЕДАКТИРОВАТЬ: Спасибо за ответы. Продолжай Поскольку это имеет отношение к моей ситуации, я должен дать понять, что мой менеджер и генеральный директор оба программисты - хотя генеральный директор, возможно, уже забыл, на что это похоже. Очевидно их стороны программиста были перегружены другими давлениями.

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

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

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

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

Вот некоторые факты, которые вы можете взять с собой по этому вопросу.

• Менеджмент, если они сами не программисты , не поймет Секрета Айсберга.
• Это проблема невежества, а не злого умысла. Генеральный директор хочет хороший продукт - он просто не понимает всего, что входит в хороший продукт.
• Генеральный директор (и ваш непосредственный начальник) не глупы - изучите и подготовьте некоторые факты и некоторые конкретные данные о том, почему вы должны тратить время на это и другие проблемы Айсберга.

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

Вы не

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

Я говорю, внесите ваши желаемые изменения в ваши следующие технические оценки. Эй, мы «должны» перейти на эту новую платформу, представленную Apple. Не позволяйте не использовать ARC в вашей дорожной карте. Там нет вариантов; переход на ARC - единственный путь.

Я уже отвечал на подобный вопрос здесь раньше, так что это можно считать дубликатом. По сути, вы не собираетесь подписывать «рефакторинг». Чтобы сделать код чище, следуйте правилу бойскаута: всегда оставляйте код чище, когда вы его покидаете, чем когда вы прибыли.

Точно так же, как погашение реального долга может показаться непреодолимой задачей (или навести порядок в грязном доме). Хитрость заключается в том, чтобы сделать его лучше по частям, пока вы не начнете видеть «острова чистоты». Как только вы наберете значительный импульс, другие разработчики в команде начнут замечать и в конечном итоге вносить свой вклад в задачу.

Я бы посоветовал прочитать « Чистый кодер» от «Дяди» Боба Мартина. Написание хорошего кода является частью вашей работы. Вы не спрашиваете разрешения делать свою работу, вы просто делаете это.

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

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

Удачи!

Представить бизнес-кейс

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

• Какова первоначальная стоимость?
• Какова текущая стоимость?
• Каковы предполагаемые сбережения денег / времени и откуда они берутся?
• Сколько времени пройдет, прежде чем мы увидим рентабельность инвестиций?

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

• Сколько времени в настоящее время тратит разработка на решение проблем, которые будут устранены или смягчены?
• Сколько жалоб пользователей вы получаете в связи с проблемами, которые это удалит или уменьшит?
• Какие еще преимущества это будет иметь?

Выстроить числа и сделать это грубое, но простое уравнение. Это будет стоить X, и это принесет пользу компании Y.

Примечание: не удивляйтесь, если внедрение академически хорошей идеи обходится слишком дорого.

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

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

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

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

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

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

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

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

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

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

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

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

Но, конечно, следуйте прекрасным советам, данным по улучшению вещей.

Вы, очевидно, работаете на босса с острыми волосами (PHB). Он больше не программирует, если вообще когда-либо, и если бы он это делал, он, вероятно, был не очень хорош (хотя ему нравится вставлять такие фразы, как «правильность констант» и «ошибка сегментации», чтобы ребята знали, что он заработал свои полосы) ) - вот как он выделился для управления.

Генеральный директор (у которого практически есть ирокез) любит PHB, потому что PHB предоставляет функции . На каждом спринте он с гордостью демонстрирует новый флажок (слегка смещенный, с неоднозначной меткой), блестящий значок (еще не работает ни в одной среде, но 8-битный цвет над Citrix) и форму (со случайными сбоями из-за условий гонки). в C на базе xml-варианта на заказ реализована локальная база данных, которую никто из команды разработчиков не осмелится трогать, потому что она была написана одной из легенд старой гвардии dev 10 лет назад и выполняет ВСЕ с макросами с 5-буквенными именами, независимо от того, нуждались ли они в 5 или не).

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

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

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

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

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

Вы оба правы и оба не правы, поэтому эти проблемы остаются на долгое время и вызывают неприятные чувства.

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

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

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

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

Как вы решаете эту проблему? Вы общаетесь и понимаете друг друга по ряду вопросов. Это, скорее всего, будет направлено на вовлечение и удовлетворение клиентов.

Чтобы решить эту проблему в стабильном и перспективном методе, договоримся о чем-то: измеряем стоимость исправления ошибок в старом коде. Измерьте время, которое требуется дополнительно для работы со старым программным обеспечением и как это будет с новой кодовой базой.

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

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

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

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

Убедить его. Объясните ему несколько небольших примеров подобных технических улучшений, которые вы сделали, и их преимущества для проектов.

Вы должны продать эти изменения только так, как руководство хочет купить:

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

Задача вашего босса - убедиться, что компания ориентирует разработку на предоставление того, что клиенты воспринимают как добавленную стоимость. Есть два фактора, которые могут изменить это восприятие:

1. Сколько времени занимает доставка запроса клиента?
2. Вы доставляете, когда говорите?

Большинство предпочло бы, чтобы вы сказали, что это займет 6 недель и доставит за 5, чем сказать, что вы доставите за 3, но возьмите 4.

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

Позвольте мне рассказать вам о возможности в 2 миллиарда долларов, которая едва не попала в наши руки из-за инерции руководства.

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

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

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

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

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

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

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

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

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

Вам нужно узнать о таких вещах, как альтернативные издержки, ROI (возврат инвестиций) и NPV (чистая приведенная стоимость). Для этого вам не требуется MBA, но вам нужен доступ к данным, которые могут быть вам недоступны, например, затраты на рабочую силу, накладные расходы и потенциальные доходы. Если вы можете дать четкий аргумент, что один путь обеспечит большую ценность, чем другой, используя жесткие числа, вы получите полное внимание от руководства.

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

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

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

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

Удачи!

Вот почему ваш запрос на автоматический подсчет ссылок отклоняется:

1. Это не улучшение . Если у вас есть что-то большее, чем привет, любое изменение идет в неверном направлении. Никакой рефакторинг не изменит того факта, что если вам нужно внести изменения, он всегда идет в неправильном направлении. Хитрость заключается в том, чтобы знать, когда ваши изменения настолько значительны, что все еще стоит риск возникновения новых проблем. Ваше руководство четко заявило, что если конечные пользователи не видят его, риск не стоит.
2. Подсчет ссылок - совершенно безумная особенность. Вы видели, как какая-то существующая крупная известная компания внедрила какую-то функцию, и сразу же подумали, что вам нужна такая же функция. Ну, вполне вероятно, что ваша кодовая база полностью отличается от того, что использует Apple. Вероятно, подсчет ссылок не сработает, или это просто трата времени. Вы должны найти другой способ, который не требует распространения примитивов подсчета ссылок повсюду в вашем коде. Вероятно, ваш план пересчета требует тысячи изменений в кодовой базе, большинство этих изменений не являются необходимыми. Просто трата времени и денег.
3. Вы решаете не ту проблему. Руководство обычно знает, какие проблемы существуют в системе. Некоторая не относящаяся к делу проблема утечки памяти, которую решает решение по пересчету, не является одной из них. Сосредоточьтесь на реальных проблемах, а не на воображаемых проблемах с тем, как компьютеры управляют памятью.
4. На его реализацию уходит слишком много времени. Apple - немного большая компания, чем ваша незначительная команда, в которой мало программистов и менеджеров. Они могут сделать большие изменения, просто заплатив цену. Если для реализации чего-либо требуется несколько миллионов, это арахис. Если небольшие компании попытаются сделать то же самое, у них быстро кончатся деньги. Разработка программного обеспечения уже очень дорогая; добавление ненужных затрат не поможет ни на минуту. Одна нерелевантная функция, такая как управление памятью, откроет шлюзы: после того, как они одобрят это, половина ваших программистов захочет реализовать свое «улучшение». Это бесконечная история, и компания может сделать что-то полезное вместо этого.

Вот несколько шагов, которые вы можете использовать для решения проблемы:

1. Удалите функцию
2. Узнайте, в чем реальная проблема
3. Начните делать что-то полезное
4. Тщательно планируйте, как вы используете свое время
5. Узнайте, как ваши улучшения приносят деньги
6. Выберите только те функции, которые приносят большую часть денег
7. Поймите, что программный аспект разработки программного обеспечения - это лишь малая часть всей системы - его усовершенствования никогда не будут стоить времени