Image via Shutterstock.Всем привет. Сегодня хочу затронуть такую тему, как технический долг с точки зрения проектного менеджера.
Для начала разберемся, что такое технический долг (ТД). Под ТД я имею в виду:
— Откровенно плохую архитектуру;
— Не-модульность компонентов;
— Плохое качество кода отдельных компонентов;
— «Костыли»;
— Изменения, которые нужно сделать в отдельных модулях кода, вызванные другими изменениями.
Причины возникновения и последствия
ТД может быть вызван такими вещами, как:
— Сжатые сроки,когда разработка «как положено» откладывается на тот момент, «когда будет время». В результате такого подхода страдает модульность кода, при небольшом изменении одного участка страдает весь код сразу. Из-за этого тривиальные задачи могут выполняться днями.
— Плохое взаимодействиевнутри команды, которое приводит к тому, что на этапе отладки приходиться тратить времени больше, чем было запланировано. Это, в свою очередь, возвращает к предыдущему пункту.
— Непонимание заказчикомтого, как устроен его продукт. В таком случае разработчикам приходиться добавлять функционал, который противоречит первоначальной задумке. Либо успевать к определенным датам, когда продукт должен быть представлен инвесторам\тестировщикам\пользователям. В результате костыли в коде растут, как грибы.
— Отсутствие рефакторинга. Как правило, случается из-за невозможности донести до заказчика необходимость его проведения. И, как следствие, происходит потеря качества и производительности кода.
— Низкая квалификация сотрудников. Они вроде и хотели бы написать код лучше, но как-то не выходит.
А на выходе получатся продукт, который сложно поддерживать.
Как и любой другой долг, этот тоже приходится со временем отдавать. Команда отдает долг в тот момент, когда переписывает код. ТД также имеет проценты. Их приходиться выплачивать за счет того, что при выполнении следующих задач нужно тратить больше времени, чем можно было бы.
А как все это выглядит со стороны проектного менеджера? Приблизительно вот так. Сроки подходят к концу, бюджет подходит к концу, резервов уже нет — а дело не сделано.
Как пример, в моей практике был такой случай: заказчик постоянно присылал все новые и новые требования, согласно которым функционал становился сложнее. Каждый раз, когда поступало новое требование, команда давала заказчику оценку, что задача займет небольшое количество часов, так как и задачи были по своей сути не сложные. Но в результате этого socket соединение было перегружено и при высокой активности часто отпадало. То есть неожиданно для нас образовался технический долг — архитектура, которая была заложена при проектировании системы, стала не оптимальной. В этой ситуации оценка давалась каждой отдельной задаче, а влияние на систему в общем не учитывалось совсем. Соответственно, времени на решение проблем также выделено не было. В итоге по окончанию выделенного на разработку времени получилось крайне не стабильное (в определенных частях) приложение.
Документируем и оцениваем
Проектный менеджер должен работать с ТД приблизительно таким же образом, как и с тасками во время формирования плана на спринт. Обязательно следует документировать ТД: делать векселя и планировать время для выплаты долгов в каждом спринте, а также распознавать и устранять риски, которые могут вызывать появление такого долга.
Таким образом, в проекте появляется новый тип задач — технический долг, с жизненным циклом, очень похожим на таск или баг. Только если источником тасок является проектный или продуктовый менеджер, а багов — команда тестировщиков, то задачи по ТД должны создаваться и сразу оцениваться разработчиками. Получается, что разработчик пишет сам себе напоминание на будущее в тот самый момент, когда делает костыль. Преимущество заключается в том, что пока воспоминания о только что написанном коде свежие, то и напоминания получатся точными. Источником задачи по погашению ТД может стать и проектный менеджер, если при проведении ретроспективы были обнаружены ТД.
При таком подходе проектный менеджер будет иметь задокументированный список проблем и активно им управлять.
Если бы я применил такой подход ранее, то имел меньше проблем со своим проектам. Тогда бы команда обращала внимание на возможные последствия добавления дополнительных данных в один и тот же канал связи и сразу бы оценивала изменения, которые нужно сделать в архитектуре, возможный перенос некоторых данных в другие каналы и т.п. И я бы мог оговорить необходимость выделения большего времени для того, чтобы интегрировать новый функционал правильно, либо оговорить другие варианты внедрения с меньшим ущербом для архитектуры приложения.
Если вы знаете/имеете практику работы с ТД, пожалуйста, пишите в комментариях. Давайте обсудим вместе.