Comments 51
Материал получился довольно объемный, но я надеюсь, что многие смогут почерпнуть там полезную информацию.
В свою очередь, предлагаю публиковать в комментарии типовые ошибки, не вошедшие в материал, а я по результатам дискуссии произведу через пару дней апдейт статьи.
В свою очередь, предлагаю публиковать в комментарии типовые ошибки, не вошедшие в материал, а я по результатам дискуссии произведу через пару дней апдейт статьи.
Блестящий материал, Андрей!
Автор молодец, написано хорошо.
Самое гланое это конечно: Отсутствие четкого осознания целей проекта или по другому "да чтоже тебе надо с!"
У меня когда-то был начальник который каждый месяц, обсуждал со всеми нами концепцию сайта и в течении 1,5 года что я там работал мы собирались и каждый что-то говорил, потом через месяц концепция признавалась неправильной и все делалось по новой.
Самое гланое это конечно: Отсутствие четкого осознания целей проекта или по другому "да чтоже тебе надо с!"
У меня когда-то был начальник который каждый месяц, обсуждал со всеми нами концепцию сайта и в течении 1,5 года что я там работал мы собирались и каждый что-то говорил, потом через месяц концепция признавалась неправильной и все делалось по новой.
Да, осознание, зачем все это надо - ключевой момент любого проекта вообще. Поэтому под номером один и записал.
Через месяц менять концепцию - это, конечно, работать плодотворно не позволит, а через полгода - почему бы и нет?
В таком случае возможность довольно сильной переработки структуры информации стоит закладывать сразу.
Примерно то же можно сказать о редизайне - рестайлинг, смену торговой марки и т.п. лучше планировать заранее. Ну по крайней мере обозначить, что через год-два будет, скорее всего, меняться то-то и то-то.
Чтобы не переделывать всё.
В таком случае возможность довольно сильной переработки структуры информации стоит закладывать сразу.
Примерно то же можно сказать о редизайне - рестайлинг, смену торговой марки и т.п. лучше планировать заранее. Ну по крайней мере обозначить, что через год-два будет, скорее всего, меняться то-то и то-то.
Чтобы не переделывать всё.
Согласен с Вами. Статья отличная. Осознание - важнейшая часть проекта.
Клевая статья, чем то похожа на статью Ашманова, правда он там клеймил программистов..:)
Что касается Дизайн-концепта, при заключении договора нужно данную бумажку прикреплять к договору как документ, иначе супер-гений в голове принимающего решение не остановится никогда пытаясь выжить из описанного максимальную пользу.
Может и получится такое что клиент на этапе создания дизайна дает задний ход и говорит что на бумажке было одно, а так другое и мол я хочу другой вариант, иначе денег Вы не получите поскольку я воспринимаю дизайн исключительно глазами а не в концепте. Для таких мудреных нужно прописывать в договоре пункт о дополнительной предоплате за разработку нового варианта Дизайн-коцепта.
Как правило таких клиентов видно сразу, они говорят что нам не надо ничего навороченного, что-то простенькое, если услышали такое можете смело отказываться или дописывать договор, сразу поясню это очень долгосрочный проект ждет впереди – начиная от созданий Дизайн-концепта который как правило придется прорисовывать и заканчивая утверждением оного.
P.S. – Хорошо заполненный бриф – уже половина дела!
Что касается Дизайн-концепта, при заключении договора нужно данную бумажку прикреплять к договору как документ, иначе супер-гений в голове принимающего решение не остановится никогда пытаясь выжить из описанного максимальную пользу.
Может и получится такое что клиент на этапе создания дизайна дает задний ход и говорит что на бумажке было одно, а так другое и мол я хочу другой вариант, иначе денег Вы не получите поскольку я воспринимаю дизайн исключительно глазами а не в концепте. Для таких мудреных нужно прописывать в договоре пункт о дополнительной предоплате за разработку нового варианта Дизайн-коцепта.
Как правило таких клиентов видно сразу, они говорят что нам не надо ничего навороченного, что-то простенькое, если услышали такое можете смело отказываться или дописывать договор, сразу поясню это очень долгосрочный проект ждет впереди – начиная от созданий Дизайн-концепта который как правило придется прорисовывать и заканчивая утверждением оного.
P.S. – Хорошо заполненный бриф – уже половина дела!
Всё так... Но когда заказчик говорит "ничего навороченного" мозг тянет в дрёму и трудно сразу поверить что именно этот клиент выжмет из тебя все соки. А не хочешь проблем - составляй четкое ТЗ...
Собственно о том и речь - ТЗ (Дизайн-концепт) будет очень долго утверждаться и к любому из вариантов придется делать визуализацию причем очень хорошего уровня.
В конце проекта, прибыль будет так не значительна при соотношении потраченного времени на один такой проект, что в будущем задумаешься о подобном сотрудничестве. Либо усиливать юридические моменты сделки.
В конце проекта, прибыль будет так не значительна при соотношении потраченного времени на один такой проект, что в будущем задумаешься о подобном сотрудничестве. Либо усиливать юридические моменты сделки.
На самом деле, это ошибки, применимые не только к заказчикам сайтов, но и к любому управлению проектами. Основы менеджмента форева!))))А статья очень интересная и полезная получилась. Спасибо за отличное переложение теоретических основ на актуальную практику))
Пункты 6 и 7 в типовом цикле прохождения проекта я бы поменял местами. Конечно, первая страница продает лучше, но базовых значительно больше, и отталкиваться лучше от них. Это если сайт не для визитки :)
Регистрация домена студией с одной стороны, конечно, ошибка. С другой стороны, когда у компании-заказчика нет человека, который смог бы вовремя перерегистрировать домен, есть реальный риск потерять домен вообще навсегда. В моей практике прецеденты были.
Очень хорошая статья. Уже в избранном.
От себя добавил бы:
1. Обязательное разделение этапов разработки с соответствующим документальным закрытием по этапам.
2. Цикл прохождения проекта может коренным образом отличаться от приведенного (хотя это и так понятно). Например если необходимо прототипирование.
От себя добавил бы:
1. Обязательное разделение этапов разработки с соответствующим документальным закрытием по этапам.
2. Цикл прохождения проекта может коренным образом отличаться от приведенного (хотя это и так понятно). Например если необходимо прототипирование.
Контролем откатов должна заниматься служба безопасности. А то получается, что где-нибудь на Age of web висит средняя минимальная стоимость сайта, равная 730$ (внизу страницы), но это совершенно не значит, что вот эти ребята живут исключительно с откатов.
Статья хорошая, но почему вы ее опубликовали в "колонках" не в "блогах"? ИМХО, тут она потеряется. Конечно, больше охват аудитории, чем в блоге, но вы же не одну статью на эту тему напишите? ;-)
В целом с мыслями согласен. Самое смешное, что практически все это прописано в старом-добром ГОСТ 34 "Информационные системы", от которого все воротят нос из-за того, что он якобы старый. На самом деле, вы его и описали. Весь вопрос в жизненном цикле системы. Вот если использовать каскадную или итерационную модель, тогда методика и система управления проектом поменяются. Даже со стороны заказчика.
Далее, про сроки. Если вы назначаете только дедлайн - это гарантированный пролет по срокам, потому как вы не можете оценить в процессе разработки степень отклонения по срокам, а отклонения есть всегда. В Project Management принято понятие Milestones - контрольные точки. По сути - это сроки завершения каждого из подэтапов. Тогда вы на каждом этапе сможете оценить изменение по срокам.
Касательно приведенной этапности работ. Это пример этапности для очень простого шаблонного сайта с минимальной управляемостью и отсутствием интеграции с какими-либо другими ИС. Потому как в противном случае, в начале надо определиться с платформой разработки, а она в свою очередь может существенно органичить возможность дизайна. В случае сложной системы, проектирование системы и БД затмит дизайн, как бык овцу.
Ну и конечно, документирование системы и обучение специалистов заказчика. Отдельный разговор о приемке системы.
В целом с мыслями согласен. Самое смешное, что практически все это прописано в старом-добром ГОСТ 34 "Информационные системы", от которого все воротят нос из-за того, что он якобы старый. На самом деле, вы его и описали. Весь вопрос в жизненном цикле системы. Вот если использовать каскадную или итерационную модель, тогда методика и система управления проектом поменяются. Даже со стороны заказчика.
Далее, про сроки. Если вы назначаете только дедлайн - это гарантированный пролет по срокам, потому как вы не можете оценить в процессе разработки степень отклонения по срокам, а отклонения есть всегда. В Project Management принято понятие Milestones - контрольные точки. По сути - это сроки завершения каждого из подэтапов. Тогда вы на каждом этапе сможете оценить изменение по срокам.
Касательно приведенной этапности работ. Это пример этапности для очень простого шаблонного сайта с минимальной управляемостью и отсутствием интеграции с какими-либо другими ИС. Потому как в противном случае, в начале надо определиться с платформой разработки, а она в свою очередь может существенно органичить возможность дизайна. В случае сложной системы, проектирование системы и БД затмит дизайн, как бык овцу.
Ну и конечно, документирование системы и обучение специалистов заказчика. Отдельный разговор о приемке системы.
Опубликовал в колонках, поскольку формат показался более подхяодящим =)
Насчет дедлайнов согласен абсолютно. Но хочу отметить, что материал нацелен на двольно широкую аудитию, поэтому мне показалось более разумным указать базовый тезис, который уже можно детализировать.
Этапность - тоже согласен. Приведенный цикл довольно прост и, конечно, не универсален. Однако расписывать более сложные схемы, наверное, в этом материале не имела смысла, этому можно посвятить отдельную интересную статью.
Спасибо за комментарии!
Насчет дедлайнов согласен абсолютно. Но хочу отметить, что материал нацелен на двольно широкую аудитию, поэтому мне показалось более разумным указать базовый тезис, который уже можно детализировать.
Этапность - тоже согласен. Приведенный цикл довольно прост и, конечно, не универсален. Однако расписывать более сложные схемы, наверное, в этом материале не имела смысла, этому можно посвятить отдельную интересную статью.
Спасибо за комментарии!
"1. Отсутствие четкого осознания целей проекта" - очень верно что "номер один"!
отличная статья.
отличная статья.
Чётко написаниое ТЗ со всеми прибамбасами от заказчика как приложение к подписаному договору с обеих сторон, шаг в лево шаг, шаг в право от ТЗ, соответственно и цена растёт в геометрической прогрессии - $$$$$$$$$$$$$$$, что тоже необходимо чётко указать в договоре.
Заказчик такая сука, что всю кровь выпьет,пока Вы не заставите его подписаться под чётко сформулированным ТЗ и полный вперёд после предоплаты в 70% от стоимости заказа:-)
Заказчик такая сука, что всю кровь выпьет,пока Вы не заставите его подписаться под чётко сформулированным ТЗ и полный вперёд после предоплаты в 70% от стоимости заказа:-)
С трудом представляю четко прописанный Дизайн-концепт и привязку к функциональности, все равно тот же шаг влево, шаг вправо будет.
Исходить он причем будет от разработчика, поскольку иной раз из-за мелочи складывается представление о проекте и его разработчике. Опять же было бы не лишний подписать доп. соглашение на поддержку ресурса, кроме оговоренных сроков гарантии.
Исходить он причем будет от разработчика, поскольку иной раз из-за мелочи складывается представление о проекте и его разработчике. Опять же было бы не лишний подписать доп. соглашение на поддержку ресурса, кроме оговоренных сроков гарантии.
Четко написанное ТЗ при непонимании Заказчиком, чего ему надо от сайта, выльется в бесполезную поделку, которой ни Заказчик доволен не будет, ни студия в портфолио положить без стыда не сможет
Спасибо, Андрей.
Очень хорошая подборка материала в хорошо изложенном виде.
Очень хорошая подборка материала в хорошо изложенном виде.
Отличная статья. Сейчас отправлю ссылку своему главному заказчику. Чтоб правильно рассчитывал бюджет/ставил ТЗ и вообще имел концепцию :)))
В мемориз. Без сомнений.
Андрей, спасибо.
Андрей, спасибо.
в десяточку! Ща вышлю своему "любимому" заказчику :) пусть почитает и поймет, что это не я идиот-менеджер, а "что -то хотели" - "что-то и получили" :) в мемориз однозначно.
Сайт-памятник...
как желанно для каждого пользователя, потребителя, клиента, когда сайты "живут, растут и дышат". Мечта остается мечтой.
Андрей, продолжай в том же духе - ясно, практично и кратко.
как желанно для каждого пользователя, потребителя, клиента, когда сайты "живут, растут и дышат". Мечта остается мечтой.
Андрей, продолжай в том же духе - ясно, практично и кратко.
Есть еще одна распространенная ошибка: недооценка юзабильности или переоценка пользователей. Заказчик и разработчик, продвинутыые пользователи довольно сложных программулин, делают сайт, в который пользователи просто не врубаются. Граждане, делайте сервисы для тупых!
Классная статья.
Говорю это как веб-девелопер.
Послал линк шефу.
Говорю это как веб-девелопер.
Послал линк шефу.
в целом согласен, но бывают варианты, что заказчик игнорирует ТЗ, просто подписывает не читая, а через пару месяцев выясняется, что он хотел совсем не так. И опа, двойное попадалово - деньги потрачены и время ушло.
Вторая проблема, которая здесь не сильно поднята это четкие acceptance criteria (сорри, русский термин вылетел из головы) - надо четко представлять, что вас устраивает, а иначе, придется долго бодаться с разработчиками и, возможно, доплачивать за оптимизацию суммы сопоставимые с бюджетом проекта.
Вторая проблема, которая здесь не сильно поднята это четкие acceptance criteria (сорри, русский термин вылетел из головы) - надо четко представлять, что вас устраивает, а иначе, придется долго бодаться с разработчиками и, возможно, доплачивать за оптимизацию суммы сопоставимые с бюджетом проекта.
" ...заказчик игнорирует ТЗ, просто подписывает не читая, а через пару месяцев выясняется, что он хотел совсем не так. И опа, двойное попадалово - деньги потрачены и время ушло." - возьмите с заказчика предоплату 70%, и то что он не читал ТЗ, это его уже проблемы, а не Ваши. Хочет заказчик что-то другое - составте очередное тех. задание и пусть платит деньги впрёд.
"Утром деньги, в обед стулья(сайт)" и т.д.
"Утром деньги, в обед стулья(сайт)" и т.д.
Автору статьи !!!
"Довольно часто заказчик не может правильно оценить бюджет проекта" - Вы поставили всё с ног на голову.
Бюджет проекта определяет испольнитель(подрядчик) проекта, и это есть та самая стоимость, оказываемых услуг по разработке сайта.
"Довольно часто заказчик не может правильно оценить бюджет проекта" - Вы поставили всё с ног на голову.
Бюджет проекта определяет испольнитель(подрядчик) проекта, и это есть та самая стоимость, оказываемых услуг по разработке сайта.
Бюджет проекта определяет как раз таки заказчик. И уже исходя из имеющегося бюджета выбирает исполнителей.
При таком подходе заказчика и сайты получаются корявые, типа сделали на столько, на сколько денег было в кубышке.
А вообще цена на всё устанавливается рынком во всём цивилизованом мире, а не через одно место как у нас.
Простой пример: одна конторка подсчитала смету и обьявила потенциальному заказчику - 3000грн., а другой разработчик обьявил цену в 30 000 евро, и как Вы думаете у кого заказали разработку сайта ???
А вообще цена на всё устанавливается рынком во всём цивилизованом мире, а не через одно место как у нас.
Простой пример: одна конторка подсчитала смету и обьявила потенциальному заказчику - 3000грн., а другой разработчик обьявил цену в 30 000 евро, и как Вы думаете у кого заказали разработку сайта ???
UFO just landed and posted this here
Сайты корявые получаются совсем в другом случае. ;)
Если заказчик не понимает зачем ему сайт и соответственно не может расчитать бюджет, то и получаются "памятники" за бешенные деньги или кривые сайты собранные на коленке. Затраты на создание сайта - это обычное вложение в развитие бизнеса. Что тут непонятного? Причем здесь кубышка?
Если заказчик не понимает зачем ему сайт и соответственно не может расчитать бюджет, то и получаются "памятники" за бешенные деньги или кривые сайты собранные на коленке. Затраты на создание сайта - это обычное вложение в развитие бизнеса. Что тут непонятного? Причем здесь кубышка?
"...Если заказчик не понимает зачем ему сайт..." - так нафига попу гармонь ???
О брат! Это то и есть главный вопрос! 8)
И статья собствено во многом об этом.
Если бы заказчик всегда знал зачем ему гармонь и отдавал себе отчет инструмент какого уровня он может приобрести в свой бюджет, исполнителям бы было сплошное шоколадное счастие.
И статья собствено во многом об этом.
Если бы заказчик всегда знал зачем ему гармонь и отдавал себе отчет инструмент какого уровня он может приобрести в свой бюджет, исполнителям бы было сплошное шоколадное счастие.
Вот потому я и прикрыл лавочку по разработке сайтов, слишком много гемороя и головняка с эитми заказчиками.
Есть много других способов подьёма денег с инете.
Есть много других способов подьёма денег с инете.
А кто сказал что это легко? :)
К клиенту нужен индивидуальный подход.
А баян нужен ему затем, что у всех по баяну, а у него нет. Зачастую именно это стимулирует компании заказывать сайт не понимая что с ним делать. Думают ща сделаем сайт, напишем на всех визитках и СМИшной рекламе урлу и все, сразу все только с нами и будут работать.
Узкоспециализированный рынок как правило ограничен и все друг друга знают, вот и лепят у кого памятник да оградка симпотишней.
Тут либо принципы, либо клиенториентирование, либо действительно прикрывать лавку и зарабатывать другим способом.
К клиенту нужен индивидуальный подход.
А баян нужен ему затем, что у всех по баяну, а у него нет. Зачастую именно это стимулирует компании заказывать сайт не понимая что с ним делать. Думают ща сделаем сайт, напишем на всех визитках и СМИшной рекламе урлу и все, сразу все только с нами и будут работать.
Узкоспециализированный рынок как правило ограничен и все друг друга знают, вот и лепят у кого памятник да оградка симпотишней.
Тут либо принципы, либо клиенториентирование, либо действительно прикрывать лавку и зарабатывать другим способом.
отличнаястатья, довольно хорошо написана для неподготовленного "заказчика" :)
в мемориз :)
в мемориз :)
Хотел еще добавить один момент. Зачастую заказчик слишком торопит по срокам, хотя это не оправдано и не имеет под собой реального основания (например, у компании не было сайта до сего момента. Компания, вроде бы работала нормально, и вдруг директор решил, что надо сделать сайт через месяц и точка). Таким образом вынуждая менеджеров разработчика "лукавить" с определением сроков. И вместо двух месяцев на разработку в договоре красуется один. Иногда на такое приходится идти.
Результат — плохая статистика.
Причина со стороны заказчика — непонимание процессов создания сайта, самодурство.
Причина со стороны исполнителя — нежелание бороться за правильные цифры.
Результат — плохая статистика.
Причина со стороны заказчика — непонимание процессов создания сайта, самодурство.
Причина со стороны исполнителя — нежелание бороться за правильные цифры.
Текст очень по делу.
В копилку абсурдов: есть еще одна очень тяжелая болезнь, коррелирующая с отсутствием понимания цели сайта, - это когда "главный заказчик" (например директор компании) олицетворяет себя с сайтом, выливается это в бесконечный и неконструктивный "диалог" при утверждении дизайна.
В копилку абсурдов: есть еще одна очень тяжелая болезнь, коррелирующая с отсутствием понимания цели сайта, - это когда "главный заказчик" (например директор компании) олицетворяет себя с сайтом, выливается это в бесконечный и неконструктивный "диалог" при утверждении дизайна.
Only those users with full accounts are able to leave comments. Log in, please.
Типовые менеджерские ошибки, совершаемые заказчиком при разработке сайта