Одной из наиболее трудных (но при этом и самой фундаментальной) задачей проектных групп SAP является определение точных и выполнимых требований к решению для определенной бизнес-цели. Рассмотрим следующий пример: представьте, что требуется написать алгоритм для проверки наличия дублированных счетов-фактур на определенном этапе процесса, например, при следующем вводе данных или в течение выполнения ночного фонового задания. Сразу возникают следующие вопросы: что именно заставляет нас полагать, что один счетфактура идентичен другому? Считать ли два счета идентичными при простом совпадении данных заказчика и общего количества или необходимо проверить идентичность каждого отдельного поля? А если все данные “совпадают”, а последовательность строк – нет? Зависят ли эти критерии от компании, отдела или пользователя (очень часто!)? Какие еще возможные ситуации не были учтены или продуманы?

К сожалению, приведенный выше пример взят из реальной жизни. Именно такое решение требовалось создать в рамках одного из последних проектов в SAP. Этот проект заставил нас пересмотреть подход к разработке приложений. Если говорить вкратце, на разработку решения было потрачено большое количество времени, а в результате мы лишь убедились, что оно не функционирует должным образом и требует значительных доработок¹. Причина: слишком поздно были обнаружено существенное расхождение между мнениям разработчиков и пользователей о том, какие счета являются “идентичными”. К тому же имела место серьезная недооценка масштабов задачи.

¹ Фактически, технология, выбранная для проведения анализа подобия (TREX), была основана на неполном представлении разработчиков о требованиях к решению. Впоследствии нам пришлось внепланово написать целый ряд подпрограмм поиска, что существенно расширило объем проекта, отодвинуло дату поставки и увеличило затраты. Если бы заранее были известны конкретные требования к решению, то, возможно, этой дополнительной работы удалось бы избежать.

В этой статье рассматривается альтернативный, итеративный подход к процессу сбора требований/проектирования приложения, который называется исследовательское моделирование (eXploratory Modelling, xM). Он успешно применялся в рамках последних проектов SAP. Данный подход направлен на преодоление извечной коммуникационной пропасти между разработчиками и пользователями за счет более интенсивного взаимодействия с предполагаемыми (и будущими) конечными пользователями и сокращения циклов анализа/проектирования для обеспечения мгновенной обратной связи и внесения корректировок в проект. Широко известен метод использования HTML-макетов для визуализации статических функциональных возможностей и шагов процесса. Основная идея xM состоит в создании аналогичного функционального макета – внедренной функционирующей модели вместе с простым тестовым приложением – в случае сложных или неизвестных требований и его использовании в качестве основы для обсуждения с пользователями бизнес-процесса. Трудность при этом вызывает создание такой экспериментальной среды в рамках разумных усилий.