Мы в Интерлогике постоянно пишем ТЗ для программистов 1С! Поэтому решили с вами поделиться информацией, как сделать это правильно.
Я редко взаимодействую с программистами. За это у нас отвечает Анатолий. Если вам понадобится помощь с поиском разработчика или написанием техзадания — то на консультации встретитесь с ним.
👋 Привет! Меня зовут Алексей! Я руковожу Интерлогикой, и мы занимаемся автоматизацией управленческого учёта и бизнес-процессов. А ещё я провожу консультации, иногда пишу статьи, в которых отвечаю вопросы читателей, вы, кстати, тоже можете задать вопрос в форме, которая в низу страницы, ну или +7 (495) 764 83 81 , или через телеграм @Interlogik
Считается, что техническое задание составляет заказчик и передаёт его программисту! С одной стороны — это так, с другой — точно нет!
В пользу «заказчик составляет ТЗ» — только конечный заказчик, пользователь 1С в полной мере понимает, что он хочет получить и что ему надо.
Но при этом заказчик не обязан вникать и разбираться в технических нюансах. Да и редко разбирается! В итоге у заказчика почти никогда нет возможности написать внятное ТЗ.
В этом случае, самый лучший ход — разработчик должен сам взять необходимую информацию и пожелания у заказчика. Написать техническое задание под себя. И согласовать его!
В Интерлогике Анатолий берёт необходимую информацию у заказчика, переводит её на язык программистов и нанимает нужных людей. С точки зрения разработчика — мы заказчики.
Мы встречали самые разные форматы техзаданий! Были глупые и бесполезные, были и такие, что составлялись лишь для «отъёма денег», были и из одной строчки: «Сделайте, пожалуйста, чтобы финрезультат считался». Помню задания на пятьдесят страниц, оформленных по ГОСТу. Но объём — не определяет качество ТЗ!
Задача техзадания — упростить коммуникацию между заказчиком и исполнителем, ускорив разработку и не потеряв информацию. ТЗ хоть и документ, но он не должен плодить бюрократию! Поэтому маленькие задачи могут выглядеть, как короткое сообщение в Телеграме!
Предлагаю использовать следующую структуру ТЗ:
Такая структура удобная для описания задач на 1-50 часов работы. Разберём элементы структуры подробнее.
Цель. Пункт подсказываем программисту 1С, что и как следует думать пользователю, чтобы выполнить бизнес-процесс.
Дано. Объясняем разработчику, с чем ему работать: программы, техническое окружение и так далее.
Что нужно сделать. Лучше объяснять с точки зрения пользователя, используя юзер-сторис из эджайла.
Как принимается работа. Важный пункт, который объяснит как принимается работа, при каких условиях он получит деньги. Это поможет заточить работу на работающий модуль и учёт, вместо следования букве ТЗ.
А что насчёт бюджета, разве в правильно составленном ТЗ он не должен быть?
Хороший вопрос! Нет, не должен быть! =) Бюджет — важен, но когда ТЗ пишет благополучатель, то он, вероятно, не понимает тонкости разработки. Может недооценить сложности и спугнуть разработчика или наоборот, заплатить больше. Будет выглядеть или как «Хочу из Сыктывкара долететь до Чикаго! За 5000 рублей!» или перебор «Вот вам 10 тысяч рублей, дайте мне чашку кофе». Лучше взять консультацию и выяснить «сколько это должно стоить.
Дедлайны. Ко срокам относитесь так же как и к бюджеты — они должны быть реалистичными, для этого лучше консультироваться со специалистами.
Вот главное:
Рассмотрим основные:
Эти ссылки для дополнительного чтения, мы отобрали вручную!
— Как составить идеальное ТЗ
— Как и где найти программиста 1С
— Консультации по автоматизации управленческого учёта