Проектирование сайта как консультационная услуга

    Два с половиной года назад хабровчан нужно было убеждать в необходимости проектирования. Сегодня поисковая выдача Яндекса по запросу «проектирование сайта» содержит больше сотни тысяч страниц (к сожалению, не всегда хорошего качества). Это говорит о консенсусе в отрасли — проектирование сайтов необходимо.

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

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

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

    Мы считаем, что самое главное на этой картинке — стрелки переходов от документа к документу. И вот почему.

    Поэтапное снижение неопределённости


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

    Качественный процесс проектирования поэтапно снижает неопределённость относительно будущего проекта.



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

    Когда клиент видит бриф на продаже проекта, а потом — интерактивный прототип через две недели тишины, он видит вот такую картину.



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

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

    В сознании всей проектной команды


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

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

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

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

    Что это значит для заказчиков и исполнителей?


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

    Если вы исполнитель:
    • Вам необходимо до начала проектирования проработать ожидания клиента.
      В идеале он должен осознать пункты для заказчика, описанные выше. Если клиент ожидает получить «вау, это именно то, что я хотел» и при этом вообще не участвовать в процессе, вы невероятно рискуете.
    • Вы должны быть готовы оказывать консультационную услугу.
      Вам нужно научиться щипцами извлекать из клиента информацию, прояснять расклады сил в компании (если там больше одного стейкхолдера), прорабатывать возражения, доказывать свою точку зрения и формировать образ эксперта в глазах клиента.
      «В работе стремителен, вопросов задаю мало» — это не может относиться к проектированию.
    • Проектирование не может быть дешёвым или бесплатным.
      «Разработка интерактивного прототипа: бесплатно при заказе разработки» — вы шутите или вы молодой фрилансер?!
      В зависимости от процесса, с учётом всех переговоров с клиентом (которые составляют большу́ю часть трудоёмкости), проектирование сайта с нуля не может занимать меньше 40-60 часов.
      Даже при стоимости часа для клиента около 1000 рублей (а это ниже среднего по рынку) стоимость проектирования составляет около 50 000 рублей.

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

    Видео выступления, копирайты и ссылки на источники

    Кельник
    34.23
    Company
    Share post

    Comments 38

      +4
      Налоговая очень не любит, когда в документах указывают консультационные услуги, особенно с большими суммами т.к. это любимый способ отмыва бабла.
        0
        Согласен. Но речь не о договорах, а о смысловом наполнении процесса. И об отношении сторон к проектированию.
          +1
          Мне кажется, что использование слова «услуга» не годится для общего определения. На мой взгляд, лучше так: Проектирование сайта — коммуникационный процесс создания образа будущего сайта, конечным результатом которой является одинаковое уточнение назначения, задач, структуры, функциональности, сценариев использования и тектоники сайта в сознании всей проектной команды.
            0
            одинаковое уточнение

            … понимание.
        +4
        >стоимость проектирования составляет около 50 000 рублей.
        80% заказчиков сайтов не доросли еще до такого

        >Два с половиной года назад хабровчан нужно было убеждать в необходимости проектирования
        имхо теперь надо ждать пока не хабровчан, а заказчиков надо будет НЕ убеждать

        PS: в целом статью прочитал с интересом и удовольствием, но как сказал выше пока из заказчиков не многие такое понимают
          +1
          Хуже. Многие делают умное лицо, но в проектную документацию залезают уже на этапе сдачи сайта с самым ненавистным мне вопросом «а как у нас с этим-то и с этим-то? а я думал, это само собой разумеется».
            0
            Заказчики сами не поймут. Они начнут это всё понимать, если все хабровчане будут убеждать в этом своих клиентов. Мы работаем над этим со своими клиентами, на конференциях и в статьях. Но мы как сообщество профессионалов обязаны подтягивать уровень клиентов — сами они не подтянутся, потому что это не их работа.
            +1
            Результатом проектирования должен являться документ – прототип. Так как вашему заказчику нужно проектирование для уточнения ТЗ и снижения затрат на разработку таким образом. Вы лишь описываете процесс. Да, он верный, было бы неплохо так поступать, но в большинстве (!) случаев если вы будете менять что-то в голове у генерального директора заказчика, вы просто растяните время для себя и для клиента, заставите его потратить неожиданно больше денег, чем он планировал, за счёт увеличения сроков и тп. Начинайте всегда с того, что хочет клиент – с создания прототипа. И лишь если у вас прекрасное взаимопонимание с клиентом, и вы чувствуете, что он ХОЧЕТ, чтобы ему объяснили и его научили – вмешивайтесь и меняйте. Иначе будет только минус.
              +1
              Прототип — это только следствие качественно выполненных работ. Если команда может прийти к одинаковому пониманию проекта без документации и без прототипа, проектирование от этого не пострадает. То есть, понимание первично, а документ вторичен.
                0
                Что вы будете делать, если в процессе работы над проектом придёт новый сотрудник? Опять приходить к общему взаимопониманию? С прототипом быстрее немного будет.
                +1
                Начинайте всегда с того, что хочет клиент

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

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

                  0
                  В принципе, вы всё верно описываете. Хорошо, если клиент принимает участие в работе. Только часто клиентам результаты важны, а принимать участие они в процессе не могут. Для того и нужны прототипы, – это простой способ согласовать понимание результата в процессе работы.
                    0
                    Не могу понять — клиент в итоге принимает участие в процессе или нет? Если клиент на протяжении проекта обсуждает с вами прототипы — это прекрасно. Если он не принимает такого участия, то с высокой долей вероятностью ему а) не нужна эта работа б) у вас не получится хорошее решение.
                0
                Есть один нюанс. Проектирование — работа, а не услуга (есть юридические различия), и у нее должен быть результат работ — проектная документация. Так во всех других отраслях.
                  +1
                  Алексей, ты говоришь про юридические тонкости и про отчётность. Это верно.

                  Но я говорю о том, что главное это не документация. Главное — одинаковое поэтапное снижение неопределённости относительно проекта. Если это свершилось при полном отсутствии документации — проектирование всё равно успешно. А по твоему определению результат отсутствует.
                    0
                    Когда я еще был врачом, меня учили, что историю болезни мы пишем для прокурора. Позже, уже в IT, я стал свидетелем нескольких разбирательств, которых не случилось бы при наличии проектной документации.

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

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

                    Снижение неопределенности — само собой, это одна из главных целей проектирования.
                      0
                      Алексей, ещё раз. Я совершенно не спорю с тем, что конечная документация необходима в подавляющем большинстве случаев. Но самым важным, что даёт проектирование в 99% случаев, является не документация. И эту разницу должны хорошо осознавать и исполнители, и клиенты — независимо от того, что написано в договоре.

                      У нас был случай, когда компания обратилась к нам за большим юзабилити-аудитом (с последующими возможными доработками сайта). Самым главным результатом проекта был не отчёт, а глубокое понимание команды на стороне клиента (включая генерального), что им нужно качественно отстраивать стратегию продаж. Они отправились восвояси без доработок сайта, и это было прекрасно — клиент получил то, что ему на самом деле нужно. В концепции «первичен документ» они бы пошли допиливать сайт и тратить деньги на то, на что их не нужно было тратить.
                        0
                        То есть, вы говорите, что документация должна писаться строго после прояснения деталей проекта? Вы это хотели сказать статьей?
                          0
                          Не совсем. Вообще говоря, документация пишется в процессе прояснения деталей. И именно процесс прояснения деталей (в сознании всех участников рабочей группы) является главным, а не итоговый документ. Итоговый документ — следствие.
                      0
                      Чтобы неопределенность отсутствовала, надо, чтобы определенность присутствовала. Любая определенность «на словах» — это не результат проектирования, а «просто поговорили». А я как-то привык к тому, что проектная документация служит защитой исполнителю на этапе приемки проекта.
                        0
                        Согласен с вами — в большинстве случаев при проектировании происходит именно прояснение, выяснение деталей и консалтинг. На это требуется как время непосредственной работы, так и время на «дозревание» мыслей по проекту в голове у всех участников проекта.
                        Отличная статья, спасибо!
                      0
                      Спасибо, за статью. Но я бы не назвал «проектирование...(не важно чего)» консультационной услугой. Тем более, что, как и было отмечено в первом комментарии, «консультационные услуги» (если это не аудит или юр. консультации) очень сомнительная статья расходов для всех гос. инстанций в любой стране.
                        +1
                        И давайте договоримся (как таксисты у вокзала) не брать за сайт меньше 100тр… АйТи мы или твари дрожащие =)
                          +1
                          Как я вас понимаю. Как же надоели эти студенты-самоделкины, считающие себя самыми умными, чтобы использовать фреймворки, и за три копейки генерирующие тонны говнокода. Я слышал, даже, что появился маньяк-убийца, знакомящийся с такими на сайтах о фрилансе.
                            0
                            Вы не уловили нотки сарказма.
                            Я — как исполнитель не уговорю клиента на услугу вида «проектирование сайта» и как заказчик скажу: А давайте я вам щас на листочке все нарисую и все…
                            Есть 2 вида клиента: Я_САМЫЙ_УМНЫЙ и Я_В_ЭТОМ_НИЧЕГО_НЕ_ПОНИМАЮ.
                            В первом случае спорить с клиентом бесполезно… какие к черту целевые группы, функционал. Крупное фото где он в пиджаке на главной странице и музыка чтоб на сайте играла. После 3 часов беседы про функционал: да-да-да, но фото и музыку оставьте…
                            Второй случай тоже не нуждается в проектировании. Клиент согласен на все что вы предложите. Че тогда бумагу марать.

                            Промежуточные случаи это когда один непрофессионал заказывает работу у другого непрофессионала, тогда идет совместное изучение, понимание, поиски решений. Ну и тут о проектировании говорить нечего.
                            п.с А демпинг в IT меня удручает — вы правы.
                              0
                              1. «Клиент согласен на все что вы предложите. Че тогда бумагу марать.» — делать надо не то, что вы предложите, а то, что нужно конечным потребителям клиента. Значит, их надо исследовать. Значит, проектирование необходимо.

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

                                Я не сказал, что нужно «отрыгнуть» никому не нужный продукт. Конечно нужно изучать рынок, целевую аудиторию, проводить маркетинговые исследования.
                                Надо определиться о клиентах / проектах какого уровня мы ведем речь.
                                Если заказчик серьезный, бюджет адекватный, планы долгие то это одно. Здесь я полностью согласен.
                                Но есть и заказчики другого уровня, коих большинство, где бюджет с трудом перекрывает разработку…
                                0
                                Клиент согласен на все что вы предложите. Че тогда бумагу марать.
                                Спустя месяц «пардон, я хочу музыку на главной и свое фото в пиджаке… и потом — у нас же не было никакого документа с самого начала, я думал, вы будете оперативно все реализовывать». Это, так сказать, закон изменчивости состояния заказчика. От него может спасти только формализация отношений. Поверьте мне, это важно. Я на этом один раз обжегся и теперь без плана действий (называйте это ТЗ, проектной документацией или как угодно) к работе не приступаю. В этом плане действий обычно подробно описывается и поведение, и структура не только страниц, но и данных, выведенных на эту страницу. И, кстати, написание не занимает много времени — стоит только привыкнуть. Зато споров и негатива практически нет.
                                  0
                                  закон изменчивости состояния заказчика

                                  Как правило (имхо) если заказчик адекватный все всегда нормально решается. А если, извините, мудак, то не тз, не договоры не спасают.
                                  Сайт — это некий живой организм. Сделать все сразу все правильно и хорошо это редкий случай. С нормальными заказчиками мы все время проводим ре-факторинг.
                            +1
                            Есть ширпотреб, есть индпошив
                            Есть типовая панель, есть индивидуальная планировка
                            Есть Лего, есть 3д принтеры

                            Хороший ширпотреб требует проектирования, но это происходит на фабрике, а не у прилавка

                            Короче говоря — покупайте спроектированное. Ну а индивидуально или массово — вопрос цели и бюджета.
                              +1
                              Увы, но клиенты всегда будут хотеть экономить, а нерадивые студенты всегда будут пилить сайты-визитки сотнями за три рубля. И ситуация эта вряд ли изменится в ближайшее время.
                              Да и что говорить о мелких проектах, когда владельцы крупных сайтов с гигантским трафиком не утруждают себя даже протестировать собственный продукт. И о качественном проектировании, думаю, даже речи не идет. Ведь все хотят быстрой прибыли, я уже не говорю о государственных проектах, которые пытаются сделать за неделю до Нового года, когда бюджет нужно СРОЧНО осваивать.
                              В общем печально, что ни говори.
                                0
                                Виктория, то же самое говорили о проектировании три года назад — и ничего, теперь все проектируют как миленькие. Ну или хотя бы делают вид. Дорогу осилит идущий.
                                  0
                                  Но есть и положительная тенденция. Приходилось встречать заказчиков, которые вдоволь нахлебались от нерадивых студентов. Зачастую экономия от использования услуг этих студентов выливается в дополнительные расходы в виде безбожного просерания всех сроков, ненадлежащего исполнения работы и т.д. За очень редким исключением, на выходе у таких исполнителей получается более-менее халтура. А те, у кого на выходе получается действительно что-то стоящее, как правило, очень быстро перестают быть фрилансерами. Не знаю, наверное у меня профессиональная деформация, но когда я от кого-то слышу «ну я сайтики делаю на вордпрессе и жумле», мне хочется вцепиться ему в глотку.
                                    0
                                    А те, у кого на выходе получается действительно что-то стоящее, как правило, очень быстро перестают быть фрилансерами

                                    Прокомментируйте. Кем они становятся?
                                      0
                                      Один такой знакомый стал тимлидом, другой лид девом.
                                        0
                                        У вас не правильное представление о фрилансе…
                                        Фрилансер — это не студент говнокодер… а самостоятельный специалист.
                                        Хороший фрилансер может зарабатывать в разы больше ведущих специалистов в компании.
                                        0
                                        Кто-то и свои компании открывает. :)
                                      0
                                      о государственных проектах, которые пытаются сделать за неделю до Нового года, когда бюджет нужно СРОЧНО осваивать.

                                      Если задача сформулирована как «освоить бюджет за неделю», то грех жаловаться на такую задачу :-)
                                      Говоря серьезно, нет проблемы выполнить работу в те сроки, в которые хочет клиент, даже если это 1 неделя. Узнайте его потребности и расскажите, что вы можете за 1 неделю успеть. Удивительно, но такой диалог в 99% случаев приводит и положительному результату: клиент знает, чем вы можете ему помочь, вы знаете, что действительно нужно клиенту и не даете невыполнимые обещания.

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

                                    Only users with full accounts can post comments. Log in, please.