Курица или яйцо: что раньше, прототипы или ТЗ?

    image

    Бывают ситуации, когда проект нужно подготовить в очень сжатые сроки, и совсем нет времени на изучение способов решения задачи и выбора из них самого оптимального. Команда просто бросается с головой в реализацию, полагаясь на опыт и интуицию. Обычно получается хорошо. Но остается ощущение, что можно сделать лучше, была бы только возможность остановиться и обдумать задачу.
    Например, в нашей команде разработки интернет-решений не у всех и далеко не всегда было понимание, с чего начинать проектирование: с прототипов интерфейсов или технического задания. В обоих случаях есть сторонники и противники, есть плюсы и минусы. Не хватает только единого мнения.

    Договоримся, что прототипы и ТЗ мы используем для того, чтобы:
    • согласовать состав работ с заказчиком,
    • сформулировать задачи дизайнерам и разработчикам,
    • разработать сценарии функционального тестирования,
    • написать пользовательские инструкции,
    • выполнить приёмку работ.

    Прототипы могут быть любого типа. ТЗ можно заменить на схемы с пояснениями. Здесь содержание важнее формы. Конечно, при условии, что формат документа устраивает и заказчика, и команду.

    Сначала правильнее проработать прототипы


    Как это будет. Рисуем. Обсуждаем. Перерисовываем и обсуждаем. Обсуждаем и дорисовываем. Согласовываем.
    Результат, который мы видим. Много детальных прототипов. Все понимают, как будет выглядеть система. Всем нравится.
    Результат на самом деле. Цели и задачи проекта нигде не зафиксированы, поэтому нет уверенности в том, что прототипы им соответствуют. Никто не помнит, какие ограничения и функции обсуждались при формировании прототипов. В любом случае их нет в формате, который можно передать заказчику или команде. И если автор прототипов внезапно решит улететь на Марс, то на расшифровку его работы уйдет много времени. И, скорее всего, после проработки описания окажется, что кто-то из команды иначе представлял себе действия, совершаемые по клику. Даже если прототип интерактивный, он не отражает внутреннюю логику.
    Необходимые действия. РазработатьТЗ. Важно не просто описать то, что есть на прототипах, а полностью проработать функционал. Откорректировать прототипы. Причём это могут быть как незначительные правки, так и кардинальные изменения или отрисовка прототипа.

    image

    Или всё-таки сначала ТЗ?


    Как это будет. Анализируем. Продумываем. Описываем. Обсуждаем. Анализируем. Дописываем и обсуждаем. Анализируем. Обсуждаем и переписываем. Согласовываем.
    Результат, который мы видим. У нас есть ТЗ. Десятки или сотни страниц с детальным описанием.
    Результат на самом деле. Автор документа знает, как всё должно быть. Знает, какие есть ограничения. Никто не представляет себе, как это описание будет выглядеть визуально. Вряд ли кто-то кроме автора прочитал и разобрался в документе, потому что сплошной текст без картинок уныл и трудно воспринимается.
    Необходимые действия. Спроектировать прототипы. Упростить и дополнить ТЗ после прорисовки прототипов (хорошие прототипы выявят узкие места и логические ошибки в описании).

    Что не так?


    Неизбежные ошибки
    В случае первоочередности прототипов мы упускаем детали, которые удается продумать только на этапе описания. Если на первом плане ТЗ, то мы не видим способы оптимизации интерфейса, которые так легко выявить на прототипе. Ошибки возникают потому, что мы слишком явно разделяем части одного целого.

    Прототипы и ТЗ это не только ваше творчество, но и основа для работы других членов команды. Обсудите с соответствующими специалистами узкие места и спорные моменты и убедитесь, что требования к прототипам и требования ТЗ реализуемы.

    Разница восприятия
    Очень трудно прийти к единому видению проекта, ориентируясь только на текст или только на прототипы. Люди представляют себе разные образы, когда читают один тот же текст, и подразумевают разный функционал, глядя на одни и те же картинки.

    Размывание процесса
    При разделении проектирования прототипов и ТЗ на отдельные этапы, мы согласовываем один документ, затем второй, а затем вносим правки в первый, хотя он был уже согласован. У заказчика складывается впечатление, что договоренность не важна, а правки ТЗ и прототипов доступны на любом этапе проекта. Под слоганом “давайте изменим вот эту кнопку” происходит бесконечная итерация изменений.

    Рост трудозатрат и снижение мотивации
    Если наращивание описания и прототипов происходит постепенно, то правки вносить легче и быстрее, ведь править нужно меньший объём. Простая математика: 5 прототипов сделаны на основе главной страницы, значит, в случае правок главной страницы мы правим сразу 6 прототипов. В итоговом ТЗ нужно править 100 страниц, а в первоначальной концепции только 10 (все цифры, конечно, условные, но основную идею они отображают). Создание всеобъемлющих описаний, отрисовка сразу всех прототипов и их последующие правки – зря потраченное время. Но что гораздо хуже – возникает ощущение бесполезной работы, которую нужно переделывать от начала до конца снова и снова (пусть даже незначительно).

    И прототипы, и ТЗ


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

    Прототипы и ТЗ по отдельности не закроют все пункты. Нам нужны оба документа, причем они должны быть согласованы между собой и представлять единое целое по смыслу и функциям. В идеале, прототипы и ТЗ – это один документ. И лучше не дробить его на части без крайней необходимости.

    Как это будет.
    1. Проработка концепции и прототипов основных страниц. Анализируем. В ТЗ описываем концепцию проекта, указываем основные модули/блоки/функции, продумываем роли и указываем ограничения. Рисуем прототипы самых сложных и самых важных страниц. Обсуждаем. Как правило, по концепции у команды возникает много вопросов, а у заказчика – много пожеланий. Анализируем. Корректируем. Согласовываем.

    Обсуждение с заказчиком – необязательно личная встреча (хотя это самый лучший способ). Чтобы получить быстрый ответ или сэкономить время, используйте Skype, режим редактирования в Word, электронную почту и прочие способы связи.

    2. Детализация описания и прорисовка прототипов всех уникальных страниц. Анализируем. Расширяем описание в ТЗ. Технические аспекты описываем на высоком уровне. Рисуем прототипы всех уникальных страниц, то есть для похожих страниц, например, “Создание опроса” и “Редактирование опроса”, на данном этапе можно отрисовать только одну из них. Обсуждаем. Анализируем. Корректируем. Согласовываем.
    3. Полное описание и прорисовка прототипов всех страниц. Анализируем. Фиксируем в ТЗ все нюансы по функционалу и технической стороне реализации. Рисуем все состояния элементов и страниц. Обсуждаем. Анализируем. Корректируем. Согласовываем.

    Прототипы и ТЗ могут делать разные люди, если они при этом являются эффективной командой.

    Результат, который мы видим. Все понимают, как будет выглядеть система. Все понимают, каким функционалом будет обладать система.
    Результат на самом деле. Документы, с которыми удобно работать всем членам команды и заказчику. Всё отрисовано, всё описано.
    Необходимые действия. Двигаться дальше по проекту.

    Марина Демина, проектировщик ADV/web-engineering
    • +14
    • 13,2k
    • 8

    ADV/web-engineering co.

    46,00

    Компания

    Поделиться публикацией

    Похожие публикации

    Комментарии 8
      –2
      Пирожок
        0
        Как ни начинай — все равно в итоге получится не так, как задумывал. Пожелание левой пятки заказчика зачастую сильнее всех прототипов и ТЗ.
          0
          «В ТЗ описываем концепцию проекта» — звучит как «draw the rest of the fuckinh owl».

          Из чего состоит в вашем понимании концепция и почему она оказалась в ТЗ?
            0
            Под концепцией подразумевается краткое описание проекта: что мы хотим получить, зачем нам это нужно, как мы это сделаем.
            Концепция включена в ТЗ, так как предполагается, что ТЗ разрабатывается поэтапно, от верхнеуровнего понимания к деталям. При этом, ТЗ в статье не привязано к определенному формату, это может быть ГОСТ, а может быть договоренность между командой и заказчиком. Если используемый шаблон не допускает описание концепции, то следует проработать её в рамках отдельного документа прежде чем приступить к ТЗ.
              0
              Я правильно понимаю, что вы не используете и не предлагаете фиксировать измеримые и конкретные бизнес-цели?

              Я правильно понимаю, что вы не используете и не предлагаете фиксировать показатели назначения и, в частности, показатели качества интерфейса, например, как результативность, точность, среднее время выполнения сценария?

              Т.е. приёмка системы происходит в режиме «это понравилось заказчику», а не «система работает с заданным уровнем качества и приносит затребованные от неё результаты»?
                0
                Нет, такого смысла я не закладывала.
                «Не понравилось заказчику» не означает, что нужно сразу изменить всю логику ТЗ или предложить совершенно новые прототипы. Это обратная связь, которую нужно обработать. Не понравилось — потому что мы что-то не учли? Не учли, потому что упустили важный вопрос при сборе требований или потому что у заказчика изменились цели? Не понравилось — потому что мы не объяснили, какие преимущества получит заказчик от продукта именно в таком исполнении? Вариантов тут очень много.
                Безусловно, нужно обсудить, договориться и зафиксировать цели проекта, критерии успешности, ограничения, допущения т.д. Нужны входные и выходные требования к качеству документов, нужны требования к качеству продукта. Нужна проверка документа и тестирование продукта. Однако содержание ТЗ, обеспечение качества — это отдельные большие темы, которые не раскрыты в статье.
            0
            ТЗ — результат этапа анализа, прототипы — как минимум уже этапа проектирования (в зависимости от их типа). Другой вопрос, что часто макеты интерфейса проектируют те же аналитики, причем иногда включают их в само ТЗ.
              0
              В моей компании и в университете следующая практика. Сначала пишется устав. После на его основе в ТЗ пишутся функциональные требования. На их основе создается прототип и сдается заказчику вместе с требованиями. Если его устраивает дизайн и расположение, а так же функциональность, то из прототипа делаются скриншеты в раздел «Не функциональных требований» куда дописываются некоторые нюансы по системе.

              Итоги.
              1. заказчик и команда еще до создания прототипа точно знает всю функциональную начинку проекта.
              2. благодоря прототипу мы точно уверены что двигаемся в правильном направлении и больше не паримся с дизайном сайта.

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

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