Поиск надежного каппера – задача не из легких. На этом пути могут встретиться как действительно профессиональные аналитики, так и мошенники, обещающие золотые горы. Важно тщательно выбирать каналы, опираясь на отзывы других пользователей и статистику прогнозов. Интересный ресурс в этом контексте – https://kappery-telegramm.ru/, где собраны рейтинги капперов и полезные советы по выбору надежных источников прогнозов.
Качество ПО (в дальнейшем по тексту просто «качество») – это сложная интегральная функция, зависящая от времени. Качество характеризуется удовлетворенностью потребителя и производителя. Качество можно считать положительным или оно может стремиться к бесконечности, если средний потребитель ПО удовлетворен им «сегодня», «завтра» и «послезавтра», а производитель получает постоянный рост чистой прибыли. Т.е. качество можно измерять в деньгах. Часто можно опускать рост прибыли, поскольку между прибылью и удовлетворенностью потребителя есть прямая зависимость.
За качество ответственен менеджер проекта. Его задача вырабатывать стратегию постоянного роста качества и её превентивно выполнять. Непонимание этого особенно на ранних этапах (неопытными менеджерами) создаёт огромные негативные последствия (конкретно убытки) на поздних этапах. Качество – это требование любого проекта, которое подразумевается по умолчанию и не прописывается в контрактах.
Качество не обеспечивается только тестированием, дизайном или код ревью и т.п. В некоторых случаях, оно может быть ухудшено тестированием, если QA инженер будет находить несущественные дефекты. Например, тестировать hotswap sd карты, если в реальном use-case-е невозможно вытащить карту памяти без выключения устройства. Исправление таких дефектов может усложнить архитектуру, и таким образом, потенциально внести новые проблемы (понизить качество). Другой пример: в тестирование можно вкладывать бесконечное количество денег и при этом не обеспечивать качество, поскольку известно, что усилия на нахождение каждого следующего дефекта возрастают.
Качество ПО не равняется его надёжности. Надёжность – это необходимое требование к вообще именованию ПО «качественным». Если ПО выполняет функцию со 100% надёжностью (без каких либо сбоев сколь угодно длительное время), но при этом не удовлетворяет потребителя (работает медленно, создаёт издержки и т.п.), то ПО — некачественное. Использование надёжности как единственной метрики качества – это типичная ошибка начинающего менеджера. (Примечание. В моей практике встречались проекты ненадёжные, но очень популярные).
Качество одного и того же ПО «сегодня» может быть высокое, а «завтра» средним или даже плохим. Например, «завтра» изобретут новую технологию, и удовлетворенность потребителя резко упадёт в сравнении с продуктами конкурентов. Качество не абсолютно. В проектах скорость изменения качества (его улучшения) должна быть больше скорости его падения. В противном случае падение спроса и прибыли компании неизбежно. Побеждает тот, кто улучшает качество быстрее его естественной деградации, а ещё тот, кто делает это быстрее конкурентов.
В сложных проектах понимание уровня качества ПО может быть ложным или не полным. Чтобы понять следствия и причины низкого качества, нужно идти от потребителя до формирования требований и от требований до потребителя и искать причины не удовлетворённости и издержек. Качество ПО – это в т.ч. и функция процесса его создания. Глубокая специализация в компании уменьшает возможность понимания проблем качества. Например, QA инженер может считать что виноват в плохом качестве продукта только потому, что он не нашёл все дефекты на ранних этапах проекта, а их нашли конечные пользователи; в то время как сама сложность проекта или предметной области говорит, что обеспечить качество можно только при оригинальных совместных методиках тестирования ПО (в разработке которых должны участвовать все основные участники проекта). Хорошей практикой является проектирование архитектуры с позиции обеспечения её качества, т.е. Test driven Design.
Вклад этапов жизненного цикла ПО в качество меняется вместе со зрелостью проекта. В ранних версиях продукта, проверка покрытия требований тестами играет основную роль. В следующих версиях вклад в тестирование может резко понизиться и повышение качества возможно только путём учёта пользовательского мнения, редизайна системы, автоматизации тестирования и т.п. Или путём тщательного переосмысливания продукта, требований и архитектуры. Участники проекта и менеджер должны «предсказывать» влияние тех или иных решений на обеспечение качества. Требования должны учитывать сложности архитектуры, архитектура — сложности дальнейшего масштабирования и тестирования и т.д. В целом, чем более зрелый проект, тем серьёзней нужно подходить к его проблемам. На их понимание может уходить не один месяц.
Нужно понимать, что у улучшения качества есть своя цена и для компании и проектов она может быть «непосильной». При катастрофическом падении качества и убытках менеджер должен принять решение о закрытии проекта и/или старте нового подобного проекта с более высоким качеством на основе полученных уроков.
Качество обычно идёт в ряду противопоставления: качество-скорость ПО, качество-стоимость, качество-время выполнения проекта. Либо будет работать быстро, либо качественно. Либо будет дорого, либо с низким качеством и т.п. Либо быстрая реализация, либо качественная. Задача менеджера проекта найти «золотую» середину между этими гранями. Если менеджер проекта не укладывается в график проекта, то типовыми краткосрочными решениями для ускорения проекта будут: уменьшение качества, либо уменьшение фичасета и др.
Чем сильнее система масштабируется (миллионы пользователей, миллионы устройств, серверов и т.п.), тем быстрее вскрываются проблемы качества и тем ощутимей последствия низкого качества (резкое возрастание количества дефектов, возвраты, вплоть до закрытия проекта, предприятия и т.п.).
Примеры метрик для измерения качества:
- количество пользователей и их удовлетворенность продуктом;
- степень грамотности менеджмента: планирование, бюджетирование и выполнение проекта (т.е. сходимость проекта по срокам и цене, рентабельность проекта);
- количество требований и подход к их управлению;
- количество дефектов и цена исправления дефекта;
- цена добавления новой функциональности (сложность архитектуры);
- качество кода: локальное (на уровне компонента, библиотеки, модуля) и интегральное в виде архитектуры, наличие unit test-ов;
- количество тестов (и степень их автоматизации и наличия всех необходимых видов тестирования), величина покрытия;
- количество «кликов» (usability, UI design, интуитивность, интеллектуальность) и скорость работы ПО;
- надёжность (частота сбоев и т.п.);
- затраты времени на интеграцию исправления, время от интеграции до релиза (configuration management, continuous integration и т.п.);
- степень автоматизации процессов организации.
В конечном счете, успех проекта зависит от знания практик, от умения их применять в необходимом объёме, от понимания интегральной сущности качества ПО и от способности предвидеть проблемы с качеством и принятия превентивных мер.