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

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

Что включает в себя техническое задание для разработки спроектированного интерфейса?
Обычно с подрядчиком можно согласовать степень детализации ТЗ:


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

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


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

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


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


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

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

3 совета для людей, которые не любят отвечать на телефонные звонки Bog BOS: Управление рабочим временем системного администратора T-L-T: The Limoncelli Test. Тест Лимончелли: 32 вопроса к вашей команде сисадминов А зачем мне ТЗ? Я и так знаю! Артур Блох. Закон Мэрфи Как взять собеседование под свой контроль? Когда заказчик не хочет платить. Ключевые фразы Лимончелли Т. Тайм-менеджмент для системных администраторов Положение о порядке подключения и работы автоматизированных рабочих мест сотрудников предприятия в сети Интернет Психологическая деформация программистов. Взгляд с обеих сторон баррикад Согласно техническому заданию Список проверки глупых вещей — Лимончелли Хотите превратить изучение иностранного языка в увлекательное занятие?