Как написать техническое задание для программиста 1с образец

Обновлено: 04.07.2024

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

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

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

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

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

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

· Матрицы ролевого доступа

· Правила предоставления доступа к полям форм и данных

· Проверки корректности заполнения данных в формах ввода

· Процедуры сверки данных

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

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

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

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

· Перечень бизнес-объектов, с которыми имеет дело пользователь и отношения между ними, ссылки на какие объекты в каких объектах должны храниться

· Состав полей данных (табличка в эксель) по каждому бизнес-объекту, у которого есть форма ввода

· Поддержка иерархичности — нужна или нет

· Сколько данных планируется хранить

· Регулярность ввода и изменения этих данных

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

· Поддержка хранения данных с историей по датам — нужна или нет

· Поддержка расчета итогов на какую-либо дату,

· или оборотов за период — нужна или нет

· Поддержка двойной бухгалтерской записи — нужна или нет

· Поддержка вытесняющих графиков величин во времени — нужна или нет

· Поддержка процессов взаимодействия пользователей по объекту — нужна или нет

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

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

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

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

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

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

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

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

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

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

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

Мы уже немного освоились в формулировках для программиста, теперь давайте поймем, для чего нужно описывать процессы?

Лучше один раз увидеть, чем 100 раз услышать!

Программист лучше воспринимает документ, чем устные договоренности, кстати этот документ еще и экономит Ваше время и позволяет Вам следить, когда наступит ред а когда дедлайн.

Рассмотрим процесс описания пошагово:

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

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

У меня для Вас есть несколько лайфхаков что можно и что нельзя делать при описании процессов.

Мы говорим «да» Детальному описанию процессов, и говорим «нет» Мини-описанию процессов. В трех словах не описать весь функционал, который Вам может пригодиться.

Мы говорим «да» Описанию таблиц, и говорим «нет» Дизайну кнопок. Дизайн интерфейса — это другие задачи, здесь мы описываем только нужные нам процессы

Мы говорим «да» Четким формулировкам, и говорим «нет» Абстрактным фразам в описании. Нельзя писать, например в данные мы интегрируем списки. Нужна конкретика!

Мы говорим «да» Конкретному варианту действий, и говорим «нет» Двум и больше вариантам описания. Придерживайтесь правила 1 задача = одно решение!

Подведем итоги,

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

• Знать основы бухгалтерского учета и иметь навыки работы с программой 1С

• Иметь под рукой глоссарий для программиста 1С

• Понимать что Вы хотите получить, в итоге, от программируемого функционала в 1с

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компьютерные игры — относительно молодая отрасль, которая в перспективе сменит киноиндустрию, так-же как кинофильмы заменили театр. Создание игры — это коллективное творчество, во многом напоминающее создание кинофильма. Кроме того, создание компьютерных игр — одна из самых сложных IT задач, поскольку она включает все себя практические все IT области.

Все слышали про pre poduction, но мало кто знает как именно это происходит. И если про стадию разработки написано много, а про стадию издания — еще больше, то про стадию планирования известно очень мало. В лучшем случае вам посчастливится ознакомится с результатами планирования. А вот как были достигнуты эти результаты? — загадка во тьме.

Этот документ является результатом «разбора полетов» после написания игры Звездная арена для социальных сетей. В этом документе я попытался упорядочить список проблем и решений к которым я и Александр пришли в процессе совместной работы над игрою. Кроме того этот документ является частью большой работы по выстраиванию рабочего процесса создания компьютерных игр.

Я намеренно оставил за кадром другие документы: концепцию, экономическое обоснование и ТЗ для других исполнителей. Это позволило сфокусироваться на одной теме и осветить ее и только ее достаточно подробно.

Самое важное:

Четкое понимание конечного результата. (Контроль качества.)
Сроки исполнения.

Зачем нужна документация:

Какие бывают документы:

Концепция («Про че игра?»)
Спецификация (Что мы хотим получить?)
Техническое задание (Как это устроено — именно о нем будет идти речь.)
План работ (Как мы это будем делать.)

Кто участвует в обсуждении ТЗ:

Геймдизайнер (Написание документации)
Архитектор (Отслеживание полноты и подробности описания, декомпозиция.)
Программист (Оценка объемов работ.)

Требования к оформлению документации:

Форматирование. (Легко напечатать и приятно читать/держать в руках)
Выделение ключевых фраз. (Для чтения документа по диагонали)
Составление списков. (Вместо сплошного текста)
Разбиение длинных списков по группам. (По три пункта в группе)
Многократные повторения. (Избегать ссылок по документу)
Дата, номер страницы, количество страниц, нумерация пунктов. (Для точных ссылок при обсуждении прочитанного)
Оглавление, список документов, история изменений. (Для поиска по документации/версиям)

Требования к содержанию ТЗ

