Как уменьшить [закрытые] затраты на обслуживание
Попробуйте это:
if (EqualityComparer<T>.Default.Equals(myArgument, default(T)))
, который должен скомпилировать и сделать то, что Вы хотите.
8 ответов
Вы только что описали ситуацию, типичную для большинства ИТ-магазинов!
Is есть ли в доме управляющий?
Здесь уже было несколько хороших предложений. Я согласен с теми, кто сказал, что это проблема менеджмента. Вы можете пробовать все, что хотите, но это руководство, которое должно понимать ситуацию, и руководство, которое имеет право определять направление развития компании. Руководство должно решить, что разработка будет приостановлена, или что устранение грехов прошлого является более высоким приоритетом, чем текущий проект, или что необходимо переписать, или что лучший подход оправдан, или что, возможно, что-то людям нужно забрать клавиатуру.
Сейчас, конечно, необходимо лучшее кодирование, но общение - это навык, который нужен больше всего. Если руководство начинает чувствовать боль прошлых ошибок, возможно, оно готово выслушать, но, опять же, менеджеры могут оказаться теми же самыми людьми, которые втянули вас в эту неразбериху, совершив распространенную ошибку , полагая, что разработка программного обеспечения проста . Итак, ваша работа вырезана за вас.
Мы Самостоятельно
Если менеджмент не изменится, то попробуйте кое-что из того, что многие из нас в сфере ИТ должны сделать:
- Делайте постепенные шаги и постепенно внедряйте рефакторинг, когда проект по переработке кода не работает. t разрешен.
- Воспользуйтесь преимуществами некоторой специализации. Кажется, в вашем распоряжении несколько разработчиков? Им это не понравится, но для повышения эффективности некоторые из них должны быть назначены в качестве основных ресурсов на стороне поддержки, особенно если вы находитесь в положении, когда руководство не изменится и ожидает вас. делать поддержку и проекты одновременно. Работа по поддержке будет мешать проектам, а проекты будут мешать поддержке; разница в том, что проектом можно управлять, а поддержка непредсказуема. Вы должны изолировать их, чтобы снизить потери производительности, вызванные частыми переключениями контекста. Если вы действительно хотите быть максимально справедливыми по отношению к своим разработчикам, позвольте людям по очереди переключаться между поддержкой и проектами, когда это необходимо. Внимательно посмотрите на навыки своей команды; все скажут, что им нужны новые проекты, но, безусловно, одни лучше справляются с этим, а другие могут лучше работать с существующим кодом.
- Учитесь на своих ошибках. Похоже, ваш магазин авторизовал множество пользовательских приложений, но не справился с бизнес-анализом и тестированием, что привело к нагрузке на поддержку, которую вы имеете сейчас. Если вы не можете полностью исправить существующую базу кода, по крайней мере, вы можете попытаться лучше выполнить требования и тестирование (и разработку), чтобы ограничить увеличение поддержки, которую принесет новый материал.
- Вовлекайте пользователей. Пользователи будут ценны, если у вашего магазина нет доступа к официальным ресурсам для бизнес-анализа и тестирования. Они также могут помочь сообщить руководству о желании улучшить ситуацию.
- Неоплачиваемые сверхурочные. Я знаю, просто читать эту фразу - отстой. Основываясь на вашем описании, я должен предположить, что вы уже хорошо знакомы с этой концепцией. Но если вы счастливы там, где работаете, и хотите остаться, возможно, вам придется пойти на временные жертвы. Пример: в моем магазине мы делали сборки вручную через нашу IDE. Но я потратил время на исследование языка сценариев сборки, который поставляется с нашим инструментом разработки, и хотя у нас все еще нет непрерывной интеграции с автоматическим тестированием, процесс создания и миграции сборок требует значительно меньше усилий; обезьяна могла это сделать. Это экономит время и позволяет легко передать задачу любому члену команды независимо от уровня его навыков (как сказал Тотофил: автоматизировать). Это то, что вы можете сделать, чтобы помочь команде сэкономить время. Создание командной вики или более качественной пользовательской документации - это еще один пример того, что снижает поддержку или затрудняет ее выполнение (хотя руководство не ценит эти вещи и может не одобрять использование для этого обычных рабочих часов). Спросите себя: в какой компании вы хотите работать? Вам нравится ваша команда и ваши пользователи? В таком случае некоторые жертвы могут стоить того. Если нет, то начните искать.
Несколько других предложений прекрасны, и сообщение Totophil великолепно, но похоже, что вы уже в глубокой яме и работаете на сомнительное руководство; Было бы сложно выполнить все рекомендации передовой практики.
Если руководство не понимает, что такое «петля обратной связи» (например, обзоры, тестирование), то, возможно, сменить работу?
Исходя из опыта, культуру компании сложно изменение / требует времени: если вы попадаете в ситуацию, подобную той, которую вы описываете, спасите себя.
Обычно помогает поговорить с руководством и объяснить им, в чем проблема. В основном то же самое, что вы упоминаете в своем вопросе. Сообщите им, что у вас нет прогресса, потому что команда тратит много времени на поддержку приложений. Также сообщите им, что приложения имеют серьезную гниль и требуют исправления. Объясните им, что решение этих проблем требует времени и инвестиций.
Как только руководство поймет, почему что-то не работает должным образом, вы можете вместе разработать план, чтобы взять ситуацию под контроль. Вы можете поручиться за технические потребности, а также быть уверенным и чутким к потребностям бизнеса. Попробуйте придумать план, в котором, скажем, 50% времени тратится на исправление приложения, а остальные 50% - на решение бизнес-задач. Эти проценты являются предметом переговоров, так что посмотрите, что вы можете получить!
Не пытайтесь съесть всего слона сразу!
Определите конкретные приложения или их части, которые, как правило, вызывают большую часть накладных расходов на обслуживание и которые, кажется, относительно легко улучшить ... Да, я знаю, что найти такие цели непросто, но, временно сосредоточив больше усилий на этих "легких победах", вы добьетесь двух вещей:
- повысите доверие со стороны руководства, а другие заинтересованные стороны
- уменьшите, если только постепенно, количество времени, затрачиваемого на обслуживание.
и, следовательно, у вас будет больше времени для очистки других частей кода, а также больше времени для правильной работы (например, с обзорами и модульными тестами), поскольку время идет.
Возможные варианты:
- Автоматизировать
- Делегировать
- Устранить основную причину
- Привлечь больше людей
- Организовать
- Пропустить и рискнуть
- Или комбинация вышеперечисленного.
Но первый шаг - собрать некоторые данные, а затем провести быстрый анализ:
Классифицировать существующие и исторические проблемы по основной причине , источнику, частоте и требуемым усилиям.
При использовании диаграмм Парето для визуализации областей, требующих наибольших усилий или взятых из единого источника. Обращение внимания на эти области принесет наибольшую пользу и освободит людей для решения других проблем с обслуживанием.
Устранение основной причины
Всегда стремитесь устранить основную причину проблемы. Решение не должно быть дорогостоящим: «инженерное искусство состоит в том, чтобы иметь дело с одним долларом, который любой дурак может сделать с двумя». Используйте аналитические методы, такие как Five Whys , чтобы разобраться в проблеме.
При чтении вопроса одна из основных причин, похоже, связана с текущим процессом разработки программного обеспечения и давлением, которое оказывается на быстро добавить функциональность к существующей системе, что приведет к низкому качеству кода, поставляемому через поток проектов, увеличивая бремя обслуживания. Обычно это происходит из-за неправильного планирования и составления бюджета проекта, когда бюджет проекта не включает какие-либо затраты на обслуживание и план внезапно завершается после того, как изменение доставлено пользователям. Правильный способ - включить и отслеживать затраты на обслуживание в течение срока действия результатов, которые затем будут добавлены в бюджет организации. Цифра даст больше стимулов для создания надежного кода в первую очередь и поможет сделать лучший выбор между различными вариантами проекта.
Попытайтесь увидеть, есть ли какие-либо другие «скрытые стимулы» для роста поддержки.
Делегат
] ИТ-отдел или проектную группу часто можно рассматривать как бесплатный ресурс внутри организации для обучения пользователей, выполнения преобразования данных, составления отчетов, выполнения рутинной настройки системы, корректировки данных и других задач, которые действительно могут быть выполнены другими отделами.
Эти задачи могут быть либо делегированы обратно другим бизнес-единицам (путем предоставления им инструментов для выполнения работы), либо переданы сторонним поставщикам (в случае некритичной для бизнеса или конкретной системы вы можете найти лучшую качественный сервис или размещенное приложение вне компании).
Либо упростите задачи, чтобы научить пользователей выполнять более сложные задачи. Организуйте и поддержите сообщество пользователей, чтобы они могли решать наиболее распространенные проблемы, не полагаясь на ваше время.
Автоматизация
Автоматизируйте вещи, которые можно автоматизировать, включая ежедневный мониторинг. Там вещи не могут быть полностью автоматизированы, по крайней мере, частично автоматизировать их, предоставить способ поддержки библиотеки скриптов для выполнения частей процесса. Помогите членам команды изучить инструменты написания сценариев и языки.
Организуйте
Сгруппируйте похожие проблемы вместе и решите их сразу. Время разрешения может увеличиться, но для сброса 5 паролей одновременно в одной системе, которая делает каждый из них индивидуально, потребуется меньше работы.
Предоставьте пользователям возможность сообщать и отслеживать проблемы, которые дадут вам возможность решать с более организованным обслуживанием, то есть вместо того, чтобы кто-то разговаривал по телефону, ожидая немедленного решения проблемы, используйте систему отслеживания проблем с приоритетами, чтобы все можно было решать более упорядоченным образом и дать вам больше возможностей для маневра в отношении того, как и когда вы имеете дело с конкретной категорией вопросов.
Пропустить обслуживание и рискнуть
Оценить риск и последствия невыполнения части обслуживания. Если достаточно низко, сообщите всем, что работа не будет выполнена, и продолжайте работу.
Пропустить обслуживание и рискнуть
Оценить риск и последствия невыполнения части обслуживания. Если достаточно низко, сообщите всем, что работа не будет выполнена, и продолжайте работу.
Пропустить обслуживание и рискнуть
Оценить риск и последствия невыполнения части обслуживания. Если достаточно низко, сообщите всем, что работа не будет выполнена, и продолжайте работу.
Тогда этот проект, скорее всего, обречен. Если руководство не поддерживает передовые методы, такие как обзоры и тестирование кода, мало что можно сделать, чтобы помочь.
Я бы попытался убедить руководство, что внедрение наборов тестов и выполнение обзоров кода сэкономят время в долгосрочной перспективе.
] Без надлежащего процесса исправления ошибок будут просто наполовину обдуманными патчами, которые с большой вероятностью внесут новые ошибки, на исправление которых потребуется больше времени, что вызовет больше ошибок, что потребует чрезмерных затрат времени и денег.
Если сейчас потратить месяц или два на то, чтобы все исправить и начать надлежащий процесс, на самом деле будет стоить меньше времени и денег, чем продолжение текущего процесса.
Если нужно что-то только для начала. Накладные расходы можно преодолеть с помощью подхода « замораживание ». Это хороший управленческий термин, который хорошо понимается в подобных ситуациях.
Я работал над проектами как эти, это марш смерти. Мы обнаружили, что решение - «выплатить ипотеку». Найдите то, на что у вас больше всего времени, и постарайтесь исправить это. Как только они будут готовы, у вас будет время для работы над другими, более мелкими проблемами. Хорошая идея - включить TDD в свой процесс, если вы можете установить достаточное количество тестов, тогда вы можете начать вносить изменения, не беспокоясь о том, чтобы сломать больше вещей.