Уже не раз слышала от заказчиков фразу «А как нам быть уверенным в том, что вы разработаете именно такую систему, которая нам нужна?». В статье я постараюсь подробно рассказать о фактах на проекте внедрения, которые этот вопрос снимают.
Что написано пером
В рамках проектов автоматизации разрабатываются документы:
- Техническое задание. Это укрупненное видение будущего проекта. Составляется либо заказчиком, либо специалистами Исполнителя после проведенного экспресс-анализа. Содержит наименование и цели работ, требования к системе, а также зафиксированный порядок выполнения и результат работ. Грамотно составленное Техническое задание – половина успеха проекта.
- Проектные решения. Документ содержит детальное описание бизнес-процессов с указанием действующих лиц и закрепленных за ними функций. Для удобства восприятия описание может быть дополнено схемами (как правило, в формате BPMN). Данный документ позволяет увидеть будущую систему «сверху» и оценить, насколько она соответствует выдвинутым требованиям.
- Технический проект. Описывает внутренности системы. Содержит информацию о необходимых модификациях, об интеграции с другими системами, а также о конвертации данных. Документ предназначен для ИТ-специалистов, которые смогут оценить предстоящий объем работ и представить встраивание новой системы в уже существующую инфраструктуру.
Благодаря этим документам заказчик может быть уверен, что все, что зафиксировано, будет реализовано. Это ли не уверенность в том, что система будет именной той, которая нужна?
Семь раз отмерь
После того, как проектные документы согласованы и модификации выполнены, наступает этап ввода системы в эксплуатацию. В случае если заказчик в системе не до конца уверен и не готов пускать ее в массы не опробовав, проводится тестовая эксплуатация. Как это происходит:
- Составляется список ключевых специалистов. Обычно это специалисты, участвующие в проекте с самого начала. Те, кто на этапе исследования рассказывал о своих рабочих функциях и проблемах, возникающих при их выполнении. Они же зачастую принимают участие и в согласовании проектных решений. Для каждого бизнес-процесса выделяется 1-2 специалиста.
- Далее ключевые специалисты в тестовом режиме обкатывают процессы, тем самым примеряя систему на себя. Рассматриваются как рядовые ситуации, так и нестандартные.
- По итогам проведения оформляется список замечаний, которые реализовываются перед вводом системы в опытную эксплуатацию.
- После исправления замечаний процессы еще раз прогоняются для полной уверенности, что они доведены до ума.
Моя практика показывает, что этап тестовой эксплуатации особенно полезен для систем, сильно модифицируемых под заказчика. Он позволяет пользователям пощупать систему, реально оценить ее на соответствие своим ожиданиям и высказать замечания. Это ли не уверенность в том, что система разрабатывается именно та, которая нужна?
За что боролись
После тестовой эксплуатации система переходит в режим опытной эксплуатации, где каждый рядовой пользователь может опробовать ее на себе. На этом этапе в основном реализовываются пожелания, влияющие на удобство использования системы.
Надо понимать, что совершенствовать систему можно до бесконечности, и каждый проект имеет свои бюджет и сроки. Тут главное не переусердствовать. На выходе получаем систему, покрывающую оговоренные требования заказчика и соответствующую результату, зафиксированному в Техническом задании. Это ли не уверенность в том, что система получилась именной той, которую хотели?
На мой взгляд, я предоставила достаточно фактов, которые снимают вопрос из заголовка. Как видно, компания разработчик реализовывает ровно то, что пожелал заказчик. Именно поэтому требования должны быть максимально детализированы, чтобы минимизировать свободу действий, которая впоследствии может сказаться как раз таки на несоответствии первоначальным ожиданиям. Правильное формулирование требований – одно из направлений консалтинга, но это уже совсем другая история.