Какие подходы существуют для разработки и обновления веб-сайта?

Привет! Разработка и обновление веб-сайтов, особенно на WordPress, может быть организована различными способами, что позволяет улучшить процесс создания технических заданий и минимизировать количество доработок. Вот несколько подходов и методик, которые могут помочь в этом:

### 1. **Agile и Scrum**
- **Итеративная разработка:** Вместо того чтобы разрабатывать весь функционал сразу, используйте итеративный подход. Разделяйте проект на небольшие части (так называемые «спринты»), что позволяет быстрее получать обратную связь и вносить изменения.
- **Постоянная коммуникация:** Регулярные встречи с командой разработчиков для обсуждения текущего статуса и возникающих вопросов.

### 2. **User Stories**
- Определяйте требования в формате "как [тип пользователя], я хочу [цель], чтобы [причина]". Это помогает сосредоточиться на потребностях пользователей и упрощает процесс формулирования задач.

### 3. **Прототипирование**
- Используйте инструменты для создания прототипов (например, Figma, InVision), чтобы визуализировать ваши идеи до написания кода. Это поможет избежать недопонимания и упрощает процесс составления ТЗ.

### 4. **Документирование**
- Создайте шаблон для технических заданий, который включает основные блоки: описание, функциональные требования, пользовательские сценарии, визуализации и временные рамки.
- Храните документацию в облачном хранилище (например, Google Drive, Notion) и обновляйте ее по мере необходимости.

### 5. **Feedback Loops**
- Установите механизм регулярного получения обратной связи от пользователей и тестировщиков, чтобы выявлять проблемы и потребности на ранних этапах.

### 6. **Декомпозиция задач**
- Разделите задачи на более мелкие подзадачи, чтобы можно было легче отслеживать прогресс и вносить коррективы.

### 7. **Отчетность и анализ ошибок**
- Ведите учет всех доработок и помимо этого анализируйте, почему возникли те или иные проблемы в технических заданиях. Это поможет скорректировать процесс составления ТЗ в будущем.

### 8. **Инструменты управления проектами**
- Используйте Trello, Jira или аналогичные инструменты для управления задачами. Они помогут организовать работу и отслеживать выполнение.

### 9. **Код-ревью**
- Практика код-ревью позволяет выявлять ошибки на ранних стадиях и может быть частью процесса передаточной документации.

### 10. **Обучение команды**
- Организуйте обучения для своей команды, чтобы они лучше понимали требования и могли давать более точные оценки трудозатрат.

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

Все зависит от организации работы в конкретной конторе и конкретного разработчика, но лично у меня работает следующий подход: 
 1. Пишем начальное тз, минимальный необходимый перечень. 
 2. Говнокодим на основание п1 по принципу - "сделать быстро и чтобы работало по тз". 
 3. Пушим п2 в гит и разворачиваем сайт (или компонент на сайте). 
 4. Записываем фидбэк о компоненте, что не работает, как хотелось бы чтобы работало итп. Если это не критические замечания (безопасность или что то основное не работает), то откладываем изменения на месяц, квартал или год. 
 5. При накопление критической массы замечаний в п4 (ну или у Вас просто не осталось задач на настоящий момент) - добавляем рефакторинг п3 в очередь задач. 
 6. Повторяем 3-6 пункты до бесконечности. 
 
 При данном режиме работы решается сразу 3 задачи: 
 - Не требуется детальное тз на старте, в котором все равно не удастся предвидеть все наперед, соответственно сокращается общее время разработки и его стоимость. 
 - Сайт или компонент сайта выпускается в релиз очень быстро, а значит решает задачу бизнеса так же быстро. 
 - Прозрачный и прогнозируемый по срокам и стоимости режим релизов. 
 
 Важное уточнение! 
 
 Схема с минимальным ТЗ и говнокодом работает лишь с теми заказчиками, которым Вы подробно разъяснили, почему сроки и стоимость ниже, почему за каждую "хотелку" не указанную в тз придется доплачивать, и почему необходим рефакторинг. 
 
 Идеальный вариант, донести до заказчика мысль, что проект будет требовать постоянного финансирования (в определенном ежемесячном объеме) на разработку новых или рефакторинг старых компонентов. В таком случае у Вас всегда будет под рукой разработчик, который сможет оперативно и за привычную стоимость решить поставленную задачу, который уже привык работать в таком режиме и ему не нужно лишний раз объяснять одно и то же.

у нас дизайнер в фигме всё рисует, мы только делаем что он там понарисовал