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

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

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

Позвоните или напишите в чат и мы совершенно бесплатно поможем Вам подготовить ТЗ по 1С!

Кто должен писать ТЗ?

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

Для чего необходимо техзадание?

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

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

Составлять ТЗ или нет — решает каждый для себя, но это точно не будет лишним: упростит общение с клиентом и придаст работе деловой и конкретный характер.

Содержание ТЗ

Обозначим перечень наиболее важных пунктов, которые должны быть в техническом задании:

1. Цель/Задача. Сформулировать то, что должно быть реализовано в конечном итоге.

2. Описание. Вкратце изложить содержание планируемых доработок.

3. Способ реализации. Детально описать методы, с помощью которых должна быть достигнута цель. Следует прописать все особенности задачи на языке программиста: регистры, справочники (создать их или отредактировать); дизайн интерфейса и т.д. Для тех, кто не знаком и лишь что-то такое слышал про специфический язык программиста, советуем не делать ненужных попыток «заговорить» на техническом языке. Т.к. описание в идеале — это сухая констатация, исключающая неоднозначность и возможность возникновения лишних вопросов. Кроме этого этот пункт может включать в себя пример, как подобное программирование было уже исполнено где-то.

4. Оценка работы. Данный пункт очень важен — в нем нужно описать трудозатраты.

Еще два важных момента: есть утвержденные стандарты к написанию ТЗ — ГОСТы. Сейчас они редко используются, но некоторые клиенты могут по старинке просить использовать и их.

И второе, когда сдается работа может возникнуть и такое — «а мы же вроде как просили Вас сделать то-то и тогда-то. ». Есть вероятность, что придется все начать делать с самого начала.

Поэтому, повторимся, что грамотно составленное ТЗ будет полезно как для заказчика, так и для исполнителя.

Пример ТЗ для программиста

Техническое задание 1С на доработку внешней обработки

Цель

Необходимо настроить выгрузку данных из 1С в АРМ банка.

Описание

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

Выгрузка данных должна основываться на документах «ЗаявкаНаОткрытиеЛицевыхСчетовСотрудников» и «ВедомостьНаВыплатуЗарплатыВБанк».

Исходные данные

Имеющаяся обработка к конфигурации 1С «Зарплата бюджетного учреждения», осуществляющая выгрузку данных из документа «ЗаявкаНаОткрытиеЛицевыхСчетовСотрудников» и других справочников и регистров в файл DBF обмена данными с АРМ банка установленного образца.

Обработка выгружает данные в поля TAB_N, NAME, SERNUM, PASSCODE, PDAT, PWHR, BIRTHDAY, POSTINDEX, COUNTRY, CITY, STREET, REGION, BUILDING, CORP, FLAT, BPLACE, CITIZEN соответствующую информацию из конфигурации 1С, предварительно занесённую в указанный документ и другие учётные таблицы. Выгружаются табельный номер, ФИО сотрудника, его паспортные и адресные данные, день рождения и гражданство.

Способ реализации

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

Оценка работы

П отребуется 5 рабочих дней работы программиста.

Как самому написать техническое задание для ИТ службы

Основываясь на 23-х летнем опыте работы в бизнесе ИТ- компании, я четко могу сказать что в 90% случаев всех обращений клиентов за внедрением 1С, разработкой или автоматизацией нет четко сформулированной задачи и критериев результата. Это приводит к недопониманию целей и процесса реализации, к неожиданным объемам работ и нехватки выделяемого бюджета.

Один не спросил, другой не сказал. Попробуем разобраться подробнее что с этим делать.

Все вышеперечисленное совершенно не говорит о том, что заказчик не знает что ему нужно. Это значит, что он не может донести свою мысль, свою идею до собственной ИТ- службы или компании — разработчика.

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

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

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

Рассмотрим кейс одной компании «Не идет баланс»:

Звонок бухгалтера программисту 1С: «Вадим, мне срочно нужно исправить баланс, он не идет на 5000 рублей!» Мысли программиста 1С: «Не идет актив с пассивом, сейчас открою форму отчета через конфигуратор, и допишу в формуле пассива «-5000» и делов то!» Выполняет задание, проходит 10 минут, программист сообщает бухгалтеру что все выполнено, пусть проверяет.

