region23
@region23
веб-разработчик

ТЗ на разработку программного обеспечения?

Коллеги, поделитесь пожалуйста ссылками на качественные ТЗ на разработку типового SaaS-продукта.

Можно на английском. Спасибо!
  • Вопрос задан
  • 15547 просмотров
Решения вопроса 1
@Aisu_Kuge
Советовал бы взять за шаблон хорошего ТЗ упрощённые рекомендации PMBoK к проекту, а именно:

1. Разработка устава проекта (документация первоначальных требований, экономического обоснования, составление перечня заинтересованных лиц)
2. Разработка плана проекта, т.е. определяем в первом приближении как будет производится разработка и как будет производится контроль.
3. Собираем требования.
4. Определяем содержание, разбиваем его на операции, оцениваем ресурсы и время на каждую операцию.
4.1. Технические подробности, как должна себя вести система в тех или иных случаях, описать требования к дизайну.
5. Оцениваем весь бюджет разработок.
6. Желательно как-нибудь описать качество (какие-нибудь характеристики, вроде времени обрабатывания запроса) итогового продукта.
7. Готовим подробную смету по проекту (включая туда сотрудников, которые будут работать над проектом, и их з/п на время проекта).
8. Перечень лиц, кто отвечает за контроль хода выполнения работы и качества выполненной работы.

Всю информацию сводим в единый документ. Тогда и проблем будет по минимуму.

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

Всё это актуально вне зависимости от методологии разработки.
Ответ написан
Пригласить эксперта
Ответы на вопрос 4
Mendel
@Mendel
PHP-developer
Я всегда придерживался принципа, что идеальное сферическое ТЗ в вакууме это такой документ, который в будущем станет документацией на продукт.

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

Инструкцию всегда можно просто и быстро превратить в ТЗ. А если вы не готовы писать инструкцию, то вы не готовы писать ТЗ, т.е. еще не имеете достаточного понимания структуры, задачи и т.п. Может быть она и появится в процессе написания…
Ответ написан
Комментировать
EugeneOZ
@EugeneOZ
«Шаблон ТЗ» звучит как «шаблон изобретения». Забавно. Усё под подпись, шеф.
Ответ написан
Комментировать
@gleb_kudr
Шаблон примерно такой:

1. Бизнес-задача. Человеческим языком объяснить, зачем это нужно.
2. Бизнес-кейсы. «Зачем» облекаем в «как». Сценарии работы.
3. Дизайн, учитывая п. 2

Можно пользоваться методикой «что, где, когда, как». Просто, последовательно раскрываем эти вопросы.

Если ТЗ получается больше чем на пару страниц, значит его нужно разбивать на более мелкие куски до тех пор, пока каждый из них не станет достаточно элементарным для осознания одним разработчиком.
Ответ написан
Комментировать
zarincheg
@zarincheg
Думаю что лучше отходить от этого пресловутого ТЗ, по крайней мере в том виде. в котором оно обычно понимается.
Я бы посоветовал сначала составить списки:
1. Список общих требований к функционалу системы
2. Список бизнес-задач, которые должно решать приложение
3. Список use cases, т.е. то, что смогут делать пользователи на сайте.

После этого сгруппировать пункты наиболее логичным образом. Например use cases можно группировать по страницам сайта. После группировки каждый пункт описываете более подробно, чтобы было понятно что конкретно он из себя представляет.
И в принципе на выходе вы получите вполне годный план работ. Конечно некоторые моменты зависят от специфики проекта.Но такой документ команде разработчиков будет проще анализировать.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
25 июл. 2024, в 16:29
5000 руб./за проект
25 июл. 2024, в 16:26
5000 руб./за проект
25 июл. 2024, в 16:06
20000 руб./за проект