Дисклеймер: эту статью я буду еще очень много дописывать и менять, пока в ней только 1% от всего, что я хочу рассказать. Поэтому добавляйте в закладки и иногда заходите за новым контентом.
Техническое задание (ТЗ) по разработке IT-продукта — это документ, в котором указываются характеристики будущего комплекса ПО (от 1 и более программ), требующиеся для полноценной реализации проекта.
«Как сделать ТЗ?» — повсеместный вопрос, я его крайне часто задавал и за 5 лет не обнаружил полноценного ответа. Чаще всего, это попытка описать ТЗ по ГОСТу. В современной разработке это необязательно + они не покрывают большинство вопросов из «реальной жизни».
В данной статье я постарался собрать все лучшие практики написания ТЗ для IT-проектов, которые получил за более чем 5 лет их написания.
Этот чек-лист огромен, состоит из кучи пунктов, которые отвечают на вопрос: кто, как, когда, в какой последовательности, для чего, при каких условиях должен составлять ТЗ и так далее.
Поскольку такой большой материал невозможно охватить разом, я буду постепенно дополнять его, писать новый статьи и прикладывать сюда ссылки.
Добавляйте эту статью в Закладки, с каждым новым возвращением вы будете находить новые пункты. А мы приступаем (пока вразнобой):
Всегда начинайте с БФТ
Мало кто знаком с этим термином, а жаль. БФТ («Бизнес Функциональные Требования») — это документ, в котором описывается запрос от бизнеса по логике и специфике работы системы БЕЗ учета технической реализации. Скоро будет статья на жту тему.
Делайте ТЗ
Отсутствие ТЗ фатально.
Это относится как с Исполнителям, Заказчикам и даже Партнерам по проекту: если вы заранее не договоритесь о результате работы, вам не на что будет опираться, когда придет время приемки работ.
Многие честные люди погубили свои отношения и проекты просто потому что не договорились на берегу и не описали свои ожидания в ТЗ.
Не пишите все и сразу
Вопросы, которые вам заранее неизвестны могут таковыми и остаться. Главное, сделать пометку, когда конкретно будет корректировка ТЗ.
Также, абсолютно нормально представить варианты технологий, которые предстоит попробовать для оптимального решения задачы.
Если у заказчика нет технического навыка, он всегда будет недоволен
У людей, не понимающих принципов разработки ПО, до начала проекта складывается крайне размытая картинка результата. И даже ТЗ тут не поможет.
Если предположить, что ваш заказчик / руководитель более менее адекватный человек, чтобы его удовлетворить, всегда нужно сделать больше, чем вы прописали и сказать об этом.
Помните, что вас всегда обманут
Это связано с предыдущем пунктом: если у вас не было опыта в сфере, то любой специалист способен сделать такие формулировки, которые выглядят здраво, а на деле смысла не имеют, или например опустить детали, которые ему не сильно будет хотеться делать. В любом случае, если вы не дадите ТЗ на перепроверку знающему человеку, вы одной ногой уже в нереализованном проекте и огромных тратах.
Если нет референсов, то оценка проекта возможна только после ТЗ
Если вы разрабатываете площадку, у которой меньше 2-3 референсов, то сказать стоимость и срок разработки возможно только после составления ТЗ.
Вообще нет референсов? Тогда очень важно сделать Прототип
Прототип — это визуально очень упрощенная версия дизайна, которая позволяет блок-схемой накидать основной функционал на странице. Это позволяет на этапе проектирования понять удобство использования будущего продукта, В 100% СЛУЧАЕВ увидеть насколько много вы и заказчик забыли прописать в ТЗ и спланировать. Короче, прототип иногда невероятно спасает и дает сразу +20-30% к успеху разработки.
ТЗ возможно сделать только в плотной кооперации заказчика, специалиста области и IT-архитектора
Этим грешат большие фирмы и некоторые агентства: ТЗ составляют проджекты, а еще хуже продажники. А в процессе проекта не допускают архитектора до клиента.
Да, фирме так легче продавать, только качество продукта и настроение в команде страдают. Если вы заказчик, то требуйте общения с архитектором, если вы отдел разработки, то требуйте доступа к клиенту.
«Сущности» и «Сценарии»
В каждом из них вы описываете:
- Сущности (пример «Соц сеть: Пользователь, Друг, Чат, Участники чата, Сообщение, Прикрапление, …»)
- Свойства Сущностей (пример «Пользовать- имя, фамилия, адрес, email, дата последнего захода, …»)
- Сценарии, которые с ними происходят (пример «Добавление в друзья: после добавления в друзья у человека автоматически создается чат с приветственным сообщением обоим участникам, отправкой письма на почту и …»)
Более подробно я раскрою это в статье, но если упрощенно, то вы из «Сущностей» напишите «Models», а из «Сценариев» сделаете «Controllers».
Рисуйте
Визуализация ТЗ — очень важный этап, который возволяет на ранних этапах обнаружить ошибки. А иногда единственный способ понять текущую картину.
Вот несколько примеров: карта сущностей и их взаимосвязей, карта сервисов и их расположение на серверах, карта модулей и их зависимость друг от друга (+ каналы коммуникации), EPC Сценария и так далее.
Не бойтесь выделять самые большие куски в отдельные ТЗ
Видите, что какой-то Сценарий слишком большой? Вынесите в отдельный документ и приложите ссылку в ТЗ
Скоро будет продолжение…
Нужна помощь с ТЗ?
Уже есть ТЗ или БФТ? Тогда можете его отправить, я посмотрю и скажу рекомендации. Если ТЗ нет, то подскажу, что надо собрать, чтобы начать его делать.
Интересно? Кликайте сюда (переход в Контакты)