Бухгалтер счастлива, какой с ней замечательный специалист работает, берет дешево, делает быстро, просто волшебник!

А теперь давайте разберем этот кейс с помощью следующих вопросов:

· Правильно ли понял ее специалист?

· Соответствует ли решение истиному запросу бухгалтера?

· Устраивает ли полученный результат работы специалиста бухгалтера?

· По каким критериям проводится приемка работ?

Предположим что у нас опытный главный бухгалтер, который имеет представление о принципах двойной записи в учете. А вот программист 1С – умеет программировать, но не знает бухгалтерского учета, но не говорит об этом бухгалтеру.

· При постановке задачи «не идет баланс» она озвучила ожидаемый результат, что в итоге она хочет решить, но не обозначила что хочет знать в чем конкретно причина отклонения;

· Разработчик 1С понял задачу ровно так, как ее поставили, если не идут две колонки отчета их нужно уравнять в формуле расчета этих колонок.

· Метод решения направлен не на исправление и поиск ошибки в учете, а на механику формирования отчета.

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

· Главное, какой критерии приемки работ ожидается бухгалтером, механика отчета или поиск причины выявленного отклонения и ее исправление.

Кейс от компании «У нас процессы согласования как у всех»:

Запрос от директора производственного предприятия по внедрению внутреннего электронного документооборота в компании.

Целью озвучено «автоматизация процесса согласования рассмотрения договоров от поставщиков». Сейчас на предприятии процесс происходит на протяжении 2-3 недель, потому что очень много ответственных в листе согласования.

Запрос: «Рассчитайте нам стоимость внедрения 1С Документооборота, и побыстрее, процессы у нас такие же как во всех предприятиях. Ждем от вас предложение, выбираем по цене конечно, же. Где дешевле, там нам выгоднее».

Вопрос от специалиста 1С для осуществления расчета трудозатрат по внедрению 1С: «Можете ли предоставить зафиксированный процесс согласования, существующий сейчас в зависимости от вида документа? Есть ли какие либо особенности, например по договорам до 100 тысяч рублей, или более 100 тысяч рублей?

Ответ со стороны заказчика: «Вы же профессионалы, вам виднее, вы сами все должны знать. Ждем предложение по внедрению 1С»

Результат таких запросов очень часто бывает следующим:

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

· подготавливается коммерческое предложение по внедрению программы, в которое закладываются существенные возможные риски (те кто уже попадал в первый вариант развития событий) и снова провал, стороны не договорились, потому что цены слишком высокие и непонятно из чего взяты для расчета;

Как же избежать траты времени и бессмысленного слива денег на неудачные проекты? Возвращаемся к нашим вопросам:

• Четко ли поставлена задача? – конечно нет

• Правильно ли понял ее специалист 1С? – понял из своего опыта (заложил риски своих неудач)

• Соответствует ли решение истиyному запросу директора? – я бы сформулировала цель следующим образом: «Сейчас компания теряет… . тыс. рублей из-за длительных сроков согласования внутри компании, во сколько нам обойдется внедрение этого процесса, чтобы ускорить процесс до 2-4 часов»

• Устраивает ли полученный результат работы компании? – однозначно нет, оба варианта принесли затраты как времени, так и денег, не принеся положительного результата.

• По каким критериям проводится приемка работ? – критерии не были озвучены

Так что же делать?

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

Одним из эффективных источников фиксации информации является составление технического задания.

Давайте рассмотрим структуру технического задания со стороны заказчика:

В какой системе предполагается разработка/ интеграция между какими системами;

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

Например: создание дублирующего справочника «причины отказа клиентов» от заказа клиента, или дублирование «Сегмента номенклатуры».

Интеграцию, синхронизацию, обмен с другими внешними системами необходимо предусмотреть заранее, чтобы проконтролировать влияние разработки на эти обмены. Например: «Сегмент номенклатуры» необходим ли он при выгрузке данных на сайт.

Кто выступает инициатором со стороны заказчика (ФИО, должность, контакты, доступность данного лица в ближайшие 3 месяца)

