Основной вопрос статьи: Что такое «Технический долг» при разработке и внедрении программных продуктов, и как он может лишить компании возможностей развития?
С автором можно связаться в телеграмм @Yuriy_EB (efficient business)
Кому будет полезна статья? Статья будет полезной тем, кто занят разработкой и внедрением программных продуктов, или внедряет программные продукты у себя в компаниях собственными силами. В статье перечисляются примеры, как «быстрые» и «экономные» решения могут «убить» проект.
Что такое технический долг в контексте бизнес-приложений
Технический долг — это накопленные проблемы в программно-аппаратной архитектуре, или конкретно - в программном коде. Возникает «технический долг» из-за принятия быстрых в реализации, но неоптимальных решений при разработке систем учета и управления, а также при их внедрении. Особенно актуален этот вопрос при создании корпоративных информационных систем.
Почему важно и актуально правильно управлять «техническим долгом»? Ответ простой, и в то же время – ведет к насыщенной работе. По аналогии с финансовым долгом, бесконтрольный рост «технического долга» может привести компанию к ситуации, когда систему невозможно обслуживать, поддерживать в рабочем состоянии, модернизировать и улучшать. В случае с финансовым долгом – это банкротство. В случае с «техническим долгом», это наступление ситуации, когда поддерживать учетную систему в рабочем состоянии дороже, чем взять и внедрить новую систему.
Типичные ситуации накопления технического долга
Действия инициаторов проекта:
· Давление сроков внедрения: требование запустить систему к определенной дате, несмотря на неготовность;
· Экономия на тестировании: пропуск этапов проверки ради ускорения запуска;
· Игнорирование масштабируемости: выбор решений без учета будущего роста компании.
Если в вашей компании создается или внедряется IT-продукт, и вам нужно управлять процессами его создания и внедрения, реализации, управлять проектной командой, то можете обратиться ко мне в телеграмм и предложить сотрудничество.
Приведу примеры, чтобы было легче воспринять концепцию технического долга.
Пример 1. Давление сроков внедрения. Любой проект выполняется в трех рамках: сроки, деньги, ценность результата. Моя практика не исключение – я участвовал в проектах разработки и внедрения, в проектах сопровождения и развития программных продуктов. Раз были проекты, значит были и заказчики, которые очень хотели внедрить программный продукт побыстрей.
Само по себе, ничего удивительного в этом желании нет. Все заказчики хотят этого. Мотив простой: меньше сроки разработки или внедрения – меньше расход денег, внимания, и т.д. Но, все же встречались «выдающиеся» заказчики, которые, не являясь техническими специалистами, не понимая объемов работ и трудозатрат, просто на основании того, что они платят за этот проект (или готовы платить за него), считают себя в праве диктовать временные рамки проекта. «Диктовать» они могут, но любые сроки ведут к стоимости проекта. А «ускорение» проекта требует привлечения дополнительных специалистов, и требуют планирования их работы и управления ею, т.е. возникают потребности в руководящих сотрудниках тоже. Все это, часто приводит к росту стоимости всего проекта. Иногда и сроки сдвигаются.
В итоге, ускорение проекта, без адекватной проработки и последовательного выполнения работ, ведет к упрощению и потере смысла всего проекта.
Например, однажды, для тестирования гипотезы – «организация пунктов выдачи товара может дать рост продаж торговой сети», руководством компании было принято решение отказаться от внедрения 1С:Комплексной автоматизации в пользу 1С:Управление торговлей. При этом, отсутствие возможностей ведения регламентированного бухгалтерского учета в 1С:УТ было просто «вынесено за скобки» (проигнорировано). Сам по себе, выбор 1С:УТ для постановки учета в будущей сети пунктов выдачи товаров в моменте может дать сокращение сроков внедрения, т.к. сам продукт содержит меньше разделов учета. Однако, для сдачи бухгалтерской отчетности потребуется настройка обмена с 1С:Бухгалтерией для перегрузки данных и формирования бухгалтерской финансовой отчетности. Сам обмен данными выполняется не мгновенно, а занимает определенное время и выполняется периодически. В итоге, самое главное требование – оперативное получение информации об остатках на торговых точках (пунктах выдачи товаров) было проигнорировано, и «принесено в жертву» сиюминутной прихоти заказчика.
Пример 2. Экономия на тестировании. Тестирование при разработке программного продукта (а при его внедрении – моделирование отражения данных в программе) – это важный этап всего процесса разработки (внедрения). Если его проигнорировать, то «тестировать» продукт будут пользователи продукта. При этом, у них могут отсутствовать специальные знания и компетенции (и чаще всего отсутствуют), а главное – у них есть их прямые обязанности. В итоге, пользователи пробуют отражать данные в программе, получают непонятный им или ошибочный результат. Возникает раздражение и неприятие к программному продукту, и к компании, которая «заставляет» этих людей выполнять работу тестировщика (потому что компания решила экономить на тестировании). В итоге, весь проект внедрения и сам продут ставится в ситуацию полнейшей дискредитации. Иногда возникает жесточайшее сопротивление внедрению чего-либо нового в компании.
В моей практике, бывали примеры, когда сам собственник высказывал такое отношение к проекту внедрения. По смыслу, говорилось примерно следующее «Мне все равно, что там работники в программе делают. Мне главное итоговый результат – цифры доходов, которые мне должны понравиться». С одной стороны – можно понять. Собственник платит деньги за работу. Это хорошо. Но с другой стороны, выполнить качественно работы и в полном объеме невозможно, если недостаточно людей на выполнение этой работы, а собственник (руководитель) сам провоцирует внутренний конфликт и противостояние между специалистами по внедрению, и пользователями программного продукта. И да, я не всегда мог донести эту мысль до лиц принимающих решение. Иногда люди просто отказывались слушать что-либо.
Пример 3. Игнорирование масштабируемости. Был в моей практике пример. Нужно было автоматизировать работу торговых точек. В целом, все стандартно было на торговых точках. Продавец-кассир утром принимает товар, раскладывает его на прилавке. Днем продает за наличные и безналичные, пробивает чеки. Вечером заказывает продукцию, которую привезут завтра или послезавтра. После заказов на завтра и послезавтра, убирает товар, выполняет уборку рабочего места, закрывает кассовую смену и готовит инкассацию. Все вроде бы просто. НО…нет. Продавцу-кассиру нужно принять заказы на завтра и послезавтра от клиентов, которые позвонили, специально зашли заказать, или заходили купить, купили что-то и попросили заказ на завтра.
Кроме этого, нужно еще проводить пересчет товаров в торговой точке. А значит хорошо бы, если программа дает остатки товаров по торговой точке. Все это стандартная функциональность в 1С:Рознице. Казалось бы – нужно использовать 1С:Розницу. Но нет, в компании «легким путем» не пошли. В описываемом примере, в компании «зацепились» за продукт, который тоже на платформе 1С:Предприятие 8.3, но разрабатывался под влиянием и по требованиям владельцев малых торговых предприятий. В итоге, проект внедрения выполнялся более 2 лет, и в лучшем случае, был выполнен только на половину (около 100 торговых точек по городу).
При этом, процесс очень затянулся, а пользователи такое сопротивление продукту оказывали, что было принято решение переходить на связку новых продуктов (не буду тут называть какие, суть не в этом). В итоге, вместо помощи продавцам-кассирам, они получили учетную программно-аппаратную систему, которая не помогает им в работе, а «чертовски» мешает. При этом, со службой поддержки программного продукта постоянные «терки», кто главней, кто должен ошибки исправлять, кто должен не допускать ошибки учета и так далее.
Дошло даже до того, что в программе выключили контроль остатков по позициям на торговых точках («кошмар бухгалтера», невозможность контролировать остатки в программе, невозможность сверять остатки запасов с учетом и по факту, невозможность оперативно сопоставить выручку по проданным товарами). Продавцы-кассиры пишут в чат поддержки длинные письма, и многократно дублируют заявки в поддержку (чтобы ошибки исправили скорей). А бухгалтера бастуют, так как сами ошибки не могут править в программе, может только 1С администратор. Полнейший саботаж ото всех. Собственник в ужасе и очень зол, готов просто всех на месте «прибить».
И какое было тут решение? Давайте внедрять 1С:Комплексную автоматизацию. В ней есть все нужные механизмы и отчеты, ну так в рекламе говорилось. Начал я проект со сбора требований к продукту. Вроде даже несколько требований собственник и управляющие озвучили, финансовый директор тоже свое озвучил. До конечных пользователей даже не допустили. Основной посыл был: «А в друг они скажут что-то не то, что нам не нужно?» Это ошибка, я говорил, что нужно всех опросить. Но начали внедрять. Заказчик же заказывает и, обещал платить. Но хочет, чтобы было все так, как ему нужно. Нужно было реализовать механизм переноса данных из старой учетной системы в новую. Хорошо. Механизм реализовали, периодически ошибки возникали при переносе данных, но не значительные. Около 80% ошибок я «отловил» и подрядчики исправили.
Начали данные переносить. Выяснилось – в исходной учетной системе продажи осуществляются не от тех юридических лиц, от которых по факту продается товар. Чек правильно пробивается, и в личный кабинет в ФНС правильные данные отправляются, но в учете – бардак и хаос. Опять – кошмар бухгалтера. Я это знаю, т.к. как и сам бухгалтер тоже. Для меня такое положение дел было бы неприемлемым в принципе. Вести бухгалтерский учет в такой компании я бы не стал, пока ошибки не исправили и не восстановили учет. При этом – исправить этот хаос желающих не было, а новых людей тоже собственник не намерен был на работу приглашать. И очень впечатляет позиция собственника – я найду такого бухгалтера, который согласится вести учет. Адекватной эту позицию назвать я тогда не мог, но и говорить очевидную вещь собственнику – не самая лучшая идея. Проект просто остановился бы еще раньше, потому что, скорей всего, распрощались бы в тот же день. А мне интересно было доделать этот проект, опыт и знания получить. Еще и строчку в резюме.
Суть всех примеров проста – компания, управленцы и сотрудники, стремясь сделать быстрей и подешевле, просто «сами могут себе в ноги выстрелить», и лишить себя перспектив развития продукта, возможности интеграции продукта с другими учетными системами, возможностей масштабирования и т.д. А главное – лишить свой бизнес возможностей развития и масштабирования. И иногда, ни письменно, ни устно – нет никакой возможности донести эту информацию до лиц, которые принимают решение.
Но справедливости ради, в той компании я выполнил все обязательства (обещания), которые на себя взял (одно из них было – не менее 6 месяцев участвовать в проекте и сообщать о том, что мешает в работе), а собственник исправно оплачивал мое участие в проекте. И при уходе, я подготовил в письменной форме перечень всех причин, почему проект явно не будет завершен. То есть, все от меня зависящее и не вредящее здоровью, и в рамках трудовых обязанностей – я сделал.
Решения выгодоприобретателей:
· Отказ от документирования: экономия на создании технической документации;
· Упрощение архитектуры: использование простых, но неэффективных решений;
· Отсутствие резервного планирования: пренебрежение созданием планов восстановления.
Если в вашей компании создается или внедряется IT-продукт, и вам нужно управлять процессами его создания и внедрения, реализации, управлять проектной командой, то можете обратиться ко мне в телеграмм и предложить сотрудничество.
Опять, приведу несколько примеров, потому что знаю – мои статьи часто читают неспециалисты и им нелегко воспринимать информацию без примеров.
Пример 4. Отказ от документирования. Я сторонник документирования своей работы. В первую очередь потому, что при активной работе иногда сложно вспомнить даже то, над чем работал две недели назад, не то чтобы вспомнить над чем работал месяц, два и три назад. Все работы на проекте выполняются в рамках каких-либо стоимостных и временных ограничений. Поэтому, как минимум, нужно вести перечень задач, с описанием сути задачи, ее постановщика и исполнителя. Есть специализированные программные продукты для этих целей, но в простейших случаях (для демонстрации, или при работе в режиме «на коленке»), может подойти простая таблица Excel.
В качестве примера отказа от документирования могу привести ситуацию, когда люди от лица компании-заказчика игнорируют список задач, и мотивируют это посылом «Нам все равно, что там в этом списке! Нам нужна работающая программа». Мое мнение: «Это хорошо, что нужна. Но без учета задач, выполнить их все невозможно в принципе, чтобы там заказчику не хотелось».
Пример 5. Еще один пример отказа от документирования. Как-то я писал техническое задание на доработку. Конкретно, нужно было кадровый и зарплатный блок в 1С:КА усовершенствовать, расчет оплаты труда сотрудникам нужно было выполнять на основе данных о выручке по торговой точке. Стандартного механизма такого расчета там нет. Техническое задание получилось на 57 страниц. Мнения представителей заказчика очень разделялись. Собственник компании очень положительно относился – пусть пишет, это хорошо, что есть что записать.
Но вот остальные представители компании заказчика много разного высказывали. Одно из самых негативных: «Полюбил писать. Может просто затягивает и усложняет проект?». И еще момент: Оценивал техническое задание тот человек, который в принципе имел противоположные интересы - не внедрить КА, а помешать внедрению. Причин на такое отношение я увидел несколько, но наверняка – их больше, чем я увидел. Первая причина – нужно наводить порядок в базе-источнике, чтобы не переносить «бардак» в новую базу данных. Есть такой тезис: Хаос нельзя автоматизировать. При попытке автоматизации хаоса, возникает еще больший хаос. Вторая причина – не просто же так компания переходит со старого продукта, на новый. «Старый» чем-то не подходит. Причем, в компании все открыто говорили о причинах.
Мое мнение: «Без внятного технического задания, невозможно сделать полезный продукт (или доработку продукта)». Пока пишется и согласуется техническое задание, много «скелетов в шкафу» можно найти. Правильно выстроенные процессы написания и согласования технического задания приводит к устранению противоречий в ожиданиях сотрудников компании-заказчика от самого проекта внедрения продукта, приводит к формированию бюджета на реализацию доработок и адекватному планированию сроков выполнения всего проекта в целом. При условии, если не мешают, или мешают не сильно. Если даже техническое задание нет возможности согласовать в компании, то нет смысла переходить к последующим этапам проекта внедрения. Скорей всего, просто обвинят во всех бедах (срыв сроков, перерасход бюджетов, отсутствии результатов).
Пример 6. Упрощение архитектуры. Часто, под давлением сроков и бюджетов (или их отсутствия), люди приходят к мысли о том, что нужно упростить задачу и внедрить хоть что-нибудь. Иногда это выражается в том, что из всей конфигурации, в которой более 600-а типов документов, могут использоваться только 9. Мое мнение: «Ну 9, так 9. Давайте с этого и начнем». Но возникают вопросы, если продукт не используются напрямую, а используется в связке с другими, и будет нужна интеграция с другими продуктами, то – не получится ли так, что мы каждый раз будем делать полушаги? То есть, не получится ли так, что однажды, настроив интеграцию с другим продуктом, задачу пометят, как «решенную», а потом расшириться круг используемых объектов конфигурации (базы данных, программы), и не придется ли переделывать механизм переноса данных заново?
Чаще всего так и случается. Хорошо, если в компании-заказчике понимают суть итерационного подхода к разработке и внедрению. То есть всегда можно сказать, что задача формулировалась в таком виде, в таком виде она была решена. Но теперь, требования изменились и нужно исправить систему, привести ее к такому-то виду. Но когда, вместо адекватной реакции возникает «дикий топот и визг», то проект в принципе можно не закончить, т.к. условий для его завершения нет, и их невозможно создать. И, как минимум, результаты адекватно не смогут оценить, а значит не смогут адекватно оценить вклад в проект.
Пример 7. Пренебрежение резервными планами. При работе с данными очень часто возникает ситуация, в которой данные могут быть изменены или потеряны. Делать бэкап перед вмешательством, это требование «по умолчанию» в среде разработчиков. Однако, для собственников компании и управленцев, создание бэкапов, или резервных планов, это дополнительные расходы денег и внимания, времени.
В моей практике, не часто компании запускали работу над проектом и набирали две команды внедренцев, или более. Обычно это связано с финансовыми затратами, и невозможностью сравнить оба варианта между собой, т.к. если заказывают проект внедрения, то скорей всего, самостоятельно внедрить не могут (не умеют, или не хотят, или сразу все вместе). Иногда, это связано с тем, что компании сталкиваются с «требованием» от компаний внедренцев – «проект будет только наш, если будет кто-то еще, то не будем так работать!»
Мое мнение: «Я бы подумал, если такое условие выдвигается, а «наш» ли это подрядчик?» Есть же программные продукты известные. В них есть документация, работающий код, работающее приложение, есть результаты использования такой программы. Все это можно продемонстрировать и протестировать. Если подрядчик не готов работать в таких же условиях, и создавать работающий продукт (предоставив выше перечисленные подтверждения), который можно сопровождать и поддерживать – не значит ли это то, что подрядчик не обладает нужными компетенциям? Меня бы это, как минимум, насторожило. Как максимум – я бы нашел других подрядчиков, опыт имеется.
В моей практике, случалось даже так, что внезапно переключались с внедрения одного продукта на другой, при этом, отказываясь полностью от достигнутых результатов и от проектной команды. Мое мнение: «Ну хочется людям так сделать, пусть делают. Деньги их, и репутация тоже. Но нормальный проект не останавливают при первых неудачах. А если часто останавливают проект, переключаются на другой, и меняют команду, можно ли назвать такую компанию надежной? Думаю, что нет».
Собственно, поэтому я и стараюсь не нарушать обещаний, или не давать «пустых». Потому что на проекте разное может произойти, а от проектной команды и от ее доступности в критические моменты проекта – многое зависит. Хотя случалось и такое, что проектная команда – это только я один (точней, один ее участник, остальных или еще нет, или уже нет, или не планировалось вообще).
Ошибки исполнителей:
· Жёсткая привязка данных: создание зависимостей между модулями вместо гибкой архитектуры
· Дублирование функциональности: копирование кода вместо создания повторно используемых компонентов
· Отсутствие модульного тестирования: пропуск этапа проверки отдельных компонентов
Если в вашей компании создается или внедряется IT-продукт, и вам нужно управлять процессами его создания и внедрения, реализации, управлять проектной командой, то можете обратиться ко мне в телеграмм и предложить сотрудничество.
Также, приведу примеры под каждый вариант.
Пример 8. Жесткая привязка данных. Рассмотрим торговую точку. На ней моноблок кассира, сканер штрих-кодов, и фискальный регистратор. Представим, работает это оборудование на одной точке. Но возникла ситуация, нужно открыть другую торговую точку. Правильно было бы, привести комплект оборудования на действующую торговую точку, настроить там, протестировать работу. А после этого, перевезти на другую (новую), сменить организацию, склад (магазин), поменять ответственных лиц, поменять фискальный регистратор (на организацию свой ФР) – все. Можно запускать работу новой торговой точки.
Но нет… Оборудование настраивается в офисе. Тестируется, и только потом вывозится на точку. Тоже вариант, в офисе все сотрудники в сборе, не нужно ехать куда-то, все «под рукой». Классно. НО..если нужно аварийно запустить торговую точку, моноблок резервный есть, но настройка занимает два дня. Просто перевести оборудование с торговой точки и подменить – нельзя (даже, с учетом того, что есть торговые точки с двумя комплектами оборудования).
Пример 9. Дублирование функциональности. Этот пример больше связан непосредственно с разработкой программного обеспечения. Например, вместо общего модуля могут использовать доработку модуля документа. Бывает причины, когда это оправдано. Например, чтобы сохранить поддержку продукта, можно создать расширение и там нужный документ, регистр и отчет. Это не затронет основную конфигурацию 1С продукта. Обеспечит отказоустойчивость, хотя бы типовая функциональность заработает, в случае неисправности. Но в целом, лучше изменения вносить в общий модуль. А обращающиеся к нему документы будут использовать «измененный метод». Доработка только в одном месте, а не во всех документах. Явно – экономия времени разработки и тестирования новой функциональности.
Однако, встречался и с ситуацией, когда под предлогом убрать (не допустить) дублирование функций отказывались от «сложной» доработки продукта. При этом, ссылаясь на то, что в другом продукте это есть, и можно использовать это в другом продукте (подразумевалось, данные мигрируют между продуктами (программами), «Торговая точка» - > «Центральная база», а вот анализ данных не будут делать на торговой точке, будут делать в бухгалтерии, или в финансово-экономическом отделе.
Но по факту, человек просто не хотел исправлять намеренно созданный «бардак» в своей (администрируемой им) учетной системе, и прикрывался высокими целями, пользуясь технической некомпетентностью руководителя. При этом, еще и тихо саботировал будущую возможность анализа данных. Т.к., если данные придут в бухгалтерскую программу не все, то анализ нельзя будет выполнить). При этом, руководитель боялся делегировать полномочия принятия решения технически подготовленному специалисту.
Пример 10. Отсутствие модульного тестирования. Сталкивался в своей работе и с такой ситуацией, когда вместо тестового контура, обновление программы ставилось сразу на рабочий сервер. И пользователи были вынуждены тестировать «сырой» программный продукт за свой счет, тратя свое время и нервы. Глядя на эту ситуацию в компании, сложилось впечатление, что человек специально издевался над пользователями программного продукта, так как они его обидели чем-то.
Правильно будет, если все доработки тестируются на тестовой базе, и сначала силами разработчиков и тестировщиков. Если у разработчиков нет возможностей тестировать полностью свой продукт – это слабая команда. Если компания не может принять на работу нужных людей и выполнить полный цикл разработки – это слабая компания.
Есть, конечно, примеры того, когда приложения тестируют пользователи. Например, приложения для занятия английским. Пользователи могут написать разработчику, что какая то функция не работает или возникает ошибка. Но, это учебный продукт.
А когда возникает ошибка в продукте, который считает твою выручку по торговой точке и твое вознаграждение в виде процента от выручки, то просто по неволе, вынужден будешь данные о выручке и вознаграждении переносить в другую программу (например, Excel). А это не добавляет доверия к программному продукту, к специалисту занятому его внедрением, и компании, которая вынуждает человека делать дублирующие записи и проверять работу программы, которая должна была облегчить работу управляющего сетью торговых точек (территориального управляющего).
И вообще, если в компании намеренно создается такой «хаос» можно ли сказать, что компания хорошая? Тут намерено не буду приводить название компании и используемые программные продукты, т.к. не все зависит от продукта. Многое зависит от уровня зрелости культуры управления в компании, или ее отсутствия. Много зависит и от того, какие люди работают в компании, и/или создали компанию. Вопросы спорные, но у меня цель – не спор затеять, а дать примеры ошибок, которые лучше не делать, т.к. дорого. Компании теряют на этих ошибках и деньги, и время, и сотрудников, и покупателей продуктов. А это все - упущенные перспективы и нереализованные возможности.
Распространенные примеры накопления технического долга
Ситуация 1: Внедрение системы учета без должной проработки бизнес-процессов
· Причина: желание быстро автоматизировать процессы
· Последствия: необходимость постоянной доработки системы под специфические случаи
Ситуация 2: Использование устаревших технологий
· Причина: экономия на обновлении технологической базы
· Последствия: сложности с поддержкой, уязвимости безопасности
Ситуация 3: Пренебрежение качеством кода
· Причина: фокус на функциональности в ущерб качеству реализации
· Последствия: рост времени на поддержку, увеличение количества ошибок
Если в вашей компании создается или внедряется IT-продукт, и вам нужно управлять процессами его создания и внедрения, реализации, управлять проектной командой, то можете обратиться ко мне в телеграмм и предложить сотрудничество.
Возможные рекомендации - как избежать накопления технического долга
Рекомендации для инициаторов:
· Планировать реалистичные сроки внедрения;
· Выделять ресурсы на тестирование и документирование;
· Учитывать перспективы развития системы.
Рекомендации для выгодоприобретателей:
· Инвестировать в качественную архитектуру;
· Поддерживать процессы обновления;
· Контролировать качество реализации;
· Нанимать технически подготовленных людей;
· Учиться делегировать полномочия, а не только обязанности.
Рекомендации для исполнителей:
· Следовать стандартам разработки;
· Документировать решения;
· Проводить код-ревью;
· Правильно распределять трудовую нагрузку;
· Использовать гибкие методики разработки (Agile, Scrum).
Заключение
Управление техническим долгом — ключевой фактор успеха при разработке систем учета и управления (при ведении проектов разработки ПО и его внедрения). Важно понимать, что роста технического долга не всегда можно избежать полностью, но его можно контролировать и минимизировать.
Помните: технический долг — это не приговор, а инструмент, который при правильном использовании может помочь достичь бизнес-целей. Главное — осознанно принимать решения о его накоплении и иметь четкий план погашения.
Регулярный анализ технического состояния системы и своевременное устранение накопленных проблем помогут избежать серьезных проблем в будущем и обеспечить стабильную работу бизнес-процессов.
Ответ на основной вопрос статьи: Что такое «Технический долг» при разработке и внедрении программных продуктов, и как он может лишить компании возможностей развития?
Технический долг — это накопленные проблемы в коде и архитектуре программного продукта, или во всей IT-архитектуре компании, возникающие из-за принятия быстрых, но неоптимальных решений при разработке и внедрении. Такой долг лишает компанию возможностей развития следующими способами:
· Замедление разработки новых функций из-за необходимости постоянно исправлять старые ошибки;
· Рост затрат на поддержку системы вместо развития новых возможностей;
· Ограничение масштабирования бизнеса из-за негибкой архитектуры;
· Потеря специалистов, не желающих работать с проблемным кодом;
· Снижение качества продукта и ухудшение пользовательского опыта;
· Упущенные возможности быстрого реагирования на изменения рынка;
· Увеличение рисков сбоев и потери данных.
В итоге компания оказывается в ситуации, когда вместо развития новых направлений вынуждена постоянно “тушить пожары” в существующей системе, теряя конкурентные преимущества и возможности роста.
Если в вашей компании создается или внедряется IT-продукт, и вам нужно управлять процессами его создания и внедрения, реализации, управлять проектной командой, и вы хотите постараться избежать перечисленных проблем, то можете обратиться ко мне в телеграмм и предложить сотрудничество.
С автором можно связаться в телеграмм @Yuriy_EB(efficient business)
Если вам понравилась статья – оцените лайком и репостом. Это помогает развивать канал.