Технический долг в разработке ПО

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

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

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

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

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

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

Выводы очевидны

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

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

месяц рядом с другими важными задачами.

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