Как заказчику контролировать разработчиков: важные метрики и полезные сервисы

Контролировать качество в сфере разработки сложно для заказчика, потому что и сам продукт разработки — это сложная система с большим количеством элементов. Инструменты для мониторинга качества есть, но они слишком «технические», в большинстве своём ориентированы на отладку, а не на контроль и не учитывают бизнесовые показатели. К тому же добиться прозрачности проекта получится далеко не от всех подрядчиков.

К счастью, выход есть: в этой статье мы поделимся конкретными рекомендациями, какие метрики и сервисы помогают держать под контролем весь процесс разработки.

Как контролировать IT-подрядчика

Успешность каждого проекта определяют по-разному. Для интернет-магазина важен финансовый результат (прибыль, рентабельность). При разработке B2B-портала будем отслеживать, какая доля контрагентов его использует. Система автоматизированной обработки документов должна выдать определённый процент точности. И так далее, главное — договориться «на берегу», какие метрики будут целью.

‍

«При этом нельзя определять только общий успех проекта и не анализировать процесс. Почему? Не понимая, качественно ли идёт процесс разработки, не получится выявить чёткие закономерности и понять истинные причины того или иного состояния показателей, оценить, насколько в этом вина или заслуга IT-специалистов, а насколько — влияние других причин. Конверсия снизилась, а кто виноват: маркетологи провели неудачную акцию, вмешался сезонный фактор или подрядчик допустил увеличение 500-ых ошибок на сервере в последнем релизе?»

‍

‍

‍

‍

‍

‍

‍

‍

‍

‍

К тому же без качественного процесса будет очень сложно получить качественный результат.

О качестве процесса говорят следующие метрики:

