Почему важно выстроить контроль качества IT-продукта до первой строчки кода?

Обычно про контроль качества вспоминают на последних этапах разработки и очень зря. Гораздо важнее организовать систему управления качеством со старта. Сэкономите бюджет и нервные клетки.

Меня зовут Алимханов Тимур и я 12 лет занимаюсь менеджментом в IT-проектах. По личным наблюдениям, проектные команды часто не разделяют QC(Quality Control) и QA(Quality Assurance). Вот в чем дело: Quality control — это процесс проверки качества уже готового продукта, это заключительный этап разработки. При этом Quality Assurance, как подход основан на организации системы управления качеством с начала разработки.

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

Любой продукт неизбежно встраивается в экосистему. Это может быть компания или группа пользователей, со своими привычками, опытом и потребностями. Все это формирует контекст вокруг продукта. Можно идти против предпочтений аудитории, но тогда не надо удивляться, если проект провалится.

Кейс. Государственное ведомство попросило нас разместить на карте 65 тыс. социально важных объектов. Желание понятное, но загрузка этих объектов станет последним, что устройство пользователя сделает на этом Свете. Для работоспособности мы ввели AVL-tree. Технология позволила разместить сгруппированные по геолокации точки в зависимости от масштаба. Похожее решение можно увидеть в Суточно.ру и ЦИАНе.

Краха функционала удалось избежать, ведь наш аналитик вовремя заметил потенциальную проблему и на следующую встречу с клиентом мы вынесли вопрос отображения объектов.

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

Погружение в потребительские паттерны дает лучшее понимание целевой аудитории, повышает конкурентоспособность проекта и минимизирует риска. У продукта с 99,99% вероятностью будет несколько заметных конкурентов. Кому достанется аудитория — вопрос открытый. Однако понимание реальных потребностей пользователей повышает вероятность успешного захода на рынок.

У команды разработчиков и клиента могут отличаться представления о конечном виденье продукта. Чтобы не утонуть в бесконечных правках, лучше документально фиксировать реперные точки. Это поможет избежать откатов назад (но не защищает от них полностью). По крайней мере, у разработчиков будет веский довод в переговорах, ведь все ходы записаны.

Кейс. Опыт научил нас, что «страховочных тросов» много не бывает. Например, мы работали над проектом для Театра Российской Армии. Клиент настаивал на увеличении некоторых элементов в макете, а это ломало весь UX.

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

Бывает так: вроде и бюджет есть, проект полезный, заказчик мотивирован довести идею до релиза и в целом все заряжены. Вот только не покидает чувство, что что-то не так. Если одолевают сомнения, не стоит садиться писать ТЗ. Желательно посмотреть со стороны на весь проект, очертить его техническую составляющую, возможные планы по развитию на несколько лет вперед. Допускаю, что совет может показаться наивным, но это не отменяет его важность.

Кейс. Расскажу историю о разработке информационного портала для одного крупного московского ВУЗа – ГУУ. Клиент начинал разрабатывать портал, когда требования к нему были небольшие, естественно это был монолит. Сайт включал общую информацию и уставные документы. Постепенно функционал усложнялся — добавили расписание, систему контроля удаленного доступа, личные кабинеты студента, потом цифровизировали общежитие и даже библиотеку.

К чему все это привело? В один канал связи к монолиту идет поток информации: кому поставить лампочку и заменить розетку и у каких групп сменилось расписание. Естественно, портал не справлялся с нагрузкой. Допустим, заявка на лампочку идет с задержкой, не велика беда. А что насчет пропусков? Утром и вечером на проходной скапливалась очередь и вот это настоящая проблема.

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

Бывает, что заказчик знает чего хочет, однако перекладывает эту информацию в ТЗ не лучшим образом. Такая ситуация встречается часто. Если относиться к проекту с позиции простого исполнителя, то можно сделать как написано и формально исполнитель будет прав. Однако есть и другой сценарий — смотреть на задачу с позиции партнера и анализировать реальные потребности заказчика.

Моя позиция: команда разработки обязана любой ценой докопаться до UI и UX продукта. Это «бутылочное горлышко», в которое может упереться весь проект. Более того — на этапе обсуждения UI и UX наверняка всплывут неожиданные моменты, которые много расскажут о заказчике.

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

Оказалось, что в зоопарк постоянно звонили, телефонная линия буквально была перегружена. Поэтому убирать номер нельзя. Тогда мы решили узнать, а что именно интересует звонивших. Оказалось, что 90% звонков касалась времени работы зоопарка. Получается, вопрос не в доступности номера, а в том, что посетители не находят нужную им информацию.

Мы предложили клиенту следующее решение:

1. Убрать телефон из шапки сайта;

2. Вместо телефона разместить часы работы зоопарка;

3. Добавить на линию автоответчик, который бы информировал о времени работы.

Этого хватило, чтобы снизить нагрузку на линию на 95%! При этом человеческий ресурс вообще не задействован.

Вывод: пользовательский опыт, отраженный в практичном визуальном решении, не просто упрощает использование сайта. Грамотный UX снижает нагрузку на сервис и ускоряет решение задач потребителем. Поэтому на этапе проектирования должны закладываться основные сценарии, по которым после запуска работы производится анализ и оценка качества реализованного решения.

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

2. Часто придется думать наперед вместо заказчика. Сейчас он хочет просто сайт, а если через два года на базе проекта нужно будет сделать что-то сложнее? Может, подготовить фундамент под повышенную нагрузку сейчас?

3. Обязательно копайте в сторону UI и UX. Реакция клиента на эти решения много расскажет о скрытых потребностях. Как минимум, уточните детали проекта. Как максимум — убережете себя и клиента от ошибок.