Журнал

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

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

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

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

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

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

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

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

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

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

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

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

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

Структура ТЗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Алексей Баранов