Как уменьшить расходы на техническое обслуживание

Question

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

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

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

Как бы вы начали сокращать эти огромные накладные расходы?

Answer 1

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

Есть ли в доме менеджер?

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

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

Мы сами по себе

Если управление не изменится, попробуйте кое-что из того, что многие из нас в области ИТ должны сделать:

• Принимайте пошаговые меры и постепенно вводите рефакторинги, когда проект по переработке кода не авторизован.
• Воспользуйтесь преимуществами некоторой специализации. У вас есть несколько разработчиков? Им это не понравится, но для повышения эффективности некоторые из них должны быть назначены в качестве основных ресурсов на стороне поддержки, особенно если вы находитесь в положении, когда руководство не изменится и ожидает вас делать поддержку и проекты одновременно. Работа поддержки будет мешать проектам и проектам будет мешать поддержке; Разница в том, что проектом можно управлять, а поддержка непредсказуема. Вы должны изолировать их, чтобы уменьшить снижение производительности, вызванное частыми переключениями контекста. Если вы действительно хотите быть настолько честным по отношению к своим разработчикам, то пусть люди переключаются между поддержкой и проектами, когда это уместно. Внимательно посмотрите на навыки вашей команды; все скажут, что хотят проекты с нуля, но, безусловно, некоторые из них лучше, а другие могут лучше работать с существующим кодом.
• Учитесь на своих ошибках. Похоже, ваш магазин авторизовал множество пользовательских приложений, но не проделал большую работу с бизнес-анализом и тестированием, что привело к загрузке поддержки, которую вы сейчас имеете. Если вы не можете полностью исправить существующую кодовую базу, по крайней мере, вы можете попытаться лучше выполнить требования и тестирование (и разработку), чтобы ограничить увеличение поддержки, которую принесут новые вещи.
• Привлекайте пользователей. Пользователи будут полезны, если у вашего магазина нет доступа к формальным ресурсам для бизнес-анализа и тестирования. Они также могут помочь в общении с руководством о желании, чтобы все было лучше.
• Неоплачиваемая сверхурочная работа. Я знаю, просто чтение этой фразы отстой. Исходя из вашего описания, я должен предположить, что вы уже достаточно хорошо знакомы с этой концепцией. Но если вы счастливы там, где работаете и хотите остаться, вам, возможно, придется пойти на то, что, как надеются, будут временными жертвами. Пример: в моем магазине мы делали сборки вручную через нашу IDE. Но я потратил время на изучение языка сценариев сборки, который поставляется вместе с нашим инструментом разработки, и, хотя у нас все еще нет постоянной интеграции с автоматизированным тестированием, процесс создания и переноса сборок значительно меньше; обезьяна может это сделать. Это экономит время и делает задачу легко переносимой на любого члена команды независимо от уровня его квалификации (как сказал Тотофил: автоматизировать). Это то, что вы можете сделать, чтобы помочь команде сэкономить время. Создание вики для команды или лучшая пользовательская документация - другие примеры вещей, которые уменьшают поддержку или трудности, связанные с этим (хотя руководство не ценит эти вещи и может не захотеть использовать для этого обычное рабочее время). Спросите себя: является ли компания, которую вы хотите придерживаться? Вам нравится ваша команда и ваши пользователи? Если так, то некоторые жертвы могут стоить. Если нет, то начинай искать.

Некоторые другие предложения великолепны, и пост Totophil потрясающий, но похоже, что вы уже в глубокой яме и работаете на сомнительное управление; было бы трудно сделать все рекомендации передовой практики.

Answer 2

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

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

Удачи ...

Answer 3

Варианты:

• Автоматизировать
• Делегат
• Устранить основную причину
• Получите больше людей
• Организация
• Пропустить и рискнуть
• Или комбинация вышеперечисленного.

Но сначала нужно собрать некоторые данные, а затем провести быстрый анализ:

1. Классифицируйте текущие и исторические проблемы по Основная причина , источник, частота и необходимые усилия.

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

Устранить первопричину

Всегда стремитесь устранить причину проблемы. Решение не должно быть дорогим, «искусство инжиниринга заключается в том, чтобы делать с одним долларом, что любой чертов дурак может делать с двумя». Используйте аналитические методы, такие как Five Whys , чтобы решить проблему.

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

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

Делегирование

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

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

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

Автоматизировать

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

Организация

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

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

Пропустить техобслуживание и рискнуть

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

Answer 4

Не пытайтесь съесть всего слона сразу!

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

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

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

Answer 5

Если руководство не понимает, что такое «петля обратной связи» (т. Е. Обзоры, тестирование), то может быть сменить работу?

Исходя из опыта, культуру компании трудно изменить / она требует времени: если вы окажетесь в ситуации, подобной той, которую вы описываете, то спасите себя.

Answer 6

Я работал над такими проектами, это марш смерти. Мы обнаружили, что решение состоит в том, чтобы «заплатить ипотеку». Найдите вещи, которые стоят вам больше всего времени, и постарайтесь их исправить. Как только они будут сделаны, у вас будет время для работы над другими, более мелкими проблемами. Хорошей идеей является включение TDD в ваш процесс. Если вы сможете выполнить достаточно тестов, вы сможете начать вносить изменения, не беспокоясь о том, чтобы сломать больше вещей.

Answer 7

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

Answer 8

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

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

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

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

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