Я никогда не видел сравнения методов создания веб-сайтов.
Я прекрасно понимаю, насколько это будет субъективно: каждый хвалит то, что умеет. И все же, я решил обобщить свой опыт и наблюдения, как это делают другие.
В нашей сфере есть, грубо говоря, три наиболее популярных метода: дизайн, написание технического задания и Agile. Вот это я буду сравнивать.
На всякий случай согласуем условия:
- Дизайн - это детальное исследование с исследованием: задач, концепции, коммуникации, архитектуры, оценки ресурсов.
Я уже неоднократно писал об этом (вы можете увидеть это в списке моих постов) и буду писать дальше.
- Краткое (иногда его называют ТЗ, что по сути неверно) — требования, общая структура сайта на уровне разделов верхнего уровня и их краткое описание.
Об этом авторы Хабра писали в различных статьях: Технические характеристики сайта , Техническое задание: как обезопасить себя от ошибок и рисков или Типовой шаблон технического задания на разработку сайта
- Гибкий — определили общую идею, общие требования, осуществили дизайн в меру нашего желания и возможностей — сценарии, пользователи, архитектура — и понеслось.
Никто не знает, когда сайт будет запущен; это решается по ходу дела.
Б.
Пожалуйста, обратите внимание, уважаемые приверженцы agile! Я намеренно использую термин Agile иначе, чем он написан в Википедии или в Манифесте.
Я использую его для обозначения подхода, при котором команда разработчиков не знает, каким будет конечный результат, и работает короткими очередями, оценивая промежуточные результаты.
Именно такой подход к созданию сайта я имел «удовольствие» наблюдать несколько раз.
Методика сравнения проста как пареная репа: мы рассматриваем каждый метод с точки зрения его плюсов и минусов и применимости.
Все субъективно, основано на личном опыте и опыте коллег.
Я буду рассматривать каждый подход применительно к двум наиболее распространённым типам сайтов — корпоративному сайту компании и коммерческому стартап-сервису.
Буду очень признателен, если кто-нибудь поспорит со мной и поделится своими мыслями.
Собственно, поэтому я и пишу.
Если кому-то кажется, что я за проектирование, то вам так не кажется.
Дизайн
Дизайн — это тщательное создание модели сайта, описывающей его бизнес-задачи, контекст и решения.В результате проектирования мы получаем четкое понимание, что, почему и как нам следует сделать, какие ресурсы и когда это потребуются.
С точки зрения процесса дизайн — это длительная, трудоемкая, нерво- и умственно-затратная задача, которая выглядит примерно так: сбор информации, исследование контекста, создание концепции, создание персонажей и сценариев, описание коммуникации: контент, стиль, создание архитектуры: функциональной и информационной, оценка ресурсов, создание графика работы.
Плюсы
- Позволяет тестировать идеи.
Допустим, у заказчика есть представление о сайте.
Как понять, как это реализовать на практике: каким должен быть дизайн, какие функциональные решения применить, что рассказать посетителю, сколько это будет стоить и отнять время, есть ли для этого ресурсы, осуществимо ли это с точки зрения представление об организационной структуре заказчика? Ни в коем случае, если вы не занимаетесь дизайном.
- Предоставляет выбор решения .
Мы спроектировали сайт, видим возможные архитектурные, функциональные и дизайнерские решения и можем выбирать, как и что делать в зависимости от имеющихся ресурсов.
- Повышает эффективность.
Дизайн делает сайт нацеленным на решение задач, соответствующих потребностям целевой аудитории и контексту, а не чьим-то субъективным представлениям/желаниям.
- Предоставляет хороший инструмент для выбора подрядчика.
Выбрать подрядчика можно по рекомендации, портфолио, личному ощущению, интуиции – по-разному.
Но проект, который можно посмотреть и оценить его реализацию, является отличным инструментом для проведения тендера по критерию «цена/качество».
- Позволяет оценить затраты и сроки.
Думаю, комментировать не нужно.
Есть проект – есть самая точная оценка.
По сравнению с другими методами.
- В конечном итоге это экономит ресурсы и время.
Дизайн повышает точность решений, а, следовательно, снижает риск ошибок, которые всегда приводят к дополнительным затратам на разработку сайта и все, что с ним связано.
Минусы
- Дороже и дольше, чем ТК.
Обычно не менее 50 тысяч рублей, если делать добросовестно.
- Нужно учиться .
Чтобы хорошо проектировать, нужно перерыть тонну литературы, разобраться в десятках проектов, а также иметь способности.
- Не каждый разработчик понимает, как работать проект .
Недостаток знаний, опыта, слишком привык к делу.
Краткий
Бриф — это изложение требований, модели и структуры сайта с требованием заказчика «каким должен быть сайт: креативным, информативным, функциональным, с форумом и кнопками социальных сетей».Бриф часто составляется на основе заполнения анкеты от подрядчика или вообще пишется заказчиком.
Об этом я расскажу в следующей статье и уже говорил в Как поставить задачу на простой (шаблон) сайт .
Процесс чаще всего выглядит так: поговорили с клиентом, обозначили требования, набросали структуру, описали, что будет в разделах, выбрали CMS.
плюсы
- Быстрый .
Можно собрать за день-два.
- Дешевый .
Сколько стоит пара дней написания брифа в обычной веб-студии? Пара тысяч рублей.
- Есть определенная свобода действий.
Бриф можно интерпретировать так или иначе.
Например, что означает, что в брифе есть фраза «на корпоративном сайте будут новости»? Ничего, кроме того, что будут новости.
Вы можете сделать их так, а можете сделать так.
Первый займёт 2 дня, а второй – неделю.
Для кого это плюс? Для человека с более сильным характером.
Минусы
- Не продумано.
Слишком мало информации, анализа, необоснованный выбор решений.
Это влечет за собой ошибки, лишние деньги, потраченное время или необходимость запустить плохой сайт, потому что «власть требует», «пора» и т. д.
- Не позволяет реально оценить ресурсы и сроки.
Потому что не хватает детализации и понимания (см.
пункт 1).
- См.
пункт 3 в плюсах.
Гибкий
Agile — это гибкое управление процессами, разбитое на короткие участки с конкретной задачей и сроком выполнения, в результате чего мы получаем что-то работающее.Agile имеет две особенности.
Во-первых, такой подход не дает общей картины, а значит, не позволяет планировать и прогнозировать в более или менее долгосрочной перспективе.
Во-вторых, понимание общей идеи может уточняться по пути к полный переосмысление.
Занимаетесь видеочатом? Да.
За что? Для консультационных услуг.
Ладно, что для этого нужно: подключение видео и аудио, настройки, регулировка размера окна, полноэкранный режим, трансляция рабочего стола.
Идти.
Сделанный.
Как это должно работать? Не просто подключаете пользователей? Подключить авторизованных пользователей?! Разрешить ими управлять? Разрешить администратору присоединиться к беседе? Это практическая полная переработка механизма, за исключением протокола передачи данных.
Идти.
Еще два месяца.
плюсы
- Быстрый старт. Вы можете начать делать это сразу, не тратя время на документацию.
Правда, полезность этого пункта связана и с некоторыми другими.
Например, со следующим.
- Есть что показать инвестору, прежде чем начнется реальная застройка.
Инвесторы очень хорошо реагируют на то, что работает и демонстрирует идею.
Если быстро сделать прототип, можно быстро получить деньги и продолжить путь проектирования.
- Быстрые результаты и тестирование идеи на реальных пользователях.
Сделали основную часть сервиса или сайта (можно вспомнить модный flexscope), показали ее пользователям, получили обратную связь, что-то изменили и пошли дальше.
Здесь стоит отметить, что результат может быть быстрым и рабочим, но недостаточным для решения бизнес-задачи, и отзыв будет касаться конкретной детали, а не сервиса как такового.
Например, при создании интернет-магазина не обойтись только быстро составленным каталогом: нужна оплата и информация о наличии товара, чтобы не брать деньги за несуществующий товар.
А это потребует гораздо более детального изучения бизнес-процессов, а значит, нового проектирования, разработки и тестирования.
- Гибкость процесса.
Возможность менять идеи и функционал на лету.
Те.
Если вы вовремя поймете, что поступаете неправильно, вы сможете сэкономить время и деньги.
Но только великие гуру Agile знают, как понять это без анализа.
Я не знаю.
Минусы
- Нет критериев эффективности финальный результат. С точки зрения бизнеса непонятно, что произойдет, как это оценить, решит ли то, что мы делаем, наши бизнес-задачи.
- Непредсказуемость.
См.
пункт 1, а также невозможность планировать ресурсы и события, связанные с доступностью сайта.
Сколько клиентов готовы в это вписаться?
- дольше и дороже .
Да, я так думаю, потому что в Agile оплачивается каждый час, потраченный командой разработчиков, и, будьте уверены, господин Заказчик, этих часов будет очень много.
Потому что мы не знаем, что и зачем делаем, мы прислушиваемся к любому вашему капризу, готовы перелопатить всю архитектуру, ведь вы за это платите.
выводы
Итак, мое личное мнение относительно применимости вышеизложенных подходов.Дизайн полезен везде, кроме сайтов с бюджетом, не позволяющим разработать дизайн.
Если сайт простой, то дизайн можно сделать довольно быстро, сократив время на исследования и размышления.
Это не даст супер качества, но все равно будет намного лучше брифа.
Краткий применимо только там, где нет денег или навыков.
В нехватку нескольких дней на сокращенное проектирование полного цикла я не верю: это лень и некомпетентность.
Я не верю в эффективность Гибкий если речь идет о бизнес-проекте.
В общем, Agile-манифест был написан как подход к разработке ПО, но его умело затащили в управление любыми проектами и возвели чуть ли не в новую религию, позволяющую делать то, что не позволяют «консервативные водопадные модели».
«Рабочий продукт важнее полной документации».
Да, но это с учетом методологии мотивирует разработчиков решать задачи по принципу «работает и хорошо», что мало что дает для быстрого и эффективного достижения бизнес-цели.
«Реагировать на изменения важнее, чем следовать плану».
Это так, но не в случае бизнес-проекта.
Откуда берутся изменения? Чаще всего от непонимания цели.
Если мы полагаемся на реакцию на изменения, это означает, что мы увеличиваем время и стоимость разработки.
Бесконечные поиски вариантов, так и сяк, но все не то, потому что в случае с Agile такое может произойти только случайно.
Еще одна проблема Agile в клиентских проектах заключается в том, что разработчик фактически не несет никакой ответственности за конечный бизнес-результат (не программное обеспечение).
Сделали спринт — показали заказчику или менеджеру — одобрили — идем дальше.
Заказчик вынужден, глядя на промежуточные результаты, брать на себя ответственность за конечный бизнес-результат. Он может? Чаще всего нет. А когда он не получает того, что ему нужно, возразить нечего: он сам утверждал результаты всех спринтов.
На мой взгляд, когда дело касается веб-сайтов, Agile работает двояко.
Во-первых, когда команда является собственным заказчиком и носителем знаний и идей.
Ребята четко знают, чего хотят, идут к этому весело и весело, проводят время и готовы рисковать.
Во-вторых, когда нужно сделать что-то «промо»: thedeepestsite.com .
Это не отменяет необходимости проектирования, но здесь оно имеет право быть поверхностным и давать лишь четкое понимание задачи, а не подробно описывать модель и все этапы.
Если подробно описывать модель, это сильно ограничивает последующее «творчество».
Теги: #дизайн #agile #спецификации #технические спецификации #проект #зачем проектировать #кратко #управление проектом
-
Лучшие Онлайн-Работы Для Подростков 18 Лет
19 Oct, 24 -
Ваш Домашний Сервер
19 Oct, 24 -
Онлайн-Ролевая Игра Ecilavia На Webgl
19 Oct, 24 -
Разработка Браузера — Уровень Представления
19 Oct, 24
