Как продать преимущества "хорошего кода" руководству?

Ответ 1

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

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

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

Ответ 2

Я нашел, что есть всего три способа продать обслуживание для управления:

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

Вкратце: переговоры по управлению в функциях, а не в коде.

Ответ 3

Используйте одну из своих любимых "Парадигм": Большая картинка

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

Ответ 4

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

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

Ответ 5

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

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

Это долгий путь к мотыге.: -)

Ответ 6

Можете ли вы показать, что расходы на поддержку растут? Либо с точки зрения количества инцидентов поддержки, либо% разработчиков времени тратят на поддержку.

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

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

Ответ 7

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

Также: лучший код = более низкая кривая обучения для новых разработчиков.

Ответ 8

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

Ответ 9

Иногда использование аналогии может помочь нетехникам понять.

Самая лучшая аналогия для того, почему рефакторинг кода, обслуживание и т.д. важны, я нашел именно этот. Это взято из сообщение на Slashdot:

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

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

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

Ответ 10

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

Стоимость денег может быть несколькими способами:

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

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

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

Ответ 11

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

Ответ 12

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

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

Ответ 13

Продавайте его с точки зрения того, как он помогает достигать бизнес-целей.

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

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

Ответ 14

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

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

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

Ответ 15

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

Я только занимался разработкой службы, поэтому я не могу говорить о том, чтобы оправдать очистку кода в любой другой бизнес-модели, но вот мои $0.02 на это для развития сервиса:

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

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

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

Ответ 16

Скорее всего, они понимают компромиссы и принимают риски. Я думаю, что предложение повторного факторинга, как вы идете, вероятно, ваша единственная надежда.

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

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

Ответ 17

Другая мысль...

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

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

Ответ 18

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

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

Как только они видят преимущества решений, они будут уделять больше внимания проблемам.

Ответ 19

Улучшенный код легче поддерживать, но, что более важно, его также легче поддерживать кем-то, кроме оригинального автора.

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

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

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

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

Хочет ли менеджер любого бизнеса сделать ставку на одного разработчика или небольшую команду, оставаясь надолго? Если да (они сумасшедшие?), То утверждают, что разработчики перемещают компанию каждые 2-5 лет, а их набор навыков на 100% переносится.

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

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

Ответ 20

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

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

Десять лет "опыта" - это много для борьбы. С точки зрения точки зрения, у них есть продукт, он работает, конечно, есть проблемы, постоянное обслуживание и проблемы с клиентами, но никто не может спорить с результатами? Они могут? Плюс, у всех есть проблемы?

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