Я могу понять график давления. Вы хотите порадовать своих пользователей, ведь они являются источником жизненной силы компании. Однако верно и то, что определенные изменения облегчат все в будущем. К сожалению, менеджмент в моей организации инстинктивно сопротивляется таким изменениям, и это сопротивление настолько сильно, что мешает долгосрочным улучшениям.
Например, 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, и назначьте ее менеджеру.
Убедить его. Объясните ему несколько небольших примеров подобных технических улучшений, которые вы сделали, и их преимущества для проектов.
источник
Вы должны продать эти изменения только так, как руководство хочет купить:
Найдите функцию, ориентированную на пользователя, настолько привлекательную, что менеджмент просто должен ее иметь, но без некоторых низкоуровневых улучшений в коде это сделать невозможно.
источник
Задача вашего босса - убедиться, что компания ориентирует разработку на предоставление того, что клиенты воспринимают как добавленную стоимость. Есть два фактора, которые могут изменить это восприятие:
Большинство предпочло бы, чтобы вы сказали, что это займет 6 недель и доставит за 5, чем сказать, что вы доставите за 3, но возьмите 4.
Наличие современной кодовой базы, которой проще управлять и улучшать, позволяет быстрее доставлять и повышать предсказуемость. Если вы тратите слишком много времени на исправление ошибок, у вас будет меньше ресурсов для добавления новых функций. Оцените количество ресурсов, потраченных на исправление кода, и насколько вы точны в обещаниях функций. Это один из способов определить, стоит ли ваш текущий код (в соответствии с философией вашего босса) слишком дорого.
источник
Позвольте мне рассказать вам о возможности в 2 миллиарда долларов, которая едва не попала в наши руки из-за инерции руководства.
У некоторых из нас есть смысл прислушиваться к голосу клиента, то есть понимать, чего он хочет. Это не всегда то, что он просит, но если у вас есть возможность поговорить с вашим клиентом, вы в конечном итоге придете к взаимопониманию о том, что он хочет. (Тогда он может явно начать просить об этом.)
При этом важно понимать, кто должен вести этот разговор с клиентом. Обычно у вас есть люди, занимающиеся развитием бизнеса, и некоторые ведущие дизайнеры. Если у вас есть какое-либо соревнование, вы можете ожидать, что клиент также ведет с ним эту беседу.
В то же время, важно, чтобы разработчики были в курсе событий в своих областях, потому что будет конкуренция, которая победит вас, если вы этого не сделаете.
В нашей ситуации у нас был существующий клиент и довольно эффективный продукт, основанный на старых технологиях, и клиент нуждался в быстром обновлении. Что им действительно нужно, так это полноценный продукт для замены, но мышление нашей компании заключалось в том, что это немедленно вынудит нас занять конкурентную позицию, в то время как изменение существующего продукта позволило нашему клиенту продолжать работу с нами без юридической необходимости делать его конкурентоспособным. Наш менеджмент думал, что они владеют этим рынком. Проблема заключалась в том, что они не могли идти в ногу с запросами на обновление, потому что существующая структура продукта не была достаточно гибкой для обновления.
Клиент стал нетерпеливым и начал беседовать с конкурирующими источниками. Мы потеряли нашу «собственность» на этот рынок и пару миллиардов долларов дохода. Однако, как только рынок вынудил нас занять конкурентную позицию, у руководства не было иного выбора, кроме как уйти из бизнеса или конкурировать. (Большинство из тех, кто был контрольно-пропускными пунктами, в конечном счете были уволены.) Мы конкурировали и смогли вернуть бизнес с помощью тончайшей нитки.
В начале я сказал, что эта возможность едва не упала нам в руки. Мы вернули бизнес, о доходе, который я упомянул. Если бы мы были более готовы адаптироваться к потребностям клиента в начале, то не было бы реальной конкуренции.
Вот что я предлагаю на вынос: всегда старайтесь оставаться на переднем крае своих личных возможностей. Всегда разрабатывайте продукт, который является гибким и может быть быстро адаптирован к потребностям вашего клиента. Если вы слишком долго работаете в компании, которая так не думает, вы увядете, и ваша личная мотивация уменьшится. Я видел, как это произошло.
Если у вас есть идея улучшить продукт по какой-либо причине, задайте себе следующие вопросы: - Это то, что, по моему мнению, хочет клиент? Могу ли я проверить свои мысли о разработке продукта против голоса клиента? Может ли моя компания удовлетворить потребности клиентов? Если да, то как? - Вы должны быть в состоянии убедительно обосновать ваши предложения по разработке продукта.
источник
Общим языком бизнеса во всех областях и отраслях являются деньги. Проблема, которую вы описываете, не является проблемой программирования: это проблема бизнеса. Если вы хотите получить соответствующий ответ на деловое предложение, вам нужно сформулировать его на языке бизнеса. Это означает, что вы должны иметь возможность представить альтернативный план проекта, включая все затраты и выгоды.
Вам нужно узнать о таких вещах, как альтернативные издержки, ROI (возврат инвестиций) и NPV (чистая приведенная стоимость). Для этого вам не требуется MBA, но вам нужен доступ к данным, которые могут быть вам недоступны, например, затраты на рабочую силу, накладные расходы и потенциальные доходы. Если вы можете дать четкий аргумент, что один путь обеспечит большую ценность, чем другой, используя жесткие числа, вы получите полное внимание от руководства.
источник
Когда я был новым разработчиком в очень маленькой команде, я делал много подобных улучшений в свободное время. Мне это понравилось; Я мог войти в систему и попробовать новые интересные техники, сидя ночью в гостиной с моей женой. Поскольку я стал более старшим разработчиком, а затем менеджером более крупной команды, мое свободное время исчезло. Мы работали дополнительные часы только для того, чтобы сделать функции и критические исправления. Стало действительно трудно оправдать, что кто-то тратит время на эту обычную работу по дому, хотя мы все знали, насколько это важно.
Ваши начальники не нуждаются в объяснении того, насколько это важно, чтобы снизить затраты на обслуживание, снизить затраты на будущий рост, привлечь талантливую команду разработчиков и т. Д. Если они это сделают, у вас большие проблемы. Однако им может понадобиться план. Потому что сейчас я предполагаю, что у них есть все виды планов, расписаний, дорожных карт, обещаний и давления со стороны «добавления функциональности», которые конкурируют с простыми желаниями и открытыми запросами от команды разработчиков.
Одна вещь, которую вы можете попробовать, это составить документированный план. Посмотрите, можете ли вы связать его с выпусками или выйти из критериев для новой функциональности. Для вашего босса может быть сложно одобрить запрос «потратить некоторое время на восстановление подсчета ссылок», но планирование 5-дневного блока времени через 4 недели может быть проще. В основном, однако, вы видите, что новые функции запланированы и запланированы, попробуйте имитировать это или внедрить в него часть «под капотом».
Начните с малого, попросив выделить 5% времени для этого типа материала, а затем постепенно выстраивайте свои собственные приоритеты технологической дорожной карты и продолжайте прилагать усилия для обоснования экономического обоснования, рентабельности инвестиций, уровней риска и т. Д. Для каждого из них. Довольно скоро вы даже почувствуете проблемы своих боссов, поскольку вы быстро найдете гораздо больше отличных идей, чем у вас есть время.
Удачи!
источник
Вот почему ваш запрос на автоматический подсчет ссылок отклоняется:
Вот несколько шагов, которые вы можете использовать для решения проблемы:
источник