Если организация не выплачивает свой технический долг, то каждое ее усилие будет потрачено лишь на выплату процентов в форме незапланированной работы.
Этого не видно
Это то, что вы, как заказчик, не видите. Представьте себе, что вы заказали строительство дома подрядчикам. Дом построен, вы начинаете в нем жить. Наступил сезон дождей и крыша начала подтекать. В стенах завелись жуки, балки начали гнить. Появились щели, из которых начало задувать. Это те вещи, которые были сделаны по принципу “лишь бы сдать заказчику”.
В создании информационных систем тоже есть свои нюансы. Они всплывают со временем использования информационных систем или тогда, когда вы решаете внести изменения самостоятельно или с привлечением другой компании.
Сделать любой программный код и решить задачу можно очень большим количеством способов, и любой разумный человек идет по пути наименьшего сопротивления: сделать так, чтобы все работало. Это нормально с точки зрения человеческой натуры и естественного хода вещей, но неправильно по отношению к заказчику. Нельзя закрывать глаза и не задаваться вопросом: “А как это будет работать, когда данных станет очень много?”.
Конечно, должны быть рамки разумного. Часто наш технический директор при обсуждении деталей работы с менеджером проекта говорит, что нельзя делать так, а надо строить сложный (и дорогой для заказчика) механизм, потому что если записей станет миллион, то система будет работать на 1 секунду дольше. И приходится убеждать, что и с точки зрения бизнеса и с точки зрения клиента тут записей будет не большое 10. Конечно, перегибать не надо, но всегда нужно учитывать то, как клиент будет пользоваться системой через несколько лет.
При разработке проекта мы ставим задачи, которые помечаем у себя как “технический долг”. Это те вещи, которые необходимо сделать, чтобы проект работал хорошо. Часто имеется в виду закладывание такого программного кода, который в будущем позволит избежать проблем при возможной перестройке системы.
Архитектура системы должна планироваться и строиться так, чтобы систему можно было расширять. Это необходимо закладывать при раннем техническом проектировании. Когда заказчик будет дорабатывать систему самостоятельно или с помощью других подрядчиков, у него будет меньше шансов сделать что-то неправильно или испортить то, что сделано.
Недопустимо для компании
Если отдельному частному специалисту, как и бригаде строителей в примере выше, допустимо выполнить заказ так, что потом хоть трава не расти (сдать и перекреститься), то для компании это не допустимо.
Что такое нести ответственность? Это понимание того, кому необходимо будет вносить исправления, если что-то пойдет не так. Мы не так просто даем пожизненную гарантию на наши продукты, если в них не вносились изменения сторонними участниками.
Существует такой тезис — если организация не выплачивает свой технический долг, каждое ее усилие будет потрачено лишь на выплату процентов в форме незапланированной работы.
Чтобы делать меньше незапланированной работы по починке того, что сломалось, необходимо сразу сделать качественно. Именно поэтому в рамках проекта у нас есть такое понятие, как технический долг.
Были случаи по нескольким проектам, когда мы выявляли возможную проблему спустя несколько лет после завершения и запуска проекта. Ставили задачи на технический долг, обращались к клиенту и вносили изменения в проект, чтобы исправить ситуацию до возникновения проблемы.
Развитие системы
Примерно в половине случаев разработка программного продукта не останавливается на решении одной локальной задачи. Как при разработке комплексной системы автоматизации, которая выполняется в несколько этапов, так и при расширении системы путем добавления нового функционала по мере возникновения потребностей всегда появляется технический долг. Это нормальная практика при разработке информационной системы.
Вопрос в том, растет он как снежный ком или решается в процессе разработки. Проблема роста технического долга выражается в незаметности его для заказчика. В итоге проблема в том, что когда заказчику необходимо выполнить доработки или разработать новый модуль к информационной системе, возникает следующая ситуация. Он получает смету, превышающую затраты на разработку аналогичного модуля при создании новой системы. И не понимает, что происходит и почему так.
Рост стоимости разработки объективно может быть связан с тем, что выполнять доработку будет другой подрядчик, не знающий проект и архитектуру и требуется время, чтобы во всем разобраться. Но если разработка выполняется в рамках одной компании, то это или плохая архитектура приложения, или наличие технического долга на проекте. Его необходимо или разбирать, или учитывать при разработке расставленные по проекту грабли.
Как избежать технического долга от подрядчика
Результатом наличия технического долга или некачественной разработки являются рано или поздно возникшие проблемы с информационной системой и её эксплуатацией. Стоит задаться вопросом, как эти проблемы будут решаться и за чей счет. Именно это является ключевым и имеющим значение фактором для заказчика.
Всё решает наличие или отсутствие гарантии, а также вид этой гарантии. Надеяться на гарантию от молодой компании или частного специалиста не приходится, но есть разные виды гарантий и от компаний, которые существуют на рынке уже несколько лет. Стоит уточнить этот момент у подрядчика перед началом работы, а еще лучше учитывать этот фактор при выборе исполнителя.