Некоторое время назад на Facebook появилась схема, которая была названа «алгоритмом создания сайта» (на стене Димитрия Атабекова, спустя какое-то время аккаунт был закрыт). Она была дана своим автором на русском языке, но поскольку на русском получилось мелко и не очень разборчиво, мы приводим полнометражный вариант оригинала на английском языке.
Оригинал на английском:
По этому поводу там же на Facebook развернулась достаточно интересная дискуссия. Поскольку Facebook не позволяет создавать дискуссии полноценные и широкомасштабные, то многие из высказанных идей так и повисли в воздухе – тем не менее они заслуживают того, чтобы их перечислить.
Началась дискуссия с утверждения, что «контент — король сети, а внимание к нему на схеме нулевое». Оно действительно небогатое, в смысле внимание, на этой схеме – а реально, как показывает наш опыт, отраженный в т.ч в Методике успешного сайта, именно на создание контента уходит больше всего времени. Эту мысль высказал Герман Фаудер, журналист и копирайтер, который наверняка на своей «профессиональной шкуре» ощущает не только основную ценность сайта, но и стоимость расходов на его создание.
Смотрим еще раз на схему этапов создания сайта вверху – предполагается, что диаметр кружков отражает трудоемкость. Да, создание контента автор не уважает… Или просто «вынес за схему», оставив внутри только структуру и наполнение?
Вторая идея – это сомнение в сроках (2 месяца) – была высказана Владимиром Горцем, который утверждает: «Такой тайминг реален при четких требованиях и быстрых фидбеках от клиента и 100% понимании и доверии клиента к дизайнерам». Невозможно не согласиться с этим утверждением, однако наша сегодняшняя цель идет дальше – хотелось бы понять, почему от клиента не поступает четких требований и не бывает достаточно быстрой обратной связи. К этому мы перейдем через пару абзацев.
Третья идея – это серьезные сомнения в ходе благополучных результатов переговоров, которые заняли большую часть дискуссии. Эти сомнения выражаются в обсуждении, может ли сайт-прототип заменить техническое задание или нет? Юрий Новосад, например, утверждает, что прототип часто и есть техническое задание, но ему оппонирует Ярослав Корец, который согласен использовать прототип в качестве технического задания только для сайта-визитки. Потому что без технического задания (вот тут вскрывается суть, внимание!) у клиента уже в ходе разработки появится куча новых желаний: «Давайте добавим здесь, давайте прикрутим там, давайте сделаем так, чтобы все сотрудники получали уведомления…». Встает вопрос: «Почему разработчик этим озабочен?». Ведь высказанные пожелания вроде нетрудоемкие, а делают сайт лучше? Неужели трудно заложить в смету некоторую небольшую сумму «на шлифовку» и пойти навстречу? К этому мы вернемся еще через абзац.
И в итоге – вывод: «В теории — прекрасный алгоритм работы, на практике он превращается в полный хаос» (Александр Нечухаев).
Теперь выскажем наше мнение о причинах хаоса. И кроются они в том самом контенте, которому в этой схеме действительно не уделено достаточного внимания.
Повторимся: создание контента заслуживает того, чтобы быть описанным отдельно, параллельно этапам, названным «Content (содержание)» и «Desigh (разработка, а не только внешний вид)». В принципе, когда структура контента ясна, за месяц-полтора, которые нужны для разработки, контент создать можно. Не всегда получается, да, но можно.
А почему не получается?
Дело в том, что сайту требуется не просто контент, а контент структурированный. Когда сайты только появлялись и компании просто был нужен сайт, чтобы на нем разместить пару своих рекламных материалов и свои контакты, проблем с контентом не возникало. Согласования, даже если и требовались, шли гораздо быстрее. Но в последние годы контент на сайте стал сложнее, посетители сайта ждут хорошей структуры и связных текстов. И мы сейчас уже знаем, что именно должен описывать сайт. Даже если сайт не описывает «7 нот бизнеса», которые представлены на схеме вверху, тем не менее, сайт является самым настоящим самоописанием компании, которое она предлагает на суд клиента.
Стрелки на схеме, которая использована в качестве заставки, показывают формирование политики компании, но объяснения выходят за пределы заметки. Интересующимся могу сказать, что книга не только есть во всех магазинах, а еще и на торренте…
Итак, необходимо создать структурированный контент сайта, в котором отражены разные аспекты самоописания компании. Эта задача ставит зачастую и руководство, и сотрудников в тупик, потому что бреши ощущаются мгновенно, а быстро их заделать не удается. Возникают споры, нестыковки: между руководством, между руководством и сотрудниками, а еще чаще между возникающими идеями и реальной практикой. То есть становится ясно, что в описании компании, или, что хуже, – в бизнесе есть не просто нестыковки, а реальные недоработки, так называемые bad practices, которые просто так не переделаешь. На отсутствие самоописания и нестыковки различных аспектов самоописания накладываются особенности бизнес-процессов, особенно этапов согласований и утверждения решений. Во многих компаниях, особенно крупных, эти этапы производятся достаточно медленно и, кроме того, могут предполагать консенсус нескольких должностных лиц. А если таковых несколько, то одно из них болеет, пара-тройка то отсутствуют, то заняты, и все это растягивается на вечность.
Вот почему не получается учитывать мелкие полезные предложения заказчика за небольшую сумму!!! Согласования там так же мучительны и отнимают практически столько же времени, что и крупные решения. Разработчику это убыточно.
Кроме того, корпоративная культура компании может допускать «проваливание» ответственности, когда итоговые решения некому принять и подписать. Она также может содержать в себе такой забавный компонент, как «нелюбовь заканчивать».
Е.Бр., реплика в сторону: «нелюбовь заканчивать» — очень распространенная вещь в строительстве. Это знает любой, кто делал ремонт, строил дом или промышленный объект. Сама по себе эта «нелюбовь» непонятна, потому что именно на стадии завершения объект, будь то сайт или дом, приобретают законченный вид, начинают блестеть и радовать. Тем не менее феномен чрезвычайно распространен. Хочется по этому поводу рассказать забавный случай из консультационной практики, который хоть и не связан с сайтами, но весьма показателен. За консультацией обратился владелец небольшого цеха по изготовлению окон и дверей, причем жалоба у него была стандартная – нет денег. Придя в цех, я обнаружила огромное количество так называемой «незавершенки» — полуготовых дверей и окон в цехе было столько, что они мешали пройти. Тут же двое клиентов кричали, что «Все давным-давно должно быть отгружено!», из чего можно было сделать вывод, что с недостатком заказов у цеха проблем нет. А есть проблема в том, что заказчик, он же владелец компании и он же начальник производственного цеха, страшно не любит заканчивать работу. Он договаривается с клиентами, передает заказы в цех, работа начинается – но когда дело доходит до итоговой отделки, упаковки и отгрузки, просто ничего не происходит. Клиенты остаются без заказов, а компания без денег. В той конкретной ситуации найти решение удалось легко, потому что в пятнадцатиминутном разговоре выяснилось, что заместитель владельца компании как раз заканчивать любит. Все рекомендации свелись к тому, чтобы заказы принимал один, а завершал работу другой человек. Буквально через две недели компания не имела проблем ни с «незавершенкой», ни с деньгами. Надо сказать, что эту рекомендацию – развести начало работ и завершение проекта по разным людям, каждый из которых будет либо начинать, либо заканчивать, можно считать достаточно универсальной.
А каковы рекомендации участников дискуссии по отношению к этому алгоритму? Они сводятся к тому, как вы догадались, чтобы составлять технические задания, причем официально подписанные со стороны клиента, которые ограничивали бы трудоемкость разработчиков в рамках оговоренного в договоре бюджета.
Последствия такого подхода на практике известны. Конечно, цель достигается – если считать целью трудозатраты разработчика по проекту. Проект разработки сайта действительно перестает быть бесконечным, сайт сдается клиенту. Клиент, однако, который по мере создания сайта увидел огрехи технического задания, остается недовольным. Конфликты все равно возникают.
Что же делать?
Первый шаг, который приходит в голову, — посмотреть, что происходит в других сферах, которые сталкиваются с той же самой проблемой, но существуют дольше и потому должны наработать больше инструментов? Другая сфера – это прежде всего программирование, которое для таких случаев создало методологию экстремального программирования, но об этом в следующий раз.
Оставить комментарий