Закрыть
E-mail:
Пароль:
Забыли пароль?
В каталоге проекта: 13 010 веб-студий, 958 CMS, 243 289 сайтов.
РегистрацияCMS MagazineВход
CMS Magazine CMS Magazine

Проектирование: вы делаете это неправильно

На правах вступления

Очень, очень странно писать статью про проектирование в веб-разработке. Казалось бы, на эту тему уже сказано все, что только можно: Интернет и профильные СМИ полнятся статьями и целыми учебными курсами о том, что нужно спрашивать у клиента, как нужно изучать целевую аудиторию, какие программы использовать для рисования прототипов — и в какие цвета эти прототипы нужно раскрашивать.

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

Рисунок 1. Вся суть современного проектирования

По моему глубочайшему убеждению, с этой кустарщиной надо бороться, а именно вводить единую систему, которая объединит правильные подходы к проектированию, сделает очевидно вредными неправильные подходы и придаст всему происходящему общий смысл.

Я говорю не про какую-то идеальную модель, а про реально работающую методологию, коль скоро лично я внедряю ее уже во вторую компанию.Эта система не просто работает — она, как и любая эффективная и правильно выстроенная система, просто не может не работать, если для нее создать правильные условия. И в этом ее оглушительное преимущество.

Рассказу об этой системе и будет посвящен предлагаемый вашему вниманию небольшой цикл статей. В данной статье — первой серии цикла — мы сделаем плавный заход на тему и рассмотрим вопрос, почему почти все существующие ныне практики веб-разработки глубоко порочны с точки зрения проектирования и подходят только для самых простых проектов.

Его величество веб-мастер

Наш рассказ будет так или иначе касаться технического задания — основополагающего проектного документа, к которому большинство веб-разработчиков и клиентов всегда относилось довольно пренебрежительно. Что характерно, это отношение появилось не на пустом месте.

Вспомним, как в старину строилась разработка: был заказчик и был веб-мастер, который делал для заказчика сайт и при необходимости привлекал веб-дизайнера.

Весь этот нехитрый процесс укладывался в следующую схему:

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

Рисунок 2. Веб-мастер времен неолита (реконструкция)

Ни о какой проектной документации речь, понятное дело, не шла: в лучшем случае перед разработчиком лежали «хотелки» клиента, которые он затем брал в оборот, назначая цену и сроки по своему разумению. При этом качество проекта зависело лишь от таланта (или бездарности) веб-мастера и прочих непредсказуемых факторов, которые становились тем актуальнее, чем сложнее становился разрабатываемый проект и чем больше специалистов привлекалось к его реализации. Кроме того, особенно веселой становилось дальнейшее развитие проекта — в какой-то момент веб-мастер терялся в собственном проекте и непременно начинал противоречить сам себе.

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

Рисунок 3. Клиент выражает эмоции на этапе тестирования продукта.

Особенности разработки без проектной документации

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

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

Интернет рос, усложнялись веб-технологии, клиенты становились все привередливее, и методика разработки сайтов «на коленке» изжила себя. Веб-разработка начала требовать надлежащего управления, и это привело к появлению сразу двух взаимосвязанных вещей — менеджеров и технических заданий.

Необходим сайт, мобильное приложение, услуги по SEO или контекстной рекламе? Тендерная площадка WORKSPACE поможет выбрать оптимального исполнителя. База проекта насчитывает более 10 500 агентств. Сервис работает БЕСПЛАТНО как для заказчиков, так и для исполнителей.

Веб-разработка по-советски

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

Рисунок 4. Пример проекта, сделанного по ТЗ по ГОСТу

На рубеже XXи XXIвека, с началом интенсивного развития веб-разработки, проектам понадобилось юридическое подтверждение, которое можно было бы использовать как инструмент для решения различных недоговоренностей и конфликтов между заказчиком и исполнителем и снижения финансовых рисков.

И тут кому-то в голову пришла чудесная мысль достать с антресолей истории старые советские ТЗ, на которых делали программное обеспечение для управления атомными станциями и баллистическими ракетами, сдуть с них пыль, усовершенствовать и приспособить для нужд интернет-проектов.

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

Процесс разработки стал выглядеть так:

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

Рисунок 5. Клиент принимает ТЗ по ГОСТу, вид изнутри

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

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

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

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

Данная методика разработки подходит для тех проектов, на которые наплевать и заказчикам, и разработчикам, но для которых нужен отчет для начальства и иных контролирующих органов.

