Extyl-PRO. Битрикс-интегратор №1. Сложный ecommerce и нестандартные интеграции. Extyl-PRO
Адрес: Павелецкая набережная, 2, БЦ LoftVille 115114 Москва,
Телефон:+7 495 995–23–37, Электронная почта: info@extyl-pro.ru

Библиотека Экстил-ПРО

 
Информация - это важный элемент при принятии того или иного решения. В разделе "Библиотека" собраны статьи, очерки и материалы на все темы, которые касаются создания интернет сайтов, магазинов и порталов.
Комментарии к статьям

Как сделать интернет-магазин прибыльнее

Найс, пора разослать по клиентам :)

Олег Громов

Как (не) работать с дизайнером

Дизайнер не сделает за вас РЕКЛАМНЫЙ макет. Это не его функция. ЭТО БЕДА. Это беда нашего "маркетингового" сообщества, особенно руководителей. Они считают, что сделает. Дизайнер. Рекламный макет. По продукту. Как же? Мы ему продукт (название, картинку) - дали. Наш логотип - дали. Координаты куды бечь покупать - тоже дали. Все - ваяй, дизайнер. Деньги тебе платим. Узнаете? Сочувствие в данной ситуации вызывают все - и дизайнер, и его заказчик. Дизайнер, потому что он БЕЗ СОДЕРЖАНИЯ не создаст ФОРМУ (рекламный макет). И не нужно ждать от него шедевр или его ругать. Заказчик, потому что не знает о том, где берется СОДЕРЖАНИЕ для рекламного макета по продукту (картинка и название продукта, логотип компании и ее реквизиты содержанием РЕКЛАМНОГО макета не являются). И его нужно пожалеть, потому что маркетинговой таблице умножения у нас практически нигде не учат. Разгадка где брать содержание для рекламного макета таится в маркетинговом плане. В третьей его части. Все просто. И планы нужно писать. Для тех продуктов, которые приняты к продвижению (для этого тоже существует свой алгоритм). А пока этого не делается - вот так все и существуют "поди туда - не знаю куда, принеси то - не знаю что"... Пишите маркетинговые планы, друзья, и будет нам всем счастье.

нужно знать таблицу умножения

Нарисуйте мне несколько вариантов дизайна, чтобы я смог выбрать...

ДИЗАЙН - это ОЧЕНЬ важно. Но не главное. Главное - это СОДЕРЖАНИЕ. Потому что оно и определяет дизайн. Тот самый, оптимальный. АДЫН. Поэтому важно сначала полностью отработать содержание (постранично, до мелочей), а потом придавать ему форму. И если агентство будет до последней точки сначала разрабатывать и утверждать с клиентом содержание, (да, в ворде, им все владеют и могут оперативно над этим содержанием работать) то все получится счастливо. В идеале хотелось бы, конечно, чтобы и заказчики и их подрядчики были образованы в области маркетинга, тогда они говорили бы на одном языке... Хорошо что есть агентства, такие как Extyl-PRO, которые это понимают. Удачи всем

другая сторона баррикады

Нарисуйте мне несколько вариантов дизайна, чтобы я смог выбрать...

Я как фрилансер - и творец и купец. Отстаивая точку зрения автора (вариант может быть только один!), я горжусь собой как творцом, не позволяющим заказчику наступать на горло моей песне))) Как купец - смешиваю magenta и yellow - а что делать, ну нравится такое сочетание заказчику (или денег не видать...). Итог грустный, портфолио зачастую стыдно показывать)))

Гость sobakka

06.07.2015

Как написать техническое задание (ТЗ), на что обратить внимание


Согласитесь, прочесть «трехтомник» ТЗ, написанный занудными фразами с использованием канцелярского жаргона, не каждому под силу. Лучше уж «Войну и мир» старичка Толстого подавайте! Но работа есть работа, и вот юзабилити-специалист разрабатывает и передает уважаемому Заказчику проект ТЗ с просьбой прочесть и прокомментировать его — как разработать и «подогнать под пользователя» данный спроектированный интерфейс. Из чего состоит ТЗ для разработки спланированного и спроектированного интерфейса?

