- PVSM.RU - https://www.pvsm.ru -
Я ни разу не читал сравнение методов подхода к разработке сайтов. Прекрасно понимаю, насколько это будет субъективно: каждый хвалит то, что умеет делать. И всё же, я решил обобщить свой опыт и наблюдения за тем, как это делают другие. В нашей сфере существует, грубо говоря, три наиболее популярных метода: проектирование, написание «ТЗ» и Agile. Вот их-то я и сравню.
На всякий случай договоримся о терминах:
Методология сравнения проста как пареная репа: рассматриваем каждый метод с точки зрения его плюсов и минусов, применимости. Всё субъективно, основано на личном опыте и опыте коллег. Рассматривать я буду каждый подход применительно к двум самым распространённым типам сайтов — корпоративный сайт компании и коммерческий стартап-сервис.
Буду очень признателен, если кто-то будет со мной спорить, поделиться собственными мыслями. Ради этого и пишу, собственно. Если кому-то покажется, что я за проектирование — вам не показалось.
Проектирование — это щепетильное создание модели сайта, которая описывает его бизнес-задачи, контекст и решения. В результате проектирования мы получаем чёткое понимание, что, зачем и как мы должны сделать, какие ресурсы и когда на это потребуются.
С точки зрения процесса проектирование — длительное, трудоёмкое, нерво- и умозатратное занятие, которое выглядит примерно так: сбор информации, исследование контекста, создание концепции, создание персонаже и сценариев, описание коммуникации: содержание, стиль, создание архитектуры: функциональная и информационная, оценка ресурсов, создание графика работ.
Бриф — это наброски требований, модели и структуры сайта с требования заказчика «каким должен быть сайт: креативным, информативным, функциональным, с форумом и кнопками социальных сетей».
Бриф часто делается на основе заполнения анкеты исполнителя или вообще пишется заказчиком. Об этом выскажусь в следующей статье и уже говорил в Как поставить задачу для простого (шаблонного) сайта [4].
Процесс чаще всего выглядит так: поговорили с клиентом, набросали требования, набросали структуру, описали, что будет в разделах, выбрали CMS.
Agile — это гибкое управление процессом, который разбит на так называемые спринты — короткие участки с конкретной задачей и сроком, по результату которого мы получаем нечто рабочее.
У Agile две особенности. Во-первых, этот подход не даёт общей картины, а, значит, не позволяет планировать и прогнозировать в более-менее дальней перспективе. Во-вторых, понимание общей идеи может быть уточнено по ходу вплоть до полного переосмысления. Делаем видеочат? Да. Для чего? Для сервиса консультаций. Окей, что для этого нужно: видео и аудио связь, настройки, регулировка размера окна, фуллскрин, трансляция рабочего стола. Поехали. Сделали. А как он должен работать? Не просто соединять пользователей? Соединять авторизованных пользователей?! Позволять управлять ими? Позволять подключаться админу к разговору? Это практическая полная переделка механизма, кроме протокола передачи данных. Поехали. Ещё два месяца.
Итак, моё личное мнение по поводу применимости вышеописанных подходов.
Проектирование полезно везде, кроме сайтов с бюджетом, не позволяющим проектировать. Если сайт простой, то проектирование можно сделать довольно быстро, сократив время на исследование и продумывание. Это не даст суперкачества, но всё же будет намного лучше брифа.
Бриф применим только там, где нет денег или умения. В отсутствие нескольких дней на сокращённое проектирование по полному циклу я не верю: это лень и некомпетентность.
Я не верю в эффективность Agile, когда дело касается бизнес-проекта. Вообще Agile Manifesto писался как подход к разработке ПО, но его ловко перетащили в управление любыми проектами и возвели чуть ли не в новую религию, которая позволяет сделать то, что не позволяют «консервативные водопадные модели».
Agile не подразумевает планирования и общей чёткой цели. «Работающий продукт важнее, чем полная документация». Да, но это, с учётом методологии, мотивирует разработчиков решать задачи по принципу «работает — и хорошо», что мало способствует быстрому и эффективному достижению бизнес-цели. «Реакция на изменения важнее, чем следование плану.» Так то оно так, да не в случае бизнес-проекта. Откуда берутся изменения? Чаще всего, от непонимания цели. Если мы ставим на реакцию на изменение, значит, увеличиваем срок и стоимость разработки. Бесконечные переборы вариантов, так и сяк, но всё не то, потому что то в случае Agile может получиться только случайно.
Ещё одна проблема Agile в клиентских проектах в том, что разработчик фактически не несёт никакой ответственности за конечный бизнес результат (а не программный). Сделали спринт — показали заказчику или менеджеру — утвердили — дальше. Заказчик вынужден, глядя на промежуточные результаты, брать ответственность за конечный бизнес-результат на себя. Разве он может? Чаще всего, нет. А когда он получает не то, что ему надо, возразить нечего: он сам утверждал результаты всех спринтов.
На мой взгляд, Agile работает в двух случаях, когда дело касается сайтов. Во-первых, когда команда сама себе заказчик и носитель знания и идеи. Ребята чётко знают, что хотят, идут к этому весело и бодро, тратят своё время, готовы к рискам. Во-вторых, когда нужно сделать нечто «промо-подобное»: thedeepestsite.com/. [5] Это не отменяет необходимость проектирования, но здесь оно имеет право быть поверхностным и давать только чёткое понимание задачи, а не расписывать модель и все этапы детально. Если расписать модель детально, это сильно ограничивает последующий «креатив».
Автор: Altunik
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/agile/8716
Ссылки в тексте:
[1] Техническое задание на сайт: http://habrahabr.ru/post/138749/
[2] Техническое задание: как уберечь себя от ошибок и рисков: http://habrahabr.ru/post/139835/
[3] Типовой шаблон технического задания на разработку сайта: http://habrahabr.ru/post/84422/
[4] Как поставить задачу для простого (шаблонного) сайта: http://habrahabr.ru/post/125457/
[5] thedeepestsite.com/.: http://thedeepestsite.com/.
Нажмите здесь для печати.