Дальше произошло вот что. Рынок продолжал расти, а проекты становились все сложнее. Подход, когда ТЗ создается чисто для юридической галочки, стал приносить все больше и больше проблем: клиенты злились, что никто не учел по существу их требований, а владельцы веб-студий ужасались тому, что их проекты неизменно скатываются в недокументированный хаос, грозящий судебными разбирательствами и прочими неприятными вещами. Стало понятно, что ТЗ все-таки должно быть полезным и подробно описывать проект.

Рисунок 6. Медведь, сделанный по плохому ТЗ

Как этого добиться? Правильно! Нужно заставить менеджера писать более внятное ТЗ. И вот тогда произошло Великое и Ужасное: менеджер помимо управленца стал еще и проектировщиком.

Менеджер-слесарь V разряда

Теперь в разработке стали выделять целый подготовительный этап: проектирование.

Процесс разработки стал выглядеть так:

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

На практике же вышло вот что. Требования к ТЗ стали куда жестче, но ТЗ продолжали писать менеджеры; ну а чего — менеджер уже пишет ТЗ, так почему бы ему не продолжить это делать, ведь верно?

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

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

И вот к этому всему добру зачем-то прицепилось проектирование, наделив менеджера помимо организационных полномочий еще и функциями мозгового и смыслового центра проекта; в принципе, с тем же успехом менеджера могли заставить рисовать дизайн, натягивать верстку или писать скрипты (спасло то, что на тот момент должности дизайнера, верстальщика и веб-программиста были уже известны и понятны).

Рисунок 7. Разумный менеджер переживает по поводу самоидентификации

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

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

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

Рисунок 8. Разумный клиент выражает свою озабоченность недочетами в ТЗ

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

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

Особенности разработки по ТЗ, которое пишет менеджер

  • Учет требований клиента и написание детального ТЗ возложено на человека, у которого и без того миллион дел;
  • По ТЗ можно дать оценку проекта, но все упирается в его качество — а оно, как правило, хромает по причине, указанной выше;
  • Разработчику чаще всего недостаточно такого ТЗ, ему приходится многое домысливать и доделывать самостоятельно на свой страх и риск;
  • ТЗ помогает в разборе возможных претензий только тогда, когда оно написано качественно, что маловероятно в силу причин, указанных выше.
  • ТЗ не разъясняется клиентам и воспринимается ими несерьезно, что всячески одобряется менеджерами;

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

Кроме того, все ограничивается написанием ТЗ — необходимым, но отнюдь не достаточным элементом качественного проектирования.

Писатель на страже веб-разработки

Были и другие варианты. Когда стало ясно, что писать ТЗ — это дело долгое, кропотливое и занудное, разработчики щелкнули пальцами и сказали судьбоносную фразу: «О! Давайте посадим отдельного человека, который будет заниматься ТЗ!».

«Наконец-то все встанет на свои места!» — решите вы, и ошибетесь. Вместо того, чтобы углубить и расширить процессы проектирования, все почему-то решили ограничиться всего лишь одним инструментом — техническим заданием.

Процесс разработки стал выглядеть намного веселее:

Замечаете? От менеджера отрезали чисто прикладную задачу по написанию ТЗ, оставив всю остальную аналитико-мозговую канитель, включающую сбор требований и коммуникацию с заказчиком.

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

Рисунок 9. Технический писатель ликует по поводу поступившей от менеджера задачи

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

В ряде команд на технического писателя повесили-таки обязанность собирать требования с клиента, но сути это не изменило. Основным управляющим проекта остался менеджер — он продолжал объединять в себе и организационное начало, и аналитически-мозговое.

Разумеется, от этих всех рокировок клиент к ТЗ серьезнее относиться не начал и по-прежнему согласовывал его как придется.

Особенности разработки по ТЗ, которое пишет технический писатель

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

Резюме: Формально за написание ТЗ берется отдельный человек, но он не является проектировщиком, поскольку основные функции проектировщика (контроль над практическим смыслом проекта) по-прежнему выполняет менеджер.

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

«Непорядок! — снова решили разработчики, — Выходит, нам нужен отдельный проектировщик!»

И дальше совершили еще одну ошибку.

Проектировщик без проектирования

Теперь в проекте появился человек под гордым названием «проектировщик», который занялся... нет, не проектированием. Он зачем-то стал рисовать эскизы страниц будущего интернет-ресурса — прототипы, и именно это и было названо гордым словом «проектирование».

И в этот момент проектирование окончательно скатилось в непередаваемый бардак.

Вот как интересно стал выглядеть процесс разработки:

