Ну, конечно, все, что может вам посоветовать сотрудник интернет-агентства – это обратиться в веб студию. Но мы тут с вами поговорим про разработку.
Первое, что необходимо сделать – это определить, что есть «лишняя работа» и какие цели бизнес ставит перед проектом. Для этого в компаниях всегда просят бриф/примеры и общее назначение продукта.
Дальше разработка оценивает масштаб проекта, пожелания клиента по поддержке и развитию ресурса, и выносит соответствующие рекомендации по наиболее оптимальному решению – об этом поговорим подробнее:
- Конструктор сайтов - вариант для сайтов визиток/лендингов и т.п., что не требует участия разработчиков, постоянной поддержки и хранения данных. Такие проекты быстры в реализации и остаются прекрасным вариантов для демонстрации возможностей бизнеса.
- CMS - это система управления контентом. Соответственно подойдет для проектов, направленных на подачу материала в рамках блогов/новостных порталов и систем, где архитектурно не предполагается широкая масштабируемость и нагрузка.
В данном случае это определенный принцип разработки в рамках требований документации, но существенно облегченный отсутствием потребности в дополнительных библиотеках и ПО работы с файлами в рамках административной панели.
Разработчики точно знаю, что клиент разберется с контентом и работой ресурса, а заказчик точно знает, что и где можно найти в рамках обратной связи от пользователей или статистики взаимодействия. - Фреймворк – программный каркас, который задает шаблон разработки и подразумевает тонкую настройку алгоритмов и структур страниц.
Система легко обновляется, расширяется, поддерживает стандарты программирования и позволяет гибко настраивать среду.
Поэтому если проект предполагает развитие, расширение, нагрузку, поддержку – всегда остается на выбор фреймворк, покрывающий все требования архитектуры ПО для дальнейшей детальной проработки моделей.
(Существенным плюсом является отсутствие постоянной подписки на лицензии продуктов – в отличии от cms). - Приложение – в данном случае речь идет, как о декстоп, так и о мобильной разработке. Чаще всего это вопрос именно оффлайн доступности функционала, синхронизация которого с бэкенд частью происходит периодически и направлена на взаимодействия с прикладными потребностями пользователя. (Контроль питания, Фитнес-центры, Стриминговые платформы и т.п.).
И вот когда направление разработки было выбрано, можно приступать к самому главному (Все смеялись, когда нас учили, что ТЗ – это 60% работы над продуктом, но теперь все плачут, когда клиент приходит только с брифом и сжатыми дедлайнами).
Почему же написание технической документации так сильно может избавить от «лишней работы» – объясню на примере этапов разработки продукта:
- Планирование ресурса – имея на руках четкую спецификацию, задачи можно декомпозировать и четко понимать временные затраты на тот или иной функционал, структуру и связанность.
- Дизайн – с описанием структуры продукта, не нужно гадать, принимать решения со стороны проектирования(возможно неэффективные – так как нет понимания связанности модулей или бизнес требований) и просто ждать бесконечно утверждения и фидбэка клиента.
- Разработка – четкое описание алгоритмов, позволяет разработчикам выстроить архитектуру продукта наиболее выгодно для клиента и дальнейшей поддержки проекта. Потому что ни редко клиент приходит – смотрит на форму обратной связи и говорит о том, что еще нужно отправлять данные во внешние сервисы и оповещать пользователей об ответах на почту, и вот целостный модуль приходится переписывать с нуля, от чего страдает чистота кода.
- Тестирование – этап на котором просто невозможно без технической документации осуществлять проверку продукта. Поэтому независимо от того предоставил клиент техническое задание или нет, команда прописывает все входные и выходные параметры и доносит функциональные требования на этом этапе.
- Утверждение – разработка даже самого просто лендинга – это дело не одной недели, за это время все идеи, нюансы, запросы клиента могут потеряться из фокуса, поэтому наличие четких требований – поможет сориентироваться в продукте и не переживать, что было что-то упущено.
Самое главное от чего могу возникнуть «лишние работы» – это спешка. Не нужно торопить разработку, просить сделать проще и быстрее, а потом заниматься доработками и переработками разделов, потому что это всегда риски безопасности и отказоустойчивости продукта. А еще это всегда неэффективно как финансово, так ресурсно.
Делай хорошо, не делай плохо.