• статический анализ релиза (количество ошибок в коде, front-end'е; рекомендуем использовать следующие стандарты и инструменты: PSR-2, EcgM2, ESLint, W3C, PageSpeed);
  
  
• отчёты JavaScript о количестве ошибок + LogReport;
  
  
• APM типовые vs аномалии (это трейсеры, которые показывают (в миллисекундах), как работает каждый участок кода (нормально или с отклонениями), и на которых можно «провалиться» внутрь, чтобы проанализировать причины аномалий);

• ошибки 404, 500 и т. д. в динамике;

• метрики, которые уникальны для конкретной CMS;
  

• культура в релизах (частота релизов, соответствие графику, количество ошибок в них);
  

• результаты аудитов (их нужно проводить регулярно, например раз в месяц).

Эти метрики можно объединить одним понятием: технический долг.

Проблема в том, что чаще всего руководство компании-заказчика смотрит только на итоговый результат и не знает о реальном техническом состоянии проекта. Основная причина этого в том, что подрядчики не делают отчёты о качестве, и проект получается «непрозрачным». А значит, клиент не знает всех рисков и не может транслировать это своим инвесторам. Это приводит к тому, что бизнес-модель проекта не учитывает всех ограничений, а трудовые и финансовые затраты на обработку технического долга проекта не планируются заранее.

Технический долг

Технический долг — метафора, означающая все накопленные в IT-проекте проблемы, которые могут быть исправлены. Долг не всегда говорит о плохой работе разработчиков. Обычно он появляется при работе в условиях жёстких ограничений: либо по срокам, либо по бюджету. А так как в бизнесе ограничения есть всегда, то и технический долг есть всегда; его можно отслеживать, контролировать, уменьшать, но нельзя полностью устранить.

‍

«Например, мы работали с крупным e-Commerce-клиентом, который просто не успел вовремя оплатить хостинг, а проект „горел“, и пришлось сделать ему некрасивое решение на кластере (перестроить на менее „красивый“ Docker). Мы говорим заказчику: „Здесь есть технический долг, зато успели в срок. Давайте, когда будет пройден пик сезона, переделаем это решение“. Другой кейс: код замечательно работал, но разработчики заметили аномалии в производительности. Это значит, что где-то было применено неоптимальное решение (возник технический долг). Почему так происходит? Значит, были ограничения по срокам или по бюджету. Необходимо переделать».

‍

‍

‍

‍

‍

‍

‍

‍

‍

Главное с техническим долгом: оцифровать его (оценить масштаб) и запланировать работы по его уменьшению.

Работа по оцифровке качества проекта (технического долга) включает:

1. сбор параметров производительности через apminvest.com, newrelic.com, AppDynamics; мы под такими параметрами понимаем время ответа сервера и коллекцию трейсов приложений хотя бы за последние 24 часа;

2. очередь задач в разработке и решённых на сегодня;

3. мониторинг количества ошибок — от ошибок статического анализа до ошибок на сервере;

4. мониторинг ошибок пользователей и сообщений об ошибках от кол-центра (если есть кол-центр или горячая линия техподдержки);

5. контроль количества соблюдаемых процедур (процессов).

Дополнительно оцифровать технический долг помогают и бизнесовые показатели:

• сообщения от операторов (#ошибка #не_подтверждено #подтверждено) в день;
  
  
• отменённые заказы за день;
  
  
• аномалии по заказам в день (отклонения от нормы по времени, сумме среднего чека и т. п.);
  
  
• закрытые задачи за день.

Для контроля и управления производительностью сайтов существуют специальные инструменты: системы мониторинга производительности приложений APM (application performance monitoring).

Сервисы APM

Самая известная APM-система в мире — это New Relic. Она предоставляет следующие показатели производительности:

• время отклика, пропускная способность, частота ошибок и т. д.;
  
  
• выполнение внешних услуг;
  
  
• самые трудоёмкие транзакции;

• трассировка кросс-приложений;
  

• срыв транзакции;
  

• анализ развёртывания, история и сравнение.

Её минусы — высокая цена и невозможность тонкой настройки (есть «коробочное» решение, общее для всех).

‍

‍

«В kt.team мы пользуемся собственным продуктом, который заменяет New Relic и даёт нам более широкие возможности: APMinvest. Эта система удобна не только для управления качеством, но и для аудита технического состояния сайта (в том числе оцифровки технического долга). Поскольку главная цель бизнеса — это прибыль, было бы неплохо сразу видеть влияние технических показателей на финансы, в режиме реального времени, и как можно более наглядно — в виде понятной аналитической панели, дэшборда (англ. dashboard). Это также реализовано в APMinvest».

‍

‍

‍

‍

‍

‍

‍

‍

‍

Примеры вопросов, на которые может ответить APMinvest

1. Какое реальное время работы сервера? Когда наблюдаются проблемы в скорости работы? Совпадают ли просадки работы сервера с пиком активности вашей аудитории? Как это отражается на конверсии?

2. Мониторинг PageSpeed score: как влияет скорость загрузки на доход вашей компании? Какова текущая степень оптимизации вашего проекта?

3. Как после каждого релиза изменяются показатели статического анализа, количество ошибок в логах, данные из Google Analytics или вашей CRM?

4. Настроить параметры дэшборда можно под конкретный запрос, чтобы учесть любые взаимосвязи технических и бизнес-показателей. Это очень удобно и ставит работу айтишников под полный объективный контроль менеджмента.

‍

Что это даёт заказчику?

Быстрое обнаружение ошибок.

Повышение качества разработки: снижение количества ошибок, уменьшение технического долга, снижение рисков плохой работы сайта после обновлений.

Полную диагностику проекта на предмет «хронических» ошибок и технического долга, мешающих эффективному функционированию платформы.

Контроль состояния проекта, быстрые уведомления о том, что важно знать. В «Телеграме» создаётся чат-бот проекта, куда попадают сообщения обо всех ошибках, и ошибки группируются по типам.

Общий язык для постановки задач, понятный всем сотрудникам и повышающий эффективность работы команды.

Разработку в спокойном и эффективном темпе.

Итоговые рекомендации по контролю эффективности разработки

Качество разработки нужно контролировать, чтобы не допускать убытков и экономить ресурсы. Делать это легко: есть специальные сервисы для мониторинга производительности приложений (New Relic, APMinvest и другие). Используйте их в своих проектах.

Кстати, все клиенты kt.team получают доступ к APMinvest. Причина? Это помогает нам делать работу максимально качественно. Клиенты видят, что проект прозрачен, и это повышает их доверие; разработчики видят, что результаты каждого действия на виду, и более ответственно выполняют задачи; техническая команда со стороны заказчика говорит на одном языке с командой разработчиков, потому что ещё «на берегу» они договариваются о том, за какими метриками будут следить и какие значения будут считать нормой.

Чтобы узнать больше об APMinvest, задайте вопрос в комментариях — мы обязательно ответим в течение рабочего дня.

‍