Блог ИТ склеротика. А зачем мне ТЗ? Я и так знаю!

Страницы

Расширенный поиск в статьях блога

13 марта 2012 г.

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



    Проблема _непрочтения_ ТЗ встает практически каждый раз, когда "написатели" ТЗ и разработчики — люди из разных контор.
    Этот пост — о Техническом Задании на разработку интерфейсов [для пользователей].
    Разработчики – такие же люди, как и все. Читать талмуд об интерфейсе, написанный канцелярским языком – наверняка не очень приятное времяпровождение. Специалисты по интерфейсам разрабатывают ТЗ и передают их Заказчикам. И просят прочитать техническое задание (или спецификацию) – о том, как разрабатывать и изменять спроектированный интерфейс.
    Что включает в себя техническое задание для разработки спроектированного интерфейса?
    Обычно с подрядчиком можно согласовать степень детализации ТЗ:

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


      ТЗ помогает ответить на два вопроса
      1. Сделан ли интерфейс ТАК, как нужно?
      2. МОЖНО ли его применять и как его применять при реальной разработке?
      И тут встает фактор опыта. Опытный разработчик видит реализацию, у него есть уже свое видение, свои знания реализации системы. А тут его просят «изобрести велосипед» и пристают — прочитать ТЗ.
      ТЗ – это справка, большая, о том, что должно быть в идеальности.
      Но ведь можно и по-другому посмотреть на ситуацию «Я всё и так знаю».
      ТЗ надо обсуждать: куда шагать можно, а куда – нежелательно, и почему. В ТЗ по интерфейсу даются советы, о том, каким должен быть интерфейс, удобный Пользователю.
      В реальной жизни
      Лучше начинать обсуждать ТЗ еще до момента проектирования, на стадии разработки концепции интерфейса:

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

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

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

    Спроектированный интерфейс должен соответствовать требованиям, а ТЗ — объяснять, как были учтены требования. Поэтому, ТЗ также может содержать доказательные результаты лабораторного тестирования спроектированного интерфейса с пользователями.
    Второй вопрос – «МОЖНО ли применять спроектированный интерфейс для разработки»
    Спроектированный интерфейс – это пример, как должен вести себя реальный интерфейс системы при взаимодействии с пользователем.
    Почему именно так он себя ведет – опять же, написано в техническом задании. Специалист, при написании ТЗ, акцентирует внимание на элементах, которые неочевидны в контексте всего протитипа. В особенности:
    − на ключевых экранах (приоритетных и частных страниц интерфейса, возникающих при взаимодействии с пользователем);
    − на типовых экранах (имеющих сходный функционал и назначение).
    Если же спроектированный интерфейс взаимодействует с Пользователем не так, как ожидала и предполагала разработка («… НЕЛЬЗЯ такое применить/сделать»), значит или Пользователям так удобнее, или это — просчет при обсуждении технических ограничений с разработчиками.
    Поэтому наличие разработчиков в рабочей группе желательно-обязательно, а ознакомление с результатами итераций при проектировании – важно.
    Но идеальности не бывает
    Пользователи, конечно, просят или хотят чего-то (а, может, и не просят вовсе: они ведь не всё озвучивают, а привыкают к неудобности и перестают её замечать) – а технически такое неисполнимо.
    Или же рекламу надо показать в _ этом самом месте, где должна быть кнопочка_, а то бизнес загнется – значит, рекламу надо показать, хоть убейся.
    Отклонения о реального мира – возможны, и именно эти отклонения и нужно обсуждать. Это либо предусматривается в ТЗ (на моменте передачи спроектированного интерфейса, который также корректируется), либо обнаруживается при разработке и реализации, что более печально.
    Однако, если спроектированный интерфейс надо изменять в процессе реализации, это также можно предусмотреть в ТЗ – для этого необходимо включить в ТЗ описание процесса построения концепции интерфейса.
    И, в дальнейшем, при возникновении новых пользовательских требований нужно проапдейтить концепцию:
    — добавить и описать новых пользователей системы – если такие появятся;
    — описать новые цели пользователей;
    — добавить или внести изменения в пользовательские сценарии;
    — выписать и зафиксировать пользовательские требования, бизнес-требования, технические ограничения к возникающим в ходе прохождения сценариев экранам;
    — обновить список ключевых и типовых страниц, а также структуру навигации и меню интерфейса;
    — внести изменения в ТЗ и спроектированный интерфейс, чтобы, в дальнейшем, разработанный продукт можно было проверить на соответствие всем требованиям.
    Так почему надо читать ТЗ?
    0. Не только читать, но и участвовать;
    1. Опыт разработки — хорошо, а довольные пользователи важнее (клиенты или работники => или деньги, которые приносят, или время, которое экономится, или то и другое);
    2. Чтобы не допустить ошибок с неочевидным взаимодействием пользователя и системы, опираясь на опыт пользователя (клиента), а не разработчика;
    3. ТЗ нужно использовать как чеклист для проверки разработанного продукта на соответствие пользовательским требованиям.
    4. ТЗ описывает, как можно изменять интерфейс: в каких случаях и в какой последовательности, без вреда для всех сторон.


Ссылки по теме:


.

Счетчик тИЦ и PR Яндекс.Метрика Msn bot last visit powered by MyPagerank.NetYahoo bot last visit powered by MyPagerank.Net ping fast  my blog, website, or RSS feed for Free