Краткие итоги чтения доклада по 1С СППР на Инфостарт 2019

Выводы по итогам чтения доклада:

1) СППР очень проблемный в использовании продукт

2) Причина проблем в том, что СППР используется неправильно

3) Интерес к СППР есть, многих волнует как привести в порядок и сделать системным подход к управлению проектами

по автоматизации и управлению функциональностью конфигурируемых и сопровождаемых систем.

В чём содержание определения «СППР многими используется неправильно»?

Во-первых, абсолютное большинство использующих СППР взваливают её на разработчиков.

В таких случаях разработчики отвечают за описание функциональности учётных систем в СППР и за составление задач на разработку.

Вот это и есть неправильно.

С такими задачами справится и JIRA и ей подобные бесплатные продукты.

Работа разработчика в СППР не предусмотрена. СППР должна выдавать разработчику задачи на разработку.

Разработчик от СППР, а значит от совсем других участников проекта, должен получать готовые, детально описанные ТЗ.

Во-вторых, даже работа только системного архитектора в СППР недостаточна.

СППР будет эффективна только тогда, когда в ней будет сделано описание бизнес-процессов организации и, отдельно, описание функциональности программного продукта (разрабатываемого или внедряемого).

А архитектор должен связать каждый бизнес-процесс с функцией системы.

Если чего-то не хватает, то либо делается вывод, что система не подходит под процессы клиента, либо функциональность системы дорабатывается (проектируется в СППР!).

Именно об этом 4-й слайд презентации, который показывает, как отличалось бы описание бизнес-процессов по работе на проекте внедрения самой СППР от функциональности СППР заложенной в конфигурацию.

Вывод — любой проект по внедрению СППР обречён на провал, если он вешается на разработчиков.

СППР должна начинать работу гораздо раньше — при сборе требований и описании бизнес-процессов.

PS Модная тема СППР+Vanessa…

Если в СППР делать описание процессов (шагов процессов) по операциям пользователей, то,

фактически, можно получить последовательность операндов языка Геркин для Ванессы.

Т.е. почти готовый сценарий.

Опять вывод, из посткриптума — сценарии должны писать не тестировщики, а те, кто описывает процессы.

От тестировщика (разработчика/программиста) требуется всего лишь перевести шаги процессов в точные команды языка (можно ведь и автоматизировать этот момент, учитывая «человечность» языка геркин).