Эти данные необходимы для уточнения и согласования деталей по задаче. Иногда ответственным назначают человека, до которого очень сложно достучаться из-за его высокой загруженности, или он отсутствует на предприятии продолжительное время (отпуск, больничный, командировки). А от этого будут зависеть сроки приемки и тестирования работ;

Критичность задачи по сроку реализации

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

Название и путь до базы данных

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

Какой вариант работ предпочтителен (доступ к копии базы данных на сервере заказчика; передача копии базы данных разработчику; разработка на типовом функционале без подключения к данным заказчика)

· Подключение к серверу и разворачивание копии для разработки и тестирования потребует места на вашем сервере, к этому нужно быть готовым;

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

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

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

В чьей зоне компетентности подготовка копии баз данных, настройка бэкапов базы разработки; загрузка изменений для тестирования; загрузка в рабочую базу данных (ФИО, должность, контакты, доступность)

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

Описание самой задачи

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

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

Корректный вариант: разработать для технолога производства инструмент по замене сырья в спецификациях, с указанием коэффициента списания сырья, через создание новой спецификации в статусе «Действующая». Предусмотреть перевод в статус «Не действующая» спецификаций, по которым прошла замена сырья.

Ожидаемый результат

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

Описание текущего бизнес-процесса

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

Технолог получает задачу от директора по производству заменить наименование импортного сырья на российский аналог с 01.04.2022 года.

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

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

Описание желаемого бизнес-процесса

Пример что хотим: Технолог, получив задание от начальника производства формируем журнал спецификаций в базе 1С:ERP (1С:Управление производственным предприятием). Через отбор выбирает сырье, которое необходимо заменить, проставляет на какое сырье требуется заменить. При этой манипуляции старые спецификации сохраняются по сроку действия, так как они уже запущены и участвуют в выпуске продукции. А новые спецификации с российским аналогом сырья начинают действовать с определенной даты и будут задействованы при оформлении нового заказа в производство. Технолог должен успевать в срок до 1 дня по исполнению задачи по замене сырья в спецификациях, при этом списание сырья при выпуске продукции должно производится по действующей спецификации на момент запуска заказа в производство.

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

Пример: Данный функционал доступен только для пользователя «технолог». У пользователя «бухгалтер» не должно быть права менять спецификацию самостоятельно.

Как будет происходить тестирование разработки, интеграции, обмена и кто принимает в нем участие

Описываем последовательность действий пользователя при тестировании. Не забыть проверку описанных ограничений.

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

Читать:

что такое null

Пример: Технолог заходит под своим пользователем в 1С:ERP, открывает раздел АРМ Технолога, выбирает импортное сырье и осуществляет отбор спецификаций со статусом «действующая». Выбираем позицию для замены из российского сырья, проставляет коэффициент списания по сравнению с импортным сырьем и запускает обработку. Фиксируем время выполнения – тайминг.

Начальник производства заходит под своим пользователем в 1С:ERP, производит тестовый запуск нового заказа на производство, делаем тестовый выпуск продукции и проверяем по каким спецификациям списалось сырье на выпуск.

Если обнаруживаются отклонения – фиксируем его в протокол тестирования для дальнейшей отработки с разработчиками.

Заходим в 1С:ERP под пользователем бухгалтер, пробуем изменить спецификацию. Если обнаруживаются отклонения, снова фиксируем в протокол тестирования.

При достижении каких критериев/ показателей работы считаются принятыми

Важно прописать измеримые и понятные показатели. Например:

· технолог на замену спецификаций должен потратить не более 4 часов;

· корректность данные проверяется сопоставлением с отчетом «Ведомость по остаткам на складах» по графе списание за день;

· оформление заказа клиента у менеджера должно занимать не более 5 секунд при звонке постоянного клиента с подбором истории продаж;

· списание сырья на основании выпуска из производства должно соответствовать количеству в действующей спецификации на дату запуска заказа;

Анализ эффективности внедрения 1С, автоматизации процессов для компании (экономическая выгода)

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

Например: перевод диспетчерской службы 7 подразделений Хлебозавода на 1С:ERP сэкономила компании более 776 400 рублей ежемесячно.

