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

25.10.2019

Содержание

Рассмотрим основные метрики и полезный сервис для контроля и управления качеством проекта.

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

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

Сервисы APM

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

Redirector

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

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

Как контролировать 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

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

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

  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», — Андрей Путин, Генеральный директор kt.team

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

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

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

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

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

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

  • Быстрое обнаружение ошибок.
  • Повышение качества разработки: снижение количества ошибок, уменьшение технического долга, снижение рисков плохой работы сайта после обновлений.
  • Полную диагностику проекта на предмет «хронических» ошибок и технического долга, мешающих эффективному функционированию платформы.
  • Контроль состояния проекта, быстрые уведомления о том, что важно знать. В «Телеграме» создаётся чат-бот проекта, куда попадают сообщения обо всех ошибках, и ошибки группируются по типам.
  • Общий язык для постановки задач, понятный всем сотрудникам и повышающий эффективность работы команды.
  • Разработку в спокойном и эффективном темпе.

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

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

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

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

Другие статьи

Смотреть все

Почему работающая микросервисная архитектура начинается с порядка в бизнес-процессах

Подробнее

Сервисная шина как эволюционное преимущество для развития компании

Подробнее

EDI как базовая система для электронного обмена данными и интеграций с партнёрами

Подробнее

Смотреть все

Мы используем файлы cookie, чтобы предоставить наилучшие возможности сайта

Ок

Ваша заявка отправлена успешно

Отправить снова

Ready to help you with your project

You'll be contacted by your personal manager