Сравнение подходов к созданию сайта: проектирование, бриф и agile

    Я ни разу не видел сравнения методов подхода к созданию сайтов. Прекрасно понимаю, насколько это будет субъективно: каждый хвалит то, что умеет делать. И всё же, я решил обобщить свой опыт и наблюдения за тем, как это делают другие. В нашей сфере существует, грубо говоря, три наиболее популярных метода: проектирование, написание «ТЗ» и Agile. Вот их-то я и сравню.

    На всякий случай договоримся о терминах:

    • Проектирование — это детальная проработка с исследованием: задачи, концепция, коммуникация, архитектура, оценка ресурсов. Об этом я писал ранее неоднократно (можно посмотреть в списке моих постов) и буду продолжать писать.
    • Бриф (иногда его называют ТЗ, что неправильно по сути)— требования, общая структура сайта на уровне разделов верхнего уровня и их краткого описания. Об этом писали хабра-авторы в разных статьях: Техническое задание на сайт, Техническое задание: как уберечь себя от ошибок и рисков или Типовой шаблон технического задания на разработку сайта
    • Agile — определили общую идею, общие требования, провели в меру желания и способностей проектирование — сценарии, пользователи, архитектура — и понеслась. Никто не знает, когда сайт можно будет запускать; это решается по ходу.

    NB. Прошу обратить внимание, уважаемые agile-адепты! Я сознательно использую термин Agile не так, как об этом написано в Википедии или в Манифесте. Я использую его для обозначения подхода, когда команда разработчиков не знает, что получится в итоге и действует короткими пробежками с оценкой промежуточных результатов. Именно это я имел «удовольствие» несколько раз наблюдать как подход к созданию сайта.

    Методология сравнения проста как пареная репа: рассматриваем каждый метод с точки зрения его плюсов и минусов, применимости. Всё субъективно, основано на личном опыте и опыте коллег. Рассматривать я буду каждый подход применительно к двум самым распространённым типам сайтов — корпоративный сайт компании и коммерческий стартап-сервис.

    Буду очень признателен, если кто-то будет со мной спорить, поделиться собственными мыслями. Ради этого и пишу, собственно. Если кому-то покажется, что я за проектирование — вам не показалось.

    Проектирование


    Проектирование — это щепетильное создание модели сайта, которая описывает его бизнес-задачи, контекст и решения. В результате проектирования мы получаем чёткое понимание, что, зачем и как мы должны сделать, какие ресурсы и когда на это потребуются.

    С точки зрения процесса проектирование — длительное, трудоёмкое, нерво- и умозатратное занятие, которое выглядит примерно так: сбор информации, исследование контекста, создание концепции, создание персонажей и сценариев, описание коммуникации: содержание, стиль, создание архитектуры: функциональная и информационная, оценка ресурсов, создание графика работ.

    Плюсы

    1. Позволяет проверить идеи. Вот есть, допустим, у заказчика представление о сайте. Как понять, как его реализовать на практике: каким должен быть дизайн, какие функциональные решения применить, что говорить посетителю, сколько это будет стоить и займёт времени, есть ли на это ресурсы, реализуемо ли это с точки зрения организационной структуры заказчика? Никак, если не проектировать.
    2. Даёт возможность выбора решений. Мы спроектировали сайт, видим возможные архитектурные, функциональные и дизайнерские решения и можем выбирать, как и что делать в зависимости от имеющихся ресурсов.
    3. Повышает эффективность. Проектирование делает сайт нацеленным на решение задач, соответствующим потребностям ЦА и контексту, а не чьим-то субъективным представлениям/желаниям.
    4. Даёт хороший инструмент для выбора подрядчика. Подрядчика можно выбирать по рекомендации, портфолио, личному ощущению, интуиции — по-разному. Но проект, в который можно посмотреть и оценить его реализацию, — это прекрасный инструмент для проведения тендера по критерию «цена/качество».
    5. Даёт возможность оценки стоимости и сроков. Думаю, комментировать не нужно. Есть проект — есть максимально точная оценка. В сравнении с другими методами.
    6. В конечном счёте, экономит ресурсы и время. Проектирование повышает точность решений, а, значит, снижает риск ошибок, которые всегда ведут к дополнительным затратам на разработку сайта и всё, имеющее к нему отношение.

    Минусы

    1. Дороже и дольше, чем ТЗ. Обычно не меньше 50 тысяч рублей, если делать на совесть.
    2. Нужно учиться. Чтобы хорошо проектировать, нужно перелопатить кучу литературы, набить кучу шишек на десятках проектов и иметь к тому же способности.
    3. Не каждый разработчик понимает, как работать по проекту. Не хватает знаний, опыта, слишком привык к брифу.

    Бриф


    Бриф — это наброски требований, модели и структуры сайта с требования заказчика «каким должен быть сайт: креативным, информативным, функциональным, с форумом и кнопками социальных сетей».

    Бриф часто делается на основе заполнения анкеты исполнителя или вообще пишется заказчиком. Об этом выскажусь в следующей статье и уже говорил в Как поставить задачу для простого (шаблонного) сайта.

    Процесс чаще всего выглядит так: поговорили с клиентом, набросали требования, набросали структуру, описали, что будет в разделах, выбрали CMS.

    Плюсы

    1. Быстро.Можно сварганить за день-два.
    2. Дёшево. Сколько стоят пару дней человека, пишущего бриф в обычной веб-студии? Пару тысяч рублей.
    3. Есть определённая свобода действий. Бриф можно трактовать так или так. Например, что означает наличие в брифе фразы «на корпоративном сайте будут новости»? Ничего, кроме того, что там будут новости. Можно их сделать так, а можно так. Первое займёт 2 дня, а второе — неделю. Для кого это плюс? Для того, у кого характер сильнее.

    Минусы

    1. Непродуманно. Слишком мало информации, анализа, безосновательный выбор решений. Это влечёт за собой ошибки, лишние деньги, потраченное впустую время или необходимость запустить плохой сайт, потому что «начальство требует», «уже пора» и т.п.
    2. Не позволяет толком оценить ресурсы и сроки. Потому что недостаточно детализации и понимания (см. пункт 1).
    3. См. пункт 3 в плюсах.

    Agile


    Agile — это гибкое управление процессом, который разбит короткие участки с конкретной задачей и сроком, по результату которого мы получаем нечто рабочее.

    У Agile две особенности. Во-первых, этот подход не даёт общей картины, а, значит, не позволяет планировать и прогнозировать в более-менее дальней перспективе. Во-вторых, понимание общей идеи может быть уточнено по ходу вплоть до полного переосмысления. Делаем видеочат? Да. Для чего? Для сервиса консультаций. Окей, что для этого нужно: видео и аудио связь, настройки, регулировка размера окна, фуллскрин, трансляция рабочего стола. Поехали. Сделали. А как он должен работать? Не просто соединять пользователей? Соединять авторизованных пользователей?! Позволять управлять ими? Позволять подключаться админу к разговору? Это практическая полная переделка механизма, кроме протокола передачи данных. Поехали. Ещё два месяца.

    Плюсы

    1. Быстрый старт. Можно начать делать сразу, не тратя время на документирование. Правда, полезность этого пункта связана с некоторыми другими. Например, со следующим.
    2. Есть, что показать инвестору перед началом реальной разработки. Инвесторы очень хорошо реагируют на нечто работающее и показывающее идею. Если быстро сделать прототип, то можно быстро получить деньги и дальше идти по пути проектирования.
    3. Быстрый результат и проверка идеи на реальных пользователях. Сделали основной кусок сервиса или сайта (можно вспомнить модный flex scope), показали пользователям, получили фидбэк, что-то изменили и пошли дальше. Тут стоит оговориться, что результат может быть быстрым и работающим, но недостаточным для решения бизнес-задачи, а фидбэк будет касаться конкретного куска, а не сервиса как такового. Например, при создании интернет-магазина одним быстро сделанным каталогом не обойдёшься: нужна оплата и данные о наличии товара, чтобы не взять деньги за несуществующий товар. А это потребует гораздо более детальной проработки бизнес-процессов, а, значит, нового проектирования, разработки и тестирования.
    4. Гибкость процесса. Возможность на ходу поменять идею, функциональность. Т.е. если вовремя осознать, что делаешь не то, то можно сэкономить время и деньги. Но как это понять без анализа, знают только великие гуру Agile-а. Я не знаю.

    Минусы

    1. Нет критериев эффективности конечного результата. С точки зрения бизнеса непонятно, что получится, как это оценивать, решает ли наши бизнес=задачи то, что мы сделаем.
    2. Непредсказуемость. См. пункт 1, а также невозможность планировать ресурсы и события, связанные с готовностью сайта. Много ли заказчиков готовы вписаться в такое?
    3. Дольше и дороже. Да, я так думаю, потому что в Agile оплачивается каждый час, потраченный командой разработчиков, а этих часов, будьте уверены, господин заказчик, будет мноооого. Потому что мы не знаем, что и для чего мы делаем, слушаем каждый ваш каприз, готовы перелопатить всю архитектуру, потому что вы за это платите.

    Выводы


    Итак, моё личное мнение по поводу применимости вышеописанных подходов.

    Проектирование полезно везде, кроме сайтов с бюджетом, не позволяющим проектировать. Если сайт простой, то проектирование можно сделать довольно быстро, сократив время на исследование и продумывание. Это не даст суперкачества, но всё же будет намного лучше брифа.

    Бриф применим только там, где нет денег или умения. В отсутствие нескольких дней на сокращённое проектирование по полному циклу я не верю: это лень и некомпетентность.

    Я не верю в эффективность Agile, когда дело касается бизнес-проекта. Вообще Agile Manifesto писался как подход к разработке ПО, но его ловко перетащили в управление любыми проектами и возвели чуть ли не в новую религию, которая позволяет сделать то, что не позволяют «консервативные водопадные модели».

    «Работающий продукт важнее, чем полная документация». Да, но это, с учётом методологии, мотивирует разработчиков решать задачи по принципу «работает — и хорошо», что мало способствует быстрому и эффективному достижению бизнес-цели. «Реакция на изменения важнее, чем следование плану.» Так то оно так, да не в случае бизнес-проекта. Откуда берутся изменения? Чаще всего, от непонимания цели. Если мы ставим на реакцию на изменение, значит, увеличиваем срок и стоимость разработки. Бесконечные переборы вариантов, так и сяк, но всё не то, потому что то в случае Agile может получиться только случайно.

    Ещё одна проблема Agile в клиентских проектах в том, что разработчик фактически не несёт никакой ответственности за конечный бизнес результат (а не программный). Сделали спринт — показали заказчику или менеджеру — утвердили — дальше. Заказчик вынужден, глядя на промежуточные результаты, брать ответственность за конечный бизнес-результат на себя. Разве он может? Чаще всего, нет. А когда он получает не то, что ему надо, возразить нечего: он сам утверждал результаты всех спринтов.

    На мой взгляд, Agile работает в двух случаях, когда дело касается сайтов. Во-первых, когда команда сама себе заказчик и носитель знания и идеи. Ребята чётко знают, что хотят, идут к этому весело и бодро, тратят своё время, готовы к рискам. Во-вторых, когда нужно сделать нечто «промо-подобное»: thedeepestsite.com. Это не отменяет необходимость проектирования, но здесь оно имеет право быть поверхностным и давать только чёткое понимание задачи, а не расписывать модель и все этапы детально. Если расписать модель детально, это сильно ограничивает последующий «креатив».
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 32
    • –1
      Про тег
      <habracut>
      не забыли?
      • 0
        Наверняка забыл. А что с ним сделать надо и зачем?
        • 0
          Из документации:
          <habracut>
          Используется только в текстах постов, скрывает под кат часть текста, следующую за тегом (будет
          написано «Читать дальше»).
          
          <habracut text="Подробности" />
          Так можно превратить надпись «Читать дальше» в любой текст.

          Ваша новость в ленте целиком: могут и заминусовать.
          • +2
            Думаю, вам намекают вставить его в статью после первого абзаца. ;)
          • 0
            Сократил запись в хабе. Это имели в виду?
          • 0
            >servitRM
            Как задолбало читать в статьях комменты, таких подсказчиков, как Вы, в топе комментов статей.
            Неужели трудно автору в личку написать?
          • 0
            По созданию и проектированию сайтов нашел хорошую подборку книг от МИФа
            • 0
              Спасибо. Кое-что не читал, кстати.
            • 0
              Было бы любопытно увидеть, как Вы проектируете — пошаговый процесс, от и до, на реальных примерах.
              • +1
                Я писал об этом в статье Что такое проектирование сайта и почему его нужно делать (от лица коллеги, потому что не было тогда своего аккаунта на Хабре) и по частям в других постах, но потом остановился, потому что понял, что методика существенно меняется с каждым новым проектом, надеюсь, в лучшую сторону. Общий подход сохранился, но детализация сильно поменялась. Планирую описать её заново с реальным кейсом в ближайшие пару месяцев.
              • +3
                Интересные мысли, но создается впечатление, что автор не знаком с работами классиков Agile, такими, как Кент Бек, Мартин Фаулер, Хенрик Книберг. Не говоря уже о каких-либо более сложных работах в этой области. Успешно применяю, то что можно обощить, как Agile уже около 10-ти лет.

                1. Нет критериев эффективности конечного результата.
                Как так? Гуглите по запросу «метрики Agile» и найдите, то что наиболее подходит для вас!

                2. Непредсказуемость.
                Как раз Agile направлен на то, что б получить результат. Но результатом в данном случае является то, что надо бизнесу, причем с точки зрения бизнеса. Мы принимаем за аксиому, что бизнес постоянно изменяется и это требует внесения изменений в ПО. Пример простой, есть компания которая продает скажем ноутбуки, и тут бизнес принимает решение, что нужно продавать еще и планшеты, потому что это перспективный рынок. До того, как появились планшеты бизнес ни на каком проектировании не мог предположить, что нужно такие требования к разработке выдвигать. Понятно, что нужно будет значительную часть системы переписать, но иначе бизнес упустит перспективную возможность, и об этом на этапе проектировании ничего не было известно. При этом, используя метрики и проектирование, можно в течении нескольких дней сказать сколько это времени займет и сколько будет стоить. Что очень хорошо для бизнеса. В Agile бизнес-решения принимает бизнес, а технические решения принимают — программисты. Ответственность в Agile должна приниматься всей командой, включая бизнес, иначе аджайла не будет. Так что аджайл в этом смысле с одной стороны предсказуем — из 20 спринтов последнего проекта, не правильно оценили время мы всего в двух и то из-за полного отсутствия информации.

                Дольше и дороже.
                Тут я просто ссылку на статью дам, которая все объясняет http://blog.scrumtrek.ru/2011/03/agile-waterfall.html
                • –2
                  Спасибо за комментарий. Я в статье говорю о подходе к разработке сайтов, а не о создании чего бы то ни было вообще в IT. Это узко-направленная оценка, а вы мне привели пример с ноутбуками и планшетами.

                  К сожалению, в практике разработки сайтов ни разу не сталкивался с тем, о чём вы говорите. Красивая теория, а на самом деле получается «делаем, как получится, получаем, что получится».

                  Вы сами хоть раз делали сайт, используя Agile и его метрики? Что получилось? Сравнивали с водопадной моделью?
                  • 0
                    Если нечто, что имеет web интерфейс можно назвать сайтом, то последние 10 лет только этим и занимаюсь.
                • +4
                  Agile — методология процесса
                  Проектирование — этап процесса
                  Бриф — документ

                  У вас какой то не академический взгляд на вещи. Как эти разноуровневые сущности можно сравнивать?
                  • –3
                    Я их сравниваю на уровне подхода к разработке, причём учитываю не только теорию, как вы правильно заметили, обвиняя меня в отсутствии должного академизма, а практику. На мой взгляд, это гораздо ценнее чисто научного подхода.

                    Как делаются на практике сайты:
                    1. Начинают с глубокого водопадного проектирования и дальше чётко без всякого agile следуют проекту.
                    2. Начинают с краткого брифа и дальше каким-то образом по нему идут, чаще всего, водопадно, собирая сайт по структуре разделов и кое-как описанным модулям.
                    3. Делают вводную — иногда это короткое проектирование, а иногда просто сбор требований — по методике agile и дальше разрабатывают по этой же методике.
                    • –3
                      На уровне теории это сравнение действительно несколько спорно, понимаю. Но на уровне практического подхода очень даже.
                    • 0
                      Проектирование и бриф это вещи направленые на детализацию требований. Если вам все предельно ясно, и вы делаете типовое решение, то можете обойтись без прототипа и приступать к оформлению. Бриф скорей всего вам понадобится, для фиксации особенных клиентских требований.

                      А будете вы это реализовывать по средством agile методик или водопада, зависит от особенностей проекта. В случае типовых решений водопад имхо предпочтительнее.
                      • 0
                        Бриф — да. Проектирование — это не вещь, направленная на детализацию требований. Проектирование — это вещь, направленная на уточнение идеи, построение модели проекта под задачи, инструмент планирования и прогнозирования. Требования — лишь малая часть проекта.
                        • 0
                          Для меня «уточнение идеи, построение модели проекта под задачи» это и есть детализация требовний. Так как требования это "совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации". Извините, но я за общепринятую терминологию, которая базируется на теории выведеную из практики.

                          И требования не «инструмент планирования и прогнозирования», а лишь данные (отправная точка) для этих активностей. Ведь требования бывают разных уровней. Почитайте Коберна.
                          • 0
                            Давайте посмотрим на сайт шире. Сайт — не только и не столько программный продукт. В проекте описывается не только и не столько функционал, сколько решение задач через коммуникацию, дизайн, функционал, услуги.
                            • 0
                              Всегда смотрю на сайт так. Мне по должности положено, я дизайнер. К каким выводам я должен прийти, по вашему мнению?
                      • 0
                        Проектирование полезно везде, кроме сайтов с бюджетом, не позволяющим проектировать.

                        Как насчёт заказчика, не желающего проектировать? «Вы профессионалы, я вам плачу, вот и делайте».
                        • 0
                          *участвовать в проектировании
                          • 0
                            Заказчик нужен на стадии сбора требований.
                            Получив требования, вы занимаетесь проектированием.
                            • 0
                              В процессе проектирования может оказаться, что не все требования собраны, а заказчик не настроен на итеративную разработку.
                            • 0
                              Не уверен, что правильно понял вопрос, но попробую ответить. Участие заказчика — это предоставление необходимой информации — требований, бизнес-задач, о себе, своих продуктах/услугах и т.п. — и потом утверждение проекта. Если он не хочет делать первое, то с ним нельзя работать, а вот если он не хочет делать второе… Это вопрос, конечно, интересный. Не встречался ещё с таким, кто сказал бы: Вот вам миллион, на выходе хочу сайт классный. Как правило, заказчик хочет и способен утвердить ключевые моменты в проекте, а за остальное действительно ответственность берёт на себя разработчик.
                              • 0
                                Да, как раз речь об ключевых и не ключевых моментах. Ключевые собрали, начали проектировать, но оказывается какой-то важный момент опущен, а заказчик не может сейчас его прояснить. Останавливать проектирование и ждать заказчика? Начинать выполнять то, что уже ясно, до конца проект на разработав? Принимать решение за заказчика?
                                • 0
                                  Да, речь именно о ключевых моментах. Если момент ключевой, то его разрешения надо ждать при любом подходе, иначе может случиться фейл. А если не ключевой, то его можно при любом подходе отложить.
                            • +3
                              Александ, извините, но то, что вы называете «Agile» — таковым не является. Создаётся впечатление, что вы абсолютно не понимаете, о чем пишете. «Agile как метод создания сайта» — простите, но это бред. Первое, что нужно уяснить: Agile — это философия и в некоторой мере методология, но никак не «способ создания сайтов». Может, стоило сначала разобраться в предмете?
                              • –2
                                Понимаю, но смотрю на это под несколько иным углом. Я вижу и считаю, что есть такой метод подхода к разработке сайта: разработчики садятся и начинают делать сайт кусками и по ходу смотрят, что получится. Вы можете забросать меня цитатами из Википедии или scrum-сайтов, говорить о философии, феноменологическом подходе, спорить по терминологии, но это не меняет сути дела. Я написал не о теоретической трактовке, а о реальном практическом применении.
                                • –1
                                  Тоже глаз резануло «Agile как метод создания сайта». «Agile как метод управления созданием сайта» звучит куда лучше, потому что методы создания сайта для меня что-то вроде написать сайт с нуля, использовать фреймворк, CMS, или, прости господи, Ucoz.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое