Как правильно написать ТЗ на систему или доработку системы 1С

Для того, чтобы Вам как заказчику, консультанту или методологу понять, что нужно разработчику 1С для того, чтобы доработать Вашу систему или разработать новую, нужно понимать, какими категориями информации он оперирует в ходе своей работы. Это сильно упростит программисту понимание того, что же от него хотят.

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

Данные правила легко соблюдать даже при написании кратких пользовательских историй, если Вы создаете их в рамках проекта SCRUM / Agile.

Итак, приступим.

Для начала вы должны понимать, что же на самом деле в 90% случаев программирует программист 1C:

  • Формы ввода информации
  • Контрольные процедуры
  • Модель данных
  • Алгоритмы автоматического заполнения данных
  • Формы вывода информации

Давайте отдельно рассмотрим каждую категорию.

Формы ввода информации

Это могут быть как формы ввода в систему какой-либо информации (документы, элементы справочников, таблицы с данными), так и формы загрузки этих данных откуда-нибудь по шаблону (например, Excel или XML и другие форматы для интеграции с другими системами).

Не забывайте указывать перечень кнопок-команд, которыми пользователь должен командовать Вашей системой.

Если техническое задание не содержит продуманного Вами заранее прообраза таких форм или шаблонов, то программист будет придумывать их по своему усмотрению, а Вы будете жаловаться, что вам это неудобно в работе.

Контрольные процедуры

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

В эту категорию попадают:

  • Матрицы ролевого доступа
  • Правила предоставления доступа к полям форм и данных
  • Проверки корректности заполнения данных в формах ввода
  • Процедуры сверки данных

Если техническое задание не содержит контрольных процедур, то созданная система будет позволять делать все что угодно любому пользователю, почти как в Excel, только с другим оформлением. Какая Вам от этого выгода?

Модель данных

Конечно, программист сделает модель данных так, как ему подскажет его опыт на текущий момент. Если программист опытный, он сделает эффективную структуру данных. А если не очень — то не очень.

Если Вы тоже «не очень» программист, то единственное полезное, что Вы сможете в этой части написать для программиста, это будут базовые характеристики модели данных:

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

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

Алгоритмы автоматического заполнения данных

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

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

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

Формы вывода информации

В эту категорию попадают отчеты и формы объектов «на просмотр» или «выбор». Понятное дело, программист не должен сам придумывать форму отчета, которую Вы представляете себе совершенно определенным образом.

Нарисуйте прообраз такого отчета в Excel, желательно, с формулами и комментариями, откуда брать информацию, и вложите в ТЗ. Этого достаточно.

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

***

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

Обеспечив программиста этим нехитрым набором сведений в техническом задании, вы на 90% застрахуете себя от того, что он сделает что-то не то.

P.S. Ну разве что у Вас работает не настоящий программист 1С. Может он лучше пишет на python?
  • +10
  • 11,1k
  • 6
Поделиться публикацией

Комментарии 6

    0
    Жаль что в реальности всем вышеописанным самому программисту и приходится заниматься.
      0
      Это кстати одна из фишек 1С-ника, он знает все.
      0
      Очень типичное поведение для производителей таких продуктов: вместо того, чтобы вникать в потребности заказчиков, попытаться заставить этих заказчиков мыслить внутренними категориями системы. Этим грешат разработчики практически всех систем автоматизации бизнес-процессов (включая ERP, банковские и прочие).

      «Что вы там мямлите про новую инструкцию ЦБ? Вы мне дайте перечень бизнес-объектов, матрицу ролевого доступа и опишите триггеры для проверки данных!»

      А проблема решается только так: между заказчиком и программистом должен стоять бизнес-аналитик, способный переводить с одного языка а другой. А не «консультант и методолог».
        0
        Обеспечив программиста этим нехитрым набором сведений в техническом задании, вы на 90%
        выполняете работу программиста.
          +1
          В 90% случаев, получив от аналитика такое техническое задание я его бы и посадил программировать :)

          Изначально подход не верный. 1С служит для решения проблем бизнеса. Задачи надо ставить исходя из той проблемы которую в данный момент надо решить.

          1. Не описывайте формы ввода информацией, описывайте состав информации, которой владеет пользователь на начало бизнес-процесса. И, как правильно описано, состав команд — действий, которые доступны пользователю.
          2. Не описывайте алгоритмы, описывайте физический смысл этапов бизнес-процесса и ограничения, которые требуется применять к каждому этапу.
          3. Запомните, контрольные процедуры не относятся к формам данных, они относятся к бизнес-логике. Ни один нормальный программист не станет делать контроль сразу в форме ввода информации. Тем более правила сверки, матрицу доступа или что-либо еще. Все это делается уже имея схему данных и модель взаимодействия.
          4. Про характеристики модели данных сказано хорошо, но важнее не то, какие будут характеристики (их вычислить ничего не стоит), важно то, какой физический смысл должен быть у объектов бизнес-логики. Не надо объекты процессов и взаимодействия описывать моделью данных — это задача программиста.
          5. Автоматическое заполнение данных — это уж точно не то о чем нужно думать. Нужно думать «Зачем в данный момент надо заполнить так, а не иначе?», «Почему я суда должен подставить это?». См. пункт 2. Если программист не понимает физический смысл, он не понимает задачу. А это значит не сможет ее решить оптимально.
          6. Формы вывода информации аналогичны пункту 1. Стоит описать не то, как будет выглядеть формочка (названия колонок в таблице отчета не скажут программисту ровно ничего), нужно описывать то, что ожидает увидеть пользователь в результате работы этапа бизнес-процесса. Т.е. те промежуточные данные, которые доступны в ходе выполнения и общий результат, который нужно отобразить. Не связывая этап бизнес-процесса с выводом информации вы просто рискуете получить какую-то ерунду, непонятно откуда взятую (например программист решит выбрать данные из регистра, который заполняется только в следующем этапе бизнес-процесса).

          Ну и как показывает практика, хорошему программисту 1С освоить питон удается в разы быстрее, чем хорошему программисту-питонисту освоить 1С:)

          Плюсик за попытку.
            0
            пример такого ТЗ с 1С если можно выложите плз

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое