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

14 января 2016, 17:55
16

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

Алексей Бородкин — о потусторонних математиках и космонавтах-юзабилистах, испортивших репутацию проектированию.

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

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

— А ты сам-то чём занимаешься?
— Проектированием и аналитикой.
— Ага. Понятно.

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

МегаФон ПроБизнес

Получите Кешбэк 100% за запуск рекламы с МегаФон Таргетом!

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

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

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

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

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

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

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

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

Есть еще и третья команда, самая интересная — космонавты-юзабилисты. (Подчеркну слово «космонавты» — нормальных юзабилистов, слава Богу, на рынке хватает.) Это особая порода. Спросишь их о проектировании — они начинают воздевать руки к небу, кричать страшные английские слова и аббревиатуры, то ли пытаясь тебя заколдовать, то ли произнося какой-то чит-код из забытой компьютерной игры (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


Телеграм Коссы — здесь самый быстрый диджитал и самые честные обсуждения: @cossaru

📬 Письма Коссы — рассылка о маркетинге и бизнесе в интернете. Раз в неделю, без инфошума: cossa.pulse.is

статья то толковая, но что за боль в самом начале не понятно, ну существуют себе эти группы людей и пусть дальше существуют, зачем это нытье? Пол статьи воды о том какие есть плохие некомпетентные засранцы. Некомпетентные засранцы жили и будут жить во всех профессиях и во все времена. И выжигаются они только потоком профессионалов на рынке и повышением уровня компетенции заказчиков и клиентов. А слушают тебя, а не этих засранцев, когда ты объяснить все нормально можешь и аргументированно, а не выливая в статью какую-то грязь про то ай ай ай какие они вот эти плохие есть. Ой ой.
Я живу по тому принципу, что засранцы должны быть названы засранцами. В ином случае они начинают окружать себя псевдоинтеллектуальным флером и казаться значимыми. Именно потому, что подобные "типа-проектировщики" в свое время узурпировали понятие проектирование, оно в итоге оказалось в том положении, в котором пребывает ныне.

Так что уж извините, засранцев я называл в своих статьях и выступлениях засранцами, называю и буду называть впредь. Если это нытье - ОК.

За отзыв по статье спасибо.
Тут про проектирование для внешних заказчиков. Жаль, что не учли проектирование для собственной фирмы (той, в которой работает тех. писатель), при разработке программы этой фирмы. В этом случае, заказчик внутренний. Хотя многое в статье применимо, но акцент на рисках (как бы заказчик не передумал или не обнаружилось, что его не верно поняли) видится флюсом. Мол, лишь бы не переделывать, лишь бы устроило заказчика. А как с коммерческой точки зрения будет работать реализованный проект - дело десятое.
Рустам, спасибо за меткое замечание! Совершенно верно, в моей статье большой упор строится на заказную разработку, поскольку я - плоть от плоти заказной разработки.

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

А пока рекомендую посмотреть мою лекцию про написание ТЗ (а на деле - про все проектирование целиком), которую я читал для Школы вебмастеров "Яндекса": https://events.yandex.ru/lib/people/1146131/ - я думаю, там есть что почерпнуть полезного.
Скачал видео, спасибо. Почему в вашем тесте ТЗ обозначен, как прикладной документ для графического дизайнера? То есть, важно, как это будет выглядеть, и не важно, как будет работать? Функционал же не относится к компетенции дизайнера.
Потому что это неправильный ответ Smile

Посмотрите внимательнее - вопрос звучит как "Какую роль НЕ выполняет ТЗ?"
Бальзам на душу.
Да еще какой.
Замечательный материал. Готов подписаться под каждой строчкой. Спасибо!
- 1 +
dph #
28.01.2016
А какой процент доработок у проекта за первый год эксплуатации? А за второй?Сколько времени от разработки (не человеко-часов, а в смысле диаграммы Ганта) занимает проектирование?А кто оплачивает проектирование?
Процент доработок зависит от проекта - у сервисов их больше, у контентных ресурсов - меньше, у корпоративных сайтов - совсем мало (хотя зависит и от компании).Про время от разработки - хороший вопрос. Я думаю, не сильно ошибусь, если назову цифру 20% (хотя тут много влияющих факторов).Проектирование оплачивает клиент, кто же еще.
Я за подход "всем сестрам по серьгам": развивающимся развитие, а засранцам - пинок, чтобы не расслаблялись.

И вот мой minimum minimorum для проектировщиков на все времена: "Разработка требований к программному обеспечению" Карла Вигерса, труды Купера, "33 стратегии войны" Роберта Грина и что-нибудь хорошее из Рэя Брэдбери.
Полезный материал, спасибо автору! Теперь Ваш сайт у меня в закладках.

✉️✨
Письма Коссы — лаконичная рассылка для тех, кто ценит своё время: cossa.pulse.is


Вход на cossa.ru

Уже есть аккаунт?
Авторизуйся через VK:
Vkontakte
Не забудьте написать email на странице своего профиля для управления рассылкой