Проектирование: вы делаете это неправильно
23.07.2014 | Автор: Алексей Бородкин, Artektiv (Директор по проектированию и аналитике) 
На правах вступления Очень, очень странно писать статью про проектирование в веб-разработке. Казалось бы, на эту тему уже сказано все, что только можно: Интернет и профильные СМИ полнятся статьями и целыми учебными курсами о том, что нужно спрашивать у клиента, как нужно изучать целевую аудиторию, какие программы использовать для рисования прототипов — и в какие цвета эти прототипы нужно раскрашивать.
Но соль ситуации в том, что весь этот разрозненный набор приемов и ухищрений не является полноценным проектированием и более похож на кустарное ремесло наподобие ремонта сапог. Приемы не сведены ни в какую систему, а потому их конечное назначение и смысл туманны даже для самих самопровозглашенных «проектировщиков». Как следствие, цены на проектирование берутся с потолка, клиент платит незнамо за что, и вместо логичного и понятного процесса получается какая-то порнография.
Рисунок 1. Вся суть современного проектирования
По моему глубочайшему убеждению, с этой кустарщиной надо бороться, а именно вводить единую систему, которая объединит правильные подходы к проектированию, сделает очевидно вредными неправильные подходы и придаст всему происходящему общий смысл.
Я говорю не про какую-то идеальную модель, а про реально работающую методологию, коль скоро лично я внедряю ее уже во вторую компанию.Эта система не просто работает — она, как и любая эффективная и правильно выстроенная система, просто не может не работать, если для нее создать правильные условия. И в этом ее оглушительное преимущество.
Рассказу об этой системе и будет посвящен предлагаемый вашему вниманию небольшой цикл статей. В данной статье — первой серии цикла — мы сделаем плавный заход на тему и рассмотрим вопрос, почему почти все существующие ныне практики веб-разработки глубоко порочны с точки зрения проектирования и подходят только для самых простых проектов.
Его величество веб-мастер Наш рассказ будет так или иначе касаться технического задания — основополагающего проектного документа, к которому большинство веб-разработчиков и клиентов всегда относилось довольно пренебрежительно. Что характерно, это отношение появилось не на пустом месте.
Вспомним, как в старину строилась разработка: был заказчик и был веб-мастер, который делал для заказчика сайт и при необходимости привлекал веб-дизайнера.
Весь этот нехитрый процесс укладывался в следующую схему:
Прелесть заключалась в том, что второй этап — продумывание проекта — происходил по большей части в голове у веб-мастера, который уточнял по ходу пьесы необходимые детали у клиента или, на худой конец, придумывал их сам. Таким образом, веб-мастер был сам себе веб-студия полного цикла.
Рисунок 2. Веб-мастер времен неолита (реконструкция)
Ни о какой проектной документации речь, понятное дело, не шла: в лучшем случае перед разработчиком лежали «хотелки» клиента, которые он затем брал в оборот, назначая цену и сроки по своему разумению. При этом качество проекта зависело лишь от таланта (или бездарности) веб-мастера и прочих непредсказуемых факторов, которые становились тем актуальнее, чем сложнее становился разрабатываемый проект и чем больше специалистов привлекалось к его реализации. Кроме того, особенно веселой становилось дальнейшее развитие проекта — в какой-то момент веб-мастер терялся в собственном проекте и непременно начинал противоречить сам себе.
О, бедный клиент тех времен! Начиная разработку интернет-проекта, он не знал, в какие мутные пучины ввергает себя — и когда он сможет получить результат. Ситуацию спасало только то, что к Интернету в те времена относились крайне несерьезно и криво работающий сайт никаких эмоций не вызывал; есть — и ладно.
Рисунок 3. Клиент выражает эмоции на этапе тестирования продукта.
Особенности разработки без проектной документации
Требования от клиента находятся только в голове у разработчика и нигде толком не зафиксированы
Никто не может дать оценку стоимости и длительности проекта до начала работы, что делает заведомо невозможным тщательное планирование сложного проекта.
Исполнитель не связан никакой документацией и волен делать все что хочет и как захочет, качество проекта зависит от степени гениальности веб-мастера и от миллиона других случайных факторов
Если у клиента или исполнителя возникают любые претензии по разработке, их невозможно предметно разобрать, поскольку отсутствует документальное обоснование и описание проекта.
Резюме: Разработка без проектной документации может срабатывать только на внутренних разработках, где заказчик постоянно вникает в суть разработки и находится в контакте с командой, и на самых простых проектах для невзыскательных клиентов.
Интернет рос, усложнялись веб-технологии, клиенты становились все привередливее, и методика разработки сайтов «на коленке» изжила себя. Веб-разработка начала требовать надлежащего управления, и это привело к появлению сразу двух взаимосвязанных вещей — менеджеров и технических заданий.
Веб-разработка по-советски В советские времена любая программная (и не только) разработка предполагала наличие технического задания — жестко регламентированного проектного документа, который по-казенному точно определял суть проекта. Такое ТЗ решало сразу несколько задач: определяло суть проекта, а также прикрывало задницы проектировщикам («Вы сделали не по ТЗ, вот оно и не работает») и, в ряде случаев, исполнителям («Мы сделали все по ТЗ, а то что оно не работает — уже ваши проблемы»).
Рисунок 4. Пример проекта, сделанного по ТЗ по ГОСТу
На рубеже XXи XXIвека, с началом интенсивного развития веб-разработки, проектам понадобилось юридическое подтверждение, которое можно было бы использовать как инструмент для решения различных недоговоренностей и конфликтов между заказчиком и исполнителем и снижения финансовых рисков.
И тут кому-то в голову пришла чудесная мысль достать с антресолей истории старые советские ТЗ, на которых делали программное обеспечение для управления атомными станциями и баллистическими ракетами, сдуть с них пыль, усовершенствовать и приспособить для нужд интернет-проектов.
Параллельно с этим на рынке веб-разработки появился менеджер — человек, который управляет процессами разработки. Разумеется, задача по написанию ТЗ была возложена именно на него — не программиста же занимать всякой писаниной, в самом деле.
Процесс разработки стал выглядеть так:
Как легко увидеть, подготовительная работа по проекту разошлась по двум направлениям: сперва разработчики чесали репу над тем, как решить задачу, а потом менеджер в одиночку носился с ТЗ и его согласовывал. Головной боли у менеджера хватало: дело в том, что ТЗ «советского» образца (также известное как «ТЗ по ГОСТу») было, мягко скажем, неудобным для работы. Когда менеджер излагал суть сайта-визитки в выражениях вида «программа работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы», мозг у всех действующих лиц неизбежно ломался и переставал работать.
Рисунок 5. Клиент принимает ТЗ по ГОСТу, вид изнутри
Немудрено, что большинство предпочло не сходить с ума в объятиях ТЗ по ГОСТу, а создать свои домотканые форматы ТЗ, которые бы выглядели юридически серьезно, но по сути ничего бы не описывали и сохраняли максимум свободы для разработчика. «Техническим заданием» этот документ был только по форме — по сути он был не более чем юридической бумажкой, на всякий случай прилагаемой к договору.
Особенности разработки по ТЗ, главная роль которого — быть приложением к договору ТЗ слабо описывает проект, требования клиента в ТЗ для галочки зафиксированы слабо или не зафиксированы вовсе Никто не может дать по такому ТЗ достоверную предварительную оценку стоимости и длительности проекта Разработчик, как и в случае разработки без ТЗ, не связан никакой прикладной документацией, и реализация проекта зависит исключительно от степени талантливости и добросовестности разработчика, что является серьезным риском для клиента (в первую очередь — финансовым) «Юридическое» ТЗ подходит только для разруливания самых общих юридических споров и не помогает разобраться исполнителям и клиентам с претензиями и конфликтами по существу Резюме: По своей сути данный подход ничем не отличается от метода разработки без ТЗ, только выглядит внушительно. К сожалению, он популярен до сих пор.
Данная методика разработки подходит для тех проектов, на которые наплевать и заказчикам, и разработчикам, но для которых нужен отчет для начальства и иных контролирующих органов.
Дальше произошло вот что. Рынок продолжал расти, а проекты становились все сложнее. Подход, когда ТЗ создается чисто для юридической галочки, стал приносить все больше и больше проблем: клиенты злились, что никто не учел по существу их требований, а владельцы веб-студий ужасались тому, что их проекты неизменно скатываются в недокументированный хаос, грозящий судебными разбирательствами и прочими неприятными вещами. Стало понятно, что ТЗ все-таки должно быть полезным и подробно описывать проект.
Рисунок 6. Медведь, сделанный по плохому ТЗ
Как этого добиться? Правильно! Нужно заставить менеджера писать более внятное ТЗ. И вот тогда произошло Великое и Ужасное: менеджер помимо управленца стал еще и проектировщиком.
Менеджер-слесарь V разряда Теперь в разработке стали выделять целый подготовительный этап: проектирование.
Процесс разработки стал выглядеть так:
Внешне разработка стала выглядеть более стройно: разработчик более не кидался с места в карьер, но тратил некоторое время на предварительное описание проекта, это описание согласовывалось, а дальше разработчик брал ТЗ за первооснову и делал на его основе проект.
На практике же вышло вот что. Требования к ТЗ стали куда жестче, но ТЗ продолжали писать менеджеры; ну, а чего — менеджер уже пишет ТЗ, так почему бы ему не продолжить это делать, ведь верно?
Неверно. В тот момент, когда менеджеров стали заставлять писать ТЗ к сложным проектам, произошло в корне неправильное событие: проектирование начал осуществлять человек, который, вообще говоря, не был для этого предназначен.
Ведь какова сфера ответственности менеджера? Это бюджетирование, организация команды, определение и выдерживание сроков проекта, ведение документооборота, ведение коммуникации с клиентом и внутренней командой и координация всей работы. Менеджер, по сути, выступает организующим началом в проекте, а это очень важная, сложная и требующая временных и мозговых затрат задача.
И вот к этому всему добру зачем-то прицепилось проектирование, наделив менеджера помимо организационных полномочий еще и функциями мозгового и смыслового центра проекта; в принципе, с тем же успехом менеджера могли заставить рисовать дизайн, натягивать верстку или писать скрипты (спасло то, что на тот момент должности дизайнера, верстальщика и веб-программиста были уже известны и понятны).
Рисунок 7. Разумный менеджер переживает по поводу самоидентификации
У менеджера начал трещать мозг: одной рукой он должен был заключать договоры, утешать клиентов, погонять программистов и разруливать конфликты, а другой — продумывать смысловую часть проекта, согласовывать ее с заказчиком и писать ТЗ. Все это требует глубочайшего погружения и колоссальной концентрации, и как менеджеры умудрялись писать осмысленные ТЗ, попутно отвлекаясь на звонки клиентов и проблемы команды, науке неизвестно.
Вдобавок ко всему у бедных менеджеров в голове разыгрался еще и конфликт между необходимостью принести как можно больше денег в компанию и желанием максимально эффективно спланировать решение поставленной клиентом задачи (в чем и состоит суть проектирования, вообще говоря). Это противоречие не имело видимого решения, и менеджеры тихо спускали свои «проектировочные» обязанности на тормозах, выдавая как-бы-технические документы, в которые на скорую руку запихивалось все подряд: от шаблонных требований к хостингу до того, в каком стиле и цветах должны быть выполнены иллюстрации. Эти документы имели дикую структуру и размытое предназначение, но клиенту было этого достаточно — он подписывал это домотканое ТЗ, прочитав от силы пару страниц.
Самое поганое, что у него было полное на то право: полученный документ был или слишком неконкретен для разработки, или слишком сложен для понимания клиентом, и никто не удосуживался построить процесс проектирования так, чтобы он был понятен и интересен всем сторонам.
Рисунок 8. Разумный клиент выражает свою озабоченность недочетами в ТЗ
В конечном счете менеджер на посту «проектировщика» на пару с недостаточно информированным клиентом полностью дискредитировали как техническое задание, так и труд проектировщика, превратив это в еще одну нудную формальность, которую все соблюдают в меру фантазии и сил. Проектирование так и не стало ключевым элементом управления практическим смыслом и ограничилось исключительно ТЗ.
Будем объективными: из этого правила были исключения, и из рук менеджера порой выходили нормальные и даже хорошие ТЗ, но это было заслугой исключительного таланта менеджера, геройствующего вопреки системе и своим должностным обязанностям — и именно по этой причине на него нельзя было полагаться как на системообразующий фактор.
Особенности разработки по ТЗ, которое пишет менеджер Учет требований клиента и написание детального ТЗ возложено на человека, у которого и без того миллион дел; По ТЗ можно дать оценку проекта, но все упирается в его качество —, а оно, как правило, хромает по причине, указанной выше; Разработчику чаще всего недостаточно такого ТЗ, ему приходится многое домысливать и доделывать самостоятельно на свой страх и риск; ТЗ помогает в разборе возможных претензий только тогда, когда оно написано качественно, что маловероятно в силу причин, указанных выше. ТЗ не разъясняется клиентам и воспринимается ими несерьезно, что всячески одобряется менеджерами; Резюме: Данная практика является самой популярной на рынке. Загруженность менеджера и наличие у него весьма обширных и ответственных обязанностей не дает ему погрузиться в проект и участвовать в проекте на всем протяжении в роли мозгового центра, отслеживая, чтобы он выполнял поставленные задачи.
Кроме того, все ограничивается написанием ТЗ — необходимым, но отнюдь не достаточным элементом качественного проектирования.
Писатель на страже веб-разработки Были и другие варианты. Когда стало ясно, что писать ТЗ — это дело долгое, кропотливое и занудное, разработчики щелкнули пальцами и сказали судьбоносную фразу: «О! Давайте посадим отдельного человека, который будет заниматься ТЗ!».
«Наконец-то все встанет на свои места!» — решите вы, и ошибетесь. Вместо того, чтобы углубить и расширить процессы проектирования, все почему-то решили ограничиться всего лишь одним инструментом — техническим заданием.
Процесс разработки стал выглядеть намного веселее:
Замечаете? От менеджера отрезали чисто прикладную задачу по написанию ТЗ, оставив всю остальную аналитико-мозговую канитель, включающую сбор требований и коммуникацию с заказчиком.
Что характерно, новому специалисту дали имя «технический писатель». И это очень точное слово: писатель не собирал требования, не ломал голову над внутренним устройством проекта и не составлял адские функциональные схемы — он просто писал ТЗ на основе информации, полученной от менеджера. В результате технический писатель оказался в роли пишущей машинки, а менеджер так и остался неполноценным «проектировщиком», не имея на то ни времени, ни возможностей. Более того, ему добавили еще и жернов на шею — передачу информации техническому писателю и контроль над его работой.
Рисунок 9. Технический писатель ликует по поводу поступившей от менеджера задачи
ТЗ получались красивые и обтекаемые по форме, но по сути принципиально ничего нового в них так и не появилось — было бы глупо ожидать этого в творении человека, у которого единственной задачей является написание ТЗ. Более того: тот факт, что требования и общие черты проекта задавал менеджер, а все формальные вещи писал технический писатель, внесло определенный хаос в проект и размыло ответственность по команде.
В ряде команд на технического писателя повесили-таки обязанность собирать требования с клиента, но сути это не изменило. Основным управляющим проекта остался менеджер — он продолжал объединять в себе и организационное начало, и аналитически-мозговое.
Разумеется, от этих всех рокировок клиент к ТЗ серьезнее относиться не начал и по-прежнему согласовывал его как придется.
Особенности разработки по ТЗ, которое пишет технический писатель Ответственность и понимание проекта размыто по команде. Развитие проекта определяет один человек, ТЗ пишет другой (а требования с клиента зачастую собирает третий). Качество ТЗ хромает, поскольку ТЗ пишет человек, перед которым стоит задача не спроектировать ресурс, а написать ТЗ. По такому ТЗ можно дать оценку проекта, но все упирается в его качество. Как и в прошлых случаях, разработчику недостаточно такого ТЗ, ему приходится многое домысливать и доделывать самостоятельно на свой страх и риск; ТЗ помогает в разборе возможных претензий, поскольку написано юридически корректно; ТЗ не воспринимается клиентами серьезно. Резюме: Формально за написание ТЗ берется отдельный человек, но он не является проектировщиком, поскольку основные функции проектировщика (контроль над практическим смыслом проекта) по-прежнему выполняет менеджер.
Таким образом, технический писатель стройности в разработке особо не прибавил. Хаос продолжал буянить и портить проекты.
«Непорядок! — снова решили разработчики, — Выходит, нам нужен отдельный проектировщик!»
И дальше совершили еще одну ошибку.
Проектировщик без проектирования Теперь в проекте появился человек под гордым названием «проектировщик», который занялся… нет, не проектированием. Он зачем-то стал рисовать эскизы страниц будущего интернет-ресурса — прототипы, и именно это и было названо гордым словом «проектирование».
И в этот момент проектирование окончательно скатилось в непередаваемый бардак.
Вот как интересно стал выглядеть процесс разработки:
Красота! Теперь прототипы и ТЗ вообще разнеслись по разным рукавам галактики и даже согласовываться начали раздельно: прототипы согласовывались очень долго и обстоятельно, ТЗ — по старинке, не читая.
«Проектировщика» посадили рисовать эскизы и чуть-чуть думать про структуру сайта, менеджер продолжил общаться с клиентом и собирать требования, а на ТЗ вообще перестали обращать внимание, в результате чего прототип и ТЗ зажили раздельной жизнью.
Это привело к печальным последствиям: некоторые влиятельные игроки рынка полностью заменили детальное обоснование проекта на веселые картинки, отказались от ТЗ и назвали это настоящим проектированием. Это было в корне неверным шагом, поскольку даже самый лучший прототип никогда не будет описывать проект так глубоко, как это может делать ТЗ с описанием структуры данных, функциональными схемами, протоколами обмена данных и т.п.
Рисунок 10. Прототип сложной информационной системы
Привлечение проектировщика для рисования прототипов кажется тем безумнее, что мозговым центром разработки при таком подходе по-прежнему остается менеджер, на котором замыкаются все-все процессы, а проектировщик выполняет чисто техническую и ограниченную роль.
Особенности разработки по прототипам Ответственность и понимание проекта предельно размыто по команде. Проектировочная команда завязана на менеджера, который продолжает выполнять и организационные функции, и аналитические. Проектирование подменяется на отрисовку прототипов. Прототипы заслоняют собой ТЗ, ТЗ или пребывает в зачаточном виде, или не пишется вообще. Такое «проектирование» стоит больших денег, но приносит минимальную ощутимую пользу; Для простых проектов разработчику достаточно прототипов, в случае сложных разработок ему приходится все домысливать и доделывать самостоятельно на свой страх и риск; ТЗ не воспринимается клиентами серьезно, правки идут исключительно на уровне прототипов. В результате проект не продуман, качество его исполнения хромает, он приносит убытки заказчику. Резюме: В разработке творится хаос, множество людей занимается зачастую противоположными вещами, посреди хаоса стоит менеджер, который по-прежнему разрывается между менеджментом и проектированием.
Что делать Таковы популярные методики проектирования, принятые на рынке. Конечно же, жизнь несколько сложнее и встречаются самые разные вариации, но в целом все они укладываются в одну из схем, описанных выше. И уж точно в любом случае менеджер является в проекте и организационным, и «мозговым» началом, а проектировщик в лучшем случае занимает роль исполнителя, ничем не отличающегося от дизайнера или верстальщика.
Для простых и дешевых проектов такой подход имеет практическую пользу, но использовать его для серьезных и сложных разработок бессмысленно и даже вредно, поскольку он приводит к большим финансовым рискам, бессмысленным задержкам и смысловым потерям. Проект перестает выполнять задачи, для которых он создавался, превращаясь в универсальный прожигатель бюджетов.
Рисунок 11. Польза современного проектирования
Для того, чтобы вернуть истинный смысл понятию «проектирование», надо отмотать ситуацию назад и, прежде всего, разобраться с разделением ролей менеджера и проектировщика и объединить их в систему, чтобы они максимально эффективно решали клиентские задачи, приносили прибыль агентству и были полезными для целевой аудитории.
Именно этой непростой задачей — выстраиванием правильной системы проектирования — мы займемся в следующих статьях нашего цикла.
А пока буду рад выслушать ваши мнения и соображения по поводу подходов, которые мы разобрали в этой статье. До связи!
Полный текст статьи читайте на CMS Magazine