Красота! Теперь прототипы и ТЗ вообще разнеслись по разным рукавам галактики и даже согласовываться начали раздельно: прототипы согласовывались очень долго и обстоятельно, ТЗ — по старинке, не читая.

«Проектировщика» посадили рисовать эскизы и чуть-чуть думать про структуру сайта, менеджер продолжил общаться с клиентом и собирать требования, а на ТЗ вообще перестали обращать внимание, в результате чего прототип и ТЗ зажили раздельной жизнью.

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

Рисунок 10. Прототип сложной информационной системы

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

Особенности разработки по прототипам

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

Резюме: В разработке творится хаос, множество людей занимается зачастую противоположными вещами, посреди хаоса стоит менеджер, который по-прежнему разрывается между менеджментом и проектированием.

Что делать

Таковы популярные методики проектирования, принятые на рынке. Конечно же, жизнь несколько сложнее и встречаются самые разные вариации,, но в целом все они укладываются в одну из схем, описанных выше. И уж точно в любом случае менеджер является в проекте и организационным, и «мозговым» началом, а проектировщик в лучшем случае занимает роль исполнителя, ничем не отличающегося от дизайнера или верстальщика.

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

Рисунок 11. Польза современного проектирования

Для того, чтобы вернуть истинный смысл понятию «проектирование», надо отмотать ситуацию назад и, прежде всего, разобраться с разделением ролей менеджера и проектировщика и объединить их в систему, чтобы они максимально эффективно решали клиентские задачи, приносили прибыль агентству и были полезными для целевой аудитории.

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

А пока буду рад выслушать ваши мнения и соображения по поводу подходов, которые мы разобрали в этой статье. До связи!

Автор: Алексей Бородкин, Notamedia (Руководитель отдела аналитики и проектирования)

Комментарии участников рынка

Михаил Галушко

Компания: AIC Media
Должность: Руководитель направления финансовой экспертизы, информационный архитектор

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

У нас в AIC были испытаны несколько методологий проектирования и сейчас мы используем единую схему сбора и систематизации требований, которая сразу озвучивается и разъясняется клиенту. ТЗ (спецификация) в этой схеме — финальный результат проектирования, где в процесс равным образом вовлечены все ключевые специалисты на проекте: помимо менеджера это UX-директор, арт-директор, бизнес-аналитик, проектировщик и дизайнер, в идеале — еще стратег и копирайтер.

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

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

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

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

При необходимости детальные прототипы и/или сверстанный дизайн проходят через этап юзабилити-тестирования, который включает в себя следующие работы:

— Очный компьютерный тест под видеозапись действий пользователя

— Очный компьютерный тест с применением eye tracker

— Личное формализованное интервью по итогам выполнения теста

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

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

Руслан Кокин

Компания: UXhot
Должность: Проектировщик интерфейсов

Складывается мнение, что Алексей путает понятия проектирование взаимодействия и проектирование архитектуры проекта (технической реализации). Задача проектировщика взаимодействия не просто рисовать экскизы и чуть-чуть думать про структуру сайта. Напротив, проектировщик взаимодействия продумывает концепцию и структуру продукта, экраны ключевых и второстепенных страниц, логику взаимодействия и точки реакции (call-to-actions). Результатом работы, обычно, является полнофункциональный прототип в html с продуманной логикой всего проекта. Данная работа крайне необходима, особенно для сложных информационных систем, так как позволяет до написания первой строчки кода разработать логику продукта с учетом бизнес-задач и потребностей целевой аудитории. Другими словами — сделать проект логичным и удобным для пользователя, при этом решащим бизнес-задачи заказчика.

Цитата: Это было в корне неверным шагом, поскольку даже самый лучший прототип никогда не будет описывать проект так глубоко, как это может делать ТЗ с описанием структуры данных, функциональными схемами, протоколами обмена данных и т.п.

У прототипов, собственно, и нет задачи описывать проект на уровне функциональных схем и протоколов обмена данными. Этим уже должны заниматься непосредственно разработчики, имея на руках работающую модель того, что должно в итоге получиться.
Проектирование и ТЗ никогда не идут параллельно, как в схеме Алексея. Первично, собираются все необходимые данные для начала работ, при необходимости проводятся исследования. Эту работу выполняет не только менеджер проекта, но и непосредственно проектировщик. Далее, проектировщик выявляет группы целевой аудитории проекта (т. н. персонажи), продумывает концепцию продукта и логику взаимодействия персонажей с продуктом. Только после этих предварительных работ начинается проектирование взаимодействия (отрисовка полнофункциональных макетов). Эта работа утверждается заказчиком и после завершения проектирования составляется ТЗ на техническую реализацию по прототипу. То есть ни какой параллельной (согласно схеме Алексея) работы по проектированию и ТЗ не может быть в принципе.

