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

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

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

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

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

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

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

О качестве процесса говорят следующие метрики:
  • статический анализ релиза (количество ошибок в коде, front-end'е; рекомендуем использовать следующие стандарты и инструменты: PSR-2, EcgM2, ESLint, W3C, PageSpeed);

  • отчёты JavaScript о количестве ошибок + LogReport;

  • APM типовые vs аномалии (это трейсеры, которые показывают (в миллисекундах), как работает каждый участок кода (нормально или с отклонениями), и на которых можно «провалиться» внутрь, чтобы проанализировать причины аномалий);

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

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

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

  • результаты аудитов (их нужно проводить регулярно, например раз в месяц).
Эти метрики можно объединить одним понятием: технический долг.

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

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

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

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

Работа по оцифровке качества проекта (технического долга) включает:
1
сбор параметров производительности через apminvest.com, newrelic.com, AppDynamics; мы под такими параметрами понимаем время ответа сервера и коллекцию трейсов приложений хотя бы за последние 24 часа;
2
очередь задач в разработке и решённых на сегодня;
3
мониторинг количества ошибок — от ошибок статического анализа до ошибок на сервере;
4
мониторинг ошибок пользователей и сообщений об ошибках от кол-центра (если есть кол-центр или горячая линия техподдержки);
5
контроль количества соблюдаемых процедур (процессов).
Дополнительно оцифровать технический долг помогают и бизнесовые показатели:
  • сообщения от операторов (#ошибка #не_подтверждено #подтверждено) в день;

  • отменённые заказы за день;

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

  • закрытые задачи за день.
Для контроля и управления производительностью сайтов существуют специальные инструменты: системы мониторинга производительности приложений APM (application performance monitoring).
Сервисы APM
Самая известная APM-система в мире — это New Relic. Она предоставляет следующие показатели производительности:
  • время отклика, пропускная способность, частота ошибок и т. д.;

  • выполнение внешних услуг;

  • самые трудоёмкие транзакции;

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

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

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

Андрей
Генеральный директор kt.team
«В kt.team мы пользуемся собственным продуктом, который заменяет New Relic и даёт нам более широкие возможности: APMinvest. Эта система удобна не только для управления качеством, но и для аудита технического состояния сайта (в том числе оцифровки технического долга). Поскольку главная цель бизнеса — это прибыль, было бы неплохо сразу видеть влияние технических показателей на финансы, в режиме реального времени, и как можно более наглядно — в виде понятной аналитической панели, дэшборда (англ. dashboard). Это также реализовано в APMinvest».
Примеры вопросов, на которые может ответить APMinvest
1
Какое реальное время работы сервера? Когда наблюдаются проблемы в скорости работы? Совпадают ли просадки работы сервера с пиком активности вашей аудитории? Как это отражается на конверсии?
2
Мониторинг PageSpeed score: как влияет скорость загрузки на доход вашей компании? Какова текущая степень оптимизации вашего проекта?
3
Как после каждого релиза изменяются показатели статического анализа, количество ошибок в логах, данные из Google Analytics или вашей CRM?
4
Настроить параметры дэшборда можно под конкретный запрос, чтобы учесть любые взаимосвязи технических и бизнес-показателей. Это очень удобно и ставит работу айтишников под полный объективный контроль менеджмента.
Что это даёт заказчику?
Быстрое обнаружение ошибок.

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

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

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

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

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

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

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

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

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

Поделиться

Хотите больше полезных материалов?
Подпишитесь на нашу новостную рассылку!

Новости мира разработки и дизайна, переводы статей, наши новые кейсы. Пишем просто о сложном, без рекламы и спама.
Остались вопросы?
Вы можете обсудить любые вопросы по своему IT-проекту с нашим экспертом.
Error get alias
Получить консультацию
Читайте также:

Нравится статья?
Укажите свою почту, и мы будем присылать вам еженедельный анонс
новых статей.