Как написать ТЗ к 3 проектам за неделю и не сойти с ума

Сама по себе разработка является воплощением задуманных идей во что-то “реальное” - код или в нашем случае набор элементов в конструкторе. В разработке есть свои тонкости и зачастую существует несколько вариантов реализации одной и той же идеи, но выбор варианта всегда связан с другими элементами и общим контекстом проекта.

Более важным элементом реализации проекта является планирование - ведь без четкого плана и договоренностей с клиентом по каждому критическому вопросу в моменте разработки начинается фрустрация и метания между тем, чтобы сделать на свой вкус, и тем, чтобы напрячь клиента, который зачастую сам не знает, как именно должно быть. И как бы не хотелось опустить руки и “сделать все как-нибудь, а потом разберемся”, очень важно потратить достаточное количество времени на написание документации к проекту и согласовать все наиболее важные моменты.

Поэтому сегодня я расскажу, как выглядит мой процесс подготовки к работе над проектом.

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

2. Далее нам нужно сгруппировать эти юзер сториз по ролям и выстроить их по порядку. Порядок может быть условно хронологическим, так как некоторые процессы могут выполняться параллельно.

3. Перед тем как углубляться в эти юзер сториз, нужно проанализировать текущие и подумать, не пропущены ли какие-либо части - для этого можно использовать ChatGPT и попросить его дополнить список или задать вопросы к ТЗ с точки зрения критика.

4. Слона лучше есть по кусочкам и поэтому далее я расписываю каждую историю по трем пунктам - интерфейс, база данных, бэкенд. Это помогает фокусироваться на конкретной сториз и думать, как она связана с другими частями приложения, находить упущенные детали и подготавливать вопросы для клиента.

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

- Для базы данных я указываю таблицу, поля и тип данных, которые будут задействованы в этой юзер сториз

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

5. После прохождения по всем сториз у меня набирается ряд вопросов, которые я оставляю комментариями в документе (я работаю в Google Docs).

6. После уточнения всех деталей, я перехожу к сборке каждой из частей - интерфейса, базы данных и бэкенда.

7. На основе описания всех частей можно приступать к созданию дизайна.

Таким образом на выходе у меня оказывается полноценное и согласованное описание проекта. Далее я перехожу к разработке.

P.S. до ноукода я год работал бизнес-аналитиком и писал ТЗ на внедрение Битрикс-24. Там я набрался опыта и выработал собственные принципы по написанию документации. Последний проект был реализован после моего ухода на основе моего ТЗ на 70 страниц.

Ставьте лайк и подписывайтесь, а таже делитесь в комментариях своим подходом к планированию проекта, мне будет интересно узнать новые best practices и улучшить свой процесс