Цитата: Для простых проектов разработчику достаточно прототипов, в случае сложных разработок ему приходится все домысливать и доделывать самостоятельно на свой страх и риск;

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

Было бы интересно узнать, где Алексей получил (и получил ли вообще?) такой опыт работы с проектированием. К сожалению, проектирование интерфейсов довольно молодая дисциплина и потому большая часть т. н. проектировщиков вовсе не являются ими. От того и получаются вот такие странные, как описанно в статье, представления о проектировании и его роли в проекте.

Тем не менее, хочется верить, что Алексей сможет предложить хорошую систему проектирования, поэтому с удовольствием буду ждать продолжения материала.

Дмитрий Подлужный

Компания: Spacebox
Должность: Арт-директор

Автор кидается громкими словами и общими утверждениями, не утруждая себя ссылкой на какие-то источники этих сведений. Чего только стоят фразы «популярные методики проектирования, принятые на рынке», «вернуть истинный смысл понятию „проектирование“», «эта система не просто работает — она не может не работать», — все это вполне достойно стать лозунгами на транспарантах, но где ссылки на источники или исследования с подтверждением этих высказываний.

Автор забыл, что большинство сайтов в России делается маленькими студиями или отдельными веб-мастерами и не стоит так легко сбрасывать их в прошлый век. Заказчик до сих пор хочет лично общаться и лично принимать участие в обсуждениях, творчестве и это нормально для части рынка.

Проектирование всегда присутствует в веб-разработке. Осознанно или нет, им могут заниматься разные люди в разных ролях, но все это зависит от структуры компании, и нет единой правильной конфигурации, которая могла бы охватить всё.

Проделанный труд по написанию такого объема текста достоин уважения, но статьей можно смело растапливать камин, не опасаясь упустить что-то полезное.

Степан Овчинников

Компания: ИНТЕРВОЛГА
Должность: Генеральный директор

Алексея тема явно давно волнует. Заглавие статьи подводит к мысли, что автор знает как правильно.
Статья анонсирована в духе классического университетского «обоснования актуальности».

Честно говоря, я ожидал такого же содержания, тем более что в начале сказано «все плохие, я Д\’Артаньян».

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

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

Описанные схемы с разделением труда мне, честно говоря, не встречались.

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

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

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

В любой здоровой схеме должен быть мозговой центр, отвечающий за общение, сбор требований, подготовку решений, и отвечающий за все это. Это — менеджер, он же (для меня) проектировщик.

Разумеется, это предъявляет большие требования к мозгам и социальному развитию этого менеджера. А кто говорил, что их по объявлениям можно набирать?

Что же касается некоей волшебной методики, которая «не может не работать» — пока я скептик. Я не верю в серебряную пулю, я верю в адекватность людей и способность организаций адаптироваться к изменениям.

С нетерпением жду второй части статьи.

 

Алексей Шишкин

Компания: Redsoft
Должность: Генеральный директор

Нужно, очень нужно писать новые статьи о проектировании — чем больше контента на эту тему, тем сложнее в ней разобраться и у нас будет больше клиентов на проектирование :)

А если серьезно, Алексей рассказал только о части экзотичных подходов к проектированию, ведь есть еще проектирование силами дизайнеров, тестировщиков, верстальщиков и даже офис-менеджеров. Но в реальности на рынке дорогих проектов, где проектирование востребовано, их доля не так уж велика — почти все опытные компании давно работают примерно по схеме, про которую Алексей расскажет позже с отклонениями, связанными с эволюцией внутри каждой конкретной компании.

И для автора коммент — картинки порадовали, но воды многовато, на мой взгляд, в духе американских книжек для чайников.

 

Святослав Бочкарев

Компания: «Кельник»
Должность: Руководитель отдела разработки проектов

Алексей Бородкин провел настолько живую ретроспекитву процесса проектирования в веб-разработке, что некоторые читатели наверняка пустили скупую слезу по ушедшей вседозволенной молодости.

Описанные стадии — естественный процесс развития проектирования. Для формирования качественных процессов ряд компаний прошли некоторые из этих этапов. И главные роли теперь за аналитиками и UX-дизайнерами.

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

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

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

Надеюсь, в следующих статьях Алексей расскажет, как настроить процессы проектирования, соблюдая баланс между качеством проработки решений и скоростью их реализации.

Анатолий Емельянов

Компания: ONE TOUCH
Должность: CEO