setevoe_planirovanie.jpg

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

 • Краткий вариант содержит только основную информацию — ключевые и типовые экраны, страницы и их элементы, навигацию и варианты поведения данных элементов на каждом конкретно взятом экране;

• Средний представляет собой алгоритм постраничного просмотра экранов данного интерфейса, показывает связи между экранами и объясняет выбор принципа построения интерфейса в целом.
• И, наконец, «Ол инклюзив», в котом собрана вся известная информация о конкретно взятом интерфейсе.

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

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

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

Во-первых, возможно, так удобнее пользователю, а во-вторых, вероятно, это просчет при взаимодействии с разработчиками. Технические ограничения необходимо обсуждать заранее. Бывает, конечно, пользователи просят изменить определенные элементы интерфейса, но, как показывает практика, чаще всего они привыкают к неудобствам программы или даже не предполагают, что изменения возможны. В таких случаях юзеры сами подстраиваются под особенности интерфейса. Но бывает и наоборот. Пользователь просит что-то поменять, а это технически невыполнимо. Либо заказчик требует, чтобы реклама всплывала «именно в этом самом месте, и ни в каком другом», иначе все пропало! А значит разбейся, но добейся — реклама должна быть там, где просят. Отклонения от выбранного реального «маршрута» всплывают в течение всего времени работы, особенно если их не обсудить заранее. Лучше всего предусмотреть это во время передачи спроектированного интерфейса и описать в ТЗ с возможностью корректировки. В противном случае отклонения обнаружатся на этапе разработки, и придется вносить изменения уже в процессе реализации.

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

•  Если на данном этапе появились новые пользователи программы — представьте их и опишите цели, которых они желают достичь;
•  Зафиксируйте новые требования пользователей, бизнес-требования, а также возникающие технические ограничения;
•  Добавьте необходимые пользовательские сценарии или внесите изменения в существующие;
•  Проапдейте меню и структуру навигации интерфейса, а также список ключевых и типовых страниц;
•  Внесите изменения в спроектированный интерфейс и, соответственно, в само техническое задание.

Теперь у вас есть возможность проверить, насколько разработанный продукт соответствует поставленным требованиям. Ну и все же, почему стоит читать ТЗ (а еще не только читать, но и активно действовать в соответствии с ним)?

1. На первом месте у нас всегда довольные пользователи (клиенты, которым удобно работать «именно так», сэкономленное время или дополнительно вырученные деньги). Ваш огромный опыт разработки — это отлично, но в данном случае пользователь важнее.

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

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

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



Возврат к списку


Рубрики

Логин: Пароль:

Отзывы клиентов

«...Стоит отметить, что мы до сих пор продолжаем наше сотрудничество с «Веб-студией Extyl-PRO» в области технической поддержки нашего интернет-сайта....»
Отзыв от компании «Кристалл»

Золотой партнер «1С-Битрикс»

]]> Экстил-ПРО - Золотой сертифицированный партнер 1С-Битрикс ]]>
]]> Экстил-ПРО - Золотой сертифицированный партнер Битрикс24 ]]>
«Золотой сертифицированный партнер обладает большим опытом разработки веб-проектов, в том числе создание высоконагруженных сайтов и сложных программных решений на основе „1С-Битрикс: Управление сайтом“»
]]> Extyl-PRO — первое место среди разработчиков 1С-Битрикс в среднем ценовом сегменте по версии Рейтинга Рунета ]]>
«Первое место среди разработчиков на 1С-Битрикс в среднем ценовом сегменте»

Компетенции Битрикс

Участник программы качества. В программе «Мониторинга качества внедрений» участвуют партнеры 1С-Битрикс, системно работающие над качеством выполняемых проектов.
Компетенция Экстил-ПРО - хостинг PHP
Компетенция Экстил-ПРО - интеграция с 1С
Компетенция Экстил-ПРО - внедрение Корпоративного портала
Компетенция Экстил-ПРО - Битрикс24
Компетенция Экстил-ПРО - Композитный сайт
Компетенция Экстил-ПРО - Системное администрирование
Компетенция (от лат. competere — соответствовать, подходить) — это личностная способность специалиста (партнера) решать определенный класс профессиональных задач.
Компетенция «Хостинг PHP» предоставляется партнерам, оказывающим услуги хостинга для проектов, работающих на PHP.