Меня зовут Андрей Ларин, я представляю компанию Корус Консалтинг. Мой опыт в проектировании и внедрении высоконагруженных систем в крупных компаниях – более 15 лет. Я руковожу подразделением, в котором работает около 200 экспертов и реализовано более 90 успешных внедрений крупных проектов.
Сегодня мы поговорим об ожиданиях клиентов от проекта – рассмотрю эту тему через призму тестирования.
Один из ключевых трендов последних лет – импортозамещение. Мы активно участвуем в проектах перехода с западного ПО на отечественные решения, в первую очередь – на платформу 1С.
В чем наша экспертиза? Мы проектируем бизнес-архитектуру, разрабатываем технические задания, методики тестирования, занимаемся системами класса ERP и управлением ресурсами. Наша задача – проектировать и интегрировать сложные, высоконагруженные системы в существующий IT-ландшафт крупных холдингов.
Отдельно хочу выделить компетенцию в области управления данными и автоматизации тестирования – как функционального, так и нагрузочного. Именно эти направления особенно востребованы при миграции с иностранного ПО на российские аналоги.
Ожидания клиента от результатов проекта
Для большинства очевидно: основные ожидания клиента связаны с функциональностью и производительностью. Заказчик заранее формулирует требования – например, количество одновременно работающих пользователей, время формирования отчетов или выполнения критических операций. С такими явными ожиданиями можно четко спланировать работы, ресурсы и сроки.
Но что насчет скрытых ожиданий? Уверен, те, кто занимался внедрением проектов, скажут: они неизбежны. Чаще всего такие ожидания проявляются на этапе опытной эксплуатации или при приемочных испытаниях – уже в самом конце проекта. В этот момент могут всплыть новые требования или дополнительные условия, которых не было в изначальном ТЗ. Это может привести либо к остановке проекта, либо – что более типично – к незапланированным затратам. А найти квалифицированных специалистов, способных оперативно закрыть такие запросы, зачастую крайне сложно.
От требований ИТ-проекта к тестированию
Если обратиться к ГОСТу, к методологиям корпоративного внедрения от 1С или другим отраслевым стандартам, можно увидеть типовую структуру технического задания, особенно в части требований к системе. Обычно она включает множество разделов, посвященных как функциональным, так и нефункциональным требованиям.
Я выделил жирным те разделы, которые соответствуют явным ожиданиям клиента – в первую очередь, это требования к производительности. Причем формулировка этих требований зависит от того, насколько четко заказчик может их описать.
Что касается функциональных требований – бывает, ТЗ состоит из ста листов, а бывает – всего из одной страницы. И речь идет об ERP-системах, где сложность и масштаб проекта требуют особого внимания к деталям.
А вот все остальные разделы – это потенциальные источники скрытых ожиданий. Дело в том, что и заказчик, и подрядчик часто воспринимают некоторые аспекты как само собой разумеющиеся. Подрядчик может просто не обратить внимания на отдельные пункты, а клиент – не прописать их явно.
И тогда на этапе опытной эксплуатации или приемочных испытаний всплывают новые требования. Это создает риски: задержки, дополнительные затраты, конфликты.
Таким образом, ожидания клиента формируются не только наличием тех или иных требований, но и характеристиками качества этих требований. Я привел примеры характеристик из ГОСТ 28195-89 (ISO/IEC 9126), которые описывают качество программного обеспечения: функциональность, надежность, производительность, удобство использования и т.д.
Каждое требование должно оцениваться не только с точки зрения «есть – нет», но и с позиции качества его реализации.
Вывод: типовое ТЗ – это не просто документ, а источник как явных, так и скрытых ожиданий клиента. То, что заказчик предоставляет – это явные ожидания. А скрытые «спрятаны» в недописанных, неформализованных или неоцененных разделах.
Поэтому обсуждать проект с заказчиком нужно не только о наличии требований, но и о характеристиках их качества. И здесь на помощь приходит тестирование – в самом широком смысле.
Тестирование как инструмент выявления ожиданий клиента
Тестирование – это не просто проверка соответствия, но и способ оценить качество реализации требований, их полноту, непротиворечивость, реализуемость. Например, такие характеристики, как функциональная пригодность, полнота покрытия потребностей, надежность – все это можно проверить и оценить еще до старта проекта.
Давайте посмотрим на типовую структуру проекта во внедрении в крупных компаниях. Она включает две ключевые фазы: доинвестиционную (пресейл) и инвестиционную (внедрение). На этапе пресейла большинство ожиданий клиента еще остаются скрытыми. Именно здесь наша задача – выявить их как можно раньше. И один из эффективных инструментов для этого – тестирование на этапе пресейла.
Обычно мы тестируем требования уже в рамках проекта: проверяем их полноту, непротиворечивость, покрытие бизнес-потребностей. Но есть и более целенаправленные виды тестирования. Например, узконаправленное тестирование критических функций – таких, как расчет себестоимости, управление запасами или финансовая отчетность. Это – санитарное тестирование требований.
Проводя такое тестирование, мы можем оценить глубину функциональных разрывов и понять, насколько текущее решение покрывает ключевые бизнес-потребности заказчика.
Также важно тестирование совместимости. Даже на этапе пресейла нужно понимать, как новая система будет интегрироваться в существующий IT-ландшафт клиента: с каким ПО она должна взаимодействовать, на каких платформах будет работать, какие есть ограничения.
Особенно это актуально для композитных систем, состоящих из нескольких компонентов на разных технологических платформах. Совместимость между ними – критически важный фактор.
Кроме того, в крупных компаниях часто требуют предоставить результаты нагрузочного тестирования – либо провести его на этапе пресейла, чтобы подтвердить, что система соответствует заявленным характеристикам производительности.
Виды тестирования на разных этапах проекта
На рисунках ниже вы видите типовую структуру этапов крупного корпоративного проекта. Для каждого этапа я выделил явные и скрытые ожидания клиента.
Явные ожидания – это те области, которые заказчик четко формулирует, обсуждает с подрядчиком и ожидает, что по ним будут выполняться работы.
Скрытые ожидания – это аспекты, которые клиент не озвучивает напрямую, но которые тем не менее важны для него. Мы все равно выполняем по ним часть работ, но в идеале – лучше выявить их заранее и включить в проектную повестку.
Проектирование. На этапе проектирования особенно важно тестирование миграции.
Миграция – отдельная и сложная тема. В первоначальных технических заданиях заказчики редко прописывают детальные требования к миграции. Обычно они либо не упоминаются, либо описаны поверхностно. А между тем, это может быть огромный объем работ – особенно при переходе с таких систем, как SAP или Oracle. Структуры данных, логика, архитектура – все совершенно разное. Чтобы корректно перенести данные и адаптировать их под новую платформу, нужно не только глубоко разобраться в контексте, но и разработать инструменты миграции, провести тестовые и полноценные миграции. И это – без учета качества данных. Как правило, оно оставляет желать лучшего: дубли, пробелы, несогласованные справочники.
Поэтому тему миграции необходимо обсуждать с заказчиком на ранних стадиях, четко разграничивать зоны ответственности и включать в план проекта.
Еще один важный, но часто недооцениваемый аспект – пользовательский интерфейс и удобство использования. Формально эти требования не влияют на функциональность или выполнение бизнес-процессов. Но на практике это критично для пользователя. Игнорирование этого аспекта может привести к дополнительным трудозатратам уже на этапе опытной эксплуатации.
Приведу пример: на одном из проектов клиент на этапе приемки указал на пункт в ТЗ: «Система должна соответствовать цветовой гамме брендбука компании». В итоге весь желтый интерфейс пришлось перекрашивать в фирменные голубые тона, а логотип 1С – убирать везде, где это возможно. Это – типичная конфликтная ситуация, которая могла быть предотвращена при более глубоком обсуждении скрытых ожиданий.
Создание решения. На этом этапе важно тестирование требований. Ведь при реализации мы сами уточняем, интерпретируем и иногда даже генерируем новые требования – уже с точки зрения технической реализации. Поэтому критически важно проверять требования на полноту, реализуемость и непротиворечивость.
Также остаются актуальными:
-
Тестирование миграции,
-
Оценка пользовательского интерфейса,
-
Проверка нефункциональных требований.
Особое внимание – трем ключевым видам тестирования:
-
Регрессионное,
-
Дымовое,
-
Верификация сборки.
А также различным видам нагрузочного тестирования.
Да, заказчик может сформулировать базовые требования к производительности – например, количество пользователей или время отклика. Но редко кто задумывается о стабильности системы при пиковых нагрузках, масштабируемости, восстановлении после сбоев. А между тем именно тесты максимальной нагрузки и сценарии стресс-тестирования позволяют выявить эти риски.
Профили нагрузки и сценарии тестирования стоит обсуждать на самых ранних стадиях проекта. Автоматизация регрессионного, дымового и функционального тестирования напрямую влияет на качество реализации требований и снижает риски в дальнейшем.
Кроме того, результаты этих тестов могут быть полезны заказчику и в период эксплуатации – для мониторинга производительности, при обновлениях, при масштабировании.
Поэтому эту тему важно поднимать заранее.
Подготовка к опытной эксплуатации. На этом этапе клиент ожидает, что все заявленные требования не просто реализованы, но и подтверждены тестами с указанием конкретных параметров качества.
Здесь вновь актуальны:
-
Тестирование требований,
-
Миграция,
-
Пользовательский интерфейс.
Опытная эксплуатация. Это, по сути, бета-тестирование и приемочные испытания. Именно здесь появляется основной поток дополнительных требований, которые нужно:
-
классифицировать,
-
оценить на соответствие проектным целям,
-
проверить на полноту, покрытие и встраиваемость в текущий объем проекта.
Это серьезная работа, требующая системного подхода.
Обратите внимание: на всех этапах после создания решения повторяются одни и те же виды тестирования – функциональные (регресс, дым, верификация) и нагрузочные. Это говорит о том, что их целесообразно автоматизировать.
Да, автоматизация – это дополнительные ресурсы. Особенно функциональное тестирование. Писать автотесты – дорого и трудоемко.
Но у нас есть наработки, которые позволяют внедрять автоматизацию с оптимальными затратами, интегрировать ее в производственный цикл проекта. Да, ресурсов потребуется больше. Но качество проекта при этом существенно возрастает, а риски – снижаются.
Передача в промышленную эксплуатацию и поддержка. На финальных этапах остаются ключевые виды тестирования:
-
Тестирование требований,
-
Функциональное тестирование,
-
Нагрузочное тестирование.
Они необходимы для обеспечения стабильности системы в долгосрочной перспективе.
Как выявить скрытые ожидания клиента от результатов проекта
Подводя итог, можно сказать: явные ожидания позволяют четко спланировать проект – определить сроки, ресурсы, бюджет. Но скрытые ожидания тоже существуют. И они, как правило, сконцентрированы в следующих областях:
– Нефункциональные требования – часто недостаточно прописаны или вообще отсутствуют в ТЗ, но критичны для успешного завершения проекта.
– Функциональные требования – здесь важно не просто следовать документу, а глубоко понимать бизнес-архитектуру заказчика, чтобы выявить неозвученные, но важные требования к процессам.
Что касается производительности: у заказчика может быть одно формальное требование – например, «1000 пользователей». Но на деле его ожидания гораздо шире: стабильность системы под нагрузкой, поведение при пиковых нагрузках, масштабируемость. Просто он не может это четко сформулировать.
По удобству использования и пользовательскому интерфейсу – формально это не функциональная критичность, но эмоционально – очень болезненный вопрос. Игнорирование этого аспекта может привести к недовольству, переделкам и конфликтам на финальных этапах.
Особое внимание стоит уделить миграции данных и совместимости систем. Эти области – частые источники скрытых ожиданий. И если они не проработаны заранее, это может привести к заморозке проекта на этапе опытной эксплуатации.
Соответственно, если мы будем системно выявлять и обсуждать эти аспекты на ранних стадиях, договариваться с заказчиком, согласовывать зоны ответственности – мы сможем существенно снизить риски.
Еще один важный вывод: в ТЗ, особенно в разделах нефункциональных требований, часто содержатся пункты, на которые подрядчик не обращает должного внимания. А заказчик при этом считает их само собой разумеющимися.
Например:
– Сопровождаемость системы,
– Локализация,
– Поддержка пользователей,
– Интеграция с внутренними сервисами.
Приведу пример: прямо сейчас у нас идет пресейл, и в разделе «Требования к технической поддержке» мелким шрифтом написано: «Должен быть реализован чат-бот для автоматической поддержки пользователей». Это, на первый взгляд, незначительное требование – но на деле оно может повлечь значительные трудозатраты на этапе опытной эксплуатации, если не было учтено заранее.
Поэтому – внимательно изучайте все разделы ТЗ, особенно нефункциональные. И, конечно, регулярное тестирование и автоматизация – как функционального, так и нагрузочного тестирования – позволяют не только выявлять скрытые ожидания, но и повышать общее качество проекта.
Все это имеет смысл обсуждать уже на ранних этапах.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
