Контролировать качество в сфере разработки сложно для заказчика, потому что и сам продукт разработки — это сложная система с большим количеством элементов. Инструменты для мониторинга качества есть, но они слишком «технические», в большинстве своём ориентированы на отладку, а не на контроль и не учитывают бизнесовые показатели. К тому же добиться прозрачности проекта получится далеко не от всех подрядчиков.
К счастью, выход есть: в этой статье мы поделимся конкретными рекомендациями, какие метрики и сервисы помогают держать под контролем весь процесс разработки.
Как контролировать IT-подрядчика
Успешность каждого проекта определяют по-разному. Для интернет-магазина важен финансовый результат (прибыль, рентабельность). При разработке B2B-портала будем отслеживать, какая доля контрагентов его использует. Система автоматизированной обработки документов должна выдать определённый процент точности. И так далее, главное — договориться «на берегу», какие метрики будут целью.
«При этом нельзя определять только общий успех проекта и не анализировать процесс. Почему? Не понимая, качественно ли идёт процесс разработки, не получится выявить чёткие закономерности и понять истинные причины того или иного состояния показателей, оценить, насколько в этом вина или заслуга IT-специалистов, а насколько — влияние других причин. Конверсия снизилась, а кто виноват: маркетологи провели неудачную акцию, вмешался сезонный фактор или подрядчик допустил увеличение 500-ых ошибок на сервере в последнем релизе?» — Андрей Путин, Генеральный директор kt.team
К тому же без качественного процесса будет очень сложно получить качественный результат.
О качестве процесса говорят следующие метрики:
- статический анализ релиза (количество ошибок в коде, front-end'е; рекомендуем использовать следующие стандарты и инструменты: PSR-2, EcgM2, ESLint, W3C, PageSpeed);
- отчёты JavaScript о количестве ошибок + LogReport;
- APM типовые vs аномалии (это трейсеры, которые показывают (в миллисекундах), как работает каждый участок кода (нормально или с отклонениями), и на которых можно «провалиться» внутрь, чтобы проанализировать причины аномалий);
- ошибки 404, 500 и т. д. в динамике;
- метрики, которые уникальны для конкретной CMS;
- культура в релизах (частота релизов, соответствие графику, количество ошибок в них);
- результаты аудитов (их нужно проводить регулярно, например раз в месяц).
Эти метрики можно объединить одним понятием: технический долг.
Проблема в том, что чаще всего руководство компании-заказчика смотрит только на итоговый результат и не знает о реальном техническом состоянии проекта. Основная причина этого в том, что подрядчики не делают отчёты о качестве, и проект получается «непрозрачным». А значит, клиент не знает всех рисков и не может транслировать это своим инвесторам. Это приводит к тому, что бизнес-модель проекта не учитывает всех ограничений, а трудовые и финансовые затраты на обработку технического долга проекта не планируются заранее.
Технический долг
Технический долг — метафора, означающая все накопленные в IT-проекте проблемы, которые могут быть исправлены. Долг не всегда говорит о плохой работе разработчиков. Обычно он появляется при работе в условиях жёстких ограничений: либо по срокам, либо по бюджету. А так как в бизнесе ограничения есть всегда, то и технический долг есть всегда; его можно отслеживать, контролировать, уменьшать, но нельзя полностью устранить.
«Например, мы работали с крупным e-Commerce-клиентом, который просто не успел вовремя оплатить хостинг, а проект „горел“, и пришлось сделать ему некрасивое решение на кластере (перестроить на менее „красивый“ Docker). Мы говорим заказчику: „Здесь есть технический долг, зато успели в срок. Давайте, когда будет пройден пик сезона, переделаем это решение“. Другой кейс: код замечательно работал, но разработчики заметили аномалии в производительности. Это значит, что где-то было применено неоптимальное решение (возник технический долг). Почему так происходит? Значит, были ограничения по срокам или по бюджету. Необходимо переделать», — Андрей Путин, Генеральный директор kt.team
Главное с техническим долгом: оцифровать его (оценить масштаб) и запланировать работы по его уменьшению.
Работа по оцифровке качества проекта (технического долга) включает:
- сбор параметров производительности через apminvest.com, newrelic.com, AppDynamics; мы под такими параметрами понимаем время ответа сервера и коллекцию трейсов приложений хотя бы за последние 24 часа;
- очередь задач в разработке и решённых на сегодня;
- мониторинг количества ошибок — от ошибок статического анализа до ошибок на сервере;
- мониторинг ошибок пользователей и сообщений об ошибках от кол-центра (если есть кол-центр или горячая линия техподдержки);
- контроль количества соблюдаемых процедур (процессов).
Дополнительно оцифровать технический долг помогают и бизнесовые показатели:
- сообщения от операторов (#ошибка #не_подтверждено #подтверждено) в день;
- отменённые заказы за день;
- аномалии по заказам в день (отклонения от нормы по времени, сумме среднего чека и т. п.);
- закрытые задачи за день.
Для контроля и управления производительностью сайтов существуют специальные инструменты: системы мониторинга производительности приложений APM (application performance monitoring).
Сервисы APM
Самая известная APM-система в мире — это New Relic. Она предоставляет следующие показатели производительности:
- время отклика, пропускная способность, частота ошибок и т. д.;
- выполнение внешних услуг;
- самые трудоёмкие транзакции;
- трассировка кросс-приложений;
- срыв транзакции;
- анализ развёртывания, история и сравнение.
Её минусы — высокая цена и невозможность тонкой настройки (есть «коробочное» решение, общее для всех).
«В KT.Team мы пользуемся собственным продуктом, который заменяет New Relic и даёт нам более широкие возможности: APMinvest. Эта система удобна не только для управления качеством, но и для аудита технического состояния сайта (в том числе оцифровки технического долга). Поскольку главная цель бизнеса — это прибыль, было бы неплохо сразу видеть влияние технических показателей на финансы, в режиме реального времени, и как можно более наглядно — в виде понятной аналитической панели, дэшборда (англ. dashboard). Это также реализовано в APMinvest», — Андрей Путин, Генеральный директор kt.team
Примеры вопросов, на которые может ответить APMinvest
1. Какое реальное время работы сервера? Когда наблюдаются проблемы в скорости работы? Совпадают ли просадки работы сервера с пиком активности вашей аудитории? Как это отражается на конверсии?
2. Мониторинг PageSpeed score: как влияет скорость загрузки на доход вашей компании? Какова текущая степень оптимизации вашего проекта?
3. Как после каждого релиза изменяются показатели статического анализа, количество ошибок в логах, данные из Google Analytics или вашей CRM?
4. Настроить параметры дэшборда можно под конкретный запрос, чтобы учесть любые взаимосвязи технических и бизнес-показателей. Это очень удобно и ставит работу айтишников под полный объективный контроль менеджмента.
Что это даёт заказчику?
- Быстрое обнаружение ошибок.
- Повышение качества разработки: снижение количества ошибок, уменьшение технического долга, снижение рисков плохой работы сайта после обновлений.
- Полную диагностику проекта на предмет «хронических» ошибок и технического долга, мешающих эффективному функционированию платформы.
- Контроль состояния проекта, быстрые уведомления о том, что важно знать. В «Телеграме» создаётся чат-бот проекта, куда попадают сообщения обо всех ошибках, и ошибки группируются по типам.
- Общий язык для постановки задач, понятный всем сотрудникам и повышающий эффективность работы команды.
- Разработку в спокойном и эффективном темпе.
Итоговые рекомендации по контролю эффективности разработки
Качество разработки нужно контролировать, чтобы не допускать убытков и экономить ресурсы. Делать это легко: есть специальные сервисы для мониторинга производительности приложений (New Relic, APMinvest и другие). Используйте их в своих проектах.
Кстати, все клиенты KT.Team получают доступ к APMinvest. Причина? Это помогает нам делать работу максимально качественно. Клиенты видят, что проект прозрачен, и это повышает их доверие; разработчики видят, что результаты каждого действия на виду, и более ответственно выполняют задачи; техническая команда со стороны заказчика говорит на одном языке с командой разработчиков, потому что ещё «на берегу» они договариваются о том, за какими метриками будут следить и какие значения будут считать нормой.
Чтобы узнать больше об APMinvest, задайте вопрос в комментариях — мы обязательно ответим в течение рабочего дня.
