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

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

Проектирование: вы делаете это неправильноНа правах вступления

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что делать

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

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

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

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

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

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

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *