Ведение проектной документации в СППР

02.09.25

Управление ИТ - Стандарты и документация

Организация ведения проектной документации на базе СППР. Как решить вопросы эффективности при проектах, направленных на доработку или внедрение новых продуктов от 1С, при "зоопарке" программ финансового учета и анализа, бухгалтерии ведения конструкторской документации и самое "любимое" это разработки, целые системы на 1С, которые не имеют документации.

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

Появилась мысль вести документацию проекта прямо в системе СППР, но все руки не доходили,  пока в моей жизни не появился работодатель, со своим внутренним проектом и всеми проблемами, описанными выше. По мере разработки, которая как-то документировалась в confluence, а задачи в jira. И тут мне как человеку "оркестру" отдали на доработку блок бюджетирования и продаж. По сути  аналитик с обязанностями - функциональный архитектор и руководитель проекта (команда из 6 человек).

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

Первично определился с составом документации и последовательностями.

 

 

В СППР добавил  подсистему "Проектная документация". По мере необходимости создал документы. Все примеры покажу на тестовой системе, чтоб не нарушить авторские права, которые передал своей организации, хотя тут первая версия и уже есть задумка идти далее.

 

 

Функциональные требования – документ, определяющий предполагаемое поведение информационной системы. Тут СППР дает возможность сравнить требование и функции системы, которые уже реализованы, для определения и фиксации функциональных разрывов

 

 

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

 

 

Далее формируется Техническое задание, Проектное решение.

Дойдя до момента разработки Технических требований (частных технических заданий), понимаю, что мне как аналитику требуется описание требований исходя из того, что уже есть объекты системы для полей и логики, далее для объекта разработки всегда добавляем все необходимое - Руководства пользователя, Справка, Сценарии проверки, Авторский надзор в виде Протокола тестирования.

 

 

Руководство пользователя имеет связь с техническим требованием, все описание шаблонно. 

 

 

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

В типовом функционале Сценарии тестирования добавлена вкладка, позволяющая описать сценарий ручного тестирования, это следствие того, что в организации отсутствуют системы авто тестирования.

 

 

Все разработанные формы имеют связи с типовым функционалом "Проекты", "Функции", "Ошибки", "Задачи", "Роли" и т.д.

К примеру, в "Программе обучения" при проведении обучения определяется "Роль" пользователя и показываются не все действия, а только выбранной роли.

 

 

Перед сдачей в ОПЭ зачастую пропускают момент настроек, по сути логическое поведение в "Техническом требовании", определяет значения в константах, настройках и заполнения первичных данных и требуемые обмены между системами, все это определяется в "Описании настроек"

 

 

Подводя итоги:

По мере внесения данных по предыдущим разработкам повышается качество оценки необходимости изменений, позволяет оценить соответствие функций регламентам организации. При изменении всегда можно четко понимать требуемый объем разработки и стоимость.

Все идеи, зафиксированные в СППР, превращаются в свою ветку доработки/разработки с учетом имеющихся и запланированных функций и связанных с функциями объектов. Команда понимает что делается в рамках проектах, снижается нагрузка по контролю за проектом.

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

См. также

Внедрение изменений Стандарты и документация Бесплатно (free)

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

02.10.2025    669    0    user1923656    0    

3

Стандарты и документация Работа с требованиями Взгляд со стороны Заказчика Бесплатно (free)

«Без хорошего ТЗ — результат такой себе». Но что делать, если ТЗ все время получаются плохими? Вместо того, чтобы заставлять заказчиков следовать шаблонам, мы применили концепцию обучения Дэвида Колба. В статье делимся опытом проведения 8 мастер-классов для 60 коллег по основам написания ТЗ, декомпозиции требований и описанию ошибок. Вы не получите волшебную таблетку, но узнаете конкретный план действий, который поможет сократить время анализа требований и улучшить коммуникацию в команде.

25.09.2025    524    0    user1514417    0    

1

Стандарты и документация Россия Бесплатно (free)

Система менеджмента качества уже много лет активно применяется в среде "1С-Франчайзи". Но не все и не всегда используют ее на 100%. Делюсь, как это делаем мы уже достаточно давно.

04.09.2025    464    0    user1073387    1    

3

