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

Мы в Интерлогике постоянно пишем ТЗ для программистов 1С! Поэтому решили с вами поделиться информацией, как сделать это правильно.

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

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

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

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

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

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

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

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

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

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

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

Структура ТЗ

Предлагаю использовать следующую структуру ТЗ:

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

Такая структура удобная для описания задач на 1-50 часов работы. Разберём элементы структуры подробнее.

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

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

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

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

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

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

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

Рассмотрим основные:

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

👉 Нужна помощь в написании ТЗ? Мы готовы помочь, для этого оставьте заявку на странице консультацией, или сразу свяжитесь с нами по телефону +7 (495) 764 83 81#nbspили через телеграм @Interlogik

Эти ссылки для дополнительного чтения, мы отобрали вручную!
— Как составить идеальное ТЗ
— Как и где найти программиста 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 рабочих дней работы программиста.

Отзывы о компании

Сивелькина С. В.

ПАО “НИКО-БАНК” выражает свою благодарность за оперативную и грамотную работу.
В условиях постоянно меняющегося законодательства Банк заинтересован иметь полную и актуальную номативную базу. Это обеспечивается использованием Банком справочно-нормативной системы “Гарант”.

Безусловным плюсом в работе компании “МастерСофт” является быстрое реагирование сотрудников при предоставлении документов по запросу Банка, принятых до обновления справочно-правовой системы.
Мордвинцев С. П.

Коллектив компании “АЭРОПОРТ ОРЕНБУРГ” выражает благодарность за взаимовыгодное сотрудничество с МастерСофт-ИТ. Оперативная поставка антивирусных программ Dr. Web обеспечила надежную защиту нашей компьтерной сети.

Особая благодарность сотрудникам Департамента продаж СЦ ИТ за профессиональный подход в решении всех возникающих задач.
Ряховская Н. А.

ООО “Орский Вагонный Завод” выражает искреннюю благодраность за качество обслуживания вашими специалистами. Консультации и поставка антивирусов всегда проходят оперативно и на высоком профессиональном уровне.
Уверены, что и в дальнейшем наше сотрудничество на взаимовыгодных условиях продолжится.
Кетерер Т. М.

Главный бухгалтер муниципального бюджетного учреждения дополнительного образования “Дворец творчества детей и молодёжи” Кетерер Татьяна Михайловна выражает благодарность специалистам МастерСофт:
“Я хотела бы объявить благодарность вашим сотрудникам. Работает с нами по программе “1С: Бухгалтерия бюджетного учреждения 8” непосредственно Шевлягина Юлия.

Так же огромная благодарность за отзывчивость, терпение и квалифицированную, своевременную помощь Набокиной Олесе и Ерёменко Татьяне (они нас сопровождают по программе “Зарплата и Кадры”).

Им очень с нами тяжело, но они терпеливо продолжают сотрудничать. С вами очень надёжно. Конечно же наши ошибки есть и без вас мы бы вообще о них не знали и в суде, наверное, судились бы. А сейчас мы решаем вопросы…”.

Источник

Время на прочтение
4 мин

Количество просмотров 29K

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

***

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

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

P.S. Ну разве что у Вас работает не настоящий программист 1С. Может он лучше пишет на python?

Источник

Мы в Интерлогике постоянно пишем ТЗ для программистов 1С! Поэтому, решили с вами поделиться информацией, как сделать это правильно.

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

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

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

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

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

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

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

Рассмотрим основные:

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

Нужна помощь в написании ТЗ? Зовите нас! Поможем составить!

Эти ссылки для дополнительного чтения, мы отобрали вручную!
— Как составить идеальное ТЗ
— Как и где найти программиста 1С

За статью «Как правильно составить ТЗ» спасибо специалистам Интерлогики

Источник

1 С чего начать? Два способа.
2 Что должно содержать ТЗ
3 Пример технического задания
- 3.1 1 Назначение системы
- 3.2 Задачи создания системы.
- 3.3 Объектами автоматизации являются:

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

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

С чего начать? Два способа.

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

Я расскажу о двух способах как составить подробное ТЗ.

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

Сотрудник рисует колонки, объясняет, что они отражают. И все это заносится в задание на разработку.

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

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

Второй способ — это движение от задачи. Например, задача: «настроить обмен между сайтом и основной базой». Представьте, что этот обмен уже работает, какие данные и куда попадают? Напишите в задание свое видение!

Что должно содержать ТЗ

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

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

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

Исходя из своей практики, могу порекомендовать вот эти пункты:

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

Я их взял из ГОСТ 34.602-89 поищите в интернете. Он родом из СССР, но актуальность не потерял до сих пор!

Пример технического задания

1 Назначение системы

Разработка конфигурации «Управление Гостевым домом».

Целью создания системы является организация учета по управлению гостевым домом:

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

Задачи создания системы.

Создаваемая конфигурация «Управление Гостевым домом» предназначена для решения следующих задач:

организация приема заявок и бронирования;

учет заселения постояльцев и хранение их данных;

учет закупок расходных материалов;

учет прибыли, доходов и расходов Заказчика;

учет имущества в номерах;

создать отчеты и печатные формы для карточек номеров и заселения;

создать отчеты по финансовой деятельности.

Объектами автоматизации являются:

✅ рабочее место менеджера на ресепшен

✅ рабочее место руководителя

✅ рабочее место обслуживающего персонала

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

Источник

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