Расчет до внедрения: 7 заводов в каждом на приеме заказов работало по 3 диспетчера в смене при минимальной зарплате 12 000, график сутки через двое. Получаем сумму: 7 производственных площадок * 3 смены * 3 диспетчера * 12 000 (зп) = 756 000 ежемесячно + 24% налоги с ФОТ = 937 440 рублей ежемесячно.

Расчет после внедрения: централизовали диспетчерскую службу, перевели ее в управляющую компанию. В центральную диспетчерскую перевели 5 сотрудников, график работы Пн. -Пт., дежурства Сб, Вс не полным составом. Максимально автоматизировали прием заказов от торговых сетей без участия диспетчеров, прием заказов по телефону не более 5 сек. на заказ, при звонке через АТС программа сама определяет клиента и сразу выводит на экран диспетчеру заказ клиента в открытом виде с подобранными товарами которые они брали за последние 7 дней, цена уже стоит в заказе, диспетчеру осталось только количество внести со слов клиента. Средний чек по заказу вырос, так как программа автоматически подсказывает что еще клиент может заказать к Пасхе например. Итог: 5 человек * 26 000 рублей + 24% налоги с ФОТ = 161 000 рублей ежемесячно.

Экономия в результате автоматизации 776 400 рублей! Стоимость проекта на 2020 год по этому этапу составила 2,5 млн. рублей включая оборудование по IP телефонии. Затраты по проекту окупили себя за 3,5 месяца!

Когда подводится экономический эффект от внедрения, приходит понимание, что это того стоило.

Я призываю Вас принять участие в нашей мастерской и отработать навык составления технического задания на практике.

Наша компания Soft+ 5 апреля 2022 года провела закрытую экспериментальную мастерскую «Напиши техническое заданием сам», направленную на подготовку пользователей 1С самостоятельно составлять технические задания как своим ИТ службам, так и ИТ компаниям.

В Мастерской приняли участие 18 представителей, среди которых наши клиенты, методисты и разработчики компании Soft+. Посмотрели на материал со всех заинтересованных сторон, определили как лучше отработать формат.

Эксперимент признали удачным, и мы готовы выпустить формат данной мастерской в общедоступный режим. Узнать подробнее вы можете на нашем сайте Витрина вебинаров Soft+ (soft-plus. ru)

Мария Эсмонтова, Управляющий партнер ИТ компании Soft+; Сертифицированный практик бизнес-ТРИЗ 2 уровня; +79272713948,

Как правильно составить ТЗ для программиста 1С

Я редко взаимодействую с программистами. За это у нас отвечает Анатолий. Если вам понадобится помощь с поиском разработчика или написанием техзадания — то на консультации встретитесь с ним.

Ключевое, что нужно запомнить: идеального техздания — нет! Поэтому не заморачивайтесь особо над «правильностью»

�� Привет! Меня зовут Алексей! Я руковожу Интерлогикой, и мы занимаемся автоматизацией управленческого учёта и бизнес-процессов. А ещё я провожу консультации, иногда пишу статьи, в которых отвечаю вопросы читателей, вы, кстати, тоже можете задать вопрос в форме, которая в низу страницы, ну или +7 (495) 764 83 81 , или через телеграм @Interlogik

Кто должен составлять ТЗ для программиста 1С

Считается, что техническое задание составляет заказчик и передаёт его программисту! С одной стороны — это так, с другой — точно нет!

В пользу «заказчик составляет ТЗ» — только конечный заказчик, пользователь 1С в полной мере понимает, что он хочет получить и что ему надо.

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

В Интерлогике Анатолий берёт необходимую информацию у заказчика, переводит её на язык программистов и нанимает нужных людей. С точки зрения разработчика — мы заказчики.

Как выглядят технические задания

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

Задача техзадания — упростить коммуникацию между заказчиком и исполнителем, ускорив разработку и не потеряв информацию. ТЗ хоть и документ, но он не должен плодить бюрократию! Поэтому маленькие задачи могут выглядеть, как короткое сообщение в Телеграме!

Структура ТЗ

