Все нижеописанное является изложением моего собственного опыта и не является истиной в последней инстанции. Комменты, деление опытом – приветствуются!
Спойлер – идеального формата ТЗ нет.
За свой опыт работы я составлял и решил сотни задач по 1С и побывал в разных «шкурах» при их решении:
- как разработчик,
- как консультант,
- как организатор/менеджер,
- как заказчик,
- просто как наблюдатель
Я видел и задачи из одной строчки типа: «Сделайте нам, пожалуйста, чтобы финрезультат считался в 1С», и монструозные задачи оформленные по ГОСТ34 на 50 страниц убористого текста на внедрение системы учета чего-нибудь, как на скрине ниже.
Скрин с ГОСТа
Я понял, что нет идеального формата ТЗ для программиста, который гарантировал бы, что все будет выполнено все так, как вам хотелось бы.
Для маленькой задачи избыточное ТЗ может «сожрать» ваше время или ресурсы впустую, а на большую задачу/проект избыточное ТЗ заставит вас переписывать половину ТЗ потому, что новое требование, которое возникло или не было учтено, меняет множество спроектированных и описанных механизмов.
Как составить техническое задание для разработки мобильного приложения?
С другой стороны, по ТЗ «Сделайте мне все хорошо», тоже маловероятно достичь результата.
Тем не менее, я предлагаю использовать следующую структуру ТЗ. Из опыта, она проста и подходит для большинства задач с объемом трудозатрат разработчика в диапазоне от 1 до 50 часов.
Скрин шаблончика.
Кстати, на сайте interlogika.ru много интересных материалов по автоматизации.
Кратко пройдусь по некоторым важным пунктам правильного технического задания.
Пункт который раскрывает в контексте чего разработчику следует думать и принимать решения при выполнении задачи. Нарисовать кнопку это не цель, создать отчет тоже не цель. Попробуйте описать цель в виде результата от использования новшества.
Например: «Я перестану тратить время на сбор отчетов на 10 минут меньше в день» или «У меня появится информация, на основании которой я смогу принять решение и не терять товар стоимостью 1/10 от своих суммарных запасов» и т.п.
Прям, как в задачке по физике . Тезисно о чем там писать указано в шаблоне. Цель – дать понять на уровне слов с каким техническим окружением и программами придется работать программисту.
- Что нужно сделать
Вроде бы, это есть сама суть ТЗ. Практически, чем более полно описать этот пункт и добить материалами, тем больше вероятность решения задачи так как вам хотелось бы.
Особенно обратите внимание на тезис «сценарий использования». Он похож на описание в виде userstories по agile методам и описания могут звучать примерно так: – «Я, как пользователь логист открываю монитор доставки, смотрю столбец таблицы тут, нажимаю сюда и т.д.». Очень хорошо дает понимание разработчику процесса использования дорабатываемого функционала.
ТОП-9 советов как написать техническое задание? (ТЗ или техзадание за 9 шагов)
- Как будет осуществляться проверка/сдача работ
Жирный пунктик о том, как будет проводится проверка и кем. Будем проверять на тестовой базе или сразу в продакшн запускаем. Если даже не описывать этот пункт, то хотя бы просто подумайте о нем, как это будет выглядеть.
Напоследок несколько скринов задач из моей системы учета задач.
Источник: dzen.ru
Как писать техническое задание на программный продукт
Рассмотрим, как правильно составить техническое задание на разработку программного продукта.
Пример заполненного ТЗ.
Техническое задание на разработку модели системы дистанционного обучения с применением технологии «клиент-сервер».
Разработать модель системы дистанционного обучения «» с использованием клиент-серверной технологии. Модель предполагает дальнейшее развитие в программный комплекс, предназначенный для заочных и дистанционных форм обучения средних учебных заведений, учебных центров повышения квалификации и центров переподготовки сотрудников.
2. Основания для разработки
Основанием для разработки является задание на курсовой проект.
Основания для проведения разработки: приказ № 471к от 25.12.201… на выполнение выпускной квалификационной работы «Обработка отраслевой информации на примере создание дистанционного курса «Операционные системы».
Наименование и условное обозначение разработки: ДК «Операционные системы»
3. Назначение разработки
Модель является первым этапом реализации сложного комплекса системы дистанционного обучения, предназначенного для внедрения и использования в учебных заведениях. Назначение системы – реализовать новый подход к обучению, позволяющий людям с периферии иметь возможность изучить учебные программы, подготовленные в крупных ВУЗах страны, а также позволяющий получать образование или повышать квалификацию дома или на рабочем месте без отрыва от производства.
4. Требования к программе или программному изделию.
4.1 Требования к функциональным характеристикам.
Разрабатываемая модель должна обладать следующими функциями:
· Работать под управлением ОС Windows 7/8.
· Использовать для соединения и обмена данными протокол TCP/IP.
· Использовать свой протокол, как надстройку над TCP/IP для передачи данных и команд.
· Иметь доступный и простой интерфейс пользователя.
· Иметь гибкую систему настроек.
· Серверная часть должна хранить базу данных пользователей, имеющих доступ к системе и обеспечивать аутентификацию пользователей согласно имеющихся записей.
· Серверная часть должна хранить базу данных учебных курсов, доступных для изучения пользователями.
· Серверная часть должна поддерживать соединение до 32000 пользователей одновременно.
· Клиентская часть должна хранить базу данных адресов серверов для подключения.
4.2 Требования к надежности.
Надежность системы в целом зависит от надежности используемой операционной системы. Серверная часть должна обслуживать без сбоев одновременное подключение и работу до 32000 пользователей. Обе части должны без потерь передавать информацию по каналу связи между клиентом и сервером.
4.3 Условия эксплуатации.
Стандартные условия эксплуатации программных продуктов. Необходимые сотрудники для обслуживания серверной части системы – системный администратор для обслуживания собственно сервера (регистрация и удаление пользователей, добавление и настройка учебных материалов) и группа разработчиков учебных курсов, численность и состав которой зависит от конкретной дисциплины курса.
Климатические условия эксплуатации носителя: Для работы на компьютере в помещении должны быть обеспечены оптимальные параметры микроклимата: температура, относительная и абсолютная влажность.
Оптимальными параметрами микроклимата в помещении с компьютерами считаются:
• Температура воздуха — от 19 до 21 градуса.
• Относительная влажность — от 62 до 55% соответственно.
• Скорость движения воздуха — не более 0,1 м/с.
В производственных помещениях, в которых работа с использованием ПЭВМ является вспомогательной, температура, относительная влажность и скорость движения воздуха на рабочих местах должны соответствовать действующим санитарным нормам микроклимата производственных помещений. Содержание вредных химических веществ в воздухе таких помещений не должно превышать предельно допустимых концентраций вредных веществ в воздухе рабочей зоны в соответствии с действующими гигиеническими нормативами.
Требования к видам обслуживания: для установки и поддержки работоспособности сайта для МКУ «Ордынского историко-художественного музея» требуется наличие браузера.
4.4 Требования к составу и параметрам технических средств.
Для нормальной работы как серверной, так и клиентской частей необходимо:
· Компьютер с процессором Intel Pentium-100 или 100%- совместимым.
· Оперативная память не менее 16 Мb.
· Жесткий диск объемом не менее 1 Gb.
· Наличие адаптера подключения к сети (сетевой карты, модема и т.п.).
· Установленная ОС Windows 95/98/NT/2000.
· Настроенный протокол TCP/IP.
4.5 Требования к информационной и программной совместимости.
Модель системы должна работать под управлением ОС Windows XP/7/8/10, поэтому требуется совместимость исполняемого модуля и библиотек динамического подключения стандартам, используемым этими ОС на платформе IBM PC. Модель должна использовать свой протокол передачи данных высокого уровня как надстройку над TCP/IP. Для хранения информации требуется использование баз данных формата MDB (Microsoft Access).
Для доступа к базам данных Microsoft Access 16 требуется наличие установленного ядра работы с БД Microsoft JET DAO версии 3.5. В качестве средства разработки требуется использовать интегрированную среду разработки Borland Delphi 7, включающую редактор исходных текстов, компилятор, компоновщик и отладчик.
В качестве средства проектирования структуры базы данных и создания файла базы данных требуется использовать Microsoft Access 16.
4.6 Требования к маркировке и упаковке.
4.7 Требования к транспортированию и хранению.
4.8 Специальные требования.
5. Требования к программной документации.
Программной документацией к разрабатываемой модели системы дистанционного обучения является расчетно-пояснительная записка.
Состав пользовательской документации:
• Структурная схема организации.
6. Стадии и этапы разработки.
| № | Содержание работы | Срок | Исполнитель этапа разработки |
| Исследование концепций дистанционного обучения и имеющихся на сегодняшний день решений. | 1-2 недели | Цыганов П.В., Кузнецов Д.Д. | |
| Выработка своего решения | 3-я неделя | Цыганов П.В., Кузнецов Д.Д. | |
| Выработка технического задания | 4-я неделя | Цыганов П.В., Кузнецов Д.Д. | |
| Разработка протокола прикладного уровня “DECSS Protocol” для передачи команд и данных между клиентом и сервером. Создание библиотеки классов, реализующей разработанный протокол. | 5-7 недели | Цыганов П.В. | |
| Принятие решения по разработке формата файлов для хранения учебных курсов. Разработка библиотеки классов для поддержки принятого формата. | 5-7 недели | Кузнецов Д.Д. | |
| На основе разработанного протокола создание «скелета» серверной и клиентской части модели. | 8-10 недели | Цыганов П.В.| | |
| На основе созданной библиотеки классов для работы с файлом учебного курса создание средств просмотра курса. | 8-10 недели | Кузнецов Д.Д. | |
| Объединение разработанных частей в единую модель. | 11 неделя | Цыганов П.В., Кузнецов Д.Д. | |
| Сдача и защита курсового проекта. | 12 неделя | Цыганов П.В., Кузнецов Д.Д. |
7. Порядок контроля и приемки.
Испытание представленной модели и контроль качества ее работы провести на базе компьютерного класса кафедры ИУ6. Во время испытаний проверить работу системы по следующим позициям:
· Запуск серверной и клиентской частей.
· Соединение клиента (-ов) с сервером, проверка правильности обработки сервером соединения.
· Аутентификация пользователя на сервере. Проверка изменения состава зарегистрированных пользователей и групп.
· Подключение на сервере учебного курса с тем, чтобы он был доступен для просмотра.
· Просмотр учебного курса с клиентского рабочего места.
· Завершение сеанса связи.
Источник: poisk-ru.ru
Как написать ТЗ для мобильного приложения
Техническое задание на создание мобильного приложения — важный пункт разработки. Что должно быть в ТЗ, какие задачи решать и кто отвечает за его составление, мы расскажем в этой статье.
Что такое ТЗ на разработку мобильного приложения
- ТЗ для мобильного приложения — это руководство для команды разработчиков, объясняющее каким должен быть конечный продукт.
ТЗ — это важный атрибут профессионального сайтостроения, который ясно описывает логику приложения, перечисляет элементы и сценарии их взаимодействия, указывает на типы данных, регламентирует сроки исполнения работ и условия сдачи проекта.
Вопросы, с которых начинается ТЗ на разработку приложения (пример)
Как правило, техзадание составляется общими усилиями клиента и подрядчика. Роль заказчика в написании ТЗ для приложения значительна, но, особенно важным представляется его участие на первом этапе, когда формируется структура документа.
Готовые ответы на следующие вопросы упростят и ускорят составление технического задания.
Каким заказчик видит свое приложение?
Конкретика в формулировках и ясное понимание задач и целей проекта, помогают с самого начала определить правильный вектор на цель и не тратить ресурсы на проверку ненужных гипотез.
Какова специфика программы?
Новое ПО добавит в корпоративную систему удаленный контроль за персоналом, оптимизирует продажи в B2B сегменте или станет выполнять функции онлайн-каталога в розничных сетях? От специализации будет зависеть масштаб усилий, затраченных на разработку, а значит — время и стоимость реализации.
Будет ли выгода от запуска сервиса?
Прежде чем обращаться к специалистам за ТЗ на разработку приложения, следует четко понимать, как вы собираетесь монетизировать инструмент. Бизнесу важно определить преимущества перед конкурентами и объем охвата пользователей, чтобы проанализировать рентабельность.
Каким бюджетом располагает заказчик?
Разработка — это не единственные затраты, которые заказчику предстоит понести в дальнейшем. Есть плата за поддержание и обновления ПО, маркетинговый бюджет, расходы на публикацию в магазинах приложений. Если ситуация позволяет, можно поискать на рынке готовые решения, доработка которых под ваши потребности обойдется дешевле.
Какую платформу выбрать?
Android — более массовая платформа, устройства и приложения для нее дешевле. Доля аудитории iOS ниже, однако она более платежеспособна. Если сервис подразумевает массовость, имеет смысл готовить техническое задание на разработку приложения для нескольких платформ или же воспользоваться кроссплатформенными решениями.
Кто будет отвечать за внедрение, релиз и отладку?
Что не терять время на неизбежные трудности синхронизации готового приложения с отделами IT-структуры заказчика, следует до начала активной разработки обговорить и зафиксировать список решений и назначить ответственных за их сроки и реализацию.
Заказчик, досконально изучивший рынок и конкурентов в выбранной нише, может сэкономить на услугах аналитики, собирающей информацию о потенциале мобильного приложения с нуля.
Как написать ТЗ для мобильного приложения
Определить, какой формат и уровень проработки документа подойдет в конкретном случае, сложно. Даже самый лучший универсальный шаблон ТЗ на разработку приложения обычно не закрывает вопросы личных предпочтений и специализации. Однако есть общие моменты, которые характерны для большинства форматов технической документации.
- Конкретика во всём: у шрифтов есть названия, у цвета — коды, у форм и элементов — размеры.
- Четкое разделение полномочий: участие и ответственность исполнителя и заказчика строго регламентированы.
- Нет субъективных оценок, только факты: «красиво» и «полезно» — субъективно. Оперируя в техзадании подобными терминами, стороны рискуют качеством процессов.
Учесть все нюансы не получится даже в самом совершенном ТЗ, а останавливать работу для обсуждения каждой мелочи — контрпродуктивно. Проблему решает Agile-подход, который позволяет вносить изменения в ТЗ по ходу разработки.
Кто пишет ТЗ?
Со стороны может показаться, что повторить любой пример технического задания на разработку приложения — простая задача. Это не так: грамотное ТЗ требует специальных технических знаний.
Заказчик
Вряд ли можно составить хорошее задание после прочтения пары статей в интернете. В лучшем случае у вас получится формальный список требований, не отвечающий реальным условиям и целям разработки.
Когда заказчик может составить этот документ самостоятельно:
- Проект простой. Для статичного ленда без сложных скриптов и с минимумом функций, вполне достаточно поверхностных знаний о работе над ПО и примеров ТЗ для приложения из сети.
- Личный опыт full-stack разработки позволяет делегировать задачу подрядчику. Так как обе стороны говорят на одном языке, сделать это несложно.
- Полное доверие исполнителю. ТЗ сводится к тезисам и передаче полномочий на принятие решений разработчику.
Указанные условия — редкость. Поэтому чаще используется другой подход: ТЗ составляют специалисты команды, которая будет работать над приложением или же привлекаются независимые специалисты.
Эксперты
Профессиональным описанием мобильного приложения занимаются, как правило, несколько человек — маркетолог, дизайнер, разработчик, технический автор. Это дает возможность получить документ, учитывающий все детали реализации мобильного ПО.
- Маркетологи находят целевую аудиторию (ЦА), определяют ее мотивы и вносят в ТЗ рекомендации, подсказывающие остальным специалистам, каким должен быть продукт, чтобы отвечать ожиданиям потребителей и быть востребованным.
- Разработчики отвечают за технические компоненты: код, оптимизацию внутренней и серверной частей программы. Они лучше других понимают особенности, которые помогут приложению работать стабильно и быстро.
- Дизайнеры вносят предложения по визуальному представлению ПО. Здесь важно учитывать не только модные тренды в оформлении, но и удобство пользовательского интерфейса.
- Технический писатель обрабатывает информацию, собранную другими специалистами, грамотно компилирует ее и переводит на общедоступный язык, понятный всем участникам проекта.
Собирать команду для составления ТЗ из независимых экспертов будет дорого и долго. Оптимальное решение в таком случае — делегировать процесс команде разработчиков, которая будет заниматься созданием продукта.
Структура ТЗ для приложения
В техническом задании для разработки приложения можно выделить следующую структуру:
Требования к разработке ТЗ мобильного приложения
Упомянутые выше специалисты, участвующие в составлении техзадания, — это стандарт. Однако учитывая разнообразие ниш и специфики мобильного ПО, может потребоваться расширенный состав участников. Поэтому подрядчику, который берёт на себя реализацию проекта, желательно иметь в команде профессионалов необходимых специализаций.
Лучшим решением, предполагающим, что будут выполнены все требования к мобильному приложению, вероятно, станет обращение в студию полного цикла, которая контролирует максимум процессов — от аналитики рынка и составления ТЗ до разработки и выпуска продукта на рынок.
Такой подход кажется наиболее надежным, так как может гарантировать, что члены команды учтут все возможности и риски реализации нового приложения и на каждом этапе этого процесса будут взаимодействовать с максимальной эффективностью.
Наконец, основным требованием является понимание компанией-разработчиком целей ПО клиента и условий, в которых ему придется существовать и конкурировать как на рынке в целом, так и в выбранной нише.
Это означает, что подобранная команда должна иметь, доказанный наличием релевантных кейсов, опыт запуска различных проектов. Даже самый совершенный образец технического задания на разработку приложения не может заменить обширное портфолио.
Вывод
Составление ТЗ на мобильное приложение — важный этап разработки. Благодаря ему можно осознанно управлять соотношением деталей, которые просчитываются заранее и теми, что возникают в процессе реализации.
Правильное техническое задание помогает:
- увеличить шансы создать продукт, соответствующий задачам бизнеса;
- подготовить точный прогноз относительно сроков и стоимости разработки;
- избежать конфликтов между исполнителем и заказчиком из-за разного понимания задач и методов решения;
- сократить риски изменений проекта из-за нечетко прописанных требований.
От ТЗ на разработку зависит управление проектом: либо он контролируется, либо процесс протекает стихийно.
Источник: sibdev.pro