Да, такое может произойти, но в принципе другим разработчикам боятся хорошего проекта, сделанного чужими руками, не стоит. Проект даёт им ту информацию, которая им всё-равно понадобится.
Если они хотят облечь его в удобную для себя форму — да, пожалуйста. В русском языке слова для такого действия нет, а в английском есть — debrief, т.е. переформулировка задания под себя с уточнением непонятных мест. Пусть дополнят и уточнят проект и работают в своё удовольствие.
Есть другая проблема — иной взгляд на проект. Это когда другой разработчик смотрит на проект и думает, что он бы сделал всё (или половину) иначе. Что же, он имеет право так думать, но клиент с проектировщиком работали над проектом и, видимо, не просто так его утвердили. Значит, он действительно соответствует целям клиента и предлагает правильные решения. В таком случае клиенту нужно найти разработчика, который конструктивно посмотрит на проект, возможно, дополнит его и возьмётся за работу.
Приятная особенность проекта в том, что он не прописывает мелкие детали и оставляет определённую степень свободы разработчику.
Не узнали ничего — это хорошо. Значит, вы в теме. Насчёт очевидности — это, к сожалению, не так. Далеко не так…
Про исследования подробнее будет в следующей статье, но только не про особенности, а про методику с примерами. Особенности поведения пользователей в каждой области свои или вовсе от области не зависят. Возможно, если будет интересный материал касательно конкретной области, опубликуем.
Опыт разработки больших проектов есть, и исследование там действительно занимало 2-4 месяца. Светлана, что именно интересно в этом плане? Дело в том, что исследование для большого проекта качественно и методически мало чем отличается от исследования для маленького проекта. Отличается количественно: продолжительностью, объёмом изученных источников, размером выборки (не всегда, кстати, потому что есть маленькие проекты на большую аудиторию), более широким набором представителей ЦА и т.п.
Общий алгоритм определения стоимости сайта прост как пареная репа: все затраты + ожидаемая прибыль. А вот как определить все затраты — это уже интереснее.
Мы всегда стараемся сначала заключить договор на проектирование и оцениваем сайт уже по готовому проекту. Если клиент решительно не готов к такой схеме, то есть два варианта развития событий:
1. Если это простой сайт, то мы можем прикинуть его стоимость +10%, включая проектирование, и заявить её клиенту.
2. Если это сложный сайт, то мы вынуждены отказываться от работы без предварительного проектирования. Увы, корректная оценка без проектирования часто просто невозможна.
Мы уже придумали заказчика, выбрали легенду — вот здесь можно посмотреть — и как раз занимаемся проектированием. Выложим отдельно описание каждого этапа проектирования, начиная с целеполагания и исследования.
Я как раз в «P.S.» указал, что статья для затравки и описывает в целом процесс проектирования. Детали будут позже в отдельных топиках. Ваше пожелание я учёл.
Менеджеру проекта, который лично с клиентом не взаимодействует, пока тот не соизволит сам приехать в офис и все нам рассказать? Дизайнеру, которому вообще пофиг?
Вот это грустно. Это неправильно поставленный процесс создания сайта. Менеджер проекта — первый, кто должен с клиентом взаимодействовать.
Мы работаем в России. И проектируем несколько дней, несколько недель или месяцев — столько, сколько нужно.
Насчёт сайтов-визиток: размер сайта не играет роли. Проектирование нерентабельно только в проектах с очень маленьким бюджетом — 10-20 тысяч рублей. Да и то, можно сократить проектирование хотя бы до уровня, который есть в видении, и результат уже будет лучше.
Надо объяснять и, лучше всего, если не понимают, не работать. Не надо прогибаться: сделаете плохой сайт, клиент останется недоволен, ничего не заработаете, потратите время и нервы.
У нас были такие случаи, но нам почти всегда удавалось объяснить клиенту, зачем нужно проектирование. В тех редких случаях, когда не удавалось, отказывались работать.
Вам нужно заниматься своим делом, а проектировать должен проектировщик до того, как вы приступите к работе. Если же вы и есть проектировщик, то не начинайте рисовать до создания проекта сайта.
Какой отличный комментарий. Давайте-ка по пунктам:
1. Проект и Техническое задание — это принципиально разные вещи. Клиент действительно, за некоторыми исключениями, может не знать про существование ТЗ как такового. Его дело — согласовать ключевые моменты, которые и формируются при проектировании, а остальное — сугубо ваша ответственность.
2. 99% наших клиентов, вне зависимости от размера, сферы деятельности, возраста, пола, национальной принадлежности, социального статуса и т.п. после непродолжительной, но весьма содержательной беседы, понимают, зачем нужно проектировать. Повторюсь, только в проектах с маленьким бюджетом и столь же маленькими задачами проектирование нерентабельно.
3. Уважаемый Alexx_ps, клиент НЕ должен определяться, какие разделы у него будут на сайте. Это должны определять вы и только вы в процессе проектирования. Вы должны родить 100% разделов и подразделов, детально их описать по предложенной нами или другой схеме, а клиент должен это утвердить.
По соображениям NDA мы не можем выкладывать реальные проекты, но мы как раз готовим шаблон проекта для вымышленного шоу-рума женской одежды «XXX», упоминавшегося в предыдущей статье в шаблоне видения.
Это будет тем более полезно, что будет заметно реальное отличие видения, короткого пред-проекта для оценки задачи, от реального проекта — постановки задачи.
Самое хорошее в статье — это вывод. Потому что он конструктивный.
Насчёт «дурацких» просьб клиента: мой опыт говорит, что за каждой такой просьбой обязательно стоит что-то помимо личных амбиций (за редчайшим исключением), и это что-то надо отыскать. Тогда и волк будет сытым, и овцы останутся в целости и сохранности. Вот такое, например, часто случается у нас в работе:
— Хочу яркий зелёный шрифт и побольше в заголовке!
— Судя по всему, вы считаете, что заголовок сейчас недостаточно виден. Хотите усилить акцент на нём, чтобы он лучше читался?
— Да!
— Как вам вот такие варианты (предлагаете грамотные варианты усиления акцента)?
— Отлично, беру вот этот.
Если они хотят облечь его в удобную для себя форму — да, пожалуйста. В русском языке слова для такого действия нет, а в английском есть — debrief, т.е. переформулировка задания под себя с уточнением непонятных мест. Пусть дополнят и уточнят проект и работают в своё удовольствие.
Есть другая проблема — иной взгляд на проект. Это когда другой разработчик смотрит на проект и думает, что он бы сделал всё (или половину) иначе. Что же, он имеет право так думать, но клиент с проектировщиком работали над проектом и, видимо, не просто так его утвердили. Значит, он действительно соответствует целям клиента и предлагает правильные решения. В таком случае клиенту нужно найти разработчика, который конструктивно посмотрит на проект, возможно, дополнит его и возьмётся за работу.
Приятная особенность проекта в том, что он не прописывает мелкие детали и оставляет определённую степень свободы разработчику.
Не узнали ничего — это хорошо. Значит, вы в теме. Насчёт очевидности — это, к сожалению, не так. Далеко не так…
Про исследования подробнее будет в следующей статье, но только не про особенности, а про методику с примерами. Особенности поведения пользователей в каждой области свои или вовсе от области не зависят. Возможно, если будет интересный материал касательно конкретной области, опубликуем.
Опыт разработки больших проектов есть, и исследование там действительно занимало 2-4 месяца. Светлана, что именно интересно в этом плане? Дело в том, что исследование для большого проекта качественно и методически мало чем отличается от исследования для маленького проекта. Отличается количественно: продолжительностью, объёмом изученных источников, размером выборки (не всегда, кстати, потому что есть маленькие проекты на большую аудиторию), более широким набором представителей ЦА и т.п.
Общий алгоритм определения стоимости сайта прост как пареная репа: все затраты + ожидаемая прибыль. А вот как определить все затраты — это уже интереснее.
Мы всегда стараемся сначала заключить договор на проектирование и оцениваем сайт уже по готовому проекту. Если клиент решительно не готов к такой схеме, то есть два варианта развития событий:
1. Если это простой сайт, то мы можем прикинуть его стоимость +10%, включая проектирование, и заявить её клиенту.
2. Если это сложный сайт, то мы вынуждены отказываться от работы без предварительного проектирования. Увы, корректная оценка без проектирования часто просто невозможна.
Мы уже придумали заказчика, выбрали легенду — вот здесь можно посмотреть — и как раз занимаемся проектированием. Выложим отдельно описание каждого этапа проектирования, начиная с целеполагания и исследования.
Вот это грустно. Это неправильно поставленный процесс создания сайта. Менеджер проекта — первый, кто должен с клиентом взаимодействовать.
Насчёт сайтов-визиток: размер сайта не играет роли. Проектирование нерентабельно только в проектах с очень маленьким бюджетом — 10-20 тысяч рублей. Да и то, можно сократить проектирование хотя бы до уровня, который есть в видении, и результат уже будет лучше.
У нас были такие случаи, но нам почти всегда удавалось объяснить клиенту, зачем нужно проектирование. В тех редких случаях, когда не удавалось, отказывались работать.
Вам нужно заниматься своим делом, а проектировать должен проектировщик до того, как вы приступите к работе. Если же вы и есть проектировщик, то не начинайте рисовать до создания проекта сайта.
1. Проект и Техническое задание — это принципиально разные вещи. Клиент действительно, за некоторыми исключениями, может не знать про существование ТЗ как такового. Его дело — согласовать ключевые моменты, которые и формируются при проектировании, а остальное — сугубо ваша ответственность.
2. 99% наших клиентов, вне зависимости от размера, сферы деятельности, возраста, пола, национальной принадлежности, социального статуса и т.п. после непродолжительной, но весьма содержательной беседы, понимают, зачем нужно проектировать. Повторюсь, только в проектах с маленьким бюджетом и столь же маленькими задачами проектирование нерентабельно.
3. Уважаемый Alexx_ps, клиент НЕ должен определяться, какие разделы у него будут на сайте. Это должны определять вы и только вы в процессе проектирования. Вы должны родить 100% разделов и подразделов, детально их описать по предложенной нами или другой схеме, а клиент должен это утвердить.
Принято. Напишу об этом отдельно.
По соображениям NDA мы не можем выкладывать реальные проекты, но мы как раз готовим шаблон проекта для вымышленного шоу-рума женской одежды «XXX», упоминавшегося в предыдущей статье в шаблоне видения.
Это будет тем более полезно, что будет заметно реальное отличие видения, короткого пред-проекта для оценки задачи, от реального проекта — постановки задачи.
Насчёт «дурацких» просьб клиента: мой опыт говорит, что за каждой такой просьбой обязательно стоит что-то помимо личных амбиций (за редчайшим исключением), и это что-то надо отыскать. Тогда и волк будет сытым, и овцы останутся в целости и сохранности. Вот такое, например, часто случается у нас в работе:
— Хочу яркий зелёный шрифт и побольше в заголовке!
— Судя по всему, вы считаете, что заголовок сейчас недостаточно виден. Хотите усилить акцент на нём, чтобы он лучше читался?
— Да!
— Как вам вот такие варианты (предлагаете грамотные варианты усиления акцента)?
— Отлично, беру вот этот.