Спросите десять заказчиков, что такое качественная система, и девять ответят одно и то же: «Чтобы не было багов». Это понятный ответ, но он примерно такой же полный, как определение хорошего автомобиля словами «чтобы не ломался». Машина, которая не ломается, но разгоняется до сотни за минуту, расходует сорок литров и в которой невозможно сидеть дольше часа, вряд ли кто-то назовёт качественной. С программными системами то же самое. Отсутствие ошибок это лишь одна грань качества, и далеко не всегда самая важная.
Качество многомерно
Инженеры давно поняли, что качество нельзя описать одним словом, и разложили его на характеристики. Есть международный стандарт ISO/IEC 25010, который делает это довольно подробно. Я не буду пересказывать стандарт целиком, это скучно даже для меня. Но знать основные характеристики полезно каждому, кто заказывает или принимает систему, потому что каждая из них стоит денег, и про каждую нужно договориться заранее.
Требование к качеству, о котором не договорились, будет выполнено так, как удобно исполнителю. И это не злой умысел, это физика проектов.
Основные характеристики
Вот те, о которых я обязательно говорю с клиентами на этапе проектирования, и почему.
- Функциональная пригодность: система делает то, что нужно бизнесу, полностью и правильно. Это база, без неё остальное не имеет смысла.
- Производительность: как быстро система отвечает и сколько пользователей и операций выдерживает одновременно. Страница, которая открывается пять секунд, формально работает, но сотрудники будут её ненавидеть.
- Надёжность: как долго система работает без сбоев, как быстро восстанавливается после них, теряет ли данные при аварии.
- Удобство использования: насколько легко новому человеку освоить систему и насколько быстро опытный выполняет в ней ежедневные задачи.
- Безопасность: защищены ли данные, видит ли каждый только то, что ему положено, остаются ли следы действий.
- Сопровождаемость: насколько быстро и безопасно можно вносить изменения в систему. Это характеристика, которую заказчики почти никогда не называют, и которая сильнее всего влияет на стоимость владения.
- Совместимость и переносимость: умеет ли система обмениваться данными с другими программами и можно ли перенести её на другой сервер или в другое окружение без героизма.
Невидимые требования, о которых забывают
Обратите внимание: функциональные требования, то есть что система делает, заказчики описывают охотно и подробно. А вот требования к качеству, то есть как хорошо она это делает, почти всегда остаются за кадром. Их не видно в макетах, о них не спорят на презентациях, и поэтому они всплывают позже, в самый неприятный момент.
Типичная история: систему сдали, всё работает, все довольны. Через полгода в базе накопилось сто тысяч заказов, и отчёт, который раньше строился за секунду, теперь строится три минуты. Ошибки нет, функция работает. Но требование к производительности никто не формулировал, поэтому никто его и не проверял. Или другая история: нужно добавить новое поле в карточку клиента, а подрядчик оценивает это в две недели, потому что система написана так, что любое изменение тянет за собой десятки правок. Требование к сопровождаемости тоже никто не формулировал.
Как описать требования так, чтобы их можно было проверить
Главное правило: требование к качеству должно быть измеримым. «Система должна работать быстро» это пожелание, а не требование. «Основные экраны открываются не дольше двух секунд при пятидесяти одновременных пользователях» это требование, которое можно проверить на приёмке. «Система должна быть надёжной» это пожелание. «Плановая недоступность не более часа в месяц, резервная копия данных не старше суток» это требование.
Второе правило: не требуйте максимума во всём. Каждая характеристика стоит денег, и некоторые из них конкурируют друг с другом. Максимальная безопасность часто снижает удобство. Максимальная производительность может усложнить код и ухудшить сопровождаемость. Внутренней системе на двадцать сотрудников не нужна отказоустойчивость банка. Расставьте приоритеты: что для Вашего бизнеса критично, что важно, а что достаточно на приемлемом уровне.
Третье: проверяйте не только на старте. Требования к качеству нужно проверять регулярно, особенно производительность и надёжность, потому что они меняются по мере роста данных и нагрузки. Хорошая система сама следит за своими показателями и сообщает, когда они начинают выходить за рамки.
Что делать завтра
Если Вы заказываете систему, добавьте в техническое задание отдельный раздел о требованиях к качеству. Пройдитесь по списку характеристик выше и для каждой ответьте на вопрос: что будет, если здесь окажется плохо? Где ответ «потеряем деньги или клиентов», сформулируйте измеримое требование. Где ответ «ничего страшного», оставьте на усмотрение исполнителя.
Если система у Вас уже есть, проведите простой аудит: замерьте скорость ключевых экранов, проверьте, когда последний раз делалась резервная копия и пробовали ли из неё восстановиться, спросите команду, сколько стоит добавить простое поле. Ответы многое скажут о реальном качестве. В Systems мы закладываем требования к качеству в проект с первого этапа и проверяем их на приёмке так же строго, как функции. Потому что система без багов, которой неудобно пользоваться и которую дорого менять, это не качество. Это просто отсутствие одного вида проблем.
