Так, спасибо за вопросы. Кое-что я забыл уточнить в статье. Уточняю сейчас: описанное в статье исследование мы проводим, когда клиент принял решение делать сайт и хотя бы приблизительно представляет, зачем и для кого он его делает.
Это, безусловно, не бизнес-анализ и не маркетинговое исследование. Наше исследование не ответит на вопросы: «Стоит ли делать сайт?», «Как зарабатывать?», «Каков объём рынка?», «Кто целевая аудитория?» и т.п. Это всё предмет маркетингового и бизнес-анализа.
Наше исследование даёт качественную информацию: Как сделать сайт по выбранной бизнес-модели? Чего ЦА ожидает от такого сайта, какие задачи планирует решать с его помощью? Каковы критерии оценки сайта? и т.п. Добавил это в статью.
О целевой аудитории мы должны знать нужен ли ей такой сайт и, если да, то зачем.
Это хороший проверочный вопрос, который часто даёт полезную качественную информацию про опыт и критерии оценки сайта. Например, задавая этот вопрос про сайт бутика ХХХ (см. пример плана исследования), я получил несколько ответов «Нет», а, уточнив, почему не нужен, получал следующие ответы: «А потому что видела я такие сайты: они дурацкие, неудобные, плохо показывают одежду, на них часто нет цен, на сайте висят уже проданные вещи». Понятно, что все эти ответы, если их инвертировать — это критерии оценки сайта.
«Нужен ли вам вебпроект, где вы сможете общаться с вашими друзьями, заводить новых, размещать фотографии, обмениваться сообщениями и т.д.», то гарантировано на нас польется поток описанный мной ранее, а именно: «бред», «я лучше так встречусь», «сделаю свой сайт», или коронный ответ, который меня просто выводит — «дак и зачем это, я и сейчас могу такое сделать на coolsite.narod.ru».
Именно так. Нужно узнать, что у него на уме, чего он хочет, чем он будет руководствоваться, принимая решение: идти дальше главной страницы или нет, звонить ли, заказывать ли продукт и т.п.
Мне кажется, что вы, Corrado, как верно заметил VeryWell, имеете в виду исследование с отличными от наших задачами. Наше исследование не нацелено на создание успешной бизнес-модели — оно помогает создать успешную модель взаимодействия с посетителем. Оно помогает создать сайт (или любой другой аналогичный продукт), который будет нравиться посетителю, «общение» с которым будет приятным и полезным, который, в рамках выбранной бизнес-модели, будет максимально эффективно решать задачи посетителя и нашего клиента.
Смотрите, вы же сами пишете: «В итоге моя мысль сводится к тому, что для понимания надобности решения какой либо «проблемы» совсем не нужны углубленные исследования, все это можно только почувствовать по настроения на рынке.» Что значит «почувствовать»? Чтобы почувствовать настроение на рынке, необходимо его изучить. Когда вы делаете сайт, полагаясь только на собственное мнение и «чувство», риск ошибиться и сделать сайт, который не будет удовлетворять посетителя, резко увеличивается (если только вы до этого не сделали пару десятков таких же сайтов). А это выброшенные время и деньги.
Согласен с последней фразой: нужно узнать, какие задачи люди хотят решать. И, действительно, часового интервью в 95% не нужно; у нас обычно получается 20-30 минут. Безусловно — опять вы правы — нельзя напрямую брать желания будущего пользователя сайта и делать, как он сказал. Его мнение — это всего лишь основание для принятия вами профессионального решения.
А отрицание пользы исследования, как мне кажется, идёт от того, что вам никогда не приходилось проводить исследование и видеть, какие результаты оно даёт. Если я не прав, и вы проводили исследования, в следствие чего в них разочаровались, то поправьте меня.
А это было, собственно, основной идеей — сделать максимально простое и понятное руководство.
Пользу исследования осознают многие. Некоторые даже что-то слышали про методики, но вот как это сделать применительно к сайту, если у тебя нет соответствующего образования и опыта, — это вопрос, на который мы попытались дать чёткий ответ.
Вы учили клиента на его собственных ошибках. Этот способ наиболее распространённый, но, на наш взгляд несколько негуманный :) Хотя, есть такие люди, которых иначе не научишь, что уж там.
Данил, очень хорошо написанная и полезная статья. Думаю, многие поймут, зачем нужен хороший договор. Комментарии, кстати, не менее ценные получились.
Я от себя добавлю, что очень полезно дополнять договор так называемыми Правилами работы над проектом. Правила, во-первых, дают клиенту представление о том, как будет идти работа, во-вторых, в случае спорных или сложных ситуаций помогают их разрешить, и, в-третьих, отлично организуют процесс с самого начала, что позволяет избежать потерь времени и ресурсов.
Я начал писать комментарий и понял, что у меня уже получается пару тысяч знаков. Так у меня получилась статья «Рабочий процесс как важная часть договорённостей с клиентом». Она про то, зачем нужно оговаривать правила в договоре и, вообще, обучать клиента.
Мы прописываем в договоре передачу прав на весь продукт, т.е. Сайт целиком, и отдельно — на его составляющие. Лично мы передаём систему управления контентом и средства разработчика только в право пользования, но не распоряжения. Проектная документация, дизайн, вёрстка переходят в полное распоряжение Заказчика.
Светлана, я понял ваш вопрос. Изумительно, что вы это спросили.
Тут имеет смысл уточнить, что проект и ТЗ — суть вещи принципиально разные. Задача проекта — определить цели, направление и ключевые точки, а задача ТЗ — прописать детально, что и как делать, чтобы разработчик мог выполнить работу. Проект либо не содержит таких деталей, либо содержит их, но допускает их изменение. ТЗ же должно быть предельно чётким, хотя и оно должно допускать изменение.
Вообще, наш опыт говорит, что пытаться прописать всё и максимально детально на этапе проектирования, а иногда даже ТЗ — это потеря времени, причём! это относится не только к большим проектам, но к ним в большей степени. Гораздо эффективнее управлять изменениями в процессе работы над проектом. Но это не означает, что проект должен быть на 3 страницах и содержать только общие слова. Важна золотая середина, о которой вы упомянули. К сожалению, словами её определить трудно; в отсутствии примера (мы его готовим), я не могу вам сейчас продемонстрировать это наглядно, но обещаю, что это будет сделано.
Про потерю актуальности данных могу сказать, что если входящие данные имеют свойство быстро терять актуальность, что в идеале должно выясниться в процессе исследования, то это — отличная информация для проекта: связанные вещи на сайте прописываются как предполагающие частые изменения.
Резюмирую: углубляться в детали на уровне проекта не стоит, а какой объём данных можно считать достаточным для перехода к разработке интерфейсов и программированию — это лучше показать на примере реального проекта.
Да, такое может произойти, но в принципе другим разработчикам боятся хорошего проекта, сделанного чужими руками, не стоит. Проект даёт им ту информацию, которая им всё-равно понадобится.
Если они хотят облечь его в удобную для себя форму — да, пожалуйста. В русском языке слова для такого действия нет, а в английском есть — debrief, т.е. переформулировка задания под себя с уточнением непонятных мест. Пусть дополнят и уточнят проект и работают в своё удовольствие.
Есть другая проблема — иной взгляд на проект. Это когда другой разработчик смотрит на проект и думает, что он бы сделал всё (или половину) иначе. Что же, он имеет право так думать, но клиент с проектировщиком работали над проектом и, видимо, не просто так его утвердили. Значит, он действительно соответствует целям клиента и предлагает правильные решения. В таком случае клиенту нужно найти разработчика, который конструктивно посмотрит на проект, возможно, дополнит его и возьмётся за работу.
Приятная особенность проекта в том, что он не прописывает мелкие детали и оставляет определённую степень свободы разработчику.
Это, безусловно, не бизнес-анализ и не маркетинговое исследование. Наше исследование не ответит на вопросы: «Стоит ли делать сайт?», «Как зарабатывать?», «Каков объём рынка?», «Кто целевая аудитория?» и т.п. Это всё предмет маркетингового и бизнес-анализа.
Наше исследование даёт качественную информацию: Как сделать сайт по выбранной бизнес-модели? Чего ЦА ожидает от такого сайта, какие задачи планирует решать с его помощью? Каковы критерии оценки сайта? и т.п. Добавил это в статью.
О целевой аудитории мы должны знать нужен ли ей такой сайт и, если да, то зачем.
Это хороший проверочный вопрос, который часто даёт полезную качественную информацию про опыт и критерии оценки сайта. Например, задавая этот вопрос про сайт бутика ХХХ (см. пример плана исследования), я получил несколько ответов «Нет», а, уточнив, почему не нужен, получал следующие ответы: «А потому что видела я такие сайты: они дурацкие, неудобные, плохо показывают одежду, на них часто нет цен, на сайте висят уже проданные вещи». Понятно, что все эти ответы, если их инвертировать — это критерии оценки сайта.
Очень-очень-очень спорное заявление.
Мне кажется, что вы, Corrado, как верно заметил VeryWell, имеете в виду исследование с отличными от наших задачами. Наше исследование не нацелено на создание успешной бизнес-модели — оно помогает создать успешную модель взаимодействия с посетителем. Оно помогает создать сайт (или любой другой аналогичный продукт), который будет нравиться посетителю, «общение» с которым будет приятным и полезным, который, в рамках выбранной бизнес-модели, будет максимально эффективно решать задачи посетителя и нашего клиента.
Смотрите, вы же сами пишете: «В итоге моя мысль сводится к тому, что для понимания надобности решения какой либо «проблемы» совсем не нужны углубленные исследования, все это можно только почувствовать по настроения на рынке.» Что значит «почувствовать»? Чтобы почувствовать настроение на рынке, необходимо его изучить. Когда вы делаете сайт, полагаясь только на собственное мнение и «чувство», риск ошибиться и сделать сайт, который не будет удовлетворять посетителя, резко увеличивается (если только вы до этого не сделали пару десятков таких же сайтов). А это выброшенные время и деньги.
А отрицание пользы исследования, как мне кажется, идёт от того, что вам никогда не приходилось проводить исследование и видеть, какие результаты оно даёт. Если я не прав, и вы проводили исследования, в следствие чего в них разочаровались, то поправьте меня.
Да, подождите, пожалуйста. На следующей неделе точно выложим.
А если результаты, то они они будут выложены примерно через неделю в отдельной статье.
Пользу исследования осознают многие. Некоторые даже что-то слышали про методики, но вот как это сделать применительно к сайту, если у тебя нет соответствующего образования и опыта, — это вопрос, на который мы попытались дать чёткий ответ.
Я от себя добавлю, что очень полезно дополнять договор так называемыми Правилами работы над проектом. Правила, во-первых, дают клиенту представление о том, как будет идти работа, во-вторых, в случае спорных или сложных ситуаций помогают их разрешить, и, в-третьих, отлично организуют процесс с самого начала, что позволяет избежать потерь времени и ресурсов.
Я начал писать комментарий и понял, что у меня уже получается пару тысяч знаков. Так у меня получилась статья «Рабочий процесс как важная часть договорённостей с клиентом». Она про то, зачем нужно оговаривать правила в договоре и, вообще, обучать клиента.
Тут имеет смысл уточнить, что проект и ТЗ — суть вещи принципиально разные. Задача проекта — определить цели, направление и ключевые точки, а задача ТЗ — прописать детально, что и как делать, чтобы разработчик мог выполнить работу. Проект либо не содержит таких деталей, либо содержит их, но допускает их изменение. ТЗ же должно быть предельно чётким, хотя и оно должно допускать изменение.
Вообще, наш опыт говорит, что пытаться прописать всё и максимально детально на этапе проектирования, а иногда даже ТЗ — это потеря времени, причём! это относится не только к большим проектам, но к ним в большей степени. Гораздо эффективнее управлять изменениями в процессе работы над проектом. Но это не означает, что проект должен быть на 3 страницах и содержать только общие слова. Важна золотая середина, о которой вы упомянули. К сожалению, словами её определить трудно; в отсутствии примера (мы его готовим), я не могу вам сейчас продемонстрировать это наглядно, но обещаю, что это будет сделано.
Про потерю актуальности данных могу сказать, что если входящие данные имеют свойство быстро терять актуальность, что в идеале должно выясниться в процессе исследования, то это — отличная информация для проекта: связанные вещи на сайте прописываются как предполагающие частые изменения.
Резюмирую: углубляться в детали на уровне проекта не стоит, а какой объём данных можно считать достаточным для перехода к разработке интерфейсов и программированию — это лучше показать на примере реального проекта.
Если они хотят облечь его в удобную для себя форму — да, пожалуйста. В русском языке слова для такого действия нет, а в английском есть — debrief, т.е. переформулировка задания под себя с уточнением непонятных мест. Пусть дополнят и уточнят проект и работают в своё удовольствие.
Есть другая проблема — иной взгляд на проект. Это когда другой разработчик смотрит на проект и думает, что он бы сделал всё (или половину) иначе. Что же, он имеет право так думать, но клиент с проектировщиком работали над проектом и, видимо, не просто так его утвердили. Значит, он действительно соответствует целям клиента и предлагает правильные решения. В таком случае клиенту нужно найти разработчика, который конструктивно посмотрит на проект, возможно, дополнит его и возьмётся за работу.
Приятная особенность проекта в том, что он не прописывает мелкие детали и оставляет определённую степень свободы разработчику.