Написать ТЗ

[murzindima]

• [ ] Функциональные требования
• [ ] Нефункциональные требования

Документ должен описывать технический скоуп работ:

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

• [ ] Зафиксированы функциональные и нефункциональные требования к решению. При выработке SLO команда самостоятельно принимает решения о балансе: идеальная архитектура, текущая архитектура или сделать на коленке в зависимости от сроков и важности проекта.

• [ ] Проект должен быть декомпозирован по продуктовым фичам, а декомпозиция провалидирована лидом.

• [ ] Понятна очерёдность выпуска фич, определена и зафиксирована дата релиза всего проекта.

• [ ] Техническое задание нужно согласовать с заказчиком. Постарайтесь найти решение win/win, устраивающее как разработку, так и бизнес.

[murzindima]

Всё работает Понятна польхователям – типа что туда ходи, туда не ходи Код "красивый" Ошибки обрабатываются правильно и 500 почти нет

[murzindima]

Функциональные требования — это любые требования, которые отвечают на вопрос: «Что должно быть сделано, чтобы идея работала?» Чем лучше вы декомпозируете требования, тем легче будет потом их реализовывать.

Нефункциональными требованиями обычно называют те, которые задают ограничения вашей идее. Обычно это требования к безопасности, отказоустойчивости, скорости работы — по сути, всё то, что не относится напрямую к вашей идее, но без реализации этих требований пользователи могут не воспринять вашу задумку.

[murzindima]

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

[murzindima]

• Проблематика. Зачем мы делаем этот проект? Какую боль хотим закрыть? Какую задачу решить? Что нового узнать?

• Ограничения. Платформы, на которых вносим изменения (десктоп, мобильные приложения). Как выкатываем? Планируются ли A/B-тесты? Закладывается ли этапность в разработке? Для каких типов пользователей мы вносим изменения? Есть ли у релиза желаемый срок, если он,например, приурочен к какому-то событию?

• Макеты. Ссылки на все описания макетов для всех платформ. Если вы начинаете с какой-то одной платформы, то макеты нужны только для неё. Ещё нужно понимать, что макеты могут быть не финальными и меняться во время разработки.

• Список дел. По каждой платформе сделайте описание того, что нужно изменить. Обязательно со скриншотами из макетов, чтобы подкрепить объяснения визуальной частью. Вообще, многие вещи проще зафиксировать картинкой.

• Нулевые состояния. Нулевые выдачи, незаполненные заявки, неоформленные профили и т.д.

• Рассылки или пуши. Какой текст пишем в письме или СМС? В каком шаблоне отправляем? Куда возвращаем пользователя с пуша?

• Сценарии. С каких экранов и куда переходит пользователь? Что за чем происходит? Если поведение везде одинаковое, то это тоже нужно указать.

• Служба поддержки. Нужна ли выделенная админ-панель для сотрудника клиентской службы или службы поддержки, чтобы обеспечить бесперебойную работу сервиса?