Чем проектирование отличается от шарлатанства

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

А ты видишь, что ему ничего не понятно. Нет проектирования, нет рынка, нет ценности для клиента — нет ни-че-го. А благодаря кому так вышло?

Эффективная и выгодная реклама с сервисом от МегаФона

Широкий выбор рекламных каналов, более 100 параметров по интересам, подробная аналитика и другие возможности уже ждут в Личном кабинете. А еще кешбэк 100% за запуск рекламы в первый месяц и еще 10% — каждый месяц.

Узнать больше >>

Реклама. ПАО «МегаФон». ИНН 7812014560. ОГРН 1027809169585. ERID LjN8K1P7y.

Перечень странных персонажей

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

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

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

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

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

Есть еще и третья команда, самая интересная — космонавты-юзабилисты. (Подчеркну слово «космонавты» — нормальных юзабилистов, слава Богу, на рынке хватает.) Это особая порода. Спросишь их о проектировании — они начинают воздевать руки к небу, кричать страшные английские слова и аббревиатуры, то ли пытаясь тебя заколдовать, то ли произнося какой-то чит-код из забытой компьютерной игры (HCD! ISO! UX! CX! IDDQD! DNKORNHOLIO!).

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

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

Для таких юзабилистов не существует технической начинки продукта — это вообще не про них.

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

И есть одна вещь, которая объединяет вышеперечисленные команды — это неумение ответить на один-единственный вопрос. Очень простой и очень важный: «А нафига вам проектирование?».

Царь-вопрос и Царь-ответ

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

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

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

Смысл в другом.

Есть такой замечательный американский дядька — Карл Вигерс. Он сделал много всего хорошего и полезного, но главным делом его жизни я считаю книгу Software Requirements (или, как ее громоздко называют в наших краях, «Разработка требований к программному обеспечению»).

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

В одной из глав Карл Вигерс пишет, что на американском рынке разработки 40% бюджета проекта уходит на переделки, появившиеся из-за того, что заказчик и разработчик плохо сформулировали требования к продукту и вообще не поняли друг друга.

Вдумайтесь — 40%! Почти половина стоимости проекта улетает в трубу из-за того, что на берегу перед отплытием не продумали предстоящую веб-разработку!

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

Можно ли избежать подобных потерь? Можно. И именно тут на сцену и выкатывается проектирование.

Его величество Настоящее Проектирование

Многие это забывают, но смысл проектирования заключается в минимизации рисков разработки (риски не уложиться в сроки и бюджеты).

Каким образом проектирование минимизирует риски?

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

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

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

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

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

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

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

4. Проектирование фиксирует все договоренности. Кульминацией процесса правильного проектирования является написание большого, единого описания создаваемого продукта — спецификации (более популярное, хотя и в корне неверное название такого документа — ТЗ).

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

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

Красиво, правда?

А ведь я еще не сказал самое главное. При всех своих прелестях проектирование отнимает всего лишь 15% от бюджета на проект — это подтверждают и Карл Вигерс, и наш опыт Notamedia. Доля проектирования на различных проектах неизменно колебалась в пределах 13–17%.

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

И вот в этом заключается единственный смысл проектирования: фиксированное по стоимости проектирование минимизирует не фиксированные по стоимости риски.

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

Источник картинки на тизере: Flickr