Русский язык. (Никаких мемов, искаженных аглийских терминов, албанского языка и прочего мусора. Даже внутреннюю документацию читают очень многие.)
Никаких общих слов типа:
- все возможные варианты
- карта придумывается компьютером
- взаимодействие различных объектов
- после всех действий и т.д.
Все названия видов сущностей(классов) должны иметь:
- русское название (для игрока)
- английское (для кода)
- краткое описание (расшифровка/подсказка/комментарий)
Сущность должна иметь только одно название. (Чтобы “броня” не превращалась на другой странице в “армор” или “щит”).
Предложения должны быть полными и понятными читателю без пристального изучения контекста. (Не надо подразумевать, что читатель сам догадается до того, что подразумевал автор)
Все что можно измерить, должно быть измерено.
- размеры картинки в пикселях и байтах
- количество столбцов и клеток в таблице
- количество символов в текстовом поле
- количество оружия на уровень
- время сессии и т.д.

Главные требования к результату работы программиста:

Гибкость системы к изменениям. (Динамические требования.)
Автоматический сбор данных об ошибках. (Обратная связь.)
Простота запуска и настройки заказчиком. (Демонстрация результата.)

Первый этап написания ТЗ:

Описание предметной области, ее формализация в понятных программистам терминах.

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

Почему так : Разработчику может быть известно о других вариантах объекта, о которых пользователь не догадывается или они ему недоступны в силу ограниченных прав. Также пользователи склонны упрощать названия часто используемых объектов, когда общаются между собой, и также пишут в технических заданиях. Но для разработчика это может быть не так очевидно.

Плохой вариант : “При печати заказа выводится строка про НДС, а когда смотрю Акты на печать, ее нет”

Не указано, из какого документа и какая печатная форма выводится. То, что это документ “Заказ”, не очевидно. Возможно, это печатная форма так называется, а документ подразумевается совсем другой.
Не понятно, о какой строке про НДС идет речь, и в каком месте печ.формы это можно увидеть?
Где пользователь смотрит то, что он называет “Акты на печать”? Если это ПФ, тогда что за признак “на печать”? И что такое “Акт”? - печатная форма или документ? Если это ПФ, то какая именно? Печатных форм со словом Акт может быть несколько.

Возможный хороший вариант : При формировании печатной формы “Акт выполненных работ (наш)” из формы документа “Заказ клиента”, перед подписями ответственных есть строка “Не включая НДС, согласно пп. 777 такого-то Положения”. А если формировать ту же печ.форму из обработки “Реестр печатных форм” с установленным флажком “На печать”, то эта строка пропадает.

Описывать цель доработки

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

Почему так : Из контекста цели можно понять, как именно реализовать отдельные детали, если их описание отсутствует или недостаточно подробно описано в ТЗ. Опытный разработчик/архитектор при этом может предложить более эффективный вариант решения, внести коррективы или внести дополнительные предложения, как лучше реализовать. А от каких-то решений, наоборот, отговорит в силу их неэффективности.

Плохой вариант : Прошу в отчет “Анализ продаж по распродажам” добавить колонку “Дата отгрузки партии”

Почему плохо : Нет уточнения, для чего нужна колонка? - для дополнительной группировки, какого-то анализа или для отбора строк этого отчета, чтобы потом результат подставить в другой отчет?

Возможный хороший вариант : В связи с частыми жалобами на просроченную продукцию во время промоакций, требуется дополнительный анализ отгружаемых партий в торговый зал, чтобы понимать сроки их логистики. Было бы удобно добавить колонку “Дата отгрузки партии” в отчет “Анализ продаж по распродажам”. Это бы позволило выгрузить отчет в Excel и отобрать строки с критичными сроками.

Вывод : Оказывается, отчет вообще не устраивает пользователя. Он просто пытается решить новую назревшую проблему подручными средствами.

Рассказать, что не устраивает в существующем функционале

По аналогии с предыдущим примером (см. “Описывать цель доработки”), при средних и крупных доработках хорошо бы знать, что именно не устраивает в текущей ситуации и почему требуется разработка? Возможно, часть задач можно закрыть функционалом смежных подсистем конфигурации, о которых пользователь не знает, или открыть ему доступ к дополнительным объектам/функциям, которые позволять это сделать.

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

Предоставить пример ожидаемого результата или референсы

Картинка, пример отчета в Excel, скрин из другой программы (“хочу также”), или хотя бы словесное описание того, что должно присутствовать в результате.

Описывать порядок и правила получения данных

Подробно описывать, откуда должны браться данные (например, для отчета), их порядок получения и алгоритм расчета.

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

Плохой вариант : Для нового отчета по партиям добавить информацию о себестоимости.

Почему плохо : Не ясно, что за информация о себестоимости нужна, сколько должно быть новых колонок и каких? - себестоимость единицы, партии или всего наличного остатка. И что следует понимать под “себестоимостью”, она бывает фактической, полной, производственной, включающей или нет различные косвенные суммы.

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

Читайте также: