Типовые менеджерские ошибки, совершаемые заказчиком при разработке сайта

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

    Тот факт, что мне приходилось находиться “по обе стороны баррикад” позволяет взглянуть на ситуацию с разных сторон и постараться выделить ключевые моменты, определяющие ход проекта.

    1. Отсутствие четкого осознания целей проекта

    Очень часто при создании сайта у заказчика отсутствует четкое понимание целей, которые стоят перед проектом. И в итоге результат может оказаться плачевным: вы “что-то” попросили, мы “что-то” и сделали. Четкое понимание, что сайт нужен только для галочки и указания на визитках (а для многих компаний это так и есть) избавило бы множество заказчиков от головной боли и лишних трат.

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

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

    2. Неправильная оценка и распределение бюджета проекта

    Довольно часто заказчик не может правильно оценить бюджет проекта и правильно расставить приоритеты по аспектам работ. Очень часто заказчик исходит из личных предпочтений и устоявшихся стереотипов (например, “дизайн сайта не важен, главное — информация”). Это неверно, бюджет должен формироваться исходя из четкого понимания целей и задач проекта (см. пункт выше). Если вы определили, что основная задача сайта – поддержание бренда или определенной марки продукта в Сети, глупо экономить на разработке дизайн-концепции.

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

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

    СРОКИ

    Не секрет, что более 80% проектов по созданию сайтов не укладываются в изначально установленные сроки, и работа затягивается на время, иногда превосходящее календарный план в разы. Это касается практически всех проектов (как за 2-3 тысячи, так и за 20-30 тысяч) и студий-разработчиков любого уровня.

    Попытаемся выделить ключевые ошибки заказчика, которые приводят к затягиванию сроков по проекту:

    3. Затягивание согласования работ

    Главная причина затягивания сроков со стороны заказчика – мучительные согласования результатов работ. Особенно это касается разработки дизайн-концепции сайта. Чем больше людей со стороны заказчика участвуют в этом процессе (а по дизайну каждый считает себя специалистом) – тем больше хаоса привносится в проект. Это необходимо исключить – у проекта должен быть менеджер, курирующий все вопросы по проекту, а так же четко выделенный человек, принимающий окончательные решения. Разработчику обязательно нужно обеспечить доступ как к менеджеру, так и принимающему решения лицу, как бы трудно это ни было. Остальных “советчиков” необходимо исключить из процесса, потому что выполнения всех их пожеланий и комментариев (зачастую необоснованных и противоречащих друг другу) затянет проект на неопределенный срок. Это ни в коей мере не касается этапа тестирования сайта и выявления ошибок – тут нужно привлечь максимально широкий круг людей, чтобы вычистить все огрехи. Нужно четко построить модель взаимодействия по проекту с разработчиком именно на уровне менеджмента компании.

    При принятии решения по дизайну необходимо максимально абстрагироваться от собственных предпочтений и мыслить в категориях пользователя из ЦА и общей адекватности предлагаемых вариантов.

    Очень часто заказчик начинает “придираться” к мелочам в дизайне, хотя на самом деле ему не нравится предложенный концепт в принципе, но он просто не может (или опасается) это выразить. Важно отследить этот момент и предложить разработать новый вариант. Разработчику это будет проще, чем потратить месяцы на согласование не играющих роли мелочей, которые все равно не добавят удовлетворенности заказчику. Не теряйте за мелочами общего видения проекта!

    Еще один важный аспект – не пускайте проект на самотек. Очень часто после первого срыва сроков по этапам, заказчик расслабляется и перестает оперативно реагировать на ситуацию. Это может привести к огромным задержкам по срокам, поскольку разработчик часто склонен сделать то же самое. Проект может попасть в “мертвую точку”, когда все потеряли к нему интерес. Сдвинуть ситуацию с этой точки может стоить огромных усилий.

    4. Неправильная организация этапа подготовки материалов на сайт

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

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

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

    “Хорошая ситуация” – когда на момент старта проекта в студию приезжает менеджер со стороны клиента и привозит кипу бумаг и высокую стойку CD с информацией (все-все, что он смог собрать). Это правильно.

    Разработчик не обманывает вас, когда говорит, что материалы крайне важны для его работы. Это действительно так. Идеальная ситуация – 100%-ая готовность материалов на момент начала работ по дизайну. Наличие материалов к этому моменты позволит вам существенно ускорить процесс, а также лишить разработчика типичной отговорки “не было материалов, поэтому задержали сроки”, хотя, как правило, это не является отговоркой, а действительной причиной.

    5. Отсутствие дедлайна работ

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

    6. Оптимизм исполнителя при составлении календарного плана

    Довольно часто при утверждении календарного плана разработчик рассматривает “идеальную ситуацию” и указывает слишком малые сроки. Идеальных проектов не бывает, это надо помнить. Календарный план нужно оценить на общую адекватность, обязательно проверить на наличие этапов на согласование работ и подписание документов, получение оплаты и пр.

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

    7. Нарушение типового цикла проведения работ

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

    Например, заказчик часто требует начать параллельно с этапом дизайна этап сборки и верстки сайта. Это в корне неверно, поскольку при внесении изменений в дизайн-макеты может поменяться вся концепция ресурса, и все выполненные работы по дальнейшим этапам пойдут насмарку.

    Типовой цикл прохождения проекта выглядит примерно так:

    • 1) Определение целей и задач проекта

      2) Определение позиционирования, анализ информации о продукции/услугах и ЦА

      3) Разработка общей веб-стратегии компании (проекта).
      В веб-стратегию должна войти информация о целях и задачах ресурса, ЦА, проведен анализ конкурентов, должны присутствовать рекомендации по структуре и функционалу сайта, а также разработан примерный план дальнейшего продвижения ресурса (анализ действий конкурентов, примерные мероприятия и бюджеты). Составление подобной стратегии существенно помогает на всех стадиях жизненного цикла вашего проекта. Имеет смысл заказывать разработку стратегии внешней по отношению к вашему подрядчику экспертной структуре.

      4) Разработка Технического Задания (ТЗ) на сайт, итоговой сметы и календарного плана работ.

      Задача ТЗ – максимально подробно определить все аспекты работ по сайту, создать единое видение (это очень важно) проекта и заказчика и исполнителя.

      5) Разработка дизайн-концепции сайта

      6) Разработка макета главной страницы

      7) Разработка макетов внутренних страниц

      8) HTML-верстка сайта

      9) Разработка анимационных FLASH-элементов

      10) Сборка сайта на базе CMS-системы и разработка дополнительного функционала

      11) Контент-наполнение сайта, пакетный внос данных в БД

      12) Запуск пилотной версии сайта, тестирование, устранение ошибок

      13) Перенос сайта на хостинг, тестирование, открытие сайта


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

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

      8. Создание “сайта-памятника”

      Еще одна типовая ошибка заказчика – считать, что после создания сайта его работа по развитию Интернет-направления заканчивается. Это в корне не верно. Создание сайта – точка “ноль” для его существования. Чтобы сайт стал эффективным маркетинговым инструментом, необходимо разработать стратегию его продвижения, а также на постоянной основе заниматься его обновлениями, мониторингом состояния, произведением улучшений и доработок, развитием.

      В сети существует множество примеров красивых “сайтов-памятников”, которым не уделяется внимания со стороны их владельцев. Они висят “мертвым грузом”, не принося никакой пользы и сводя к нулю все усилия, потраченные на их разработку.

      Небольшой пример – большинство заказчиков хотят видеть на своем сайте ленту новостей, которая публикуется на главной странице. При этом у большинства компаний не хватает сил поддерживать ее в актуальном состоянии (или просто нет должного количества информационных поводов). Определите этот момент еще на стадии проектирования, ведь нет ничего хуже сайта с новостями за прошлый год на первой странице – он моментально создает у пользователя ощущение “заброшенности ресурса”. Лучше не публикуйте новости вообще, они, как правило, не очень интересны пользователю.

      МЕЛКИЕ ОШИБКИ

      Так же можно выделить ряд более мелких ошибок, обычно совершаемых заказчиком, рассмотрение которых при этом может быть интересно:

      9. Регистрация домена студией или лично менеджером проекта

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

      10. Большая предоплата фрилансеру

      Работая с фрилансером, необходимо помнить. Что получение большой предоплаты крайне расслабляет человека и сводит его мотивацию практически к нулю. Этот грустный факт подтвержден многолетним опытом. Не давайте предоплату частнику более 10-20% процентов, даже если вы очень в нем уверены. Это не касается работы с крупными студиями – получение предоплаты в 40-60% процентов от бюджета проекта является нормой для рынка.

      11. Отсутствие контроля откатов

      Мы живем в России, и не надо забывать о существующей повсеместно практике откатов. Если ваш менеджер, которому вы поручили создание сайта, настойчиво рекомендует конкретного исполнителя, и у вас появляются сомнения в разумности представленной сметы, ее необходимо проверить. Отправьте запрос в 2-3 компании, работающие в диапазоне вашего общего бюджета, и сравните их с предлагаемой сметой. Возможно, вы будете неприятно удивлены.

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

      Терехов Андрей (andrey@terekhov.ru)
    Поделиться публикацией

    Похожие публикации

    Комментарии 51
      +1
      Материал получился довольно объемный, но я надеюсь, что многие смогут почерпнуть там полезную информацию.
      В свою очередь, предлагаю публиковать в комментарии типовые ошибки, не вошедшие в материал, а я по результатам дискуссии произведу через пару дней апдейт статьи.
        0
        Да, очень хорошая подборка, спасибо. Теперь, в случае чего, можно просто давать ссылку, не утруждая себя разъяснениями:) Изложено доходчиво, понятно.
          0
          замечательно и по-делу :)
          0
          Блестящий материал, Андрей!
            +1
            Спасибо, рад, что понравился =)
              0
              + 1, в избранное!
              +1
              Автор молодец, написано хорошо.

              Самое гланое это конечно: Отсутствие четкого осознания целей проекта или по другому "да чтоже тебе надо с!"
              У меня когда-то был начальник который каждый месяц, обсуждал со всеми нами концепцию сайта и в течении 1,5 года что я там работал мы собирались и каждый что-то говорил, потом через месяц концепция признавалась неправильной и все делалось по новой.
                +2
                Да, осознание, зачем все это надо - ключевой момент любого проекта вообще. Поэтому под номером один и записал.
                  0
                  Через месяц менять концепцию - это, конечно, работать плодотворно не позволит, а через полгода - почему бы и нет?

                  В таком случае возможность довольно сильной переработки структуры информации стоит закладывать сразу.

                  Примерно то же можно сказать о редизайне - рестайлинг, смену торговой марки и т.п. лучше планировать заранее. Ну по крайней мере обозначить, что через год-два будет, скорее всего, меняться то-то и то-то.

                  Чтобы не переделывать всё.
                    +1
                    Согласен с Вами. Статья отличная. Осознание - важнейшая часть проекта.
                    0
                    Клевая статья, чем то похожа на статью Ашманова, правда он там клеймил программистов..:)

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

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

                    P.S. – Хорошо заполненный бриф – уже половина дела!
                      0
                      Всё так... Но когда заказчик говорит "ничего навороченного" мозг тянет в дрёму и трудно сразу поверить что именно этот клиент выжмет из тебя все соки. А не хочешь проблем - составляй четкое ТЗ...
                        +1
                        Собственно о том и речь - ТЗ (Дизайн-концепт) будет очень долго утверждаться и к любому из вариантов придется делать визуализацию причем очень хорошего уровня.
                        В конце проекта, прибыль будет так не значительна при соотношении потраченного времени на один такой проект, что в будущем задумаешься о подобном сотрудничестве. Либо усиливать юридические моменты сделки.
                      +7
                      На самом деле, это ошибки, применимые не только к заказчикам сайтов, но и к любому управлению проектами. Основы менеджмента форева!))))А статья очень интересная и полезная получилась. Спасибо за отличное переложение теоретических основ на актуальную практику))
                        0
                        Пункты 6 и 7 в типовом цикле прохождения проекта я бы поменял местами. Конечно, первая страница продает лучше, но базовых значительно больше, и отталкиваться лучше от них. Это если сайт не для визитки :)
                          0
                          Регистрация домена студией с одной стороны, конечно, ошибка. С другой стороны, когда у компании-заказчика нет человека, который смог бы вовремя перерегистрировать домен, есть реальный риск потерять домен вообще навсегда. В моей практике прецеденты были.
                            +1
                            Это тоже верно, и на моей практике такие случаи были. Хоть гораздо чаще домен просто снимается с делегирования и сайт падает. Это сразу видно, поэтому до потери домена редко доходит.
                            0
                            Очень хорошая статья. Уже в избранном.
                            От себя добавил бы:
                            1. Обязательное разделение этапов разработки с соответствующим документальным закрытием по этапам.
                            2. Цикл прохождения проекта может коренным образом отличаться от приведенного (хотя это и так понятно). Например если необходимо прототипирование.
                              0
                              Контролем откатов должна заниматься служба безопасности. А то получается, что где-нибудь на Age of web висит средняя минимальная стоимость сайта, равная 730$ (внизу страницы), но это совершенно не значит, что вот эти ребята живут исключительно с откатов.
                                +1
                                Служба безопасности есть далеко не везде, да и черт ногу сломит в нашей терминологии, не смогут отследить =)
                                +5
                                Статья хорошая, но почему вы ее опубликовали в "колонках" не в "блогах"? ИМХО, тут она потеряется. Конечно, больше охват аудитории, чем в блоге, но вы же не одну статью на эту тему напишите? ;-)

                                В целом с мыслями согласен. Самое смешное, что практически все это прописано в старом-добром ГОСТ 34 "Информационные системы", от которого все воротят нос из-за того, что он якобы старый. На самом деле, вы его и описали. Весь вопрос в жизненном цикле системы. Вот если использовать каскадную или итерационную модель, тогда методика и система управления проектом поменяются. Даже со стороны заказчика.

                                Далее, про сроки. Если вы назначаете только дедлайн - это гарантированный пролет по срокам, потому как вы не можете оценить в процессе разработки степень отклонения по срокам, а отклонения есть всегда. В Project Management принято понятие Milestones - контрольные точки. По сути - это сроки завершения каждого из подэтапов. Тогда вы на каждом этапе сможете оценить изменение по срокам.

                                Касательно приведенной этапности работ. Это пример этапности для очень простого шаблонного сайта с минимальной управляемостью и отсутствием интеграции с какими-либо другими ИС. Потому как в противном случае, в начале надо определиться с платформой разработки, а она в свою очередь может существенно органичить возможность дизайна. В случае сложной системы, проектирование системы и БД затмит дизайн, как бык овцу.

                                Ну и конечно, документирование системы и обучение специалистов заказчика. Отдельный разговор о приемке системы.
                                  +2
                                  Опубликовал в колонках, поскольку формат показался более подхяодящим =)

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

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

                                  Спасибо за комментарии!
                                    0
                                    Всегда приятно комментировать хорошо изложенные мысли!

                                    А расписывать надо. Потому как и заказчику надо понимать внутреннюю кухню, а также основы управления требованиями. Иначе никакого ТЗ в реальные сроки не появится. Проверял на собственной шкуре неоднократно.
                                  0
                                  "1. Отсутствие четкого осознания целей проекта" - очень верно что "номер один"!
                                  отличная статья.
                                    0
                                    Чётко написаниое ТЗ со всеми прибамбасами от заказчика как приложение к подписаному договору с обеих сторон, шаг в лево шаг, шаг в право от ТЗ, соответственно и цена растёт в геометрической прогрессии - $$$$$$$$$$$$$$$, что тоже необходимо чётко указать в договоре.

                                    Заказчик такая сука, что всю кровь выпьет,пока Вы не заставите его подписаться под чётко сформулированным ТЗ и полный вперёд после предоплаты в 70% от стоимости заказа:-)
                                      0
                                      С трудом представляю четко прописанный Дизайн-концепт и привязку к функциональности, все равно тот же шаг влево, шаг вправо будет.
                                      Исходить он причем будет от разработчика, поскольку иной раз из-за мелочи складывается представление о проекте и его разработчике. Опять же было бы не лишний подписать доп. соглашение на поддержку ресурса, кроме оговоренных сроков гарантии.
                                        +1
                                        Четко написанное ТЗ при непонимании Заказчиком, чего ему надо от сайта, выльется в бесполезную поделку, которой ни Заказчик доволен не будет, ни студия в портфолио положить без стыда не сможет
                                        0
                                        Спасибо, Андрей.
                                        Очень хорошая подборка материала в хорошо изложенном виде.
                                          0
                                          Отличная статья. Сейчас отправлю ссылку своему главному заказчику. Чтоб правильно рассчитывал бюджет/ставил ТЗ и вообще имел концепцию :)))
                                            0
                                            В мемориз. Без сомнений.
                                            Андрей, спасибо.
                                              0
                                              в десяточку! Ща вышлю своему "любимому" заказчику :) пусть почитает и поймет, что это не я идиот-менеджер, а "что -то хотели" - "что-то и получили" :) в мемориз однозначно.
                                                0
                                                Сайт-памятник...
                                                как желанно для каждого пользователя, потребителя, клиента, когда сайты "живут, растут и дышат". Мечта остается мечтой.

                                                Андрей, продолжай в том же духе - ясно, практично и кратко.
                                                  +1
                                                  Есть еще одна распространенная ошибка: недооценка юзабильности или переоценка пользователей. Заказчик и разработчик, продвинутыые пользователи довольно сложных программулин, делают сайт, в который пользователи просто не врубаются. Граждане, делайте сервисы для тупых!
                                                    0
                                                    Ну для тупых то уж не надо.
                                                    Есть же практически целая наука - юзабилити.
                                                    Интерфейс должен быть предсказуем.
                                                    0
                                                    Классная статья.
                                                    Говорю это как веб-девелопер.
                                                    Послал линк шефу.
                                                      0
                                                      в целом согласен, но бывают варианты, что заказчик игнорирует ТЗ, просто подписывает не читая, а через пару месяцев выясняется, что он хотел совсем не так. И опа, двойное попадалово - деньги потрачены и время ушло.

                                                      Вторая проблема, которая здесь не сильно поднята это четкие acceptance criteria (сорри, русский термин вылетел из головы) - надо четко представлять, что вас устраивает, а иначе, придется долго бодаться с разработчиками и, возможно, доплачивать за оптимизацию суммы сопоставимые с бюджетом проекта.
                                                        0
                                                        " ...заказчик игнорирует ТЗ, просто подписывает не читая, а через пару месяцев выясняется, что он хотел совсем не так. И опа, двойное попадалово - деньги потрачены и время ушло." - возьмите с заказчика предоплату 70%, и то что он не читал ТЗ, это его уже проблемы, а не Ваши. Хочет заказчик что-то другое - составте очередное тех. задание и пусть платит деньги впрёд.

                                                        "Утром деньги, в обед стулья(сайт)" и т.д.
                                                          0
                                                          Автору статьи !!!

                                                          "Довольно часто заказчик не может правильно оценить бюджет проекта" - Вы поставили всё с ног на голову.


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

                                                              А вообще цена на всё устанавливается рынком во всём цивилизованом мире, а не через одно место как у нас.

                                                              Простой пример: одна конторка подсчитала смету и обьявила потенциальному заказчику - 3000грн., а другой разработчик обьявил цену в 30 000 евро, и как Вы думаете у кого заказали разработку сайта ???
                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                  0
                                                                  Так вот, сайт заказали у Тёмы Лебедева, потому как это круто:-), и качество гарантировано.
                                                                  0
                                                                  Сайты корявые получаются совсем в другом случае. ;)
                                                                  Если заказчик не понимает зачем ему сайт и соответственно не может расчитать бюджет, то и получаются "памятники" за бешенные деньги или кривые сайты собранные на коленке. Затраты на создание сайта - это обычное вложение в развитие бизнеса. Что тут непонятного? Причем здесь кубышка?
                                                                    0
                                                                    "...Если заказчик не понимает зачем ему сайт..." - так нафига попу гармонь ???
                                                                      0
                                                                      О брат! Это то и есть главный вопрос! 8)
                                                                      И статья собствено во многом об этом.
                                                                      Если бы заказчик всегда знал зачем ему гармонь и отдавал себе отчет инструмент какого уровня он может приобрести в свой бюджет, исполнителям бы было сплошное шоколадное счастие.
                                                                        0
                                                                        Вот потому я и прикрыл лавочку по разработке сайтов, слишком много гемороя и головняка с эитми заказчиками.

                                                                        Есть много других способов подьёма денег с инете.
                                                                          +1
                                                                          А кто сказал что это легко? :)

                                                                          К клиенту нужен индивидуальный подход.
                                                                          А баян нужен ему затем, что у всех по баяну, а у него нет. Зачастую именно это стимулирует компании заказывать сайт не понимая что с ним делать. Думают ща сделаем сайт, напишем на всех визитках и СМИшной рекламе урлу и все, сразу все только с нами и будут работать.
                                                                          Узкоспециализированный рынок как правило ограничен и все друг друга знают, вот и лепят у кого памятник да оградка симпотишней.

                                                                          Тут либо принципы, либо клиенториентирование, либо действительно прикрывать лавку и зарабатывать другим способом.
                                                                            0
                                                                            Респект полный:-)

                                                                            Не в бровь, а в глаз.
                                                              0
                                                              отличнаястатья, довольно хорошо написана для неподготовленного "заказчика" :)
                                                              в мемориз :)
                                                                0
                                                                Хотел еще добавить один момент. Зачастую заказчик слишком торопит по срокам, хотя это не оправдано и не имеет под собой реального основания (например, у компании не было сайта до сего момента. Компания, вроде бы работала нормально, и вдруг директор решил, что надо сделать сайт через месяц и точка). Таким образом вынуждая менеджеров разработчика "лукавить" с определением сроков. И вместо двух месяцев на разработку в договоре красуется один. Иногда на такое приходится идти.
                                                                Результат — плохая статистика.
                                                                Причина со стороны заказчика — непонимание процессов создания сайта, самодурство.
                                                                Причина со стороны исполнителя — нежелание бороться за правильные цифры.
                                                                  0
                                                                  Текст очень по делу.

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

                                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                  Самое читаемое