Взгляд со стороны Заказчика Работа с требованиями Стандарты и документация Бесплатно (free)

Погружаемся в реалии крупных проектов, где тестирование – не просто этап контроля качества, а инструмент управления ожиданиями, снижения рисков и успешного внедрения.

29.08.2025    971    0    larandrey    0    

1

Стандарты и документация Оценка проекта Бесплатно (free)

Корректно формулировать предпосылки и цели проекта умеют немногие. Как показывает практика, с этим очень тяжело справляются функциональные заказчики. И даже для сотрудников, которые много лет занимаются проектами внедрения информационных систем, это не тривиальная задача. Расскажем о том, как проверить корректность целей, сформулировать предпосылки и правильно составить Устав проекта.

13.08.2025    760    0    INK2018    5    

6

Работа с требованиями Стандарты и документация Бесплатно (free)

Удивительно, но до сих пор большинство аналитиков не слышали о своде знаний по бизнес-анализу BABOK Guide и не знают, что фактически уже используют его техники в работе. Расскажем о том, как с помощью техник BABOK сделать ТЗ максимально «живым» – структурировать требования, визуализировать процессы, смоделировать данные и интерфейсы, чтобы ТЗ было понятно и заказчику, и разработчику.

31.07.2025    1465    41    otkalo    8    

2

Стандарты и документация Бесплатно (free)

Статья посвящена распространённой проблеме в разработке 1С – чрезмерному формализму технических заданий, превращающих гибкий процесс внедрения в бюрократический кошмар. Мы разбираем, почему объёмное ТЗ не гарантирует успех проекта, как оно может парализовать работу команды и что делать, чтобы перейти от «мертвых» документов к живому процессу разработки. На практических примерах из мира 1С показываем, какие форматы взаимодействия действительно работают и как сохранить баланс между ясностью требований и гибкостью решений.

29.07.2025    1710    0    Vasin86    19    

25

Взгляд со стороны Заказчика Стандарты и документация Бесплатно (free)

В этой статье я поделюсь своим личным опытом оптимизации работы по составлению технических заданий с последующей реализацией проектов. Расскажу о том, с какими проблемами и неудобствами приходилось сталкиваться, и какие выводы позволили сократить временные и трудовые затраты при взаимодействии с заказчиками и исполнителями.

28.03.2025    927    0    1Concept    0    

4
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. roman72 403 03.09.25 10:44 Сейчас в теме
Открыл тему по вашей статье в канале СППР

Первое впечатление: решение полностью параллельно типовому функционалу СППР.
Стоило ли делать такое дублирование или можно было обойтись типовым функционалом?
2. user1023273 3 03.09.25 16:31 Сейчас в теме
В самом начале описано что данного функционала нет. Да интеграция в типовые процессы, функции, ошибки, задачи и.т.д.
Вот небольшой кейс:
Требуется оформление предварительной калькуляции по ГОЗ - для оценки себестоимости не серийного производства какого либо изделия.
Вопросы:
Как РП оформить требования к функции, не в виде идеи, а как документ функциональное требование? Как определить объем доработок в деньгах?
Где отразить требования к срокам, этапам, содержанию и результатам выполнения работ?
Как сравнить требуемые функции и существующие с фиксацией функциональных разрывов?
Как отразить Общее техническое задание и проектное решение описывающее структуру, принципы взаимодействия компонентов системы? - Делать группировки в справочнике функции, а как потом это все показать заказчику?
Как оформить требования бизнес аналитику и указать вид формы объекта, где отразить эскиз, как он привяжет процесс к объекту разработки?
Как системному аналитику отразить требования к объекту системы, с учетом внутренней логики, как указать используемые объекты и источники данных?
Могу пройтись по всем требованиям от организационных до технических.

Самое интересное когда Ваш заказчик говорит нам не нужна Ваша документация, а следом нам где руководство пользователя. Далее а где настройки системы и интеграции описаны? Потом ГОСТ и иное.

В моей жизни ЧТЗ включает описание полей, логики заполнения итд. на рисунке пример такого описания.
Прикрепленные файлы:
3. DEG156 28 02.10.25 05:20 Сейчас в теме
А где само решение ? Скачать ?
Для отправки сообщения требуется регистрация/авторизация