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