Техническое задание для программиста 1С
В жизни очень часто бывает так, что человек не может объяснить, что хочет, даже в бытовых вещах. Когда дело доходит до объяснения программисту своих «хотелок», человек просто впадает в ступор.
Кто должен писать ТЗ?
В идеале ТЗ должен составлять заказчик — только он знает, что ему нужно. Но на практике из-за низкой компетенции заказчика в сфере 1С часто это приходится делать исполнителю. Заказчик устно озвучивает свои потребности, а программист(консультант) оформляет это в письменной форме.
Зачем нужно техническое задание?
Любые доработки в системе 1С, в идеале, должны сопровождаться техническим заданием. Это, во-первых, четкое определение задачи, сроков и метода выполнения. Во-вторых, это документ, с помощью которого решаются все спорные моменты в будущем. Писать ТЗ или нет — дело, конечно, Ваше, лично мне ТЗ облегчает работу и общение с клиентом.
Что должно содержать в себе техническое задание?
Тех. задание обязательно должно содержать в себе:
Примеры и образцы ТЗ для 1С
Небольшая подборка, которую я нашел в свободном доступе в сети. Начиная от самых простых и доступных, заканчивая достаточно сложными документами:
К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.
Как писать четкие ТЗ программистам, дизайнерам и даже себе
Составить техническое задание так, чтобы человек понял, что от него требуется и у него появилась внутренняя мотивация решить твою задачу, — это не особое искусство или магия, а конкретный скилл, который можно и нужно вырабатывать.
У меня 8-летний опыт в проектном менеджменте, работе с дизайнерами, программистами и в постановке задач для них. А последние 3 года я руковожу собственной digital-студией «Пекло». Поэтому с уверенностью говорю, что неважно, работаешь ты с придирчивым разработчиком-перфекционистом или супер-творческим десигнером, подход к формированию задачи одинаковый, за исключением нескольких мелочей.
В этой статье я поделюсь советами и приемами, которые я использую в работе сам: как составить ТЗ так, чтобы вашим коллегам, подрядчикам, партнерам было приятно и комфортно принимать и осуществлять ваши задачи. А это залог эффективной командной работы, выполненных планов, заработанных денег. Поехали!
Рекомендации выше подходят как для мелких задач, не требующих дальнейших описаний, видения решения и так далее. Также я рекомендую использовать эти правила даже для ведения личных задач, а не только для постановки коллегам.
Задача, «подкрепленная» дедлайном более приоритетная и важная к исполнению. Задача без дедлайна получает статус «ну, когда-нибудь хорошо было бы ее сделать».
Если вы ставите задачу партнерам и вы не рулите приоритетами их задач, то обязательно уточняйте, когда ее смогут выполнить.
Описание задачи необходимо для крупных и объемных задач, где нужно передать весь контекст проекта и понимание ситуации. Обычно описание задачи состоит из нескольких логичных последовательных блоков (это важно!):
Но помните, что не нужно писать летописи-лонгриды из ваших user story при описании багов. Краткость — сестра таланта. Плюс текст отформатированный, с расставленными акцентами, логично распределенный на абзацы.
Заголовок: Задать подготовленные мета-данные для страниц сайта
Мы обнаружили, что на сайте не сформулированы titles & meta descriptions. У части страниц они не заполнены, половина страниц — дубли, а оставшаяся часть сформулирована без использования ключевых слов и некликабельно. Это критическая ошибка, так как без корректных мета-данных сайт не может расти в поисковой выдаче.
Мы составили таблицу в Google Docs с прописанными мета-данными для каждой статической страницы сайта, а также с шаблонами для динамически генерируемых страниц. Ссылка на документ: . Так как у проекта нет админки, где мы могли бы все настроить своими руками, просьба вставить метаданные из документа на страницы сайта:
Просьба это сделать ASAP, так как от этого зависит вся дальнейшая работа по оптимизации. После реализации задачи, мы отправим сайт на переиндексацию и сразу получим увеличение показов и кликов в выдаче! Если в ходе работы возникнут вопросы — без проблем спрашивайте!
Пояснение: кратко описываем проблему, подготавливаем всю необходимую информацию для разработчика (таблица), далее описываем решение задачи, объясняем подводные камни с «переменными». В конце обозначаем важность задачи, желаемые сроки и профит, который будет от решенной задачи. Также мы добавляем, что мы если что рядом и готовы оперативно ответить и помочь (снижает стресс при получении незнакомой задачи).
Самое важное: если решенная задача имеет конкретный результат и пользу, то у исполнителя есть мотивация ее выполнить. Если важность задачи не раскрыта и понимание того, что она даст, то и желания сделать задачу, быть причастным к ее решению тоже особого нет.
Заголовок: Разработать landing page для
К нам обратились ребята из ХХХ. Они организуют ивенты и тусовки для крупных компаний, и за два года стали лидерами. Текущий лендинг — унылое говно и не соответствует их компании.
Мы узнали собрали всю инфу и контент у клиента:
Помни: рисуем mobile-first, так как 90% трафика — мобильные устройства!
Предлагаю перед стартом работ встретиться и обсудить детали работ, я детальнее расскажу про компанию и структуру лендинга, которую мы продумали. По срокам — нужно показать макет до ХХХ, так что время на подумать есть. Контент дали хороший, заказчик адекватный — так что уверен, сможем сделать круто!
Пояснение: рассказываем о сильных сторонах клиента и о проблеме, даем всю необходимую информацию для старта работ и показываем важные технические нюансы. Из моего опыта, дезигнеры, как правило, не любят много букв, текст читают и копипастят невнимательно, поэтому с ними чаще всего нужно обсуждать задачу голосом. В конце, опять же, говорим о положительных нюансах и намерении сделать круто. Однако, жизнь, тяжелая и непредсказуемая штука: может прилететь говняный проект, и вы понимаете, что уже не отвертеться, его нужно сдать и забыть как страшный сон. В таком случае не обманывать коллегу и говорить честно: «Брат, мы должны сделать эту грязную работу!».
Некоторые из советов (вроде написания заголовков задач) вообще не требуют дополнительного времени на постановку, а вот насколько развернутые и детально описанные должны быть ТЗ — определяет контекст задачи. Перед постановкой задачи обязательно:
В результате вы сэкономите всем время, нервы, быстрее и круче решите задачу, получите каеф от гладкого процесса.
С каждым человеком у нас складываются определенные взаимоотношения и стиль общения. И чтобы задача лучше читалась и воспринималась исполнителем, можно этот нюанс учитывать и отходить от официоза, канцеляризмов и написать текст на «вашем» языке, что тоже будет комфортнее для восприятия информации
Еще небольшая фишка: когда задача уже сформулирована по феншую. Ее нужно ПРОДАТЬ исполнителю:
Прямо по канонам AIDA получается, да? 🙂
Хороший пример:
Вася, привет! В процессе аудита сайта мы обнаружили серьезную ошибку — которая мешает росту сайта. Нужна твоя помощь. Посмотри, пожалуйста, ее сегодня — <ссылка на тикет>!
Плохой пример:
Всем привет! Завели новую задачу:
Главное, сформировать у себя привычку писать задачи по феншую — это перестанет быть для вас стрессом, нагрузкой и перестанет занимать дополнительное время. Зато будет порядок в процессах и в эффективности работы!
Как грамотно составить техническое задание для программиста
Бывает так, что сайт уже готов, а в нем отсутствует какая-нибудь важная функция: программа рассылки, онлайн-калькулятор, нет нужных полей в CMS и пр. Когда после этого заново просматривается техническое задание к этому проекту, то вдруг выясняется, что эти функции просто не были включены в техзадание. Чтобы этого не случилось, в данной статье подробно опишется, как грамотно составить ТЗ для программиста, чтобы в будущем не было никаких проблем.
Структура ТЗ
Для того, чтобы грамотно составить техническое задание программисту, необходимо правильно обозначить структуру. Выделим основные разделы, которые в любом случае должны присутствовать в ТЗ.
Определение цели проекта
Без четкого понимания конечной цели невозможно создать качественный продукт, который полностью устроил бы заказчика. Поэтому, чем лучше будет поставлена цель работы перед разработчиком, тем предпочтительней будет полученный конечный результат.
Для разработчика четко сформулированная цель всего проекта дает полное понимание всей сути поставленной задачи. Для заказчика цель работы дает осознание всех задач, которые решаются по мере продвижения работы.
Полный бюджет проекта
Для исполнителя бюджет проекта, написанный в техническом задании, на начальном этапе дает согласованный с работодателем учет всех его работ. В некоторых случаях, после обоюдного согласования трудовых затрат, происходит корректировка конечной стоимости проекта. Заказчику полный бюджет в ТЗ дает понимание, сколько всего денежных средств надо будет заплатить разработчику. И уже на этих данных он может планировать свой бюджет.
Перечень необходимых работ
Без полного перечня планируемых работ невозможно представить ни одного грамотного техзадания. Он должен быть удобным в понимании и составлен в виде пунктов.
Для исполнителя список работ нужен для понимания, по какой технологии ему следует выполнять задание, какой программный код использовать. Также перечень пунктов в какой-то мере является его гарантом, если вдруг по окончании проекта заказчику что-то не понравилось. Всегда можно открыть техническое задание и увидеть, была ли включена данная работа в условный перечень.
Также у программистов по ходу проекта всегда имеется возможность отказаться от каких-либо заданий, которые не были предварительно включены в список. Или включить их все-таки в ТЗ, но за дополнительную плату. Работодателю перечисленный список работ дает подробное понимание выполняемых заданий на каждом конкретном этапе.
Тщательно описывается готовый продукт
В техническом задании программисту в обязательном порядке должен быть пункт, в котором было бы подробное описание конечного продукта. Для исполнителя данный раздел дает уверенность в правильном понимании итогового результата. Заказчику описание продукта также нужно для полного представления о готовом проекте.
Оценивание результата проекта
Оценка результата может быть предварительной, когда она производится после каждого этапа проделанных работ, или итоговой, уже после окончательного завершения проекта. Оценивание делается при помощи специализированных программ тестирования. Сравнивается полученный результат с требованиями задания для программиста.
Для исполнителя этот пункт ТЗ нужен для того, чтобы он на любом этапе работы имел возможность убедиться в том, что проект соответствует всем нужным требованиям технического задания. Заказчику оценка работ необходима для понимания того, что вложение денег в проект было сделано не зря.
Сроки выполнения работ
Не может быть ТЗ без срока выполнения заказа. Да, бывают ситуации, когда изначально очень тяжело определить весь фронт работ. Или по мере выполнения штатных задач над проектом появляются форс-мажорные обстоятельства, которые вынуждают сдвигать конечные сроки выполнения работы. Но, в любом случае, хотя бы предварительное время работы над проектом должно быть.
Исполнителям срок исполнения заказа позволяет уже на начальном этапе объективно оценить свои потребности в ресурсах и трудозатраты (часы работы). Для заказчика – полное ориентирование в сроках работы, что позволяет планировать все свои остальные проекты. Часто бывает, что работа для данного ТЗ является только составной частью какого-то большого проекта. И он не может дальше продвигаться, пока не будет выполнена эта конкретная работа.
Будущее обслуживание проекта
Всегда, даже после самого удачного проекта, по прошествии некоторого времени, могут обнаруживаться ошибки («баги»), которые следует незамедлительно исправлять. Поэтому, в любом техническом задании, все запланированные работы должны учитывать будущее обслуживание сайта в перспективе.
Исполнителю этот перечень работ дает представление о будущей нагрузке, которая будет присутствовать в связи с дальнейшим обслуживанием. Для заказчика данный пункт в ТЗ дает информацию, которая позволяет планировать затраты на будущую поддержку сайта.
Выявление проблем
В этот пункт техзадания входят работы, которые могут возникнуть при форс-мажорных обстоятельствах. Для того, чтобы грамотно составить данную часть ТЗ, нужно знать самые слабые места сайта, и уже на основе этих знаний заранее предугадать возникновение будущих неполадок.
Обычно, пункт по выявлению проблем составляется заказчиком совместно с программистом или группой программистов, которые пишут код. Они, как никто лучше знают все «узкие» места проекта.
Пример ТЗ для программиста
Приведем реальный пример технического задания для веб-разработчика на тему: «Доработка полей в CMS». Это ТЗ содержит следующие пункты с заданием:
Для типа Страницы, такого поля нет:
Какие поля нужны / что нужно выводить:
Названия для полей:
Нужно, на странице редактирования, указанные выше поля:
Область для размещения полей:
Основные рекомендации и пояснения по написанию ТЗ
Каждое ТЗ для программиста является уникальным, но общие советы применимы ко всем заданиям. Вот главные рекомендации по написанию технического задания для программиста:
Главные ошибки при составлении ТЗ
Каким бы грамотным специалистом не составлялось техническое задание для разработчика, все равно, фактически в каждом написанном ТЗ, имеются типовые ошибки. Рассмотрим самые основные из них:
Интеграция с сервисом рассылок: как написать техническое задание
Блочный редактор писем, готовые шаблоны email, формы подписки и автоматизация. Запускайте email-рассылки, чтобы быть на связи со своими клиентами.
Как развиваться в диджитал. Какие каналы сейчас в тренде. Как зарабатывать больше и поднимать чек за свои услуги.
Рассказываем про инструменты для email-рассылок. Обсуждаем лучшие примеры и механики. Говорим о деньгах. Публикуем вакансии.
Интеграция — это не сложно
Часто при настройке триггерных писем нужно просить программиста сделать интеграцию сайта или CRM-системы с сервисом email-рассылок. Юлия Повх рассказывает, как ставить такие задачи программисту понятно и просто.
Вещи, которые по началу кажутся сложными, мы лучше понимаем на простых примерах.
Например, вы хотите, чтобы все данные с заявок на сайте автоматически попадали в список рассылки «Заказы с сайта». Давайте посмотрим, как ставить такие задачи программисту без необходимости хоть что-то понимать в программировании.
3 способа связать сайт с сервисом рассылок
Прежде всего, нужно решить, как связать сервис email-рассылок с вашим или CRM-системой.
Вы можете использовать:
Последний способ используется, когда готовых интеграций нет или нужно сделать что-то, что они не позволяют.
Поэтому советую изучить для начала, что можно сделать с помощью готовых интеграций. И только если нужную вам задачу невозможно решить, обращаемся к API.
Что за зверь такой – API?
По сути, это «язык», с помощью которого две системы (например, сайт и система рассылки) могут понимать друг друга и обмениваться данными.
API-документация — это развернутая инструкция для программиста, как организовать «общение» вашего сайта с системой рассылки, чтобы она совершала нужные действия в нужный момент.
Для того чтобы программист понял, что именно вы от него хотите, ему нужно это максимально детально объяснять.
Я в работе использую такую схему:
Пример работы этой схемы легко понять на известном меме:
А теперь разберём первую схему детальнее.
Что проработать в техническом задании. 5 элементов
1. Источник
Источник – это система, откуда мы берём данные.
Например, какой-либо сайт example.com или ваша CRM-система.
2. Триггер
Триггер – это событие, по которому данные должны передаваться.
Например, могут быть такие триггеры:
То есть, триггеры зависят от возможных действий пользователя на сайте или смены статусов в CRM-системе.
3. Данные
Какую именно информацию о пользователе мы передадим в систему рассылки, когда сработает триггер.
В большинстве случаев нужно передавать email-адрес и значения других полей, которые необходимо продумать заранее.
Например, на сайте есть форма заявки с такими полями:
И мы хотим, чтобы данные автоматически попадали в группу «Заявки».
В системе рассылки поля «имя», «email» и «телефон» уже существуют по умолчанию. А вот поле «Город» нам некуда передавать, поэтому для начала его нужно создать в системе рассылки.
Пример технического задания для программиста
В жизни очень часто бывает так, что человек не может объяснить, что хочет, даже в бытовых вещах. Когда дело доходит до объяснения программисту своих «хотелок», человек просто впадает в ступор.
Кто должен писать ТЗ?
В идеале ТЗ должен составлять заказчик — только он знает, что ему нужно. Но на практике из-за низкой компетенции заказчика в сфере 1С часто это приходится делать исполнителю. Заказчик устно озвучивает свои потребности, а программист(консультант) оформляет это в письменной форме.
Зачем нужно техническое задание?
Любые доработки в системе 1С, в идеале, должны сопровождаться техническим заданием. Это, во-первых, четкое определение задачи, сроков и метода выполнения. Во-вторых, это документ, с помощью которого решаются все спорные моменты в будущем. Писать ТЗ или нет — дело, конечно, Ваше, лично мне ТЗ облегчает работу и общение с клиентом.
Получите 267 видеоуроков по 1С бесплатно:
Что должно содержать в себе техническое задание?
Тех. задание обязательно должно содержать в себе:
Примеры и образцы ТЗ для 1С
Небольшая подборка, которую я нашел в свободном доступе в сети. Начиная от самых простых и доступных, заканчивая достаточно сложными документами:
К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.
Что такое техническое задание (ТЗ)?
Техническим заданием называется служебный документ с описанием правил выполнения работы и требований к исполнителю.
Почему важно зафиксировать весь процесс работы в виде технической документации?
У каждого проекта должны быть обозначены границы – по стоимости, объему выполняемых работ, срокам исполнения и качеству. Все это должно быть зафиксировано в ТЗ.
Если одна из сторон хочет сотрудничать без техзадания
Это может означать следующее:
Заказчик не устанавливает четких требований специально, чтобы затем получить часть работ бесплатно, либо он не уверен/ не знает/ не решил/ не понимает, что ему надо.
Разработчик надеется на постоянное продолжение работ за счет заказчика, аргументируя это некой неопределенностью.
В такой ситуации противоположная сторона должна обязательно настоять на создании технического задания с четкими границами и определением задач. Без этого сторонам будет трудно доказать, что работы были сделаны, или, наоборот, не сделаны должным образом.
Участники проекта
Заказчик | Менеджер проекта | Разработчики |
---|---|---|
Ставит задачу | Ставит задачу разработчикам | Выполняют задание в соответствии с ТЗ |
Согласовывает ТЗ | Контролирует ход работы и расставляет приоритеты | |
Принимает работу | Осуществляет взаимодействие с заказчиком и разработчиком | |
Тестирует выполненную работу (если нет тестировщиков) |
Если проект большой, дополнительно могут добавиться участники:
Если проект маленький, то заказчик и исполнитель, как правило, работают напрямую. В этом случае тестирование берёт на себя заказчик, а разработчик сам контролирует сроки и ставит приоритеты.
Что дает сторонам каждый раздел ТЗ:
Раздел ТЗ
+ Для Заказчика
+ Для Разработчика
Осознание задач, которые решает проект или его доработка
Понимание сути задачи
Представление о том, каким будет готовый продукт
Уверенность в правильном понимании конечного результата
Ориентирование в сроках работ и получения планируемых результатов
Оценка трудозатрат и потребности в ресурсах
Определение более-менее точной суммы затрат и планирование бюджета
Согласованный учет всех работ проекта
Подробное описание работ и каждого этапа реализации проекта
Ведение работ по установленной технологии. Возможность отказаться от работ, не предусмотренных заданием, либо включить их в ТЗ за доплату
Оценка результата работ
Проверка работы проекта по программе тестирования на соответствие требованиям задания
Возможность удостовериться в бесперебойной работе проекта и в его соответствии требованиям ТЗ
Планирование затрат на обслуживание и представление о дальнейшей поддержке проекта
Выполнение работ с учетом обслуживания проекта в перспективе
Планируемые доработки проекта
Доработка в соответствии с новыми потребностями
Последствия составления некачественного задания
Программист или команда разработчиков действуют «вслепую», несогласованно, не имея четкого представления о конечном результате проекта. Итогом будут зря потраченные время и деньги, испорченные отношения с заказчиком.
Результат проекта не соответствует ожиданиям заказчика. Потребуется дополнительный бюджет и время на доработки.
Обычно разработке качественного ТЗ мешают следующие моменты:
Заказчик не готов платить до 40% от стоимости проекта только за разработку задания. Например, можно еще до начала проектирования написать все тест-кейсы и заложить в ТЗ. Но в этом случае стоимость задания с тест-кейсами может превысить стоимость разработки, а его составление займет не один месяц. Зато это полностью снимает вопрос с ошибками в работе и упрощает приёмку.
Заказчик не знает всех деталей проекта до начала эксплуатации уже готового результата.
Исполнитель не готов без должной оплаты тратить больше ресурсов на разработку ТЗ.
Исполнитель и заказчик не могут предвидеть заранее все возможные проблемы. Опытные участники проекта с обоих сторон могут заранее предусмотреть ряд типовых и уникальных проблем, но это не гарантирует, что вся работа над проектом пройдет гладко.
Например, забыли прописать в техзадании наличие одной кнопки, а после сдачи проекта оказалось, что без неё полноценно пользоваться системой нельзя. Для добавления же кнопки требуется переделать половину внутренней архитектуры базы данных, а значит и часть программного кода переписывать. Кто из сторон виноват в этой ситуации?
Большинство таких проблем решает Agile (гибкий подход к работе), но это не отменяет необходимость составления ТЗ. Используйте Agile при разработке любых проектов с высокой неопределённостью. Как правило, против этого выступают только заказчики, потому что они не видят точной границы цены и сроков. Зато финальный продукт гарантировано будет выполнять поставленные задачи – Agile в разы снижает число готовых проектов, которые были заброшены из-за того, что не выполняют своих функций.
Стороны должны понимать, что большинство проектов выполняется с большой долей неопределённости, и заранее договариваться, как будут взаимодействовать в случае возникновения проблем.
Техзадание должно отвечать на вопросы:
Основные рекомендации и пояснения по написанию ТЗ
7 типовых ошибок
Пример правильного технического задания на доработку проекта
Задача:
Разместить на сайт www.site.name.ru новую страницу, где будут размещены контакты и фотографии продавцов-консультантов, а также онлайн чат.
Описание:
Если работы выполняются для целей SEO – не забывайте закладывать все необходимые элементы на странице.
Также внизу разместить форму заказа.
PS. Стоимость и сроки исполнения, как правило, указываются отдельно в приложении к договору. Исполнитель выставит стоимость работ, исходя из прописанных в техзадании задач. Чем больше пожеланий – тем больше будет стоимость.
Читать дальше подобные статьи
Онлайн SEO-сервис Labrika
Получите рекомендации для продвижения сайта на основе 178 требований поисковых систем
Многие сталкиваются с тем, что достаточно сложно объяснить коротко и ясно то, что мы хотим в повседневной жизни. А уж когда надо дать задание специалисту написать программу для организации или ИП с учетом особенностей и собственных пожеланий по функционалу, то можно вообще «зависнуть».