И мало кто из заказчиков задумывается о таком этапе выполнения проекта как "моделирование", порой называя его "предпроектным обследованием", т.е. относят не к полноценной части проекта, а только к малозначительной подготовительной работе. В то же время мы, специалисты-внедренцы, считаем данный этап очень важным.

Если вернуться к условному разделению клиентов на группы, то правы представители и второй, и третьей групп. Чтобы успешно внедрить информационную систему, нужно понять, куда мы целимся. Для этого необходимо сначала собрать все требования, а затем придумать и описать, как они должны быть реализованы. Именно для этих целей и служит ТЗ. Важно отметить, что часто сложным является даже не проектирование, а "просто" сбор требований пользователей. Подробнее об этапе сбора требований можно прочитать ЗДЕСЬ.

Итак, требования собраны. Далее систему нужно спроектировать. В традиционном представлении об этапе проектирования думают как об этапе составления технического задания для разработки внедряемой системы. Но что если система уже существует? В этом случае правильным будет не пытаться изобрести велосипед, а использовать уже проверенный практикой функционал. Этот функционал может даже где-то не идеально подходить заказчику, зато его внедрение намного дешевле и перспективнее, т.к. будет шанс бесплатно получать типовые обновления функционала. Таким образом, задача превращается из написания "абстрактного" ТЗ в поиск способа наиболее эффективно решить задачу с помощью уже имеющейся системы. И именно этот процесс мы называем "Моделированием".

Как знают продвинутые заказчики, одной из больших проблем в разработке информационных систем является отсутствие однозначного понимания текстов технических заданий и требований всеми участниками процесса. Есть бессчетное число примеров, когда после очень долгого сбора требований и написания технического задания - итоговая система не особо устраивает заказчиков, чьи требования, формально, были полностью учтены в ТЗ. Причина этого очень проста - не видя итогового результата очень сложно себе представить в голове итоговую систему, и это представление может быть разным у заказчиков и исполнителей. В качестве решения этой проблемы, в мире разработки коммерческого ПО уже давно лучшей практикой признана т.н. "итеративная разработка" или Agile, когда все функции реализуются постепенно, с демонстрацией промежуточного результата заказчику, чтобы он мог на более раннем этапе внести свои корректировки.

Вместо послесловия

Олег Демиденко,
руководитель отдела внедрения ООО “Кодерлайн”