А зачем мне ТЗ? Я и так знаю!

    Проблема _непрочтения_ ТЗ встает практически каждый раз, когда "написатели" ТЗ и разработчики — люди из разных контор.

    Этот пост — о Техническом Задании на разработку интерфейсов [для пользователей].

    Разработчики – такие же люди, как и все. Читать талмуд об интерфейсе, написанный канцелярским языком – наверняка не очень приятное времяпровождение. Специалисты по интерфейсам разрабатывают ТЗ и передают их Заказчикам. И просят прочитать техническое задание (или спецификацию) – о том, как разрабатывать и изменять спроектированный интерфейс.

    Что включает в себя техническое задание для разработки спроектированного интерфейса?


    Обычно с подрядчиком можно согласовать степень детализации ТЗ:
    1. Это может быть документ, который описывает ключевые и типовые экраны интерфейса, элементы экранов (или страниц) и неоднозначное поведение этих элементов на конкретном экране.
    2. Или же документ, который включает в себя методологию постраничного “сбора” экранов интерфейса и объясняет связи между экранами. А также такое ТЗ может объяснить, почему применена та или иная логика построения интерфейса.
    3. Или вообще документище: руководство по эргономике, которое расскажет всё-всё об интерфейсе (и все равно его, наверняка, никто не прочитает).

    ТЗ помогает ответить на два вопроса


    1. Сделан ли интерфейс ТАК, как нужно?
    2. МОЖНО ли его применять и как его применять при реальной разработке?

    И тут встает фактор опыта. Опытный разработчик видит реализацию, у него есть уже свое видение, свои знания реализации системы. А тут его просят «изобрести велосипед» и пристают — прочитать ТЗ.
    ТЗ – это справка, большая, о том, что должно быть в идеальности.

    Но ведь можно и по-другому посмотреть на ситуацию «Я всё и так знаю».

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

    В реальной жизни


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

    Профит: разработчик более вовлечен и мотивирован: ему надо просто предупредить исполнителей о том, что неприменимо в новом (или измененном) интерфейсе, на его взгляд и по его опыту.

    Первый вопрос – «Сделан ли интерфейс ТАК, как нужно?»


    ТАК – это чтобы удовлетворял требованиям пользователя (пользователь — на первом месте), требованиям бизнеса, требованиям разработки.
    • Требования бизнеса обсуждаются и фиксируются на начальном этапе проекта.
    • Требования разработки фиксируются в виде технических возможностей и ограничений на начальном этапе, а также в ходе итераций (желательно на этапе разработки концепта интерфейса, и на этапе сдачи драфта проделанной работы).
    • Требования Пользователей к интерфейсу – на начальном этапе (интервью с пользователями), на этапе разработки концепта (профили, сценарии, структура навигации, описание страниц интерфейса при постановке задачи на проектирование).
    Спроектированный интерфейс должен соответствовать требованиям, а ТЗ — объяснять, как были учтены требования. Поэтому, ТЗ также может содержать доказательные результаты лабораторного тестирования спроектированного интерфейса с пользователями.

    Второй вопрос – «МОЖНО ли применять спроектированный интерфейс для разработки»


    Спроектированный интерфейс – это пример, как должен вести себя реальный интерфейс системы при взаимодействии с пользователем.
    Почему именно так он себя ведет – опять же, написано в техническом задании. Специалист, при написании ТЗ, акцентирует внимание на элементах, которые неочевидны в контексте всего протитипа. В особенности:
    − на ключевых экранах (приоритетных и частных страниц интерфейса, возникающих при взаимодействии с пользователем);
    − на типовых экранах (имеющих сходный функционал и назначение).

    Если же спроектированный интерфейс взаимодействует с Пользователем не так, как ожидала и предполагала разработка («… НЕЛЬЗЯ такое применить/сделать»), значит или Пользователям так удобнее, или это — просчет при обсуждении технических ограничений с разработчиками.
    Поэтому наличие разработчиков в рабочей группе желательно-обязательно, а ознакомление с результатами итераций при проектировании – важно.

    Но идеальности не бывает


    Пользователи, конечно, просят или хотят чего-то (а, может, и не просят вовсе: они ведь не всё озвучивают, а привыкают к неудобности и перестают её замечать) – а технически такое неисполнимо.
    Или же рекламу надо показать в _ этом самом месте, где должна быть кнопочка_, а то бизнес загнется – значит, рекламу надо показать, хоть убейся.

    Отклонения о реального мира – возможны, и именно эти отклонения и нужно обсуждать. Это либо предусматривается в ТЗ (на моменте передачи спроектированного интерфейса, который также корректируется), либо обнаруживается при разработке и реализации, что более печально.

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

    Так почему надо читать ТЗ?


    0. Не только читать, но и участвовать;
    1. Опыт разработки — хорошо, а довольные пользователи важнее (клиенты или работники => или деньги, которые приносят, или время, которое экономится, или то и другое);
    2. Чтобы не допустить ошибок с неочевидным взаимодействием пользователя и системы, опираясь на опыт пользователя (клиента), а не разработчика;
    3. ТЗ нужно использовать как чеклист для проверки разработанного продукта на соответствие пользовательским требованиям.
    4. ТЗ описывает, как можно изменять интерфейс: в каких случаях и в какой последовательности, без вреда для всех сторон.

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

    Комментарии 29

      +6
      Огромнвй плюс ТЗ в том, что оно позволяет избежать инсинуаций со стороны заказчика на тему «а давайте попробуем еще вот так» или «мы (всегда умеляет в такой постановке вопроса вовлечение исполниьеля, не Я, но МЫ), итак, мы забыли с вами об одной важной вещи, давайте доделаем и сразу рассчитаемся».
        +5
        Больше всего мне нравится «мы», ага: )
          +3
          Это похоже на моральное давление. Что-то вроде попытки навязать чувство вины…
          0
          В договор нужно включать что-то вроде «Заказчик вправе изменить объём работ в рамках 10% как в большую, так и в меньшую сторону. В данном случае оценку объёма работ осуществляет Исполнитель. Оплата производится пропорционально выполненному объёму работ, в пересчёте от изначально согласованного. Исполнитель вправе назначить новый срок исполнения работ».
            +1
            Как говорилось в одной хорошей книге, в таком случае хорошим ответом будет: «Ок, давайте тогда мы посчитаем смету для таких изменений». Это отлично остужает порывы внесения изменений после согласования ТЗ.
            +4
            Наличие ТЗ практически не снимает рисков, связанных с отступлением от него и бесконечным произволом заказчика в виде постоянных изменений требований на определенных проектах. Кто работал на гос сектор — поймет меня.
              +1
              Предполагаю, проблема государственного сектора в том, что в договоре трудно установить нормальные условия (изменение требований, в частности) для исполнителя — из-за фиксированных форм и отчетности.

              Ну и БЮРОКРАТИЯ, конечно же, куда без неё.

              Кстати, проблема актуальна и для коммерческих фирм, которые отдают работы на сторону по тендерам.
              0
              Почему «ТЗ интерфейса»? Проблема с следованию ТЗ, так же как его написания — это общая проблема, и не имеет значения, речь идёт о том, как обрабатываются коды ошибок или как выглядит кнопка.

              Главная проблема — ТЗ не документ для «заказчика». Те, кто просит проверить ТЗ заказчику и согласиться с ним, напоминают врача, который предлагает схему лечения (с рискованными инвазивными операциями) и просит подписать согласие, предполагая в случае чего «но вы же сами прочитали».

              Умение читать ТЗ (в смысле, анализировать его на выполнимость и разумность того, что получится) — искусство, сравнимое с его написанием.

                0
                amarao, спасибо за комментарий, действительно, ТЗ — не воспринимается как документ, которому желательно следовать.

                Так как я не могу говорить за всех специалистов, которые занимаются написанием ТЗ для разработки, говорю про ТЗ на интерфейс системы (раньше ведь такого не было, и разработчики, по-большому счету, сами решали что и куда ставить и какие будут «рюшечки»).

                Если все делается внутри компанией самостоятельно (полный цикл), всё просто: ставится и исполняется определенная задача, исходя из того «как это принято у нас».

                Если кусок «аналитика+проектирование+дизайн» делает кто-то сторонний, убедить разработку в правильности решений исполнителя — очень сложно.

                И плевать разработке на ТЗ (у них есть свое мнение), особенно если они _никак_ не принимали участие в проекте.

                +1 — по поводу «проверить ТЗ» — это попахивает садизмом: "ПрокомментируйРаскритикуй же меня, разработка!".
                  –1
                  >ТЗ — не воспринимается как документ, которому желательно следовать.

                  Не всё так однозначно. Мне приходилось делать такой жуткий интерфейс. С нелепыми действиями, с лишними кликами. Даже ведущий был согласен со мной, что реализовывать интерфейс по такому ТЗ не следует. Но ТЗ такое ТЗ. Всё было задокументировано и принято. Спасали некоторые пробелы, которые не были оговорены в ТЗ и которые я сделал по-своему.
                    +1
                    Не стала писать «надо следовать», написала «желательно».

                    К сожалению, компании — «написатели» ТЗ не знаю ваш продукт лучше вас, согласитесь.

                    Делать просто потому, что так написано — печально, особенно, если повлиять на изменение Вы не в силах (к примеру, вы — разработка на аутсорсе, которой передали ТЗ). Мрак ;(
                0
                А можно где нибудь посмотреть действительно клёвое и правильное ТЗ/Спецификацию на разработку интерфейса?
                  +1
                  Это фантастика
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Мне кажется, что идеального ТЗ на интерфейс «под всех» — не может существовать.
                      Клиентоориентированность, персональный подход делают ТЗ не просто формальным документом.
                      Зарубежом есть практика — публиковать требования к интерфейсам в общем доступе.
                      Не очень давно выкладывали существующие требования для разных платформ, в разрезе стран, можно погуглить.
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • НЛО прилетело и опубликовало эту надпись здесь
                          0
                          Чем больше детализация — тем больше шанс того, что ему будут бездумно следовать, исполняя каждую деталь.
                          Это риск для конечного пользователя (вдруг что-то можно сделать лучше, чем было на момент написания такого детального ТЗ).
                          • НЛО прилетело и опубликовало эту надпись здесь
                              0
                              Прав, очень прав.
                              Хочется, чтобы разработка принимала участие, от которого получится тот самый профит, на этапе создания ТЗ.
                              Мне снять розовые очки?)
                              • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        Поясните, пожалуйста, о какой методологии разработки Вы пишете?
                        Мне кажется Вы иногда смешиваете стадию постановки задачи, стадию проектирования и стадию внедрения. Если говорить обо всём этом, то полезно было бы упомянуть Технический проект и Программу и методику испытаний. Последний документ как раз и следует применять при проверке системы перед/при внедрении.
                          0
                          Я не пишу о методологии, как таковой.
                          Пост о ТЗ на интерфейс, который будут разрабатывать после аутсорсинговых работ, то есть сильно потОм, и другие люди.

                          Я не застрагиваю тему, _как_ будут разрабатываться, тестироваться и доводиться до ума конечный продукт.

                          И, к сожалению, ни разу не сталкивалась с документом «Методика испытаний», поделитесь?
                            0
                            Мы работаем много лет с крупной государственной компанией, и наше «бумажное» внешнее взаимодействие определяется древним 34-м ГОСТ-ом. Преимущества и недостатки такого подхода давайте оставим за скобками, но в ГОСТе определён такой документ: Программа и методика испытаний (ПМИ). Фактически, это сценарии испытаний продукта. Наверняка, вы пользуетесь одной из Agile-методологий, но в них тоже практикуются проектные документы и сценарии тестирования.

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

                            Хотя, наверное, зря я докапываюсь :). На сколько я понял, Вы несколько упростили процесс и у вас нет фазы ТЗ и фазы ТП (Технический проект). Вы сразу формулируете и согласовываете один документ, отражающий постановку задачи и технические решения. И когда-нибудь «сильно потОм» отдадите это разработчикам. Видимо, меня ввело в заблуждение слово ТЗ. Строго говоря, это не ТЗ, но вариант вполне рабочий. У нас такое не пройдёт из-за требований заказчика, но это сугубо наша проблема.

                            Пожалуй, в ближайшее время поделюсь своим опытом в блоге. Это тема не комментария, а, наверное, статьи и отдельного обсуждения. Мне будет очень интересно хабрамнение.
                          0
                          :( а где «боевые» случаи? коварные истории? картинки было-стало?
                            +1
                            >Профит: разработчик более вовлечен и мотивирован: ему надо просто предупредить исполнителей о том, что неприменимо в новом (или измененном) интерфейсе, на его взгляд и по его опыту.

                            По-моему, стоит выделить слово «что», а не «неприменимо».

                            Статья верная, проблема решается путём объяснения разработчикам важности ТЗ и соответствия проекта оному (возможно, с угрозами неоплаты того рабочего времени, что ушло на переделку из-за незнания ТЗ). На чётко сформулированном ТЗ строится всё тестирование (из литературы по тестированию, кстати, можно многое узнать о том, как писать ТЗ), иначе как проверять продукт, если нет четкого понятия о том, какой он должен быть?

                            С другой стороны, всегда нужно у разработчиков узнавать, чего им не хватало в ТЗ, или вообще удобно ли им работать с ТЗ в той форме, в которой вы им её предлагаете. Имхо, ТЗ пишется именно для разработчиков, а значит, ТЗ должно быть удобно и понятно для них
                              0
                              Спасибо, поправила) Смысл — именно в перечислении.
                              0
                              Занимаюсь разработкой интерфейсов: те дизайн юзабилити и реализация в реальных проектах (WPF и CSS)
                              И вот мое мнение — невозможно составить тз на интерфейс так что оно будет учитывать все аспекты и нюансы.
                              Всегда получившееся приложение(четко по ТЗ) и его вариант «на бумаге» — это две разные вещи.
                              Причина проста:
                              Приложение — оно живое, динамическое, масштабируемое…
                              Бумага — она мертвая, статическая, с физическими размерами…

                              Сейчас я работаю в основном без ТЗ, делаю немного по другому.
                              1) составляем бриф на дизайн и юзабилити вместе с заказчиком
                              2) делаем оценку стоимости дизайна и юзабилити (приблизительно творческую работу никогда нельзя оценить временем), кроме того юзабилити надо заниматься уже на этапе дизайна, иначе потом может быть поздно. В смете так же указываем и некоторые важные детали как что-то сложное будет реализовано и почему.
                              3) рисуем, согласовываем, снова рисуем, дорисовываем, думаем над юзабилити, снова рисуем… пока не добьемся True интерфейса на бумаге.
                              4) после согласования интерфейса на бумаге, делаем оценку сроков и стоимости реализации его в реальном приложении, тк мы сами проектировали интерфейс, ТЗ нам не особо нужно, документ составляем только один — смету, по ней же и осуществляем сдачу/приемку работ по пунктам в смете., те если какого-то окна нет в смете — заказчик не вправе требовать его добавить.
                              этот этап довольно сложный, оценить время тут сложно хоть с тз хоть без него.
                              5) Реализовываем интерфейс…
                              И вот тут то начинается самое интересное, не всегда то — что мы придумали на бумаге, в реальности удобно (много факторов на это влияют, например тормоза железа или сервера, анимация режет глаз, невозможность выполнить новые задумки из-за ограничений платформы, и тд и тп)
                              Кроме того, все это не всегда красиво, бывает очень красивый интерфейс — как картинка — просто супер, но вот как реальное приложение — ляпист, нелеп, мерцает на состояниях мыши или мелок для пальца заказчика на сенсоре (на картинке не каждый заказчик это все поймет)
                              И поэтому, тут также привлекается дизайнер и юзабилист, чтобы… менять интерфейс прямо на ходу (естественно не целиком и полностью а некоторые мелочи как правило)

                              Все в разы интереснее, если заказчик приходит со своим ТЗ и дизайном… Тут как правило очень часто идет под нож и дизайн и ТЗ, хорошо если заказчик понимает замечание еще до начала реализации верстки XAML или CSS после моего беглого но зоркого взгляда выявившего массу нюансов и недочетов в дизайне и ТЗ, но если уперт — потом либо получает каку по ТЗ, либо платит дважды за перерисовку и переверстку.

                              Так что следовать ТЗ на интерфейс целиком и полностью — это глобальная ошибка, всех нюансов не учесть на бумажке. Когда это все заработает и задвигается — всплывает столько неучтенных мелочей, что иногда за голову можно схватиться (собственно поэтому не забывайте накидывать 25% на высчитанное время реализации)
                                0
                                ТЗ передать можно просто на бумажке, а можно с динамическим прототипом.
                                Умышленно не писала про прототипы, так как проблема единая.

                                Опять же — круто, когда ТЗ могут изменять (не забывая про пользователей), оперативно, не тратя лишнее время разработчиков.
                                К тому же, если в ТЗ прописать, где и как можно поменять интерфейс — получится гораздо легче вносить изменения ;)

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

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