Как описать процессы на языке программиста»
Итак начнем, что программирует программист в 1С?
· Формы ввода информации
· Контрольные процедуры
· Модель данных
· Алгоритмы автоматического заполнения данных
· Формы вывода информации
Давайте отдельно рассмотрим каждую категорию
Формы ввода информации
Это могут быть как формы ввода в систему какой-либо информации (документы, элементы справочников, таблицы с данными), так и формы загрузки этих данных откуда-нибудь по шаблону (например, Excel или XML и другие форматы для интеграции с другими системами).
Не забывайте указывать в ТЗ перечень кнопок-команд, которыми пользователь должен командовать Вашей системой для ввода данных.
Если техническое задание не содержит продуманного Вами заранее прообраза таких форм или шаблонов, то программист будет придумывать их по своему усмотрению, а Вы будете жаловаться, что вам это неудобно в работе. Лучше всего если есть референсы на данный процесс в других системах или системах конкурентов. Качественный референс идеально поймет любой программист.
Контрольные процедуры
В бизнес-процессах эти процедуры являются предварительными контролями, чтобы вам было понятно. То есть это такие контроли, которые система делает сама в тот момент, когда пользователь с той или иной ролью пытается работать с системой, и выдает предупреждение или намеренно прерывает работу пользователя, не позволяя ему выполнить задуманное.
В эту категорию попадают:
· Матрицы ролевого доступа
· Правила предоставления доступа к полям форм и данных
· Проверки корректности заполнения данных в формах ввода
· Процедуры сверки данных
Если техническое задание не содержит контрольных процедур, то созданная система будет позволять делать все что угодно любому пользователю, почти как в Excel, только с другим оформлением. Какая Вам от этого выгода?
Модель данных
Конечно, программист сделает модель данных так, как ему подскажет его опыт на текущий момент. Если программист опытный, он сделает эффективную структуру данных. А если не очень — то не очень.
Если Вы тоже пока «не очень» программист, то единственное полезное, что Вы сможете в этой части написать для программиста, это будут базовые характеристики модели данных:
· Перечень бизнес-объектов, с которыми имеет дело пользователь и отношения между ними, ссылки на какие объекты в каких объектах должны храниться
· Состав полей данных (табличка в эксель) по каждому бизнес-объекту, у которого есть форма ввода
· Поддержка иерархичности — нужна или нет
· Сколько данных планируется хранить
· Регулярность ввода и изменения этих данных
· Нужно ли хранить в одном объекте несколько таблиц данных, и если да, то с какими аналитиками, будет ли какой-либо другой объект ссылаться на записи этих таблиц
· Поддержка хранения данных с историей по датам — нужна или нет
· Поддержка расчета итогов на какую-либо дату,
· или оборотов за период — нужна или нет
· Поддержка двойной бухгалтерской записи — нужна или нет
· Поддержка вытесняющих графиков величин во времени — нужна или нет
· Поддержка процессов взаимодействия пользователей по объекту — нужна или нет
Эти сведения помогут программисту создать нужную категорию объектов системы, которую потом не нужно будет переделывать, если он сам не догадался о вышеперечисленных характеристиках.
Алгоритмы автоматического заполнения данных
Если у Вас формы ввода содержат много полей или таблиц, Ваши пользователи вряд ли захотят каждый раз заполнять все поля с чистого листа.
Здесь Вы должны продумать, какие поля или таблицы могут быть заполнены по другим полям или таблицам этого или других бизнес-объектов.
Так же, здесь Вы продумываете зависимые автоматические заполнения форм ввода в зависимости от только что измененных полей пользователем. Например, после выбора номенклатуры пользователю не надо выбирать ее основную единицу измерения, система подставит ее по умолчанию сама
Формы вывода информации
В эту категорию попадают отчеты и формы объектов «на просмотр» или «выбор». Понятное дело, программист не должен сам придумывать форму отчета, которую Вы представляете себе совершенно определенным образом.
Нарисуйте прообраз такого отчета в Excel, желательно, с формулами и комментариями, откуда брать информацию, и вложите в ТЗ. Этого достаточно.
Так же сюда попадают формы выгрузки данных в Excel или XML и другие форматы для интеграции с другими системами.
Формы ввода и вывода часто могут объединяться с алгоритмами заполнения данных и контрольными процедурами в функциональные интерактивные АРМы пользователей, дополняться кнопками, вызывающими определенные действия и события в системе. Тем не менее, к ним применимы те же самые принципы написания технического задания, с учетом этих особенностей.
Обеспечив программиста этим нехитрым набором сведений в техническом задании, вы на 90% застрахуете себя от того, что он сделает что-то не то.
Мы уже немного освоились в формулировках для программиста, теперь давайте поймем, для чего нужно описывать процессы?
Лучше один раз увидеть, чем 100 раз услышать!
Программист лучше воспринимает документ, чем устные договоренности, кстати этот документ еще и экономит Ваше время и позволяет Вам следить, когда наступит ред а когда дедлайн.
Рассмотрим процесс описания пошагово:
- Четко сформулируйте все что Вы хотите получить в итоге от данного процесса в программе. Избегайте абстрактных фраз, например: берем данные от сюда и отправляем их в этот отчет
- Сформируйте какой пакет данных или действий, для этого итога, Вам необходим на входе. Если вы не сформулируете данные программист просто не пойме откуда их брать, процесс разработки затянется, а у вас не будет вовремя разработанной функции в 1С и работа встанет
- Всегда рисуйте пример какие столбцы будут в итоговом отчете на выходе данных, описывайте их, а также из каких процессов или функций программы поступили эти данные
На самом деле этого достаточно, главное правильное распределение каждого отдельно взятого процесса. Не кидайте все функции и процессы в один котел. Все должно происходить и быть описано пошагово
У меня для Вас есть несколько лайфхаков что можно и что нельзя делать при описании процессов.
Мы говорим «да» Детальному описанию процессов, и говорим «нет» Мини-описанию процессов. В трех словах не описать весь функционал, который Вам может пригодиться.
Мы говорим «да» Описанию таблиц, и говорим «нет» Дизайну кнопок. Дизайн интерфейса — это другие задачи, здесь мы описываем только нужные нам процессы
Мы говорим «да» Четким формулировкам, и говорим «нет» Абстрактным фразам в описании. Нельзя писать, например в данные мы интегрируем списки. Нужна конкретика!
Мы говорим «да» Конкретному варианту действий, и говорим «нет» Двум и больше вариантам описания. Придерживайтесь правила 1 задача = одно решение!
Подведем итоги,
Чтобы описать процессы в техническом задании на «языке» программиста, Вам нужно:
• Знать основы бухгалтерского учета и иметь навыки работы с программой 1С
• Иметь под рукой глоссарий для программиста 1С
• Понимать что Вы хотите получить, в итоге, от программируемого функционала в 1с
• Логику процесса ввода или вывода информации в системе
• Краткое техническое описание бизнес-требований
