was successfully added to your cart.

Корзина

Чек-лист по написанию ТЗ (общий)

Дисклеймер: эту статью я буду еще очень много дописывать и менять, пока в ней только 1% от всего, что я хочу рассказать. Поэтому добавляйте в закладки и иногда заходите за новым контентом.

Техническое задание (ТЗ) по разработке IT-продукта — это документ, в котором указываются характеристики будущего комплекса ПО (от 1 и более программ), требующиеся для полноценной реализации проекта.

«Как сделать ТЗ?» — повсеместный вопрос, я его крайне часто задавал и за 5 лет не обнаружил полноценного ответа. Чаще всего, это попытка описать ТЗ по ГОСТу. В современной разработке это необязательно + они не покрывают большинство вопросов из «реальной жизни».

В данной статье я постарался собрать все лучшие практики написания ТЗ для IT-проектов, которые получил за более чем 5 лет их написания.

Этот чек-лист огромен, состоит из кучи пунктов, которые отвечают на вопрос: кто, как, когда, в какой последовательности, для чего, при каких условиях должен составлять ТЗ и так далее.

Поскольку такой большой материал невозможно охватить разом, я буду постепенно дополнять его, писать новый статьи и прикладывать сюда ссылки.

Добавляйте эту статью в Закладки, с каждым новым возвращением вы будете находить новые пункты. А мы приступаем (пока вразнобой):

Всегда начинайте с БФТ

Мало кто знаком с этим термином, а жаль. БФТ («Бизнес Функциональные Требования») — это документ, в котором описывается запрос от бизнеса по логике и специфике работы системы БЕЗ учета технической реализации. Скоро будет статья на жту тему.

Делайте ТЗ

Отсутствие ТЗ фатально.

Это относится как с Исполнителям, Заказчикам и даже Партнерам по проекту: если вы заранее не договоритесь о результате работы, вам не на что будет опираться, когда придет время приемки работ.

Многие честные люди погубили свои отношения и проекты просто потому что не договорились на берегу и не описали свои ожидания в ТЗ.

Не пишите все и сразу

Вопросы, которые вам заранее неизвестны могут таковыми и остаться. Главное, сделать пометку, когда конкретно будет корректировка ТЗ.

Также, абсолютно нормально представить варианты технологий, которые предстоит попробовать для оптимального решения задачы.

Если у заказчика нет технического навыка, он всегда будет недоволен

У людей, не понимающих принципов разработки ПО, до начала проекта складывается крайне размытая картинка результата. И даже ТЗ тут не поможет.

Если предположить, что ваш заказчик / руководитель более менее адекватный человек, чтобы его удовлетворить, всегда нужно сделать больше, чем вы прописали и сказать об этом.

Помните, что вас всегда обманут

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

Если нет референсов, то оценка проекта возможна только после ТЗ

Если вы разрабатываете площадку, у которой меньше 2-3 референсов, то сказать стоимость и срок разработки возможно только после составления ТЗ.

Вообще нет референсов? Тогда очень важно сделать Прототип

Прототип — это визуально очень упрощенная версия дизайна, которая позволяет блок-схемой накидать основной функционал на странице. Это позволяет на этапе проектирования понять удобство использования будущего продукта, В 100% СЛУЧАЕВ увидеть насколько много вы и заказчик забыли прописать в ТЗ и спланировать. Короче, прототип иногда невероятно спасает и дает сразу +20-30% к успеху разработки.

ТЗ возможно сделать только в плотной кооперации заказчика, специалиста области и IT-архитектора

Этим грешат большие фирмы и некоторые агентства: ТЗ составляют проджекты, а еще хуже продажники. А в процессе проекта не допускают архитектора до клиента.

Да, фирме так легче продавать, только качество продукта и настроение в команде страдают. Если вы заказчик, то требуйте общения с архитектором, если вы отдел разработки, то требуйте доступа к клиенту.

«Сущности» и «Сценарии»

В каждом из них вы описываете:

  1. Сущности (пример «Соц сеть: Пользователь, Друг, Чат, Участники чата, Сообщение, Прикрапление, …»)
  2. Свойства Сущностей (пример «Пользовать- имя, фамилия, адрес, email, дата последнего захода, …»)
  3. Сценарии, которые с ними происходят (пример «Добавление в друзья: после добавления в друзья у человека автоматически создается чат с приветственным сообщением обоим участникам, отправкой письма на почту и …»)

Более подробно я раскрою это в статье, но если упрощенно, то вы из «Сущностей» напишите «Models», а из «Сценариев» сделаете «Controllers».

Рисуйте

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

Вот несколько примеров: карта сущностей и их взаимосвязей, карта сервисов и их расположение на серверах, карта модулей и их зависимость друг от друга (+ каналы коммуникации), EPC Сценария и так далее.

Не бойтесь выделять самые большие куски в отдельные ТЗ

Видите, что какой-то Сценарий слишком большой? Вынесите в отдельный документ и приложите ссылку в ТЗ

Скоро будет продолжение

Нужна помощь с ТЗ?

Уже есть ТЗ или БФТ? Тогда можете его отправить, я посмотрю и скажу рекомендации. Если ТЗ нет, то подскажу, что надо собрать, чтобы начать его делать.

Интересно? Кликайте сюда (переход в Контакты)

Гораздо больше контента и развлечений в Telegram-канале