Разработка и развертывание систем BI достаточно быстрый и дешевый процесс, но их обслуживание с течением времени является дорогостоящим. Это можно представить, через метафору технического долга.
Технический долг — обозначает накопленные в программном коде или архитектуре проблемы, связанные с пренебрежением к качеству при разработке программного обеспечения и вызывающие дополнительные затраты труда в будущем.
Часто существуют обоснованные стратегические причины брать на себя технический долг. Не вся задолженность является безнадежной, но вся задолженность нуждается в обслуживании. Технический долг может быть выплачен путем рефакторинга кода, улучшения тестирования, удаления мертвого кода, уменьшения зависимостей, ужесточения API и улучшения документации. Цель не в том, чтобы добавить новую функциональность, а в том, чтобы сделать возможным будущие улучшения, уменьшить количество ошибок и улучшить ремонтопригодность. Отсрочка таких платежей приводит к сложным расходам. Скрытый долг опасен, так как он бесшумно увеличивается.
Примеры технического долга в BI:
Только знание об этом, к сожалению, не обеспечивает каких-либо метрик для управления. Как измерить технический долг в системе или оценить полную стоимость этого долга? То, что команда все еще работает, не является свидетельством низкого уровня долга, поскольку полная стоимость долга становится очевидной только с течением времени.
Можно рассмотреть несколько полезных вопросов:
Мы надеемся, что данная статья может послужить стимулом для дополнительных разработок в области BI, включая совершенствование методик тестирования, шаблонов проектирования и другого. Но наиболее важным моментом, является то, что техническая задолженность — это проблема, о которой должны знать и программисты, и менеджеры.
Технический долг — обозначает накопленные в программном коде или архитектуре проблемы, связанные с пренебрежением к качеству при разработке программного обеспечения и вызывающие дополнительные затраты труда в будущем.
Часто существуют обоснованные стратегические причины брать на себя технический долг. Не вся задолженность является безнадежной, но вся задолженность нуждается в обслуживании. Технический долг может быть выплачен путем рефакторинга кода, улучшения тестирования, удаления мертвого кода, уменьшения зависимостей, ужесточения API и улучшения документации. Цель не в том, чтобы добавить новую функциональность, а в том, чтобы сделать возможным будущие улучшения, уменьшить количество ошибок и улучшить ремонтопригодность. Отсрочка таких платежей приводит к сложным расходам. Скрытый долг опасен, так как он бесшумно увеличивается.
Примеры технического долга в BI:
- В BI проекте существует хранилище данных, но фактически оно является копией рабочей базы данных. В результате, теряются преимущества хранилища, такие как скорость обновления данных, также возможны потери или повреждения данных.
- При загрузке и модификации данных (ETL) не происходит проверка/исправление повреждённых данных. Ошибки переносятся в приложение.
- Неоптимальные названия полей и переменных затрудняют редактирование и использование приложения в будущем.
- Изначально неправильно выбранная модель/структура данных приложения ведёт к проблемам при эксплуатации и модификации приложения.
- Менеджер BI под давлением берет на себя обязательство завершить проект к определённой дате, которая в большей степени определяется ожиданиями заинтересованных сторон, чем ресурсами команды или оценками (если таковые имеются). И либо этого не происходит, либо проект получается низкого качества.
- Каждый проект BI — это свой собственный остров пользовательских требований и подходов. Не существует централизованной стратегии BI. Например, из-за отсутствия унификации приходится тратить больше времени на изменение разных приложений.
- Не определены конкретные роли людей, работающих над проектом, и методы их взаимодействия (коммуникации).
- Администраторы своевременно не обновляют версии программного обеспечения BI, в результате чего могут возникнуть ошибки, либо могут воспроизвестись какие-то ошибки, которые уже были исправлены вендором.
Только знание об этом, к сожалению, не обеспечивает каких-либо метрик для управления. Как измерить технический долг в системе или оценить полную стоимость этого долга? То, что команда все еще работает, не является свидетельством низкого уровня долга, поскольку полная стоимость долга становится очевидной только с течением времени.
Можно рассмотреть несколько полезных вопросов:
- Насколько легко можно в полной мере протестировать совершенно новый алгоритм для расчета показателей?
- Как точно можно измерить влияние нового изменения в системе?
- Как быстро можно ввести в курс дела новых членов команды?
Мы надеемся, что данная статья может послужить стимулом для дополнительных разработок в области BI, включая совершенствование методик тестирования, шаблонов проектирования и другого. Но наиболее важным моментом, является то, что техническая задолженность — это проблема, о которой должны знать и программисты, и менеджеры.