Дано (что имеется у клиента, обычно речь про программы и версии);
Что изменить (цели разработки);
Что Сделать (конкретные шаги изменения, лучше описывать через юзер-стори);
Сдача (при каких условиях задача считается принятой).

Цель. Пункт подсказываем программисту 1С, что и как следует думать пользователю, чтобы выполнить бизнес-процесс.

Дано. Объясняем разработчику, с чем ему работать: программы, техническое окружение и так далее.

Что нужно сделать. Лучше объяснять с точки зрения пользователя, используя юзер-сторис из эджайла.

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

А что насчёт бюджета, разве в правильно составленном ТЗ он не должен быть?
Хороший вопрос! Нет, не должен быть! =) Бюджет — важен, но когда ТЗ пишет благополучатель, то он, вероятно, не понимает тонкости разработки. Может недооценить сложности и спугнуть разработчика или наоборот, заплатить больше. Будет выглядеть или как «Хочу из Сыктывкара долететь до Чикаго! За 5000 рублей!» или перебор «Вот вам 10 тысяч рублей, дайте мне чашку кофе». Лучше взять консультацию и выяснить «сколько это должно стоить.

Дедлайны. Ко срокам относитесь так же как и к бюджеты — они должны быть реалистичными, для этого лучше консультироваться со специалистами.

Избегайте этих ошибок при составлении ТЗ для программиста 1С

Абстракции. Проговорите голосом ТЗ, убедитесь, что исполнитель будет делать ровно то, что нужно вам, а не то, что соответствует букве ТЗ. Впрочем, если ваши ожидания расходятся с записями — скорректируйте записи.
Больше данных. В теории разработчик может написать заказчику и задать вопросы о программах, техническом окружении и прочие вещи. В реальности такое происходит редко. Часто разработчик садится «в последний день», когда выясняет, что ему нужна какая-то деталь. И начинается запоздалое «дёрганье». Сразу всё распишите и дайте пароли-явки, для самостоятельного выяснения.
Условия приёмки и «штрафы». Обязательно чётко пропишите, при каких условиях разработка будет принята и оплачена. Больше внимания на «способность решить задачу», чем на «срыв дедлайна». Когда разработчик понимает, что запороть программу страшнее, чем просрать сроки — разработка делается от души и правильно.
Ответственные. Укажите контакты ответственных лиц. Позаботьтесь о запасных, в случае недоступности или внезапных увольнений. Иногда мы нанимаем «школьников-фрилансеров» и не стесняемся, в этом случае, брать телефоны родителей-бабушек. Чтобы в случае чего успешно связаться с разработчиком. Интересно, что нам ни разу не приходилось звонить бабушке, разработчику достаточно просто знать, что у нас есть такой рычаг влияния.
Вместо описания формы ввода опишите состав информации, которая есть у пользователя на начала бизнес-процесса и состав команд, которые ему доступны.
Не описывайте алгоритмы! Лучше смысл этапов бизнес-процесса и ограничения.

Простой пример частного технического задания (ЧТЗ) для 1С-ника

Частное техническое задание (далее ЧТЗ) – это выделенный блок технического задания (ТЗ), в котором описана определенная часть разработок проекта. Как правило, Частное техническое задание описывает определенную небольшую функциональность и позволяет разделить работу по нескольким разработчикам, так чтобы они не «пересекались» в рамках функциональной области. По сути, ЧТЗ – это и есть ТЗ только на часть системы. Обязательный атрибут технического задания на внедрение системы на крупных проектах.
Зачем писать Частное техническое задание на «маленьких» проектах, где и так все понятно?
Практика показывает, что даже на небольших проектах, несогласованные представления исполнителя с ожиданиями заказчика приводят к дополнительным затратам на исправления, а порой и конфликтным ситуациям, поэтому правильно задокументированные задачи, являются залогом успешно сдачи работ.
В данной статье будут описаны самые необходимые аспекты разработки технического задания для 1С, взятые из практики внедрения не только на крупных, но и на небольших проектах. Здесь не будет описания ГОСТ-ов и прочих формальностей. Целью статьи является описание упрощенного формата документирования задания на разработку.
Структура представленном здесь примере технического задания для 1С, состоит из следующих разделов

1.Контекст задачи