Совмещать описание ТЗ с проектированием интерфейсов — крайне неправильно.

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

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

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

При таком подходе будет меньше издержек: у команды увеличивается понимание и ответственность за проект.

Кроме того, надо учитывать и вовлеченность клиента. Необходимо показывать заказчику промежуточные этапы работы. При возникновении решения задачи важно не игнорировать согласование с клиентом. Согласование позволяет избежать подводных камней, которые в дальнейшем могут повлиять на результат всей работы. Узнав о них на этом этапе, можно сэкономить кучу времени и сил, избежав переделки функционала в дальнейшем.

Это также решает и уровень понимания проекта клиентом.

Светлана Шелаева

Компания: Redsoft
Должность: Проектировщик

Я не так давно влилась в сферу веб-разработок, поэтому про древние схемы особо не знала. Спасибо за экскурc!

Так получилось, что к нашей студии ни одна из перечисленных схем не походит на 100%. У нас с появлением первых проектировщиков задача по написанию ТЗ сразу легла на них. Я считаю, что это очень логично, так как проектировщик должен знать о проекте не меньше, чем менеджер и даже больше, когда дело касается деталей. У нас проектировщик подключается к проекту со второй встречи с клиентом, и ему дается полное право обсуждать все вопросы с ним напрямую без участия менеджера. То есть, он сразу вникает в курс дела.

Если у проектировщика мало опыта, то менеджер вникает в суть проекта и продолжает быть проектировщиком, как это было описано в статье. Но как только менеджер чувствует, что он может доверить проект проектировщику, он начинает заниматься чисто менеджерскими обязанностями. У нас в студии пока практикуются оба варианта.

Я считаю, что корень проблемы состоит в том, что на российском рынке пока мало таких проектировщиков, которые могут полностью потянуть проект, особенно сложный. А почему мало — потому что эта профессия в России еще молодая (в некоторых студиях, насколько я знаю, до сих пор нет проектировщиков). То есть, у большинства проектировщиков еще мало опыта, поэтому они в основном работают подмастерьями у менеджеров.

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

Резюме по статье: наверное, эмоциональная статья больше захватывает читателя, но хотелось бы меньше рефлексии по поводу того, почему все так плохо и неправильно, а больше дела. Поэтому будем ждать следующих статей про правильную систему проектирования, поскольку, на мой взгляд, главная задача сейчас — обучать и выращивать грамотных проектировщиков! )

Владимир Попов

Компания: Агентство интернет-маркетинга Level Up
Должность: Директор

Мы делаем правильно, потому что это работает.

Итак, 7 шагов к успешному проекту.

1. Мы давно и успешно используем такую схему разработки:

Анкета -> ТЗ -> Прототип -> Концепция дизайна -> Дизайн и т.д. 

2. До правильного проектирования делаем правильное ТЗ.

Для этого у нас есть правильный менеджер проекта. Иногда, нужен помощник, но менеджер должен «быть в теме» на 100%. Даем всем участникам проекта сказать свое слово и каждому утвердить в ТЗ свою часть проекта: дизайн, разработка, оптимизация, контент.

3. Гибкость — это свойство менеджера проекта, а не тех писателя. Используйте его по полной. И если не стоит жестких ограничений бюджета, то на стадии ТЗ можно делать дополнительные продажи. Заказчик чаще всего готов к участию в мозговых штурмах и появлению «допов» в результате штурмов. И увеличение бюджета в пределах 30% всегда можно придумать с равноценной пользой для дела. Для менеджера это дополнительная мотивация в рутинном процессе, для заказчика — возможность воплотить все свои ожидания.

ТЗ определяет структуру разделов сайта, тип, порядок и приоритет размещения контента, сценарии пользователей. Это все необходимо утвердить с заказчиком до начала проектирования.

4. Проектирование начинается ручкой на бумаге на первой рабочей встрече с заказчиком. Скетчи готовит менеджер, иногда заказчик проявляет свою творческую инициативу.

Ваш менеджер стесняется рисовать? Научите его этому!

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

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

7. Если на сайте главное — имидж, то сперва утверждаем дизайн концепцию, а проектируем уже на ее основе.

Спасибо автору!

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

Желаю удачи в построении системы!

 

 

Если Вы хотите дать экспертный комментарий к статьям, публикуемым на CMS Magazine, следите за анонсами материалов в нашей группе в Facebook.

Комментарии (Facebook)

Рекомендуем:


CMS Magazine CMS Magazine
RSS-подписка
CMS Magazine CMS Magazine
CMS Magazine