В данном разделе идет описание в следующей последовательности пользовательская история -> проблема или предложение -> ожидаемый результат Этот раздел позволяет разработчику понять суть проблемы и спроектировать техническую часть (если он участвует в разработке структуры технического задания) Заполняется Аналитиком и/или Заказчиком

2.Критерии результата

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

3.Техническое описание

В разделе технического описания задания должен быть представлен результат архитектурного и функционального решения. Описаны структуры добавленных объектов, требования к поведению системы при наступлении определенных событий. Т.е. описан способ реализации поставленной задачи.
Можно использовать следующие подразделы: ● Интерфейс (формы ввода, расположение команд) ● Добавленные, измененные объекты (архитектура) ● Контрольные процедуры (проверка введенных пользователем данных) ● Алгоритмы автоматического заполнения ● Алгоритмы реагирования на события ● Алгоритмы реагирования на команды ● Ролевая модель ● Формы вывода информации Заполняется Архитектором или Программистом

4.Контактные лица

Список участников проекта в рамках данного Частного технического задания. Согласно данного списка разработчик может связаться с тем или иным участником для уточнения или согласования определенных действий. Для удобства сюда можно добавить контактные данные.

5.Трудоемкость
Оценка планируемых трудозатрат на выполнение данного ЧТЗ Заполняется Архитектором или Программистом

6.Чек-лист

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

2. Пример технического задания в 1С

Хочется еще раз отметить, что ЧТЗ или ТЗ позволяют не только действовать согласованно всем участникам проекта, но и получить осознанное представление о ходе разработки и критериях успешной сдачи работ. Рассмотрим пример технического задания для 1С. —————————————————————————————————————————— ЧТЗ-031 Учет личного автотранспорта

Контекст задачи

В организации существует необходимость ведения учета использования личного автотранспорта сотрудников. В данный момент учет ведется в файле «Личный автотранспорт.xls». В этот файл заносятся данные о марке транспортного средства и его госномер. У одного сотрудника может быть несколько единиц транспортных средств. Необходимо реализовать данный учет в информационной базе в карточке физического лица.

Критерии результата

1.В карточке физического лица добавлена возможность ввода данных о работе на личном автотранспорте. 2.Обеспечена возможность ввода и хранения названия марки автомобиля и госномера для каждой единицы личного транспорта человека. 2.Можно ввести несколько единиц транспортных средств для одного физического лица. 3.Данные о личном автотранспорте могут вводить только сотрудники кадровой службы. Сотрудники HR-отдела могут только просматривать эти данные. Для остальных сотрудников эти данные должны быть недоступны. 4.Данные файла «Личный автотранспорт.xls» перенесены в информационную базу.

Техническое описание
Интерфейс

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

Данные о личном автомобильном транспорте

Добавленные объекты

Регистры сведений:
Роли:

Измененные объекты

Подсистемы:

Автозаполнение:

При добавлении новой записи Личный автотранспорт автоматически устанавливать значение поля «Номер по порядку»

Контактные лица

Трудоемкость
● Разработка – 1 ч. ● Перенос данных – 2 ч. ● Тестирование – 0,5 ч. Итого – 3 ч.
Чек-лист выполнения

1.Разработать функционал и загрузить результат в хранилище. Обновить тестовую базу из хранилища. отв. Программист 2.Загрузить данные из файла «Личный автотранспорт.xls» в тестовую базу 1С. отв. Программист 3.В тестовой базе: добавить в профиль Кадровой службы роль «Редактирование личный автотранспорт», добавить в профиль HR-отдела роль «Просмотр личный автотранспорт». отв. Аналитик 4.Проверка и тестирование результата в тестовой базе 1С. отв. Аналитик/Заказчик 5.Обновление рабочей базы 1С из хранилища. отв. Администратор 6.Загрузка данных из файла «Личный автотранспорт.xls» в рабочую базу 1С. отв. Программист 7.В рабочей базе: добавить в профиль Кадровой службы роль «Редактирование личный автотранспорт», добавить в профиль HR-отдела роль «Просмотр личный автотранспорт». отв. Администратор
Специалист компании «Кодерлайн» Игорь Торба